Dropping NETIF_F_SG since no checksum feature.

2006-10-09 Thread Michael S. Tsirkin
Hi! I'm trying to build a network device driver supporting a very large MTU (around 64K) on top of an infiniband connection, and I've hit a couple of issues I'd appreciate some feedback on: 1. On the send side, I've set NETIF_F_SG, but hardware does not support checksum offloading, and I

Re: Dropping NETIF_F_SG since no checksum feature.

2006-10-10 Thread Michael S. Tsirkin
Quoting r. Stephen Hemminger [EMAIL PROTECTED]: Subject: Re: Dropping NETIF_F_SG since no checksum feature. On Mon, 9 Oct 2006 19:47:05 +0200 Michael S. Tsirkin [EMAIL PROTECTED] wrote: Hi! I'm trying to build a network device driver supporting a very large MTU (around 64K) on top

Re: Dropping NETIF_F_SG since no checksum feature.

2006-10-10 Thread Michael S. Tsirkin
Quoting r. Stephen Hemminger [EMAIL PROTECTED]: I'm trying to build a network device driver supporting a very large MTU (around 64K) on top of an infiniband connection, and I've hit a couple of issues I'd appreciate some feedback on: 1. On the send side, I've set

Re: Dropping NETIF_F_SG since no checksum feature.

2006-10-10 Thread Michael S. Tsirkin
Quoting r. Roland Dreier [EMAIL PROTECTED]: Subject: Re: Dropping NETIF_F_SG since no checksum feature. Michael Maybe I can patch linux to allow SG without checksum? Michael Dave, maybe you could drop a hint or two on whether this Michael is worthwhile and what are the issues

Re: Dropping NETIF_F_SG since no checksum feature.

2006-10-11 Thread Michael S. Tsirkin
Quoting r. David Miller [EMAIL PROTECTED]: Subject: Re: Dropping NETIF_F_SG since no checksum feature. From: Michael S. Tsirkin [EMAIL PROTECTED] Date: Wed, 11 Oct 2006 02:13:38 +0200 Maybe I can patch linux to allow SG without checksum? Dave, maybe you could drop a hint or two

Re: Dropping NETIF_F_SG since no checksum feature.

2006-10-11 Thread Michael S. Tsirkin
Quoting r. David Miller [EMAIL PROTECTED]: Subject: Re: Dropping NETIF_F_SG since no checksum feature. From: Michael S. Tsirkin [EMAIL PROTECTED] Date: Wed, 11 Oct 2006 11:05:04 +0200 So, it seems that if I set NETIF_F_SG but clear NETIF_F_ALL_CSUM, data will be copied over rather than

Re: Dropping NETIF_F_SG since no checksum feature.

2006-10-11 Thread Michael S. Tsirkin
, again, for drivers that want it. Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED] --- diff --git a/net/core/dev.c b/net/core/dev.c index d4a1ec3..2d731a0 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -2930,14 +2930,6 @@ #endif } } - /* Fix illegal SG+CSUM

Re: Dropping NETIF_F_SG since no checksum feature.

2006-10-11 Thread Michael S. Tsirkin
Quoting r. Steven Whitehouse [EMAIL PROTECTED]: Subject: Re: Dropping NETIF_F_SG since no checksum feature. Hi, On Wed, Oct 11, 2006 at 05:01:03PM +0200, Michael S. Tsirkin wrote: Quoting Steven Whitehouse [EMAIL PROTECTED]: ssize_t tcp_sendpage(struct socket *sock, struct page *page

Re: Dropping NETIF_F_SG since no checksum feature.

2006-10-11 Thread Michael S. Tsirkin
Quoting r. David Miller [EMAIL PROTECTED]: Subject: Re: Dropping NETIF_F_SG since no checksum feature. From: Michael S. Tsirkin [EMAIL PROTECTED] Date: Wed, 11 Oct 2006 17:01:03 +0200 Quoting Steven Whitehouse [EMAIL PROTECTED]: ssize_t tcp_sendpage(struct socket *sock, struct page

Re: Dropping NETIF_F_SG since no checksum feature.

2006-10-11 Thread Michael S. Tsirkin
Quoting r. Stephen Hemminger [EMAIL PROTECTED]: Subject: Re: Dropping NETIF_F_SG since no checksum feature. O You might want to try ignoring the check in dev.c and testing to see if there is a performance gain. It wouldn't be hard to test a modified version and validate the

Re: Dropping NETIF_F_SG since no checksum feature.

2006-10-11 Thread Michael S. Tsirkin
Quoting r. Stephen Hemminger [EMAIL PROTECTED]: Subject: Re: Dropping NETIF_F_SG since no checksum feature. On Wed, 11 Oct 2006 21:11:38 +0100 Steven Whitehouse [EMAIL PROTECTED] wrote: Hi, On Wed, Oct 11, 2006 at 05:01:03PM +0200, Michael S. Tsirkin wrote: Quoting Steven

Re: Dropping NETIF_F_SG since no checksum feature.

2006-10-12 Thread Michael S. Tsirkin
Quoting r. David Miller [EMAIL PROTECTED]: Subject: Re: Dropping NETIF_F_SG since no checksum feature. From: Michael S. Tsirkin [EMAIL PROTECTED] Date: Wed, 11 Oct 2006 23:23:39 +0200 With my patch, there is a huge performance gain by increasing MTU to 64K. And it seems the only way

Re: Dropping NETIF_F_SG since no checksum feature.

2006-10-13 Thread Michael S. Tsirkin
Quoting r. David Miller [EMAIL PROTECTED]: Subject: Re: Dropping NETIF_F_SG since no checksum feature. From: Michael S. Tsirkin [EMAIL PROTECTED] Date: Thu, 12 Oct 2006 21:12:06 +0200 Quoting r. David Miller [EMAIL PROTECTED]: Subject: Re: Dropping NETIF_F_SG since no checksum feature

Re: [PATCH v4 01/13] Linux RDMA Core Changes

2006-12-24 Thread Michael S. Tsirkin
diff --git a/drivers/infiniband/hw/mthca/mthca_cq.c b/drivers/infiniband/hw/mthca/mthca_cq.c index 283d50b..15cbd49 100644 --- a/drivers/infiniband/hw/mthca/mthca_cq.c +++ b/drivers/infiniband/hw/mthca/mthca_cq.c @@ -722,7 +722,8 @@ repoll: return err == 0 || err == -EAGAIN ? npolled

Re: [PATCH v4 01/13] Linux RDMA Core Changes

2007-01-03 Thread Michael S. Tsirkin
@@ -1373,7 +1374,7 @@ int ib_peek_cq(struct ib_cq *cq, int wc_ static inline int ib_req_notify_cq(struct ib_cq *cq, enum ib_cq_notify cq_notify) { - return cq-device-req_notify_cq(cq, cq_notify); + return cq-device-req_notify_cq(cq, cq_notify,

Re: [PATCH v4 01/13] Linux RDMA Core Changes

2007-01-03 Thread Michael S. Tsirkin
No, it won't need 2 transitions - just an extra function call, so it won't hurt performance - it would improve performance. ib_uverbs_req_notify_cq would call ib_uverbs_req_notify_cq() { ib_set_cq_udata(cq, udata)

Re: [PATCH v4 01/13] Linux RDMA Core Changes

2007-01-03 Thread Michael S. Tsirkin
I've run this code with mthca and didn't notice any performance degradation, but I wasn't specifically measuring cq_poll overhead in a tight loop... We were speaking about ib_req_notify_cq here, actually, not cq poll. So what was tested? -- MST - To unsubscribe from this list: send the line

Re: [PATCH v4 01/13] Linux RDMA Core Changes

2007-01-03 Thread Michael S. Tsirkin
I've run this code with mthca and didn't notice any performance degradation, but I wasn't specifically measuring cq_poll overhead in a tight loop... We were speaking about ib_req_notify_cq here, actually, not cq poll. So what was tested? Sorry, I meant req_notify. I didn't

Re: [PATCH v4 01/13] Linux RDMA Core Changes

2007-01-03 Thread Michael S. Tsirkin
No, it won't need 2 transitions - just an extra function call, so it won't hurt performance - it would improve performance. ib_uverbs_req_notify_cq would call ib_uverbs_req_notify_cq() { ib_set_cq_udata(cq, udata)

Re: [PATCH v4 01/13] Linux RDMA Core Changes

2007-01-03 Thread Michael S. Tsirkin
Without extra param (1000 iterations in cycles): ave 101.283 min 91 max 247 With extra param (1000 iterations in cycles): ave 103.311 min 91 max 221 A 2% hit then. Not huge, but 0 either. Convert cycles to ns (3466.727 MHz CPU): Without: 101.283 / 3466.727 = .02922us ==

Re: [PATCH v4 01/13] Linux RDMA Core Changes

2007-01-06 Thread Michael S. Tsirkin
[Felix Marti] In addition, is arming the CQ really in the performance path? - Don't apps poll the CQ as long as there are pending CQEs and only arm the CQ for notification once there is nothing left to do? If this is the case, it would mean that we waste a few cycles 'idle' cycles.

Re: [PATCH 1/10] cxgb3 - main header files

2007-01-09 Thread Michael S. Tsirkin
We also need to decide on the ib_req_notify_cq() issue. Let's clarify - do you oppose doing copy_from_user from a fixed address passed in during setup? If OK with you, this seems the best way as it is the least controversial and least disruptive one. -- MST - To unsubscribe from this list:

Repost [PATCH 1 of 3] move destructor to struct neigh_parms

2006-01-18 Thread Michael S. Tsirkin
it safely. Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED] Index: linux-2.6.15/net/core/neighbour.c === --- linux-2.6.15.orig/net/core/neighbour.c 2006-01-12 11:58:15.0 +0200 +++ linux-2.6.15/net/core/neighbour.c 2006

Re: Fwd: [PATCH 1 of 3] move destructor to struct neigh_parms

2006-01-18 Thread Michael S. Tsirkin
Quoting Shirley Ma [EMAIL PROTECTED]: Subject: Re: Fwd: [PATCH 1 of 3] move destructor to struct neigh_parms + if (neigh-parms-neigh_destructor) + (neigh-parms-neigh_destructor)(neigh); Is that safe without checking neigh-parms here?

Re: RFC: move SDP from AF_INET_SDP to IPPROTO_SDP

2006-03-06 Thread Michael S. Tsirkin
with infiniband reliable connection send messages. -- Michael S. Tsirkin Staff Engineer, Mellanox Technologies - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

TSO and IPoIB performance degradation

2006-03-06 Thread Michael S. Tsirkin
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 - To unsubscribe from this list: send

Re: [openib-general] Re: TSO and IPoIB performance degradation

2006-03-07 Thread Michael S. Tsirkin
Quoting r. Stephen Hemminger [EMAIL PROTECTED]: Is IB using NAPI or just doing netif_rx()? No, IPoIB doesn't use NAPI. -- Michael S. Tsirkin Staff Engineer, Mellanox Technologies - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED

Re: Re: TSO and IPoIB performance degradation

2006-03-08 Thread Michael S. Tsirkin
the trick without hurting TSO? Could a solution be to simply look at the frame size, and call tcp_send_delayed_ack if the frame size is small? -- Michael S. Tsirkin Staff Engineer, Mellanox Technologies - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message

Re: TSO and IPoIB performance degradation

2006-03-09 Thread Michael S. Tsirkin
even sooner than we have at least two full sized segments? Or does __tcp_ack_snd_check delay until we have at least two full sized segments? David, could you explain please? -- Michael S. Tsirkin Staff Engineer, Mellanox Technologies - To unsubscribe from this list: send the line unsubscribe

Re: TSO and IPoIB performance degradation

2006-03-09 Thread Michael S. Tsirkin
Quoting r. Michael S. Tsirkin [EMAIL PROTECTED]: Or does __tcp_ack_snd_check delay until we have at least two full sized segments? What I'm trying to say, since RFC 2525, 2.13 talks about every second full-sized segment, so following the code from __tcp_ack_snd_check, why does it do

Re: TSO and IPoIB performance degradation

2006-03-20 Thread Michael S. Tsirkin
you accept such a patch? It would be nice to get 2.6.17 back to within at least 10% of 2.6.11. -- Michael S. Tsirkin Staff Engineer, Mellanox Technologies - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http

Re: TSO and IPoIB performance degradation

2006-03-20 Thread Michael S. Tsirkin
measurements, TCP on top of IP over InfiniBand on Linux seems to hit one of these cases. Do you agree to that? -- Michael S. Tsirkin Staff Engineer, Mellanox Technologies - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo

Re: TSO and IPoIB performance degradation

2006-03-20 Thread Michael S. Tsirkin
not seem to be a way to figure it out automagically when doing this is a good idea, I proposed adding some kind of knob that will let the user apply the consideration for us. -- Michael S. Tsirkin Staff Engineer, Mellanox Technologies - To unsubscribe from this list: send the line unsubscribe

Re: TSO and IPoIB performance degradation

2006-03-20 Thread Michael S. Tsirkin
context. We were talking about stretching ACKs - while avoiding stretch ACKs is important for TCP congestion control, it's not the only mechanism. -- Michael S. Tsirkin Staff Engineer, Mellanox Technologies - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message

Re: [PATCH 6/6 v2] IB: userspace support for RDMA connection manager

2006-03-22 Thread Michael S. Tsirkin
Quoting r. Roland Dreier [EMAIL PROTECTED]: Subject: Re: [PATCH 6/6 v2] IB: userspace support for RDMA connection manager I added this patch to the rdma_cm branch in my git tree. BTW, is there some way to see your git tree e.g. with gitweb? -- Michael S. Tsirkin Staff Engineer, Mellanox

Re: lockdep question (was Re: IPoIB caused a kernel: BUG: softlockup detected on CPU#0!)

2007-03-12 Thread Michael S. Tsirkin
Quoting Ingo Molnar [EMAIL PROTECTED]: Subject: Re: lockdep question (was Re: IPoIB caused a kernel: BUG: softlockup detected on CPU#0!) * Michael S. Tsirkin [EMAIL PROTECTED] wrote: could you turn on CONFIG_SLAB_DEBUG as well? that should catch certain types of use-after-free

dst_ifdown breaks infiniband?

2007-03-18 Thread Michael S. Tsirkin
Alexey, Roland, In debugging kernel lockup that occurs with IP over InfiniBand in 2.6.21-rc4: ( https://bugs.openfabrics.org/show_bug.cgi?id=402 ) I noticed the following code in dst_ifdown: /* Dirty hack. We did it in 2.2 (in __dst_free), * we have _very_ good reasons not to repeat * this

Re: dst_ifdown breaks infiniband?

2007-03-18 Thread Michael S. Tsirkin
Quoting Alexey Kuznetsov [EMAIL PROTECTED]: Subject: Re: dst_ifdown breaks infiniband? Hello! This is not new code, and should have triggered long time ago, so I am not sure how come we are triggering this only now, but somehow this did not lead to crashes in 2.6.20 I see. I guess

Re: dst_ifdown breaks infiniband?

2007-03-18 Thread Michael S. Tsirkin
Quoting Alexey Kuznetsov [EMAIL PROTECTED]: Subject: Re: dst_ifdown breaks infiniband? Hello! This is not new code, and should have triggered long time ago, so I am not sure how come we are triggering this only now, but somehow this did not lead to crashes in 2.6.20 I see. I guess

Re: dst_ifdown breaks infiniband?

2007-03-18 Thread Michael S. Tsirkin
Quoting Alexey Kuznetsov [EMAIL PROTECTED]: Subject: Re: dst_ifdown breaks infiniband? Hello! Hmm. Something I don't understand: does the code in question not run on *each* device unregister? It does. Why do I only see this under stress? You should have some referenced

Re: dst_ifdown breaks infiniband?

2007-03-18 Thread Michael S. Tsirkin
Why is neighbour-dev changed here? It holds reference to device and prevents its destruction. If dst is held somewhere, we cannot destroy the device and deadlock while unregister. BTW, can this ever happen for the loopback device itself? Is it ever unregistered? -- MST - To unsubscribe

Re: dst_ifdown breaks infiniband?

2007-03-18 Thread Michael S. Tsirkin
It should be cleared and we should be sure it will not be destroyed before quiescent state. I'm confused. didn't you say dst_ifdown is called after quiescent state? Quiescent state should happen after dst-neighbour is invalidated. And this implies that all the users of dst-neighbour

Re: dst_ifdown breaks infiniband?

2007-03-18 Thread Michael S. Tsirkin
Quoting Alexey Kuznetsov [EMAIL PROTECTED]: Subject: Re: dst_ifdown breaks infiniband? Can dst-neighbour be changed to point to NULL instead, and the neighbour released? It should be cleared and we should be sure it will not be destroyed before quiescent state. Seems, this is the only

Re: dst_ifdown breaks infiniband?

2007-03-18 Thread Michael S. Tsirkin
Quoting Michael S. Tsirkin [EMAIL PROTECTED]: Subject: Re: dst_ifdown breaks infiniband? Quoting Alexey Kuznetsov [EMAIL PROTECTED]: Subject: Re: dst_ifdown breaks infiniband? Can dst-neighbour be changed to point to NULL instead, and the neighbour released? It should be cleared

Re: dst_ifdown breaks infiniband?

2007-03-18 Thread Michael S. Tsirkin
Quoting Michael S. Tsirkin [EMAIL PROTECTED]: Subject: Re: dst_ifdown breaks infiniband? Quoting Michael S. Tsirkin [EMAIL PROTECTED]: Subject: Re: dst_ifdown breaks infiniband? Quoting Alexey Kuznetsov [EMAIL PROTECTED]: Subject: Re: dst_ifdown breaks infiniband? Can dst

Re: [ofa-general] Re: dst_ifdown breaks infiniband?

2007-03-18 Thread Michael S. Tsirkin
Quoting Eric W. Biederman ebiederman@lnxi.com: Subject: Re: [ofa-general] Re: dst_ifdown breaks infiniband? Michael S. Tsirkin [EMAIL PROTECTED] writes: Why is neighbour-dev changed here? It holds reference to device and prevents its destruction. If dst is held somewhere, we

Re: [ofa-general] Re: dst_ifdown breaks infiniband?

2007-03-18 Thread Michael S. Tsirkin
Quoting Michael S. Tsirkin [EMAIL PROTECTED]: Subject: Re: [ofa-general] Re: dst_ifdown breaks infiniband? Quoting Eric W. Biederman ebiederman@lnxi.com: Subject: Re: [ofa-general] Re: dst_ifdown breaks infiniband? Michael S. Tsirkin [EMAIL PROTECTED] writes: Why is neighbour

Re: [ofa-general] Re: dst_ifdown breaks infiniband?

2007-03-18 Thread Michael S. Tsirkin
Quoting David Miller [EMAIL PROTECTED]: Subject: Re: [ofa-general] Re: dst_ifdown breaks infiniband? From: Michael S. Tsirkin [EMAIL PROTECTED] Date: Mon, 19 Mar 2007 00:42:34 +0200 Quoting Michael S. Tsirkin [EMAIL PROTECTED]: Subject: Re: [ofa-general] Re: dst_ifdown breaks

Re: dst_ifdown breaks infiniband?

2007-03-18 Thread Michael S. Tsirkin
Quoting Michael S. Tsirkin [EMAIL PROTECTED]: Subject: Re: dst_ifdown breaks infiniband? Quoting Michael S. Tsirkin [EMAIL PROTECTED]: Subject: Re: dst_ifdown breaks infiniband? Quoting Michael S. Tsirkin [EMAIL PROTECTED]: Subject: Re: dst_ifdown breaks infiniband? Quoting

Re: [ofa-general] Re: dst_ifdown breaks infiniband?

2007-03-19 Thread Michael S. Tsirkin
Quoting Alexey Kuznetsov [EMAIL PROTECTED]: Subject: Re: [ofa-general] Re: dst_ifdown breaks infiniband? Does this look sane (untested)? It does not, unfortunately. Instead of regular crash in infiniband you will get numerous random NULL pointer dereferences both due to dst-neighbour

Re: dst_ifdown breaks infiniband?

2007-03-19 Thread Michael S. Tsirkin
. This is an old bug, but apparently, started to get triggered more infiniband after recent multicast and connected mode changes. Fix this by delaying dev_put until the neigh_params object is removed. Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED] diff --git a/net/core/neighbour.c b/net/core

Re: dst_ifdown breaks infiniband?

2007-03-19 Thread Michael S. Tsirkin
Quoting Michael S. Tsirkin [EMAIL PROTECTED]: Subject: Re: dst_ifdown breaks infiniband? Any simpler ideas? Well, if inifiniband destructor really needs to take that lock... no. Right now I do not see. OK, this is actually not hard to fix - for infiniband, we can just look

Re: dst_ifdown breaks infiniband?

2007-03-19 Thread Michael S. Tsirkin
Quoting Alexey Kuznetsov [EMAIL PROTECTED]: Subject: Re: dst_ifdown breaks infiniband? Hello! If a device driver sets neigh_destructor in neigh_params, this could get called after the device has been unregistered and the driver module removed. It is the same problem: if

Re: dst_ifdown breaks infiniband?

2007-03-19 Thread Michael S. Tsirkin
Quoting Alexey Kuznetsov [EMAIL PROTECTED]: Subject: Re: dst_ifdown breaks infiniband? Hello! If a device driver sets neigh_destructor in neigh_params, this could get called after the device has been unregistered and the driver module removed. It is the same problem: if

Re: dst_ifdown breaks infiniband?

2007-03-19 Thread Michael S. Tsirkin
Quoting Alexey Kuznetsov [EMAIL PROTECTED]: Subject: Re: dst_ifdown breaks infiniband? Hello! infiniband sets parm-neigh_destructor, and I search for a way to prevent this destructor from being called after the module has been unloaded. Ideas? It must be called in any case to

Re: dst_ifdown breaks infiniband?

2007-03-20 Thread Michael S. Tsirkin
are experiencing these crashes. David, Alexey, what do you think about this patch? Is it right? Could this patch be considered for 2.6.21? Acked-by: Michael S. Tsirkin [EMAIL PROTECTED] I think this is enough for ipoib which is the only user of this thing. Initialization private part

Re: [PATCH 0 of 39] ipath - bug fixes, performance enhancements,and portability improvements

2006-06-30 Thread Michael S. Tsirkin
Quoting r. Bryan O'Sullivan [EMAIL PROTECTED]: Subject: [PATCH 0 of 39] ipath - bug fixes, performance enhancements,and portability improvements Hi, Andrew - These patches bring the ipath driver up to date with a number of bug fixes, performance improvements, and better PowerPC support.

Re: [PATCH 0 of 39] ipath - bug fixes, performanceenhancements,and portability improvements

2006-07-01 Thread Michael S. Tsirkin
Quoting r. Bryan O'Sullivan [EMAIL PROTECTED]: Subject: Re: [PATCH 0 of 39] ipath - bug fixes, performanceenhancements,and portability improvements On Fri, 2006-06-30 at 19:31 +0300, Michael S. Tsirkin wrote: OK, next week I'll put these into my tree, too. Thanks. The first 37

Re: [PATCH 38 of 39] IB/ipath - More changes to support InfiniPath on PowerPC 970 systems

2006-07-03 Thread Michael S. Tsirkin
Quoting r. Anton Blanchard [EMAIL PROTECTED]: Subject: Re: [PATCH 38 of 39] IB/ipath - More changes to support InfiniPath on PowerPC 970 systems Hi, Please fix the generic code if it doesn't provide the facility you need at the moment. Don't shoe horn it into your driver just to

[PATCH] IB/mthca: fix static rate returned by mthca_ah_query

2006-07-10 Thread Michael S. Tsirkin
Andrew, this has been out for a couple of days - could you drop this into -mm / push this along to Linus, please? - Forwarded message from Michael S. Tsirkin [EMAIL PROTECTED] - Please review: git://www.mellanox.co.il/~git/infiniband mst-for-2.6.18 This has the following patch: IB

[PATCH] IB/mthca: comment fix

2006-07-10 Thread Michael S. Tsirkin
modify qp as well. Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED] diff --git a/drivers/infiniband/hw/mthca/mthca_qp.c b/drivers/infiniband/hw/mthca/mthca_qp.c index 490fc78..2f3917e 100644 --- a/drivers/infiniband/hw/mthca/mthca_qp.c +++ b/drivers/infiniband/hw/mthca/mthca_qp.c @@ -1114,7

Re: [PATCH] IB/mthca: comment fix

2006-07-10 Thread Michael S. Tsirkin
Quoting r. Arjan van de Ven [EMAIL PROTECTED]: Subject: Re: [PATCH] IB/mthca: comment fix On Mon, 2006-07-10 at 14:14 +0300, Michael S. Tsirkin wrote: Hi Andrew, Here's a cosmetic patch for IB/mthca. Pls drop it into -mm and on. --- comment in mthca_qp.c makes it seem lockdep

Re: [PATCH] IB/mthca: comment fix

2006-07-10 Thread Michael S. Tsirkin
Quoting r. Arjan van de Ven [EMAIL PROTECTED]: makes sense to me; my main concern is that we document the bug that was there; unless you document such things.. these bugs tend to have a habit of resurfacing later ;) Right. Although lockdep will catch this one quickly :) -- MST - To

[PATCH updated] IB/mthca: comment fix

2006-07-10 Thread Michael S. Tsirkin
-by: Michael S. Tsirkin [EMAIL PROTECTED] diff --git a/drivers/infiniband/hw/mthca/mthca_qp.c b/drivers/infiniband/hw/mthca/mthca_qp.c index 490fc78..cd8b672 100644 --- a/drivers/infiniband/hw/mthca/mthca_qp.c +++ b/drivers/infiniband/hw/mthca/mthca_qp.c @@ -222,9 +222,8 @@ static void *get_send_wqe

[PATCH] IB/addr: gid structure alignment fix

2006-07-10 Thread Michael S. Tsirkin
] Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED] Index: gitcma/include/rdma/ib_addr.h === --- gitcma.orig/include/rdma/ib_addr.h 2006-07-09 23:41:27.0 +0300 +++ gitcma/include/rdma/ib_addr.h 2006-07-09 23:51

[PATCH] IB/cm: drop REQ when out of memory

2006-07-10 Thread Michael S. Tsirkin
Hello Andrew! Could you please drop the following in -mm and on to Linus? --- If a user of the IB CM returns -ENOMEM from their connection callback, simply drop the incoming REQ - do not attempt to send a reject. This should allow the sender to retry the request. Signed-off-by: Michael S

[PATCH] srp: fix fmr error handling

2006-07-10 Thread Michael S. Tsirkin
Andrew, could you pls drop the following in -mm and on to Linus? --- From: Vu Pham [EMAIL PROTECTED] srp_unmap_data assumes req-fmr is NULL if the request is not mapped, so we must clean it out in case of an error. Signed-off-by: Vu Pham [EMAIL PROTECTED] Signed-off-by: Michael S. Tsirkin

[PATCHv2] IB/mthca: comment fix

2006-07-10 Thread Michael S. Tsirkin
it to mthca_wq_reset. Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED] diff --git a/drivers/infiniband/hw/mthca/mthca_qp.c b/drivers/infiniband/hw/mthca/mthca_qp.c index 490fc78..cd8b672 100644 --- a/drivers/infiniband/hw/mthca/mthca_qp.c +++ b/drivers/infiniband/hw/mthca/mthca_qp.c @@ -222,9 +222,8

infiniband patch series (was Re: ipath patch series a-comin', but no IB maintainer to shepherd them)

2006-07-10 Thread Michael S. Tsirkin
Quoting r. Michael S. Tsirkin [EMAIL PROTECTED]: Yes, -mm seems like a good way to get more review. Andrew, am I using the right format to send things upstream to you? There's really a set of independent patches, so it didn't make sense to me to batch them up in a series. OK? Maybe the addition

[PATCH] IB/cm: set private data length for reject messages

2006-07-10 Thread Michael S. Tsirkin
Hi Andrew, Here's another infiniband patch that needs to go upstream. --- From: Ira Weiny [EMAIL PROTECTED] Set private data length for reject messages to the correct size. Fix from openib svn r8483. Signed-off-by: Sean Hefty [EMAIL PROTECTED] Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED

[PATCH fixed] srp: fix fmr error handling

2006-07-10 Thread Michael S. Tsirkin
if the request is not mapped, so we must clean it out in case of an error. Signed-off-by: Vu Pham [EMAIL PROTECTED] Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED] Acked-by: Roland Dreier [EMAIL PROTECTED] diff --git a/drivers/infiniband/ulp/srp/ib_srp.c b/drivers/infiniband/ulp/srp

Re: infiniband patch series (was Re: ipath patch series a-comin', but no IB maintainer to shepherd them)

2006-07-10 Thread Michael S. Tsirkin
Quoting r. Andrew Morton [EMAIL PROTECTED]: Sure. Although I am a little surprised to be be receiving them while Roland is in taking-time-off-but-not-really-doing-so mode. Well, I don't know what's up either, but Roland acked patches explicitly so I figured that's what he wants, too. -- MST

Re: InfiniBand merge plans for 2.6.19

2006-08-18 Thread Michael S. Tsirkin
Quoting r. Roland Dreier [EMAIL PROTECTED]: o I also have the following minor changes queued in the for-2.6.19 branch of infiniband.git: Cold you oplease consider IB/mthca: recover from device errors as well? -- MST - To unsubscribe from this list: send the line unsubscribe

Re: [PATCH 11/12 -Rev2] IPoIB xmit API addition

2007-07-22 Thread Michael S. Tsirkin
+ /* + * Handle skbs completion from tx_tail to wr_id. It is possible to + * handle WC's from earlier post_sends (possible multiple) in this + * iteration as we move from tx_tail to wr_id, since if the last + * WR (which is the one which had a completion request)

Re: Re: [PATCH V3 0/7] net/bonding: ADD IPoIB support for the bonding driver

2007-07-31 Thread Michael S. Tsirkin
Quoting Moni Shoua [EMAIL PROTECTED]: Subject: Re: Re: [PATCH V3 0/7] net/bonding: ADD IPoIB support for?the bonding driver Roland Dreier wrote: 1. When bonding enslaves an IPoIB device the bonding neighbor holds a reference to a cleanup function in the IPoIB drives. This makes it

Re: Re: Re: [PATCH V3 0/7] net/bonding: ADD IPoIB support for the bonding driver

2007-07-31 Thread Michael S. Tsirkin
Quoting Or Gerlitz [EMAIL PROTECTED]: Subject: Re: Re: Re: [PATCH V3 0/7] net/bonding: ADD IPoIB support for?the bonding driver Michael S. Tsirkin wrote: Maybe we could use hard_header_cache/header_cache_update methods instead of neighbour cleanup calls. To do this, it is possible

Re: [PATCH V3 0/7] net/bonding: ADD IPoIB support for the bonding driver

2007-07-31 Thread Michael S. Tsirkin
Quoting Or Gerlitz [EMAIL PROTECTED]: Subject: Re: [PATCH V3 0/7] net/bonding: ADD IPoIB support for?the?bonding driver Michael S. Tsirkin wrote: Quoting Or Gerlitz [EMAIL PROTECTED]: To be precise, bonding will copy all the symbols it copies today from the slave module (ipoib), see

Re: [ofa-general] Re: Re: Re: [PATCH V3 0/7] net/bonding: ADD IPoIB support for the bonding driver

2007-08-01 Thread Michael S. Tsirkin
Quoting Moni Shoua [EMAIL PROTECTED]: Subject: Re: [ofa-general] Re: Re: Re: [PATCH V3 0/7] net/bonding: ADD IPoIB support for?the bonding driver It's always wrong to copy symbols from another module without referencing it. Michael, It seems like the preferred approach is to

Re: InfiniBand/RDMA merge plans for 2.6.24

2007-09-18 Thread Michael S. Tsirkin
Quoting Roland Dreier [EMAIL PROTECTED]: Subject: InfiniBand/RDMA merge plans for 2.6.24 With 2.6.24 probably opening in the not-too-distant future, it's probably a good time to review what my plans are for when the merge window opens. Roland, could you merge the common TX CQ patch please?

Re: InfiniBand/RDMA merge plans for 2.6.24

2007-09-18 Thread Michael S. Tsirkin
Quoting Roland Dreier [EMAIL PROTECTED]: Subject: Re: InfiniBand/RDMA merge plans for 2.6.24 Roland, could you merge the common TX CQ patch please? It actually fixes a real problem. Yes, I will, but it collides with the net-2.6.24 NAPI rework I think, so it may not go in until a few

Re: InfiniBand/RDMA merge plans for 2.6.24

2007-09-19 Thread Michael S. Tsirkin
Missing from this list (IMPORTANT patch!): [ofa-general] [PATCH 2 of 2] IB/mlx4: Handle new FW requirement for send request prefetching, for WQE sg lists (Posted by me to list on Sept 4) {patch header: This is an addendum to Roland's commit 0e6e74162164d908edf7889ac66dca09e7505745 (June

Re: [PATCH] vhost: use kthread_run macro

2015-04-15 Thread Michael S. Tsirkin
On Tue, Apr 14, 2015 at 05:32:34PM -0400, Bandan Das wrote: Code Cleanup, kthread_run is a convenient wrapper around kthread_create() that even wakes up the process for us. Use it and remove no longer needed temp task_struct variable. Signed-off-by: Bandan Das b...@redhat.com ---

Re: [PATCH net-next] net: replace last open coded skb_orphan_frags with function call

2015-06-08 Thread Michael S. Tsirkin
that to the last remaining open coded site. Signed-off-by: Willem de Bruijn will...@google.com Acked-by: Michael S. Tsirkin m...@redhat.com --- net/core/dev.c | 11 ++- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/net/core/dev.c b/net/core/dev.c index 0602e91

Re: [PATCH RFC] tun, macvtap: higher order allocations for skbs

2015-06-18 Thread Michael S. Tsirkin
On Thu, Jun 18, 2015 at 12:54:44PM +0200, Christian Borntraeger wrote: Am 18.06.2015 um 12:20 schrieb Michael S. Tsirkin: Needs more testing. Anyone see anything wrong with this? Can you explain the motivation? FWIW, basic networking between two guest over macvtap still seems to work

Re: [RFC] virtio_net: Adding tx_timeout function.

2015-06-24 Thread Michael S. Tsirkin
On Tue, Jun 23, 2015 at 10:44:29PM -0300, Julio Faracco wrote: virtio_net paravirtualized driver does not have a tx_timeout() function to guarantee that the driver will recover properly after receiving a timeout during a transmission of a packet. This patch add this feature and throw a timeout

Re: [PATCH RFC] vhost: add ioctl to query nregions upper limit

2015-06-24 Thread Michael S. Tsirkin
On Wed, Jun 24, 2015 at 04:07:27PM +0200, Igor Mammedov wrote: On Wed, 24 Jun 2015 15:49:27 +0200 Michael S. Tsirkin m...@redhat.com wrote: Userspace currently simply tries to give vhost as many regions as it happens to have, but you only have the mem table when you have initialized

[PATCH RFC] vhost: add ioctl to query nregions upper limit

2015-06-24 Thread Michael S. Tsirkin
that the current userspace behaviour (trial and error) is required, just in case we want it back. Signed-off-by: Michael S. Tsirkin m...@redhat.com Cc: Igor Mammedov imamm...@redhat.com Cc: Paolo Bonzini pbonz...@redhat.com --- include/uapi/linux/vhost.h | 17 - drivers/vhost/vhost.c

Re: [PATCH RFC] vhost: add ioctl to query nregions upper limit

2015-06-24 Thread Michael S. Tsirkin
On Wed, Jun 24, 2015 at 04:52:29PM +0200, Igor Mammedov wrote: On Wed, 24 Jun 2015 16:17:46 +0200 Michael S. Tsirkin m...@redhat.com wrote: On Wed, Jun 24, 2015 at 04:07:27PM +0200, Igor Mammedov wrote: On Wed, 24 Jun 2015 15:49:27 +0200 Michael S. Tsirkin m...@redhat.com wrote

Re: [PATCH net-next] Increase limit of macvtap queues

2015-06-14 Thread Michael S. Tsirkin
On Fri, Jun 12, 2015 at 07:00:28PM +0530, Pankaj Gupta wrote: Macvtap should be compatible with tuntap for maximum number of queues. '1059590254fa9dce9cafc4f07d1103dbec415e76' removes the limitation and increases number of queues in tuntap. Now, Its safe to increase number of queues in Macvtap

[PATCH RFC] tun, macvtap: higher order allocations for skbs

2015-06-18 Thread Michael S. Tsirkin
Needs more testing. Anyone see anything wrong with this? Signed-off-by: Michael S. Tsirkin m...@redhat.com --- drivers/net/macvtap.c | 2 +- drivers/net/tun.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c index 928f3f4

Re: [RESUBMIT Patch 1/1] net: replace if()/BUG with BUG_ON

2015-06-17 Thread Michael S. Tsirkin
On Wed, Jun 17, 2015 at 10:06:01AM +0530, Maninder Singh wrote: Use BUG_ON(condition) instead of if(condition)/BUG() . Signed-off-by: Maninder Singh maninder...@samsung.com Reviewed-by: Akhilesh Kumar akhiles...@samsung.com Why not? Acked-by: Michael S. Tsirkin m...@redhat.com --- net

Re: [PATCH v6 2/8] tun: add tun_is_little_endian() helper

2015-06-01 Thread Michael S. Tsirkin
On Fri, Apr 24, 2015 at 02:24:38PM +0200, Greg Kurz wrote: Signed-off-by: Greg Kurz gk...@linux.vnet.ibm.com Dave, could you please ack merging this through the virtio tree? --- drivers/net/tun.c |9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git

Re: [PATCH v6 3/8] macvtap: introduce macvtap_is_little_endian() helper

2015-06-01 Thread Michael S. Tsirkin
On Fri, Apr 24, 2015 at 02:24:48PM +0200, Greg Kurz wrote: Signed-off-by: Greg Kurz gk...@linux.vnet.ibm.com Dave, could you pls ack merging this through the virtio tree? --- drivers/net/macvtap.c |9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git

[PULL] vhost: cleanups and fixes

2015-06-01 Thread Michael S. Tsirkin
it. Signed-off-by: Michael S. Tsirkin m...@redhat.com Mikko Rapeli (1): include/uapi/linux/virtio_balloon.h: include linux/virtio_types.h include/uapi/linux/virtio_balloon.h | 1 + 1 file changed, 1 insertion

Re: [PULL] vhost: cleanups and fixes

2015-06-01 Thread Michael S. Tsirkin
The mail subject is wrong or course - the one in the pull request is correct. Sorry about that - this shouldn't interfere with merging it, I'll correct it for future requests. -- MST -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to

[PULL] virtio/vhost: cross endian support

2015-07-01 Thread Michael S. Tsirkin
but none fix regressions and none are related to these ones, so it looks like a good time for a merge for -rc1. Signed-off-by: Michael S. Tsirkin m...@redhat.com Gerd Hoffmann (1): virtio-pci: alloc only resources actually

Re: [RFC] virtio_net: Adding tx_timeout function.

2015-07-01 Thread Michael S. Tsirkin
On Wed, Jun 24, 2015 at 10:31:09PM -0300, Julio Faracco wrote: 2015-06-24 3:10 GMT-03:00 Michael S. Tsirkin m...@redhat.com: On Tue, Jun 23, 2015 at 10:44:29PM -0300, Julio Faracco wrote: virtio_net paravirtualized driver does not have a tx_timeout() function to guarantee

Re: [PULL] virtio/vhost: cross endian support

2015-07-02 Thread Michael S. Tsirkin
On Wed, Jul 01, 2015 at 12:02:50PM -0700, Linus Torvalds wrote: On Wed, Jul 1, 2015 at 2:31 AM, Michael S. Tsirkin m...@redhat.com wrote: virtio/vhost: cross endian support Ugh. Does this really have to be dynamic? Can't virtio do the sane thing, and just use a _fixed_ endianness

Re: [PULL] virtio/vhost: cross endian support

2015-07-02 Thread Michael S. Tsirkin
On Wed, Jul 01, 2015 at 12:03:59PM -0700, Linus Torvalds wrote: On Wed, Jul 1, 2015 at 12:02 PM, Linus Torvalds torva...@linux-foundation.org wrote: Doing a unconditional byte swap is faster and simpler than the crazy conditionals. Unconditional endianness not only makes for simpler and

Re: [RFC] virtio_net: Adding tx_timeout function.

2015-07-02 Thread Michael S. Tsirkin
On Thu, Jul 02, 2015 at 03:23:56AM -0400, Pankaj Gupta wrote: On Wed, Jun 24, 2015 at 10:31:09PM -0300, Julio Faracco wrote: 2015-06-24 3:10 GMT-03:00 Michael S. Tsirkin m...@redhat.com: On Tue, Jun 23, 2015 at 10:44:29PM -0300, Julio Faracco wrote: virtio_net paravirtualized

  1   2   3   4   5   6   7   8   9   10   >