netdev - Jumbo frames on Broadcom Genet network hardware

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-next>] [day] [month] [year] [list]

Message-ID: <CAPY8ntBEsfUhE7wHR7dOXh0=LiZkM0uBR9KxsmUspH2CAobtUg@mail.gmail.com>
Date: Fri, 14 Jul 2023 18:02:29 +0100
From: Dave Stevenson <dave.stevenson@...pberrypi.com>
To: Doug Berger <opendmb@...il.com>, Florian Fainelli <florian.fainelli@...adcom.com>
Cc: netdev@...r.kernel.org
Subject: Jumbo frames on Broadcom Genet network hardware

Hi Doug, Florian, and everyone else.

At Raspberry Pi we've had a few queries about enabling jumbo frames on
Pi4 (BCM2711), which uses the Genet network IP (V5).

I've had a look through and can increase the buffer sizes
appropriately, but it seems that we get the notification of the packet
whenever the threshold defined in GENET_0_RBUF_PKT_RDY_THLD is hit.
The status block appears to be written at this point, so we end up
dropping the packet because the driver believes it is fragmented (SOP
but not EOP set [1]), and presumably any checksum offload is from that
point in the frame too.
Setting RBUF_PKT_RDY_THLD to 0xF0 (units of 16bytes) allows for 3840
byte buffers plus the 64byte status block, and that all seems to work.
(My hacking is available at [2])

Is this the right way to support jumbo frames on genet, or is there a
better approach? It appears that you can configure the buffers to be
up to 16kB, but I don't see how that is useful if you can't get beyond
3840 bytes sensibly before status blocks are written and the host CPU
notified.

Others have reported that before the status blocks were always enabled
[3] then larger buffer sizes worked without changing the value in
PKT_RDY_THLD. I haven't managed to reproduce that. They were also
hacking global defines to allow selection of larger MTUs, so I
wouldn't like to say if they broke anything else in the process, and
it was also quite a long time ago (pre 5.6).

Many thanks in advance.
  Dave

[1] https://elixir.bootlin.com/linux/latest/source/drivers/net/ethernet/broadcom/genet/bcmgenet.c#L2324
[2] https://github.com/6by9/linux/tree/rpi-6.4.y-genet/drivers/net/ethernet/broadcom/genet
[3] https://github.com/torvalds/linux/commit/9a9ba2a4aaaa4e75a5f118b8ab642a55c34f95cb