> On Jun 18, 2015, at 3:40 AM, shouta.ueh...@jp.yokogawa.com wrote: > > These results show that almost delay is spent at ioctl(SIOCBRADDBR), > and usleep_range is called twice to ixgbe driver. > 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. > And can you remove or mitigate the delay?
I believe that I can address your issue. After looking into it a bit I found that the values returned by ixgbe_get_copper_link_capabilities_generic really can not change. So, by saving the results from the first successful access, subsequent calls do not need to access the phy again for that information. It will not address this issue for other kinds of phys, but it will for these copper phys. How does that sound? Are you willing or able to apply a patch and build a driver? I see that you are using RHEL 7, so it may be easier to supply a patch that could be applied to our out-of-tree driver, rather than have you get the RHEL7 kernel source and try to deal with that. If not, the best approach may be to wait for a release of our out-of-tree driver that includes the patch. Unless you can wait for a RHEL7 update to pick it up. At least a fix should be coming for this. -- 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
