Michael S. Tsirkin wrote:
Quoting Or Gerlitz <[EMAIL PROTECTED]>:
Roland Dreier wrote:
Do you agree that using cached IB L2 info where the net stack wants to
renew its IPoIB L2 (which is IB L3 && L4) info is a bug?
Yes, looks that way.
Also your point that there's no reason for IPoIB to keep the path info
once it has created the AH makes sense to me. I haven't had a chance
to look at the code but it seems we could kill off a lot of stuff by
just creating AHs immediately and then dumping the path record.
Indeed.
As I said above, if the network stack decides to renew its IPoIB L2
info, the IB stack must provide it with non-cached IB L2 info
If what you have in mind is keeping local sa cache in sync
with IPoIB cache, wouldn't it be better to have an API to
invalidate a cache entry?
What I have in mind is that IPoIB must not use cached IB path info.
If the IB stack has path caching which is in the default flow of
requesting a path record, it should provide an API (eg flag to the
function through which one does path query) to request a non cached path.
The design I was thinking to suggest for IPoIB is to almost always use
this API since this policy makes the implementation consistent with the
decisions made by the network stack neighbour cache
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
