[Openib-windows] Geting remote and locale ip addresses - the functionality

[Tzachi Dar]

In a previous mail Fab asked the following questions:
 
What functionality should IPoIB provide?  Should it provide?
 
1. IP to path
2. Ethernet MAC to path
3. IP to GID
4. Ethernet MAC to GID
5. Get all locally assigned IP addresses
6. Path validation (e.g. given an IP pair and a path, return validity of
path)
 
WSD would care most about 1, 5, and 6.  DAPL probably only cares about 1 and
6. What about SDP?
 
Before I'll try to answer the questions I'll say that I assume that each
adapter has one mac address and that it can have one or many IP's. This is
not always the case, but this is the very big majority of the cases.
 
The questions above are not very clear since they don't really say if this
is remote IP or local ip, that should be used. Still, I'll try to explain
the way I see things.
 
On SDP and WSD (I don't know about DAPL) one gets the remote IP that he has
to connect to it. He might get the local IP. If he doesn't get the locale
IP, he should be able to find it. Windows supplies the GetBestRoute function
that does exactly this. This function exists in user mode, I'm not sure if
it exists in kernel mode, and in any case this is not something that the
IPOIB should know about. From here I assume that we have both IP's.
 
Given the locale IP and the remote IP one should be able to find both ports
GIDS. This is something that the IPOIB should be able to supply.
 
Let's look at the problem of converting the locale IP to a port's GID (and
probably also the HCA's GID). This information should be known to the IPOIB,
and we can make a query that gets the answer. In appendix a I explain how
one can get this information even without using the IPOIB module.
We will have to decide if we want to take the way from the appendix or
create more changes to IPOIB. In any case, we have to note that this
information changes. No matter how we do it, this makes the problem much
more complicated (if you are pessimistic and much more interesting if you
are optimistic). 
 
The second problem is getting the remote GID from the remote IP. This
information is only known to the IPOIB module. After doing an arp (can be
done easily from user mode and we should have the IP translated to the
remote MAC). To my understanding, all information should already be in the
IPOIB driver as an "endpt" (the function __endpt_mgr_ref should return it
immediately). 
 
As for translating the two gids to a path: This can be easily done by each
ULP and is not something special to the IPOIB driver. Still each ULP has to
do it, so it might be a good idea to also do the path lookup. To my filling
it makes things somewhat complicated, and we can avoid it, but as I said, it
can be done. This also rises the question of doing it sync or non sync
(which will make things even more complicated).
 
Path validation - I'm not sure that I understand the question, if I have a
path to validate, I can simply ask for the new path to be created and
compare them, or is there anything else in this?
 
So to summarize: 
1)     Get all locale ip addresses, We can do it or not do it, I recommend
to do it in the IPOIB. As the information changes, it would be better to
create some notification mechanism, I suggest not implementing this
mechanism at start.
2)     Get remote IP - we must implement.
3)     Get/verify path we can implement but I believe that we shouldn't do
it.
 
Do you agree? Any comments?
 
Appendix A - How to get all the locale IP addresses (and even to map them to
InfiniBand ports): 
Windows provides the function GetAdaptersInfo which gives all IP adapters as
well as their locale IP. For each adapter there is a "name" that is actually
a guid that uniquely describes the adapter. In the registry there is a key
named:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Network\{4D36E972-E325-1
1CE-BFC1-08002BE10318} that has an entry for each adapter. For each of the
adapters there is a sub key call Connection. Under this there is a value
that is called PnpInstanceID this value starts with IBA\IPOIB for InfiniBand
devices, so we know that this is "our" card. Next there is the guid of the
port. 
 
Please note that since adapters (and more likely IP addresses) change with
time, it is not that simple to cache the information in user mode.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20050907/2f417c33/attachment.html>