[OpenAFS-devel] Andrew Deason's OpenAFS RX performance patches
John P Janosik
jpjanosi@us.ibm.com
Thu, 6 May 2021 21:22:08 -0500
--=_alternative 000D02E2862586CE_=
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Hi Ben,
We have been importing these patches into our IBM internal OpenAFS 1.8.X=20
builds for over a year and have had our busiest cells running these=20
versions since fall last year. We hit some deadlock issue early on but=20
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=20
are running, but I don't feel confident calling it a review. I missed the=
=20
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=20
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,
>=20
> First, a shout-out. I'd like to say a big "Thank you!" for the work that=
=20
you do supporting OpenAFS by addressing security vulnerabilities and=20
ensuring that it continues to work on each newly-released version of (at=20
least) Linux, Windows, and MacOS -- obviously the two most important goals=
=20
for keeping OpenAFS moving forward.
>=20
> However I have a plea: AFS has never noted as a real speed demon for=20
data transfer. But its lack of performance is cited as a contributing=20
factor leading some who might otherwise use AFS to consider alternatives=20
(smb, nfs, cloud). In early 2019, Andrew Deason proposed some changes to=20
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/=20
>.
>=20
> Andrew submitted patches to OpenAFS's gerrit primarily affecting=20
sendmmsg and recvmmsg (circa gerrit ~13601 - 13613) but it's approaching=20
two years later and from what I can tell, it doesn't look like these have=20
made it into a released version yet.
The patches are visible at
https://gerrit.openafs.org/#/q/topic:recvmmsg+(status:open+OR+status:merged=
)=20
and
https://gerrit.openafs.org/#/q/topic:sendmmsg+(status:open+OR+status:merged=
)=20
, 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=20
prioritized? Removing "performance sucks," from the list of why sites may=20
consider moving away from AFS would be wonderful, especially if the work=20
is complete -- or very close to complete. [It might also lead to it being=20
considered more seriously by homelab users, SMB (small and medium=20
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=20
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=20
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=20
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=20
--=_alternative 000D02E2862586CE_=
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
<span style=3D" font-size:10pt;font-family:sans-serif">Hi Ben,</span><br><b=
r><span style=3D" font-size:10pt;font-family:sans-serif">We have been impor=
ting
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.</span><br><br><span style=3D" font=
-size:10pt;font-family:sans-serif">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 :).</span><br><span style=3D=
" font-size:10pt;font-family:sans-serif"><br>John Janosik<br>jpjanosi@us.ib=
m.com</span><br><br><br><br><span style=3D" font-size:9pt;color:#5f5f5f;fon=
t-family:sans-serif">From:
</span><span style=3D" font-size:9pt;font-family=
:sans-serif">Benjamin
Kaduk <kaduk@mit.edu></span><br><span style=3D" font-size:9pt;color:#=
5f5f5f;font-family:sans-serif">To:
</span><span style=3D" font-size:9pt;font-family=
:sans-serif">sweetpotatopie2021
<sweetpotatopie2021@protonmail.com></span><br><span style=3D" font-si=
ze:9pt;color:#5f5f5f;font-family:sans-serif">Cc:
</span><span style=3D" font-size:9pt;font-family=
:sans-serif">"openafs-devel@openafs.org"
<openafs-devel@openafs.org></span><br><span style=3D" font-size:9pt;c=
olor:#5f5f5f;font-family:sans-serif">Date:
</span><span style=3D" font-size:9pt;font-family=
:sans-serif">05/06/2021
09:00 PM</span><br><span style=3D" font-size:9pt;color:#5f5f5f;font-family:=
sans-serif">Subject:
</span><span style=3D" font-size:9pt;font-family=
:sans-serif">[EXTERNAL]
Re: [OpenAFS-devel] Andrew Deason's OpenAFS RX performance patches</span><b=
r><span style=3D" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Sent
by: </span><span style=3D" font-size:9pt;font-fa=
mily:sans-serif">openafs-devel-admin@openafs.org</span><br><hr noshade><br>=
<br><br><tt><span style=3D" font-size:10pt">Hi JR,<br><br>On Wed, May 05, 2=
021 at 02:48:39PM +0000, sweetpotatopie2021 wrote:<br>> Dear developers,=
<br>> <br>> First, a shout-out. I'd like to say a big "Thank you=
!" for
the work that you do supporting OpenAFS by addressing security vulnerabilit=
ies
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.<br>> <br>> 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 <</span></tt><a =
href=3D"https://openafs-workshop.org/2019/schedule/how-to-saturate-a-10g-li=
nk-with-an-openafs-rx-fileserver/"><tt><span style=3D" font-size:10pt">http=
s://openafs-workshop.org/2019/schedule/how-to-saturate-a-10g-link-with-an-o=
penafs-rx-fileserver/</span></tt></a><tt><span style=3D" font-size:10pt">&g=
t;.<br>> <br>> 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.<br><br>The patches are visible at<br></span></=
tt><a href=3D"https://gerrit.openafs.org/#/q/topic:recvmmsg+(status:open+OR=
+status:merged)"><tt><span style=3D" font-size:10pt">https://gerrit.openafs=
.org/#/q/topic:recvmmsg+(status:open+OR+status:merged)</span></tt></a><tt><=
span style=3D" font-size:10pt"><br>and<br></span></tt><a href=3D"https://ge=
rrit.openafs.org/#/q/topic:sendmmsg+(status:open+OR+status:merged)"><tt><sp=
an style=3D" font-size:10pt">https://gerrit.openafs.org/#/q/topic:sendmmsg+=
(status:open+OR+status:merged)</span></tt></a><tt><span style=3D" font-size=
:10pt"><br>, and you are correct, the changes that actually have a performa=
nce impact<br>have not been merged yet. (Some of the earlier cleanup =
commits have
been<br>merged.)<br><br>> 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.]<br><br>I'm sad to say that the main bo=
ttleneck here is myself. I'm the only<br>person currently doing merge=
s to master, and my time is spread quite thin<br>(I'm an IETF Security Area=
Director, which is something that takes at least<br>15 hours a week and ca=
n take as much time as is available). This
work is<br>also competing for review time with patches to provide OS suppor=
t for new<br>OS versions, other bugfixes and cleanup that come in, rxgk sup=
port, and
the<br>underlying changes needed to bring in rxgk support. It's not a=
ll
getting<br>done, and that's not something I'm happy about, but I also don't=
have a<br>clear path for changing that in the near future.<br><br>The main=
thing that would help to get these changes merged would be careful<br>code=
review (though most of these already have received positive reviews,<br>so=
only a truly careful review would be expected to find new issues), and<br>=
reports of successful stress testing of the code.<br><br>-Ben<br>__________=
_____________________________________<br>OpenAFS-devel mailing list<br>Open=
AFS-devel@openafs.org<br></span></tt><a href=3D"https://lists.openafs.org/m=
ailman/listinfo/openafs-devel"><tt><span style=3D" font-size:10pt">https://=
lists.openafs.org/mailman/listinfo/openafs-devel</span></tt></a><tt><span s=
tyle=3D" font-size:10pt"><br><br></span></tt><br><br><BR>
--=_alternative 000D02E2862586CE_=--