On Tue, 11 Oct 2011 14:16:36 +0400
Pavel Shilovsky <[email protected]> wrote:

> 2011/10/11 Pavel Shilovsky <[email protected]>:
> > 2011/10/4 Jeff Layton <[email protected]>:
> >> On Tue, 4 Oct 2011 13:04:19 +0400
> >> Pavel Shilovsky <[email protected]> wrote:
> >>
> >>> 2011/8/27 Pavel Shilovsky <[email protected]>:
> >>> > 2011/8/26 Jeff Layton <[email protected]>:
> >>> >> 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 [email protected]
> >>> >> 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 <[email protected]>
> >>
> >
> > 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 <[email protected]>
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to