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
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
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 enable
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 bug causes a
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
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 does
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
large
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
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,
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 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:
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
Hello,
I have a little update to the unlucky GRO IPoIB behaviour I observed
in the last weeks in datagram mode on our ConnectX cards. In the
GRO receive path the kernel steps into the inet_gro_receive() function
of net/ipv4/af_inet.c. If I read the code right it compares two
IP packets and
On Wed, Apr 3, 2013 at 12:03 PM, Markus Stockhausen
markus.stockhau...@gmx.de wrote:
going through hard lessons to understand the SKBs maybe I finally
found the reason for the unnecessary memcpy commands. Even with
newest 3.9-rc5 kernel the problem persists. IPoIB creates only
fragmented SKBs
Hello,
...
If I get it right round about 6% (7.38% * 84.56%) of the time the
machine does a
memcpy inside __pskb_pull_tail. The comments on this function reads ...
it expands
header moving its tail forward and copying necessary data from
fragmented part. ...
It is pretty complicated.
Hello,
today I did some IPoIB profiling on one of our infiniband servers.
Environment on server side is
- Kernel: 3.5.0-26-generic #42~precise1-Ubuntu
- Mellanox Technologies MT26418 (LnkSta: Speed 2.5GT/s, Width x8)
- Infiniband MTU 2044 (cannot increase to 4K because of old switch)
- one 4
Markus Stockhausen markus.stockhau...@gmx.de wrote:
Hello,
today I did some IPoIB profiling on one of our infiniband servers.
Environment on server side is
- Kernel: 3.5.0-26-generic #42~precise1-Ubuntu
- Mellanox Technologies MT26418 (LnkSta: Speed 2.5GT/s, Width x8)
- Infiniband MTU
I don't know if this is a recent regression, but then the test is new. I
tried it on another system yesterday, but it was running 2.6.18 (RH EL 5?)
with some OFED installation. My plan is to start pulling older versions of
the kernel.
I don't understand why, but the GRO issue seems to be
This short series fixes two kind of badly hurting bugs that we
stepped on lately. We would be happy to have them treated quickly
so they can be pushed further to -stable, distros, etc.
Roland, when (hopefully soon) accepting these, could you please add CC
to stable in the commits so they
On Tue, Jan 31, 2012 at 11:12 AM, Hefty, Sean sean.he...@intel.com wrote:
What sort of impact does this bug to ipoib have?
I ask because my bandwidth numbers on 3.2 for large, unidirectional transfers
over ipoib are abysmal.
I don't think this particular issue is a regression... the
On 1/26/2012 4:39 PM, Or Gerlitz wrote:
This short series fixes two kind of badly hurting bugs that we
stepped on lately. We would be happy to have them treated quickly
so they can be pushed further to -stable, distros, etc.
Roland, when (hopefully soon) accepting these, could you please add
This short series fixes two kind of badly hurting bugs that we
stepped on lately. We would be happy to have them treated quickly
so they can be pushed further to -stable, distros, etc.
The 1st bug is in the mlx4_ib driver where vendor mads are just silently
dropped, which means that vendor
22 matches
Mail list logo
