> 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 _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
