From owner-freebsd-net@FreeBSD.ORG Fri Mar 4 10:59:45 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C3B9E16A4CE; Fri, 4 Mar 2005 10:59:45 +0000 (GMT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 671EA43D2D; Fri, 4 Mar 2005 10:59:45 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.8) with ESMTP id j24AxjCg000815; Fri, 4 Mar 2005 02:59:45 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j24AxgZh000814; Fri, 4 Mar 2005 02:59:42 -0800 (PST) (envelope-from rizzo) Date: Fri, 4 Mar 2005 02:59:42 -0800 From: Luigi Rizzo To: Pawel Jakub Dawidek Message-ID: <20050304025942.E134@xorpc.icir.org> References: <200503011642.48813.jhb@FreeBSD.org> <20050301162949.A64187@xorpc.icir.org> <20050303232458.GO9291@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20050303232458.GO9291@darkness.comp.waw.pl>; from pjd@freebsd.org on Fri, Mar 04, 2005 at 12:24:58AM +0100 cc: dima <_pppp@mail.ru> cc: John Baldwin cc: net@freebsd.org Subject: Polling objectives (was Re: Giant-free polling [PATCH]) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 10:59:45 -0000 On Fri, Mar 04, 2005 at 12:24:58AM +0100, Pawel Jakub Dawidek wrote: ... (luigi) > +> this said, if the lock requests are blocking, you basically end > +> up with the polling loops always contending for the locks, with only one > +> doing actual work and the other one always busy-waiting. ... (pawel) > I think we should just implement per-interface idlepoll threads, so we can > run polling code on many CPUs for many interfaces. no this won't work, because this would leave the problem of scheduling the idlepoll threads unresolved, and you would end up with a huge overhead context-switching the idlepoll threads, or with one (or a few) interfaces getting polled and saturating resources. For the records, even the UP case had this problem -- in the initial implementation of polling, the first busy interface encountered in the polling loop would easily saturate the entire ipintrq causing other packets to be dropped systematically. I would like to restate the motivations for using polling instead of interrupts. Among the advantages of polling there were: 1. reduction of context switches: not one per interrupt, but one per timer tick (this is orders or magnitude smaller on a busy box, where you do care for the overhead); If you don't implement this, you will not improve the throughput of the box under load, and possibly will not even be able to prevent livelock 2. predictable scheduling of kernel vs userland work; If you don't implement this, once again you won't be able to prevent livelock 3. predictable scheduling of work among the various interfaces. if you don't implement this, you might risk unfairness in the handling of traffic, which can even lead to systematic starvation of certain interfaces. The UP polling code did implement all of the above. I would suggest people interested in implementing SMP polling to make sure that their _design_ covers the above issues _before_ coming up with patches. I _do not_ have a complete solution. Just coming up with something that is called polling but has none of the above properties would be misleading for the users (who do associate features to names) and a regression for the project. IMHO. thanks luigi > -- > Pawel Jakub Dawidek http://www.wheel.pl > pjd@FreeBSD.org http://www.FreeBSD.org > FreeBSD committer Am I Evil? Yes, I Am!