netdev - Re: [net-next,v9] net: ethernet: rtsn: Add support for Renesas Ethernet-TSN

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]

Date: Tue, 25 Jun 2024 16:51:08 +0100
From: Paul Barker <paul.barker.ct@...renesas.com>
To: Paolo Abeni <pabeni@...hat.com>,
 Niklas Söderlund <niklas.soderlund+renesas@...natech.se>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Andrew Lunn <andrew@...n.ch>,
 netdev@...r.kernel.org, linux-renesas-soc@...r.kernel.org
Subject: Re: [net-next,v9] net: ethernet: rtsn: Add support for Renesas
 Ethernet-TSN

Hi Paolo, Niklas,

On 20/06/2024 16:23, Paolo Abeni wrote:
> On Thu, 2024-06-20 at 13:50 +0200, Niklas Söderlund wrote:
>> On 2024-06-20 13:13:21 +0200, Paolo Abeni wrote:
>>>
>>> skb allocation is preferred at receive time, so that the sk_buff itself
>>> is hot in the cache. Adapting to such style would likely require a
>>> larger refactor, so feel free to avoid it.
>>
>> This is good feedback. There are advanced features in TSN that I would 
>> like to work on in the future. One of them is to improve the Rx path to 
>> support split descriptors allowing for larger MTU. That too would 
>> require invasive changes in this code. I will make a note of it and try 
>> to do both.
> 
> In the context of a largish refactor, then I suggest additional
> investigating replacing napi_gro_receive() with napi_gro_frags().
> 
> The latter should provide the best performances for GRO-ed traffic.

This prompted me to try converting ravb_rx_gbeth() in the ravb driver to
use napi_get_frags()/napi_gro_frags(). The result of that change was no
improvement in TCP RX performance and a roughly 10% loss in UDP RX
performance on the RZ/G2UL. i.e. napi_gro_frags() is worse than
napi_gro_receive() in this driver.

I guess using napi_gro_frags() removes the need to copy data if you need
to add space to the first fragment for a struct skb_shared_info. For the
GbEth IP, we reserve space for the shared info structure in every
fragment buffer anyway. For <=1500 byte packets there is no benefit to
changing this, but for larger packets perhaps we would see better
efficiency if all of each 2kB fragment buffer could be used for packet
data, with space for the shared info being allocated separately via
napi_get_frags(). Some thoughts for the future I guess.

Am I missing anything here about why napi_gro_frags() should be better?

Thanks,

-- 
Paul Barker
Download attachment "OpenPGP_0x27F4B3459F002257.asc" of type "application/pgp-keys" (3521 bytes)

Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (237 bytes)