>
> We've solved most of the performance issues, but NFS is still
> eating a little too much cpu for my tastes. Unfortunately it is getting to
> the point where a significant portion of the performance loss is occuring
> in the network driver itself. Some of my cards eat 25% of the cpu just
> in 'interrupt' (at 10 MBytes/sec half duplex), not even counting the
> TCP or UDP stacks. This is mainly due to the MTU being too small (i.e.
> packet fragmentation takes it toll on the interrupt subsystem). SCSI
> cards are way ahead of NIC cards in regards to reducing interrupt
> overhead (though gigabit NICs have caught up some).
Actually, I'm not sure I buy this at all. Both the EtherExpress and
3C905 families give less than one interrupt per datagram, and the
other overheads on them are comparably small.
I think you'll want to do some profiling before getting too concerned
about the network drivers themselves; gigabit hardware isn't really any
lighter on the CPU than good 100Mbps hardware, and we can handle better
than 400MBps UDP inbound on a reasonable (400MHz) system right now.
(Lots better with jumbo frames.)
My guesses (based on some of the profiling that Bill Paul did) would be
the IP and UDP checksum guessing, but more that I think you'll find that
a considerable amount of the inbound NFS traffic handling is actually
performed in the interrupt context (ie. I don't think that stuff is
being handed off to a softnet handler), blowing out the numbers a bit.
--
\\ Give a man a fish, and you feed him for a day. \\ Mike Smith
\\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
