DPDK patches and discussions
 help / color / mirror / Atom feed
From: Jeff Daly <jeffd@silicom-usa.com>
To: "Zhang, Qi Z" <qi.z.zhang@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: Stephen Douthit <stephend@silicom-usa.com>,
	"Yang, Qiming" <qiming.yang@intel.com>,
	"Wu, Wenjun1" <wenjun1.wu@intel.com>
Subject: RE: [PATCH v2] net/ixgbe: Treat 1G Cu SFPs as 1G SX on the X550 devices
Date: Mon, 30 May 2022 13:32:40 +0000	[thread overview]
Message-ID: <VI1PR0402MB35178C081A6CA4105A545059EADD9@VI1PR0402MB3517.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <DM4PR11MB599444B8F52D475AAC058BFED7DA9@DM4PR11MB5994.namprd11.prod.outlook.com>



> -----Original Message-----
> From: Zhang, Qi Z <qi.z.zhang@intel.com>
> Sent: Sunday, May 29, 2022 6:49 PM
> To: Jeff Daly <jeffd@silicom-usa.com>; dev@dpdk.org
> Cc: Stephen Douthit <stephend@silicom-usa.com>; Yang, Qiming
> <qiming.yang@intel.com>; Wu, Wenjun1 <wenjun1.wu@intel.com>
> Subject: RE: [PATCH v2] net/ixgbe: Treat 1G Cu SFPs as 1G SX on the X550
> devices
> 
> Caution: This is an external email. Please take care when clicking links or
> opening attachments.
> 
> 
> > -----Original Message-----
> > From: Jeff Daly <jeffd@silicom-usa.com>
> > Sent: Friday, May 27, 2022 4:44 AM
> > To: dev@dpdk.org
> > Cc: Stephen Douthit <stephend@silicom-usa.com>; Yang, Qiming
> > <qiming.yang@intel.com>; Wu, Wenjun1 <wenjun1.wu@intel.com>
> > Subject: [PATCH v2] net/ixgbe: Treat 1G Cu SFPs as 1G SX on the X550
> > devices
> >
> > 1G Cu SFPs are not officially supported on the X552/X553 family of
> > devices but create an option cu_sfp_as_sx to treat them as 1G SX
> > modules since they usually work.  Print a warning though since support
> > isn't validated, similar to what already happens for other
> > unofficially supported SFPs enabled via the allow_unsupported_sfps
> parameter inherited from the mainline Linux driver.
> >
> > Signed-off-by: Jeff Daly <jeffd@silicom-usa.com>
> > Suggested-by: Stephen Douthit <stephend@silicom-usa.com>
> > ---
> > v2:
> > * Introduced cu_sfp_as_sx option, default off.
> > ---
> >  doc/guides/nics/ixgbe.rst           | 16 ++++++++++++++
> >  drivers/net/ixgbe/base/ixgbe_type.h |  1 +
> > drivers/net/ixgbe/base/ixgbe_x550.c | 12 ++++++++++-
> >  drivers/net/ixgbe/ixgbe_ethdev.c    | 33
> +++++++++++++++++++++++++++++
> >  drivers/net/ixgbe/ixgbe_ethdev.h    |  3 +++
> >  5 files changed, 64 insertions(+), 1 deletion(-)
> >
> > diff --git a/doc/guides/nics/ixgbe.rst b/doc/guides/nics/ixgbe.rst
> > index
> > 82fa453fa28e..5db63083eef8 100644
> > --- a/doc/guides/nics/ixgbe.rst
> > +++ b/doc/guides/nics/ixgbe.rst
> > @@ -101,6 +101,22 @@ To guarantee the constraint, capabilities in
> > dev_conf.rxmode.offloads will be ch
> >
> >  fdir_conf->mode will also be checked.
> >
> > +Runtime Options
> > +^^^^^^^^^^^^^^^^^^
> > +
> > +The following ``devargs`` options can be enabled at runtime. They
> > +must be passed as part of EAL arguments. For example,
> > +
> > +.. code-block:: console
> > +
> > +   dpdk-testpmd -a af:10.0,cu_sfp_as_sx=1 -- -i
> > +
> > +- ``cu_sfp_as_sx`` (default **0**)
> 
> Can we make this devargs more generic e.g.: "allow_unsupported_phy"
> So we don't need to add a devarg for similar requirement case by case in
> future, of cause we still need to well explain all the unsupported cases in the
> document.
> 
> 

this patch is specifically to change the driver's recognition of Cu transceivers
and treat them as optical transceivers.  so should we consider this an 
unsupported phy and use that same switch 'allow_unsupported_phy' or are
you looking for a more generic name than 'cu_sfp_as_sx'?  if you are looking
for a more generic name vs just reusing allow_unsupported_phy, then please
pick something and I'll submit a new patch, but I don't want to guess what
would be ok by submitting patches.



  reply	other threads:[~2022-05-30 13:32 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-07 22:34 [PATCH] " jeffd
2022-04-13 14:21 ` Thomas Monjalon
2022-05-20  0:14   ` Zhang, Qi Z
2022-05-20 18:02     ` Jeff Daly
2022-05-23  5:36       ` Zhang, Qi Z
2022-05-23 14:13         ` Jeff Daly
2022-05-23 23:22           ` Zhang, Qi Z
2022-05-25 15:23             ` Jeff Daly
2022-05-26  0:28               ` Zhang, Qi Z
2022-04-14  1:31 ` Wang, Haiyue
2022-04-14  9:42   ` Thomas Monjalon
2022-04-14 12:13     ` Wang, Haiyue
2022-04-14 12:18       ` Thomas Monjalon
2022-04-14 15:11         ` Jeff Daly
2022-04-14 15:43           ` Stephen Hemminger
2022-04-14 17:06             ` Thomas Monjalon
2022-04-19  9:11               ` Morten Brørup
2022-04-19 12:32                 ` Wang, Haiyue
2022-04-15  1:10           ` Wang, Haiyue
2022-05-26 20:43 ` [PATCH v2] " Jeff Daly
2022-05-29 22:49   ` Zhang, Qi Z
2022-05-30 13:32     ` Jeff Daly [this message]
2022-05-30 13:50       ` Zhang, Qi Z
2022-05-31 12:30         ` Jeff Daly
2022-05-31 13:38           ` Zhang, Qi Z

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=VI1PR0402MB35178C081A6CA4105A545059EADD9@VI1PR0402MB3517.eurprd04.prod.outlook.com \
    --to=jeffd@silicom-usa.com \
    --cc=dev@dpdk.org \
    --cc=qi.z.zhang@intel.com \
    --cc=qiming.yang@intel.com \
    --cc=stephend@silicom-usa.com \
    --cc=wenjun1.wu@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).