From: Andrew Lunn <andrew@lunn•ch>
To: Edward Cree <ecree.xilinx@gmail•com>
Cc: Jakub Kicinski <kuba@kernel•org>,
davem@davemloft•net, netdev@vger•kernel.org,
michael.chan@broadcom•com, damian.dybek@intel•com,
paul.greenwalt@intel•com, rajur@chelsio•com,
jaroslawx.gawin@intel•com, vkochan@marvell•com, alobakin@pm•me,
snelson@pensando•io, shayagr@amazon•com, ayal@nvidia•com,
shenjian15@huawei•com, saeedm@nvidia•com, mkubecek@suse•cz,
roopa@nvidia•com
Subject: Re: [PATCH net-next 6/6] ethtool: clarify the ethtool FEC interface
Date: Mon, 29 Mar 2021 14:32:42 +0200 [thread overview]
Message-ID: <YGHI6ucPwFZDQE06@lunn.ch> (raw)
In-Reply-To: <435d5a68-95bf-81b6-2d29-75d2888e62cd@gmail.com>
On Mon, Mar 29, 2021 at 12:56:30PM +0100, Edward Cree wrote:
> On 25/03/2021 01:12, Jakub Kicinski wrote:
> > Drivers should reject mixing %ETHTOOL_FEC_AUTO_BIT with other
> > + * FEC modes, because it's unclear whether in this case other modes constrain
> > + * AUTO or are independent choices.
>
> Does this mean you want me to spin a patch to sfc to reject this?
> Currently for us e.g. AUTO|RS means use RS if the cable and link partner
> both support it, otherwise let firmware choose (presumably between BASER
> and OFF) based on cable/module & link partner caps and/or parallel detect.
> We took this approach because our requirements writers believed that
> customers would have a need for this setting; they called it "prefer FEC",
> and I think the idea was to use FEC if possible (even on cables where the
> IEEE-recommended default is no FEC, such as CA-25G-N 3m DAC) but allow
> fallback to no FEC if e.g. link partner doesn't advertise FEC in AN.
> Similarly, AUTO|BASER ("prefer BASE-R FEC") might be desired by a user who
> wants to use BASE-R if possible to minimise latency, but fall back to RS
> FEC if the cable or link partner insists on it (eg CA-25G-L 5m DAC).
> Whether we were right and all this is actually useful, I couldn't say.
Jacub was talking about adding a netlink API as the next step. You
should feed this in as a requirement for that. Being able to express
preferences in the API in an explicitly documented way.
It there any other existing ethtool setting which could be used as a
model? EEE, master/slave? I would class pause as an anti model, that
is frequently done wrong :-(
Andrew
next prev parent reply other threads:[~2021-03-29 12:33 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-25 1:11 [PATCH net-next 0/6] ethtool: clarify the ethtool FEC interface Jakub Kicinski
2021-03-25 1:11 ` [PATCH net-next 1/6] ethtool: fec: fix typo in kdoc Jakub Kicinski
2021-03-25 12:06 ` Andrew Lunn
2021-03-25 1:11 ` [PATCH net-next 2/6] ethtool: fec: remove long structure description Jakub Kicinski
2021-03-25 12:07 ` Andrew Lunn
2021-03-25 1:11 ` [PATCH net-next 3/6] ethtool: fec: sanitize ethtool_fecparam->reserved Jakub Kicinski
2021-03-25 12:22 ` Andrew Lunn
2021-03-25 16:02 ` Jakub Kicinski
2021-03-25 1:11 ` [PATCH net-next 4/6] ethtool: fec: sanitize ethtool_fecparam->active_fec Jakub Kicinski
2021-03-25 12:25 ` Andrew Lunn
2021-03-25 1:11 ` [PATCH net-next 5/6] ethtool: fec: sanitize ethtool_fecparam->fec Jakub Kicinski
2021-03-25 12:00 ` Dan Carpenter
2021-03-25 16:03 ` Jakub Kicinski
2021-03-25 1:12 ` [PATCH net-next 6/6] ethtool: clarify the ethtool FEC interface Jakub Kicinski
2021-03-29 11:56 ` Edward Cree
2021-03-29 12:32 ` Andrew Lunn [this message]
2021-03-29 17:39 ` Jakub Kicinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YGHI6ucPwFZDQE06@lunn.ch \
--to=andrew@lunn$(echo .)ch \
--cc=alobakin@pm$(echo .)me \
--cc=ayal@nvidia$(echo .)com \
--cc=damian.dybek@intel$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=ecree.xilinx@gmail$(echo .)com \
--cc=jaroslawx.gawin@intel$(echo .)com \
--cc=kuba@kernel$(echo .)org \
--cc=michael.chan@broadcom$(echo .)com \
--cc=mkubecek@suse$(echo .)cz \
--cc=netdev@vger$(echo .)kernel.org \
--cc=paul.greenwalt@intel$(echo .)com \
--cc=rajur@chelsio$(echo .)com \
--cc=roopa@nvidia$(echo .)com \
--cc=saeedm@nvidia$(echo .)com \
--cc=shayagr@amazon$(echo .)com \
--cc=shenjian15@huawei$(echo .)com \
--cc=snelson@pensando$(echo .)io \
--cc=vkochan@marvell$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox