[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<PAXPR04MB91851EC6E79D76E8220C5251893CA@PAXPR04MB9185.eurprd04.prod.outlook.com>
Date: Sat, 23 Aug 2025 21:18:57 +0000
From: Shenwei Wang <shenwei.wang@....com>
To: Andrew Lunn <andrew@...n.ch>
CC: Wei Fang <wei.fang@....com>, Andrew Lunn <andrew+netdev@...n.ch>, "David
S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub
Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Alexei
Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, Jesper
Dangaard Brouer <hawk@...nel.org>, John Fastabend <john.fastabend@...il.com>,
Clark Wang <xiaoning.wang@....com>, Stanislav Fomichev <sdf@...ichev.me>,
"imx@...ts.linux.dev" <imx@...ts.linux.dev>, "netdev@...r.kernel.org"
<netdev@...r.kernel.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, dl-linux-imx <linux-imx@....com>
Subject: Re: [PATCH v3 net-next 3/5] net: fec: add rx_frame_size to support
configurable RX length
> -----Original Message-----
> From: Andrew Lunn <andrew@...n.ch>
> Sent: Saturday, August 23, 2025 3:55 PM
> To: Shenwei Wang <shenwei.wang@....com>
> Cc: Wei Fang <wei.fang@....com>; Andrew Lunn <andrew+netdev@...n.ch>;
> David S. Miller <davem@...emloft.net>; Eric Dumazet
> <edumazet@...gle.com>; Jakub Kicinski <kuba@...nel.org>; Paolo Abeni
> <pabeni@...hat.com>; Alexei Starovoitov <ast@...nel.org>; Daniel Borkmann
> <daniel@...earbox.net>; Jesper Dangaard Brouer <hawk@...nel.org>; John
> Fastabend <john.fastabend@...il.com>; Clark Wang
> <xiaoning.wang@....com>; Stanislav Fomichev <sdf@...ichev.me>;
> imx@...ts.linux.dev; netdev@...r.kernel.org; linux-kernel@...r.kernel.org; dl-
> linux-imx <linux-imx@....com>
> Subject: [EXT] Re: [PATCH v3 net-next 3/5] net: fec: add rx_frame_size to
> support configurable RX length
> > >
> > > Please could you extend that a little. What happens if the received
> > > frame is bigger than the buffer? Does the hardware fragment it over two
> buffers?
> > >
> >
> > The hardware doesn't have the capability to fragment received frames
> > that exceed the MAX_FL value. Instead, it flags an overrun error in the status
> register when such frames are encountered.
>
> And how is this useful for jumbo? Why would i want the RX frame size bigger than
> the RX buffer size?
>
I would say this is purely a software implementation, as the driver simply sets MAX_FL
to a fixed value, PKT_MAXBUF_SIZE. The patch does not alter that logic. I agree the
comments need to be rephrased.
> >
> > MAX_FL defines the maximum allowable frame length, while TRUNC_FL
> > specifies the threshold beyond which frames are truncated.
> >
> > Here, TRUNC_FL is configured based on the RX buffer size, allowing the
> > hardware to handle oversized frame errors automatically without requiring
> software intervention.
>
> Please could you expand the commit message.
>
> I still don't quite get it. Why not set MAX_FL = TRUNC_FL = RX buffer size?
>
That's the logic in v2. We added a logic to change MAX_FL.
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1148,8 +1148,8 @@ fec_restart(struct net_device *ndev)
u32 rcntl = FEC_RCR_MII;
u32 ecntl = FEC_ECR_ETHEREN;
- if (fep->max_buf_size == OPT_FRAME_SIZE)
- rcntl |= (fep->max_buf_size << 16);
+ if (OPT_FRAME_SIZE != 0)
+ rcntl |= (fep->rx_frame_size << 16);
After further consideration, I think we can simply keep MAX_FL set to max_buf_size and
only update TRUNC_FL as needed. This approach is also sufficient, so the logic introduced
in patch v2 has been removed. Let me know if you want to add back the above logic.
Thanks,
Shenwei
> Andrew
Powered by blists - more mailing lists