Jonathan Lemon wrote: > > In article <local.mail.freebsd-current/[EMAIL PROTECTED]> you write: > >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 > > Oh, bah. The fxp clearly has the equivalent of fxp_rxeof and > fxp_txeof routines, these are just inlined into the fxp_intr > routine instead of being separate functions. It was all of 10 > minutes work to break them out into separate functions. I did > this to allow polled transmit/receive for some work in progress > that will be committed soon.
I look forward to seeing the commits. I was considering doing this for similar reasons, using poling based on opportunistic timer (per the research by Banga, of Rice University), and had discussed with Bill Paul the merits of exposing the tx_eof and rx_eof routines in the device API (Bill didn't like the idea, since it had overhead, and argued that some cards won't transfer data again until the interrupt was acknowledged). I didn't bother to do this work, as with a 1GHz processor, a 100Mbit driver really can't push the interrupt overhead high enough for me to worry about it while there is other lower hanging fruit to be harvested first. For the gigabit cards, the interrupt rate was high enough that it actually mattered. I was also not sure that the FXP card would continue to DMA new data into the ring, with an unacknowledged interrupt pending. I'm more concerned with the fact that ~8% of the profiled time is being spent in the ipfw code (with only 6 rules present), and ~60% of the time is being spent in the inpcbhash code (even if you jack the table size to some ridiculously large number)... clearly, the code needs a rewrite (a trie seems like the most correct data structure here). The use of anonymous ports (host picks port) for a single bound source IP address (as opposed to INADDR_ANY) breaks outgoing connections, limiting them to 65535, since they are all treated (incorrectly) as being in the same port collision domain -- that needs fixed, too, if I'm going to have half a million connections in and half a million connections out, at the same time. There are some problems with the routing code as well; in particular, returned packes from a default gateway set up as the explicit route for an IP work, but if there is a default route to the machine hosting the gateway, the packet gets all the way back (indeed, tcpdump on the target machine sees it), but the target machine's ping program doesn't see the packet (very strange; still under investigation). On a related note, it seems that ping will hang forever and not respond to ^T or ^C, if it hasn't gotten at least one packet back (something bogus in the singal handlers -- also under investigation). I was also considering rewriting the Tigon III firmware to move a SYN cookie implementation onto the card itself, but of course, you would need a card with a lot of RAM to do this. The bottom line is that there is a lot of work to be done, and the FXP stuff is way, way down the list -- if people want performance, they can buy the high end product (Tigon) instead of the low end (FXP). Regards, -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
