Date: Mon, 8 Apr 2013 15:15:32 -0400 From: Ryan Stone <rysto32@gmail.com> 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: <CAFMmRNxFcg3ag_5ZRCpa-FGxUrR5TxCy4dbcjFRhEdWU1hF=MA@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 Mon, Apr 8, 2013 at 1:14 PM, 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.
>
> Thx,
> Venkat.
>
Shouldn't you be triggering a taskqueue to actually transmit the packet in
the "failed to acquire lock" case? Otherwise it could be held in the drbr
indefinitely.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFMmRNxFcg3ag_5ZRCpa-FGxUrR5TxCy4dbcjFRhEdWU1hF=MA>