Date: Mon, 15 Oct 2012 20:32:10 +0400 From: Gleb Smirnoff <glebius@FreeBSD.org> To: John Baldwin <jhb@FreeBSD.org> Cc: freebsd-net@FreeBSD.org, "Alexander V. Chernikov" <melifaro@FreeBSD.org>, Luigi Rizzo <rizzo@iet.unipi.it>, Jack Vogel <jfvogel@gmail.com>, net@FreeBSD.org Subject: Re: ixgbe & if_igb RX ring locking Message-ID: <20121015163210.GW89655@FreeBSD.org> In-Reply-To: <201210150904.27567.jhb@freebsd.org> References: <5079A9A1.4070403@FreeBSD.org> <CAFOYbc=N87_OECto7B8jdzmRZA-yoa_JWgvVc8kwpK9umO97rQ@mail.gmail.com> <507C1960.6050500@FreeBSD.org> <201210150904.27567.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Oct 15, 2012 at 09:04:27AM -0400, John Baldwin wrote:
J> > 3) in practice taskqueue routine is a nightmare for many people since
J> > there is no way to stop "kernel {ix0 que}" thread eating 100% cpu after
J> > some traffic burst happens: once it is called it starts to schedule
J> > itself more and more replacing original ISR routine. Additionally,
J> > increasing rx_process_limit does not help since taskqueue is called with
J> > the same limit. Finally, currently netisr taskq threads are not bound to
J> > any CPU which makes the process even more uncontrollable.
J>
J> I think part of the problem here is that the taskqueue in ixgbe(4) is
J> bogusly rescheduled for TX handling. Instead, ixgbe_msix_que() should
J> just start transmitting packets directly.
J>
J> I fixed this in igb(4) here:
J>
J> http://svnweb.freebsd.org/base?view=revision&revision=233708
The problem Alexander describes in 3) definitely wasn't fixed in r233708.
It is still present in head/, and it prevents me to do good benchmarking
of pf(4) on igb(4).
The problem is related to RX handling, so I don't see how r233708 could
fix it.
--
Totus tuus, Glebius.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121015163210.GW89655>