diff mbox series

[v2,3/7] net/ixgbe: Check that SFF-8472 soft rate select is supported before write

Message ID 20211206221922.644187-4-stephend@silicom-usa.com (mailing list archive)
State Superseded, archived
Delegated to: Qi Zhang
Headers
Series ixgbe SFP handling fixes |

Checks

Context Check Description
ci/checkpatch success coding style OK

Commit Message

Stephen Douthit Dec. 6, 2021, 10:19 p.m. UTC 
  Make sure an SFP is really a SFF-8472 device that supports the optional
soft rate select feature before just blindly poking those I2C registers.

Skip all I2C traffic if we know there's no SFP.

Fixes: f3430431aba ("ixgbe/base: add SFP+ dual-speed support")
Cc: stable@dpdk.org

Signed-off-by: Stephen Douthit <stephend@silicom-usa.com>
---
 drivers/net/ixgbe/base/ixgbe_common.c | 46 +++++++++++++++++++++++++++
 drivers/net/ixgbe/base/ixgbe_phy.h    |  3 ++
 2 files changed, 49 insertions(+)

Comments

Wang, Haiyue Dec. 20, 2021, 7:53 a.m. UTC | #1 
> -----Original Message-----
> From: Stephen Douthit <stephend@silicom-usa.com>
> Sent: Tuesday, December 7, 2021 06:19
> To: Wang, Haiyue <haiyue.wang@intel.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>; Changchun Ouyang
> <changchun.ouyang@intel.com>; Zhang, Helin <helin.zhang@intel.com>
> Cc: dev@dpdk.org; Wen Wang <wenw@silicom-usa.com>; Stephen Douthit <stephend@silicom-usa.com>;
> stable@dpdk.org
> Subject: [PATCH v2 3/7] net/ixgbe: Check that SFF-8472 soft rate select is supported before write
> 
> Make sure an SFP is really a SFF-8472 device that supports the optional
> soft rate select feature before just blindly poking those I2C registers.
> 
> Skip all I2C traffic if we know there's no SFP.
> 
> Fixes: f3430431aba ("ixgbe/base: add SFP+ dual-speed support")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Stephen Douthit <stephend@silicom-usa.com>
> ---


>  	/* Set RS0 */
>  	status = hw->phy.ops.read_i2c_byte(hw, IXGBE_SFF_SFF_8472_OSCB,
>  					   IXGBE_I2C_EEPROM_DEV_ADDR2,
> diff --git a/drivers/net/ixgbe/base/ixgbe_phy.h b/drivers/net/ixgbe/base/ixgbe_phy.h
> index ceefbb3e68..cd57ce040f 100644
> --- a/drivers/net/ixgbe/base/ixgbe_phy.h
> +++ b/drivers/net/ixgbe/base/ixgbe_phy.h
> @@ -21,6 +21,7 @@
>  #define IXGBE_SFF_CABLE_TECHNOLOGY	0x8
>  #define IXGBE_SFF_CABLE_SPEC_COMP	0x3C
>  #define IXGBE_SFF_SFF_8472_SWAP		0x5C
> +#define IXGBE_SFF_SFF_8472_EOPT		0x5D

Looks like this is YOUR platform specific, then this patchset can't be
merged. : - (

>  #define IXGBE_SFF_SFF_8472_COMP		0x5E
>  #define IXGBE_SFF_SFF_8472_OSCB		0x6E
>  #define IXGBE_SFF_SFF_8472_ESCB		0x76
> @@ -48,6 +49,8 @@
>  #define IXGBE_SFF_SOFT_RS_SELECT_10G	0x8
> --
> 2.31.1
Stephen Douthit Dec. 20, 2021, 9:32 p.m. UTC | #2 
On 12/20/21 02:53, Wang, Haiyue wrote:
>> -----Original Message-----
>> From: Stephen Douthit <stephend@silicom-usa.com>
>> Sent: Tuesday, December 7, 2021 06:19
>> To: Wang, Haiyue <haiyue.wang@intel.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>; Changchun Ouyang
>> <changchun.ouyang@intel.com>; Zhang, Helin <helin.zhang@intel.com>
>> Cc: dev@dpdk.org; Wen Wang <wenw@silicom-usa.com>; Stephen Douthit <stephend@silicom-usa.com>;
>> stable@dpdk.org
>> Subject: [PATCH v2 3/7] net/ixgbe: Check that SFF-8472 soft rate select is supported before write
>>
>> Make sure an SFP is really a SFF-8472 device that supports the optional
>> soft rate select feature before just blindly poking those I2C registers.
>>
>> Skip all I2C traffic if we know there's no SFP.
>>
>> Fixes: f3430431aba ("ixgbe/base: add SFP+ dual-speed support")
>> Cc: stable@dpdk.org
>>
>> Signed-off-by: Stephen Douthit <stephend@silicom-usa.com>
>> ---
> 
> 
>>        /* Set RS0 */
>>        status = hw->phy.ops.read_i2c_byte(hw, IXGBE_SFF_SFF_8472_OSCB,
>>                                           IXGBE_I2C_EEPROM_DEV_ADDR2,
>> diff --git a/drivers/net/ixgbe/base/ixgbe_phy.h b/drivers/net/ixgbe/base/ixgbe_phy.h
>> index ceefbb3e68..cd57ce040f 100644
>> --- a/drivers/net/ixgbe/base/ixgbe_phy.h
>> +++ b/drivers/net/ixgbe/base/ixgbe_phy.h
>> @@ -21,6 +21,7 @@
>>   #define IXGBE_SFF_CABLE_TECHNOLOGY   0x8
>>   #define IXGBE_SFF_CABLE_SPEC_COMP    0x3C
>>   #define IXGBE_SFF_SFF_8472_SWAP              0x5C
>> +#define IXGBE_SFF_SFF_8472_EOPT              0x5D
> 
> Looks like this is YOUR platform specific, then this patchset can't be
> merged. : - (

This isn't anything unique to our hardware, these values are coming from
the SFF-8472 SFP+ I2C specification.

The ability to do a soft rate select via I2C is an optional feature, and
modules that support it are supposed to set bit 3 in byte 93 (0x5d), the
"Enhanced Options" register, to advertise the functionality.

Please see section 8.10 and Table 8-6 in the SFF-8472 spec.

Checking the RATE_SELECT bit flag may be overkill since the transceiver
is supposed to ignore writes to rate select control bits if the feature
isn't implemented.  I can drop that check if you like, but the other
checks for a 8472 device (vs 8079) aren't anything different than what
already happens in the driver elsewhere[1].  I'd argue that testing that
a feature is supported in hardware before trying to use it is normal
driver behavior.

If instead you mean that the entire series is somehow applicable only to
our hardware, I'm not sure why.

That hotplug issue isn't seen on the same hardware when using the Linux
driver; so it's a dpdk problem (at least on C3000 ixgbe devs), and not a
hardware problem.  Fixing the hotplug/rateswap issue was my primary
goal, the other patches fix problems I found along the way while
debugging.

I can also reproduce the hotplug/rateswap issue on the PLCC-B, an Intel
reference design for the C3000 family, so again, not unique to this
platform.

Please let me know if that addresses your concerns, or if I've missed
your point.

Thanks,
Steve

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c?h=v5.16-rc6

>>   #define IXGBE_SFF_SFF_8472_COMP              0x5E
>>   #define IXGBE_SFF_SFF_8472_OSCB              0x6E
>>   #define IXGBE_SFF_SFF_8472_ESCB              0x76
>> @@ -48,6 +49,8 @@
>>   #define IXGBE_SFF_SOFT_RS_SELECT_10G 0x8
>> --
>> 2.31.1
>
Wang, Haiyue Dec. 21, 2021, 1:15 a.m. UTC | #3 
> -----Original Message-----
> From: Stephen Douthit <stephend@silicom-usa.com>
> Sent: Tuesday, December 21, 2021 05:33
> To: Wang, Haiyue <haiyue.wang@intel.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>; Changchun Ouyang
> <changchun.ouyang@intel.com>; Zhang, Helin <helin.zhang@intel.com>
> Cc: dev@dpdk.org; Wang, Wen <wenw@silicom-usa.com>; stable@dpdk.org
> Subject: Re: [PATCH v2 3/7] net/ixgbe: Check that SFF-8472 soft rate select is supported before write
> 
> On 12/20/21 02:53, Wang, Haiyue wrote:
> >> -----Original Message-----
> >> From: Stephen Douthit <stephend@silicom-usa.com>
> >> Sent: Tuesday, December 7, 2021 06:19
> >> To: Wang, Haiyue <haiyue.wang@intel.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>; Changchun Ouyang
> >> <changchun.ouyang@intel.com>; Zhang, Helin <helin.zhang@intel.com>
> >> Cc: dev@dpdk.org; Wen Wang <wenw@silicom-usa.com>; Stephen Douthit <stephend@silicom-usa.com>;
> >> stable@dpdk.org
> >> Subject: [PATCH v2 3/7] net/ixgbe: Check that SFF-8472 soft rate select is supported before write
> >>
> >> Make sure an SFP is really a SFF-8472 device that supports the optional
> >> soft rate select feature before just blindly poking those I2C registers.
> >>
> >> Skip all I2C traffic if we know there's no SFP.
> >>
> >> Fixes: f3430431aba ("ixgbe/base: add SFP+ dual-speed support")
> >> Cc: stable@dpdk.org
> >>
> >> Signed-off-by: Stephen Douthit <stephend@silicom-usa.com>
> >> ---
> >
> >
> >>        /* Set RS0 */
> >>        status = hw->phy.ops.read_i2c_byte(hw, IXGBE_SFF_SFF_8472_OSCB,
> >>                                           IXGBE_I2C_EEPROM_DEV_ADDR2,
> >> diff --git a/drivers/net/ixgbe/base/ixgbe_phy.h b/drivers/net/ixgbe/base/ixgbe_phy.h
> >> index ceefbb3e68..cd57ce040f 100644
> >> --- a/drivers/net/ixgbe/base/ixgbe_phy.h
> >> +++ b/drivers/net/ixgbe/base/ixgbe_phy.h
> >> @@ -21,6 +21,7 @@
> >>   #define IXGBE_SFF_CABLE_TECHNOLOGY   0x8
> >>   #define IXGBE_SFF_CABLE_SPEC_COMP    0x3C
> >>   #define IXGBE_SFF_SFF_8472_SWAP              0x5C
> >> +#define IXGBE_SFF_SFF_8472_EOPT              0x5D
> >
> > Looks like this is YOUR platform specific, then this patchset can't be
> > merged. : - (
> 
> This isn't anything unique to our hardware, these values are coming from
> the SFF-8472 SFP+ I2C specification.
> 
> The ability to do a soft rate select via I2C is an optional feature, and
> modules that support it are supposed to set bit 3 in byte 93 (0x5d), the
> "Enhanced Options" register, to advertise the functionality.
> 
> Please see section 8.10 and Table 8-6 in the SFF-8472 spec.
> 
> Checking the RATE_SELECT bit flag may be overkill since the transceiver
> is supposed to ignore writes to rate select control bits if the feature
> isn't implemented.  I can drop that check if you like, but the other
> checks for a 8472 device (vs 8079) aren't anything different than what
> already happens in the driver elsewhere[1].  I'd argue that testing that
> a feature is supported in hardware before trying to use it is normal
> driver behavior.
> 
> If instead you mean that the entire series is somehow applicable only to
> our hardware, I'm not sure why.
> 
> That hotplug issue isn't seen on the same hardware when using the Linux
> driver; so it's a dpdk problem (at least on C3000 ixgbe devs), and not a

I can't find your related fix in two official Linux drivers:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/intel/ixgbe
https://www.intel.com/content/www/us/en/download/14302/14687/intel-network-adapter-driver-for-pcie-intel-10-gigabit-ethernet-network-connections-under-linux.html?

Normally, DPDK keeps sync with this kind of release.

> hardware problem.  Fixing the hotplug/rateswap issue was my primary
> goal, the other patches fix problems I found along the way while
> debugging.
> 
> I can also reproduce the hotplug/rateswap issue on the PLCC-B, an Intel
> reference design for the C3000 family, so again, not unique to this
> platform.

I guess this is just in C3000 reference board SDK ?

I recommend you submit the fix to kernel firstly, you will get more
experts' reviews and fully test:

https://patchwork.ozlabs.org/project/intel-wired-lan/list/
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

> 
> Please let me know if that addresses your concerns, or if I've missed
> your point.
> 





> Thanks,
> Steve
> 
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/intel/ixg
> be/ixgbe_ethtool.c?h=v5.16-rc6
> 
> >>   #define IXGBE_SFF_SFF_8472_COMP              0x5E
> >>   #define IXGBE_SFF_SFF_8472_OSCB              0x6E
> >>   #define IXGBE_SFF_SFF_8472_ESCB              0x76
> >> @@ -48,6 +49,8 @@
> >>   #define IXGBE_SFF_SOFT_RS_SELECT_10G 0x8
> >> --
> >> 2.31.1
> >
Morten Brørup Dec. 21, 2021, 8:57 a.m. UTC | #4 
> From: Wang, Haiyue [mailto:haiyue.wang@intel.com]
> Sent: Tuesday, 21 December 2021 02.15
> 
> > -----Original Message-----
> > From: Stephen Douthit <stephend@silicom-usa.com>
> > Sent: Tuesday, December 21, 2021 05:33
> >
> > On 12/20/21 02:53, Wang, Haiyue wrote:
> > >> -----Original Message-----
> > >> From: Stephen Douthit <stephend@silicom-usa.com>
> > >> Sent: Tuesday, December 7, 2021 06:19
> > >>
> > >> Make sure an SFP is really a SFF-8472 device that supports the
> optional
> > >> soft rate select feature before just blindly poking those I2C
> registers.
> > >>
> > >> Skip all I2C traffic if we know there's no SFP.
> > >>
> > >> Fixes: f3430431aba ("ixgbe/base: add SFP+ dual-speed support")
> > >> Cc: stable@dpdk.org
> > >>
> > >> Signed-off-by: Stephen Douthit <stephend@silicom-usa.com>
> > >> ---
> > >
> > >
> > >>        /* Set RS0 */
> > >>        status = hw->phy.ops.read_i2c_byte(hw,
> IXGBE_SFF_SFF_8472_OSCB,
> > >>
> IXGBE_I2C_EEPROM_DEV_ADDR2,
> > >> diff --git a/drivers/net/ixgbe/base/ixgbe_phy.h
> b/drivers/net/ixgbe/base/ixgbe_phy.h
> > >> index ceefbb3e68..cd57ce040f 100644
> > >> --- a/drivers/net/ixgbe/base/ixgbe_phy.h
> > >> +++ b/drivers/net/ixgbe/base/ixgbe_phy.h
> > >> @@ -21,6 +21,7 @@
> > >>   #define IXGBE_SFF_CABLE_TECHNOLOGY   0x8
> > >>   #define IXGBE_SFF_CABLE_SPEC_COMP    0x3C
> > >>   #define IXGBE_SFF_SFF_8472_SWAP              0x5C
> > >> +#define IXGBE_SFF_SFF_8472_EOPT              0x5D
> > >
> > > Looks like this is YOUR platform specific, then this patchset can't
> be
> > > merged. : - (
> >
> > This isn't anything unique to our hardware, these values are coming
> from
> > the SFF-8472 SFP+ I2C specification.
> >
> > The ability to do a soft rate select via I2C is an optional feature,
> and
> > modules that support it are supposed to set bit 3 in byte 93 (0x5d),
> the
> > "Enhanced Options" register, to advertise the functionality.
> >
> > Please see section 8.10 and Table 8-6 in the SFF-8472 spec.
> >
> > Checking the RATE_SELECT bit flag may be overkill since the
> transceiver
> > is supposed to ignore writes to rate select control bits if the
> feature
> > isn't implemented.  I can drop that check if you like, but the other
> > checks for a 8472 device (vs 8079) aren't anything different than
> what
> > already happens in the driver elsewhere[1].  I'd argue that testing
> that
> > a feature is supported in hardware before trying to use it is normal
> > driver behavior.
> >
> > If instead you mean that the entire series is somehow applicable only
> to
> > our hardware, I'm not sure why.
> >
> > That hotplug issue isn't seen on the same hardware when using the
> Linux
> > driver; so it's a dpdk problem (at least on C3000 ixgbe devs), and
> not a
> 
> I can't find your related fix in two official Linux drivers:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree
> /drivers/net/ethernet/intel/ixgbe
> https://www.intel.com/content/www/us/en/download/14302/14687/intel-
> network-adapter-driver-for-pcie-intel-10-gigabit-ethernet-network-
> connections-under-linux.html?
> 
> Normally, DPDK keeps sync with this kind of release.
> 

Working with the Linux kernel mainline drivers is good advice.

The official Intel Linux drivers seem to be ages behind the Kernel mainline, and they don't fully support the C3000 NICs, so don’t waste any time there! We recently tried using the official Intel Linux drivers for a C3338 based project (using Kernel 3.19 in 32 bit mode with x2APIC disabled), and they didn't work at all. We ended up backporting the necessary changes from the kernel mainline instead.

> > hardware problem.  Fixing the hotplug/rateswap issue was my primary
> > goal, the other patches fix problems I found along the way while
> > debugging.
> >
> > I can also reproduce the hotplug/rateswap issue on the PLCC-B, an
> Intel
> > reference design for the C3000 family, so again, not unique to this
> > platform.
> 
> I guess this is just in C3000 reference board SDK ?
> 
> I recommend you submit the fix to kernel firstly, you will get more
> experts' reviews and fully test:
> 
> https://patchwork.ozlabs.org/project/intel-wired-lan/list/
> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
>
Stephen Douthit Dec. 21, 2021, 2:05 p.m. UTC | #5 
On 12/20/21 20:15, Wang, Haiyue wrote:
>> -----Original Message-----
>> From: Stephen Douthit <stephend@silicom-usa.com>
>> Sent: Tuesday, December 21, 2021 05:33
>> To: Wang, Haiyue <haiyue.wang@intel.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>; Changchun Ouyang
>> <changchun.ouyang@intel.com>; Zhang, Helin <helin.zhang@intel.com>
>> Cc: dev@dpdk.org; Wang, Wen <wenw@silicom-usa.com>; stable@dpdk.org
>> Subject: Re: [PATCH v2 3/7] net/ixgbe: Check that SFF-8472 soft rate select is supported before write
>>
>> On 12/20/21 02:53, Wang, Haiyue wrote:
>>>> -----Original Message-----
>>>> From: Stephen Douthit <stephend@silicom-usa.com>
>>>> Sent: Tuesday, December 7, 2021 06:19
>>>> To: Wang, Haiyue <haiyue.wang@intel.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>; Changchun Ouyang
>>>> <changchun.ouyang@intel.com>; Zhang, Helin <helin.zhang@intel.com>
>>>> Cc: dev@dpdk.org; Wen Wang <wenw@silicom-usa.com>; Stephen Douthit <stephend@silicom-usa.com>;
>>>> stable@dpdk.org
>>>> Subject: [PATCH v2 3/7] net/ixgbe: Check that SFF-8472 soft rate select is supported before write
>>>>
>>>> Make sure an SFP is really a SFF-8472 device that supports the optional
>>>> soft rate select feature before just blindly poking those I2C registers.
>>>>
>>>> Skip all I2C traffic if we know there's no SFP.
>>>>
>>>> Fixes: f3430431aba ("ixgbe/base: add SFP+ dual-speed support")
>>>> Cc: stable@dpdk.org
>>>>
>>>> Signed-off-by: Stephen Douthit <stephend@silicom-usa.com>
>>>> ---
>>>
>>>
>>>>         /* Set RS0 */
>>>>         status = hw->phy.ops.read_i2c_byte(hw, IXGBE_SFF_SFF_8472_OSCB,
>>>>                                            IXGBE_I2C_EEPROM_DEV_ADDR2,
>>>> diff --git a/drivers/net/ixgbe/base/ixgbe_phy.h b/drivers/net/ixgbe/base/ixgbe_phy.h
>>>> index ceefbb3e68..cd57ce040f 100644
>>>> --- a/drivers/net/ixgbe/base/ixgbe_phy.h
>>>> +++ b/drivers/net/ixgbe/base/ixgbe_phy.h
>>>> @@ -21,6 +21,7 @@
>>>>    #define IXGBE_SFF_CABLE_TECHNOLOGY   0x8
>>>>    #define IXGBE_SFF_CABLE_SPEC_COMP    0x3C
>>>>    #define IXGBE_SFF_SFF_8472_SWAP              0x5C
>>>> +#define IXGBE_SFF_SFF_8472_EOPT              0x5D
>>>
>>> Looks like this is YOUR platform specific, then this patchset can't be
>>> merged. : - (
>>
>> This isn't anything unique to our hardware, these values are coming from
>> the SFF-8472 SFP+ I2C specification.
>>
>> The ability to do a soft rate select via I2C is an optional feature, and
>> modules that support it are supposed to set bit 3 in byte 93 (0x5d), the
>> "Enhanced Options" register, to advertise the functionality.
>>
>> Please see section 8.10 and Table 8-6 in the SFF-8472 spec.
>>
>> Checking the RATE_SELECT bit flag may be overkill since the transceiver
>> is supposed to ignore writes to rate select control bits if the feature
>> isn't implemented.  I can drop that check if you like, but the other
>> checks for a 8472 device (vs 8079) aren't anything different than what
>> already happens in the driver elsewhere[1].  I'd argue that testing that
>> a feature is supported in hardware before trying to use it is normal
>> driver behavior.
>>
>> If instead you mean that the entire series is somehow applicable only to
>> our hardware, I'm not sure why.
>>
>> That hotplug issue isn't seen on the same hardware when using the Linux
>> driver; so it's a dpdk problem (at least on C3000 ixgbe devs), and not a
> 
> I can't find your related fix in two official Linux drivers:

There's no submission from me on the hotplug issue for the mainline,
because the issue isn't present in Linux, only in DPDK.

> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/intel/ixgbe
> https://www.intel.com/content/www/us/en/download/14302/14687/intel-network-adapter-driver-for-pcie-intel-10-gigabit-ethernet-network-connections-under-linux.html?
> 
> Normally, DPDK keeps sync with this kind of release.
> 
>> hardware problem.  Fixing the hotplug/rateswap issue was my primary
>> goal, the other patches fix problems I found along the way while
>> debugging.
>>
>> I can also reproduce the hotplug/rateswap issue on the PLCC-B, an Intel
>> reference design for the C3000 family, so again, not unique to this
>> platform.
> 
> I guess this is just in C3000 reference board SDK ?

It's the board covered by Intel Doc # 574437.

> I recommend you submit the fix to kernel firstly, you will get more
> experts' reviews and fully test:

Since patch 3 isn't directly related to the hotplug issue should I pull
it from the series for v3 to keep the hotplug fixes moving forward here,
and in parallel submit just that one to Linux?

Thanks,
Steve

> https://patchwork.ozlabs.org/project/intel-wired-lan/list/
> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
> 
>>
>> Please let me know if that addresses your concerns, or if I've missed
>> your point.
>>
> 
> 
> 
> 
> 
>> Thanks,
>> Steve
>>
>> [1]
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/intel/ixg
>> be/ixgbe_ethtool.c?h=v5.16-rc6
>>
>>>>    #define IXGBE_SFF_SFF_8472_COMP              0x5E
>>>>    #define IXGBE_SFF_SFF_8472_OSCB              0x6E
>>>>    #define IXGBE_SFF_SFF_8472_ESCB              0x76
>>>> @@ -48,6 +49,8 @@
>>>>    #define IXGBE_SFF_SOFT_RS_SELECT_10G 0x8
>>>> --
>>>> 2.31.1
>>>
>
Wang, Haiyue Dec. 22, 2021, 1:24 a.m. UTC | #6 
> -----Original Message-----
> From: Morten Brørup <mb@smartsharesystems.com>
> Sent: Tuesday, December 21, 2021 16:58
> To: Wang, Haiyue <haiyue.wang@intel.com>; stephend@silicom-usa.com; Lu, Wenzhuo <wenzhuo.lu@intel.com>;
> Changchun Ouyang <changchun.ouyang@intel.com>; Zhang, Helin <helin.zhang@intel.com>
> Cc: dev@dpdk.org; Wang, Wen <wenw@silicom-usa.com>; stable@dpdk.org
> Subject: RE: [PATCH v2 3/7] net/ixgbe: Check that SFF-8472 soft rate select is supported before write
> 
> > From: Wang, Haiyue [mailto:haiyue.wang@intel.com]
> > Sent: Tuesday, 21 December 2021 02.15
> >
> > > -----Original Message-----
> > > From: Stephen Douthit <stephend@silicom-usa.com>
> > > Sent: Tuesday, December 21, 2021 05:33
> > >
> > > On 12/20/21 02:53, Wang, Haiyue wrote:
> > > >> -----Original Message-----
> > > >> From: Stephen Douthit <stephend@silicom-usa.com>
> > > >> Sent: Tuesday, December 7, 2021 06:19
> > > >>
> > > >> Make sure an SFP is really a SFF-8472 device that supports the
> > optional
> > > >> soft rate select feature before just blindly poking those I2C
> > registers.
> > > >>
> > > >> Skip all I2C traffic if we know there's no SFP.
> > > >>
> > > >> Fixes: f3430431aba ("ixgbe/base: add SFP+ dual-speed support")
> > > >> Cc: stable@dpdk.org
> > > >>
> > > >> Signed-off-by: Stephen Douthit <stephend@silicom-usa.com>
> > > >> ---
> > > >


> >
> > Normally, DPDK keeps sync with this kind of release.
> >
> 
> Working with the Linux kernel mainline drivers is good advice.
> 
> The official Intel Linux drivers seem to be ages behind the Kernel mainline, and they don't fully

No, the "ixgbe" drivers is updated on "7/8/2021".

https://www.intel.com/content/www/us/en/download/14302/14687/intel-network-adapter-driver-for-pcie-intel-10-gigabit-ethernet-network-connections-under-linux.html

> support the C3000 NICs, so don’t waste any time there! We recently tried using the official Intel
> Linux drivers for a C3338 based project (using Kernel 3.19 in 32 bit mode with x2APIC disabled), and
> they didn't work at all. We ended up backporting the necessary changes from the kernel mainline
> instead.

From Steve's response: 
     ME: "I guess this is just in C3000 reference board SDK ?"
     Steve: "It's the board covered by Intel Doc # 574437."

I check the doc "Last Updated: 11/07/2018".... It should be some kind of customer release, that's why
they are not in the official *open source* Linux driver, so keep your patch set as private.
Morten Brørup Dec. 22, 2021, 10:43 a.m. UTC | #7 
> From: Wang, Haiyue [mailto:haiyue.wang@intel.com]
> Sent: Wednesday, 22 December 2021 02.24
> 
> > -----Original Message-----
> > From: Morten Brørup <mb@smartsharesystems.com>
> > Sent: Tuesday, December 21, 2021 16:58
> >
> > > From: Wang, Haiyue [mailto:haiyue.wang@intel.com]
> > > Sent: Tuesday, 21 December 2021 02.15
> > >
> > > > -----Original Message-----
> > > > From: Stephen Douthit <stephend@silicom-usa.com>
> > > > Sent: Tuesday, December 21, 2021 05:33
> > > >
> > > > On 12/20/21 02:53, Wang, Haiyue wrote:
> > > > >> -----Original Message-----
> > > > >> From: Stephen Douthit <stephend@silicom-usa.com>
> > > > >> Sent: Tuesday, December 7, 2021 06:19
> > > > >>
> > > > >> Make sure an SFP is really a SFF-8472 device that supports the
> > > optional
> > > > >> soft rate select feature before just blindly poking those I2C
> > > registers.
> > > > >>
> > > > >> Skip all I2C traffic if we know there's no SFP.
> > > > >>
> > > > >> Fixes: f3430431aba ("ixgbe/base: add SFP+ dual-speed support")
> > > > >> Cc: stable@dpdk.org
> > > > >>
> > > > >> Signed-off-by: Stephen Douthit <stephend@silicom-usa.com>
> > > > >> ---
> > > > >
> 
> 
> > >
> > > Normally, DPDK keeps sync with this kind of release.
> > >
> >
> > Working with the Linux kernel mainline drivers is good advice.
> >
> > The official Intel Linux drivers seem to be ages behind the Kernel
> mainline, and they don't fully
> 
> No, the "ixgbe" drivers is updated on "7/8/2021".
> 
> https://www.intel.com/content/www/us/en/download/14302/14687/intel-
> network-adapter-driver-for-pcie-intel-10-gigabit-ethernet-network-
> connections-under-linux.html

So you can imagine my surprise that they didn't work on the C3338 SoC launched by Intel in Q1'17. The web page says that the drivers supports kernel versions 2.6.18 to 5.12, so we expected them to work with kernel 3.19. Perhaps they haven't been tested with the C3338 SoC. Also, the test section on the web page only mentions 64 bit distributions, so perhaps they haven't been tested with a 32 bit kernel. There is no test report available, so I can only speculate.

I am sorry if I came off as badmouthing the Intel out-of-tree driver. I was only trying to convey to the good folks at Silicom that kernel.org is a better source of inspiration than the Intel out-of-tree driver, which is not as up-to-date as the kernel.org driver, and thus not the optimal source of inspiration for driver development. The out-of-tree drivers serve a different purpose, where they are extremely valuable: In normal production environments where it is not an option to compile and deploy a kernel from scratch.

> 
> > support the C3000 NICs, so don’t waste any time there! We recently
> tried using the official Intel
> > Linux drivers for a C3338 based project (using Kernel 3.19 in 32 bit
> mode with x2APIC disabled), and
> > they didn't work at all. We ended up backporting the necessary
> changes from the kernel mainline
> > instead.
> 
> From Steve's response:
>      ME: "I guess this is just in C3000 reference board SDK ?"
>      Steve: "It's the board covered by Intel Doc # 574437."
> 
> I check the doc "Last Updated: 11/07/2018".... It should be some kind
> of customer release, that's why
> they are not in the official *open source* Linux driver, so keep your
> patch set as private.

I didn't mention it explicitly, but I'm not involved with Silicom, and was not referring to their hardware. The hardware board we had problems with is currently in volume production at a major ODM. But I guess that it is usually being deployed with a 64 bit kernel, as opposed to the 32 bit kernel we were using.


Med venlig hilsen / kind regards

Morten Brørup
CTO


SmartShare Systems A/S
Tonsbakken 16-18
DK-2740 Skovlunde
Denmark

Office      +45 70 20 00 93
Direct      +45 89 93 50 22
Mobile      +45 25 40 82 12

mb@smartsharesystems.com
www.smartsharesystems.com
Wang, Haiyue Dec. 22, 2021, 4:03 p.m. UTC | #8 
> -----Original Message-----
> From: Morten Brørup <mb@smartsharesystems.com>
> Sent: Wednesday, December 22, 2021 18:44
> To: Wang, Haiyue <haiyue.wang@intel.com>; stephend@silicom-usa.com; Lu, Wenzhuo <wenzhuo.lu@intel.com>;
> Zhang, Helin <helin.zhang@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>
> Cc: dev@dpdk.org; Wang, Wen <wenw@silicom-usa.com>; stable@dpdk.org
> Subject: RE: [PATCH v2 3/7] net/ixgbe: Check that SFF-8472 soft rate select is supported before write
> 
> > From: Wang, Haiyue [mailto:haiyue.wang@intel.com]
> > Sent: Wednesday, 22 December 2021 02.24
> >
> > > -----Original Message-----
> > > From: Morten Brørup <mb@smartsharesystems.com>
> > > Sent: Tuesday, December 21, 2021 16:58
> > >
> > > > From: Wang, Haiyue [mailto:haiyue.wang@intel.com]
> > > > Sent: Tuesday, 21 December 2021 02.15
> > > >
> > > > > -----Original Message-----
> > > > > From: Stephen Douthit <stephend@silicom-usa.com>
> > > > > Sent: Tuesday, December 21, 2021 05:33
> > > > >
> > > > > On 12/20/21 02:53, Wang, Haiyue wrote:
> > > > > >> -----Original Message-----
> > > > > >> From: Stephen Douthit <stephend@silicom-usa.com>
> > > > > >> Sent: Tuesday, December 7, 2021 06:19
> > > > > >>
> > > > > >> Make sure an SFP is really a SFF-8472 device that supports the
> > > > optional
> > > > > >> soft rate select feature before just blindly poking those I2C
> > > > registers.
> > > > > >>
> > > > > >> Skip all I2C traffic if we know there's no SFP.
> > > > > >>
> > > > > >> Fixes: f3430431aba ("ixgbe/base: add SFP+ dual-speed support")
> > > > > >> Cc: stable@dpdk.org
> > > > > >>
> > > > > >> Signed-off-by: Stephen Douthit <stephend@silicom-usa.com>
> > > > > >> ---
> > > > > >
> >
> >
> > > >
> > > > Normally, DPDK keeps sync with this kind of release.
> > > >
> > >
> > > Working with the Linux kernel mainline drivers is good advice.
> > >
> > > The official Intel Linux drivers seem to be ages behind the Kernel
> > mainline, and they don't fully
> >
> > No, the "ixgbe" drivers is updated on "7/8/2021".
> >
> > https://www.intel.com/content/www/us/en/download/14302/14687/intel-
> > network-adapter-driver-for-pcie-intel-10-gigabit-ethernet-network-
> > connections-under-linux.html
> 
> So you can imagine my surprise that they didn't work on the C3338 SoC launched by Intel in Q1'17. The
> web page says that the drivers supports kernel versions 2.6.18 to 5.12, so we expected them to work
> with kernel 3.19. Perhaps they haven't been tested with the C3338 SoC. Also, the test section on the
> web page only mentions 64 bit distributions, so perhaps they haven't been tested with a 32 bit kernel.
> There is no test report available, so I can only speculate.
> 
> I am sorry if I came off as badmouthing the Intel out-of-tree driver. I was only trying to convey to
> the good folks at Silicom that kernel.org is a better source of inspiration than the Intel out-of-tree
> driver, which is not as up-to-date as the kernel.org driver, and thus not the optimal source of
> inspiration for driver development. The out-of-tree drivers serve a different purpose, where they are
> extremely valuable: In normal production environments where it is not an option to compile and deploy
> a kernel from scratch.
>

> >
> > > support the C3000 NICs, so don’t waste any time there! We recently
> > tried using the official Intel
> > > Linux drivers for a C3338 based project (using Kernel 3.19 in 32 bit
> > mode with x2APIC disabled), and
> > > they didn't work at all. We ended up backporting the necessary
> > changes from the kernel mainline
> > > instead.
> >
> > From Steve's response:
> >      ME: "I guess this is just in C3000 reference board SDK ?"
> >      Steve: "It's the board covered by Intel Doc # 574437."
> >
> > I check the doc "Last Updated: 11/07/2018".... It should be some kind
> > of customer release, that's why
> > they are not in the official *open source* Linux driver, so keep your
> > patch set as private.
> 
> I didn't mention it explicitly, but I'm not involved with Silicom, and was not referring to their
> hardware. The hardware board we had problems with is currently in volume production at a major ODM.
> But I guess that it is usually being deployed with a 64 bit kernel, as opposed to the 32 bit kernel we
> were using.

I understood, but we need to follow the open source vs customer release policy,
so not everything is upstream.

The ixgbe (especially in base directory) code is so stable, so in other words,
this patch set can be rebased easily. ;-)

If the patch is about ixgbe ethdev part (vs kernel netdev), it will be welcomed,
since our team mainly work on this (And the base code is mainly developed by the
kernel team, that's why I recommend to send it to
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan).

Hope this will make things clear. ;-)

> 
> 
> Med venlig hilsen / kind regards
> 
> Morten Brørup
> CTO
> 
> 
> SmartShare Systems A/S
> Tonsbakken 16-18
> DK-2740 Skovlunde
> Denmark
> 
> Office      +45 70 20 00 93
> Direct      +45 89 93 50 22
> Mobile      +45 25 40 82 12
> 
> mb@smartsharesystems.com
> www.smartsharesystems.com
Morten Brørup Dec. 22, 2021, 7:13 p.m. UTC | #9 
> From: Wang, Haiyue [mailto:haiyue.wang@intel.com]
> Sent: Wednesday, 22 December 2021 17.03
> 
> > -----Original Message-----
> > From: Morten Brørup <mb@smartsharesystems.com>
> > Sent: Wednesday, December 22, 2021 18:44
> >
> > > From: Wang, Haiyue [mailto:haiyue.wang@intel.com]
> > > Sent: Wednesday, 22 December 2021 02.24
> > >
> > > > -----Original Message-----
> > > > From: Morten Brørup <mb@smartsharesystems.com>
> > > > Sent: Tuesday, December 21, 2021 16:58
> > > >
> > > > > From: Wang, Haiyue [mailto:haiyue.wang@intel.com]
> > > > > Sent: Tuesday, 21 December 2021 02.15
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Stephen Douthit <stephend@silicom-usa.com>
> > > > > > Sent: Tuesday, December 21, 2021 05:33
> > > > > >
> > > > > > On 12/20/21 02:53, Wang, Haiyue wrote:
> > > > > > >> -----Original Message-----
> > > > > > >> From: Stephen Douthit <stephend@silicom-usa.com>
> > > > > > >> Sent: Tuesday, December 7, 2021 06:19
> > > > > > >>
> > > > > > >> Make sure an SFP is really a SFF-8472 device that supports
> the
> > > > > optional
> > > > > > >> soft rate select feature before just blindly poking those
> I2C
> > > > > registers.
> > > > > > >>
> > > > > > >> Skip all I2C traffic if we know there's no SFP.
> > > > > > >>
> > > > > > >> Fixes: f3430431aba ("ixgbe/base: add SFP+ dual-speed
> support")
> > > > > > >> Cc: stable@dpdk.org
> > > > > > >>
> > > > > > >> Signed-off-by: Stephen Douthit <stephend@silicom-usa.com>
> > > > > > >> ---
> > > > > > >
> > >
> > >
> > > > >
> > > > > Normally, DPDK keeps sync with this kind of release.
> > > > >
> > > >
> > > > Working with the Linux kernel mainline drivers is good advice.
> > > >
> > > > The official Intel Linux drivers seem to be ages behind the
> Kernel
> > > mainline, and they don't fully
> > >
> > > No, the "ixgbe" drivers is updated on "7/8/2021".
> > >
> > > https://www.intel.com/content/www/us/en/download/14302/14687/intel-
> > > network-adapter-driver-for-pcie-intel-10-gigabit-ethernet-network-
> > > connections-under-linux.html
> >
> > So you can imagine my surprise that they didn't work on the C3338 SoC
> launched by Intel in Q1'17. The
> > web page says that the drivers supports kernel versions 2.6.18 to
> 5.12, so we expected them to work
> > with kernel 3.19. Perhaps they haven't been tested with the C3338
> SoC. Also, the test section on the
> > web page only mentions 64 bit distributions, so perhaps they haven't
> been tested with a 32 bit kernel.
> > There is no test report available, so I can only speculate.
> >
> > I am sorry if I came off as badmouthing the Intel out-of-tree driver.
> I was only trying to convey to
> > the good folks at Silicom that kernel.org is a better source of
> inspiration than the Intel out-of-tree
> > driver, which is not as up-to-date as the kernel.org driver, and thus
> not the optimal source of
> > inspiration for driver development. The out-of-tree drivers serve a
> different purpose, where they are
> > extremely valuable: In normal production environments where it is not
> an option to compile and deploy
> > a kernel from scratch.
> >
> 
> > >
> > > > support the C3000 NICs, so don’t waste any time there! We
> recently
> > > tried using the official Intel
> > > > Linux drivers for a C3338 based project (using Kernel 3.19 in 32
> bit
> > > mode with x2APIC disabled), and
> > > > they didn't work at all. We ended up backporting the necessary
> > > changes from the kernel mainline
> > > > instead.
> > >
> > > From Steve's response:
> > >      ME: "I guess this is just in C3000 reference board SDK ?"
> > >      Steve: "It's the board covered by Intel Doc # 574437."
> > >
> > > I check the doc "Last Updated: 11/07/2018".... It should be some
> kind
> > > of customer release, that's why
> > > they are not in the official *open source* Linux driver, so keep
> your
> > > patch set as private.
> >
> > I didn't mention it explicitly, but I'm not involved with Silicom,
> and was not referring to their
> > hardware. The hardware board we had problems with is currently in
> volume production at a major ODM.
> > But I guess that it is usually being deployed with a 64 bit kernel,
> as opposed to the 32 bit kernel we
> > were using.
> 
> I understood, but we need to follow the open source vs customer release
> policy,
> so not everything is upstream.
> 
> The ixgbe (especially in base directory) code is so stable, so in other
> words,
> this patch set can be rebased easily. ;-)
> 
> If the patch is about ixgbe ethdev part (vs kernel netdev), it will be
> welcomed,
> since our team mainly work on this (And the base code is mainly
> developed by the
> kernel team, that's why I recommend to send it to
> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan).
> 
> Hope this will make things clear. ;-)

ACK. :-)
Stephen Douthit Dec. 22, 2021, 9:44 p.m. UTC | #10 
<snip>

>>>
>>>  From Steve's response:
>>>       ME: "I guess this is just in C3000 reference board SDK ?"
>>>       Steve: "It's the board covered by Intel Doc # 574437."
>>>
>>> I check the doc "Last Updated: 11/07/2018".... It should be some kind
>>> of customer release, that's why
>>> they are not in the official *open source* Linux driver, so keep your
>>> patch set as private.
>>
>> I didn't mention it explicitly, but I'm not involved with Silicom, and was not referring to their
>> hardware. The hardware board we had problems with is currently in volume production at a major ODM.
>> But I guess that it is usually being deployed with a 64 bit kernel, as opposed to the 32 bit kernel we
>> were using.
> 
> I understood, but we need to follow the open source vs customer release policy,
> so not everything is upstream.

I'm afraid we're still talking past each other here.

I'm using the CRB as a "known good" platform to confirm that the hotplug
issue is _not_ some OEM specific platform quirk.  The CRB is not the
target of the patch set, it's a way for me to make sure I'm not chasing
a bug in our hardware.  If our hardware was the only place the bug was
present I would agree that maintaining this fix outside of mainline
would make sense, but testing on the CRB proves that's not the case.

Implying that testing patches on a CRB somehow makes them ineligible to
be open sourced/upstreamed doesn't really make sense to me.

> The ixgbe (especially in base directory) code is so stable, so in other words,
> this patch set can be rebased easily. ;-)
I found an 82599ES (device ID 0x10fb) this afternoon, and the dpdk ixgbe
driver is "so stable" (I know you meant from a standpoint of few
commits, but couldn't resist) that it has the exact same problem I was
debugging on the C3000 devices. :)

Big log at the end of the email.[4]

Unfortunately my patch series does not fix the issue on the 82599 like
it did for the C3000, so I'll need to look into that now that I have a
card to test on. :(

> If the patch is about ixgbe ethdev part (vs kernel netdev), it will be welcomed,
> since our team mainly work on this (And the base code is mainly developed by the
> kernel team, that's why I recommend to send it to
> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan).

What I believe you're saying is that you want any edits to base/* to
come from the mainline Linux driver, and only fixes to ixgbe_ethdev.c
from this mailing list.

Here's how the hotplug patches -- 1, 2, 4, 5 -- (ignoring 3, 6, & 7 for
now), break down into those two categories:

Patch 1:
All edits are to ixgbe_ethdev.c, and the same code is already in the
mainline.[1]

Seems good to submit here.

Patch 2:
Located in base/, but exports functionality that makes Patch 5 simpler.

I could probably drop this patch and rework Patch 5 to just attempt an
I2C read and see if it's ACKed/NAKed, but I believe that this is
cleaner.  Since the driver bitbangs the I2C bus, I'd prefer to avoid the
overhead and check the SFP present signal via the associated SDP input
and skip the I2C traffic if I know the cage is empty.

This patch seems like it could go either way, add present check to Linux
and backport, or just move the code into ixgbe_ethdev.c since it's not
fixing anything in Linux.

Patch 4:
Located in base/, but addresses a workaround found _only in dpdk_ that
checks the TX laser enable bit (SDP3 on 82599) to qualify the link
status reported by ixgbe_check_mac_link_generic().

The original code smells off to me for a number of reasons.
1) There's nothing like that in mainline.  The only code touching SDP3
there is just controlling the TX laser[2], SDP3's status is never read.

2) The workaround runs on all fiber platforms, even though the commit
message said it was for the 82599eb.  The C3000 doesn't use SDP3 for
TX_DISABLE so poking it on that platform is definitely incorrect, and
may be wrong for others.

3) Open coding this in a single location instead of putting it in a
platform specific mac->ops.check_link() callback implies that the link
status returned at every other check_link() callsite may be bogus if
the workaround is really needed.

I could leave the workaround where it started off in ixgbe_ethdev and
just add a mac type qualifier.  With that edit it seems good to submit
here.

Patch 5:
All edits are to ixgbe_ethdev.c, and addresses an issue not found in
the Linux driver.  The Linux driver uses ixgbe_service_task()[3] to
handle SFP detection and setup, and handles hotplug just fine.  This
patch moves the dpdk driver closer to that working scheme.

Seems good to submit here.

In summary:
1 & 5 seem like clear candidates to upstream directly via dpdk, 2 could
be reworked to avoid touching base/ or dropped and 5 refactored, and 4
can be easily refactored to avoid touching base/.  However my gut says
something's off and commits 1ca05831b9b & ff8162cb957 that made patch 4
necessary in the first place weren't really getting to root cause since
the Linux driver functions without this workaround.

> Hope this will make things clear. ;-)

Same. :)

Either way I'm hoping to be out for the rest of the year, so I'll
revisit this January 3rd.

Happy holidays!

Thanks,
Steve

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c?h=v5.16-rc6#n2887
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c?h=v5.16-rc6#n572
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c?h=v5.16-rc6#n592
[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c?h=v5.16-rc6#n7911
[4] Wall of text:

Script started on 2021-12-22 11:19:00-05:00 [TERM="screen.xterm-256color" TTY="/dev/pts/2" COLUMNS="136" LINES="72"]
[root@madrid dpdk]# ./build/app/dpdk-testpmd --log-level *:info -c7 --vdev=0000:20:00.0 --vdev=0000:20:00.1 -- -i --nb-cores=2 --nb-ports=2 --total-num-mbufs=2048
EAL: Detected CPU lcores: 8
EAL: Detected NUMA nodes: 1
EAL: Detected static linkage of DPDK
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
EAL: Selected IOVA mode 'VA'
EAL: No available 1048576 kB hugepages reported
EAL: VFIO support initialized
EAL: Using IOMMU type 1 (Type 1)
EAL: Ignore mapping IO port bar(2)
EAL: Probe PCI driver: net_ixgbe (8086:10fb) device: 0000:20:00.0 (socket 0)
EAL: Ignore mapping IO port bar(2)
EAL: Probe PCI driver: net_ixgbe (8086:10fb) device: 0000:20:00.1 (socket 0)
Interactive-mode selected
testpmd: create a new mbuf pool <mb_pool_0>: n=2048, size=2176, socket=0
testpmd: preferred mempool ops selected: ring_mp_mc
Configuring Port 0 (socket 0)
ixgbe_dev_link_status_print():  Port 0: Link Down
Port 0: 00:E0:ED:97:62:4D
Configuring Port 1 (socket 0)
ixgbe_dev_link_status_print():  Port 1: Link Down
Port 1: 00:E0:ED:97:62:4E
Checking link statuses...
Done
testpmd> # started with empty SFP cages
testpmd> show port info all

********************* Infos for port 0  *********************
MAC address: 00:E0:ED:97:62:4D
Device name: 0000:20:00.0
Driver name: net_ixgbe
Firmware-version: 0x800000cb
Devargs:
Connect to socket: 0
memory allocation on the socket: 0
Link status: down
Link speed: None
Link duplex: half-duplex
Autoneg status: On
MTU: 1500
Promiscuous mode: enabled
Allmulticast mode: disabled
Maximum number of MAC addresses: 128
Maximum number of MAC addresses of hash filtering: 4096
VLAN offload:
   strip off, filter off, extend off, qinq strip off
Hash key size in bytes: 40
Redirection table size: 128
Supported RSS offload flow types:
   ipv4
   ipv4-tcp
   ipv4-udp
   ipv6
   ipv6-tcp
   ipv6-udp
   ipv6-ex
   ipv6-tcp-ex
   ipv6-udp-ex
Minimum size of RX buffer: 1024
Maximum configurable length of RX packet: 15872
Maximum configurable size of LRO aggregated packet: 0
Maximum number of VMDq pools: 64
Current number of RX queues: 1
Max possible RX queues: 128
Max possible number of RXDs per queue: 4096
Min possible number of RXDs per queue: 32
RXDs number alignment: 8
Current number of TX queues: 1
Max possible TX queues: 64
Max possible number of TXDs per queue: 4096
Min possible number of TXDs per queue: 32
TXDs number alignment: 8
Max segment number per packet: 40
Max segment number per MTU/TSO: 40
Device capabilities: 0x0( )

********************* Infos for port 1  *********************
MAC address: 00:E0:ED:97:62:4E
Device name: 0000:20:00.1
Driver name: net_ixgbe
Firmware-version: 0x800000cb
Devargs:
Connect to socket: 0
memory allocation on the socket: 0
Link status: down
Link speed: None
Link duplex: half-duplex
Autoneg status: On
MTU: 1500
Promiscuous mode: enabled
Allmulticast mode: disabled
Maximum number of MAC addresses: 128
Maximum number of MAC addresses of hash filtering: 4096
VLAN offload:
   strip off, filter off, extend off, qinq strip off
Hash key size in bytes: 40
Redirection table size: 128
Supported RSS offload flow types:
   ipv4
   ipv4-tcp
   ipv4-udp
   ipv6
   ipv6-tcp
   ipv6-udp
   ipv6-ex
   ipv6-tcp-ex
   ipv6-udp-ex
Minimum size of RX buffer: 1024
Maximum configurable length of RX packet: 15872
Maximum configurable size of LRO aggregated packet: 0
Maximum number of VMDq pools: 64
Current number of RX queues: 1
Max possible RX queues: 128
Max possible number of RXDs per queue: 4096
Min possible number of RXDs per queue: 32
RXDs number alignment: 8
Current number of TX queues: 1
Max possible TX queues: 64
Max possible number of TXDs per queue: 4096
Min possible number of TXDs per queue: 32
TXDs number alignment: 8
Max segment number per packet: 40
Max segment number per MTU/TSO: 40
Device capabilities: 0x0( )
testpmd> # Cages now filled with 1G SFPs
testpmd> show port info all

********************* Infos for port 0  *********************
MAC address: 00:E0:ED:97:62:4D
Device name: 0000:20:00.0
Driver name: net_ixgbe
Firmware-version: 0x800000cb
Devargs:
Connect to socket: 0
memory allocation on the socket: 0
Link status: down
Link speed: None
Link duplex: half-duplex
Autoneg status: On
MTU: 1500
Promiscuous mode: enabled
Allmulticast mode: disabled
Maximum number of MAC addresses: 128
Maximum number of MAC addresses of hash filtering: 4096
VLAN offload:
   strip off, filter off, extend off, qinq strip off
Hash key size in bytes: 40
Redirection table size: 128
Supported RSS offload flow types:
   ipv4
   ipv4-tcp
   ipv4-udp
   ipv6
   ipv6-tcp
   ipv6-udp
   ipv6-ex
   ipv6-tcp-ex
   ipv6-udp-ex
Minimum size of RX buffer: 1024
Maximum configurable length of RX packet: 15872
Maximum configurable size of LRO aggregated packet: 0
Maximum number of VMDq pools: 64
Current number of RX queues: 1
Max possible RX queues: 128
Max possible number of RXDs per queue: 4096
Min possible number of RXDs per queue: 32
RXDs number alignment: 8
Current number of TX queues: 1
Max possible TX queues: 64
Max possible number of TXDs per queue: 4096
Min possible number of TXDs per queue: 32
TXDs number alignment: 8
Max segment number per packet: 40
Max segment number per MTU/TSO: 40
Device capabilities: 0x0( )

********************* Infos for port 1  *********************
MAC address: 00:E0:ED:97:62:4E
Device name: 0000:20:00.1
Driver name: net_ixgbe
Firmware-version: 0x800000cb
Devargs:
Connect to socket: 0
memory allocation on the socket: 0
Link status: down
Link speed: None
Link duplex: half-duplex
Autoneg status: On
MTU: 1500
Promiscuous mode: enabled
Allmulticast mode: disabled
Maximum number of MAC addresses: 128
Maximum number of MAC addresses of hash filtering: 4096
VLAN offload:
   strip off, filter off, extend off, qinq strip off
Hash key size in bytes: 40
Redirection table size: 128
Supported RSS offload flow types:
   ipv4
   ipv4-tcp
   ipv4-udp
   ipv6
   ipv6-tcp
   ipv6-udp
   ipv6-ex
   ipv6-tcp-ex
   ipv6-udp-ex
Minimum size of RX buffer: 1024
Maximum configurable length of RX packet: 15872
Maximum configurable size of LRO aggregated packet: 0
Maximum number of VMDq pools: 64
Current number of RX queues: 1
Max possible RX queues: 128
Max possible number of RXDs per queue: 4096
Min possible number of RXDs per queue: 32
RXDs number alignment: 8
Current number of TX queues: 1
Max possible TX queues: 64
Max possible number of TXDs per queue: 4096
Min possible number of TXDs per queue: 32
TXDs number alignment: 8
Max segment number per packet: 40
Max segment number per MTU/TSO: 40
Device capabilities: 0x0( )
testpmd> # No link detected if SFPs not present when testpmd launched, bug
testpmd> quit

Stopping port 0...
Stopping ports...
Done

Stopping port 1...
Stopping ports...
Done

Shutting down port 0...
Closing ports...
Port 0 is closed
Done

Shutting down port 1...
Closing ports...
Port 1 is closed
Done

Bye...
[root@madrid dpdk]# # Starting testpmd again with 1G SFPs already in cages
[root@madrid dpdk]# ./build/app/dpdk-testpmd --log-level *:info -c7 --vdev=0000:20:00.0 --vdev=0000:20:00.1 -- -i --nb-cores=2 --nb-ports=2 --total-num-mbufs=2048
EAL: Detected CPU lcores: 8
EAL: Detected NUMA nodes: 1
EAL: Detected static linkage of DPDK
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
EAL: Selected IOVA mode 'VA'
EAL: No available 1048576 kB hugepages reported
EAL: VFIO support initialized
EAL: Using IOMMU type 1 (Type 1)
EAL: Ignore mapping IO port bar(2)
EAL: Probe PCI driver: net_ixgbe (8086:10fb) device: 0000:20:00.0 (socket 0)
EAL: Ignore mapping IO port bar(2)
EAL: Probe PCI driver: net_ixgbe (8086:10fb) device: 0000:20:00.1 (socket 0)
Interactive-mode selected
testpmd: create a new mbuf pool <mb_pool_0>: n=2048, size=2176, socket=0
testpmd: preferred mempool ops selected: ring_mp_mc
Configuring Port 0 (socket 0)
ixgbe_dev_link_status_print():  Port 0: Link Down
Port 0: 00:E0:ED:97:62:4D
Configuring Port 1 (socket 0)
ixgbe_dev_link_status_print():  Port 1: Link Down
Port 1: 00:E0:ED:97:62:4E
Checking link statuses...
ixgbe_dev_link_status_print(): Port 1: Link Up - speed 1000 Mbps - full-duplex
ixgbe_dev_link_status_print(): Port 0: Link Up - speed 1000 Mbps - full-duplex
Done
testpmd> ixgbe_dev_link_status_print(): Port 1: Link Up - speed 1000 Mbps - full-duplex

Port 1: link state change event
ixgbe_dev_link_status_print(): Port 0: Link Up - speed 1000 Mbps - full-duplex

Port 0: link state change event

testpmd> # Link detected correctly for SFPs present on testpmd start
testpmd> show port info all

********************* Infos for port 0  *********************
MAC address: 00:E0:ED:97:62:4D
Device name: 0000:20:00.0
Driver name: net_ixgbe
Firmware-version: 0x800000cb
Devargs:
Connect to socket: 0
memory allocation on the socket: 0
Link status: up
Link speed: 1 Gbps
Link duplex: full-duplex
Autoneg status: On
MTU: 1500
Promiscuous mode: enabled
Allmulticast mode: disabled
Maximum number of MAC addresses: 128
Maximum number of MAC addresses of hash filtering: 4096
VLAN offload:
   strip off, filter off, extend off, qinq strip off
Hash key size in bytes: 40
Redirection table size: 128
Supported RSS offload flow types:
   ipv4
   ipv4-tcp
   ipv4-udp
   ipv6
   ipv6-tcp
   ipv6-udp
   ipv6-ex
   ipv6-tcp-ex
   ipv6-udp-ex
Minimum size of RX buffer: 1024
Maximum configurable length of RX packet: 15872
Maximum configurable size of LRO aggregated packet: 0
Maximum number of VMDq pools: 64
Current number of RX queues: 1
Max possible RX queues: 128
Max possible number of RXDs per queue: 4096
Min possible number of RXDs per queue: 32
RXDs number alignment: 8
Current number of TX queues: 1
Max possible TX queues: 64
Max possible number of TXDs per queue: 4096
Min possible number of TXDs per queue: 32
TXDs number alignment: 8
Max segment number per packet: 40
Max segment number per MTU/TSO: 40
Device capabilities: 0x0( )

********************* Infos for port 1  *********************
MAC address: 00:E0:ED:97:62:4E
Device name: 0000:20:00.1
Driver name: net_ixgbe
Firmware-version: 0x800000cb
Devargs:
Connect to socket: 0
memory allocation on the socket: 0
Link status: up
Link speed: 1 Gbps
Link duplex: full-duplex
Autoneg status: On
MTU: 1500
Promiscuous mode: enabled
Allmulticast mode: disabled
Maximum number of MAC addresses: 128
Maximum number of MAC addresses of hash filtering: 4096
VLAN offload:
   strip off, filter off, extend off, qinq strip off
Hash key size in bytes: 40
Redirection table size: 128
Supported RSS offload flow types:
   ipv4
   ipv4-tcp
   ipv4-udp
   ipv6
   ipv6-tcp
   ipv6-udp
   ipv6-ex
   ipv6-tcp-ex
   ipv6-udp-ex
Minimum size of RX buffer: 1024
Maximum configurable length of RX packet: 15872
Maximum configurable size of LRO aggregated packet: 0
Maximum number of VMDq pools: 64
Current number of RX queues: 1
Max possible RX queues: 128
Max possible number of RXDs per queue: 4096
Min possible number of RXDs per queue: 32
RXDs number alignment: 8
Current number of TX queues: 1
Max possible TX queues: 64
Max possible number of TXDs per queue: 4096
Min possible number of TXDs per queue: 32
TXDs number alignment: 8
Max segment number per packet: 40
Max segment number per MTU/TSO: 40
Device capabilities: 0x0( )
testpmd> # unplug/replug 1G SFPs
testpmd> ixgbe_dev_link_status_print():  Port 0: Link Down
ixgbe_dev_link_status_print():  Port 1: Link Down
ixgbe_dev_link_status_print():  Port 0: Link Down

Port 0: link state change event
ixgbe_dev_link_status_print():  Port 1: Link Down

Port 1: link state change event
ixgbe_dev_link_status_print(): Port 1: Link Up - speed 1000 Mbps - full-duplex
ixgbe_dev_link_status_print(): Port 0: Link Up - speed 1000 Mbps - full-duplex
ixgbe_dev_link_status_print(): Port 1: Link Up - speed 1000 Mbps - full-duplex

Port 1: link state change event
ixgbe_dev_link_status_print(): Port 0: Link Up - speed 1000 Mbps - full-duplex

Port 0: link state change event

testpmd> # Link back up at 1G after unplug/replug
testpmd> # Now swapping 1G SFPs for 10G SFPs
testpmd> ixgbe_dev_link_status_print():  Port 0: Link Down
ixgbe_dev_link_status_print():  Port 1: Link Down
ixgbe_dev_link_status_print():  Port 0: Link Down

Port 0: link state change event
ixgbe_dev_link_status_print():  Port 1: Link Down

Port 1: link state change event
ixgbe_dev_link_status_print(): Port 1: Link Up - speed 1000 Mbps - full-duplex
ixgbe_dev_link_status_print(): Port 0: Link Up - speed 1000 Mbps - full-duplex
ixgbe_dev_link_status_print(): Port 1: Link Up - speed 1000 Mbps - full-duplex

Port 1: link state change event
ixgbe_dev_link_status_print(): Port 0: Link Up - speed 1000 Mbps - full-duplex

Port 0: link state change event

testpmd> # Same bug, testpmd did not correctly ID and link at 10G, still at 1G
testpmd> show port info all

********************* Infos for port 0  *********************
MAC address: 00:E0:ED:97:62:4D
Device name: 0000:20:00.0
Driver name: net_ixgbe
Firmware-version: 0x800000cb
Devargs:
Connect to socket: 0
memory allocation on the socket: 0
Link status: up
Link speed: 1 Gbps
Link duplex: full-duplex
Autoneg status: On
MTU: 1500
Promiscuous mode: enabled
Allmulticast mode: disabled
Maximum number of MAC addresses: 128
Maximum number of MAC addresses of hash filtering: 4096
VLAN offload:
   strip off, filter off, extend off, qinq strip off
Hash key size in bytes: 40
Redirection table size: 128
Supported RSS offload flow types:
   ipv4
   ipv4-tcp
   ipv4-udp
   ipv6
   ipv6-tcp
   ipv6-udp
   ipv6-ex
   ipv6-tcp-ex
   ipv6-udp-ex
Minimum size of RX buffer: 1024
Maximum configurable length of RX packet: 15872
Maximum configurable size of LRO aggregated packet: 0
Maximum number of VMDq pools: 64
Current number of RX queues: 1
Max possible RX queues: 128
Max possible number of RXDs per queue: 4096
Min possible number of RXDs per queue: 32
RXDs number alignment: 8
Current number of TX queues: 1
Max possible TX queues: 64
Max possible number of TXDs per queue: 4096
Min possible number of TXDs per queue: 32
TXDs number alignment: 8
Max segment number per packet: 40
Max segment number per MTU/TSO: 40
Device capabilities: 0x0( )

********************* Infos for port 1  *********************
MAC address: 00:E0:ED:97:62:4E
Device name: 0000:20:00.1
Driver name: net_ixgbe
Firmware-version: 0x800000cb
Devargs:
Connect to socket: 0
memory allocation on the socket: 0
Link status: up
Link speed: 1 Gbps
Link duplex: full-duplex
Autoneg status: On
MTU: 1500
Promiscuous mode: enabled
Allmulticast mode: disabled
Maximum number of MAC addresses: 128
Maximum number of MAC addresses of hash filtering: 4096
VLAN offload:
   strip off, filter off, extend off, qinq strip off
Hash key size in bytes: 40
Redirection table size: 128
Supported RSS offload flow types:
   ipv4
   ipv4-tcp
   ipv4-udp
   ipv6
   ipv6-tcp
   ipv6-udp
   ipv6-ex
   ipv6-tcp-ex
   ipv6-udp-ex
Minimum size of RX buffer: 1024
Maximum configurable length of RX packet: 15872
Maximum configurable size of LRO aggregated packet: 0
Maximum number of VMDq pools: 64
Current number of RX queues: 1
Max possible RX queues: 128
Max possible number of RXDs per queue: 4096
Min possible number of RXDs per queue: 32
RXDs number alignment: 8
Current number of TX queues: 1
Max possible TX queues: 64
Max possible number of TXDs per queue: 4096
Min possible number of TXDs per queue: 32
TXDs number alignment: 8
Max segment number per packet: 40
Max segment number per MTU/TSO: 40
Device capabilities: 0x0( )
testpmd> # quit and restart testpmd with 10G SFPs already installed
testpmd> quit

Stopping port 0...
Stopping ports...
ixgbe_dev_link_status_print():  Port 1: Link Down
Done

Stopping port 1...
Stopping ports...
Done

Shutting down port 0...
Closing ports...
Port 0 is closed
Done

Shutting down port 1...
Closing ports...
Port 1 is closed
Done

Bye...
[root@madrid dpdk]# ./build/app/dpdk-testpmd --log-level *:info -c7 --vdev=0000:20:00.0 --vdev=0000:20:00.1 -- -i --nb-cores=2 --nb-ports=2 --total-num-mbufs=2048
EAL: Detected CPU lcores: 8
EAL: Detected NUMA nodes: 1
EAL: Detected static linkage of DPDK
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
EAL: Selected IOVA mode 'VA'
EAL: No available 1048576 kB hugepages reported
EAL: VFIO support initialized
EAL: Using IOMMU type 1 (Type 1)
EAL: Ignore mapping IO port bar(2)
EAL: Probe PCI driver: net_ixgbe (8086:10fb) device: 0000:20:00.0 (socket 0)
EAL: Ignore mapping IO port bar(2)
EAL: Probe PCI driver: net_ixgbe (8086:10fb) device: 0000:20:00.1 (socket 0)
Interactive-mode selected
testpmd: create a new mbuf pool <mb_pool_0>: n=2048, size=2176, socket=0
testpmd: preferred mempool ops selected: ring_mp_mc
Configuring Port 0 (socket 0)
ixgbe_dev_link_status_print():  Port 0: Link Down
Port 0: 00:E0:ED:97:62:4D
Configuring Port 1 (socket 0)
ixgbe_dev_link_status_print():  Port 1: Link Down
Port 1: 00:E0:ED:97:62:4E
Checking link statuses...
ixgbe_dev_link_status_print(): Port 1: Link Up - speed 10000 Mbps - full-duplex
ixgbe_dev_link_status_print(): Port 0: Link Up - speed 10000 Mbps - full-duplex
Done
testpmd> ixgbe_dev_link_status_print(): Port 1: Link Up - speed 10000 Mbps - full-duplex

Port 1: link state change event
ixgbe_dev_link_status_print(): Port 0: Link Up - speed 10000 Mbps - full-duplex

Port 0: link state change event

testpmd> # now linked correctly @ 10G
testpmd> show port info all

********************* Infos for port 0  *********************
MAC address: 00:E0:ED:97:62:4D
Device name: 0000:20:00.0
Driver name: net_ixgbe
Firmware-version: 0x800000cb
Devargs:
Connect to socket: 0
memory allocation on the socket: 0
Link status: up
Link speed: 10 Gbps
Link duplex: full-duplex
Autoneg status: On
MTU: 1500
Promiscuous mode: enabled
Allmulticast mode: disabled
Maximum number of MAC addresses: 128
Maximum number of MAC addresses of hash filtering: 4096
VLAN offload:
   strip off, filter off, extend off, qinq strip off
Hash key size in bytes: 40
Redirection table size: 128
Supported RSS offload flow types:
   ipv4
   ipv4-tcp
   ipv4-udp
   ipv6
   ipv6-tcp
   ipv6-udp
   ipv6-ex
   ipv6-tcp-ex
   ipv6-udp-ex
Minimum size of RX buffer: 1024
Maximum configurable length of RX packet: 15872
Maximum configurable size of LRO aggregated packet: 0
Maximum number of VMDq pools: 64
Current number of RX queues: 1
Max possible RX queues: 128
Max possible number of RXDs per queue: 4096
Min possible number of RXDs per queue: 32
RXDs number alignment: 8
Current number of TX queues: 1
Max possible TX queues: 64
Max possible number of TXDs per queue: 4096
Min possible number of TXDs per queue: 32
TXDs number alignment: 8
Max segment number per packet: 40
Max segment number per MTU/TSO: 40
Device capabilities: 0x0( )

********************* Infos for port 1  *********************
MAC address: 00:E0:ED:97:62:4E
Device name: 0000:20:00.1
Driver name: net_ixgbe
Firmware-version: 0x800000cb
Devargs:
Connect to socket: 0
memory allocation on the socket: 0
Link status: up
Link speed: 10 Gbps
Link duplex: full-duplex
Autoneg status: On
MTU: 1500
Promiscuous mode: enabled
Allmulticast mode: disabled
Maximum number of MAC addresses: 128
Maximum number of MAC addresses of hash filtering: 4096
VLAN offload:
   strip off, filter off, extend off, qinq strip off
Hash key size in bytes: 40
Redirection table size: 128
Supported RSS offload flow types:
   ipv4
   ipv4-tcp
   ipv4-udp
   ipv6
   ipv6-tcp
   ipv6-udp
   ipv6-ex
   ipv6-tcp-ex
   ipv6-udp-ex
Minimum size of RX buffer: 1024
Maximum configurable length of RX packet: 15872
Maximum configurable size of LRO aggregated packet: 0
Maximum number of VMDq pools: 64
Current number of RX queues: 1
Max possible RX queues: 128
Max possible number of RXDs per queue: 4096
Min possible number of RXDs per queue: 32
RXDs number alignment: 8
Current number of TX queues: 1
Max possible TX queues: 64
Max possible number of TXDs per queue: 4096
Min possible number of TXDs per queue: 32
TXDs number alignment: 8
Max segment number per packet: 40
Max segment number per MTU/TSO: 40
Device capabilities: 0x0( )
testpmd> # swap 10G SFPs for 1G, expect no link since they wont be IDed and setup for 1G, and cant handle 10G
testpmd> ixgbe_dev_link_status_print():  Port 0: Link Down
ixgbe_dev_link_status_print():  Port 1: Link Down
ixgbe_dev_link_status_print():  Port 0: Link Down

Port 0: link state change event
ixgbe_dev_link_status_print():  Port 1: Link Down

Port 1: link state change event

testpmd> # 1G SFPs now installed, and as expected, no link :(
testpmd> show port info all

********************* Infos for port 0  *********************
MAC address: 00:E0:ED:97:62:4D
Device name: 0000:20:00.0
Driver name: net_ixgbe
Firmware-version: 0x800000cb
Devargs:
Connect to socket: 0
memory allocation on the socket: 0
Link status: down
Link speed: None
Link duplex: half-duplex
Autoneg status: On
MTU: 1500
Promiscuous mode: enabled
Allmulticast mode: disabled
Maximum number of MAC addresses: 128
Maximum number of MAC addresses of hash filtering: 4096
VLAN offload:
   strip off, filter off, extend off, qinq strip off
Hash key size in bytes: 40
Redirection table size: 128
Supported RSS offload flow types:
   ipv4
   ipv4-tcp
   ipv4-udp
   ipv6
   ipv6-tcp
   ipv6-udp
   ipv6-ex
   ipv6-tcp-ex
   ipv6-udp-ex
Minimum size of RX buffer: 1024
Maximum configurable length of RX packet: 15872
Maximum configurable size of LRO aggregated packet: 0
Maximum number of VMDq pools: 64
Current number of RX queues: 1
Max possible RX queues: 128
Max possible number of RXDs per queue: 4096
Min possible number of RXDs per queue: 32
RXDs number alignment: 8
Current number of TX queues: 1
Max possible TX queues: 64
Max possible number of TXDs per queue: 4096
Min possible number of TXDs per queue: 32
TXDs number alignment: 8
Max segment number per packet: 40
Max segment number per MTU/TSO: 40
Device capabilities: 0x0( )

********************* Infos for port 1  *********************
MAC address: 00:E0:ED:97:62:4E
Device name: 0000:20:00.1
Driver name: net_ixgbe
Firmware-version: 0x800000cb
Devargs:
Connect to socket: 0
memory allocation on the socket: 0
Link status: down
Link speed: None
Link duplex: half-duplex
Autoneg status: On
MTU: 1500
Promiscuous mode: enabled
Allmulticast mode: disabled
Maximum number of MAC addresses: 128
Maximum number of MAC addresses of hash filtering: 4096
VLAN offload:
   strip off, filter off, extend off, qinq strip off
Hash key size in bytes: 40
Redirection table size: 128
Supported RSS offload flow types:
   ipv4
   ipv4-tcp
   ipv4-udp
   ipv6
   ipv6-tcp
   ipv6-udp
   ipv6-ex
   ipv6-tcp-ex
   ipv6-udp-ex
Minimum size of RX buffer: 1024
Maximum configurable length of RX packet: 15872
Maximum configurable size of LRO aggregated packet: 0
Maximum number of VMDq pools: 64
Current number of RX queues: 1
Max possible RX queues: 128
Max possible number of RXDs per queue: 4096
Min possible number of RXDs per queue: 32
RXDs number alignment: 8
Current number of TX queues: 1
Max possible TX queues: 64
Max possible number of TXDs per queue: 4096
Min possible number of TXDs per queue: 32
TXDs number alignment: 8
Max segment number per packet: 40
Max segment number per MTU/TSO: 40
Device capabilities: 0x0( )
testpmd> quit

Stopping port 0...
Stopping ports...
Done

Stopping port 1...
Stopping ports...
Done

Shutting down port 0...
Closing ports...
Port 0 is closed
Done

Shutting down port 1...
Closing ports...
Port 1 is closed
Done

Bye...
[root@madrid dpdk]# exit
Script done on 2021-12-22 11:32:00-05:00 [COMMAND_EXIT_CODE="0"]
Wang, Haiyue Dec. 23, 2021, 12:55 a.m. UTC | #11 
> -----Original Message-----
> From: Stephen Douthit <stephend@silicom-usa.com>
> Sent: Thursday, December 23, 2021 05:44
> To: Wang, Haiyue <haiyue.wang@intel.com>; Morten Brørup <mb@smartsharesystems.com>; Lu, Wenzhuo
> <wenzhuo.lu@intel.com>; Zhang, Helin <helin.zhang@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>
> Cc: dev@dpdk.org; Wang, Wen <wenw@silicom-usa.com>; stable@dpdk.org
> Subject: Re: [PATCH v2 3/7] net/ixgbe: Check that SFF-8472 soft rate select is supported before write
> 
> <snip>
> 


> Same. :)
> 
> Either way I'm hoping to be out for the rest of the year, so I'll
> revisit this January 3rd.
> 
> Happy holidays!

OK, let's see in 2022, happy holidays. ;-)

> 
> Thanks,
> Steve
> 

> 
> Bye...
> [root@madrid dpdk]# exit
> Script done on 2021-12-22 11:32:00-05:00 [COMMAND_EXIT_CODE="0"]
Stephen Douthit Jan. 18, 2022, 9:06 p.m. UTC | #12 
On 12/22/21 19:55, Wang, Haiyue wrote:
> OK, let's see in 2022, happy holidays. ;-)

A bit of a slower start to 2022 than I had hoped, but I have a v3 of the
hotplug fix in progress.  It's now working for the 82599 and C3000 ixgbe
devices under Linux, and I'm in the process of getting this built and
tested under FreeBSD.

Assuming the FreeBSD testing comes together smoothly my plan is to split
these patches into three series:

1) The SFP hotplug fix
2) Refactor SDP3 TX_DISABLE 82599 link check stuff
3) Support of additional SFP types under ixgbe

My focus right now is on the SFP hotplug fix, so please let me know if
there's any additional feedback on that portion of the original series.

Right now the feedback I have that impacts the hotplug fix is a cleanup
for patch 1, and the general comment that changes to files under
ixgbe/base are usually backported from Linux, and so I should refactor
my changes to live in ixgbe_ethdev.c

Thanks,
Steve
Wang, Haiyue Jan. 19, 2022, 12:31 a.m. UTC | #13 
> -----Original Message-----
> From: Stephen Douthit <stephend@silicom-usa.com>
> Sent: Wednesday, January 19, 2022 05:06
> To: Wang, Haiyue <haiyue.wang@intel.com>; Morten Brørup <mb@smartsharesystems.com>; Lu, Wenzhuo
> <wenzhuo.lu@intel.com>; Zhang, Helin <helin.zhang@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>
> Cc: dev@dpdk.org; Wang, Wen <wenw@silicom-usa.com>; stable@dpdk.org
> Subject: Re: [PATCH v2 3/7] net/ixgbe: Check that SFF-8472 soft rate select is supported before write
> 
> On 12/22/21 19:55, Wang, Haiyue wrote:
> > OK, let's see in 2022, happy holidays. ;-)
> 
> A bit of a slower start to 2022 than I had hoped, but I have a v3 of the
> hotplug fix in progress.  It's now working for the 82599 and C3000 ixgbe
> devices under Linux, and I'm in the process of getting this built and
> tested under FreeBSD.
> 
> Assuming the FreeBSD testing comes together smoothly my plan is to split
> these patches into three series:
> 
> 1) The SFP hotplug fix
> 2) Refactor SDP3 TX_DISABLE 82599 link check stuff
> 3) Support of additional SFP types under ixgbe
> 
> My focus right now is on the SFP hotplug fix, so please let me know if
> there's any additional feedback on that portion of the original series.
> 
> Right now the feedback I have that impacts the hotplug fix is a cleanup
> for patch 1, and the general comment that changes to files under
> ixgbe/base are usually backported from Linux, and so I should refactor
> my changes to live in ixgbe_ethdev.c

Yeah, just put the change in base code to *separate patch*, so that they are
easily to be reviewed, thanks.

> 
> Thanks,
> Steve
Ferruh Yigit Feb. 7, 2022, 4:04 p.m. UTC | #14 
On 1/19/2022 12:31 AM, Wang, Haiyue wrote:
>> -----Original Message-----
>> From: Stephen Douthit <stephend@silicom-usa.com>
>> Sent: Wednesday, January 19, 2022 05:06
>> To: Wang, Haiyue <haiyue.wang@intel.com>; Morten Brørup <mb@smartsharesystems.com>; Lu, Wenzhuo
>> <wenzhuo.lu@intel.com>; Zhang, Helin <helin.zhang@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>
>> Cc: dev@dpdk.org; Wang, Wen <wenw@silicom-usa.com>; stable@dpdk.org
>> Subject: Re: [PATCH v2 3/7] net/ixgbe: Check that SFF-8472 soft rate select is supported before write
>>
>> On 12/22/21 19:55, Wang, Haiyue wrote:
>>> OK, let's see in 2022, happy holidays. ;-)
>>
>> A bit of a slower start to 2022 than I had hoped, but I have a v3 of the
>> hotplug fix in progress.  It's now working for the 82599 and C3000 ixgbe
>> devices under Linux, and I'm in the process of getting this built and
>> tested under FreeBSD.
>>
>> Assuming the FreeBSD testing comes together smoothly my plan is to split
>> these patches into three series:
>>
>> 1) The SFP hotplug fix
>> 2) Refactor SDP3 TX_DISABLE 82599 link check stuff
>> 3) Support of additional SFP types under ixgbe
>>
>> My focus right now is on the SFP hotplug fix, so please let me know if
>> there's any additional feedback on that portion of the original series.
>>
>> Right now the feedback I have that impacts the hotplug fix is a cleanup
>> for patch 1, and the general comment that changes to files under
>> ixgbe/base are usually backported from Linux, and so I should refactor
>> my changes to live in ixgbe_ethdev.c
> 
> Yeah, just put the change in base code to *separate patch*, so that they are
> easily to be reviewed, thanks.
> 

Hi Steve, Wen, Haiyue,

Can you please clarify the above change request?

I though it is related to splitting base code updates into their own
patches, but that already seems the case in set (except from a few minor mix).

And what is the status, is there a new version worked on? Or is the
set waiting for more review?

Thanks,
ferruh
Jeff Daly Feb. 8, 2022, 1:50 p.m. UTC | #15 
Ferruh,
	Stephen has passed on support of his patches to me, I will be the main point of contact going forward.  I'm still ramping up on the code, expect patch updates to come from me in the future.

-----Original Message-----
From: Ferruh Yigit <ferruh.yigit@intel.com> 
Sent: Monday, February 7, 2022 11:04 AM
To: Wang, Haiyue <haiyue.wang@intel.com>; Stephen Douthit <stephend@silicom-usa.com>; Morten Brørup <mb@smartsharesystems.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>; Zhang, Helin <helin.zhang@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>
Cc: dev@dpdk.org; Wen Wang <wenw@silicom-usa.com>; stable@dpdk.org
Subject: Re: [PATCH v2 3/7] net/ixgbe: Check that SFF-8472 soft rate select is supported before write

Caution: This is an external email. Please take care when clicking links or opening attachments.


On 1/19/2022 12:31 AM, Wang, Haiyue wrote:
>> -----Original Message-----
>> From: Stephen Douthit <stephend@silicom-usa.com>
>> Sent: Wednesday, January 19, 2022 05:06
>> To: Wang, Haiyue <haiyue.wang@intel.com>; Morten Brørup 
>> <mb@smartsharesystems.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>; 
>> Zhang, Helin <helin.zhang@intel.com>; Zhang, Qi Z 
>> <qi.z.zhang@intel.com>
>> Cc: dev@dpdk.org; Wang, Wen <wenw@silicom-usa.com>; stable@dpdk.org
>> Subject: Re: [PATCH v2 3/7] net/ixgbe: Check that SFF-8472 soft rate 
>> select is supported before write
>>
>> On 12/22/21 19:55, Wang, Haiyue wrote:
>>> OK, let's see in 2022, happy holidays. ;-)
>>
>> A bit of a slower start to 2022 than I had hoped, but I have a v3 of 
>> the hotplug fix in progress.  It's now working for the 82599 and 
>> C3000 ixgbe devices under Linux, and I'm in the process of getting 
>> this built and tested under FreeBSD.
>>
>> Assuming the FreeBSD testing comes together smoothly my plan is to 
>> split these patches into three series:
>>
>> 1) The SFP hotplug fix
>> 2) Refactor SDP3 TX_DISABLE 82599 link check stuff
>> 3) Support of additional SFP types under ixgbe
>>
>> My focus right now is on the SFP hotplug fix, so please let me know 
>> if there's any additional feedback on that portion of the original series.
>>
>> Right now the feedback I have that impacts the hotplug fix is a 
>> cleanup for patch 1, and the general comment that changes to files 
>> under ixgbe/base are usually backported from Linux, and so I should 
>> refactor my changes to live in ixgbe_ethdev.c
>
> Yeah, just put the change in base code to *separate patch*, so that 
> they are easily to be reviewed, thanks.
>

Hi Steve, Wen, Haiyue,

Can you please clarify the above change request?

I though it is related to splitting base code updates into their own patches, but that already seems the case in set (except from a few minor mix).

And what is the status, is there a new version worked on? Or is the set waiting for more review?

Thanks,
ferruh
Ferruh Yigit Feb. 8, 2022, 2:52 p.m. UTC | #16 
On 2/8/2022 1:50 PM, Jeff Daly wrote:

moved response down, please don't top post.

> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> Sent: Monday, February 7, 2022 11:04 AM
> To: Wang, Haiyue <haiyue.wang@intel.com>; Stephen Douthit <stephend@silicom-usa.com>; Morten Brørup <mb@smartsharesystems.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>; Zhang, Helin <helin.zhang@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>
> Cc: dev@dpdk.org; Wen Wang <wenw@silicom-usa.com>; stable@dpdk.org
> Subject: Re: [PATCH v2 3/7] net/ixgbe: Check that SFF-8472 soft rate select is supported before write
> 
> Caution: This is an external email. Please take care when clicking links or opening attachments.
> 
> 
> On 1/19/2022 12:31 AM, Wang, Haiyue wrote:
>>> -----Original Message-----
>>> From: Stephen Douthit <stephend@silicom-usa.com>
>>> Sent: Wednesday, January 19, 2022 05:06
>>> To: Wang, Haiyue <haiyue.wang@intel.com>; Morten Brørup
>>> <mb@smartsharesystems.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>;
>>> Zhang, Helin <helin.zhang@intel.com>; Zhang, Qi Z
>>> <qi.z.zhang@intel.com>
>>> Cc: dev@dpdk.org; Wang, Wen <wenw@silicom-usa.com>; stable@dpdk.org
>>> Subject: Re: [PATCH v2 3/7] net/ixgbe: Check that SFF-8472 soft rate
>>> select is supported before write
>>>
>>> On 12/22/21 19:55, Wang, Haiyue wrote:
>>>> OK, let's see in 2022, happy holidays. ;-)
>>>
>>> A bit of a slower start to 2022 than I had hoped, but I have a v3 of
>>> the hotplug fix in progress.  It's now working for the 82599 and
>>> C3000 ixgbe devices under Linux, and I'm in the process of getting
>>> this built and tested under FreeBSD.
>>>
>>> Assuming the FreeBSD testing comes together smoothly my plan is to
>>> split these patches into three series:
>>>
>>> 1) The SFP hotplug fix
>>> 2) Refactor SDP3 TX_DISABLE 82599 link check stuff
>>> 3) Support of additional SFP types under ixgbe
>>>
>>> My focus right now is on the SFP hotplug fix, so please let me know
>>> if there's any additional feedback on that portion of the original series.
>>>
>>> Right now the feedback I have that impacts the hotplug fix is a
>>> cleanup for patch 1, and the general comment that changes to files
>>> under ixgbe/base are usually backported from Linux, and so I should
>>> refactor my changes to live in ixgbe_ethdev.c
>>
>> Yeah, just put the change in base code to *separate patch*, so that
>> they are easily to be reviewed, thanks.
>>
> 
> Hi Steve, Wen, Haiyue,
> 
> Can you please clarify the above change request?
> 
> I though it is related to splitting base code updates into their own patches, but that already seems the case in set (except from a few minor mix).
> 
> And what is the status, is there a new version worked on? Or is the set waiting for more review?
> 
> Ferruh,
> 	Stephen has passed on support of his patches to me, I will be the main point of contact going forward.  I'm still ramping up on the code, expect patch updates to come from me in the future.
> 

Hi Jeff,

What is the planned changes in the next version?

I just want to be sure that we are on same page with the change request,
to not waste effort/time.

Haiyue, perhaps can you articulate the request again?
Wang, Haiyue Feb. 9, 2022, 4 a.m. UTC | #17 
> -----Original Message-----
> From: Yigit, Ferruh <ferruh.yigit@intel.com>
> Sent: Tuesday, February 8, 2022 22:52
> To: Daly, Jeff <jeffd@silicom-usa.com>; Wang, Haiyue <haiyue.wang@intel.com>; Stephen Douthit
> <stephend@silicom-usa.com>; Morten Brørup <mb@smartsharesystems.com>; Lu, Wenzhuo
> <wenzhuo.lu@intel.com>; Zhang, Helin <helin.zhang@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>
> Cc: dev@dpdk.org; Wang, Wen <wenw@silicom-usa.com>; stable@dpdk.org
> Subject: Re: [PATCH v2 3/7] net/ixgbe: Check that SFF-8472 soft rate select is supported before write
> 
> On 2/8/2022 1:50 PM, Jeff Daly wrote:
> 
> moved response down, please don't top post.
> 
> > -----Original Message-----
> > From: Ferruh Yigit <ferruh.yigit@intel.com>
> > Sent: Monday, February 7, 2022 11:04 AM
> > To: Wang, Haiyue <haiyue.wang@intel.com>; Stephen Douthit <stephend@silicom-usa.com>; Morten Brørup
> <mb@smartsharesystems.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>; Zhang, Helin <helin.zhang@intel.com>;
> Zhang, Qi Z <qi.z.zhang@intel.com>
> > Cc: dev@dpdk.org; Wen Wang <wenw@silicom-usa.com>; stable@dpdk.org
> > Subject: Re: [PATCH v2 3/7] net/ixgbe: Check that SFF-8472 soft rate select is supported before
> write
> >
> > Caution: This is an external email. Please take care when clicking links or opening attachments.
> >
> >
> > On 1/19/2022 12:31 AM, Wang, Haiyue wrote:
> >>> -----Original Message-----
> >>> From: Stephen Douthit <stephend@silicom-usa.com>
> >>> Sent: Wednesday, January 19, 2022 05:06
> >>> To: Wang, Haiyue <haiyue.wang@intel.com>; Morten Brørup
> >>> <mb@smartsharesystems.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>;
> >>> Zhang, Helin <helin.zhang@intel.com>; Zhang, Qi Z
> >>> <qi.z.zhang@intel.com>
> >>> Cc: dev@dpdk.org; Wang, Wen <wenw@silicom-usa.com>; stable@dpdk.org
> >>> Subject: Re: [PATCH v2 3/7] net/ixgbe: Check that SFF-8472 soft rate
> >>> select is supported before write
> >>>
> >>> On 12/22/21 19:55, Wang, Haiyue wrote:
> >>>> OK, let's see in 2022, happy holidays. ;-)
> >>>
> >>> A bit of a slower start to 2022 than I had hoped, but I have a v3 of
> >>> the hotplug fix in progress.  It's now working for the 82599 and
> >>> C3000 ixgbe devices under Linux, and I'm in the process of getting
> >>> this built and tested under FreeBSD.
> >>>
> >>> Assuming the FreeBSD testing comes together smoothly my plan is to
> >>> split these patches into three series:
> >>>
> >>> 1) The SFP hotplug fix
> >>> 2) Refactor SDP3 TX_DISABLE 82599 link check stuff
> >>> 3) Support of additional SFP types under ixgbe
> >>>
> >>> My focus right now is on the SFP hotplug fix, so please let me know
> >>> if there's any additional feedback on that portion of the original series.
> >>>
> >>> Right now the feedback I have that impacts the hotplug fix is a
> >>> cleanup for patch 1, and the general comment that changes to files
> >>> under ixgbe/base are usually backported from Linux, and so I should
> >>> refactor my changes to live in ixgbe_ethdev.c
> >>
> >> Yeah, just put the change in base code to *separate patch*, so that
> >> they are easily to be reviewed, thanks.
> >>
> >
> > Hi Steve, Wen, Haiyue,
> >
> > Can you please clarify the above change request?
> >
> > I though it is related to splitting base code updates into their own patches, but that already seems
> the case in set (except from a few minor mix).
> >
> > And what is the status, is there a new version worked on? Or is the set waiting for more review?
> >
> > Ferruh,
> > 	Stephen has passed on support of his patches to me, I will be the main point of contact going
> forward.  I'm still ramping up on the code, expect patch updates to come from me in the future.
> >
> 
> Hi Jeff,
> 
> What is the planned changes in the next version?
> 
> I just want to be sure that we are on same page with the change request,
> to not waste effort/time.
> 
> Haiyue, perhaps can you articulate the request again?

Just put the change in base directory into separate patch (es), so that we can ask
different experts to review the patchset easily.

Thanks.
Ferruh Yigit Feb. 9, 2022, 1:33 p.m. UTC | #18 
On 2/9/2022 4:00 AM, Wang, Haiyue wrote:
>> -----Original Message-----
>> From: Yigit, Ferruh <ferruh.yigit@intel.com>
>> Sent: Tuesday, February 8, 2022 22:52
>> To: Daly, Jeff <jeffd@silicom-usa.com>; Wang, Haiyue <haiyue.wang@intel.com>; Stephen Douthit
>> <stephend@silicom-usa.com>; Morten Brørup <mb@smartsharesystems.com>; Lu, Wenzhuo
>> <wenzhuo.lu@intel.com>; Zhang, Helin <helin.zhang@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>
>> Cc: dev@dpdk.org; Wang, Wen <wenw@silicom-usa.com>; stable@dpdk.org
>> Subject: Re: [PATCH v2 3/7] net/ixgbe: Check that SFF-8472 soft rate select is supported before write
>>
>> On 2/8/2022 1:50 PM, Jeff Daly wrote:
>>
>> moved response down, please don't top post.
>>
>>> -----Original Message-----
>>> From: Ferruh Yigit <ferruh.yigit@intel.com>
>>> Sent: Monday, February 7, 2022 11:04 AM
>>> To: Wang, Haiyue <haiyue.wang@intel.com>; Stephen Douthit <stephend@silicom-usa.com>; Morten Brørup
>> <mb@smartsharesystems.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>; Zhang, Helin <helin.zhang@intel.com>;
>> Zhang, Qi Z <qi.z.zhang@intel.com>
>>> Cc: dev@dpdk.org; Wen Wang <wenw@silicom-usa.com>; stable@dpdk.org
>>> Subject: Re: [PATCH v2 3/7] net/ixgbe: Check that SFF-8472 soft rate select is supported before
>> write
>>>
>>> Caution: This is an external email. Please take care when clicking links or opening attachments.
>>>
>>>
>>> On 1/19/2022 12:31 AM, Wang, Haiyue wrote:
>>>>> -----Original Message-----
>>>>> From: Stephen Douthit <stephend@silicom-usa.com>
>>>>> Sent: Wednesday, January 19, 2022 05:06
>>>>> To: Wang, Haiyue <haiyue.wang@intel.com>; Morten Brørup
>>>>> <mb@smartsharesystems.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>;
>>>>> Zhang, Helin <helin.zhang@intel.com>; Zhang, Qi Z
>>>>> <qi.z.zhang@intel.com>
>>>>> Cc: dev@dpdk.org; Wang, Wen <wenw@silicom-usa.com>; stable@dpdk.org
>>>>> Subject: Re: [PATCH v2 3/7] net/ixgbe: Check that SFF-8472 soft rate
>>>>> select is supported before write
>>>>>
>>>>> On 12/22/21 19:55, Wang, Haiyue wrote:
>>>>>> OK, let's see in 2022, happy holidays. ;-)
>>>>>
>>>>> A bit of a slower start to 2022 than I had hoped, but I have a v3 of
>>>>> the hotplug fix in progress.  It's now working for the 82599 and
>>>>> C3000 ixgbe devices under Linux, and I'm in the process of getting
>>>>> this built and tested under FreeBSD.
>>>>>
>>>>> Assuming the FreeBSD testing comes together smoothly my plan is to
>>>>> split these patches into three series:
>>>>>
>>>>> 1) The SFP hotplug fix
>>>>> 2) Refactor SDP3 TX_DISABLE 82599 link check stuff
>>>>> 3) Support of additional SFP types under ixgbe
>>>>>
>>>>> My focus right now is on the SFP hotplug fix, so please let me know
>>>>> if there's any additional feedback on that portion of the original series.
>>>>>
>>>>> Right now the feedback I have that impacts the hotplug fix is a
>>>>> cleanup for patch 1, and the general comment that changes to files
>>>>> under ixgbe/base are usually backported from Linux, and so I should
>>>>> refactor my changes to live in ixgbe_ethdev.c
>>>>
>>>> Yeah, just put the change in base code to *separate patch*, so that
>>>> they are easily to be reviewed, thanks.
>>>>
>>>
>>> Hi Steve, Wen, Haiyue,
>>>
>>> Can you please clarify the above change request?
>>>
>>> I though it is related to splitting base code updates into their own patches, but that already seems
>> the case in set (except from a few minor mix).
>>>
>>> And what is the status, is there a new version worked on? Or is the set waiting for more review?
>>>
>>> Ferruh,
>>> 	Stephen has passed on support of his patches to me, I will be the main point of contact going
>> forward.  I'm still ramping up on the code, expect patch updates to come from me in the future.
>>>
>>
>> Hi Jeff,
>>
>> What is the planned changes in the next version?
>>
>> I just want to be sure that we are on same page with the change request,
>> to not waste effort/time.
>>
>> Haiyue, perhaps can you articulate the request again?
> 
> Just put the change in base directory into separate patch (es), so that we can ask
> different experts to review the patchset easily.
> 

That seems already the case, only two patch has mix and that is a little
(and related), can you please highlight the patches that requires split?
Wang, Haiyue Feb. 9, 2022, 1:43 p.m. UTC | #19 
> -----Original Message-----
> From: Yigit, Ferruh <ferruh.yigit@intel.com>
> Sent: Wednesday, February 9, 2022 21:33
> To: Wang, Haiyue <haiyue.wang@intel.com>; Daly, Jeff <jeffd@silicom-usa.com>; Stephen Douthit
> <stephend@silicom-usa.com>; Morten Brørup <mb@smartsharesystems.com>; Lu, Wenzhuo
> <wenzhuo.lu@intel.com>; Zhang, Helin <helin.zhang@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>
> Cc: dev@dpdk.org; Wang, Wen <wenw@silicom-usa.com>; stable@dpdk.org
> Subject: Re: [PATCH v2 3/7] net/ixgbe: Check that SFF-8472 soft rate select is supported before write
> 
> On 2/9/2022 4:00 AM, Wang, Haiyue wrote:
> >> -----Original Message-----
> >> From: Yigit, Ferruh <ferruh.yigit@intel.com>
> >> Sent: Tuesday, February 8, 2022 22:52
> >> To: Daly, Jeff <jeffd@silicom-usa.com>; Wang, Haiyue <haiyue.wang@intel.com>; Stephen Douthit
> >> <stephend@silicom-usa.com>; Morten Brørup <mb@smartsharesystems.com>; Lu, Wenzhuo
> >> <wenzhuo.lu@intel.com>; Zhang, Helin <helin.zhang@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>
> >> Cc: dev@dpdk.org; Wang, Wen <wenw@silicom-usa.com>; stable@dpdk.org
> >> Subject: Re: [PATCH v2 3/7] net/ixgbe: Check that SFF-8472 soft rate select is supported before
> write
> >>
> >> On 2/8/2022 1:50 PM, Jeff Daly wrote:
> >>
> >> moved response down, please don't top post.
> >>
> >>> -----Original Message-----
> >>> From: Ferruh Yigit <ferruh.yigit@intel.com>
> >>> Sent: Monday, February 7, 2022 11:04 AM
> >>> To: Wang, Haiyue <haiyue.wang@intel.com>; Stephen Douthit <stephend@silicom-usa.com>; Morten
> Brørup
> >> <mb@smartsharesystems.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>; Zhang, Helin
> <helin.zhang@intel.com>;
> >> Zhang, Qi Z <qi.z.zhang@intel.com>
> >>> Cc: dev@dpdk.org; Wen Wang <wenw@silicom-usa.com>; stable@dpdk.org
> >>> Subject: Re: [PATCH v2 3/7] net/ixgbe: Check that SFF-8472 soft rate select is supported before
> >> write
> >>>
> >>> Caution: This is an external email. Please take care when clicking links or opening attachments.
> >>>
> >>>
> >>> On 1/19/2022 12:31 AM, Wang, Haiyue wrote:
> >>>>> -----Original Message-----
> >>>>> From: Stephen Douthit <stephend@silicom-usa.com>
> >>>>> Sent: Wednesday, January 19, 2022 05:06
> >>>>> To: Wang, Haiyue <haiyue.wang@intel.com>; Morten Brørup
> >>>>> <mb@smartsharesystems.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>;
> >>>>> Zhang, Helin <helin.zhang@intel.com>; Zhang, Qi Z
> >>>>> <qi.z.zhang@intel.com>
> >>>>> Cc: dev@dpdk.org; Wang, Wen <wenw@silicom-usa.com>; stable@dpdk.org
> >>>>> Subject: Re: [PATCH v2 3/7] net/ixgbe: Check that SFF-8472 soft rate
> >>>>> select is supported before write
> >>>>>
> >>>>> On 12/22/21 19:55, Wang, Haiyue wrote:
> >>>>>> OK, let's see in 2022, happy holidays. ;-)
> >>>>>
> >>>>> A bit of a slower start to 2022 than I had hoped, but I have a v3 of
> >>>>> the hotplug fix in progress.  It's now working for the 82599 and
> >>>>> C3000 ixgbe devices under Linux, and I'm in the process of getting
> >>>>> this built and tested under FreeBSD.
> >>>>>
> >>>>> Assuming the FreeBSD testing comes together smoothly my plan is to
> >>>>> split these patches into three series:
> >>>>>
> >>>>> 1) The SFP hotplug fix
> >>>>> 2) Refactor SDP3 TX_DISABLE 82599 link check stuff
> >>>>> 3) Support of additional SFP types under ixgbe
> >>>>>
> >>>>> My focus right now is on the SFP hotplug fix, so please let me know
> >>>>> if there's any additional feedback on that portion of the original series.
> >>>>>
> >>>>> Right now the feedback I have that impacts the hotplug fix is a
> >>>>> cleanup for patch 1, and the general comment that changes to files
> >>>>> under ixgbe/base are usually backported from Linux, and so I should
> >>>>> refactor my changes to live in ixgbe_ethdev.c
> >>>>
> >>>> Yeah, just put the change in base code to *separate patch*, so that
> >>>> they are easily to be reviewed, thanks.
> >>>>
> >>>
> >>> Hi Steve, Wen, Haiyue,
> >>>
> >>> Can you please clarify the above change request?
> >>>
> >>> I though it is related to splitting base code updates into their own patches, but that already
> seems
> >> the case in set (except from a few minor mix).
> >>>
> >>> And what is the status, is there a new version worked on? Or is the set waiting for more review?
> >>>
> >>> Ferruh,
> >>> 	Stephen has passed on support of his patches to me, I will be the main point of contact going
> >> forward.  I'm still ramping up on the code, expect patch updates to come from me in the future.
> >>>
> >>
> >> Hi Jeff,
> >>
> >> What is the planned changes in the next version?
> >>
> >> I just want to be sure that we are on same page with the change request,
> >> to not waste effort/time.
> >>
> >> Haiyue, perhaps can you articulate the request again?
> >
> > Just put the change in base directory into separate patch (es), so that we can ask
> > different experts to review the patchset easily.
> >
> 
> That seems already the case, only two patch has mix and that is a little
> (and related), can you please highlight the patches that requires split?

Yes, two patches.

[v2,4/7] net/ixgbe: Run 82599 link status workaround only on affected devices
[v2,5/7] net/ixgbe: Fix SFP detection and linking on hotplug

And adding the "net/ixgbe/base:" prefix explicitly is better.
diff mbox series

Patch

diff --git a/drivers/net/ixgbe/base/ixgbe_common.c b/drivers/net/ixgbe/base/ixgbe_common.c
index 2764cf7cf1..3be1cc7fa2 100644
--- a/drivers/net/ixgbe/base/ixgbe_common.c
+++ b/drivers/net/ixgbe/base/ixgbe_common.c
@@ -5371,6 +5371,7 @@  s32 ixgbe_setup_mac_link_multispeed_fiber(struct ixgbe_hw *hw,
 void ixgbe_set_soft_rate_select_speed(struct ixgbe_hw *hw,
 					ixgbe_link_speed speed)
 {
+	enum ixgbe_sfp_cage_status sfp_cage_status;
 	s32 status;
 	u8 rs, eeprom_data;
 
@@ -5387,6 +5388,51 @@  void ixgbe_set_soft_rate_select_speed(struct ixgbe_hw *hw,
 		return;
 	}
 
+	/* Can't set rate on missing devices, skip all I2C access */
+	sfp_cage_status = ixgbe_check_sfp_cage(hw);
+	if (sfp_cage_status == IXGBE_SFP_CAGE_EMPTY ||
+	    sfp_cage_status == IXGBE_SFP_CAGE_NOCAGE) {
+		DEBUGOUT("No SFP\n");
+		return;
+	}
+
+	/* This only applies to SFF-8472 devices, so check that this device has
+	 * a non-zero SFF8472 compliance code @ device 0xA0 byte 94
+	 */
+	status = hw->phy.ops.read_i2c_eeprom(hw,
+					     IXGBE_SFF_SFF_8472_COMP,
+					     &eeprom_data);
+	if (status || !eeprom_data) {
+		DEBUGOUT("Not a SFF-8472 device\n");
+		goto out;
+	}
+
+	/* (read|write)_i2c_byte() don't support the address change mechanism
+	 * outlined in section 8.9 "Addressing Modes" of SFF_8472, so if that
+	 * is a requirement give up
+	 */
+	status = hw->phy.ops.read_i2c_eeprom(hw,
+					     IXGBE_SFF_SFF_8472_SWAP,
+					     &eeprom_data);
+	if (status || (eeprom_data & IXGBE_SFF_ADDRESSING_MODE)) {
+		DEBUGOUT("Address change not supported\n");
+		goto out;
+	}
+	/* Digital diagnostic monitoring must be supported for rate select */
+	if (!(eeprom_data & IXGBE_SFF_DDM_IMPLEMENTED)) {
+		DEBUGOUT("DDM not implemented\n");
+		goto out;
+	}
+
+	/* Finally check if the optional rate select feature is implemented */
+	status = hw->phy.ops.read_i2c_eeprom(hw,
+					     IXGBE_SFF_SFF_8472_EOPT,
+					     &eeprom_data);
+	if (status || !(eeprom_data & IXGBE_SFF_HAVE_RS)) {
+		DEBUGOUT("Rate select not supported");
+		goto out;
+	}
+
 	/* Set RS0 */
 	status = hw->phy.ops.read_i2c_byte(hw, IXGBE_SFF_SFF_8472_OSCB,
 					   IXGBE_I2C_EEPROM_DEV_ADDR2,
diff --git a/drivers/net/ixgbe/base/ixgbe_phy.h b/drivers/net/ixgbe/base/ixgbe_phy.h
index ceefbb3e68..cd57ce040f 100644
--- a/drivers/net/ixgbe/base/ixgbe_phy.h
+++ b/drivers/net/ixgbe/base/ixgbe_phy.h
@@ -21,6 +21,7 @@ 
 #define IXGBE_SFF_CABLE_TECHNOLOGY	0x8
 #define IXGBE_SFF_CABLE_SPEC_COMP	0x3C
 #define IXGBE_SFF_SFF_8472_SWAP		0x5C
+#define IXGBE_SFF_SFF_8472_EOPT		0x5D
 #define IXGBE_SFF_SFF_8472_COMP		0x5E
 #define IXGBE_SFF_SFF_8472_OSCB		0x6E
 #define IXGBE_SFF_SFF_8472_ESCB		0x76
@@ -48,6 +49,8 @@ 
 #define IXGBE_SFF_SOFT_RS_SELECT_10G	0x8
 #define IXGBE_SFF_SOFT_RS_SELECT_1G	0x0
 #define IXGBE_SFF_ADDRESSING_MODE	0x4
+#define IXGBE_SFF_DDM_IMPLEMENTED	0x40
+#define IXGBE_SFF_HAVE_RS		0x2
 #define IXGBE_SFF_QSFP_DA_ACTIVE_CABLE	0x1
 #define IXGBE_SFF_QSFP_DA_PASSIVE_CABLE	0x8
 #define IXGBE_SFF_QSFP_CONNECTOR_NOT_SEPARABLE	0x23