Date: Tue, 24 Mar 2020 15:13:40 -0400 From: Ryan Stone <rysto32@gmail.com> To: Patrick Kelsey <pkelsey@freebsd.org> Cc: freebsd-net <freebsd-net@freebsd.org> Subject: Re: Can net.iflib.min_tx_latency=0 introduce an unbounded amount of latency? Message-ID: <CAFMmRNx2Kn63cpu8Tn2V=rEL-7JY1NC_=E723eG_3Ddcapqttg@mail.gmail.com> In-Reply-To: <CAD44qMVPLz75vA%2BhupdmTe_hRjTCNTeuT63nXGQM8bTTf5OftA@mail.gmail.com> References: <CAFMmRNx4FkT2meX2o%2Be-ksgFMmAX6kveu%2BHBY8hxkv_StpyauQ@mail.gmail.com> <CAD44qMVPLz75vA%2BhupdmTe_hRjTCNTeuT63nXGQM8bTTf5OftA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks for the analysis. I haven't had much of an opportunity to get into the guts of iflib and I'm not very successful at following the round trips through mpring yet. On Mon, Mar 23, 2020 at 12:50 AM Patrick Kelsey <pkelsey@freebsd.org> wrote= : > > > > 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=3D0), 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() invocatio= n (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(), whi= ch will then enqueue the special marker (void **)&txq, and one way or anoth= er, 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 >=3D TX= Q_MAX_DB_DEFERRED(...) is satisfied, unless there are too many posted packe= ts in the hardware queue that aren't being drained by the hardware (this wo= uld result in the in_use parameter remaining elevated such that a small num= ber of pending packets would not exceed the threshold, and also no slot rec= laim occurring). > > -Patrick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFMmRNx2Kn63cpu8Tn2V=rEL-7JY1NC_=E723eG_3Ddcapqttg>