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.
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c
b/drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c
inde
I looked at TSO code earlier this year. IIRC, if TSO is on, the upper
layer (e.g. IP) would just send the super-packet down (to IPOIB) w/out
segmentation (for send); if off, it then does the segmentation (to
match the MTU size) before calling device's send. For GSO, I would
imagine it needs some so
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-byte data blocks are transferred, each
> >>
From: Vladimir Koushnir
Signed-off-by: Vladimir Koushnir
Signed-off-by: Hal Rosenstock
---
diff --git a/include/opensm/osm_pkey.h b/include/opensm/osm_pkey.h
index 2ba80b3..9459b5b 100644
--- a/include/opensm/osm_pkey.h
+++ b/include/opensm/osm_pkey.h
@@ -82,7 +82,7 @@ struct osm_physp;
* SYNO
This issue was caught by Tetsuo Handa and Acked on 10/30:
http://marc.info/?t=13831336458&r=1&w=2.
Roland, I noticed that the Tetsuo's original message didn't cc the linux-rdma
list?
Mike
> -Original Message-
> From: Stephen Rothwell [mailto:s...@canb.auug.org.au]
> Sent: Sunday, N
> Hi Markus,
>
> Can you please tell me what is the FW version you have on your ConnectX
> cards?
of course. the server has:
root@client:~# ibstat
CA 'mlx4_0'
CA type: MT26418
Number of ports: 1
Firmware version: 2.9.1000
Hardware version: a0
Node GUID: 0x
Signed-off-by: Hal Rosenstock
---
diff --git a/Makefile.am b/Makefile.am
index 4e3dee7..bf72134 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -125,6 +125,7 @@ man_MANS = \
man/rdma_client.1 \
man/rdma_xserver.1 \
man/rdma_xclient.1 \
+ man/riostream.1 \
man/r
From: Dan Ben Yosef
Remove node in addition to port when getting timeout for
pkeyGet for sw port 0.
Signed-off-by: Dan Ben Yosef
Signed-off-by: Hal Rosenstock
---
diff --git a/opensm/osm_drop_mgr.c b/opensm/osm_drop_mgr.c
index 85a6f58..11c1561 100644
--- a/opensm/osm_drop_mgr.c
+++ b/opensm/
From: Vladimir Koushnir
Signed-off-by: Vladimir Koushnir
Signed-off-by: Hal Rosenstock
---
opensm/osm_opensm.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/opensm/osm_opensm.c b/opensm/osm_opensm.c
index b3c487f..f2e04f6 100644
--- a/opensm/osm_opensm.c
+++ b/ope
Hi Markus,
Can you please tell me what is the FW version you have on your ConnectX
cards?
Thanks, Erez
Hi Erez,
don't you see that behaviour in tcpdump? what kernel are you using?
On server side we have a 3.5 on client side a 3.11 kernel each of them with
kernel standard drivers/modules.
Hi Erez,
> don't you see that behaviour in tcpdump? what kernel are you using?
On server side we have a 3.5 on client side a 3.11 kernel each of them with
kernel standard drivers/modules. I can see the same pattern of GRO
aggregation on the client that you mention but only if I disable TSO for
Hi Markus,
As Or already mentioned, it seems that we have accumulations of ip
packets, when GRO is enabled over ib interface, from tcpdump in the
recieve side we can see:
10:09:27.336951 IP 11.134.33.1.41377 > 11.134.41.1.35957: Flags [.], seq
3795959253:3796023381, ack 2, win 110, length 64
> Thats why the flush flag is always set and the GRO stack does
> not work at all. I'm willing to dig deeper into this but I'm unsure
> if those fields are filled on sender or receiver side and especially
> where in the IPoIB stack.
Maybe I got the reason for that strange ack behaviour during
lar
13 matches
Mail list logo
