netdev - RE: [EXT] mvpp2: incorrect max mtu?

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: <CO6PR18MB3873FB0E037EEE6104FAFD80B02C9@CO6PR18MB3873.namprd18.prod.outlook.com>
Date:   Tue, 18 May 2021 10:25:58 +0000
From:   Stefan Chulski <stefanc@...vell.com>
To:     Russell King <linux@...linux.org.uk>
CC:     Marcin Wojtas <mw@...ihalf.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [EXT] mvpp2: incorrect max mtu?

> -----Original Message-----
> From: Russell King <linux@...linux.org.uk>
> Sent: Tuesday, May 18, 2021 12:42 PM
> To: Stefan Chulski <stefanc@...vell.com>
> Cc: Marcin Wojtas <mw@...ihalf.com>; netdev@...r.kernel.org
> Subject: Re: [EXT] mvpp2: incorrect max mtu?
> 
> On Tue, May 18, 2021 at 06:09:12AM +0000, Stefan Chulski wrote:
> > Look like PPv2 tried scatter frame since it was larger than Jumbo buffer size
> and it drained buffer pool(Buffers never released).
> > Received packet should be less than value set in
> MVPP2_POOL_BUF_SIZE_REG for long pool.
> 
> So this must mean that setting dev->max_mtu is incorrect.
> 
> From what I can see, the value programmed into that register would be
> MVPP2_BM_JUMBO_PKT_SIZE which I believe is 9888. This is currently the
> same value that dev->max_mtu is set to, but max_mtu is the data payload
> size in the ethernet frame, which doesn't include the hardware ethernet
> header.
> 
> So, should max_mtu be set to 14 bytes less? Or should it be set to 9856? Less
> 14 bytes? Or what?

Yes, look like dev->max_mtuis incorrect. It should be 9856, MVPP2_POOL_BUF_SIZE_REG,  Pool Buffer Size is in 32 units.
But before changing it I prefer to test different sizes. Currently, I don't have a connected board. 
I will connect board and perform some tests. JUMBO_FRAME_SIZE is the size of the buffer, but packet offset should be taken into account.

> It is really confusing that we have these definitions that state e.g.
> that JUMBO_FRAME_SIZE is 10432 but the frame size comment says 9856.
> It's not clear why it's different like that - why the additional 576 octets.
> 
> All of this could do with some explanation in the driver - would it be possible
> to add some kind of documentation, or at least make the definitions around
> packet and frame size more understandable please?
> 
> Thanks.

Yes, definition or comments should be improved. 

Regards,
Stefan.