[ofw] ping on WinOF

[Rupert Dance]

I am talking about Linux but since there is a lot of shared base code I
thought this information might be useful.

 

From: Tzachi Dar [mailto:tzachid at mellanox.co.il] 
Sent: Thursday, July 02, 2009 2:52 AM
To: Rupert Dance; David Brean; ofw at lists.openfabrics.org
Subject: RE: [ofw] ping on WinOF

 

Thanks for your info -  Rupert Dance.

 

However it seems you are talking about Linux, while we were talking about
windows, o r am I missing something?

 

Thanks

Tzachi

 


  _____  


From: ofw-bounces at lists.openfabrics.org
[mailto:ofw-bounces at lists.openfabrics.org] On Behalf Of Rupert Dance
Sent: Wednesday, July 01, 2009 7:27 PM
To: 'David Brean'; ofw at lists.openfabrics.org
Subject: RE: [ofw] ping on WinOF

We have seen issues with IPoIB in datagram mode particularly when you use a
large size (8192 and greater).  This was reported to the OFA Bugzilla Bug #
1287 <https://bugs.openfabrics.org/show_bug.cgi?id=1287> . Yosef Etigin
looked into this and suggested a workaround that did affect the first packet
drop. Here is his comment:

 

It is a network stack limitation and not related ipoib in particular.

There's a limit (default = 3) on number of pending skb's before a neighbour
is

resolved. You can increase it with sysctl net.ipv4.neigh.ib0.unres_qlen.

Obviously, same thing happens with Ethernet interface.

 

When testing at UNH-IOL for the Logo program, this is what we did:

 

After working with Sasha Khapyorsky on this issue we have a working fix. To
further explain the situation, the large packet sizes we are using are
overflowing the buffers so there is no room to append the arp request on to
the beginning of the cmd. This results in a dropped packet because the
system doesn't know how to get to the destination due to an empty arp table.
The fix, increase the buffer size via:

 

sysctl net.ipv4.neigh.ib0.unres_qlen=17 # default is the value 3

 

Thanks

 

Rupert Dance

 

From: ofw-bounces at lists.openfabrics.org
[mailto:ofw-bounces at lists.openfabrics.org] On Behalf Of David Brean
Sent: Wednesday, July 01, 2009 11:39 AM
To: ofw at lists.openfabrics.org
Subject: [ofw] ping on WinOF

 

Hello,

An internal customer is using WinOF 2.0.X and has reported to me the
following behavior related to IPoIB and ping:

Do you have any ideas on why windows 2008 client with HCA may first timeout
ping to other clients on the fabric?

Initially ping fails but then starts working.

Example :  Ping is invoked three times successfully.

C:\GRITS>ping -a 192.168.100.235

Pinging 192.168.100.235 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 192.168.100.235:
   Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\GRITS>ping -a 192.168.100.235

Pinging 192.168.100.235 with 32 bytes of data:
Request timed out.
Request timed out.
Reply from 192.168.100.235: bytes=32 time<1ms TTL=255
Reply from 192.168.100.235: bytes=32 time<1ms TTL=255

Ping statistics for 192.168.100.235:
   Packets: Sent = 4, Received = 2, Lost = 2 (50% loss),
Approximate round trip times in milli-seconds:
   Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\GRITS>ping -a 192.168.100.235

Pinging 192.168.100.235 with 32 bytes of data:
Reply from 192.168.100.235: bytes=32 time<1ms TTL=255
Reply from 192.168.100.235: bytes=32 time<1ms TTL=255
Reply from 192.168.100.235: bytes=32 time<1ms TTL=255
Reply from 192.168.100.235: bytes=32 time<1ms TTL=255

Ping statistics for 192.168.100.235:
   Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
   Minimum = 0ms, Maximum = 0ms, Average = 0ms

Then we are good for sometime before this starts again if network is idle on
the fabric.

Has this sort of behavior been observed before?  The Linux and Solaris nodes
sharing the same IP subnet appear to be behaving normally.  Windows server
is the "out-of-the-box" configuration with Voltaire switch configured with
only the default partition (0xFFFF).

-David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20090702/866d9ab4/attachment.html>