[PATCH] NET_DMA: remove unused dma_memcpy_to_kernel_iovec

(repost - original eaten by vger?)

Al Viro pointed out that dma_memcpy_to_kernel_iovec() really was
unreachable and thus unused.  The code originally was there to support
in-kernel dma needs, but since it remains unused, we'll pull it out.

Signed-off-by: Shannon Nelson <redacted>
---

 drivers/dma/iovlock.c |   27 ---------------------------
 1 files changed, 0 insertions(+), 27 deletions(-)

diff --git a/drivers/dma/iovlock.c b/drivers/dma/iovlock.c
index d637555..e763d72 100644
--- a/drivers/dma/iovlock.c
+++ b/drivers/dma/iovlock.c

@@ -143,29 +143,6 @@ void dma_unpin_iovec_pages(struct dma_pinned_list *pinned_list)
 	kfree(pinned_list);
 }
 
-static dma_cookie_t dma_memcpy_to_kernel_iovec(struct dma_chan *chan, struct
-	iovec *iov, unsigned char *kdata, size_t len)
-{
-	dma_cookie_t dma_cookie = 0;
-
-	while (len > 0) {
-		if (iov->iov_len) {
-			int copy = min_t(unsigned int, iov->iov_len, len);
-			dma_cookie = dma_async_memcpy_buf_to_buf(
-					chan,
-					iov->iov_base,
-					kdata,
-					copy);
-			kdata += copy;
-			len -= copy;
-			iov->iov_len -= copy;
-			iov->iov_base += copy;
-		}
-		iov++;
-	}
-
-	return dma_cookie;
-}
 
 /*
  * We have already pinned down the pages we will be using in the iovecs.

@@ -187,10 +164,6 @@ dma_cookie_t dma_memcpy_to_iovec(struct dma_chan *chan, struct iovec *iov,
 	if (!chan)
 		return memcpy_toiovec(iov, kdata, len);
 
-	/* -> kernel copies (e.g. smbfs) */
-	if (!pinned_list)
-		return dma_memcpy_to_kernel_iovec(chan, iov, kdata, len);
-
 	iovec_idx = 0;
 	while (iovec_idx < pinned_list->nr_iovecs) {
 		struct dma_page_list *page_list;

From: Shannon Nelson <redacted>
Date: Tue, 24 Jul 2007 17:36:06 -0700

(repost - original eaten by vger?)

This one seems to have made it.

Al Viro pointed out that dma_memcpy_to_kernel_iovec() really was
unreachable and thus unused.  The code originally was there to support
in-kernel dma needs, but since it remains unused, we'll pull it out.

Signed-off-by: Shannon Nelson <redacted>

This looks OK, unless some objections come up I'll merge this in
during my next round of net fixes to Linus.

From: Shannon Nelson <redacted>
Date: Tue, 24 Jul 2007 17:36:06 -0700

(repost - original eaten by vger?)

Al Viro pointed out that dma_memcpy_to_kernel_iovec() really was
unreachable and thus unused.  The code originally was there to support
in-kernel dma needs, but since it remains unused, we'll pull it out.

Signed-off-by: Shannon Nelson <redacted>

Applied, thanks Shannon.

On 7/26/07, David Miller [off-list ref] wrote:

From: Shannon Nelson <redacted>
Date: Tue, 24 Jul 2007 17:36:06 -0700

quoted

(repost - original eaten by vger?)

Al Viro pointed out that dma_memcpy_to_kernel_iovec() really was
unreachable and thus unused.  The code originally was there to support
in-kernel dma needs, but since it remains unused, we'll pull it out.

Signed-off-by: Shannon Nelson <redacted>

Applied, thanks Shannon.

NET_DMA on kernel buffer is pretty useful in ndb, iSCSI target and
initiators which uses kernel buffer to receive data. Are there any
other issues with dma-memcpy on kernel buffers, if not then following
patch makes dma_memcpy_to_kernel_iovec() reachable from tcp_recvmsg.
I tested this patch and it work fine with unh iSCSI target.


comments?

--pravin.

Index: linux-2.6.23-rc1/net/ipv4/tcp.c
===================================================================

--- linux-2.6.23-rc1.orig/net/ipv4/tcp.c	2007-07-23 02:11:00.000000000 +0530
+++ linux-2.6.23-rc1/net/ipv4/tcp.c	2007-07-30 17:43:51.000000000 +0530

@@ -1115,7 +1115,7 @@
 	int target;		/* Read at least this many bytes */
  	long timeo;
  	struct task_struct *user_recv = NULL;
-	int copied_early = 0;
+	int copied_early = 0, kernel_dma = 0;
  	struct sk_buff *skb;

  	lock_sock(sk);

@@ -1154,6 +1154,9 @@
 		    !sysctl_tcp_low_latency &&
 		    __get_cpu_var(softnet_data).net_dma) {
 			preempt_enable_no_resched();
+			if (segment_eq(get_fs(), KERNEL_DS))
+				kernel_dma = 1;
+			else
  			tp->ucopy.pinned_list =
  					dma_pin_iovec_pages(msg->msg_iov, len);
 		} else {

@@ -1362,7 +1365,7 @@

 		if (!(flags & MSG_TRUNC)) {
  #ifdef CONFIG_NET_DMA
-			if (!tp->ucopy.dma_chan && tp->ucopy.pinned_list)
+			if (!tp->ucopy.dma_chan  && (kernel_dma || tp->ucopy.pinned_list))
  				tp->ucopy.dma_chan = get_softnet_dma();

  			if (tp->ucopy.dma_chan) {

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Mon, Jul 30, 2007 at 08:09:53PM +0530, pravin wrote:

comments?

please avoid using plain sendmsg/recvmsg from kernelspace.  Adding these
segment checks is more than a bad hack and not something that should
clutter up fasthpathes.  Add to that problems with kthreads vs blocking
recvmsg and you have a bigger mess than you can handle.

On 7/26/07, David Miller [off-list ref] wrote:

quoted

From: Shannon Nelson <redacted>
Date: Tue, 24 Jul 2007 17:36:06 -0700

quoted

(repost - original eaten by vger?)

Al Viro pointed out that dma_memcpy_to_kernel_iovec() really was 
unreachable and thus unused.  The code originally was there to 
support in-kernel dma needs, but since it remains unused, 

we'll pull it out.

quoted

quoted

Signed-off-by: Shannon Nelson <redacted>

Applied, thanks Shannon.

NET_DMA on kernel buffer is pretty useful in ndb, iSCSI 
target and initiators which uses kernel buffer to receive 
data. Are there any other issues with dma-memcpy on kernel 
buffers, if not then following patch makes 
dma_memcpy_to_kernel_iovec() reachable from tcp_recvmsg.
I tested this patch and it work fine with unh iSCSI target.


comments?

--pravin.

Pravin,
	Currently, NET_DMA only has one provider in the kernel, namely
TCP.  As the driver stands now, I'd like to keep this function out since
it really wasn't being used before.  Shannon has posted patches that
will hopefully make it into 2.6.24 that allow multiple clients to
request DMA channels, so things like iSCSI, ndb, UDP, and NFS can ask
for channels without depending on TCP.  Once we get to that point, if we
see the need for the function, we can add it back.
	We have tried getting iSCSI accelerated through NET_DMA already,
and didn't see the performance boost that made it worthwhile to do.
Once the multiple client channel patches are in, we can revisit that,
since it can be done "right."

Cheers,
-PJ Waskiewicz