From owner-freebsd-arch@freebsd.org Mon Aug 31 21:33:34 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A4C339C6F04 for ; Mon, 31 Aug 2015 21:33:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 829AF1625; Mon, 31 Aug 2015 21:33:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 925E3B913; Mon, 31 Aug 2015 17:33:33 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Cc: John-Mark Gurney , Adrian Chadd , Sean Bruno , Jack Vogel Subject: Re: Network card interrupt handling Date: Mon, 31 Aug 2015 14:18:17 -0700 Message-ID: <5699836.EEH7cPOQBG@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-PRERELEASE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20150831000003.GJ33167@funkthat.com> References: <55DDE9B8.4080903@freebsd.org> <20150831000003.GJ33167@funkthat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 31 Aug 2015 17:33:33 -0400 (EDT) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 21:33:34 -0000 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