[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAPY8ntB-_m-JZqveVXaYkpQ6xrmHcWvE-zfysvNCNTKws7qFdg@mail.gmail.com>
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
>
Powered by blists - more mailing lists