>-----Original Message----- >From: Scott Silverman >[mailto:[email protected]] >Sent: Tuesday, April 08, 2014 2:10 PM >To: Tantilov, Emil S >Cc: [email protected] >Subject: Re: [E1000-devel] ixgbe causes slow ioctl / breaks >net-snmp, ifconfig, ip > >I believe that the NET-SNMP agent ends up reading it in a >loop as it gathers statistics, but I don't know how I would confirm >that.
Certain statistics make sense to collect in a short period of time - like Tx/Rx bytes to get a good representation of the throughput, but in this case net-snmp is reading mostly static info (unless it tries to determine the link state somehow). What is worse is that if not cached some of that info comes from HW reads and those are slow and expensive (lock happy). > >If the cache timeout for NET-SNMP's statistics is lower than >the time it takes for one read, then NET-SNMP hangs until the driver >module is unloaded. The time seems to be in the 1-2 second range (1 >second always triggers it, 2 seconds sometimes does). You can try and increase the read interval net-snmp is using for this type of data and see if this would help. Either way I'll try to fix this somehow since it can be abused by user space. Thanks, Emil > > > > >Thanks, > >Scott Silverman | IT | Simplex Investments | 312-360-2444 >230 S. LaSalle St., Suite 4-100, Chicago, IL 60604 > > >On Tue, Apr 8, 2014 at 11:55 AM, Tantilov, Emil S ><[email protected] >> wrote: > >> >-----Original Message----- >> >From: "Oleg A. Arkhangelsky" [mailto:[email protected]] >> >Sent: Monday, April 07, 2014 9:57 PM >> >To: Scott Silverman; [email protected] >> >Subject: Re: [E1000-devel] ixgbe causes slow ioctl / >breaks >> >net-snmp, ifconfig, ip >> > >> > >> > >> >05.04.2014, 01:25, "Scott Silverman" >> ><[email protected]>: >> > >> >> CentOS 6.5, kernel 3.4.41 or 3.4.86, NET-SNMP 5.5 (from >CentOS6.5 repo) >> >> ixgbe 3.19.1 / 3.21.2: Once loaded, net-snmp stops >responding, and >> normal >> >> ioctls (ifconfig, ip addr, or my own code, I think just >SIOCETHTOOL) >> take a >> >> long time (1s+) to complete. >> > >> >Trying reading EEPROM is a bit slow on non-populated SFP+ >ports. >> Everything >> >will fine if you populate all 82599 ports with >transceivers or revert >> this: >> > >> >http://permalink.gmane.org/gmane.linux.network/283634 >> > >> >But I think we need some kind of better solution. >> >> The i2c reads are slow if you don't have an SFP module in >the cage. >> >> If you revert this patch then the info you get maybe >incorrect - that is >> the purpose of this fix. >> >> I wonder though if you are seeing long delays that means >that something is >> calling ixgbe_get_settings in a loop? That seems like a >bad idea. >> >> I can look into reducing the occurrence of the call, but >because the SFP >> modules are pluggable we'll need to read the data >eventually. >> >> Thanks, >> Emil >> >> > >> >-- >> >wbr, Oleg. >> > >> >"Anarchy is about taking complete responsibility for >> >yourself." >> > Alan Moore. >> > >> >--------------------------------------------------------- >--- >> >------------------ >> >Put Bad Developers to Shame >> >Dominate Development with Jenkins Continuous Integration >> >Continuously Automate Build, Test & Deployment >> >Start a new project now. Try Jenkins in the cloud. >> >http://p.sf.net/sfu/13600_Cloudbees >> >_______________________________________________ >> >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 >> ------------------------------------------------------------------------------ Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ 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
