Sorry for the slow replay, I'm currently at a conference so I'm not getting to my email as fast as I would like.
I'll try to answer some of your questions below: Hope this helps. Thanks, Don Skidmore <[email protected]> > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Tuesday, March 12, 2013 7:36 PM > To: Skidmore, Donald C > Cc: Waskiewicz Jr, Peter P; [email protected]; Tantilov, Emil S > Subject: Re: ixgbe for 82599, how to disable autoneg? > > Thank you for the info so far. > > Just to give a little more specifics on my application ... The ATTO NS12 NIC > has > two SFP+ interfaces. It uses an 82599EB ethernet controller. We are using > Finisar dual rate 1G/10G SFP+ single mode modules. We have two > computers, each with an NS12. We are are creating one 1G link and one 10G > link between the computers. I was already using ethtool to restrict the > advertised rate to 1G for one port and 10G for the other port. So it sounds > like I was already doing all that was possible to configure things so the > links > will come up as fast as possible except the option of disabling laser > functions > that was mentioned? What are the tradeoffs in disabling laser functions? How I thought that might help was that the driver would let the PHY attempt to get link in probe as well as not drop link on an ifconfig down. That way you might have link by the time you needed it later when you do a ifconfig up. There are some non-trivial side effects. Like not being able to auto try link speed for one. There would be ways around this (i.e. allow the laser disable to happen in some places just not drive up and down) but I figured the more blunt approach of just disabling them out right would at least show you if it would help at all. > > The links between the two computers include experimental wireless > segments which is where the 100 msec latency in each direction comes from. > From an ethernet point of view, the ethernet link is from one NIC to the > other NIC. We went thought a lot of tuning to get all the link speed code working forcing a 100 msec delay in there could very well be causing issues there. Is there any way you could allow the link to go up when you connect to the wireless link as appose to when the wireless gets link itself. That is if I understand what you're doing correctly. :) > > It would be very helpful to have a clear understanding of exactly what is > required to establish a solid link light. As I have mentioned, sometimes it > can > take a while to get a link light. Also, if we encounter non-ideal conditions > on > the wireless segment such as non-zero BER, the NIC link light will flicker. > Please let me know if there is a mode of operation of the > 82599 with SFP+ modules that would best tolerate these harsh conditions. > Also, please let me know if there is a limit to the latency that can exist > between the two NICs and still be able to establish an ethernet link. The real issue is that the PHY is doing most of the work here; you can look through the code where we set it into motion. The function ixgbe_start_mac_link_82599() would be a good place to start. As far as what you could do about the link flap. The driver could ignore lsc for a few seconds after link up assuming they are just flap. The driver currently does something like this look at ixgbe_watchdog_update_link() for some examples. > > Skidmore, Donald C writes: > > > > > > >> -----Original Message----- > >> From: Waskiewicz Jr, Peter P [mailto:[email protected]] > >> Sent: Monday, March 11, 2013 10:19 PM > >> To: [email protected] > >> Cc: [email protected]; Tantilov, Emil S > >> Subject: Re: [E1000-devel] ixgbe for 82599, how to disable autoneg? > >> > >> On 3/11/2013 8:38 PM, [email protected] wrote: > >> > My understanding is that this does not disable auto-negotiation but > >> > rather just sets what is advertised during auto-negotiation as > >> > supported > >> rates. > >> > > >> > We are working with an rather odd experimental system where we are > >> > trying to create a 10G link between two 82599 based NICs (ATTO > >> > FastFrame NS12 with dual SFP+ modules) over an optical link with > >> > 100 msec of latency in each direction. We are experiencing long > >> > delays in getting a link light that we believe is related to auto- > negotiation. > >> > We would like to try running without auto-negotiation. It appears > >> > the > >> > 82599 controller supports, so > >> > > >> > Does the 82599 support 1GbE and 10GbE via SFP+ without auto- > >> negotiation? > >> > > >> > I was hoping to get some guidance on how to go about modifying the > >> > ixgbe driver so that I can try 1G and 10G without auto-negotiation. > >> > >> Ah, so you're using dual-speed optics. What you're referring to > >> isn't auto- negotiation per se, it's what we call Smart Speed. Since > >> 10G fiber doesn't have a speed auto-negotiation via spec, we came up > >> with this algorithm to do the speed detection and downshift. > >> > >> I would search the code (ixgbe_82599.c for example) and set > >> smart_speed in the PHY struct to smart_speed_off when in the case of > multispeed_fiber. > >> > >> Hope this helps, > >> -PJ > >> > > > > Smartspeed may well be causing some latency but it would only come into > play on a backplane device. And since you mentioned SFP+ it leads me to > believe that you're not on one. PJ point was very valid however in that 10G > doesn't do autoneg for say. For multi-speed fiber we instead "try" all the > speeds that you have advertised (like Emil mentioned before). So in the case > of 0x1020 (10G and 1G) we will try 10G - 1G - 10G. So this could well be > causing latency on your 1G connection if we first attempt a 10G. You could > prevent this by only advertising the speed you want to connect to likewise > have your peer do the same. > > > > Now from your example code you sent I don't believe would work, once > again I'm assuming you are using SFP+ fiber. If that is the case your example > was using KX and KX4 which I don't believe would work. > > > > If you are only worried about getting link light up faster and don't care > about auto try, you could also disable the laser functions in > ixgbe_init_mac_link_ops_82599() much like we do if MNG FW is running. > Then the link would turn on (assuming we could get link) in probe and not > turn off with a 'ifconfig down'. > > > > Thanks, > > Don Skidmore <[email protected]> > ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ E1000-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
