[ofa-general] Re: IPoIB path caching

[Or Gerlitz]

Sean Hefty wrote:
>> Indeed. The argument I was trying to make is that arp cache 
>> invalidation  requires IPoIB PR cache invalidation, this handles 100% 
>> of the cases, including the 10% not covered by doing cache 
>> invalidation based only on  IB events such as port up / sm lid change 
>> / sm reregister / etc
> 
> ARP cache invalidation does not require, nor does it actually do IPoIB 
> PR cache invalidation.  We can argue whether or not it should, but the 
> two are not linked together today.

When I said "requires" I meant that "I think that it is required", I 
agree that the current IPoIB code does not link them together. In the 
beginning on this thread Roland commented saying he agree with me, but 
since then he did not provide more input to the discussion...

> The local SA updates paths either in response to an event: LID change, 
> port state change, GID in/out of service,

what's the reasoning to update the cache when there is GID out of 
service? you don't cache IP 2 GID mapping, nor the IB SA provides GID 
resolution services... What do you do on GID OUT, just remove all the 
paths in the cache for which this is the DGID?

> I like the advantages of keeping the local SA entirely in user space, 
> but there are issues that need to be worked through first.  And 
> implementation wise, it's unlikely to give us anything that remains in 
> sync any better than what's already been proposed without the use of 
> non-standard extensions.

Does it mean that you will have to re-implement RMPP in a user space 
library or just the initiation of the query would be from user space?

Or.