[openib-general] IB Address Translation service
paul.baxter at dsl.pipex.com
Mon Feb 28 11:31:47 PST 2005
> 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. )
PS As is probably evident from the above, I didn't look into the technical
detail of the existing code.
More information about the general