[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220601014825.GA10961@nj-rack01-04.nji.corigine.com>
Date: Wed, 1 Jun 2022 09:48:25 +0800
From: Yinjun Zhang <yinjun.zhang@...igine.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Simon Horman <simon.horman@...igine.com>,
David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
oss-drivers@...igine.com, Yu Xiao <yu.xiao@...igine.com>,
Louis Peens <louis.peens@...igine.com>
Subject: Re: [PATCH net] nfp: correct the output of `ethtool --show-fec
<intf>`
On Mon, May 30, 2022 at 09:32:32PM -0700, Jakub Kicinski wrote:
> On Mon, 30 May 2022 10:48:42 +0200 Simon Horman wrote:
> > The output of `Configured FEC encodings` should display user
> > configured/requested value,
>
> That stands to reason, but when I checked what all drivers do 7 out
> of 10 upstream drivers at the time used it to report supported modes.
It seems you're right. I agree it's OK that nfp driver keep the same with
majority drivers' implementations.
> At which point it may be better to change the text in ethtool user
> space that try to change the meaning of the field..
To adapt to both implementations, "Supported/Configured FEC encodings"
would be a compromise I think.
>
> > rather than the NIC supported modes list.
> >
> > Before this patch, the output is:
> > # ethtool --show-fec <intf>
> > FEC parameters for <intf>:
> > Configured FEC encodings: Auto Off RS BaseR
> > Active FEC encoding: None
> >
> > With this patch, the corrected output is:
> > # ethtool --show-fec <intf>
> > FEC parameters for <intf>:
> > Configured FEC encodings: Auto
> > Active FEC encoding: None
>
Powered by blists - more mailing lists