> 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?
I have the same question too. This issue causes that performance of bridge control depended on hardware. I think this is not a desired behavior of bridge control. > 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? That sounds good. According to your proposal, ixgbe_get_copper_link_capabilities_generic will not cause a delay except the first time, right? And it sounds like that the issue will be avoided not only for X540 but also any other Intel Network adapter. I expect that the issue will be resolved in the future by its fix. > Are you willing or able to apply a patch and build a driver? Yes, I want to try it. Could you make the patch? Shota -----Original Message----- From: Rustad, Mark D [mailto:mark.d.rus...@intel.com] Sent: Saturday, June 20, 2015 2:14 AM To: Uehara, Shouta (shouta.ueh...@jp.yokogawa.com) Cc: e1000-devel@lists.sourceforge.net; Tanaka, Mihoko (mihoko.tan...@jp.yokogawa.com); Katano, Ryouta (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: > > 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 ----- CONFIDENTIAL: This e-mail may contain information that is confidential or otherwise protected from disclosure and intended only for the party to whom it is addressed. If you are not the intended recipient, please notify the sender by return and delete this e-mail. You are hereby formally advised that any unauthorized use, disclosure or copying of this email is strictly prohibited and may be unlawful. ------------------------------------------------------------------------------ Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical & virtual servers, alerts via email & sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o _______________________________________________ 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
