[openfabrics-ewg] [openib-general] OFED 1.1 release - schedule and features

[Or Gerlitz]

Vladimir Sokolovsky wrote:
> Hi Or,
> I am working on IPoIB failover.
> I tried Michael's Tsirkin patch for ipoib (updating neighbor structure) 
> and it fixes the issue Roland was talking about.
> 
> Meanwhile I have tested the following flow:
> /*_Setup description:_*/
> 
>    host1 - 2 IB ports connected to IB switch.
>            ib0: 11.0.0.1
>            ib1: 12.0.0.1
> 
>    host2 - port 1 connected to the IB switch.
>            ib0: 11.0.0.2
>            opensm over port1
> 
> 
> /*_Flow description:_*/
>    - ping host2 -> 11.0.0.1 (passed)
>    - set port1 of the host1 to 'DOWN' state (disconnect the port from IB 
> subnet)
>    - ping host2 -> 11.0.0.1 (failed)
>    - ifconfig ib0 0.0.0.0 (on host1)
>    - ifconfig ib1 11.0.0.1 (on host1)
>    - arping -I ib1 11.0.0.1 (on host1)
>    - ping host2 -> 11.0.0.1 (passed)
> 
> arping in this case was not really necessary because ping issues ARP 
> requests by himself.

Hi Vlad,

Did you have any special reason to assign host1:ib1 an IP address 
***before*** the failover? is the reason for that happen to be having it 
joins the IPv4 multicast group at "batch time", that is not during the 
failover?

 >    - arping -I ib1 11.0.0.1 (on host1)

-U  Unsolicited ARP mode to update neighbours' ARP caches. No replies 
are expected

-A  The same as -U, but ARP REPLY packets used instead of ARP REQUEST.

I think we want arping to send a gratuitous arp with the MAC of ib1
so weren't you need to provide the -U or -A command line to arping?

If i understand correct, gratuitous arp was not sent in your usage case 
so i am not sure Michael's patch was exercised.

 > Note: I updated the original arping to be able to send broadcast using
 > ipv4_bcast_addr.

Can you please send the patch to arping?

 > Also, I have tested ssh over IPoIB with the same flow. In this case
 > arping also wasn't necessary , but it makes an update of neighbors
 > with the new MAC address (of ib1 interface) more quickly.

Two interesting test cases you might want to validate your approach with 
is something "long" ie that delivers much traffic before and after the 
failover ie: iperf or netperf over TCP AND UDP. I have not validated it 
but i think UDP would not generate ARP so the gratuitous is the only way 
   to update the remote system with the MAC change.

Or.