From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pz2-f12.google.com (mail-pz2-f12.google.com [74.125.228.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D30343B2D14 for ; Sun, 27 Sep 2026 05:15:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.228.12 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790486122; cv=none; b=F2qYb5GGpyrZ7wB8apd1AACDK98bX3fdrXir9fiEWnCQf21/54JVsCVbqKqGPkaZ3UvtLqPR2Nxo0F/fV29e2ZL8ad+wMbUo0E8suqPrQDk2gRr7LWS0ALmEGNt/BZDP33g4EXGlMv2TzEaBsof9mkVDygLRupSmUcrLrHVmQSE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790486122; c=relaxed/simple; bh=Mj6a9MgdGCqWYAQGPhRA9sgl7Qe9WwUI4ge989Hfa88=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=AOZ1e4/GjPOeZ+T90oTCgPM2H5BEJ/YiZimTRVBd+tUSyYH9MuAyPKSM0gmI02SgqsULNPOUYt/aopYlZh0zMc23FeEK+P2Pucp9Qbj10GtcQmDliCw0Z8b9cTtMmX2QlmioGwrp3m92uHSMV+F0iCr+Woi25zi0/8MfIF2l10g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=OtbCbEAL; arc=none smtp.client-ip=74.125.228.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="OtbCbEAL" Received: by mail-pz2-f12.google.com with SMTP id d2e1a72fcca58-85469f204f6so976864b3a.2 for ; Sat, 26 Sep 2026 22:15:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790486120; x=1791090920; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=OjKSfukDZvlY1eXjlV/PoddSyojDKst8RtQu8NrZS7I=; b=OtbCbEALZGSTOiKY8BVEckLUD9ldbK5dm0D6aa1cI8I730FdFdac2alwxRhh1HRViV n+dtNgfbhS32jt0q9eWBN1IDQMMSVtDChdhx+EUPOdVJfeu3oLExKxGDY0SfAOn4YzYO kAVraD65UwfYXeB+lagYMhT6HMyGBZaJFyZ184/Giu4NA0JESZoqWl6LR0vdvSxVUJiq Sg2QkGJjqWxLbt6BwejAAoInbSp25n2CTW5XMLW/mvKGxFaWjbnFG3UYojN7Pi5FusK9 /9pt9Obi8op9riSFp11xFxT4SvUEySRU/44Duh5F05BsNTYBW+jk0UhDq0mfHxHCssHM /gmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790486120; x=1791090920; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=OjKSfukDZvlY1eXjlV/PoddSyojDKst8RtQu8NrZS7I=; b=zVTQvfYd4kLd4D2RX6LHx/G+vaPLTG82b6LLaweGQV0bfWeSC9uvQTu9RzXRz+RsEG whyeOae2iiiNjipy36SqMxeUWHhMYKheKtnow+GHeqbPTRd+MwJ+0KIjxyag6bDJyf9b CuyhN1eh6vbYleYbcUrl6rOfA3pZCXE0F7bCP303AEbSmt2YC3rNiG01I378UQRKL5YX pL0MyBHDGeMF4JNDGtFxMHJox0TaOr/Y94D6t04ORCcbvij6hcbBGIM2PcGWgL+pwD2s hiHLzxcXq/zBWSaVqDiRR6+ONP2QRjvhUiu8+jYIA538pOc3Z3vADpF+Qj85qhmMjHds 60iA== X-Forwarded-Encrypted: i=1; AKwUvBwnu5qIUobwsojSGRKj6Fwcnj6X0iXZa2aCFS0/WOqb95tSpAEFeFu5p9MA8JJRKmHRBMUj8izne8ufuvc=@vger.kernel.org X-Gm-Message-State: AFuF++kSZ2QcLM0OZSppQzX2hYOFf4/aN52it96c0xNy4iGkJcSBnKfJ oGb3v1Eqgif4juYSxPbeVct3ECXl6Cpv7e0ub4ZRQS151hKNkuHv4Tgk X-Gm-Gg: AYBFou3EX500tdlLCcDX8RGfYT4dile9wmhdkASEQMJUEvdGeRBAU1BvX3dTa78HJ41 brAshEPo4gdhrUAaORit2Je1Z9LTsc7wjKlMrYikbGbOjY4fwuaHqfaM4U0hrvZvVfyRTrXQwv6 2jCBJVHNEADAjrJuzu6U9Akmn4DKDJvjBXXc25n89Crp3xW0vVb1XZ4w7ON2HOb38iAokUGK3Aa uKe/3O7xXc4R1/8liVUDEWKr3VFs1p6CzoK+xkp50kakY7D5VjctJjK1rP3DzqBkp+ExW1f+h7C he6qNbPqltnr6JriVnajUplYULAOKR0712YZlvVyWM1kR9miPhv5MPr3Ms+YlGn88QT58gqMqTT VyCjh1TJmnGAItDLYgL6w+Lsy7T3Gaei2tsO2pC90V7cZoZRhrE9LwjhMB9biM5I8H5T1m6pL/y IWbxsqu+oclEI4tSyOUk9P2KBiYZuikhrREuMSyDTbeXej+ijOddOZWHJzNsE3zA75BE0Frw== X-Received: by 2002:a05:6a00:464e:b0:881:e266:c3d4 with SMTP id d2e1a72fcca58-881e266c980mr1869862b3a.25.1790486119873; Sat, 26 Sep 2026 22:15:19 -0700 (PDT) Received: from gmail.com ([2a03:2880:7ff:4::]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-87feaf852d7sm2718078b3a.42.2026.09.26.22.15.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 26 Sep 2026 22:15:17 -0700 (PDT) Date: Sat, 26 Sep 2026 22:14:55 -0700 From: Narcisa Vasile To: Hamza Mahfooz Cc: netdev@vger.kernel.org, "K. Y. Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , Stanislav Fomichev , Simon Horman , Erni Sri Satya Vennela , Dipayaan Roy , Aditya Garg , Jacob Keller , Saurabh Sengar , linux-hyperv@vger.kernel.org, bpf@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH net] net: mana: reserve RX buffer headroom to fix forwarding performance Message-ID: References: <20260923144500.4073380-1-hamzamahfooz@linux.microsoft.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260923144500.4073380-1-hamzamahfooz@linux.microsoft.com> On Wed, Sep 23, 2026 at 10:45:00AM -0400, Hamza Mahfooz wrote: > Commit 730ff06d3f5c ("net: mana: Use page pool fragments for RX buffers > instead of full pages to improve memory efficiency.") started handing > out RX buffers with zero headroom so that two buffers fit into one page > at the default MTU. > > The MANA TX path, however, stores the per scatter-gather entry DMA > mappings in `struct mana_skb_head` at skb->head, and mana_start_xmit() > therefore calls skb_cow_head(skb, MANA_HEADROOM). The port advertises > this requirement as ndev->needed_headroom = MANA_HEADROOM. > > As a result every packet that is received and then forwarded out of a > MANA port fails the skb_cow() in ip_forward() and gets reallocated and > copied by pskb_expand_head(). This is invisible to a plain RX or TX > workload, but it puts a full skb reallocation plus memcpy on the hot > path of every single forwarded packet, which is exactly what a > router/NVA workload does. > > Restore the headroom. Note that reserving MANA_HEADROOM (232) is not > enough: ip_forward() asks for LL_RESERVED_SPACE(dev), which rounds > hard_header_len + needed_headroom up to HH_DATA_MOD and is 256 bytes on > ethernet. Use LL_RESERVED_SPACE() directly so the value keeps tracking > both constants. > > At the default MTU on a 4K page this means a buffer no longer fits twice > into a page (SKB_DATA_ALIGN(1500 + MANA_RXBUF_PAD + 256) = 2112), so the > frag-vs-single decision is now made by computing the real buffer size > instead of comparing the MTU against PAGE_SIZE / 2. The page_pool > fragment path is still used wherever at least two buffers genuinely fit, > e.g. on 16K and 64K page sizes. > > Measured on an Azure VM with a MANA NIC acting as a forwarding NVA (UDP, > 1400 byte payload, 4 streams, 8 Gbps offered, only the forwarding > node's kernel differs), 8 runs each, median: > > forwarded pps throughput > before 272,830 3.06 Gbps > after 390,560 4.37 Gbps (+43%) > > perf on the forwarding node, same workload: > > memset_orig __pi_memcpy pskb_expand_head > before 10.07% 3.96% present > after 0.94% 0.64% gone > > Cc: stable@vger.kernel.org > Fixes: 730ff06d3f5c ("net: mana: Use page pool fragments for RX buffers instead of full pages to improve memory efficiency.") > Signed-off-by: Hamza Mahfooz > --- > drivers/net/ethernet/microsoft/mana/mana_en.c | 58 ++++++++++++++----- > 1 file changed, 44 insertions(+), 14 deletions(-) > > diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c > index 591fb4191d90d..e3f3b33ba9062 100644 > --- a/drivers/net/ethernet/microsoft/mana/mana_en.c > +++ b/drivers/net/ethernet/microsoft/mana/mana_en.c > @@ -758,6 +758,36 @@ static void *mana_get_rxbuf_pre(struct mana_rxq *rxq, dma_addr_t *da) > return va; > } > > +/* RX buffers must be allocated with enough headroom for the TX path: > + * mana_start_xmit() stores the SGE DMA mappings in struct mana_skb_head at > + * skb->head, which is why the port advertises ndev->needed_headroom = > + * MANA_HEADROOM. > + * > + * An skb that is forwarded out of a MANA port has to satisfy > + * skb_cow(skb, LL_RESERVED_SPACE(dev) + ...) in ip_forward(), so reserve > + * LL_RESERVED_SPACE() here rather than just MANA_HEADROOM - it rounds > + * hard_header_len + needed_headroom up to HH_DATA_MOD and is therefore > + * larger. Reserving less makes every forwarded packet get reallocated and > + * copied by pskb_expand_head(). > + */ nit: maybe trim this comment to make it easier to read. For example, "Reserve enough headroom to satisfy the skb_cow() call in ip_forward() and avoid reallocation." > +static u32 mana_get_rxbuf_headroom(struct mana_port_context *apc) > +{ > + u32 headroom = LL_RESERVED_SPACE(apc->ndev); > + > + if (mana_xdp_get(apc)) > + return max_t(u32, headroom, XDP_PACKET_HEADROOM); > + This implies that the headroom could now be greater than XDP_PACKET_HEADROOM, in XDP case. Should we then use the actual headroom value, instead of assuming XDP_PACKET_HEADROOM, in mana_run_xdp() when preparing the buffer: line 94: xdp_prepare_buff(xdp, buf_va, XDP_PACKET_HEADROOM, pkt_len, true); Does MANA_XDP_MTU_MAX need to be updated? > + return headroom; > +} > +