On Mar 26, 2014, at 3:36 PM, Aaron Brice <[email protected]> wrote:
> Well, I got past the ioctl part but it seems that we're also doing > some QoS stuff using netlink sockets that is getting delayed also, and > I can't get rid of the rtnl lock there.. Is there anything that can > be done on the driver side? 200ms seems like a long time to be > holding the lock.. I don't have any experience with the igb driver myself, but a quick look shows that it is only taking the rtnl lock in two places, and those probably are not your issue. It would be nice if the rtnl lock were to be broken down into finer-grained locks, but that is likely to be a pretty significant and intrusive change. And not likely to happen very soon. Since it sounds like you have been modifying the kernel already, a possible workaround that I have used in the past is to add a character device interface and to issue ioctls to it. This can work if you can be sure that those ioctls can be performed safely without using the rtnl lock. I have used that technique with success. Since you are also using netlink sockets, that may not help much unless you can find a way to perform those operations via a character device ioctl safely as well. It is an ugly hack and would never be accepted upstream, but if you don't need to do that, it might help your situation. -- Mark Rustad, Networking Division, Intel Corporation ------------------------------------------------------------------------------ _______________________________________________ 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
