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. > > http://www.research.digital.com/wrl/techreports/abstracts/95.8.html > > http://ftp.digital.com/%7emogul/usenix96.ps > > > > 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
