Peter Wemm wrote:
> > This is based on ideas in the Jeff Mogul (DEC Western Research
> > Labs) paper from 1995:
> These look like a subset of what Garrett was working on in 1996:

Guess Jeff Mogul beat him to it; I wish Garrett's code had been
committed, so I wouldn't have had to reinvent it myself.

It's actually an idea from the serial communications era.
Digital Press published a book by McNamara, called "Technical
Aspects of Data Communication", which described taking a
serial interrupt, and then polling like hell until there was
no more data.  This was really the only way to handle the
highest possible baud rates on things like 8MHz PCs.  My copy
is from 1982.

> >
> >
> >
> > Kris: Commit this... K PLZ THX.
> Certainly not with this lousy patch with no context!

I don't understand the complaint.

If it's the if_dc.c patch you are upset about, I *did* say
the if_ti.c patch was cleaner.  The problem is that the
other drivers don't really lend themselves to doing this in
a clean way, without a rewrite of the interrupt processing.

If you can tell me what context you lack, or why you think the
patch is lousy (it passes style(9), perhaps I can make you
less negative?

If it's just context, and you are unwilling to read the papers
cited, the basic idea is this:

1)      Handle interrupts normally

2)      Have a seperate routine to do the transfer completion
        polling (almost every driver ever written by Bill
        Paul has this already)

3)      Set a flag if any data was transferred (i.e. there was
        active data -- this will always be true for either the
        transmit or the receive the first time through)

4)      Make the transmit and receive interrupt handlers return
        this flag

5)      If the flag is set, repeat the process of the poll;
        this assumes that the interrupt notification is not
        the only notification of data transfer completion,
        and that there is a ring descriptor or other method
        to successfully determine if the data transfer has
        been completed, without needing an interrupt

The result is that if a card is very, very busy, rather than
taking an interrupt, doing ether input, and then exiting, only
to immediately get an interrupt again, and taking the trap
overhead twice and the restart overhead twice (or more), the
single interrupt is used to do the work.

In practice, this in itself will not prevent receiver livelock;
it's a necessary, but not sufficient design change.

As I also said: you're not going to see improvement from this
unless you can drive the card at its highest rate.

Clearly this would also be very applicable to non-Gigabit cards,
but the only one we use is the FXP, and the FXP driver is very
poorly structured for being able to do this type of thing (I
really like Bill Paul's recent drivers much better).  I can't
test with other cards, and I'm not sure they meet the assumption
I documented in #5, above.

In any case, feel free to pee on it to make it smell like you,
or rewrite it from scratch, if you want.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to