[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241008125326.2e17dce9@kernel.org>
Date: Tue, 8 Oct 2024 12:53:26 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Michael Chan <michael.chan@...adcom.com>
Cc: Taehee Yoo <ap420073@...il.com>, Andrew Lunn <andrew@...n.ch>,
davem@...emloft.net, pabeni@...hat.com, edumazet@...gle.com,
almasrymina@...gle.com, netdev@...r.kernel.org, linux-doc@...r.kernel.org,
donald.hunter@...il.com, corbet@....net, kory.maincent@...tlin.com,
maxime.chevallier@...tlin.com, danieller@...dia.com,
hengqi@...ux.alibaba.com, ecree.xilinx@...il.com,
przemyslaw.kitszel@...el.com, hkallweit1@...il.com, ahmed.zaki@...el.com,
paul.greenwalt@...el.com, rrameshbabu@...dia.com, idosch@...dia.com,
asml.silence@...il.com, kaiyuanz@...gle.com, willemb@...gle.com,
aleksander.lobakin@...el.com, dw@...idwei.uk, sridhar.samudrala@...el.com,
bcreeley@....com
Subject: Re: [PATCH net-next v3 1/7] bnxt_en: add support for rx-copybreak
ethtool command
On Tue, 8 Oct 2024 12:38:18 -0700 Michael Chan wrote:
> > Where does the min value of 64 come from? Ethernet min frame length?
>
> The length is actually the ethernet length minus the 4-byte CRC. So
> 60 is the minimum length that the driver will see. Anything smaller
> coming from the wire will be a runt frame discarded by the chip.
Also for VF to VF traffic?
> > IIUC the copybreak threshold is purely a SW feature, after this series.
> > If someone sets the copybreak value to, say 13 it will simply never
> > engage but it's not really an invalid setting, IMHO. Similarly setting
> > it to 0 makes intuitive sense (that's how e1000e works, AFAICT).
>
> Right, setting it to 0 or 13 will have the same effect of disabling
> it. 0 makes more intuitive sense.
Agreed on 0 making sense, but not sure if rejecting intermediate values
buys us anything. As Andrew mentioned consistency is important. I only
checked two drivers (e1000e and gve) and they don't seem to check
the lower limit.
Powered by blists - more mailing lists