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

Date: Fri, 15 Dec 2023 11:23:15 +0000
From: Dave Stevenson <dave.stevenson@...pberrypi.com>
To: Florian Fainelli <florian.fainelli@...adcom.com>
Cc: Doug Berger <opendmb@...il.com>, netdev@...r.kernel.org
Subject: Re: Jumbo frames on Broadcom Genet network hardware

Hi Florian

On Wed, 2 Aug 2023 at 00:27, Florian Fainelli
<florian.fainelli@...adcom.com> wrote:
>
> 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.

A gentle ping - did you find anything?

Raspberry Pi and Broadcom obviously have a business relationship and
NDAs, so if documentation can be passed across for us to try and add
jumbo frame support, then that would reduce your work burden. I
appreciate that it has to go through the right channels though.

Thanks
  Dave

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