Thread (11 messages) 11 messages, 3 authors, 2022-11-02

RE: [PATCH net v2 0/3] net: lan966x: Fixes for when MTU is changed

From: David Laight <hidden>
Date: 2022-10-31 15:27:16
Also in: lkml

From: 'Horatiu Vultur'
Sent: 31 October 2022 15:02

The 10/31/2022 10:43, David Laight wrote:
quoted
From: Horatiu Vultur
quoted
Sent: 30 October 2022 21:37
Hi David,
quoted
quoted
There were multiple problems in different parts of the driver when
the MTU was changed.
The first problem was that the HW was missing to configure the correct
value, it was missing ETH_HLEN and ETH_FCS_LEN. The second problem was
when vlan filtering was enabled/disabled, the MRU was not adjusted
corretly. While the last issue was that the FDMA was calculated wrongly
the correct maximum MTU.
IIRC all these lengths are 1514, 1518 and maybe 1522?
And also 1526, if the frame has 2 vlan tags.
quoted
How long are the actual receive buffers?
I'd guess they have to be rounded up to a whole number of cache lines
(especially on non-coherent systems) so are probably 1536 bytes.
The receive buffers can be different sizes, it can be up to 65k.
They are currently allign to page size.
Is that necessary?
I don't know where the buffers are allocated, but even 4k seems
a bit profligate for normal ethernet mtu.
If the page size if larger it is even sillier.

If the buffer is embedded in an skb you really want the skb
to be under 4k (I don't think a 1500 byte mtu can fit in 2k).

But you might as well tell the hardware the actual buffer length
(remember to allow for the crc and any alignment header).
quoted
If driver does support 8k+ jumbo frames just set the hardware
frame length to match the receive buffer size.
In that case I should always allocate maximum frame size(65k) for all
regardless of the MTU?
That would be very wasteful. I'd set the buffer large enough for
the mtu but let the hardware fill the entire buffer.

Allocating 64k buffers for big jumbo frames doesn't seem right.
If the mtu is 64k then kmalloc() will allocate 128k.
This is going to cause 'oddities' with small packets where
the 'true_size' is massively more than the data size.

Isn't there a scheme where you can create an skb from a page
list that contains fragments of the ethernet frame?
In which case I'd have thought you'd want to fill the ring
with page size buffers and then handle the hardware writing
a long frame to multiple buffers/descriptors.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help