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]

Date:   Mon, 31 Oct 2022 15:27:07 +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: 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?
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).

> >
> > 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)