From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pz2-f40.google.com (mail-pz2-f40.google.com [74.125.228.40]) (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 D2ED136CE19 for ; Sun, 27 Sep 2026 05:15:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.228.40 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790486122; cv=none; b=Rgg153bcpY5Tj1Hp6/ihHC5fu8G6D8VEckzGATeXDlqxzQpa+aitp3cmk8yCA2I6HHufzTeEW6kUVAWRCc7hqupmmU3vHEGarHCaRlkoPgIpGEz02VWhNZCJwYC7oUxZhuabxmTdMd7oJi3Bj3IPJc1s6ejOzjlNfcw006siJ3Q= 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.40 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-f40.google.com with SMTP id d2e1a72fcca58-8804b59404aso834271b3a.3 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=H+kdt0y4/k5PafcqpVXumg/1zHep6ndtLRHOqEtmso6qPP+fd/ehFV31RSYmN76Una FaNDP1x9x+6Z6q3dUcL/OB/K0fw4SMvtXz5bYYq2zTOO26k4RZyIpu+tdAV+uOVJxve0 yYI42nQMt+NHcKo5+XBr/CDBGOLGzVFAjwUiF7zVc4zVDeJ6Fh7l3bsKpAgIkK5lZ/In bAjj98YtQTSBdDxcFP3gcccTV2swFTBPkiBJ0pG7IiLu6uQdhkpvy6lLxJxU8SB14BeO Jf5Ou3PfpeSUV8Svysozzhluu+0fznvUCi2Kgx2JCXqkRCVQRMxFJetaXFSP2tSU6e4i Qujw== X-Forwarded-Encrypted: i=1; AKwUvBxH8hHRHnRk0hwsUz50mtoshLaSVgn7Ciwx5WSBWbhEQmHhOMPgbTXk32V59kGJM90VMLGaPYPzJT3me+c=@vger.kernel.org X-Gm-Message-State: AFuF++n7X4fur9ltAiMsoXmT0NrAwzXucye5atP+OucDdqiVSwkaiP6j WJbIyEpV5lLMueuP1sTiXSvoqJE2KFE8D+/dAB30A/L8GS2HrOMaVnpa X-Gm-Gg: AYBFou2A1Lmxv2P0dGkyhJrnT4Xrz1rvgj47ZZxSwjDcaoeoDvuZdYU/yPjeq08+F9z J5cSNMv5XP/QanV0l81VMNI7dyXiai+WrJGgqmdx7a5pme5GHTu4+3uAR+tJfKz4u4hESjisMJY +b+uUPyaE+lylo+GG48epxwmM5eHHirvoZ58DQafC3lhGaBd+wIia79g278D5iDFoyMHNvOA763 spqznblA2o3giuZNXsnX8rZkHK4ly/x+gspQwRpk9kVlRQyWpdNr32FFCUQ79yyyRI/9Qe32TQ2 FAkbVju6gh/DWL51OnjOzuZSTNxOnOfQBGg4kMsh49CAxONA0TNZOoiSCRT+LMT6ZVDXn7gQ1mw ZPRnCVFi2aG1ue+nBXk1xp+lnkKn69KHR0kgYRkRIoso73B9DOhGhT1PWSJ3ZMF7Aj8eTFowaDN fFZM7+CFDF3onbWAPg1CXnkOS92TxY7Bk3kuWmDE0lLiADs1/gvvpiqUHqUmu59+Z+zwj2Mg== 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-hyperv@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; > +} > +