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