Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 1 Nov 2022 17:04:52 +0100
From:   'Horatiu Vultur' <horatiu.vultur@microchip.com>
To:     David Laight <David.Laight@aculab.com>
CC:     "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "davem@davemloft.net" <davem@davemloft.net>,
        "edumazet@google.com" <edumazet@google.com>,
        "kuba@kernel.org" <kuba@kernel.org>,
        "pabeni@redhat.com" <pabeni@redhat.com>,
        "UNGLinuxDriver@microchip.com" <UNGLinuxDriver@microchip.com>
Subject: Re: [PATCH net v2 0/3] net: lan966x: Fixes for when MTU is changed
Message-ID: <20221101160452.mhk6ze7hzjaz4hzo@soft-dev3-1>
References: <20221030213636.1031408-1-horatiu.vultur@microchip.com>
 <b75a7136030846f587e555763ef2750e@AcuMS.aculab.com>
 <20221031150133.2be5xr7cmuhr4gng@soft-dev3-1>
 <219ebe83a5ad4467937545ee5a0e77e4@AcuMS.aculab.com>
 <20221101075906.ets6zsti3c54idae@soft-dev3-1>
 <de73370512334c76b1500e12cfd33005@AcuMS.aculab.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <de73370512334c76b1500e12cfd33005@AcuMS.aculab.com>
Precedence: bulk

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