netdev - Re: 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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8b4b8f65-b536-2036-f946-bae55a34bce4@broadcom.com>
Date: Tue, 1 Aug 2023 16:27:26 -0700
From: Florian Fainelli <florian.fainelli@...adcom.com>
To: Dave Stevenson <dave.stevenson@...pberrypi.com>,
 Doug Berger <opendmb@...il.com>
Cc: netdev@...r.kernel.org
Subject: Re: Jumbo frames on Broadcom Genet network hardware

Hi Dave,

On 7/14/23 10:02, Dave Stevenson wrote:
> 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).

We have had quite a few inquiries through direct emails so there does 
appear to be interest in supporting Jumbo frames indeed.

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

About 10 years ago is the last time I tried to implement Jumbo frames 
with GENET and at the time I only raised the Unimac maximum frame length 
register and would get an Ethernet frame that is fragmented with a 
SOF=1,EOF=0 initial buffer, multiple SOF=0,EOF=0 buffers, and a final 
SOF=0,EOF=1 buffer. This was the best I could achieve at the time.

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

Yes, I have seen those hacks, and they do not look too good. Let me dig 
up the little hardware documentation I have left and see whether we can 
come up with proper 9000 bytes Ethernet frames without too much hacking 
around.

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

-- 
Florian


Download attachment "smime.p7s" of type "application/pkcs7-signature" (4221 bytes)