> Von: Or Gerlitz [ogerl...@mellanox.com]
> Gesendet: Mittwoch, 6. November 2013 08:50
> An: Markus Stockhausen; Jason Gunthorpe; Erez Shitrit
> Cc: linux-rdma@vger.kernel.org; Wendy Cheng
> Betreff: Re: IPoIB GRO
>
> On 05/11/2013 20:08, Markus Stockhausen wrote:
> > Incredible how a card that d
On 05/11/2013 20:08, Markus Stockhausen wrote:
Incredible how a card that does not support TSO can bring big packets
on the wire that somehow get reassembled on the client side
not sure to follow, you have shown they are **not** reassembled, correct?
--
To unsubscribe from this list: send the l
From: Dan Carpenter
Date: Tue, 5 Nov 2013 01:20:56 +0300
> The printk() looks like it is left over debug code. I have removed it.
>
> Signed-off-by: Dan Carpenter
> ---
> v2: Remove the printk instead of moving it infront of the return.
This doesn't apply to the current tree, I suspect some
On Tue, 2013-11-05 at 11:13 +0200, Sagi Grimberg wrote:
> On 11/4/2013 8:41 PM, Nicholas A. Bellinger wrote:
> > On Sat, 2013-11-02 at 14:57 -0700, Bart Van Assche wrote:
> >> On 1/11/2013 18:36, Nicholas A. Bellinger wrote:
> >>> On Fri, 2013-11-01 at 08:03 -0700, Bart Van Assche wrote:
> On
> > so, to summarize:
> > The HW does the work (truncates the big ip packet to series of ip
> > packets, each with the relevant mtu size and increases the ip-id for
> > each)
> > The FW enables that work on the HW
> > the FW in A0 card doesn't enable that option for the HW.
>
> Sounds like this bu
From: Dan Ben Yosef
Need to check pkey received counter flag only
after get mads and not set.
Signed-off-by: Dan Ben Yosef
---
include/opensm/osm_port.h |3 ++-
opensm/osm_pkey_rcv.c |3 ++-
opensm/osm_port.c |6 --
3 files changed, 8 insertions(+), 4 deletions(-)
Fix the man pages of rdma_destroy_ep & rdma_destroy_qp to the correct return
value (void).
---
man/rdma_destroy_ep.3 |5 +
man/rdma_destroy_qp.3 |3 ---
2 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/man/rdma_destroy_ep.3 b/man/rdma_destroy_ep.3
index b48a1e5..750702a
On Tue, Nov 05, 2013 at 10:48:10AM +0200, Erez Shitrit wrote:
> so, to summarize:
> The HW does the work (truncates the big ip packet to series of ip
> packets, each with the relevant mtu size and increases the ip-id for
> each)
> The FW enables that work on the HW
> the FW in A0 card doesn't enab
On 05/11/2013 11:05, Yann Droneaud wrote:
Thanks Matan for carrying on the patchset.
I've quite the same patchset, but the other way around, eg. enabling
the flow steering verbs after cleanup on the new ABI. I thought it would
make more sense this way. Would you like me to send the patchset this
Hi,
Le mercredi 30 octobre 2013 à 11:52 +0200, Matan Barak a écrit :
> This series is a continuous improvement for the uverbs extension mechanism
> that was introduced as an experimental feature for v3.12.
>
> Yann Droneaud suggested and implemented the following improvements:
> - structure renam
Hi Matan,
Le mercredi 30 octobre 2013 à 11:52 +0200, Matan Barak a écrit :
> From: Yann Droneaud
>
> The unused field in the extended header is a perfect candidate
> to hold the command "comp_mask" (eg. bit field used to handle
> compatibility). This was suggested by Roland Dreier in a previous
On 11/4/2013 8:41 PM, Nicholas A. Bellinger wrote:
On Sat, 2013-11-02 at 14:57 -0700, Bart Van Assche wrote:
On 1/11/2013 18:36, Nicholas A. Bellinger wrote:
On Fri, 2013-11-01 at 08:03 -0700, Bart Van Assche wrote:
On 31/10/2013 5:24, Sagi Grimberg wrote:
In T10-DIF, when a series of 512-byt
On 05/11/2013 10:25, Markus Stockhausen wrote:
Are the TCP Ids in an TSO setup generated through firmware or in the software
stack?
in HW
And if in firmware: How does the card know how to increase them? I would expect
that it only works with IB packets
and does not know of the IP encapsulati
I see. This didn't happen on our setups here since we tests with
newer cards (ConnectX2/3/3-pro).
For ConnectX1 (A0) and this firmware that you are using smells
like something goes wrong. If possible, I would change to newish
card.
No problem with that. My journey up to here was hard but very
i
> I see. This didn't happen on our setups here since we tests with
> newer cards (ConnectX2/3/3-pro).
> For ConnectX1 (A0) and this firmware that you are using smells
> like something goes wrong. If possible, I would change to newish
> card.
No problem with that. My journey up to here was hard
On 04/11/2013 23:17, Wendy Cheng wrote:
Look to me that the "segmentation offload" (TSO) and "receive offload (GSO) are
mutual exclusive ?
Wendy, the problem Markus stepped on was no GRO on the receive side b/c
of bad ID-ing of packets on the sender side during the TSO process.
GSO is SW
On 04/11/2013 15:21, Markus Stockhausen wrote:
I changed the client side test to another host with newer firmware.
Nevertheless the TSO problem occurs there too.
root@client:~# ibstat
CA 'mlx4_0'
CA type: MT25418
Number of ports: 2
Firmware version: 2.9.1000
17 matches
Mail list logo
