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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <de73370512334c76b1500e12cfd33005@AcuMS.aculab.com>
Date:   Tue, 1 Nov 2022 09:03:56 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Horatiu Vultur' <horatiu.vultur@...rochip.com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>
Subject: RE: [PATCH net v2 0/3] net: lan966x: Fixes for when MTU is changed

From: 'Horatiu Vultur'
> Sent: 01 November 2022 07:59
> 
> The 10/31/2022 15:27, David Laight wrote:
> >
> > From: 'Horatiu Vultur'
> > > Sent: 31 October 2022 15:02
> > >
> > > 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.
> >
> > Is that necessary?
> 
> HW requires to have the start of frame alligned to 128 bytes.

Not a real problem.
Even dma_alloc_coherent() guarantees alignment.

I'm not 100% sure of all the options of the Linux stack.
But for ~1500 byte mtu I'd have thought that receiving
directly into an skb would be best (1 page allocated for an skb).
For large mtu (and hardware receive coalescing) receiving
into pages is probably better - but not high order allocations.

...
> > 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).
> 
> I am already doing that here [2]
> And I need to do it for each frame it can received.

That is the length of the buffer.
Not the maximum frame length - which seems to be elsewhere.
I suspect that having the maximum frame length less than the
buffer size stops the driver having to handle long frames
that span multiple buffers.
(and very long frames that are longer than all the buffers!)

...
> > I'd set the buffer large enough for the mtu but let the hardware fill
> > the entire buffer.
> 
> I am not 100% sure I follow it. Can you expend on this a little bit?

At the moment I think the receive buffer descriptors have a length
of 4k. But you are setting another 'maximum frame length' register
to (eg) 1518 so that the hardware rejects long frames.
But you can set the 'maximum frame length' register to (just under)
4k so that longer frames are received ok but without the driver
having to worry about frames spanning multiple buffer fragments.

The network stack might choose to discard frames with an overlong mtu.
But that can be done after all the headers have been removed.

...
> But all these possible changes will need to go through net-next.

Indeed.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)