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

[Benjamin Kaduk]

Hi John,

My mailer thinks I did not respond to this yet, so my apologies if this is
a duplicate.

Thank you for reporting on your experiences; it does help indicate
confidence in the readiness of the patches.

-Ben

On Thu, May 06, 2021 at 09:22:08PM -0500, John P Janosik wrote:
> 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
> jpjanosi@us.ibm.com
> 
> 
> 
> From:   Benjamin Kaduk <kaduk@mit.edu>
> To:     sweetpotatopie2021 <sweetpotatopie2021@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-admin@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 
> 
> 
> 
> 
> 
>