linux-kernel - 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: <20221101160452.mhk6ze7hzjaz4hzo@soft-dev3-1>
Date:   Tue, 1 Nov 2022 17:04:52 +0100
From:   'Horatiu Vultur' <horatiu.vultur@...rochip.com>
To:     David Laight <David.Laight@...lab.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

The 11/01/2022 09:03, David Laight wrote:
> > 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.

But am I not doing this already? I allocate the page here [1] and then create
the skb here[2].

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

That is correct.

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

But this will not just put more load on CPU? In the way that I accept
long frames but then they will be discard by the CPU.
And I can do this in HW, because I know what is the maximum frame length
accepted on that interface.

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

[1] https://elixir.bootlin.com/linux/v6.1-rc3/source/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c#L17
[2] https://elixir.bootlin.com/linux/v6.1-rc3/source/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c#L417

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

-- 
/Horatiu