From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 3 09:45:29 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B4B2E16A4CE for ; Wed, 3 Mar 2004 09:45:29 -0800 (PST) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9100743D1F for ; Wed, 3 Mar 2004 09:45:29 -0800 (PST) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i23HjR9Q026656; Wed, 3 Mar 2004 09:45:27 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i23HjOhh026655; Wed, 3 Mar 2004 09:45:24 -0800 (PST) (envelope-from rizzo) Date: Wed, 3 Mar 2004 09:45:24 -0800 From: Luigi Rizzo To: Andrew Gallatin Message-ID: <20040303094524.A26257@xorpc.icir.org> References: <16453.62383.59435.72390@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <16453.62383.59435.72390@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Wed, Mar 03, 2004 at 10:03:11AM -0500 cc: freebsd-hackers@freebsd.org Subject: Re: em0, polling performance, P4 2.8ghz FSB 800mhz X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2004 17:45:29 -0000 On Wed, Mar 03, 2004 at 10:03:11AM -0500, Andrew Gallatin wrote: > > Don Bowman writes: > > > I'm not sure what affect on fxp. fxp is inherently limited > > by something internal to it, which prevents achieving > > high packet rates. bge is the best chip, but doesn't but you should not compare apples and oranges. the fxp is a 100mbit NIC, the bge is a GigE NIC. > Just curious - why is bge the best chip? Is it because > it exports a really nice API (separate recv ring for small messages), > or is the chip inherently faster, regardless of its API? > > I'm trying to design a new ethernet API for a firmware-based nic, > and I'm trying to convince a colleague that having separate > receive rings for small and large frames is a really good thing. i am actually not very convinced either, unless you are telling me that there is a way to preserve ordering. Or you'd be in trouble when, on your busy link, there is a mismatch between user-level and link-level block sizes. So, what is your design like, you want to pass the NIC buffers of 2-3 different sizes and let the NIC choose from the most appropriate pool depending on the incoming frame size, but still return received frames in a single ring in arrival order ? This would make sense, but having completely separate rings (small frames here, large frames there) with no ordering relation would not. cheers luigi > Drew > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"