On 17/06/2024 15:29, Andrew Lunn wrote: > On Mon, Jun 17, 2024 at 03:03:21PM +0100, Paul Barker wrote: >> On 16/06/2024 02:23, Andrew Lunn wrote: >>> On Sat, Jun 15, 2024 at 11:30:38AM +0100, Paul Barker wrote: >>>> The RX frame size limit should not be based on the current MTU setting. >>>> Instead it should be based on the hardware capabilities. >>> >>> This is a bit odd. MTU is Maximum Transmission Unit, so clearly is >>> about Tx. MRU does not really exist. Does TCP allow for asymmetric >>> MTU/MRU? Does MTU discovery work correctly for this? >>> >>> In general, it seems like drivers implement min(MTU, MRU) and nothing >>> more. Do you have a real use case for this asymmetry? >>> >>> Andrew >> >> Hi Andrew, >> >> This change is based on my understanding of MTU/MRU, on the specs of the >> RZ SoCs I'm working with (primarily RZ/G2L family, RZ/G3S and RZ/G2H) >> and on some testing. My goal here is just to make the capabilities of >> the hardware available to users. >> >> For the RZ/G2L family and RZ/G3S, we can only support an MTU of up to >> 1500 bytes, but we can receive frames of up to (IIRC) 8192 bytes. I have >> tested sending jumbo frames to an RZ/G2L device using both iperf3 and >> ping and I see no errors. >> >> * For iperf3 RX testing, the RZ/G2L is only responding with acks. These >> are small regardless of the size of the received packets, so the >> mis-match in MTU between the two hosts causes no issue. >> >> * For ping testing, the RZ/G2L will give a fragmented response to the >> ping packet which the other host can reassemble. >> >> For the RZ/G2H, we support sending frames of up to 2047 bytes but we can >> receive frames of up to 4092 bytes. The driver will need a few more >> changes to handle reception of packets >2kB in size, but this is >> something we can do in the near future. >> >> Is there any reason why we shouldn't support this? I am by no means an >> expert in the Linux networking internals so there may be things I'm >> missing. > > I've no really experience what the Linux stack will do. I have seen a > number of devices which do not limit received packets to the MTU, > i.e. they are happy to receive bigger packets. And i don't think this > has caused an issue. But is it ever actually used? Do users setup > asymmetric jumbo systems? I've no idea. > > One thing i suggest you test is you put this in the middle of two > systems which do support jumbo. > > 4K 1.5K 4K > A <-----> B <-----> C <------> D. > > Make your device B and C, setting the MTU as supported. But set A and > D with a jumbo MTU which your systems should be able to receive. Do IP > routing along the chain. And then do some iperf transfers. I would > test both IPv4 and IPv6, since MTU path discovery in IPv6 is used a > lot, and gateways are not supposed to fragment. > > I'm assuming here your device does actually have two interfaces? If > it is only ever an end system, that simplifies it a lot, and these > tests are not needed. > > Andrew Apologies, my response here is abysmally late due to illness, other priorities and then the loss of my main dev box. 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. Thanks, -- Paul Barker
