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. Thanks, -- Paul Barker
Attachment:
OpenPGP_0x27F4B3459F002257.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
