On 8 April 2013 10:14, Duvvuru,Venkat Kumar
<venkatkumar.duvv...@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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
