Roland> First, let's understand the problem we're trying to solve. Roland> Who are the consumers of this address translation service?
shaharf> Any ULPs at user & kernel, and also some shaharf> applications.
I think this is too general an answer. We should be designing based on specific ULPs and applications. For example, I don't see anything particularly useful to IPoIB in this API. Perhaps Libor can comment on how this API works for SDP.
Recently a project I've been working on has been looking at porting IB software to an embedded PowerPC though my question also applies to a slimmed down embedded Linux PC system.
If I wanted to support SDP over a link with one end being embedded, I had thought I'd need to port the whole of the IPoIB driver for address resolution (albeit I may be able to cut a few corners with the code.)
Would this proposed address translation layer interface provide a sufficient subset of IPoIB functionality that allowed an SDP implementation to exist without a larger, full-featured IPoIB implementation?
If so, it sounds like a useful decoupling (refactoring) of a more generally useful subset of the IPoIB driver. It wouldn't be of use for the IPoIB driver per se, but would be more modular and suited to other applications particularly slimmed down ones. (Perhaps finding a place in Linux 'on a bios' for network booting or slimmed down embedded processing nodes.)
Having now just read Yaron's reply, I am even more convinced that this is the right way to go albeit I can't comment on the API etc (Could someone explain the differences in using ARP and ATS. )
Paul
PS As is probably evident from the above, I didn't look into the technical detail of the existing code.
_______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
