Date: Sat, 3 Apr 2004 02:49:52 +0300 From: Ruslan Ermilov <ru@FreeBSD.ORG> To: Bill Paul <wpaul@FreeBSD.ORG> Cc: net@FreeBSD.ORG Subject: Re: [PATCH] TX algorithms, missetting IFF_OACTIVE and if_timer Message-ID: <20040402234952.GA743@ip.net.ua> In-Reply-To: <20040402170302.C227F16A4CF@hub.freebsd.org> References: <20040402120619.GA10105@ip.net.ua> <20040402170302.C227F16A4CF@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040402234952.GA743>