From owner-freebsd-arch@freebsd.org Mon Aug 31 15:49:29 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 488A69C7A3D for ; Mon, 31 Aug 2015 15:49:29 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2DBC024A for ; Mon, 31 Aug 2015 15:49:28 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from [192.168.200.200] (unknown [50.136.155.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 802FD193655 for ; Mon, 31 Aug 2015 15:49:22 +0000 (UTC) Subject: Re: Network card interrupt handling To: freebsd-arch@freebsd.org References: <55DDE9B8.4080903@freebsd.org> <20150828184800.GE33167@funkthat.com> From: Sean Bruno X-Enigmail-Draft-Status: N1110 Message-ID: <55E47781.7020009@freebsd.org> Date: Mon, 31 Aug 2015 08:49:21 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150828184800.GE33167@funkthat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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 15:49:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > I have a better question, for MSI-X, we have a dedicated interrupt > thread to do the processing, so why are we even doing any > moderation in this case? It's not any different than spinning in > the task queue.. > > How about the attached patch that just disables taskqueue > processing for MSI-X RX interrupts, and does all processing in the > interrupt thread? This is another design that I had thought of. For em(4) when using seperate ISR threads for *each* rx queue and *each* tx queue, I think that doing processing in the interrupt thread is the right thing to do. I'm unsure of what the correct thing to do when tx/rx is combined into a single handler though (igb/ix for example). This would lead to possible starvation as Adrian has pointed out. There is nothing stopping us from breaking the queues apart into seperate tx/rx threads of execution for these drivers. em(4) was my little science project to see what the behavior would be. > > Do you need to add the rx_task to the em_local_timer? If so, then > I would look at setting a flag in the _rxeof that says that > processing is happening... and in the case of the taskqueue, when > it sees this flag set, it just exits, while for the interrupt > filter case, we'd need to be more careful (possibly set a flag that > the taskqueue will inspect, and cause it to stop processing the rx > queue)... > ^^ I'll ponder this a bit further today and comment after coffee. > btw, since you're hacking on em a lot, interrested in fixing em's > jumbo frames so it doesn't use 9k clusters, but instead page sized > clusters? > > Uh ... hrm. I can look into it, but would need more details as I'm pretty ignorant of what you're referring to. Ping me off list and I'll take a look (jumbo frames is out of scope for $dayjob). sean -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJV5Hd+XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kL4wH/AmMvnZ7EKfF04qKhUxdOA90 YN5OZpyeXc8zk0QUq+INNMIHiQJN1wCHiOVd46YIuwjdWeSvHxKgnJMV1whDod55 c4QO6WG5yRcP5Wl30YN5XhjfUW48MYytYXxlAY5cC5A+TIUq/HywSNmyEVxKAooY lSw+8Zpdzaozv1LxS70bRggi9y/y5NEgcVViO1cjip+nkl3eNvYOFq5jp2KJc0vS +oe/wqbF5syRiBO4R2XnJs6PJ9BALOF73pFteHBebAe5jUwt6UD17c35/I2B4v60 +zNuM3rdNdDCOecFEdFctOQe6XDpSAu6Q7Dv88SKoKeIs+2lXHD/AJf24heTQOg= =oY0k -----END PGP SIGNATURE-----