All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
To: linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: [RFC][PATCHSET] reduce messing with iovecs in cifs
Date: Sat, 9 Apr 2016 21:43:02 +0100	[thread overview]
Message-ID: <20160409204301.GF25498@ZenIV.linux.org.uk> (raw)

	Now that sendmsg/recvmsg do not mangle iovecs and are capable of
handling bvec-based ->msg_iter, we can seriously reduce the amount of PITA
in cifs.  The series below is completely untested, and I would appreciate
comments/review/testing/etc.

I'll post the individual patches in followups; for those who prefer to use
git it can be found in
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git sendmsg.cifs

1/6: [net] drop 'size' argument of sock_recvmsg()
	should go via net-next; does what it says.

2/6: cifs: merge the hash calculation helpers
	takes the common parts of {cifs,smb2,smb3}_calc_signature() into a
common helper.

3/6: cifs: quit playing games with draining iovecs
	Switch smb_send_kvec() to passing msghdr (and thus iov_iter) and
make it use sock_sendmsg() - that allows to avoid draining iovecs, since
->msg_iter will be advanced properly and all we need is to keep it around
between the calls of sock_sendmsg(), rather than reinitializing it on each
loop iteration.  The same thing allows to get rid of messing with kmap()
when sending the stuff in ->rq_pages[] - ITER_BVEC will do the right thing.

4/6: cifs: no need to wank with copying and advancing iovec on recvmsg side either
	Similar to the previous - use sock_recvmsg() in cifs_readv_from_socket()
and there's no need to modify iovecs, or allocate a copy especially for
such modifications, etc.

5/6: cifs_readv_receive: use cifs_read_from_socket()
	building a 1-element iovec array for cifs_readv_from_socket() is
an overkill - simple cifs_read_from_socket() will do just fine.

6/6: cifs: don't bother with kmap on read_pages side
	Similar to the other half of 3/6: we can use ITER_BVEC for
read-into-page case.  Just make cifs_readv_from_socket() take msghdr from
caller and use a helper that would feed it a bvec-backed ->msg_iter.

WARNING: multiple messages have this Message-ID (diff)
From: Al Viro <viro@ZenIV.linux.org.uk>
To: linux-cifs@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Subject: [RFC][PATCHSET] reduce messing with iovecs in cifs
Date: Sat, 9 Apr 2016 21:43:02 +0100	[thread overview]
Message-ID: <20160409204301.GF25498@ZenIV.linux.org.uk> (raw)

	Now that sendmsg/recvmsg do not mangle iovecs and are capable of
handling bvec-based ->msg_iter, we can seriously reduce the amount of PITA
in cifs.  The series below is completely untested, and I would appreciate
comments/review/testing/etc.

I'll post the individual patches in followups; for those who prefer to use
git it can be found in
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git sendmsg.cifs

1/6: [net] drop 'size' argument of sock_recvmsg()
	should go via net-next; does what it says.

2/6: cifs: merge the hash calculation helpers
	takes the common parts of {cifs,smb2,smb3}_calc_signature() into a
common helper.

3/6: cifs: quit playing games with draining iovecs
	Switch smb_send_kvec() to passing msghdr (and thus iov_iter) and
make it use sock_sendmsg() - that allows to avoid draining iovecs, since
->msg_iter will be advanced properly and all we need is to keep it around
between the calls of sock_sendmsg(), rather than reinitializing it on each
loop iteration.  The same thing allows to get rid of messing with kmap()
when sending the stuff in ->rq_pages[] - ITER_BVEC will do the right thing.

4/6: cifs: no need to wank with copying and advancing iovec on recvmsg side either
	Similar to the previous - use sock_recvmsg() in cifs_readv_from_socket()
and there's no need to modify iovecs, or allocate a copy especially for
such modifications, etc.

5/6: cifs_readv_receive: use cifs_read_from_socket()
	building a 1-element iovec array for cifs_readv_from_socket() is
an overkill - simple cifs_read_from_socket() will do just fine.

6/6: cifs: don't bother with kmap on read_pages side
	Similar to the other half of 3/6: we can use ITER_BVEC for
read-into-page case.  Just make cifs_readv_from_socket() take msghdr from
caller and use a helper that would feed it a bvec-backed ->msg_iter.

             reply	other threads:[~2016-04-09 20:43 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-09 20:43 Al Viro [this message]
2016-04-09 20:43 ` [RFC][PATCHSET] reduce messing with iovecs in cifs Al Viro
2016-04-09 20:50 ` [PATCH 2/6] cifs: merge the hash calculation helpers Al Viro
     [not found]   ` <20160409205056.GH25498-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
2016-04-13  5:07     ` Shirish Pargaonkar
2016-04-13  5:07       ` Shirish Pargaonkar
2016-04-19 16:12   ` Jeff Layton
     [not found] ` <20160409204301.GF25498-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
2016-04-09 20:50   ` [PATCH 1/6] [net] drop 'size' argument of sock_recvmsg() Al Viro
2016-04-09 20:50     ` Al Viro
     [not found]     ` <20160409205029.GG25498-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
2016-04-19 16:03       ` Jeff Layton
2016-04-19 16:03         ` Jeff Layton
2016-04-09 20:51   ` [PATCH 3/6] cifs: quit playing games with draining iovecs Al Viro
2016-04-09 20:51     ` Al Viro
     [not found]     ` <20160409205129.GI25498-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
2016-04-19 17:53       ` Jeff Layton
2016-04-19 17:53         ` Jeff Layton
2016-04-19 22:41         ` Al Viro
2016-04-09 20:52   ` [PATCH 4/6] cifs: no need to wank with copying and advancing iovec on recvmsg side either Al Viro
2016-04-09 20:52     ` Al Viro
     [not found]     ` <20160409205210.GJ25498-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
2016-04-19 17:55       ` Jeff Layton
2016-04-19 17:55         ` Jeff Layton
2016-04-09 20:52   ` [PATCH 5/6] cifs_readv_receive: use cifs_read_from_socket() Al Viro
2016-04-09 20:52     ` Al Viro
     [not found]     ` <20160409205236.GK25498-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
2016-04-19 15:01       ` Jeff Layton
2016-04-19 15:01         ` Jeff Layton
2016-04-09 20:53   ` [PATCH 6/6] cifs: don't bother with kmap on read_pages side Al Viro
2016-04-09 20:53     ` Al Viro
     [not found]     ` <20160409205304.GL25498-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
2016-04-19 18:24       ` Jeff Layton
2016-04-19 18:24         ` Jeff Layton
2016-04-11  2:43   ` [RFC][PATCHSET] reduce messing with iovecs in cifs Shirish Pargaonkar
2016-04-11  2:43     ` Shirish Pargaonkar
2016-04-25  3:22   ` Steve French
2016-04-25  3:22     ` Steve French

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160409204301.GF25498@ZenIV.linux.org.uk \
    --to=viro-3bdd1+5odreifsdqtta3olvcufugdwfn@public.gmane.org \
    --cc=linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.