Re: [PATCH] IPoIB: Stop lying about hard_header_len and use skb->cb to stash LL addresses

2012-02-08 Thread Or Gerlitz
On 2/8/2012 9:50 AM, Eric Dumazet wrote: Le mercredi 08 février 2012 à 07:29 +, Hefty, Sean a écrit : I tested this with Dave's patch and Eric's first patch against Linus' latest tree 3.3-rc2+, and things look good so far. Thanks for testing, I'll resend my (updated) patch today. same

[PATCH] Infiniband-Diags: ibping server sends responses even after the client has terminated

2012-02-08 Thread Mike Heinz
This is OFED bug 1974, it's been open for a couple of years now. Ira, I think you're the ib-diags guy now, right? In any case, it's a trivial issue: ibping -S treats receive errors as if they were valid incoming MAD packets and tries to send responses to them. The fix is easy, just check the st

Re: [PATCH] Infiniband-Diags: ibping server sends responses even after the client has terminated

2012-02-08 Thread Ira Weiny
On Wed, 8 Feb 2012 06:34:47 -0800 Mike Heinz wrote: > This is OFED bug 1974, it's been open for a couple of years now. Ira, I think > you're the ib-diags guy now, right? > > In any case, it's a trivial issue: ibping -S treats receive errors as if they > were valid incoming MAD packets and trie

RE: [PATCH] Infiniband-Diags: ibping server sends responses even after the client has terminated

2012-02-08 Thread Mike Heinz
Absolutely. Sorry, I knocked the patch out quickly because I came across it while looking at another problem, next time I'll be sure to do the full procedure. -Original Message- From: Ira Weiny [mailto:wei...@llnl.gov] Sent: Wednesday, February 08, 2012 1:20 PM To: Mike Heinz Cc: linux-r

[PATCH net-next] gro: more generic L2 header check

2012-02-08 Thread Eric Dumazet
Shlomo Pongratz reported GRO L2 header check was suited for Ethernet only, and failed on IB/ipoib traffic. He provided a patch faking a zeroed header to let GRO aggregates frames. Roland Dreier, Herbert Xu, and others suggested we change GRO L2 header check to be more generic, ie not assuming L2

Re: [PATCH] IPoIB: Stop lying about hard_header_len and use skb->cb to stash LL addresses

2012-02-08 Thread David Miller
From: Roland Dreier Date: Tue, 7 Feb 2012 16:51:21 -0800 > From: Roland Dreier > > Commit a0417fa3a18a ("net: Make qdisc_skb_cb upper size bound > explicit.") made it possible for a netdev driver to use skb->cb > between its header_ops.create method and its .ndo_start_xmit > method. Use this

Re: [PATCH net-next] gro: more generic L2 header check

2012-02-08 Thread David Miller
From: Eric Dumazet Date: Wed, 08 Feb 2012 19:51:50 +0100 > Shlomo Pongratz reported GRO L2 header check was suited for Ethernet > only, and failed on IB/ipoib traffic. > > He provided a patch faking a zeroed header to let GRO aggregates frames. > > Roland Dreier, Herbert Xu, and others suggeste

Re: [PATCH net-next] gro: more generic L2 header check

2012-02-08 Thread Or Gerlitz
On Wed, Feb 8, 2012 at 10:50 PM, David Miller wrote: > From: Eric Dumazet > > Shlomo Pongratz reported GRO L2 header check was suited for Ethernet > > only, and failed on IB/ipoib traffic. > > He provided a patch faking a zeroed header to let GRO aggregates frames. > > > > Roland Dreier, Herbert

Re: [PATCH] IB/ehca: use kthread_create_on_node

2012-02-08 Thread Or Gerlitz
On Thu, Feb 2, 2012 at 7:08 PM, Roland Dreier wrote: > On Thu, Feb 2, 2012 at 3:12 AM, Eric Dumazet wrote: >> Any news on this patch ? > Sorry, just dropped it in the shuffle.  I'll get it into 3.4, thanks. Roland, I noted that you typically use the for-next branch of the infiniband tree for

Re: [PATCH net-next] gro: more generic L2 header check

2012-02-08 Thread David Miller
From: Or Gerlitz Date: Wed, 8 Feb 2012 23:08:26 +0200 > On Wed, Feb 8, 2012 at 10:50 PM, David Miller wrote: >> From: Eric Dumazet >> > Shlomo Pongratz reported GRO L2 header check was suited for Ethernet >> > only, and failed on IB/ipoib traffic. >> > He provided a patch faking a zeroed header

Re: [PATCH] IB/ehca: use kthread_create_on_node

2012-02-08 Thread Roland Dreier
On Wed, Feb 8, 2012 at 1:26 PM, Or Gerlitz wrote: > I noted that you typically use the for-next branch of the infiniband > tree for fixes during > the 1 < kernN-rc < (say) 6 time and for features during (kernN-rc > 6) > till kern(N+1)-rc1 > > This means that the window of time when features are ac

Re: [PATCH net-next] gro: more generic L2 header check

2012-02-08 Thread Or Gerlitz
On Wed, Feb 8, 2012 at 11:31 PM, David Miller wrote: > From: Or Gerlitz >> Hi Dave, for correct operation / future bisection, you should 1st >> apply Roland's patch which reduces the hard header len advertized by >> ipoib to be only the size of the ipoib header without that 20 bytes >> headroom,

Re: [PATCH] IB/ehca: use kthread_create_on_node

2012-02-08 Thread Or Gerlitz
On Wed, Feb 8, 2012 at 11:35 PM, Roland Dreier wrote: > On Wed, Feb 8, 2012 at 1:26 PM, Or Gerlitz wrote: >> [...] This means that the window of time when features are actually accepted >> into your tree is kind of very limited. Would it be possible to >> maintain two branches: for-next and (say

Possibly serious bug in ib_mad: processing packets from ibping can consume 100% of CPU and may leave user processes locked in umad_recv

2012-02-08 Thread Mike Heinz
So, take a set of 3 or 4 hosts on a fabric, and run # ibping -S on each. Then, on each, run the ibping client in a loop so that each host sends a few packets to each other host. For example: # while true; do echo; date; echo; ibping -c 3 -L 3; ibping -c 3 -L 5; ibping -c 3 -L 1; sleep 1; don

mlx4_wq_overflow question

2012-02-08 Thread Eli Cohen
Hi Roland, referring to the function below, I can't find a strong reason to check again after acquiring the cq spinlock. Any idea? static int mlx4_wq_overflow(struct mlx4_ib_wq *wq, int nreq, struct ib_cq *ib_cq) { unsigned cur; struct mlx4_ib_cq *cq; cur = wq->head - wq-

Re: Possibly serious bug in ib_mad: processing packets from ibping can consume 100% of CPU and may leave user processes locked in umad_recv

2012-02-08 Thread Or Gerlitz
On Thu, Feb 9, 2012 at 12:41 AM, Mike Heinz wrote: > This behavior has been demonstrated on 1.5.4 and 1.5.4.1, and on RHEL6.0, 6.1 > and 5.7 tried kernel.org? this list deals with kernels from that fabric. Or. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body

Re: [PATCH net-next] gro: more generic L2 header check

2012-02-08 Thread David Miller
From: Or Gerlitz Date: Wed, 8 Feb 2012 23:49:43 +0200 > On Wed, Feb 8, 2012 at 11:31 PM, David Miller wrote: >> From: Or Gerlitz > >>> Hi Dave, for correct operation / future bisection, you should 1st >>> apply Roland's patch which reduces the hard header len advertized by >>> ipoib to be only

Re: [PATCH/RFC G-U-P experts] IB/umem: Modernize our get_user_pages() parameters

2012-02-08 Thread Hugh Dickins
On Tue, 7 Feb 2012, Hugh Dickins wrote: > On Mon, 6 Feb 2012, Roland Dreier wrote: > > Which I think explains why the code is the way it is. But clearly > > we could do better if we had a better way of telling GUP our real > > intentions -- ie the FOLL_READONLY_COW flag. > > You've persuaded me.

Re: [PATCH net-next] gro: more generic L2 header check

2012-02-08 Thread Or Gerlitz
On Thu, Feb 9, 2012 at 1:09 AM, David Miller wrote: > I don't think this is an appropriate bug fix at all. I'm not sure to understand > Apparently this problem has existed since day one and the world has > kept on spinning meanwhile. Dave, the bug was introduced on 2.6.38 when LRO was removed f

Re: [PATCH net-next] gro: more generic L2 header check

2012-02-08 Thread David Miller
From: Or Gerlitz Date: Thu, 9 Feb 2012 01:20:46 +0200 > On Thu, Feb 9, 2012 at 1:09 AM, David Miller wrote: >> I don't think this is an appropriate bug fix at all. > > I'm not sure to understand > >> Apparently this problem has existed since day one and the world has >> kept on spinning meanwh

RE: Possibly serious bug in ib_mad: processing packets from ibping can consume 100% of CPU and may leave user processes locked in umad_recv

2012-02-08 Thread Hefty, Sean
> Subject: Possibly serious bug in ib_mad: processing packets from ibping can > consume 100% of CPU and may leave user processes locked in umad_recv Is there a chance that the low level driver is asking to send the MAD to itself over and over again? -- To unsubscribe from this list: send the line