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

[Jeff Daly]

> -----Original Message-----
> From: Zhang, Qi Z <qi.z.zhang at intel.com>
> Sent: Wednesday, May 11, 2022 9:27 PM
> To: Jeff Daly <jeffd at silicom-usa.com>; dev at dpdk.org
> Cc: stable at dpdk.org; Stephen Douthit <stephend at silicom-usa.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.
> 
> 
> > -----Original Message-----
> > From: Jeff Daly <jeffd at silicom-usa.com>
> > Sent: Wednesday, April 13, 2022 1:42 AM
> > To: dev at dpdk.org
> > Cc: stable at dpdk.org; Stephen Douthit <stephend at silicom-usa.com>;
> Wang,
> > Haiyue <haiyue.wang at intel.com>
> > Subject: [PATCH v6 2/2] net/ixgbe: Fix SFP detection and linking on
> > hotplug
> >
> > 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.
> 
> Does kernel driver has the same issue for this?
> 

No, the kernel driver does the correct thing.

> >
> > 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.
> 
> If kernel driver don't have this issue, Is this the same way that kernel driver
> handle this issue?
>

The history can probably be searched back for, but yes the mechanism
implemented in this patch tries to follow the kernel's method for handling
hotplug.  The patch has been split into 3 chunks, starting with:

https://patchwork.dpdk.org/project/dpdk/patch/ffbdaf3aa487241a51bb6512bbb4701da17e69fe.1652988826.git.jeffd@silicom-usa.com/

it was refactored according to the wishes of the prior maintainer, so it's not
exactly the same as this one which is why it was submitted as a new one, 
not a revision of this.  

HTH.
 
> Btw, could you break down the patch for easy review?
> 
> Thanks
> Qi