Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Chuck Lever III <chuck.lever@oracle.com>
To:     Jeff Layton <jlayton@kernel.org>
CC:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH v1 1/8] NFSD: Optimize nfsd4_encode_operation()
Thread-Topic: [PATCH v1 1/8] NFSD: Optimize nfsd4_encode_operation()
Thread-Index: AQHYngbpSQ9QZL9xbkiIK/IHMr+cjK2K0oqAgARp8QCAAE7PAA==
Date:   Mon, 25 Jul 2022 20:18:17 +0000
Message-ID: <7B967688-54B3-489A-87B9-3971DDFFFE87@oracle.com>
References: <165852051841.11198.2929614302983292322.stgit@manet.1015granger.net>
 <A87D312E-1042-451A-A1B7-438351BCE368@oracle.com>
 <59534604ed620c0b7e9ec565a4f1505ca0910420.camel@kernel.org>
In-Reply-To: <59534604ed620c0b7e9ec565a4f1505ca0910420.camel@kernel.org>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?81flYzM+TfqnCxj1giKayX70HFvSBDhcf6hMAzMW0hibSyRzeDJTOmQ1pmm6?=
 =?us-ascii?Q?0XF9jC68+WeyYog4w+l9dX/srTD7NTreI/QsSDtfOt9At/NNOckSR7CqWezn?=
 =?us-ascii?Q?VZBPITF52Q/5hGH5kDqm0qtYmN8trb+gwiozLdS5+3N+Kc9AFjnKTAVRC00q?=
 =?us-ascii?Q?sssIAzWx6Dhw9DTmU8t7W84YAM2fpgdN/275oKTjYp/DUxMkAxS2rjRkyFeL?=
 =?us-ascii?Q?kHA7leeWJ/Gu18A2oLlmb4vquI+QPmtdeBqGRFRtoGTxaRFG7veNM+eQaSXd?=
 =?us-ascii?Q?GZiuZUl1+N5yy/7MXlO8BKi2tmZFFEgggTrDd/Cx2wShwuS6ImJxwTFQmp47?=
 =?us-ascii?Q?AaVJAPwaPYPGJHiqUtfILRSlYqA+8zdnz39/pcmgXMLNAvRvbU0igY7dnY3A?=
 =?us-ascii?Q?eY9ZCSATMYFbPx8B/yZfp2Oj4Nt3aYtCJXvYFj3tx29VYyyD4BGuCsKx3W0W?=
 =?us-ascii?Q?JHKlJVkqerV7uzfIMTzsV3YeUCIk+n/PFrCp/ZpKmJECvRVZt6SN5y+qJuI0?=
 =?us-ascii?Q?0f/HgiWaZxYg95spMjdsuQcEOzzmz1VAy2pUUiS1DIf5zn4E2qA+orXrlVIr?=
 =?us-ascii?Q?0DwVr2wn8BU7HVDJPNWQxgNEpFs30eZcdw749sf9/L0+vwcbKjh4QsJnNiUt?=
 =?us-ascii?Q?1knUm751lwDRBHv6XpzPKAmouIKuQQLk+5ksCTr+nkCC4bqtNRPfjyTW4AAn?=
 =?us-ascii?Q?TRzqQQthqn9a4DXh8jT9EVPkE1KyTyLoH82tVB097ZDIKsxolL3d1SRTheZG?=
 =?us-ascii?Q?8zl/GpKYXmsF1fd2H3UvUykW1fkanvIKYHE2aTdfhbysUY3QpE3ja8VH5rYZ?=
 =?us-ascii?Q?Lw/qCrG6UXcze5hZy3jdParV96LxWozz2qrqyi/qV9DdCAE45Fb3Vu/HtVEy?=
 =?us-ascii?Q?aWaw3lqRXZMa5fC+1aTTssXSbGUzUJbr0Mi+zhQ72dCJmyHxR7bMLACXbZ++?=
 =?us-ascii?Q?fEzTZePJgwKNE6MbeVwID2avTPb3WTvM0iuuhQDUR3OY3TA1fa6OlCxujqpy?=
 =?us-ascii?Q?umx+s4T1swgwy9I1XREJ7G4ckHgQS8dT2aSjqVlaDbgJHBXOrJ/8nedbqCvo?=
 =?us-ascii?Q?uWWs7iRSFkU6kwFu2mCUoTKbom6dI/6ShFx8DtKHaG+54E0zN5m5MaaBNKoY?=
 =?us-ascii?Q?k1uUfsUzxTanAC6kCYOoMxBmk2egn/cbgYNNUdNFfkd5Mg/mtAYNuPijoZp9?=
 =?us-ascii?Q?8317noylliKKfUSBt7H5VAh4RVWhXYKd9UXkaYRwNkGS+rpsPHPtZWKSXjzf?=
 =?us-ascii?Q?4tm6U0stM97hW6DfKgvAsMv9lTHicleSZPuWcXB6CMB0KhPjWyKXCjrreHH1?=
 =?us-ascii?Q?LbwE6ZK3gg2unWsf3FO3u8oymhORMNr1+7Z/SSbMucxV5gql3M0TG2kGlGAF?=
 =?us-ascii?Q?DbF7lJIGjGv1r5Qr1ko0CKBscTHuqY5bcPjyykYgkOhgZ3Y7CW3ZUbHoYZvo?=
 =?us-ascii?Q?8D+qaFnNPKophqFSzxH03okNmCsbXK5ws4TIK39RcpkpGAWKxlFocCF6XTfJ?=
 =?us-ascii?Q?wiPqhVJ0OUKq4Fs4FjkKIEXYbEBZ+iLQds9QVl9acRFlozCnTNg+7i2Zn9C2?=
 =?us-ascii?Q?lZIrMajbDi/Dfcz32tPqBQy5QZ0hV5KyvF1IyDGurOnhCa9UqfFl+SUspfnH?=
 =?us-ascii?Q?mW7ofQhmZR19hh3BrU9J2MlON3x5XKUC7eXnlrmBWN4VWHBTmNTi/ewnvt2Z?=
 =?us-ascii?Q?SeFGZA=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4821628618A42E41A4DB56D22DF6DDB4@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN0PR10MB5128.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 98af56a9-bef8-444e-1e70-08da6e7acfae
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2022 20:18:17.5237
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: yfLO41sbmYqxeFloj1Rle7CBbPYAmJXkTa37AWeHj/4iKsXBwokaHPyVjlZ74uxvJlA5CEyyMlxEmnodpAU8PQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR10MB3523
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib:17.11.122.1
 definitions=2022-07-25_12,2022-07-25_03,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 malwarescore=0 phishscore=0
 spamscore=0 mlxlogscore=999 suspectscore=0 bulkscore=0 adultscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000
 definitions=main-2207250083
X-Proofpoint-GUID: SYOrgj67cRHDOE_0eVQ-rvFZ4ih0B3tr
X-Proofpoint-ORIG-GUID: SYOrgj67cRHDOE_0eVQ-rvFZ4ih0B3tr
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org


> On Jul 25, 2022, at 11:36 AM, Jeff Layton <jlayton@kernel.org> wrote:
>=20
> On Fri, 2022-07-22 at 20:12 +0000, Chuck Lever III wrote:
>>=20
>>> On Jul 22, 2022, at 4:08 PM, Chuck Lever <chuck.lever@oracle.com> wrote=
:
>>>=20
>>> write_bytes_to_xdr_buf() is a generic way to place a variable-length
>>> data item in an already-reserved spot in the encoding buffer.
>>> However, it is costly, and here, it is unnecessary because the
>>> data item is fixed in size, the buffer destination address is
>>> always word-aligned, and the destination location is already in
>>> @p.
>>>=20
>>> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
>>> ---
>>> fs/nfsd/nfs4xdr.c |    3 +--
>>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>>=20
>>> diff --git a/fs/nfsd/nfs4xdr.c b/fs/nfsd/nfs4xdr.c
>>> index 2acea7792bb2..b52ea7d8313a 100644
>>> --- a/fs/nfsd/nfs4xdr.c
>>> +++ b/fs/nfsd/nfs4xdr.c
>>> @@ -5373,8 +5373,7 @@ nfsd4_encode_operation(struct nfsd4_compoundres *=
resp, struct nfsd4_op *op)
>>> 						so->so_replay.rp_buf, len);
>>> 	}
>>> status:
>>> -	/* Note that op->status is already in network byte order: */
>>> -	write_bytes_to_xdr_buf(xdr->buf, post_err_offset - 4, &op->status, 4)=
;
>>> +	*p =3D op->status;
>>> }
>>>=20
>>> /*=20
>>=20
>> I hit "Send" too soon. Here's the cover letter for this series.
>>=20
>> write_bytes_to_xdr_buf() is a generic mechanism by which to push
>> an arbitrary set of bytes to an arbitrary alignment within an
>> xdr_buf. It's expensive to use, though.
>>=20
>> I found several hot paths in the server's NFSv4 reply encoders
>> that write a 4-byte XDR data item on a 4-byte alignment, and
>> thus can use the classic "*p =3D cpu_to_be32(yada)" form instead
>> of write_bytes_to_xdr_buf().
>>=20
>> This series replaces some write_bytes_to_xdr_buf() call sites.
>>=20
>>=20
>> --
>> Chuck Lever
>>=20
>>=20
>>=20
>=20
> Nice cleanup. This series looks good to me (and it's a net-negative LoC
> too).
>=20
> Reviewed-by: Jeff Layton <jlayton@kernel.org>

Thanks, Jeff!


--
Chuck Lever