Skip site navigation (1)Skip section navigation (2)
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>