netdev - Re: [PATCH net-next v4 4/6] enic: Use the Page Pool API for RX when MTU is less than page size

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: <20250106161953.019083b3@kernel.org>
Date: Mon, 6 Jan 2025 16:19:53 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: John Daley <johndale@...co.com>
Cc: andrew+netdev@...n.ch, benve@...co.com, davem@...emloft.net,
 edumazet@...gle.com, neescoba@...co.com, netdev@...r.kernel.org,
 pabeni@...hat.com, satishkh@...co.com
Subject: Re: [PATCH net-next v4 4/6] enic: Use the Page Pool API for RX when
 MTU is less than page size

On Mon,  6 Jan 2025 13:54:25 -0800 John Daley wrote:
> >> The Page Pool API improves bandwidth and CPU overhead by recycling
> >> pages instead of allocating new buffers in the driver. Make use of
> >> page pool fragment allocation for smaller MTUs so that multiple
> >> packets can share a page.  
> >
> >Why the MTU limitation? You can set page_pool_params.order
> >to appropriate value always use the page pool.  
> 
> I thought it might waste memory, e.g. allocating 16K for 9000 mtu.
> But now that you mention it, I see that the added code complexity is
> probably not worth it. I am unclear on what to set pp_params.max_len
> to when MTU > PAGE_SIZE. Order * PAGE_SIZE or MTU size? In this case
> the pages won't be fragmented so isn't only necessary for the MTU sized
> area to be DMA SYNC'ed?

Good point, once fragmentation is no longer possible you can
set .max_len to the size of the fragment HW may clobber,
and .offset to the reserved headroom.

> >  
> >> +    page_pool_destroy(rq->pool);
> >> +}  
> 
> I will make a v5 shortly. Would you recommend I split the patchset into 2 parts
> as I think @andrew+netdev was suggesting? The last 2 patches are kind of unrelated
> to the first 4.

Yes, seems like a good idea, patches 5 and 6 would probably have been
merged a while back if they were separate.