[OpenAFS-devel] Andrew Deason's OpenAFS RX performance patches

[Benjamin Kaduk]

Hi JR,

On Wed, May 05, 2021 at 02:48:39PM +0000, sweetpotatopie2021 wrote:
> Dear developers,
> 
> First, a shout-out. I'd like to say a big "Thank you!" for the work that you do supporting OpenAFS by addressing security vulnerabilities and ensuring that it continues to work on each newly-released version of (at least) Linux, Windows, and MacOS -- obviously the two most important goals for keeping OpenAFS moving forward.
> 
> However I have a plea: AFS has never noted as a real speed demon for data transfer. But its lack of performance is cited as a contributing factor leading some who might otherwise use AFS to consider alternatives (smb, nfs, cloud). In early 2019, Andrew Deason proposed some changes to RX which promised performance gains without changing to TCP. See <https://openafs-workshop.org/2019/schedule/how-to-saturate-a-10g-link-with-an-openafs-rx-fileserver/>.
> 
> Andrew submitted patches to OpenAFS's gerrit primarily affecting sendmmsg and recvmmsg (circa gerrit ~13601 - 13613) but it's approaching two years later and from what I can tell, it doesn't look like these have made it into a released version yet.

The patches are visible at
https://gerrit.openafs.org/#/q/topic:recvmmsg+(status:open+OR+status:merged)
and
https://gerrit.openafs.org/#/q/topic:sendmmsg+(status:open+OR+status:merged)
, and you are correct, the changes that actually have a performance impact
have not been merged yet.  (Some of the earlier cleanup commits have been
merged.)

> Can moving these changes forward to a released version of OpenAFS be prioritized? Removing "performance sucks," from the list of why sites may consider moving away from AFS would be wonderful, especially if the work is complete -- or very close to complete. [It might also lead to it being considered more seriously by homelab users, SMB (small and medium business) techs, and others.]

I'm sad to say that the main bottleneck here is myself.  I'm the only
person currently doing merges to master, and my time is spread quite thin
(I'm an IETF Security Area Director, which is something that takes at least
15 hours a week and can take as much time as is available).  This work is
also competing for review time with patches to provide OS support for new
OS versions, other bugfixes and cleanup that come in, rxgk support, and the
underlying changes needed to bring in rxgk support.  It's not all getting
done, and that's not something I'm happy about, but I also don't have a
clear path for changing that in the near future.

The main thing that would help to get these changes merged would be careful
code review (though most of these already have received positive reviews,
so only a truly careful review would be expected to find new issues), and
reports of successful stress testing of the code.

-Ben