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
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
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
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. There's no real
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
(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 who this
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
+++
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
+++
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
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
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 +++
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
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
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
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, 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 top level as
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 best
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 keep
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/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 how
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 registers but
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 doesn't need to
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
index
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
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
30 matches
Mail list logo
