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] [day] [month] [year] [list]

Message-Id: <20250107030016.24407-1-johndale@cisco.com>
Date: Mon,  6 Jan 2025 19:00:16 -0800
From: John Daley <johndale@...co.com>
To: kuba@...nel.org
Cc: andrew+netdev@...n.ch,
	benve@...co.com,
	davem@...emloft.net,
	edumazet@...gle.com,
	johndale@...co.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

>> >> 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.

Ok, testing going good so far, but need another day.
>
>> >  
>> >> +    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.

Ok, I submitted patches 5 and 6 as separate trivial patchset. Hopefully it will be
merged by the time my testing for the page_pool changes are complete so I can submit
on top of them. thanks!