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
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
