* TSO and IPoIB performance degradation
From: Michael S. Tsirkin @ 2006-03-06 22:34 UTC (permalink / raw)
To: netdev, openib-general, Linux Kernel Mailing List,
David S. Miller, Matt Leininger
Hello, Dave!
As you might know, the TSO patches merged into mainline kernel
since 2.6.11 have hurt performance for the simple (non-TSO)
high-speed netdevice that is IPoIB driver.
This was discussed at length here
http://openib.org/pipermail/openib-general/2005-October/012271.html
I'm trying to figure out what can be done to improve the situation.
In partucular, I'm looking at the Super TSO patch
http://oss.sgi.com/archives/netdev/2005-05/msg00889.html
merged into mainline here
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=314324121f9b94b2ca657a494cf2b9cb0e4a28cc
There, you said:
When we do ucopy receive (ie. copying directly to userspace
during tcp input processing) we attempt to delay the ACK
until cleanup_rbuf() is invoked. Most of the time this
technique works very well, and we emit one ACK advertising
the largest window.
But this explodes if the ucopy prequeue is large enough.
When the receiver is cpu limited and TSO frames are large,
the receiver is inundated with ucopy processing, such that
the ACK comes out very late. Often, this is so late that
by the time the sender gets the ACK the window has emptied
too much to be kept full by the sender.
The existing TSO code mostly avoided this by keeping the
TSO packets no larger than 1/8 of the available window.
But with the new code we can get much larger TSO frames.
So I'm trying to get a handle on it: could a solution be to simply
look at the frame size, and call tcp_send_delayed_ack from
if the frame size is no larger than 1/8?
Does this make sense?
Thanks,
--
Michael S. Tsirkin
Staff Engineer, Mellanox Technologies
^ permalink raw reply
* Re: Re: [PATCH 6/6] IB: userspace support for RDMA connection manager
From: Roland Dreier @ 2006-03-06 22:32 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel, openib-general, netdev
In-Reply-To: <20060306.142814.109285730.davem@davemloft.net>
David> Please make sure you check "x86_64 vs. x86", and then
David> something like "powerpc64 vs. powerpc32" or "sparc64
David> vs. sparc32", as those are the two different classes of ABI
David> layouts.
Yes, I tried ppc64 vs ppc and it still comes out the same.
Unfortunately I don't have any sparc handy to try.
The fundamental question seems to be whether things like
struct foo {
struct sockaddr_in6 src;
struct sockaddr_in6 dst;
};
and
struct bar {
struct sockaddr_in6 a;
__u32 b;
};
end up being packed, even though struct sockaddr_in6 is 28 bytes in
size. And as far as I can tell, they always do, I guess because the
individual fields of struct sockaddr_in6 are all <= 32 bits.
- R.
^ permalink raw reply
* Re: Re: [PATCH 6/6] IB: userspace support for RDMA connection manager
From: David S. Miller @ 2006-03-06 22:28 UTC (permalink / raw)
To: rdreier; +Cc: linux-kernel, openib-general, netdev
In-Reply-To: <adabqwj5j7b.fsf@cisco.com>
From: Roland Dreier <rdreier@cisco.com>
Date: Mon, 06 Mar 2006 13:58:32 -0800
> Sean> Unless I miss counted, they should be aligned.
> Sean> ib_user_path_rec is defined near the end of patch 1/6.
>
> You're right. struct sockaddr_in6 is 28 bytes long (not a multiple of
> 8) but gcc seems to lay everything out the same on 32-bit and 64-bit
> architectures just the same.
Please make sure you check "x86_64 vs. x86", and then something like
"powerpc64 vs. powerpc32" or "sparc64 vs. sparc32", as those are the
two different classes of ABI layouts.
^ permalink raw reply
* Re: [PATCH 2/6] IB: match connection requests based on private data
From: Sean Hefty @ 2006-03-06 22:05 UTC (permalink / raw)
To: Sean Hefty; +Cc: netdev, 'Roland Dreier', linux-kernel, openib-general
In-Reply-To: <ORSMSX401FRaqbC8wSA00000005@orsmsx401.amr.corp.intel.com>
Sean Hefty wrote:
> +static void cm_mask_compare_data(u8 *dst, u8 *src, u8 *mask)
> +{
> + int i;
> +
> + for (i = 0; i < IB_CM_PRIVATE_DATA_COMPARE_SIZE; i++)
> + dst[i] = src[i] & mask[i];
> +}
> +
> +static int cm_compare_data(struct ib_cm_private_data_compare *src_data,
> + struct ib_cm_private_data_compare *dst_data)
> +{
> + u8 src[IB_CM_PRIVATE_DATA_COMPARE_SIZE];
> + u8 dst[IB_CM_PRIVATE_DATA_COMPARE_SIZE];
Ugh. I sent the wrong patch series. This was the original set of patches,
before any feedback was incorporated. I will need to resend patches 2, 4, 5,
and 6. Sorry about this.
- Sean
^ permalink raw reply
* Re: Re: [PATCH 6/6] IB: userspace support for RDMA connection manager
From: Roland Dreier @ 2006-03-06 21:58 UTC (permalink / raw)
To: Sean Hefty; +Cc: netdev, linux-kernel, openib-general
In-Reply-To: <440CACB5.2010609@ichips.intel.com>
Sean> Unless I miss counted, they should be aligned.
Sean> ib_user_path_rec is defined near the end of patch 1/6.
You're right. struct sockaddr_in6 is 28 bytes long (not a multiple of
8) but gcc seems to lay everything out the same on 32-bit and 64-bit
architectures just the same.
- R.
^ permalink raw reply
* Re: Re: [PATCH 6/6] IB: userspace support for RDMA connection manager
From: Sean Hefty @ 2006-03-06 21:43 UTC (permalink / raw)
To: Roland Dreier; +Cc: netdev, linux-kernel, openib-general
In-Reply-To: <adak6b75k9s.fsf@cisco.com>
Roland Dreier wrote:
> On the other hand I think it would be good to let this userspace
> interface cook a little more, say in -mm.
I think that this makes sense.
- Sean
^ permalink raw reply
* Re: [PATCH 3/6] net/IB: export ip_dev_find
From: David S. Miller @ 2006-03-06 21:42 UTC (permalink / raw)
To: rdreier; +Cc: netdev, linux-kernel, openib-general
In-Reply-To: <adaslpv5kh2.fsf@cisco.com>
From: Roland Dreier <rdreier@cisco.com>
Date: Mon, 06 Mar 2006 13:31:05 -0800
> Sean> Export ip_dev_find to allow locating a net_device given an
> Sean> IP address.
>
> My plan is to queue all of this stuff for merging in 2.6.17.
>
> Is there any objection from netdev or openib-general people?
>
> I just looked back, and the original "unexport ip_dev_find()" patch
> was a de-Bunk-ing change. Now that there is a modular user, is there
> any problem with re-exporting it?
I'm fine with re-exporting it.
^ permalink raw reply
* Re: Re: [PATCH 6/6] IB: userspace support for RDMA connection manager
From: Sean Hefty @ 2006-03-06 21:42 UTC (permalink / raw)
To: Roland Dreier; +Cc: netdev, linux-kernel, openib-general
In-Reply-To: <adaoe0j5kd6.fsf@cisco.com>
Roland Dreier wrote:
> > +struct rdma_ucm_query_route_resp {
> > + __u64 node_guid;
> > + struct ib_user_path_rec ib_route[2];
> > + struct sockaddr_in6 src_addr;
> > + struct sockaddr_in6 dst_addr;
> > + __u32 num_paths;
> > + __u8 port_num;
> > + __u8 reserved[3];
> > +};
>
> Is there a 32-bit/64-bit compatibility problem here? From a quick
> look, struct sockaddr_in6 is not 8-byte aligned.
Unless I miss counted, they should be aligned. ib_user_path_rec is defined near
the end of patch 1/6.
+struct ib_user_path_rec {
+ __u8 dgid[16];
+ __u8 sgid[16];
+ __be16 dlid;
+ __be16 slid;
+ __u32 raw_traffic;
+ __be32 flow_label;
+ __u32 reversible;
+ __u32 mtu;
+ __be16 pkey;
+ __u8 hop_limit;
+ __u8 traffic_class;
+ __u8 numb_path;
+ __u8 sl;
+ __u8 mtu_selector;
+ __u8 rate_selector;
+ __u8 rate;
+ __u8 packet_life_time_selector;
+ __u8 packet_life_time;
+ __u8 preference;
+};
- Sean
^ permalink raw reply
* Re: [PATCH 6/6] IB: userspace support for RDMA connection manager
From: Roland Dreier @ 2006-03-06 21:35 UTC (permalink / raw)
To: Sean Hefty; +Cc: netdev, linux-kernel, openib-general
In-Reply-To: <ORSMSX4011XvpFVjCRG00000009@orsmsx401.amr.corp.intel.com>
I think it makes sense to merge patches 1-5 independently of this
patch. The kernel interface is needed by iSER and NFS/RDMA, and
maintaining compatibility isn't a huge deal, so we can merge it now
(assuming it looks mergable).
On the other hand I think it would be good to let this userspace
interface cook a little more, say in -mm.
Anyone have any problems with that plan?
- R.
^ permalink raw reply
* Re: [PATCH 6/6] IB: userspace support for RDMA connection manager
From: Roland Dreier @ 2006-03-06 21:33 UTC (permalink / raw)
To: Sean Hefty; +Cc: netdev, linux-kernel, openib-general
In-Reply-To: <ORSMSX4011XvpFVjCRG00000009@orsmsx401.amr.corp.intel.com>
> +struct rdma_ucm_query_route_resp {
> + __u64 node_guid;
> + struct ib_user_path_rec ib_route[2];
> + struct sockaddr_in6 src_addr;
> + struct sockaddr_in6 dst_addr;
> + __u32 num_paths;
> + __u8 port_num;
> + __u8 reserved[3];
> +};
Is there a 32-bit/64-bit compatibility problem here? From a quick
look, struct sockaddr_in6 is not 8-byte aligned.
- R.
^ permalink raw reply
* Re: [PATCH 3/6] net/IB: export ip_dev_find
From: Roland Dreier @ 2006-03-06 21:31 UTC (permalink / raw)
To: Sean Hefty; +Cc: netdev, linux-kernel, openib-general
In-Reply-To: <ORSMSX4011XvpFVjCRG00000006@orsmsx401.amr.corp.intel.com>
Sean> Export ip_dev_find to allow locating a net_device given an
Sean> IP address.
My plan is to queue all of this stuff for merging in 2.6.17.
Is there any objection from netdev or openib-general people?
I just looked back, and the original "unexport ip_dev_find()" patch
was a de-Bunk-ing change. Now that there is a modular user, is there
any problem with re-exporting it?
Thanks,
Roland
^ permalink raw reply
* Re: de2104x: interrupts before interrupt handler is registered
From: Francois Romieu @ 2006-03-06 21:17 UTC (permalink / raw)
To: Martin Michlmayr; +Cc: netdev, linux-kernel
In-Reply-To: <20060306191706.GA6947@deprecation.cyrius.com>
Martin Michlmayr <tbm@cyrius.com> :
[...]
> There's another interrupt related bug in the driver, though. I
> sometimes get a kernel panic when rsycing several 100 megs of data
> across the LAN. A picture showing the call trace can be found at
> http://www.cyrius.com/tmp/de2104x_panic.jpg
Not sure about this one, but...
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
diff --git a/drivers/net/tulip/de2104x.c b/drivers/net/tulip/de2104x.c
index d7fb3ff..49235e2 100644
--- a/drivers/net/tulip/de2104x.c
+++ b/drivers/net/tulip/de2104x.c
@@ -1455,6 +1455,8 @@ static void de_tx_timeout (struct net_de
synchronize_irq(dev->irq);
de_clean_rings(de);
+ de_init_rings(de);
+
de_init_hw(de);
netif_wake_queue(dev);
^ permalink raw reply related
* Re: de2104x: interrupts before interrupt handler is registered
From: Francois Romieu @ 2006-03-06 20:54 UTC (permalink / raw)
To: Martin Michlmayr; +Cc: netdev, linux-kernel
In-Reply-To: <20060306195953.GB10703@deprecation.cyrius.com>
Martin Michlmayr <tbm@cyrius.com> :
[...]
> By the way, I'm getting the following messages in dmesg:
>
> eth0: tx err, status 0x7fffb002
Tx underrun.
Is there anything which could induce a noticeable load on the PCI bus ?
--
Ueimor
^ permalink raw reply
* RE: RFC: move SDP from AF_INET_SDP to IPPROTO_SDP
From: Caitlin Bestler @ 2006-03-06 20:32 UTC (permalink / raw)
To: David Stevens; +Cc: Linux Kernel Mailing List, Michael S. Tsirkin, netdev
> -----Original Message-----
> From: David Stevens [mailto:dlstevens@us.ibm.com]
> Sent: Monday, March 06, 2006 12:32 PM
> To: Caitlin Bestler
> Cc: Linux Kernel Mailing List; Michael S. Tsirkin;
> netdev@vger.kernel.org
> Subject: RE: RFC: move SDP from AF_INET_SDP to IPPROTO_SDP
>
> IPPROTO_* should match the protocol field on the wire, which
> I gather isn't different. And I'm assuming there is no
> standard API defined already...
>
SDP uses the existing standard sockets API.
That was the intent in its design, and it is
the sole justification for its use. If you are
not using the existing sockets API then your
application would be *far* better off coding
directly to RDMA.
The wire protocol *is* different, it uses RDMA.
There is some justification for the application
knowing this, albeit slight ones. For example
you need to know if the peer supports SDP and
it might effect how intermediate firewalls
need to be configured.
^ permalink raw reply
* RE: RFC: move SDP from AF_INET_SDP to IPPROTO_SDP
From: David Stevens @ 2006-03-06 20:31 UTC (permalink / raw)
To: Caitlin Bestler; +Cc: Linux Kernel Mailing List, Michael S. Tsirkin, netdev
In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F12FBF33@NT-SJCA-0751.brcm.ad.broadcom.com>
IPPROTO_* should match the protocol field on the wire, which
I gather isn't different. And I'm assuming there is no standard API
defined already...
What about using a socket option?
+-DLS
^ permalink raw reply
* Re: de2104x: interrupts before interrupt handler is registered
From: Martin Michlmayr @ 2006-03-06 20:29 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, linux-kernel
In-Reply-To: <20060306202330.GB15728@electric-eye.fr.zoreil.com>
* Francois Romieu <romieu@fr.zoreil.com> [2006-03-06 21:23]:
> > http://www.cyrius.com/tmp/config-2.6.16-rc5-486
> > By the way, I'm getting the following messages in dmesg:
> netconsole appears enabled. Do you use it ?
It's a standard Debian kernel config so pretty much everything is
enabled as a module. I didn't use netconsole.
--
Martin Michlmayr
http://www.cyrius.com/
^ permalink raw reply
* Re: de2104x: interrupts before interrupt handler is registered
From: Francois Romieu @ 2006-03-06 20:23 UTC (permalink / raw)
To: Martin Michlmayr; +Cc: netdev, linux-kernel
In-Reply-To: <20060306195953.GB10703@deprecation.cyrius.com>
Martin Michlmayr <tbm@cyrius.com> :
[...]
> http://www.cyrius.com/tmp/config-2.6.16-rc5-486
>
> By the way, I'm getting the following messages in dmesg:
netconsole appears enabled. Do you use it ?
--
Ueimor
^ permalink raw reply
* RE: RFC: move SDP from AF_INET_SDP to IPPROTO_SDP
From: Caitlin Bestler @ 2006-03-06 20:16 UTC (permalink / raw)
To: David Stevens, Michael S. Tsirkin; +Cc: Linux Kernel Mailing List, netdev
> -----Original Message-----
> From: netdev-owner@vger.kernel.org
> [mailto:netdev-owner@vger.kernel.org] On Behalf Of David Stevens
> Sent: Monday, March 06, 2006 11:49 AM
> To: Michael S. Tsirkin
> Cc: Linux Kernel Mailing List; netdev@vger.kernel.org
> Subject: Re: RFC: move SDP from AF_INET_SDP to IPPROTO_SDP
>
> I don't know any details about SDP, but if there are no
> differences at the protocol layer, then neither the address
> family nor the protocol is appropriate. If it's just an API
> change, the socket type is the right selector. So, maybe
> SOCK_DIRECT to go along with SOCK_STREAM, SOCK_DGRAM, etc.
> +-DLS
That wouldn't work either. The whole point of SDP, or TOE,
is that the API is either totally unchanged or at least
essentially unchanged.
Whenever an IP Address is used (SDP/iWARP, TOE and potentially
SDP/IB) changing from AF_INET* is wrong.
For both SDP/iWARP and SDP/IB you could argue that a different
wire protocol is in use so IPPROTO_SDP is acceptable.
That's probably the best answer as long as we are stuck
under the restriction that the selection of an alternate
stack cannot be done in the exact manner that the consumer
wants it done (that is transparently to the application).
There are even some corner case scenarios where the
application might care whether their SOCK_STREAM was
carried over SDP or plain TCP. So a protocol based
distinction is probably the least misleading of all
the explicit selection options.
^ permalink raw reply
* Re: RFC: move SDP from AF_INET_SDP to IPPROTO_SDP
From: Michael S. Tsirkin @ 2006-03-06 20:16 UTC (permalink / raw)
To: David Stevens; +Cc: Linux Kernel Mailing List, netdev
In-Reply-To: <OFB3CB1E4D.355F7555-ON88257129.006C1001-88257129.006C836D@us.ibm.com>
Quoting r. David Stevens <dlstevens@us.ibm.com>:
> Subject: Re: RFC: move SDP from AF_INET_SDP to IPPROTO_SDP
>
> I don't know any details about SDP, but if there are no differences at the
> protocol layer, then neither the address family nor the protocol is
> appropriate. If it's just an API change, the socket type is the right
> selector. So, maybe SOCK_DIRECT to go along with SOCK_STREAM,
> SOCK_DGRAM, etc.
No, the API SDP implements is the regular SOCK_STREAM semantics.
The difference is in the way connections are established with
infiniband connection management messages, and data is transferred
with infiniband reliable connection send messages.
--
Michael S. Tsirkin
Staff Engineer, Mellanox Technologies
^ permalink raw reply
* Re: de2104x: interrupts before interrupt handler is registered
From: Martin Michlmayr @ 2006-03-06 19:59 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, linux-kernel
In-Reply-To: <20060306194821.GA15728@electric-eye.fr.zoreil.com>
* Francois Romieu <romieu@fr.zoreil.com> [2006-03-06 20:48]:
> > There's another interrupt related bug in the driver, though. I
> > sometimes get a kernel panic when rsycing several 100 megs of data
> > across the LAN. A picture showing the call trace can be found at
> > http://www.cyrius.com/tmp/de2104x_panic.jpg
> Can you publish the .config ?
http://www.cyrius.com/tmp/config-2.6.16-rc5-486
By the way, I'm getting the following messages in dmesg:
eth0: tx err, status 0x7fffb002
eth0: tx err, status 0x7fffb00a
eth0: tx err, status 0x7fffb002
eth0: tx err, status 0x7fffb002
eth0: tx err, status 0x7fffb002
eth0: tx err, status 0x7fffb002
eth0: tx err, status 0x7fffb002
eth0: tx err, status 0x7fffb002
eth0: tx err, status 0x7fffb002
eth0: tx err, status 0x7fffb002
eth0: tx err, status 0x7fffb002
eth0: tx err, status 0x7fffb00a
eth0: tx err, status 0x7fffb00a
eth0: tx err, status 0x7fffb00a
eth0: tx err, status 0x7fffb002
eth0: tx err, status 0x7fffb032
eth0: tx err, status 0x7fffb002
--
Martin Michlmayr
http://www.cyrius.com/
^ permalink raw reply
* Re: Discourage duplicate symbols in the kernel? [Was: Intel I/O Acc...]
From: Chris Leech @ 2006-03-06 19:56 UTC (permalink / raw)
To: Andrew Morton; +Cc: Sam Ravnborg, jeff, linux-kernel, netdev
In-Reply-To: <20060305011852.368c016e.akpm@osdl.org>
On 3/5/06, Andrew Morton <akpm@osdl.org> wrote:
> Sam Ravnborg <sam@ravnborg.org> wrote:
> >
> > On Sun, Mar 05, 2006 at 12:09:33AM -0800, Andrew Morton wrote:
> > > > +
> > > > +static inline u8 read_reg8(struct cb_device *device, unsigned int offset)
> > > > +{
> > > > + return readb(device->reg_base + offset);
> > > > +}
> > >
> > > These are fairly generic-sounding names. In fact the as-yet-unmerged tiacx
> > > wireless driver is already using these, privately to
> > > drivers/net/wireless/tiacx/pci.c.
> >
> > Do we in general discourage duplicate symbols even if they are static?
>
> Well, it's a bit irritating that it confuses ctags. But in this case, one
> set is in a header file so the risk of collisions is much-increased.
They're in a header file that's specific to a single driver, so I
don't see where a conflict would occur. But I didn't think about
ctags, and these can easily be prefixed so I'll go ahead and change
them.
- Chris
^ permalink raw reply
* Re: RFC: move SDP from AF_INET_SDP to IPPROTO_SDP
From: David Stevens @ 2006-03-06 19:48 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Linux Kernel Mailing List, netdev
In-Reply-To: <20060306190636.GA14849@mellanox.co.il>
I don't know any details about SDP, but if there are no differences at the
protocol layer, then neither the address family nor the protocol is
appropriate. If it's just an API change, the socket type is the right
selector. So, maybe SOCK_DIRECT to go along with SOCK_STREAM,
SOCK_DGRAM, etc.
+-DLS
^ permalink raw reply
* Re: de2104x: interrupts before interrupt handler is registered
From: Francois Romieu @ 2006-03-06 19:48 UTC (permalink / raw)
To: Martin Michlmayr; +Cc: netdev, linux-kernel
In-Reply-To: <20060306191706.GA6947@deprecation.cyrius.com>
Martin Michlmayr <tbm@cyrius.com> :
[...]
> There's another interrupt related bug in the driver, though. I
> sometimes get a kernel panic when rsycing several 100 megs of data
> across the LAN. A picture showing the call trace can be found at
> http://www.cyrius.com/tmp/de2104x_panic.jpg
Can you publish the .config ?
--
Ueimor
^ permalink raw reply
* Re: [PATCH 1/8] [I/OAT] DMA memcpy subsystem
From: Chris Leech @ 2006-03-06 19:48 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: linux-kernel, netdev
In-Reply-To: <20060304192030.GA6510@kvack.org>
On 3/4/06, Benjamin LaHaise <bcrl@kvack.org> wrote:
> On Fri, Mar 03, 2006 at 01:42:20PM -0800, Chris Leech wrote:
> > +void dma_async_device_unregister(struct dma_device* device)
> > +{
> ...
> > + kref_put(&device->refcount, dma_async_device_cleanup);
> > + wait_for_completion(&device->done);
> > +}
>
> This looks like a bug: device is dereferenced after it is potentially
> freed.
Actually, this is where the code is waiting to make sure it's safe to
free device. The release function for the kref completes
device->done. Each of the devices channels holds a reference to the
device. When a device is unregistered it's channels are removed from
the clients, which hold a reference for each outstanding transaction.
When all the outstanding transactions complete, the channels kref goes
to 0, and the reference to the device is dropped. When the device
kref goes to 0 the completion is set, and it's now safe to free the
memory for the device and channel structures.
I have a writeup of the locking and reference counting that I'll
finish and add in as a big comment to the code.
-Chris
^ permalink raw reply
* Re: [PATCH 1/8] [I/OAT] DMA memcpy subsystem
From: Chris Leech @ 2006-03-06 19:39 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel, netdev
In-Reply-To: <20060303.174048.14793187.davem@davemloft.net>
On 3/3/06, David S. Miller <davem@davemloft.net> wrote:
> > +static spinlock_t dma_list_lock;
>
> Please use DEFINE_SPINLOCK().
>
> > +static void dma_chan_free_rcu(struct rcu_head *rcu) {
>
> Newline before the brace please.
>
> > +static void dma_async_device_cleanup(struct kref *kref) {
>
> Newline before the brace please.
>
> > +struct dma_chan_percpu
> > +{
>
> Left brace on the same line as "struct dma_chan_percpu" please.
>
> > +struct dma_chan
> > +{
>
> Similarly.
>
> Otherwise this patch looks mostly ok.
Thanks Dave,
I'll apply these and other feedback and get updated patches generated.
- Chris
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox