[OpenAFS-devel] rx large frames: Was: [OpenAFS] 1.4.8, Rx Performance Improvements, and a Small Business Innovative Research grant

[Rainer Toebbicke]

Matt Benjamin schrieb:

> 
> I've been speculating that what we need in this area is proper large
> frame support.  Derrick says he is actively working on that.  To the
> degree there are (known) open design problems, I'd appreciate any
> discussion.
> 

Perhaps off-topic as you talk about "frames"...

For two reasons (at least) AFS jumbograms are faster than emitting 
every single packet individually:

1. rxi_Start collects a list of packets to be sent in the current 
window, then SendXmitList groups them and drops the call lock for each 
packet effectively passed to UDP. After each packet it re-acquires the 
call lock. This is where real time goes as due to incoming traffic 
(acks) there is contention for the lock. With jumbograms you 
re-acquire the lock a factor 2-4 less often.

I have got a fix that drops the call lock once for the whole Xmit 
list. Numbers once I manage to iron out all the cases where it was 
actually vital to hang on to it.

2. RX's ACK strategy is 'nervous', however with jumbograms you only 
send one ACK per jumbogram, reduce contention on the emitter side and 
hence achieve higher packet rates. This works nicely on a switch, but 
has the obvious drawback of cruising blind on congested networks.

Now, for interoperability issues I don't see the "packet size" change 
easily in RX. Jumbograms however can make use of large Ethernet frames 
efficiently - but I would seek a reliable way to discover that the 
path is large frame (or at least jumbogram-efficient) end-to-end.


-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rainer Toebbicke
European Laboratory for Particle Physics(CERN) - Geneva, Switzerland
Phone: +41 22 767 8985       Fax: +41 22 767 7155