Mark's point is completely valid, but I would add the real issue here is why is the bridging command calling the __ethtool_get_settings? This returns lots of information some of which requires the lock you ran into. Could they get what they need elsewhere? I haven't looked at port_cost doing this for but maybe it could get it from something less far reaching?
Thanks, -Don Skidmore <donald.c.skidm...@intel.com> > -----Original Message----- > From: Rustad, Mark D [mailto:mark.d.rus...@intel.com] > Sent: Thursday, June 18, 2015 9:02 AM > To: shouta.ueh...@jp.yokogawa.com > Cc: e1000-devel@lists.sourceforge.net; mihoko.tan...@jp.yokogawa.com; > ryouta.kat...@jp.yokogawa.com > Subject: Re: [E1000-devel] ixgbe driver causes a delay in brctl addif > command. > > > On Jun 18, 2015, at 3:40 AM, shouta.ueh...@jp.yokogawa.com wrote: > > > > Both of ixgbe_acquire_swfw_sync_X540 and > ixgbe_release_swfw_sync_X540 > > call usleep_range(5000, 10000) just before return. It causes non-operation > time about 20msec. > > I want to ask you why usleep_range has to be called there. > > It is part of the interface space that there should a that much delay between > instances of taking the semaphore. > > > And can you remove or mitigate the delay? > > Removing the delay would violate the specification. One alternative would > be to save the time that the semaphore was last released and, on entry, > delay for the difference to maintain spec compliance. In this kind of case, it > might save about half of the time. So the best case time would become > about 10ms. It could still be worse if there had happened to be a driver use > of the semaphore just before this operation. If that happened to be true, > then there would be no net improvement from such a change. > > Is a best case of 10ms enough of an improvement? > > -- > Mark Rustad, Networking Division, Intel Corporation ------------------------------------------------------------------------------ _______________________________________________ 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
