Date: Wed, 14 Jan 2015 17:43:58 +0300 From: Gleb Smirnoff <glebius@FreeBSD.org> To: John Baldwin <jhb@FreeBSD.org> Cc: svn-src-projects@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r277122 - projects/ifnet/sys/dev/msk Message-ID: <20150114144358.GD15484@FreeBSD.org> In-Reply-To: <54B67E20.3090701@FreeBSD.org> References: <201501130902.t0D927NE077024@svn.freebsd.org> <5330876.Sb1U9Iz8Cz@ralph.baldwin.cx> <20150113231735.GZ15484@FreeBSD.org> <54B67E20.3090701@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John, On Wed, Jan 14, 2015 at 09:33:04AM -0500, John Baldwin wrote: J> I posted some ideas about how to handle this in a thread several years J> ago on net@ with various alternatives. In that case I was focused on J> buf_ring and I settled on an approach where a draining thread marked the J> queue as "busy" while it was draining it and cleared that flag before J> checking the head of the queue. The enqueue process returned a J> different errno value (EINPROGRESS or some such) if it queued a packet J> into a "busy" queue and the transmit routines were changed to 1) always J> enqueue the packet, and 2) if EINPROGRESS wasn't returned, use a J> blocking mtx_lock and start transmitting. J> J> However, even this model has some downsides in that one thread might be J> stuck transmitting packets queued by other threads and never pop back J> out to userland to service its associated application (a kind of J> starvation of the user side of the thread). Note that the mtx_trylock J> approach has the same problem. It might be nice to have a sort of limit J> on the number of packets a thread is willing to enqueue, but then you J> have the problem of ensuring any packets still on the queue when it hits J> its limit aren't also delayed indefinitely. Thanks, I will try to code that. J> I don't recall the exact mechanics of how Navdeep's mp_ring addresses J> this (though I believe it does from when I looked at it). J> J> Regardless, I think this was my point I attempted to make on IRC J> earlier: you need to figure out what you are going to do here first J> before you go through and convert all the drivers. Otherwise you will J> be stuck making multiple passes. Converting a "real" driver up front is J> useful so you can prototype different solutions, but I think you need to J> resolve this now before continuing your pass as the current approach is J> not suitable to be merged into HEAD. Right! What I want to do now is to convert several drivers and actually make project/ifnets usable for people who own several NICs. Then attract more developers to the problem and using this small set of converted NICs coin out a final KPI. After that go for a sweep. -- Totus tuus, Glebius.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150114144358.GD15484>