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.
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
