[openib-general] IB Address Translation service

[shaharf]

> This API seems overly complex and at the same time too inflexible to
> me.  However, rather than getting bogged down nitpicking about APIs, I
> think we have to take a few steps back.
> 

I am very open to suggestions.

> First, let's understand the problem we're trying to solve.  Who are
> the consumers of this address translation service?
> 
Any ULPs at user & kernel, and also some applications. The motivations
are:

1. Implement central address resolution functionality to enable
implementing system policies and preferences for all clients (e.g. use
ATS instead of IB-ARP)
2. Enable the (future) implementation of resolution related enhancements
such as qos mapping, several port/path fail over mechanisms (APM, port
fail over, application fail over, etc.) and source routing (enable smart
client based source ports/paths by ensuring some agreed semantics within
the lid range.

I think that we can agree that there is no use to replicate the
functionality within application and ULPs.

> Second, let's come up with the right architecture to solve the
> problem.  Are we implementing a library in userspace or a kernel
> module?  Do we have a single cache or do we need multiple caching
> policies?  And so on...
> 

My take right now is to implement a kernel based mechanism and a user
mode library to interface it.
There are other feasible solutions. I would really like you have your
suggestions and preferences.

The caching issues are non-trivial (to say the least). My approach is to
set up the minimum requirements that will enable caching in the (near)
future.
I guess that the interface will be changed and enhanced to support the
caching. It will be nice to close this issue before the implementation,
but I don't think that this is mandatory. Very frequently you can't
simply design everything before you start. The trick is to find the
correct balance.

> Finally, we can design the API.
>

I think that starting with the APIs is a valid approach that has its own
advantages and disadvantages.
 
Right now, the proposed interface does not impose anything. It is just a
direction to start with. This is good even just to place the cards on
the table and start the discussion.

> Thanks,
>   Roland
> 
Shahar