Sean Hefty wrote:
I think that there will still be a need for a separate address translation module(s)
I don't understand. You think there should be an address translation module, but you object to the *name* ib_at ? (ib_at stands for "infiniband address translation")
I suggested before that if ib_at should be fixed lets fix it. If API should be improved or other functionality should be added (or removed) why not do it in the existing ib_at ?
If there will indeed be a separate address translation module((s)?), then why would transport aware modules won't use it along with the cm ?
Doesn't that leave the cma with the abstraction purposes only ?
Caching will be complex, which is why I think that it needs to have its own module. I'm envisioning a cache that can be saved to disk for faster system startup.
I admit I'm not aware to all the complexity of caching, so I fail to see why it can't be implemented in the ib_at module.
The way I see it - If the cma can replace ib_at functionality and also serve as an at module, that's fine. But if we decide that there should be an ib_at module (which centralizes the at to all the ULP's) the cma should use this module and the cma consumer needn't be aware of it.
Guy _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
