From owner-freebsd-net@FreeBSD.ORG Fri Apr 2 15:50:03 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 B950016A4CE; Fri, 2 Apr 2004 15:50:03 -0800 (PST) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id D42E143D1D; Fri, 2 Apr 2004 15:50:02 -0800 (PST) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i32NrYMS023919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 Apr 2004 02:53:36 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i32NnrAH000794; Sat, 3 Apr 2004 02:49:53 +0300 (EEST) (envelope-from ru) Date: Sat, 3 Apr 2004 02:49:52 +0300 From: Ruslan Ermilov To: Bill Paul Message-ID: <20040402234952.GA743@ip.net.ua> References: <20040402120619.GA10105@ip.net.ua> <20040402170302.C227F16A4CF@hub.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline In-Reply-To: <20040402170302.C227F16A4CF@hub.freebsd.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: net@FreeBSD.ORG Subject: Re: [PATCH] TX algorithms, missetting IFF_OACTIVE and if_timer 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, 02 Apr 2004 23:50:03 -0000 --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 02, 2004 at 09:03:02AM -0800, Bill Paul wrote: [...] > > To differentiate the case of an empty > > ring from the full ring, some drivers (ste(4), dc(4), and > > nge(4)) have the threshold (6 for dc(4), 3 for ste(4), and > > 2 for nge(4)) to assert the gap between producer and consumer, > > thus not allow the producer to catch the consumer. (The > > vr(4) is hairier, and I will not discuss it in detail here.) > >=20 > > First, could you please explain these magic numbers? >=20 > Not really, no. Very often, values were chosen because they worked > (and in some cases, they weren't chosen by me). >=20 Hmm, well, at least I now know (learned the hard way) why the gap is ever necessary -- I will just silently join the crew who keep this secret, and don't tell it to anyone. ;) > > Also, some drivers use indexes for consumer and producer, > > where they could use "next" pointers, which should be faster. >=20 > "Should" be faster? I'm not saying you're wrong, but can you prove > that it's faster to use lists? I started out using linked lists > for descriptors, but then I started to encounter chips that used > producer/consumer indexes internally (like the Adaptec 'starfire' > chip and the Tigon II). I decided that since I tended to allocate > all of the descriptors in contiguous chunks anyway, it was simpler > to just treat them as arrays and use index counters. >=20 I experimented with ste(4) today -- except for getting 200 bytes less driver code when converting to use the precomputed pointers, I didn't notice any change in performance, so I threw my changes away. ;) > > I also think that using the gap between producer/consumer is > > suboptimal, but this gap is part of the existing algorithm. >=20 > Nowhere is it written that you can't change the algorithm. :) >=20 Now I know (I wish you'd tell me it) why the gap is necessary, but let's keep this secret. ;) > Note that if you're looking for approval from me to check in these > patches, don't bother: I will neither approve nor disapprove. The > only way for me to know if your changes are correct is to test them, > and I don't have the time or resources right now to do that. If you > want to commit them, go ahead. It's your funeral. :) >=20 Understood. This is some ancient code, and you have lot of modern stuff to play with. ;) Actually, I was just looking for your advise and your vision. [...] > And then the stork comes, and it's a driver. >=20 *LOL* Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAbfwgUkv4P6juNwoRAs7FAJ9fdEzzBnnK1LpQgZMOqoAisrMz4QCgiycJ /G59CWaywsXzgm3RyOoW1ro= =rOka -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH--