[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <316e5fb7-7f45-4564-9354-e50305f6f3fd@lunn.ch>
Date: Mon, 21 Jul 2025 15:58:05 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Hariprasad Kelam <hkelam@...vell.com>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
Sunil Goutham <sgoutham@...vell.com>,
Geetha sowjanya <gakula@...vell.com>,
Subbaraya Sundeep <sbhatta@...vell.com>,
Bharat Bhushan <bbhushan2@...vell.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>,
Tomasz Duszynski <tduszynski@...vell.com>,
Simon Horman <horms@...nel.org>
Subject: Re: [net PatchV3] Octeontx2-vf: Fix max packet length errors
On Mon, Jul 21, 2025 at 02:28:15PM +0530, Hariprasad Kelam wrote:
> Implement packet length validation before submitting packets to
> the hardware to prevent MAXLEN_ERR. Increment tx_dropped counter
> on failure.
Sorry, i did not look at previous versions of this patch, so i might
be asking a question some other Reviewer already asked.
How expensive is MAXLEN_ERR? What do you need to do when it happens?
I would _guess_ that if ndev->mtu is set correctly, and any change to
it validated, you are going to get very few packets which are too big.
Is it better to introduce this test on the hot path which effects
every single packet, or just deal with MAXLEN_ERR if it ever actually
happens, so leaving the hot path optimised for the common case?
Maybe you could include something about this in the commit message?
Andrew
Powered by blists - more mailing lists