drbr_enqueue - OCE driver - Freebsd 9.1

Adrian Chadd adrian at freebsd.org
Mon Apr 8 18:34:51 UTC 2013


On 8 April 2013 10:14, Duvvuru,Venkat Kumar
<VenkatKumar.Duvvuru at emulex.com> wrote:
> Hi,
> In the transmit path, if enqueue mechanism is used instead of blocking on the lock, the throughput is not good in some scenarios (especially single queue, multiple connections).
> For example:
> if (TRY_LOCK(&wq->tx_lock)) {
>            status = oce_multiq_transmit(ifp, m, wq);
>            UNLOCK(&wq->tx_lock);
>      } else {
>            status = drbr_enqueue(ifp, wq->br, m);
>      }
>
> Instead of the above code where the request is enqueued if I use a normal LOCK and block on it, it is giving good performance.
>
> Any suggestions on why the throughput is low in case of enqueue mechanism.

You'll have to do a little more digging:

* Is your application spewing TCP or UDP traffic? Or sometihng else?
* are frames filling up the drbr enqueue and being dropped? having a
lock means that the caller will block until the transmit completes, so
traffic isn't immediately dropped as a side effect;
* is the driver correctly checking the drbr queue when it finishes a transmit?

In fact - oce_multiq_transmit should not be transmitting that mbuf, it
should be enqueueing to the end of the drbr, then transmitting the
head item in the drbr queue. Otherwise you may get out of order
packets.



adrian


More information about the freebsd-net mailing list