Date: Mon, 31 Aug 2015 14:18:17 -0700 From: John Baldwin <jhb@freebsd.org> To: freebsd-arch@freebsd.org Cc: John-Mark Gurney <jmg@funkthat.com>, Adrian Chadd <adrian.chadd@gmail.com>, Sean Bruno <sbruno@freebsd.org>, Jack Vogel <jfvogel@gmail.com> Subject: Re: Network card interrupt handling Message-ID: <5699836.EEH7cPOQBG@ralph.baldwin.cx> In-Reply-To: <20150831000003.GJ33167@funkthat.com> References: <55DDE9B8.4080903@freebsd.org> <CAJ-VmonvrvpXDoqfsEffGSdnRkEL4w-6eBebwkWHXd8Hea-C3g@mail.gmail.com> <20150831000003.GJ33167@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday, August 30, 2015 05:00:03 PM John-Mark Gurney wrote: > Adrian Chadd wrote this message on Fri, Aug 28, 2015 at 12:41 -0700: > > [snip] > > > > Well, the other big reason for doing it deferred like this is to avoid > > network based deadlocks because you're being fed packets faster than > > you can handle them. If you never yield, you stop other NIC > > processing. > > You snipped the part of me asking isn't the interrupt thread just the > same interruptable context as the task queue? Maybe the priority is > different, but that can be adjusted to be the same and still save the > context switch... > > There is no break/moderation in the taskqueue, as it'll just enqueue > itself, and when the task queue breaks out, it'll just immediately run > itself, since it has a dedicated thread to itself... So, looks like > you get the same spinning behavior... Yes, that is true and why all the interrupt moderation stuff in the NIC drivers that I've seen has always been pointless. All it does is add extra overhead since you waste time with extra context switches back to yourself in between servicing packets. It does not permit any other NICs to run at all. (One of the goals of my other patches that I mentioned is to make it possible for multiple devices to share ithreads even when using discrete interrupts (e.g. MSI) so that the yielding done actually would give a chance for other devices to run, but currently it is all just a waste of CPU cycles). If you think this actually helps, I challenge to you capture a KTR_SCHED trace of it ever working as intended. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5699836.EEH7cPOQBG>