netdev - Re: [PATCH net-next 1/4] eth: mlx4: create a page pool for Rx

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: <ed868c30-d5e5-4496-8ea2-b40f6111f8ad@gmail.com>
Date: Tue, 11 Feb 2025 21:11:02 +0200
From: Tariq Toukan <ttoukan.linux@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: davem@...emloft.net, netdev@...r.kernel.org, edumazet@...gle.com,
 pabeni@...hat.com, andrew+netdev@...n.ch, horms@...nel.org,
 tariqt@...dia.com, hawk@...nel.org
Subject: Re: [PATCH net-next 1/4] eth: mlx4: create a page pool for Rx



On 11/02/2025 21:06, Jakub Kicinski wrote:
> On Tue, 11 Feb 2025 20:01:08 +0200 Tariq Toukan wrote:
>>> The pool_size is just the size of the cache, how many unallocated
>>> DMA mapped pages we can keep around before freeing them to system
>>> memory. It has no implications for correctness.
>>
>> Right, it doesn't hurt correctness.
>> But, we better have the cache size derived from the overall ring buffer
>> size, so that the memory consumption/footprint reflects the user
>> configuration.
>>
>> Something like:
>>
>> ring->size * (priv->frag_info[i].frag_stride for i < num_frags).
>>
>> or roughly ring->size * MLX4_EN_EFF_MTU(dev->mtu).
> 
> These calculations appear to produce byte count?

Yes.
Of course, need to align and translate to page size.

> The ring size is in *pages*. Frag is also somewhat irrelevant, given
> that we're talking about full pages here, not 2k frags. So I think
> I'll go with:
> 
> 	pp.pool_size =
> 		size * DIV_ROUND_UP(MLX4_EN_EFF_MTU(dev->mtu), PAGE_SIZE);


LGTM.