Add maximum p9 header size to MSIZE to make sure we can
have page aligned data.
Signed-off-by: Eric Van Hensbergen <[email protected]>
---
net/9p/client.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/9p/client.c b/net/9p/client.c
index fef6516a0639..416baf2f1edf 100644
--- a/net/9p/client.c
+++ b/net/9p/client.c
@@ -28,7 +28,7 @@
#define CREATE_TRACE_POINTS
#include <trace/events/9p.h>
-#define DEFAULT_MSIZE (128 * 1024)
+#define DEFAULT_MSIZE ((128 * 1024) + P9_HDRSZ)
/* Client Option Parsing (code inspired by NFS code)
* - a little lazy - parse all client options
--
2.37.2
On Saturday, December 17, 2022 7:52:05 PM CET Eric Van Hensbergen wrote:
> Add maximum p9 header size to MSIZE to make sure we can
> have page aligned data.
>
> Signed-off-by: Eric Van Hensbergen <[email protected]>
> ---
> net/9p/client.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/9p/client.c b/net/9p/client.c
> index fef6516a0639..416baf2f1edf 100644
> --- a/net/9p/client.c
> +++ b/net/9p/client.c
> @@ -28,7 +28,7 @@
> #define CREATE_TRACE_POINTS
> #include <trace/events/9p.h>
>
> -#define DEFAULT_MSIZE (128 * 1024)
> +#define DEFAULT_MSIZE ((128 * 1024) + P9_HDRSZ)
Adding 7 would make what page aligned exactly, the payload? And how?
>
> /* Client Option Parsing (code inspired by NFS code)
> * - a little lazy - parse all client options
>
ron minnich wrote on Sun, Dec 18, 2022 at 08:50:18AM -0800:
> it's fine. tbh, I doubt the fact that you were fetching 31 vs 32 pages
> mattered as much as the fact that you weren't fetching *4k at a time* :-)
Yes, I think we can just blanket this as +4k and it wouldn't change
much; I've been using 1MB+4k for rdma in previous tests...
We still aren't doing things 4k at a time with this though, I'd suggest
rounding down the rsize > msize check in p9_client_read_once():
if (!rsize || rsize > clnt->msize - P9_IOHDRSZ)
rsize = clnt->msize - P9_IOHDRSZ;
to something that's better aligned; for some reason I thought we had
that already. . . but thinking again the sizes are probably driven by
the cache and will be 4k multiples already?
> > -#define DEFAULT_MSIZE (128 * 1024)
> > +/* DEFAULT MSIZE = 32 pages worth of payload + P9_HDRSZ +
> > + * room for write (16 extra) or read (11 extra) operands.
> > + */
> > +
> > +#define DEFAULT_MSIZE ((128 * 1024) + P9_HDRSZ + 16)
There's P9_IOHDRSZ for that ;)
But I guess with the comment it doesn't matter much either way.
--
Dominique
Oh crap - I’m such an idiot - yeah IOHDRSZ was what I meant to use in the first place. Although I am left wondering why IOHDRSZ is 24 - It does seem to be one extra byte, but I won’t begrudge lucho for going for an even number.
I’ll fix this up before re-releasing the patchset. I’m just finishing breaking up my write back fixes to make them a bit more consumable as a patch.
-eric
> On Dec 18, 2022, at 1:46 PM, [email protected] wrote:
>
> ron minnich wrote on Sun, Dec 18, 2022 at 08:50:18AM -0800:
>> it's fine. tbh, I doubt the fact that you were fetching 31 vs 32 pages
>> mattered as much as the fact that you weren't fetching *4k at a time* :-)
>
> Yes, I think we can just blanket this as +4k and it wouldn't change
> much; I've been using 1MB+4k for rdma in previous tests...
>
> We still aren't doing things 4k at a time with this though, I'd suggest
> rounding down the rsize > msize check in p9_client_read_once():
>
> if (!rsize || rsize > clnt->msize - P9_IOHDRSZ)
> rsize = clnt->msize - P9_IOHDRSZ;
>
> to something that's better aligned; for some reason I thought we had
> that already. . . but thinking again the sizes are probably driven by
> the cache and will be 4k multiples already?
>
>>> -#define DEFAULT_MSIZE (128 * 1024)
>>> +/* DEFAULT MSIZE = 32 pages worth of payload + P9_HDRSZ +
>>> + * room for write (16 extra) or read (11 extra) operands.
>>> + */
>>> +
>>> +#define DEFAULT_MSIZE ((128 * 1024) + P9_HDRSZ + 16)
>
> There's P9_IOHDRSZ for that ;)
>
> But I guess with the comment it doesn't matter much either way.
>
> --
> Dominique