Date: Fri, 2 Apr 2004 09:03:02 -0800 (PST) From: wpaul@FreeBSD.ORG (Bill Paul) To: ru@FreeBSD.org (Ruslan Ermilov) Cc: net@FreeBSD.org Subject: Re: [PATCH] TX algorithms, missetting IFF_OACTIVE and if_timer Message-ID: <20040402170302.C227F16A4CF@hub.freebsd.org> In-Reply-To: <20040402120619.GA10105@ip.net.ua> from Ruslan Ermilov at "Apr 2, 2004 03:06:19 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> Gang,
>
> I've been wading through several network drivers recently,
> learning Bill Paul's code. Specifically, I examined the
> following drivers: ste(4), rl(4), dc(4), nge(4), and vr(4).
>
> They all use the consumer/producer approach for handling TX.
> if_start() works with the producer, and txeof() works with
> the consumer. The condition (consumer == producer) is when
> the TX ring is empty. 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.)
>
> First, could you please explain these magic numbers?
Not really, no. Very often, values were chosen because they worked
(and in some cases, they weren't chosen by me).
> Also, some drivers use indexes for consumer and producer,
> where they could use "next" pointers, which should be faster.
"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.
> I also think that using the gap between producer/consumer is
> suboptimal, but this gap is part of the existing algorithm.
Nowhere is it written that you can't change the algorithm. :)
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. :)
> As an aside, lot of drivers that support auto-padding
> still have useless xx_pad[XX_MIN_FRAMELEN] element in
> their xx_chain_data structure, namely, dc(4), ste(4),
> and tl(4) have it. I think these were copied from
> some template driver, is it safe to remove them?
If nothing references them, sure. Note that there is no "template
driver." I write new drivers by choosing an existing driver that
most closely matches the design of the chip I need to support, run
it through sed(1) to change its name, strip out all the device-dependent
stuff specific to the old device and replace it with stuff for the
new device.
And then the stork comes, and it's a driver.
-Bill
--
=============================================================================
-Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu
wpaul@windriver.com | Wind River Systems
=============================================================================
<adamw> you're just BEGGING to face the moose
=============================================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040402170302.C227F16A4CF>