[PATCH v6 2/2] net/ixgbe: Fix SFP detection and linking on hotplug

[Jeff Daly]

> -----Original Message-----
> From: Morten Brørup <mb at smartsharesystems.com>
> Sent: Wednesday, April 13, 2022 3:20 AM
> To: Wang, Haiyue <haiyue.wang at intel.com>; Jeff Daly <jeffd at silicom-
> usa.com>; dev at dpdk.org
> Cc: stable at dpdk.org; Stephen Douthit <stephend at silicom-usa.com>; Yang,
> Qiming <qiming.yang at intel.com>
> Subject: RE: [PATCH v6 2/2] net/ixgbe: Fix SFP detection and linking on
> hotplug
> 
> Caution: This is an external email. Please take care when clicking links or
> opening attachments.
> 
> 
> > From: Wang, Haiyue [mailto:haiyue.wang at intel.com]
> > Sent: Wednesday, 13 April 2022 09.02
> >
> > > From: Morten Brørup <mb at smartsharesystems.com>
> > > Sent: Wednesday, April 13, 2022 14:58
> > >
> > > > From: Wang, Haiyue [mailto:haiyue.wang at intel.com]
> > > > Sent: Wednesday, 13 April 2022 04.47
> > > > To: Daly, Jeff; dev at dpdk.org
> > > > Cc: stable at dpdk.org; Stephen Douthit; Yang, Qiming
> > > >
> > > > > From: Jeff Daly <jeffd at silicom-usa.com>
> > > > > Sent: Wednesday, April 13, 2022 01:42
> > > > > To: dev at dpdk.org
> > > > > Cc: stable at dpdk.org; Stephen Douthit <stephend at silicom-usa.com>;
> > > > Wang, Haiyue <haiyue.wang at intel.com>
> > > > >
> > > > > Currently the ixgbe driver does not ID any SFP except for the
> > first
> > > > one
> > > > > plugged in. This can lead to no-link, or incorrect speed
> > conditions.
> > > > >
> > > > > For example:
> > > > >
> > > > > * If link is initially established with a 1G SFP, and later a
> > 1G/10G
> > > > > multispeed part is later installed, then the MAC link setup
> > functions
> > > > are
> > > > > never called to change from 1000BASE-X to 10GBASE-R mode, and the
> > > > link
> > > > > stays running at the slower rate.
> > > > >
> > > > > * If link is initially established with a 1G SFP, and later a 10G
> > > > only
> > > > > module is later installed, no link is established, since we are
> > still
> > > > > trasnsmitting in 1000BASE-X mode to a 10GBASE-R only partner.
> > > > >
> > > > > Refactor the SFP ID/setup, and link setup code, to more closely
> > match
> > > > the
> > > > > flow of the mainline kernel driver which does not have these
> > issues.
> > > > In
> > > > > that driver a service task runs periodically to handle these
> > > > operations
> > > > > based on bit flags that have been set (usually via interrupt or
> > > > userspace
> > > > > request), and then get cleared once the requested subtask has
> > been
> > > > > completed.
> > > > >
> > > > > Fixes: af75078fece ("first public release")
> > > > > Cc: stable at dpdk.org
> > > > >
> > > >
> > > > So BIG change for new platform, DON'T CC to stable!
> > >
> > > What do you mean by "new platform"? The ixgbe hardware and driver is
> > not new.
> > >
> >
> > It's soc NIC, ixgbe not support before.
> 
> If the patch only fixes the driver for a new NIC that not supported by older
> DPDK versions, and that NIC is not going to be supported by older DPDK
> versions, then I agree that there is no point in backporting it or CC'ing stable.
> 
> However, if the patch could also apply to any other ixgbe NIC that is
> potentially supported by older DPDK versions, then it should be backported.
> 

This patch is not *only* for soc NIC, it's for *all* IXGBE supported NIC that have SFP cages. 
The code was also validated using a dual port 82599ES 10G SFI/SFP+ PCIe NIC adapter.

> >
> > > This patch fixes a bug (with a serious impact when occurring), so it
> > should be backported. The size of
> > > the patch does not disqualify it for backporting.
> > >
> > > -Morten
> >