Date: Mon, 8 Apr 2013 11:34:50 -0700 From: Adrian Chadd <adrian@freebsd.org> To: "Duvvuru,Venkat Kumar" <VenkatKumar.Duvvuru@emulex.com> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: drbr_enqueue - OCE driver - Freebsd 9.1 Message-ID: <CAJ-VmokKFwYd4vGRW%2B-xikgBMF3XqCd52Fy4Prf=gfs-GD-eew@mail.gmail.com> In-Reply-To: <BF3270C86E8B1349A26C34E4EC1C44CB2B82015D@CMEXMB1.ad.emulex.com> References: <BF3270C86E8B1349A26C34E4EC1C44CB2B82015D@CMEXMB1.ad.emulex.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8 April 2013 10:14, Duvvuru,Venkat Kumar
<VenkatKumar.Duvvuru@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmokKFwYd4vGRW%2B-xikgBMF3XqCd52Fy4Prf=gfs-GD-eew>