Or Gerlitz wrote:
Michael S. Tsirkin wrote:
And ARP table aging gives a way to recover
from stale cached data, eventually at least.
Does it?
$ grep path_list drivers/infiniband/ulp/ipoib/*c
drivers/infiniband/ulp/ipoib/ipoib_main.c: list_add_tail(&path->list,
&priv->path_list);
drivers/infiniband/ulp/ipoib/ipoib_main.c: list_splice(&priv->path_list,
&remove_list);
drivers/infiniband/ulp/ipoib/ipoib_main.c: INIT_LIST_HEAD(&priv->path_list);
drivers/infiniband/ulp/ipoib/ipoib_main.c: INIT_LIST_HEAD(&priv->path_list);
In other words we add paths to ipoib specific cache, but we never seem
to *remove* individual paths from cache - we only know how to do
full cache invalidates on events such as port state change.
this seems like a bug, if the stack decided to delete OR change a
neighbour, the path associated with it must not be re-used to create the
address handle or to establish the connection, same for multicast
neighbours.
Roland,
Can you provide your take here?
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?
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
