Hi Ben, Thank you for replying.
Is it possible that these might make it into an RC or release sometime soon? JR Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, May 13, 2021 7:32 PM, Benjamin Kaduk <ka...@mit.edu> wrote: > 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
