Re: [E1000-devel] disable igb auto-negotiation

[Ran S. <ran...@gm...>]

On Tue, Mar 27, 2018 at 11:43 PM, Alexander Duyck
<ale...@gm...> wrote:
> On Tue, Mar 27, 2018 at 1:52 AM, Ran Shalit <ran...@gm...> wrote:
>> On Thu, Mar 22, 2018 at 7:31 PM, Alexander Duyck
>> <ale...@gm...> wrote:
>>> On Thu, Mar 22, 2018 at 9:11 AM, Ran Shalit <ran...@gm...> wrote:
>>>> On Mon, Mar 19, 2018 at 10:23 PM, Alexander Duyck
>>>> <ale...@gm...> wrote:
>>>>> On Mon, Mar 19, 2018 at 12:31 PM, Ran Shalit <ran...@gm...> wrote:
>>>>>> On Mon, Mar 19, 2018 at 6:27 PM, Alexander Duyck
>>>>>> <ale...@gm...> wrote:
>>>>>>> On Mon, Mar 19, 2018 at 9:07 AM, Ran Shalit <ran...@gm...> wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I am using igb driver:
>>>>>>>>
>>>>>>>> cat output/build/linux-4.10.17/.config | grep IGB
>>>>>>>>
>>>>>>>> CONFIG_IGB=y
>>>>>>>>
>>>>>>>> CONFIG_IGB_HWMON=y
>>>>>>>>
>>>>>>>> CONFIG_IGBVF=y
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> But every boot is takes a lot of time till ethernet is ready.
>>>>>>>>
>>>>>>>> I try to disable auto negotiation, but nothing helps yet, the device
>>>>>>>> resist, and keep resets phy.
>>>>>>>>
>>>>>>>> adapter->fc_autoneg = false;
>>>>>>>>
>>>>>>>> hw->mac.autoneg = false;
>>>>>>>>
>>>>>>>> hw->phy.autoneg_advertised = 0;
>>>>>>>>
>>>>>>>>
>>>>>>>> I tried more flags, but nothing helps.
>>>>>>>> The phy always disabled/reset at boot (led is off for 1 second and then on).
>>>>>>>>
>>>>>>>> Is there a way to disable auto-negotiation with igb driver ?
>>>>>>>> I use buildroot with kernel 4.10.81.
>>>>>>>>
>>>>>>>>
>>>>>>>> Thank you for any suggestion,
>>>>>>>>
>>>>>>>> ran
>>>>>>>
>>>>>>> Instead of trying to disable it in the driver why not just change your
>>>>>>> system configuration to disable it? You should be able to configure
>>>>>>> things in either Network Manager, or via the network init scripts so
>>>>>>> that you instead just used a forced speed/duplex combination. If
>>>>>>> nothing else you can go through and drop support for any other
>>>>>>> advertised speed/duplex and that should improve the speed of autoneg
>>>>>>> itself.
>>>>>>>
>>>>>>
>>>>>> I think I tried it and it did not work, but I shall try again.
>>>>>> Where should I put it ? in init.d startup scripts ?
>>>>>> I think I tried, and yet , I have seen that in reset, the leds of the
>>>>>> phy are always turned off for a ~1.5 second and then on again.
>>>>>> This is actually what I am trying to overcome, this strange reset of
>>>>>> phy every powerup.
>>>>>
>>>>> So it sounds like what you may want to disable would not be the phy
>>>>> autoneg, but the phy reset itself. If that is what you are looking for
>>>>> then you might try modifying igb_reset_phy, or at least when we invoke
>>>>> it in igb_power_up_link. You could look at adding a private flag to
>>>>> the igb driver to disable it for your use case if that is the issue.
>>>>>
>>>>>>> You could refer to something like this for more information:
>>>>>>> https://www.shellhacks.com/change-speed-duplex-ethernet-card-linux/
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> - Alex
>>>>>>
>>>>>> Thank you very much,
>>>>>> ran
>>>>>
>>>>> Now I am not so certain if this will solve you issue. What you may
>>>>> want to do instead is take a look at the function igb_power_up_link in
>>>>> igb_main.c and possibly consider adding a flag check to allow you to
>>>>> disable it on the systems you need to disable it on, or if this is for
>>>>> just one driver you could comment the line out and see if that will
>>>>> solve the issue.
>>>>>
>>>>
>>>> Using dmesg to understand what's going on , I see 2 things:
>>>> 1. Long time interval between opening and link up (5.0 - 1.9 = ~3seconds !)
>>>
>>> For a 1G link 3 seconds isn't all that long.
>>>
>>>> 2. Long time interval between link up state and ping success ( 8 - 5 =
>>>> ~3 sedconds !)
>>>
>>> I don't know what to tell you about that part. I suspect that may be
>>> some delays in notifiers being processed after the interface has
>>> reported link up. In addition I don't know what you link partner is.
>>> Normally for a ping you have to take care of things like setting up
>>> routes, getting an ARP out to find your target, and then sending the
>>> ping to that address.
>>>
>>> What might be interesting would be to add a dump of the tx_buffer_info
>>> data for the rings that have transmitted packets. For example we might
>>> have reported link up, but the link partner may not have been
>>> responding to us because it wasn't.
>>>
>>
>> Hi Alexander,
>>
>> Is there a way to open this dump with compilation flag ? How to dump
>> this information ?
>> This time interval (from igb probe to link up) is now is the major
>> delay (we solved the other time to ping).
>>
>> Thanks,
>> ranran
>
> Actually it can be turned on dynamically to some extend. The code to
> dump the Tx descriptor information is in a function called igb_dump in
> the driver. To turn on the bits related to dumping Tx packets you
> would need to use:
> ethtool -s <ethX> msglvl hw on
> ethtool -s <ethX> msglvl tx_done on
> ethtool -s <ethX> msglvl pktdata on
>
> Then it is just a matter of triggering a call to the reset task. There
> are a few ways to get there. If nothing else you might modify the
> driver to call igb_dump() at the start of the igb_close() function.
> Then all you would have to do is bring down the interface with
> something like an ifconfig <ethX> down and that should trigger the
> dump of the Tx descriptor data.
>
> - Alex

Hi Alex,

I've dumped the tx descriptors here:
https://drive.google.com/file/d/1OaP4rTT4TF8fcFTerVRosUihJDoAgeDz/view?usp=sharing

Do you think it can explain the long boot time till link is up  ?

Thank you,
ranran