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
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).
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message