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

[sweetpotatopie2021]

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.

=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Thursday, May 13, 2021 7:32 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:

> Hi John,
>
> My mailer thinks I did not respond to this yet, so my apologies if this i=
s
> 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 w=
e
> > are running, but I don't feel confident calling it a review. I missed t=
he
> > 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 t=
hat
> > > 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 alternati=
ves
> > > (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 approach=
ing
> > > 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:me=
rged)
> > and
> > https://gerrit.openafs.org/#/q/topic:sendmmsg+(status:open+OR+status:me=
rged)
> > , and you are correct, the changes that actually have a performance imp=
act
> > have not been merged yet. (Some of the earlier cleanup commits have bee=
n
> > 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 w=
ork
> > > is complete -- or very close to complete. [It might also lead to it b=
eing
> > > 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 th=
in
> > (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 i=
s
> > also competing for review time with patches to provide OS support for n=
ew
> > 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 gettin=
g
> > 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 review=
s,
> > so only a truly careful review would be expected to find new issues), a=
nd
> > 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