lkml.org 
[lkml]   [2022]   [Oct]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2022-10-31 15:57    [W:0.066 / U:1.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site