On Tue, 12 Jun 2007, Alfred Perlstein wrote:
AFAICT FreeBSD can't currently benefit from this as there is no cpu
affinity for connections. I may be wrong, but I see lower
single-connection throughput using a receive queue per core than using a
single receive queue. RSS is done by hashing a TCP tuple (I'm deliberately
vague because at least with cxgb there are multiple combinations, the
default is the standard 4-tuple) to a receive queue.
If you're looking at concurrent TCP input processing, the tcbinfo lock is
likely one source of overhead due to high contention. I had hoped to make
further progress on this for 7.0 (it's already better than 6.0 in a number
of ways), but the instability of 7.x over the last month scuttled that
project. It will have to be an 8.0 thing, but perhaps we can look at an MFC
if that goes well. I have some initial protyping but have been waiting for
TCP to settle down again a bit before really digging in.
Robert, have you added placeholder fields to objects that require them for
support? This would help the MFC effort.
I'm not yet at a point where I'm comfortable enough with the prototyping to
believe that I have all the right things to put in. I've had to refactor the
pbcinfo structure, for example. It would also be nice to have multiple timer
threads so that timers can run on the same CPUs as the tcpcb is normally
processed on. This is basically, however, a weak affinity model designed to
limit lock contention, not eliminate the possibility of cross-CPU execution.
What we need now is a feedback system so that the scheduler can more
intelligently weight choices.
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
