[openib-general] IB Address Translation service
Libor Michalek
libor at topspin.com
Mon Feb 28 11:48:37 PST 2005
On Mon, Feb 28, 2005 at 07:31:47PM -0000, Paul Baxter wrote:
> > 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?
No, you would still need IPoIB. In my opinion, the subset of IPoIB that
you need to support ARP is big enough, that it doesn't make sense to try
and break out that subset.
> 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. )
Well to start with, ARP is based on an IETF draft and ATS is from the
DAT collabrative. ATS uses a 32 bit address, but calling it an IPv4
address is a bit of a strech. Basically ATS uses the IB SM to register
node addresses and support lookup of those nodes GIDs based on the 32
bit registered address. The intention was to support IP like addressing
without an IPoIB implementation. The two are not interoperable, they
reside in parallel, and succeed in producing much confusion. (IMO)
-Libor
More information about the general
mailing list