Re: [Nfs-ganesha-devel] zero-copy read

[Matt Benjamin]

No, you won't.

Matt

On Sun, Mar 11, 2018 at 7:15 AM, William Allen Simpson
 wrote:
> On 3/10/18 11:18 AM, Matt Benjamin wrote:
>>
>> Marcus has code that prototypes using gss_iov from mit-krb5 1.1.12.  I
>> recall describing this to you in 2013.
>>
> That would be surprising, as I didn't start working on this project
> until a year or so later than that
>
> Anyway, last year Marcus sent me a link to his prototype.  It's
> hopelessly out of date by now.  I'll need to start over.



-- 

Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103

http://www.redhat.com/en/technologies/storage

tel.  734-821-5101
fax.  734-769-8938
cel.  734-216-5309

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] zero-copy read

[William Allen Simpson]

On 3/11/18 7:15 AM, William Allen Simpson wrote:

On 3/10/18 11:18 AM, Matt Benjamin wrote:

Marcus has code that prototypes using gss_iov from mit-krb5 1.1.12.  I
recall describing this to you in 2013.


That would be surprising, as I didn't start working on this project
until a year or so later than that

Anyway, last year Marcus sent me a link to his prototype.  It's
hopelessly out of date by now.  I'll need to start over.


And isn't there anymore in any case.  Did somebody do housecleaning?

  g...@github.com:linuxbox2/gss2


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] zero-copy read

[William Allen Simpson]

On 3/10/18 11:18 AM, Matt Benjamin wrote:

Marcus has code that prototypes using gss_iov from mit-krb5 1.1.12.  I
recall describing this to you in 2013.


That would be surprising, as I didn't start working on this project
until a year or so later than that

Anyway, last year Marcus sent me a link to his prototype.  It's
hopelessly out of date by now.  I'll need to start over.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] zero-copy read

[Matt Benjamin]

Marcus has code that prototypes using gss_iov from mit-krb5 1.1.12.  I
recall describing this to you in 2013.

On Sat, Mar 10, 2018 at 11:12 AM, William Allen Simpson
 wrote:
> On 3/10/18 10:24 AM, William Allen Simpson wrote:
>
> But as I delved deeper, I'll have to make GSS work on vector i-o, as
> it currently requires one big buffer input.  This will be awhile.
>



-- 

Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103

http://www.redhat.com/en/technologies/storage

tel.  734-821-5101
fax.  734-769-8938
cel.  734-216-5309

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] zero-copy read

[William Allen Simpson]

On 3/10/18 10:24 AM, William Allen Simpson wrote:

Finally, and what I'll do this weekend, my attempt to edit
xdr_nfs23.c won't pass checkpatch commit, because all the headers
are still pre-1989 pre-ANSI K

Unfortunately, Red Hat Linux doesn't seem to have cproto built-in,
even though it's on the usual https://linux.die.net/man/1/cproto.


Found it, installed it, and it wouldn't work in our complex
everything is a sub-library source structure.  So I did it by regex.

But as I delved deeper, I'll have to make GSS work on vector i-o, as
it currently requires one big buffer input.  This will be awhile.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] zero-copy read

[Matt Benjamin]

Hi Bill,

On Sat, Mar 10, 2018 at 10:24 AM, William Allen Simpson
 wrote:
> Now that DanG has a workable vector i-o for read and write, I'm
> trying again to make reading zero-copy.  Man-oh-man, do we have
> our work cut out for us
>
> It seems that currently we provide a buffer to read.  Then XDR
> makes a new object, puts headers into it, makes another data_val
> and copies data into that, then it is all eventually passed to
> ntirpc where a buffer is created and all copied into that.
>
> If GSS, another copy is made.  (This one cannot be avoided.)
>
> So we're copying large amounts of data 4-5 times.   Not counting
> whatever the FSAL library call does internally.

Sounds like you have lots to work on.

>
> Then there is NFS_LOOKAHEAD_READ, and a nfs_request_lookahead.
> Could somebody explain what that is doing?

These are just tracking the ops being decoded, currently to help
decide if reqs should be cached.  It copies no data.

>
> AFAICT, the only test is in dup_req, and it won't keep the dup_req
> "because large, though idempotent".  Isn't a large read exactly
> where we'd benefit from holding onto a dup_req?

Basically, no.  The purpose of the DRC is to identify requests that
change the state of files/objects (are non-idempotent), and to satisfy
a client's retry of such a request, without re-executing it.  The goal
is not to be a data cache.

>
> NFS_LOOKAHEAD_HIGH_LATENCY is never used.

It's a constant.

>
> There are a lot of XDR tests for x_public having the pointer to
> nfs_request_lookahead, yet setting that pointer is one of the
> early things in nfs_worker_thread.c nfs_rpc_process_request().

It sets the structure in x_public so that it can be accessed from
within XDR decoders.

>
> Finally, and what I'll do this weekend, my attempt to edit
> xdr_nfs23.c won't pass checkpatch commit, because all the headers
> are still pre-1989 pre-ANSI K
>
> Unfortunately, Red Hat Linux doesn't seem to have cproto built-in,
> even though it's on the usual https://linux.die.net/man/1/cproto.
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel



-- 

Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103

http://www.redhat.com/en/technologies/storage

tel.  734-821-5101
fax.  734-769-8938
cel.  734-216-5309

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel