On Thu, Mar 22, 2018 at 9:11 AM, Ran Shalit <ransha...@gmail.com> wrote: > On Mon, Mar 19, 2018 at 10:23 PM, Alexander Duyck > <alexander.du...@gmail.com> wrote: >> On Mon, Mar 19, 2018 at 12:31 PM, Ran Shalit <ransha...@gmail.com> wrote: >>> On Mon, Mar 19, 2018 at 6:27 PM, Alexander Duyck >>> <alexander.du...@gmail.com> wrote: >>>> On Mon, Mar 19, 2018 at 9:07 AM, Ran Shalit <ransha...@gmail.com> 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. > # dmesg | grep > [ 1.897306] igb_init_module > [ 1.897309] igb: Intel(R) Gigabit Ethernet Network Driver << - > version 5.4.0-k > [ 1.897310] igb: Copyright (c) 2007-2014 Intel Corporation. << > [ 1.897338] igb_probe > [ 1.897728] igb_sw_init > [ 1.908895] igb_reset > [ 1.923042] igb_power_down_link > [ 1.926740] Starting network: > [ 1.944956] __igb_open > [ 1.945005] igb_power_up_link > [ 5.043281] igb 0000:03:00.0 eth0: igb: eth0 NIC Link is Up 1000 > Mbps Full Duplex, Flow Control: RX > [ 7.966910] ping success ok 0 > > Is there any possible reason for this 2 long intervals in IGB driver ? > > Thanks, > ranran These intervals aren't all that long. You have to realize we are trying to put together a digital signal that goes over electrical link. Setting all of that up takes time. The only way to short-cut that would be to have the link up before we start, and by default the link is normally at the lowest possible negotiated speed at power on in order to save on power consumption since it is assumed to only be needed to handle wake-on-lan events. - Alex ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
