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

['Horatiu Vultur' <horatiu.vultur@microchip.com>]

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