From owner-freebsd-net@FreeBSD.ORG Wed Jan 28 23:36:54 2004 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 D658F16A4CE for ; Wed, 28 Jan 2004 23:36:54 -0800 (PST) Received: from mail.dragondata.com (server2-b.dragondata.com [64.202.113.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F61543D2F for ; Wed, 28 Jan 2004 23:36:52 -0800 (PST) (envelope-from toasty@dragondata.com) Received: (qmail 45529 invoked by uid 1092); 29 Jan 2004 07:39:25 -0000 Received: from toasty@dragondata.com by server2.dragondata.com by uid 82 with qmail-scanner-1.20rc3 (uvscan: v4.2.40/v4296. spamassassin: 2.60-cvs. Clear:RC:1:. Processed in 0.659289 secs); 29 Jan 2004 07:39:25 -0000 Received: from ppp045.dhcp.your.org (HELO ?199.165.179.45?) (199.165.179.45) by mail.dragondata.com with RC4-SHA encrypted SMTP; 29 Jan 2004 07:39:24 -0000 In-Reply-To: <20040129090413.5e3a9cc0.dudu@diaspar.rdsnet.ro> References: <20040128194435.GA16076@c7.campus.utcluj.ro> <20040129090413.5e3a9cc0.dudu@diaspar.rdsnet.ro> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Kevin Day Date: Thu, 29 Jan 2004 01:36:50 -0600 To: Vlad Galu X-Mailer: Apple Mail (2.612) cc: freebsd-net@freebsd.org Subject: Re: DEVICE_POLLING with SMP 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: Thu, 29 Jan 2004 07:36:55 -0000 On Jan 29, 2004, at 1:04 AM, Vlad Galu wrote: > > I see no reason for it. Having to switch between multiple kernel > threads to handle polling may bring too much overhead. > > Would that really be happening though? If polling is happening in the idle loop, extra overhead doesn't really matter all that much, the CPU is idle, and I can't imagine it being any worse during a livelock inducing amount of traffic. If it's polling during any other time, the code is exactly the same between the UP and SMP case, and I can't imagine the overhead being all THAT much worse, would it? My primary goal with it is to stop thrashing context switches when I've got a system acting as a router with 8 network interfaces on it. Even with network card interrupt coalescing there is a whole lot of interrupt activity going on, which polling seems to make a noticeable difference with polling enabled. I'm also very interested in polling's ability to more gracefully handle extremely heavy network traffic without getting into livelock, which may be worth it to some people prone to DoS activity when they have a whole lot of bandwidth to deal with. I'd be willing to chip in a few bucks for development time if anyone wants to make the changes to try it out. It didn't look that difficult, but my time is pretty booked right now. -- Kevin