On Thu, Mar 29, 2018 at 10:35 PM, Ran Shalit <ransha...@gmail.com> wrote: > On Fri, Mar 30, 2018 at 12:34 AM, Ran Shalit <ransha...@gmail.com> wrote: >> On Thu, Mar 29, 2018 at 9:36 PM, Alexander Duyck >> <alexander.du...@gmail.com> wrote: >>> On Thu, Mar 29, 2018 at 11:18 AM, Ran Shalit <ransha...@gmail.com> wrote: >>>> On Thu, Mar 29, 2018 at 8:52 PM, Alexander Duyck >>>> <alexander.du...@gmail.com> wrote: >>>>> On Thu, Mar 29, 2018 at 7:45 AM, Ran Shalit <ransha...@gmail.com> wrote: >>>>>> On Tue, Mar 27, 2018 at 11:43 PM, Alexander Duyck >>>>>> <alexander.du...@gmail.com> wrote: >>>>>>> On Tue, Mar 27, 2018 at 1:52 AM, Ran Shalit <ransha...@gmail.com> wrote: >>>>>>>> On Thu, Mar 22, 2018 at 7:31 PM, Alexander Duyck >>>>>>>> <alexander.du...@gmail.com> wrote: >>>>>>>>> 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. >>>>>>>>> >>>>>>>> >>>>>>>> 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. >>>>>>> >>>>>> >>>>>> >>>>>> I've added start/stop log in main igb functions. >>>>>> I can now see things more clearly. >>>>>> please see the attached log below, >>>>>> It seems that igb_watchdog is responsible somehow for waking up and >>>>>> checking things, before deciding that link is up. >>>>>> Maybe there is a way to call it higher rate ? >>>>> >>>>> When the link state changes it is triggered via an interrupt. The time >>>>> was about 3.5s to bring up link here if I am understanding correctly. >>>>> The other issue I see in your test is I am guessing you aren't pinging >>>>> something with a static ARP entry which is another cause for delay in >>>>> your test. >>>>> >>>>> One other thing you might try doing to shave time off of link training >>>>> is to disable mdix via ethtool "ethtool -s <ethX> mdix off" and see if >>>>> that saves you any time. It might shave maybe about .5 seconds off of >>>>> the total link time. >>>>> >>>>> If you are wanting it to link faster maybe you should look at using >>>>> something besides 1000BaseT. Typically about 3 to 4 seconds is about >>>>> the limit for Gigabit copper. You may wan to look at a device with a >>>>> different PHY if you require a faster link time. For example for >>>>> automotive applications something like 1000BaseT1 >>>>> (https://standards.ieee.org/events/automotive/2016/d1_09_tan_1000base_t1_learning_and_next_gen_use_cases_v6.pdf) >>>>> is supposed to be the intended way to go with link times in the >>>>> sub-200ms range. >>>>> >>>>> - Alex >>>> >>>> I will check your interesting suggestions. >>>> Do you think it might help to start igb and networking earlier ? >>> >>> No. >>> >>>> I see in dmesg log that igb starts late in kernel boot, even when I >>>> add ip=... in bootargs instead of using the init.d script (which calls >>>> ifup). >>> >>> You need enough of the basics up that 2 seconds is pretty reasonable. > > > I would like to add another very interesting result I got: > disabling auto-negotiation did not reduce time, and I disabled start > networking in init.d (S40network , ifup) > and started the network instead with bootargs (ip=10.0.0.2:....) > > Is there any reason for this dependency of these methods in each other ? > > Best Regards, > ranran
So as they say "it takes two to tango". You are controlling one end of the link. What is the other end of the link configured for currently? If it is set to auto-negotiate or do stuff like automdix that will add time to link establishment. I'm not sure what you are talking about in regards to dependencies. If you are asking why the network has to be running in order to configure a network interface I would think that is kind of obvious. Thanks. - 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
