linux-kernel - RE: [PATCH V3,net-next, 2/4] net: mana: Refactor RX buffer allocation code to prepare for various MTU

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <PH7PR21MB3116194E8F7D56EB434B56A6CA989@PH7PR21MB3116.namprd21.prod.outlook.com>
Date:   Thu, 13 Apr 2023 14:03:50 +0000
From:   Haiyang Zhang <haiyangz@...rosoft.com>
To:     Leon Romanovsky <leon@...nel.org>
CC:     "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Dexuan Cui <decui@...rosoft.com>,
        KY Srinivasan <kys@...rosoft.com>,
        Paul Rosswurm <paulros@...rosoft.com>,
        "olaf@...fle.de" <olaf@...fle.de>,
        "vkuznets@...hat.com" <vkuznets@...hat.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "wei.liu@...nel.org" <wei.liu@...nel.org>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        Long Li <longli@...rosoft.com>,
        "ssengar@...ux.microsoft.com" <ssengar@...ux.microsoft.com>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        "daniel@...earbox.net" <daniel@...earbox.net>,
        "john.fastabend@...il.com" <john.fastabend@...il.com>,
        "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
        "ast@...nel.org" <ast@...nel.org>,
        Ajay Sharma <sharmaajay@...rosoft.com>,
        "hawk@...nel.org" <hawk@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH V3,net-next, 2/4] net: mana: Refactor RX buffer allocation
 code to prepare for various MTU



> -----Original Message-----
> From: Leon Romanovsky <leon@...nel.org>
> Sent: Thursday, April 13, 2023 9:04 AM
> To: Haiyang Zhang <haiyangz@...rosoft.com>
> Cc: linux-hyperv@...r.kernel.org; netdev@...r.kernel.org; Dexuan Cui
> <decui@...rosoft.com>; KY Srinivasan <kys@...rosoft.com>; Paul Rosswurm
> <paulros@...rosoft.com>; olaf@...fle.de; vkuznets@...hat.com;
> davem@...emloft.net; wei.liu@...nel.org; edumazet@...gle.com;
> kuba@...nel.org; pabeni@...hat.com; Long Li <longli@...rosoft.com>;
> ssengar@...ux.microsoft.com; linux-rdma@...r.kernel.org;
> daniel@...earbox.net; john.fastabend@...il.com; bpf@...r.kernel.org;
> ast@...nel.org; Ajay Sharma <sharmaajay@...rosoft.com>;
> hawk@...nel.org; linux-kernel@...r.kernel.org
> Subject: Re: [PATCH V3,net-next, 2/4] net: mana: Refactor RX buffer allocation
> code to prepare for various MTU
> 
> On Wed, Apr 12, 2023 at 02:16:01PM -0700, Haiyang Zhang wrote:
> > Move out common buffer allocation code from mana_process_rx_cqe() and
> > mana_alloc_rx_wqe() to helper functions.
> > Refactor related variables so they can be changed in one place, and buffer
> > sizes are in sync.
> >
> > Signed-off-by: Haiyang Zhang <haiyangz@...rosoft.com>
> > Reviewed-by: Jesse Brandeburg <jesse.brandeburg@...el.com>
> > ---
> > V3:
> > Refectored to multiple patches for readability. Suggested by Jacob Keller.
> >
> > V2:
> > Refectored to multiple patches for readability. Suggested by Yunsheng Lin.
> >
> > ---
> >  drivers/net/ethernet/microsoft/mana/mana_en.c | 154 ++++++++++-------
> -
> >  include/net/mana/mana.h                       |   6 +-
> >  2 files changed, 91 insertions(+), 69 deletions(-)
> 
> <...>
> 
> > +static void *mana_get_rxfrag(struct mana_rxq *rxq, struct device *dev,
> > +			     dma_addr_t *da, bool is_napi)
> > +{
> > +	struct page *page;
> > +	void *va;
> > +
> > +	/* Reuse XDP dropped page if available */
> > +	if (rxq->xdp_save_va) {
> > +		va = rxq->xdp_save_va;
> > +		rxq->xdp_save_va = NULL;
> > +	} else {
> > +		page = dev_alloc_page();
> 
> Documentation/networking/page_pool.rst
>    10 Basic use involves replacing alloc_pages() calls with the
>    11 page_pool_alloc_pages() call.  Drivers should use
> page_pool_dev_alloc_pages()
>    12 replacing dev_alloc_pages().
> 
> General question, is this sentence applicable to all new code or only
> for XDP related paths?

Quote from the context before that sentence --

=============
Page Pool API
=============
The page_pool allocator is optimized for the XDP mode that uses one frame
per-page, but it can fallback on the regular page allocator APIs.
Basic use involves replacing alloc_pages() calls with the
page_pool_alloc_pages() call.  Drivers should use page_pool_dev_alloc_pages()
replacing dev_alloc_pages().

--unquote

So the page pool is optimized for the XDP, and that sentence is applicable to drivers
that have set up page pool for XDP optimization.
static inline struct page *page_pool_dev_alloc_pages(struct page_pool *pool)  //need a pool been set up

Back to our mana driver, we don't have page pool setup yet. (will consider in the future)
So we cannot call page_pool_dev_alloc_pages(pool) in this place yet.

Thanks,
- Haiyang