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:     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+cjK2K0oqA
Date:   Fri, 22 Jul 2022 20:12:00 +0000
Message-ID: <A87D312E-1042-451A-A1B7-438351BCE368@oracle.com>
References: <165852051841.11198.2929614302983292322.stgit@manet.1015granger.net>
In-Reply-To: <165852051841.11198.2929614302983292322.stgit@manet.1015granger.net>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?2X4hilqVPYvsAkriUj4WAEmp+457xdHCnwH1m+kP8PhUDMk1nuurXAfMY6WQ?=
 =?us-ascii?Q?cNh3kBQNId1+B7yTkhga1xRFqMD/Zk6OWhsJaACFQWhD/P/Iu5OEprwNtP11?=
 =?us-ascii?Q?AM/2gyiswcuvaY6b87h7eP4dhHwDhHdNhGyk345VNYrdh8UXq0I3l6GLYdRX?=
 =?us-ascii?Q?fiIGOMhxRUDoQzbajQPhFJm+4RuL3iP3TQOiq3jsCWaTLZ+6kw4DbrFT893a?=
 =?us-ascii?Q?9kcsdtnV6oDg5M5FOUrhSc6FoHbyDnUxjDYldLhvWTpss9Eshdu79LX74oiD?=
 =?us-ascii?Q?Z+A9hkUoa0772kgw1MYTKXz+WwPxFeTgWRvB4OweuJ8mAQNTiAtxvNESlRjt?=
 =?us-ascii?Q?OcrU/bLsmMqpRNTWbdAeXe5lm05AGdbs5RGNEztpm3H9StHBqatUqQ/M+2Q3?=
 =?us-ascii?Q?AYcVdw51ceZahRNHVm9NpwIJoAgP2xDhNmsJFNAtV9d5OVOctgpG4zq2+o12?=
 =?us-ascii?Q?52Javxaz2URl6hCd/L2yX95uz1xayUCeUBaf5YWa3dVFk/Ba5brWwxlIviJY?=
 =?us-ascii?Q?U7LQztCniRSeUZvjvGYa6gEVpQKculWhCPpReOPISpQtfyL8MUr6HSxGNTXF?=
 =?us-ascii?Q?heAzcKyPROhbcQJrGawSPGBmJhlwmCqVp7K5ismuFc3HauNYLLwRj9kau64b?=
 =?us-ascii?Q?cd9I7zb6vOVYdiJCrL8faxWgDawT/GsE+pJ/X5C/wVC3usj9ENGNSphugVxY?=
 =?us-ascii?Q?1/bEvW78WOe851oZZvjzbjn09iFc7Ua/q3Zk7XlongsxFmAXF6qf2pNtxPd9?=
 =?us-ascii?Q?BLy3ne0U0FyR9ZiaOjub3Nm1xD5qgvtYMMajak6qVMGVLL1mP56cnpCeJud8?=
 =?us-ascii?Q?GiNNdXgP0BXuzWPixa0DEE+IIzy5Ojnbm6aPMe+1L6W5MtCgeQLI1dAqgJtS?=
 =?us-ascii?Q?ZzBwAubf65bC2uJPIXv1o37pTjILZHN/YKMvuKDJ8Dy1ZP7IU+iF1TspDgKd?=
 =?us-ascii?Q?6u+O1cvC7QodJualElPT0l96kDPmKnrnx6EYvz6LYnKXjvr+ks8QP9S3Go5r?=
 =?us-ascii?Q?bxXIkz5SVvoELquk7joO2CVDh109B6cBTySvu3wjCKnRU2WUdVD/CDG26L6h?=
 =?us-ascii?Q?o2ccJ3ZBayvxeCK4KitokMBJ7AIaqa1Ud8ESNn4VcuQAuTPXQWY47EBjHKw2?=
 =?us-ascii?Q?r3ny1r0X7XkkcmldH48K4oYA5C4cnWfxQJ9fRwohCmKOPdMVUyjannZxGbBL?=
 =?us-ascii?Q?I1FWMSYXWNTsjMn4WWKY8AAzTDfRMretfQylsfoF/mkYD2VRYYAvYfBhttuo?=
 =?us-ascii?Q?UN7o4eCmal6F/vM3lvWqEo0xIxKvJZ9Tjwi752Dmi2Fs5EdqeF9PVRbr6Ucz?=
 =?us-ascii?Q?DqV3ow9dZtN6hqY2SspHBmDloLcVlx7ImYF0oTItRzp697mWfjTTNxs42LYz?=
 =?us-ascii?Q?/AzsE77YgaNLiLIxavmeMo1z/iDGu8KbacvnUSOSM7Gy4Y+h+hbCugDYQUzy?=
 =?us-ascii?Q?5TONSVUSDkenNJ+eUaZ+rM1hAHkUc1DlaTx4Uz0uEmBavg+BhyMva2Xb4J0d?=
 =?us-ascii?Q?c5oLa2mziPJu7f2mRrBzLn8D7VP61r1MVE8cwdPNBvXOpubpAD9IJ0F3ZnL2?=
 =?us-ascii?Q?Lc4I3InDYt7E7/FSiPRvudMLX+4st4wIm65hL3f2/LX6oMY6H3hbm3CE7t83?=
 =?us-ascii?Q?DA=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <F1215133E23BDC47BEDBF990C0EB6BFA@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: fe5a68d5-49ea-487e-fff7-08da6c1e6f93
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2022 20:12:00.2510
 (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: LVX0VyBX+46mGDWowZ/3D8gg+wXVZ3uNFA0k0pDkKSliFT674agPVymnMporIBaFBzhKck6hzjJka0FkX9Dy/A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR10MB3182
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-22_06,2022-07-21_02,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 bulkscore=0 malwarescore=0
 mlxscore=0 phishscore=0 mlxlogscore=999 suspectscore=0 adultscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000
 definitions=main-2207220082
X-Proofpoint-GUID: 9ogBl0Z2FuHBPhCz1qMgpbjAxXgPx3S8
X-Proofpoint-ORIG-GUID: 9ogBl0Z2FuHBPhCz1qMgpbjAxXgPx3S8
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 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 *re=
sp, 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

I hit "Send" too soon. Here's the cover letter for this series.

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.

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().

This series replaces some write_bytes_to_xdr_buf() call sites.


--
Chuck Lever