[dpdk-dev] [PATCH] net/ixgbe: support detection of hot swapped SFP/SFP+

Srinivasan J srinidpdk at gmail.com
Fri May 19 12:04:55 CEST 2017


Hi Wei,
          Yes the changes are in ixgbe_dev_start( ),  the patch shows
the function as eth_ixgbevf_pci_remove() probably due to the way diff
recognizes the change. I have tested the change using Intel
Corporation 82599ES.

Thanks,
Srini

On Tue, May 16, 2017 at 9:04 AM, Dai, Wei <wei.dai at intel.com> wrote:
> Hi, Srini
>
> There is a bit confusion. Your patch shows that your code is added into the function eth_ixgbevf_pci_remove( ).
> But it is not. It is added into the fucntion ixgbe_dev_start( ), right ?
> So would you please rebase it to R 17.05 ?
>
> Which type of ixgbe device id did you tested ?
>
> There are many MAC types with different device id.
>
> The function ixgbe_pf_reset_hw(hw) is called before your adding code.
> ixgbe_pf_reset_hw() calls hw->mac.ops.reset_hw( ) which may points to following different function for different MAC type.
> Ixgbe_reset_hw_82598( ) calls hw->phy.ops.init(hw) if hw->phy.reset_disable == false .
> Ixgbe_reset_hw_82599( ) calls hw->phy.ops.init(hw) unconditionally.
> ixgbe_reset_hw_X540( ) doesn't' call pw->phy.ops.init(hw). For X540,  hw->phy.ops.init points to ixgbe_init_phy_ops_generic() which only initialize some function pointers.
> Ixgbe_rest_hw_x550em() calls hw->phy.ops.init(hw) unconditionally.
>
> And for VF,  ixgbe_reset_hw_vf( ) and ixgbevf_hv_reset_hw_vf( ) don't call hw->phy.ops.init(hw) anywhere.
>
> Thanks & Best Regards
> -Wei
>
>> -----Original Message-----
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
>> Sent: Sunday, May 7, 2017 6:36 AM
>> To: Srinivasan J <srinidpdk at gmail.com>
>> Cc: dev at dpdk.org; Lu, Wenzhuo <wenzhuo.lu at intel.com>; Ananyev,
>> Konstantin <konstantin.ananyev at intel.com>
>> Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: support detection of hot swapped
>> SFP/SFP+
>>
>> 06/05/2017 15:51, Srinivasan J:
>> > Hi,
>> >                    Do we need an explicit "Acked-by" keyword for this
>> > patch to be accepted and applied?
>>
>> Yes, given it is not a trivial patch, an ack from the maintainer is required.
>> Anyway, it has been submitted too late for 17.05 testing.


More information about the dev mailing list