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

[sweetpotatopie2021]

Greetings. Any progress on this? What's the hole-up? First it was that patc=
hes were tested. Then John reported success. No one is responsive?

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, July 8th, 2021 at 3:24 PM, sweetpotatopie2021 <sweetpotatopie2=
021@protonmail.com> wrote:

> Hello again.
>
> I just wanted ask again if these patches can be expedited?
>
> Thes list showed one user (John at IBM) who reported success and transfer=
 rates of 7Gb/s. Without these patches I can get 200Mb/s max.
>
> I try to apply patches myself, but don't find easy compile instructions f=
or debian/ubuntu. Usually I use ppa.
>
> A million thanks again for all you do
>
> 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 =
Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
>
> On Monday, May 24th, 2021 at 3:23 PM, sweetpotatopie2021 sweetpotatopie20=
21@protonmail.com wrote:
>
> > 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 Origina=
l Message =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 th=
is 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 wel=
l.
> > > >
> > > > I did the work to get the patches to apply to the versions of OpenA=
FS we
> > > >
> > > > are running, but I don't feel confident calling it a review. I miss=
ed 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 wo=
rk 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 import=
ant 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 contribu=
ting
> > > > >
> > > > > factor leading some who might otherwise use AFS to consider alter=
natives
> > > > >
> > > > > (smb, nfs, cloud). In early 2019, Andrew Deason proposed some cha=
nges 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 appr=
oaching
> > > > >
> > > > > two years later and from what I can tell, it doesn't look like th=
ese have
> > > > >
> > > > > made it into a released version yet.
> > > >
> > > > The patches are visible at
> > > >
> > > > https://gerrit.openafs.org/#/q/topic:recvmmsg+(status:open+OR+statu=
s:merged)
> > > >
> > > > and
> > > >
> > > > https://gerrit.openafs.org/#/q/topic:sendmmsg+(status:open+OR+statu=
s: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 s=
ites may
> > > > >
> > > > > consider moving away from AFS would be wonderful, especially if t=
he 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 onl=
y
> > > >
> > > > person currently doing merges to master, and my time is spread quit=
e 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 wo=
rk is
> > > >
> > > > also competing for review time with patches to provide OS support f=
or 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 ge=
tting
> > > >
> > > > done, and that's not something I'm happy about, but I also don't ha=
ve 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 re=
views,
> > > >
> > > > 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