On 7/20/07, Al Viro <[EMAIL PROTECTED]> wrote:
AFAICS, all callers of dma_skb_copy_datagram_iovec()
are either
* recursive for fragments, pass pinned_list unchanged or
* called from tcp, with pinned_list coming from
tp->ucopy.pinned_list and only when tp->ucopy.dma_chan is
On 7/8/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
* e1000 gets feedback
* Intel disappears for months
* Intel reappears with e1000 rewrite
* you ask them for another complete (simpler) rewrite
* Intel fights tooth and nail when the driver is not accepted verboten
I don't think it must be as
On 7/6/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
OK, just looked through the driver. I think its structured inside-out
from what it should be.
* The multitude of tiny, fine-grained operations for MAC, NVM, PHY, etc.
is a signal that organization is backwards. You should be creating
hardware
On 6/29/07, Andrew Grover <[EMAIL PROTECTED]> wrote:
I think making e1000new ICH9-and-newer isn't really the best place to
split it. The Windows e1000 driver got split on the PCI->PCIe
transition, something that clearly delineated what nics one driver
supported, and the other. T
On 6/29/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
Given past history with duplicate drivers and the problems that they
cause -- I know, I've caused some of those problems :( -- I strongly
recommend against when it can be avoided.
Leaving e1000 with current hardware, and a new e1001 for newer ha
On 7/14/06, Ian Brown <[EMAIL PROTECTED]> wrote:
I came across the e1000 download for linux in intel site.
I saw that in the readme they talk about Intel(R) I/O Acceleration Technology;
According to this readme , there is support for "systems using the
Intel(R) 5000 Series
Chipsets Integrated D
(trimmed CC to just netdev)
> > One of our engineers (on the I/O AT team) has been tasked with modifying
> > the Linux kernel to properly support multiple hardware queues (both TX and
> > RX). We'll make sure that he looks at the netpoll interface as part of
> > that process.
>
> Might I ask wh
Hah, I was just writing an email covering those. I'll incorporate that
into this reponse.
On 4/20/06, Olof Johansson <[EMAIL PROTECTED]> wrote:
> I guess the overall question is, how much of this needs to be addressed
> in the implementation before merge, and how much should be done when
> more dr
Second half of the ioatdma.c diff, split up to make it past netdev size
block -- Andy
Adds a new ioatdma driver, ioatdma.c
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
drivers/dma/ioatdma.c | 805 +++
diff --git a/drivers/dma/ioatdma.c b/dr
patch 2 got blocked due to size, here is the diff in 2 parts. -- Andy
Adds a new ioatdma driver, ioatdma.c
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
drivers/dma/ioatdma.c | 805 +++
diff --git a/drivers/dma/ioatdma.c b/drivers/dma/ioatdm
Adds an async_wait_queue and some additional fields to tcp_sock, and a
dma_cookie_t to sk_buff.
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
include/linux/skbuff.h |4
include/linux/tcp.h|8
include/net/sock.h |2 ++
include/net/tcp.h |7 +++
Provides for pinning user space pages in memory, copying to iovecs,
and copying from sk_buffs including fragmented and chained sk_buffs.
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
drivers/dma/Makefile |3
drivers/dma/iovlock.c | 301 ++
Hi I'm reposting these, originally posted by Chris Leech a few weeks ago.
However, there is an extra part since I broke up one patch that was too
big for netdev last time into two (patches 2 and 3).
Of course we're always looking for more style improvement comments, but
more importantly we're po
Any socket recv of less than this ammount will not be offloaded
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
include/linux/sysctl.h |1 +
include/net/tcp.h |1 +
net/core/user_dma.c|4
net/ipv4/sysctl_net_ipv4.c | 10 ++
diff --git a/includ
Locks down user pages and sets up for DMA in tcp_recvmsg, then calls
dma_async_try_early_copy in tcp_v4_do_rcv
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
net/ipv4/tcp.c | 101 --
net/ipv4/tcp_input.c | 74
Provides an API for offloading memory copies to DMA devices
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
drivers/Kconfig |2
drivers/Makefile |1
drivers/dma/Kconfig | 13 +
drivers/dma/Makefile |1
drivers/dma/dmaengine.c | 405 +
Add an extra argument to sk_eat_skb, and make it move early copied packets
to the async_wait_queue instead of freeing them.
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
include/net/sock.h | 13 -
net/dccp/proto.c |4 ++--
net/ipv4/tcp.c |8
net/llc/af_
Attempts to allocate per-CPU DMA channels
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
drivers/dma/Kconfig | 12 +
include/linux/netdevice.h |4 ++
include/net/netdma.h | 38
net/core/dev.c| 104
Adds a new ioatdma driver, ioatdma.c
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
drivers/dma/ioatdma.c | 805 +++
diff --git a/drivers/dma/ioatdma.c b/drivers/dma/ioatdma.c
new file mode 100644
index 000..ffe47dd
--- /dev/null
+++ b/dri
Needed to be able to call tcp_cleanup_rbuf in tcp_input.c for I/OAT
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
include/net/tcp.h |2 ++
net/ipv4/tcp.c| 10 +-
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 54e4367..ca5bdaf 100644
--- a/include/net/tcp.h
+++
On 4/19/06, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Wednesday 19 April 2006 18:39, Grover, Andrew wrote:
>
> > We have posted all the performance data we have gathered so far on the
> > linux-net wiki: http://linux-net.osdl.org/index.php/I/OAT , and listed
> > the overall concerns that have been
On 3/31/06, Kumar Gala <[EMAIL PROTECTED]> wrote:
> > Currently the code updates these variables (kept per cpu) every time a
> > copy is queued. See include/linux/dmaengine.h.
>
> Might it be better to update when the transfer is done incase of an
> error?
The queueing function is really in the be
On 3/31/06, Ingo Oeser <[EMAIL PROTECTED]> wrote:
> Kumar Gala wrote:
> > Fair, but wouldn't it be better to have the association per client.
> >
> > Maybe leave the one as a summary and have a dir per client with
> > similar stats that are for each client and add a per channel summary
> > at the t
On 3/30/06, Kumar Gala <[EMAIL PROTECTED]> wrote:
> What is the utility of exporting memcpy_count, and bytes_transferred
> to userspace via sysfs? Is this really for debug (and thus should be
> under debugfs?)
Wellit's true they're useful for debugging but I would put them in
the category of
On 3/30/06, Kumar Gala <[EMAIL PROTECTED]> wrote:
> I was under the impression that the DMA engine would provide a "sync"
> cpu based memcpy (PIO) if a real HW channel wasn't avail, if this is
> left to the client that's fine. So how does the client know he
> should use normal memcpy()?
It has to
On 3/28/06, Kumar Gala <[EMAIL PROTECTED]> wrote:
> Do you only get callback when a channel is available?
Yes
> How do you
> decide to do to provide PIO to the client?
The client is responsible for using any channels it gets, or falling
back to memcpy() if it doesn't get any. (I don't understand
On 3/28/06, Kumar Gala <[EMAIL PROTECTED]> wrote:
> >> Also, what do you think about adding an operation type (MEMCPY, XOR,
> >> CRYPTO_AES, etc). We can than validate if the operation type
> >> expected is supported by the devices that exist.
> >
> > No objections, but this speculative support d
On 3/16/06, Kumar Gala <[EMAIL PROTECTED]> wrote:
> It would seem that when a client registers (or shortly there after
> when they call dma_async_client_chan_request()) they would expect to
> get the number of channels they need by some given time period.
>
> For example, lets say a client register
(resending in plain text, trimming CCs)
Thanks to everyone for taking the time to provide feedback. We're
going to go make the changes you suggested and will hopefully have the
code fixed up (and add more docs) in a few weeks.
Regards -- Andy
-
To unsubscribe from this list: send the line "unsubs
diff --git a/drivers/dma/testclient.c b/drivers/dma/testclient.c
new file mode 100644
index 000..9bfb979
--- /dev/null
+++ b/drivers/dma/testclient.c
@@ -0,0 +1,132 @@
+/***
+
+
+ Copyright(c) 2004 - 2005 Intel Corp
diff --git a/net/core/Makefile b/net/core/Makefile
index 630da0f..d02132b 100644
--- a/net/core/Makefile
+++ b/net/core/Makefile
@@ -8,7 +8,8 @@ obj-y := sock.o request_sock.o skbuff.o
obj-$(CONFIG_SYSCTL) += sysctl_net_core.o
obj-y += dev.o ethtool.o dev_mcast.o dst.o \
-
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 48f446d..fbe5116 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -66,4 +66,6 @@ source "drivers/infiniband/Kconfig"
source "drivers/sn/Kconfig"
+source "drivers/dma/Kconfig"
+
endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
As presented in our talk at this year's OLS, the Bensley platform, which
will be out in early 2006, will have an asyncronous DMA engine. It can be
used to offload copies from the CPU, such as the kernel copies of received
packets into the user buffer.
The code consists of the following section
So I was just reading planetsun.org and came across this guy's blog entry:
http://blogs.sun.com/roller/page/tron?entry=is_the_tcp_cork_socket
Now I'm really not trying to be a troll or anything here (:-) but I
was hoping someone had an opinion on if this would be worth the effort
to implement on
34 matches
Mail list logo
