Skip to contentSkip to conversation

nfs: RPC_MAX_AUTH_SIZE is in bytes

PATCH In review J. Bruce Fields 2 participants 4 messages Sep 20, 2017

Subsystems (2)
NFS client NFS server
lore
Share & tools
lore

J. Bruce Fields

author
#0 lore raw

PATCH 1/1 nfs: RPC_MAX_AUTH_SIZE is in bytes

From: "J. Bruce Fields" <[email protected]>

The units of RPC_MAX_AUTH_SIZE is bytes, not 4-byte words. This causes the client to request a larger-than-necessary session replay slot size.

Signed-off-by J. Bruce Fields <[email protected]>
---
 fs/nfs/nfs4xdr.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
fs/nfs/nfs4xdr.c +2 -2
index 37c8af003275..14ed9791ec9c 100644
@@ -1842,8 +1842,8 @@ static void encode_create_session(struct xdr_stream *xdr,
 	 * Assumes OPEN is the biggest non-idempotent compound.
 	 * 2 is the verifier.
 	 */
-	max_resp_sz_cached = (NFS4_dec_open_sz + RPC_REPHDRSIZE +
-			      RPC_MAX_AUTH_SIZE + 2) * XDR_UNIT;
+	max_resp_sz_cached = (NFS4_dec_open_sz + RPC_REPHDRSIZE + 2)
+				* XDR_UNIT + RPC_MAX_AUTH_SIZE;
 
 	encode_op_hdr(xdr, OP_CREATE_SESSION, decode_create_session_maxsz, hdr);
 	p = reserve_space(xdr, 16 + 2*28 + 20 + clnt->cl_nodelen + 12);
Signature · 1 line
2.13.5
author
#1 lore raw
Quoted 4 lines · bfields

From: "J. Bruce Fields" <[email protected]>

The units of RPC_MAX_AUTH_SIZE is bytes, not 4-byte words. This causes the client to request a larger-than-necessary session replay slot size.

By the way, the client's still asking for 3428 bytes after that, which seems high. It's mostly the fault of NFS4_MAXLABELLEN, which is 2048. I haven't spotted an improvement there yet.

Noticed because knfsd was hitting session drc cache limits much to early and failing CREATE_SESSION (hence mount). The main trouble is on the server side, so I'm relaxing the limits there (and revisiting Trond's dynamic slot renegotiation patches). But I thought I should check for any easy improvements here too.

--b.

Quoted 24 lines
Signed-off-by J. Bruce Fields <[email protected]>
---
 fs/nfs/nfs4xdr.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
fs/nfs/nfs4xdr.c +2 -2
index 37c8af003275..14ed9791ec9c 100644
@@ -1842,8 +1842,8 @@ static void encode_create_session(struct xdr_stream *xdr,
 	 * Assumes OPEN is the biggest non-idempotent compound.
 	 * 2 is the verifier.
 	 */
-	max_resp_sz_cached = (NFS4_dec_open_sz + RPC_REPHDRSIZE +
-			      RPC_MAX_AUTH_SIZE + 2) * XDR_UNIT;
+	max_resp_sz_cached = (NFS4_dec_open_sz + RPC_REPHDRSIZE + 2)
+				* XDR_UNIT + RPC_MAX_AUTH_SIZE;
 
 	encode_op_hdr(xdr, OP_CREATE_SESSION, decode_create_session_maxsz, hdr);
 	p = reserve_space(xdr, 16 + 2*28 + 20 + clnt->cl_nodelen + 12);
Signature · 1 line
2.13.5
#2 lore raw
Quoted 11 lines · J. Bruce Fields
Quoted 4 lines · bfields

From: "J. Bruce Fields" <[email protected]>

The units of RPC_MAX_AUTH_SIZE is bytes, not 4-byte words. This causes the client to request a larger-than-necessary session replay slot size.

By the way, the client's still asking for 3428 bytes after that, which seems high. It's mostly the fault of NFS4_MAXLABELLEN, which is 2048.

The maximum size of NFSv4 LOOKUP replies is also quite large, thanks to label support (IIRC). It would be nicer for NFS/RDMA, at least, if the maximum reply sizes of common operations were small (say, less than 1024 bytes).

Quoted 1 line

I haven't spotted an improvement there yet.

I haven't either.

Quoted 27 lines

Noticed because knfsd was hitting session drc cache limits much to early and failing CREATE_SESSION (hence mount). The main trouble is on the server side, so I'm relaxing the limits there (and revisiting Trond's dynamic slot renegotiation patches). But I thought I should check for any easy improvements here too.

--b.

Quoted 19 lines
Signed-off-by J. Bruce Fields <[email protected]>

---
fs/nfs/nfs4xdr.c | 4 ++--

1 file changed, 2 insertions(+), 2 deletions(-)
fs/nfs/nfs4xdr.c +2 -2
index 37c8af003275..14ed9791ec9c 100644
@@ -1842,8 +1842,8 @@ static void encode_create_session(struct xdr_stream *xdr,
 	 * Assumes OPEN is the biggest non-idempotent compound.
 	 * 2 is the verifier.
 	 */
-	max_resp_sz_cached = (NFS4_dec_open_sz + RPC_REPHDRSIZE +
-			      RPC_MAX_AUTH_SIZE + 2) * XDR_UNIT;
+	max_resp_sz_cached = (NFS4_dec_open_sz + RPC_REPHDRSIZE + 2)
+				* XDR_UNIT + RPC_MAX_AUTH_SIZE;
Quoted 9 lines
Quoted 5 lines
fs/nfs/nfs4xdr.c +0 -0
 	encode_op_hdr(xdr, OP_CREATE_SESSION, decode_create_session_maxsz, hdr);
 	p = reserve_space(xdr, 16 + 2*28 + 20 + clnt->cl_nodelen + 12);
Signature · 1 line
2.13.5

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

--
Chuck Lever

author
#3 lore raw
Quoted 18 lines · Chuck Lever
Quoted 11 lines · J. Bruce Fields
Quoted 4 lines · bfields

From: "J. Bruce Fields" <[email protected]>

The units of RPC_MAX_AUTH_SIZE is bytes, not 4-byte words. This causes the client to request a larger-than-necessary session replay slot size.

By the way, the client's still asking for 3428 bytes after that, which seems high. It's mostly the fault of NFS4_MAXLABELLEN, which is 2048.

The maximum size of NFSv4 LOOKUP replies is also quite large, thanks to label support (IIRC). It would be nicer for NFS/RDMA, at least, if the maximum reply sizes of common operations were small (say, less than 1024 bytes).

Quoted 3 lines
Quoted 1 line

I haven't spotted an improvement there yet.

I haven't either.

Session (and I assume RDMA) limits have to be negotiated pretty early, before we know server capabilities. And even if we renegotiated later--I think security label support is per-filesystem, while the connection parameters are server-wide.

So, I dunno, all I can think of is putting off fetching the security label till it's needed, but maybe that's not practical--I don't know where it's used.

Well, whatever, we can live with it.

--b.

Quoted 43 lines
Quoted 29 lines

Noticed because knfsd was hitting session drc cache limits much to early and failing CREATE_SESSION (hence mount). The main trouble is on the server side, so I'm relaxing the limits there (and revisiting Trond's dynamic slot renegotiation patches). But I thought I should check for any easy improvements here too.

--b.

Quoted 19 lines
Signed-off-by J. Bruce Fields <[email protected]>

---
fs/nfs/nfs4xdr.c | 4 ++--

1 file changed, 2 insertions(+), 2 deletions(-)
fs/nfs/nfs4xdr.c +2 -2
index 37c8af003275..14ed9791ec9c 100644
@@ -1842,8 +1842,8 @@ static void encode_create_session(struct xdr_stream *xdr,
 	 * Assumes OPEN is the biggest non-idempotent compound.
 	 * 2 is the verifier.
 	 */
-	max_resp_sz_cached = (NFS4_dec_open_sz + RPC_REPHDRSIZE +
-			      RPC_MAX_AUTH_SIZE + 2) * XDR_UNIT;
+	max_resp_sz_cached = (NFS4_dec_open_sz + RPC_REPHDRSIZE + 2)
+				* XDR_UNIT + RPC_MAX_AUTH_SIZE;
Quoted 9 lines
Quoted 5 lines
fs/nfs/nfs4xdr.c +0 -0
 	encode_op_hdr(xdr, OP_CREATE_SESSION, decode_create_session_maxsz, hdr);
 	p = reserve_space(xdr, 16 + 2*28 + 20 + clnt->cl_nodelen + 12);
Signature · 1 line
2.13.5

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

--
Chuck Lever