Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 23 Mar 2020 00:50:08 -0400
From:      Patrick Kelsey <pkelsey@freebsd.org>
To:        Ryan Stone <rysto32@gmail.com>
Cc:        freebsd-net <freebsd-net@freebsd.org>
Subject:   Re: Can net.iflib.min_tx_latency=0 introduce an unbounded amount of latency?
Message-ID:  <CAD44qMVPLz75vA%2BhupdmTe_hRjTCNTeuT63nXGQM8bTTf5OftA@mail.gmail.com>
In-Reply-To: <CAFMmRNx4FkT2meX2o%2Be-ksgFMmAX6kveu%2BHBY8hxkv_StpyauQ@mail.gmail.com>
References:  <CAFMmRNx4FkT2meX2o%2Be-ksgFMmAX6kveu%2BHBY8hxkv_StpyauQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Mar 22, 2020 at 2:31 PM Ryan Stone <rysto32@gmail.com> wrote:

> I've been tracking down a bug at work that appears to be due to
> excessive latency introduced on the TX side of a TCP connection.  In
> looking through the iflib code, I noticed the tunable
> net.iflib.min_tx_latency.  My reading of the iflib code is that if a
> packet is enqueued to a tx ring but not posted (when
> min_tx_latency=0), then iflib can introduce an unbounded amount of
> latency if the ring is idle.  Is my reading of the code correct?
>
>
Let's see...in the case described above, the next iflib_timer() invocation
(max 500ms later) should find that txq->ift_db_pending is non-zero, which
will cause it to enqueue the TX task, which will invoke _task_fn_tx(),
which will then enqueue the special marker (void **)&txq, and one way or
another, iflib_txq_drain() will be called.

Looking at iflib_txq_drain() it appears that the first call to
iflib_txd_db_check() should post the pending packets either because a
non-zero number of slots were just reclaimed, or the check
for txq->ift_db_pending >= TXQ_MAX_DB_DEFERRED(...) is satisfied, unless
there are too many posted packets in the hardware queue that aren't being
drained by the hardware (this would result in the in_use parameter
remaining elevated such that a small number of pending packets would not
exceed the threshold, and also no slot reclaim occurring).

-Patrick



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAD44qMVPLz75vA%2BhupdmTe_hRjTCNTeuT63nXGQM8bTTf5OftA>