[PATCH] TX algorithms, missetting IFF_OACTIVE and if_timer

Bill Paul wpaul at FreeBSD.ORG
Fri Apr 2 09:03:02 PST 2004

> 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 Paul            (510) 749-2329 | Senior Engineer, Master of Unix-Fu
                 wpaul at windriver.com | Wind River Systems
              <adamw> you're just BEGGING to face the moose

More information about the freebsd-net mailing list