From owner-freebsd-arch@freebsd.org Fri Aug 28 19:41:37 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 2C4069C5119 for ; Fri, 28 Aug 2015 19:41:37 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EDC1A1DCA; Fri, 28 Aug 2015 19:41:36 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igui7 with SMTP id i7so24060142igu.0; Fri, 28 Aug 2015 12:41:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5PtqWzKXjqQo1C17G0nMj77ReMG6R58sbSGce7436sQ=; b=tpXpN9lCTdF/jLzx91mavw/MpLSA/SkQPgCadb6L0OH8+EuhVr0Q4r4LetQy4eZ8La 19amgZVajkeG/YIuPTEy5x/s2xJjbkVYtKHiG1N7D9ojBjy7GQze0jGtjSKGHPudIwQp 4aZJMibvMV4v0n3zghccmOtJHa0oaMEUdCY19JuOYAIitrDxAKs4z4pM1bEh4nLNEWrB VyL/D17eEgpYJXyluNKrAcyyLfgF5MIhM9DprukXfdDg6GKtThqY/5tpOJEeNV41PYNb g9gSKSY2zSECaltj4hwQYNu08Cj/fz0ELypjECSJxuFa1xnQd5Y5bIUdPoOpHcrHwrMK wYjA== MIME-Version: 1.0 X-Received: by 10.50.62.193 with SMTP id a1mr4546504igs.61.1440790896322; Fri, 28 Aug 2015 12:41:36 -0700 (PDT) Received: by 10.36.28.208 with HTTP; Fri, 28 Aug 2015 12:41:36 -0700 (PDT) In-Reply-To: References: <55DDE9B8.4080903@freebsd.org> <20150828184800.GE33167@funkthat.com> Date: Fri, 28 Aug 2015 12:41:36 -0700 Message-ID: Subject: Re: Network card interrupt handling From: Adrian Chadd To: Jack Vogel Cc: John-Mark Gurney , Sean Bruno , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 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: Fri, 28 Aug 2015 19:41:37 -0000 [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. People used to do run-to-completion and then complained when this happened, so polling was a thing. So - I'm all for doing it with a fast interrupt handler and a fast taskqueue. As long as we don't run things to completion and re-schedule the taskqueue (so other things on that core get network processing) then I'm okay. (I kinda want us to have NAPI at some point...) -adrian