From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Ido Goshen <Ido@cgstowernetworks.com>,
"Lu, Wenzhuo" <wenzhuo.lu@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: 10GBASE-T SFP+ copper support
Date: Fri, 26 Apr 2019 12:13:19 +0000 [thread overview]
Message-ID: <2601191342CEEE43887BDE71AB9772580148A9C453@irsmsx105.ger.corp.intel.com> (raw)
Message-ID: <20190426121319.kYuBeARwzcTJPISvsevwaga0Cfw81jv_Qj4OM1ons4c@z> (raw)
In-Reply-To: <AM0PR09MB3298F333987B181697A565F1D63C0@AM0PR09MB3298.eurprd09.prod.outlook.com>
> > > From: Ido Goshen <ido@cgstowernetworks.com>
> > >
> > > 10BASE-T SFP+ copper transceivers become cheaper and popular So far
> > > those were blocked by ixgbe as “unsupported”.
> > > e.g.
> > > eth_ixgbe_dev_init(): Unsupported SFP+ Module
> > > eth_ixgbe_dev_init(): Hardware Initialization Failure: -19
> > > EAL: Requested device 0000:0a:00.0 cannot be used
> > >
> > > This patch expands the usage of allow_unsupported_sfp to be more
> > > general and makes ixgbe more tolerant to unknown SFPs
> >
> >
> > I don't think it is a good idea to change the base code to blindly allow
> > unknown SFPs.
> > Again in eth_ixgbe_dev_init() we do set
> > hw->allow_unsupported_sfp = 1;
> > so the function below will return success anyway,
>
> what's the reason to not allow unknown SFPs?
> as is they are explicitly blocked and not working anyway, why not give them a chance?
From my perspective the question should be opposite: why to allow it?
ixgbe base code is developed and maintained by Intel ND team for several platforms.
It should be some good reason to change it inside DPDK project only.
As I said, in eth_ixgbe_dev_init() we already set hw->allow_unsupported_sfp = 1,
so unknown spf should be allowed by DPDK ixgbe PMD.
So what exact problem you are trying to solve here?
Konstantin
>
> More inputs
> 1. i40e already does support it (I didn't go deep into it but it just seems less strict on hw_init)
> 2. even with ixgbe it can work, because unsupported is only checked by ixgbe_init_hw
> so if the SFP is inserted after the app has started it does work
> kind of inconsistent
>
> >
> > >
> > > Signed-off-by: Ido Goshen <ido@cgstowernetworks.com>
> > > ---
> > > drivers/net/ixgbe/base/ixgbe_phy.c | 22 +++++++++++-----------
> > > drivers/net/ixgbe/base/ixgbe_x550.c | 3 +++
> > > 2 files changed, 14 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/drivers/net/ixgbe/base/ixgbe_phy.c
> > > b/drivers/net/ixgbe/base/ixgbe_phy.c
> > > index dd118f9..ff96afc 100644
> > > --- a/drivers/net/ixgbe/base/ixgbe_phy.c
> > > +++ b/drivers/net/ixgbe/base/ixgbe_phy.c
> > > @@ -1527,18 +1527,9 @@ s32 ixgbe_identify_sfp_module_generic(struct
> > ixgbe_hw *hw)
> > > if (hw->phy.type == ixgbe_phy_sfp_intel) {
> > > status = IXGBE_SUCCESS;
> > > } else {
> > > - if (hw->allow_unsupported_sfp == true) {
> > > - EWARN(hw,
> > > - "WARNING: Intel (R)
> > Network Connections are quality tested using Intel (R) Ethernet
> > > Optics. "
> > > - "Using untested modules is
> > not supported and may cause unstable operation or damage
> > > to the module or the adapter. "
> > > - "Intel Corporation is not
> > responsible for any harm caused by using untested modules.\n");
> > > - status = IXGBE_SUCCESS;
> > > - } else {
> > > - DEBUGOUT("SFP+ module not
> > supported\n");
> > > - hw->phy.type =
> > > + hw->phy.type =
> > > ixgbe_phy_sfp_unsupported;
> > > - status =
> > IXGBE_ERR_SFP_NOT_SUPPORTED;
> > > - }
> > > + status = IXGBE_ERR_SFP_NOT_SUPPORTED;
> > > }
> > > } else {
> > > status = IXGBE_SUCCESS;
> > > @@ -1546,6 +1537,15 @@ s32 ixgbe_identify_sfp_module_generic(struct
> > ixgbe_hw *hw)
> > > }
> > >
> > > out:
> > > + if (status == IXGBE_ERR_SFP_NOT_SUPPORTED &&
> > > + hw->allow_unsupported_sfp) {
> > > + PMD_INIT_LOG(WARNING,
> > > + "WARNING: Intel (R) Network Connections
> > are quality tested using Intel (R) Ethernet Optics. "
> > > + "Using untested modules is not supported
> > and may cause unstable
> > > +operation or damage to the module or
> > > the adapter. "
> > > + "Intel Corporation is not responsible for any
> > harm caused by using untested modules.\n");
> > > + hw->phy.type = ixgbe_phy_unknown;
> > > + status = IXGBE_SUCCESS;
> > > + }
> > > return status;
> > >
> > > err_read_i2c_eeprom:
> > > diff --git a/drivers/net/ixgbe/base/ixgbe_x550.c
> > > b/drivers/net/ixgbe/base/ixgbe_x550.c
> > > index a920a14..212d9a0 100644
> > > --- a/drivers/net/ixgbe/base/ixgbe_x550.c
> > > +++ b/drivers/net/ixgbe/base/ixgbe_x550.c
> > > @@ -1539,6 +1539,9 @@ STATIC s32
> > ixgbe_supported_sfp_modules_X550em(struct ixgbe_hw *hw, bool *linear)
> > > *linear = false;
> > > break;
> > > case ixgbe_sfp_type_unknown:
> > > + if (hw->allow_unsupported_sfp)
> > > + return IXGBE_SUCCESS;
> > > + /* fall through */
> > > case ixgbe_sfp_type_1g_cu_core0:
> > > case ixgbe_sfp_type_1g_cu_core1:
> > > default:
> > > --
> > > 1.9.1
next prev parent reply other threads:[~2019-04-26 12:13 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-24 11:31 Ido Goshen
2019-04-24 11:31 ` Ido Goshen
2019-04-24 11:47 ` Ananyev, Konstantin
2019-04-24 11:47 ` Ananyev, Konstantin
2019-04-24 21:25 ` Ido Goshen
2019-04-24 21:25 ` Ido Goshen
2019-04-26 12:13 ` Ananyev, Konstantin [this message]
2019-04-26 12:13 ` Ananyev, Konstantin
2019-04-28 6:54 ` Ido Goshen
2019-04-28 6:54 ` Ido Goshen
2019-05-01 23:40 ` Ananyev, Konstantin
2019-05-01 23:40 ` Ananyev, Konstantin
2019-05-02 9:15 ` Ido Goshen
2019-05-02 9:15 ` Ido Goshen
2019-05-06 11:22 ` Igor Russkikh
2019-05-06 11:22 ` Igor Russkikh
2019-05-07 22:45 ` Stillwell Jr, Paul M
2019-05-07 22:45 ` Stillwell Jr, Paul M
2019-05-14 12:21 ` Igor Russkikh
2019-05-14 12:21 ` Igor Russkikh
2019-05-14 17:10 ` Ido Goshen
2019-05-14 17:10 ` Ido Goshen
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=2601191342CEEE43887BDE71AB9772580148A9C453@irsmsx105.ger.corp.intel.com \
--to=konstantin.ananyev@intel.com \
--cc=Ido@cgstowernetworks.com \
--cc=dev@dpdk.org \
--cc=wenzhuo.lu@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).