From owner-freebsd-net Mon Jul 2 15:42:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id B466937B403; Mon, 2 Jul 2001 15:42:11 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id AAA39077; Tue, 3 Jul 2001 00:36:57 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200107022236.AAA39077@info.iet.unipi.it> Subject: Re: fastforwarding? In-Reply-To: <20010702222259.29F3337B401@hub.freebsd.org> from Jeffrey Hsu at "Jul 2, 2001 03:22:59 pm" To: Jeffrey Hsu Date: Tue, 3 Jul 2001 00:36:57 +0200 (CEST) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > one of them is the (relatively high) interrupt overhead ... > Interesting. We've been working on the Lazy Receiver Processing > approach (http://www.cs.rice.edu/CS/Systems/LRP) to this problem > in combination with polling after processing as suggested by Mogul's > paper. As I understand it, your approach has the benefit of simplicity > over the LRP approach. well, it is simpler because it targets a simpler problem, namely forwarding from one interface to another one. But certainly, cutting off a fair amount of interrupt processing time frees some CPU for protocol processing. At a quick glance at the URL you mention, LRP seems to look at higher level protocol processing, and at giving a more fair treatment to different flows. This problem is a bit more complex to handle, as it requires modifications in the protocol stack (and maybe the CPU scheduler) as well. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message