Date: Fri, 28 Aug 2015 12:41:36 -0700 From: Adrian Chadd <adrian.chadd@gmail.com> To: Jack Vogel <jfvogel@gmail.com> Cc: John-Mark Gurney <jmg@funkthat.com>, Sean Bruno <sbruno@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: Network card interrupt handling Message-ID: <CAJ-VmonvrvpXDoqfsEffGSdnRkEL4w-6eBebwkWHXd8Hea-C3g@mail.gmail.com> In-Reply-To: <CAFOYbcm55rJ2ZLyp0J8nkMcd2zCsTjS7GcbE1ZOJ7uXH91q7Bg@mail.gmail.com> References: <55DDE9B8.4080903@freebsd.org> <20150828184800.GE33167@funkthat.com> <CAFOYbcm55rJ2ZLyp0J8nkMcd2zCsTjS7GcbE1ZOJ7uXH91q7Bg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmonvrvpXDoqfsEffGSdnRkEL4w-6eBebwkWHXd8Hea-C3g>