Hi Ben, We have been importing these patches into our IBM internal OpenAFS 1.8.X builds for over a year and have had our busiest cells running these versions since fall last year. We hit some deadlock issue early on but that was fixed and I believe those patches made it to gerrit as well.
I did the work to get the patches to apply to the versions of OpenAFS we are running, but I don't feel confident calling it a review. I missed the deadlock issue until we actually put it into production :). John Janosik jpjan...@us.ibm.com From: Benjamin Kaduk <ka...@mit.edu> To: sweetpotatopie2021 <sweetpotatopie2...@protonmail.com> Cc: "openafs-devel@openafs.org" <openafs-devel@openafs.org> Date: 05/06/2021 09:00 PM Subject: [EXTERNAL] Re: [OpenAFS-devel] Andrew Deason's OpenAFS RX performance patches Sent by: openafs-devel-ad...@openafs.org 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 _______________________________________________ OpenAFS-devel mailing list OpenAFS-devel@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-devel
