linux-kernel - Re: [PATCH v3 net-next 3/5] net: fec: add rx_frame

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6b1f5bcd-e4d7-4309-becc-de4a12bdf363@lunn.ch>
Date: Sat, 23 Aug 2025 22:54:44 +0200
From: Andrew Lunn <andrew@...n.ch>
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" <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

> > > Add a new rx_frame_size member in the fec_enet_private structure to
> > > decouple frame size configuration from max_buf_size. This allows more
> > > precise control over RX frame length settings. It is particularly
> > > useful for Jumbo frame support because the RX frame size may possible
> > > larger than the allocated RX buffer.
> > 
> > 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?

> > >
> > > Configure TRUNC_FL (Frame Truncation Length) based on the RX buffer size.
> > > Frames exceeding this limit will be treated as error packets and dropped.
> > 
> > This bit confuses me. You want to allow rx_frame_size to be bigger than the
> > buffer size, but you also want to discard frames bigger than the buffer size?
> > 
> 
> 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?

	Andrew