Messages in this thread | | | Date | Mon, 31 Oct 2022 16:01:33 +0100 | From | 'Horatiu Vultur' <> | Subject | Re: [PATCH net v2 0/3] net: lan966x: Fixes for when MTU is changed |
| |
The 10/31/2022 10:43, David Laight wrote: > > From: Horatiu Vultur > > Sent: 30 October 2022 21:37
Hi David,
> > > > 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.
> 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.
> > 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?
> > There is no real need to exactly police the receive MTU. > There are definitely situations where the transmit MTU has > to be limited (eg to avoid ptmu blackholes) but where some > systems still send 'full sized' packets. > > There is also the possibility of receiving PPPoE encapsulated > full sized ethernet packets. > I can remember how big that header is - something like 8 bytes. > There is no real reason to discard them if they'd fit in the buffer. > > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) >
-- /Horatiu
| |