[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4e1034fb-daf6-4bdb-80d2-62536394fc2d@bp.renesas.com>
Date: Thu, 15 Aug 2024 10:10:21 +0100
From: Paul Barker <paul.barker.ct@...renesas.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Sergey Shtylyov <s.shtylyov@....ru>, "David S. Miller"
<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Niklas Söderlund <niklas.soderlund+renesas@...natech.se>,
Biju Das <biju.das.jz@...renesas.com>,
Claudiu Beznea <claudiu.beznea.uj@...renesas.com>,
Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>,
Mitsuhiro Kimura <mitsuhiro.kimura.kc@...esas.com>, netdev@...r.kernel.org,
linux-renesas-soc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [net-next PATCH 2/2] net: ravb: Fix R-Car RX frame size limit
On 13/08/2024 15:06, Andrew Lunn wrote:
>> Apologies, my response here is abysmally late due to illness, other
>> priorities and then the loss of my main dev box.
>
> Not a problem, life happens.
>
>> As you've said, a number of devices do not limit received packet size to
>> the MTU. There are many applications, other than a gateway, where using
>> jumbo packets in even just one direction would be beneficial. For
>> example if an application needs to receive large amounts of data but
>> only needs to send back control and acknowledgement messages. I think we
>> should support this where possible. This is the thought behind the first
>> patch in this series as the GbEth IP present in the RZ/G2L and other
>> Renesas SoCs has a very asymmetric capability (it can receive 8000 byte
>> frames but only transmit 1522 byte frames).
>>
>> If we explicitly do not wish to support this, that restriction should be
>> documented and then (maybe over time) handled uniformly for all network
>> drivers.
>>
>> I'm planning to submit v2 of this series shortly.
>
> Does the hardware support scatter/gather? How does supporting jumbo
> receive affect memory usage? Can you give the hardware a number of 2K
> buffers, and it will use one for a typical packet, and 4 for a jumbo
> frame?
This is exactly what happens. After recent changes [1], we use 2kB RX
buffers and an 8kB maximum RX frame size for the GbEth IP. The hardware
will split the received frame over one or more buffers as needed. As we
would allocate a ring of 2kB buffers in any case, supporting jumbo
packets doesn't cause any increase in memory usage or in CPU time spent
in memory management.
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=966726324b7b14009216fda33b47e0bc003944c6
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)
Powered by blists - more mailing lists