On Tue, 11 Oct 2011 14:16:36 +0400 Pavel Shilovsky <piastryyy@xxxxxxxxx> wrote: > 2011/10/11 Pavel Shilovsky <piastryyy@xxxxxxxxx>: > > 2011/10/4 Jeff Layton <jlayton@xxxxxxxxxx>: > >> On Tue, 4 Oct 2011 13:04:19 +0400 > >> Pavel Shilovsky <piastryyy@xxxxxxxxx> wrote: > >> > >>> 2011/8/27 Pavel Shilovsky <piastryyy@xxxxxxxxx>: > >>> > 2011/8/26 Jeff Layton <jlayton@xxxxxxxxxx>: > >>> >> This patchset does a fairly major cleanup and overhaul of the receive > >>> >> codepath for cifs. Aside from basic cleanup, there are two main goals: > >>> >> > >>> >> 1) allow the receive codepath to identify the mid before receiving all > >>> >> of the data for a particular SMB. > >>> >> > >>> >> ...and in turn... > >>> >> > >>> >> 2) add the ability for certain calls to receive their responses into > >>> >> their into their own set of buffers. > >>> >> > >>> >> These two changes allow cifs to break the CIFSMaxBufSize barrier for > >>> >> receives. This patchset just adds the necessary infrastructure to do > >>> >> the above. > >>> >> > >>> >> A separate patchset will follow that will overhaul cifs_readpages to use > >>> >> this infrastructure to allow for a larger rsize. > >>> >> > >>> >> Jeff Layton (16): > >>> >> cifs: clean up checkSMB > >>> >> cifs: consolidate signature generating code > >>> >> cifs: trivial: remove obsolete comment > >>> >> cifs: make smb_msg local to read_from_socket > >>> >> cifs: check for unresponsive server every time we call kernel_recvmsg > >>> >> cifs: simplify read_from_socket > >>> >> cifs: turn read_from_socket into a wrapper around a vectorized > >>> >> version > >>> >> cifs: keep a reusable kvec array for receives > >>> >> cifs: clean up check_rfc1002_header > >>> >> cifs: add a third receive phase to cifs_demultiplex_thread > >>> >> cifs: move mid finding into separate routine > >>> >> cifs: eliminate is_multi_rsp parm to find_cifs_mid > >>> >> cifs: move buffer pointers into TCP_Server_Info > >>> >> cifs: find mid earlier in receive codepath > >>> >> cifs: break out 3rd receive phase into separate function > >>> >> cifs: add a callback function to receive the rest of the frame > >>> >> > >>> >> fs/cifs/cifsencrypt.c | 103 ++-------- > >>> >> fs/cifs/cifsglob.h | 29 +++- > >>> >> fs/cifs/cifsproto.h | 7 +- > >>> >> fs/cifs/cifssmb.c | 5 +- > >>> >> fs/cifs/connect.c | 519 ++++++++++++++++++++++++++++--------------------- > >>> >> fs/cifs/misc.c | 51 +++--- > >>> >> fs/cifs/transport.c | 16 +- > >>> >> 7 files changed, 391 insertions(+), 339 deletions(-) > >>> >> > >>> >> -- > >>> >> 1.7.6 > >>> >> > >>> >> -- > >>> >> To unsubscribe from this list: send the line "unsubscribe linux-cifs" in > >>> >> the body of a message to majordomo@xxxxxxxxxxxxxxx > >>> >> More majordomo info at http://vger.kernel.org/majordomo-info.html > >>> >> > >>> > > >>> > The patchset looks good to me at the first glance. I am going to look > >>> > at this more carefully and test it in a few days. > >>> > > >>> > -- > >>> > Best regards, > >>> > Pavel Shilovsky. > >>> > > >>> > >>> Sorry for the long delay on this. As patchwork.kernel.org isn't > >>> available now, can you point me to public git repo, where I can fetch > >>> that changes, please? > >>> > >> > >> > >> Yes, I've moved my git repo to samba.org for the time being: > >> > >> http://git.samba.org/?p=jlayton/linux.git;a=summary > >> > >> See the "cifs-3.2" branch. > >> > >> -- > >> Jeff Layton <jlayton@xxxxxxxxxx> > >> > > > > I successfully tested this - the performance was closed to write one > > in my case - about 11.5 MB on 100Mbit LAN against Windows 7 server. > > Sorry for the type - "about 11.5 MB/s" > > > Seems like a very good work! > > Thanks for testing them! That's about what I get too. Working against samba is much faster since we can negotiate a much larger rsize/wsize. Thanks, -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
