[ofa-general] Re: Re: IPoIB-CM UC mode

[Michael S. Tsirkin]

> Quoting Or Gerlitz <ogerlitz at voltaire.com>:
> Subject: Re: [ofa-general] Re: Re: IPoIB-CM UC mode
> 
> Michael S. Tsirkin wrote:
> >>Quoting Sean Hefty <mshefty at ichips.intel.com>:
> >>Subject: Re: [ofa-general] Re: Re: IPoIB-CM UC mode
> >>
> >>>So we must send something that will force remote side to respond. One 
> >>>such
> >>>message is LAP with current primary path used as proposed alternate path.
> >>>Remote will respond with APR with AP status 5 if the connection is 
> >>>there, and
> >>>status 1 if it is not.
> >>I didn't follow this.  Is this just an out of band keep alive message? 
> >
> >Yes. Exactly.
> 
> Michael,
> 
> You may know that for each neighbour, the Linux network stack sends 
> every m jiffies a --unicast-- ARP probe, where after n jiffies there is 
> no ARP reply, it sends a broadcast ARP.
> 
> The default values are m=30*HZ and n=30*HZ, but you can change them,
> its net.ipv4.neigh.default{gc_interval,gc_stale_time}
> 
> My understanding it that it solves everything, no need for keep alives
> 
> Do I missing anything here?

How does this solve the problem?
If the remote side has lost the connection, unicast ARPs will get dropped
but broadcast ARPs will get answered to. We'd need to re-create the connection
if this happens - but is there a way to detect this?

-- 
MST