> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
------------------------------------------------------------------------------
_______________________________________________ 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
