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;
Subject: [PATCH RFC 0/4] Encode NFSv4 attributes via a branch table
From:   Chuck Lever <cel@kernel.org>
To:     linux-nfs@vger.kernel.org
Cc:     Chuck Lever <chuck.lever@oracle.com>
Date:   Thu, 29 Jun 2023 21:34:34 -0400
Message-ID: <168808788945.7728.6965361432016501208.stgit@manet.1015granger.net>
User-Agent: StGit/1.5
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Precedence: bulk

Here's something just for fun. I've converted nfsd4_encode_fattr4()
to use a bitmask loop, calling an encode helper for each attribute
to be encoded. Rotten tomatoes and gold stars are both acceptible.

I was hoping for a bit of a performance gain because encode_fattr4
is called so very often, but there was not much difference at all.

The main benefit here is the hard scope boundary for each of the
separate attribute encoders -- that makes for safer code that is
easier to reason about, and might even be more straightforward to
convert to machine-generated code, if we ever want to do that.

And notably it will automatically encode the attributes in bitmask
order.

There are a few readability improvements that could be done, like
defining meaningfully-named macros for the bit positions. The ones
we have now are not directly usable for table indices. It might get
us another step closer to the XDR specification if we could find a
way to encode the whole bitmask in a single loop.

---

Chuck Lever (4):
      NFSD: Add struct nfsd4_fattr_args
      NFSD: Encode attributes in WORD0 using a bitmask loop
      NFSD: Encode attributes in WORD1 using a bitmask loop
      NFSD: Encode attributes in WORD2 using a bitmask loop


 fs/nfsd/nfs4xdr.c | 1089 +++++++++++++++++++++++++++------------------
 1 file changed, 657 insertions(+), 432 deletions(-)

--
Chuck Lever