[ofw] udapl for windows

[Tzachi Dar]

IPOIB and SDP are using arp while WSD is using ATS.
As far as I know on Linux ATS is not used and therefore if DAPL will use
it, it will not be interposable with Linux.

Please note that we didn't find a way to read the arp cache of windows
directly.
What is being done is that IPOIB looks at all the ARP replies and
updates it's tables accordingly. So, IPOIB does know where the remote
addresses are if windows knows them.

So any one can query ipoib to get the information. Another issue is how
to tell windows to do the query by itself. The answer to this is: use
SendArp() this will cause windows to do the query and than one can look
at the result of the query on ipoib.

Please note that all the caching issues are minor to my understanding as
each component can hold it's own cache of the arp/ATS results and get
the results very quickly.

Thanks
Tzachi 

P.S.
There is one way to read the entire arp table using the arp.exe that
comes with windows. This can be used but requires to create another
process.
A different solution is to reverse engineer it and look at the function:
AllocateAndGetArpEntTableFromStack 
> -----Original Message-----
> From: Sean Hefty [mailto:sean.hefty at intel.com] 
> Sent: Tuesday, December 11, 2007 8:08 PM
> To: 'Fab Tillier'; Tzachi Dar; Davis, Arlin R; Gabor Forgacs; 
> ofw at lists.openfabrics.org
> Subject: RE: [ofw] udapl for windows
> 
> >The SendArp function sends an ARP request every time it is 
> invoked.  It 
> >doesn't actually lookup the system's ARP cache.  Using SendArp was 
> >tried with WSD and found to give significantly worse connection 
> >establishment rates (~50%) than doing the ATS query to the 
> SA, which is 
> >why WSD still uses ATS.  I suppose the ATS query rate 
> depends on the SM.
> 
> Can the system's ARP cache be checked before SendArp is 
> called?  Doesn't IPoIB on Windows uses ARP and not ATS for 
> its mapping?  I would prefer to have a single mechanism for 
> mapping IP addresses, versus trying to keep multiple mappings in sync.
> 
> This is somewhat separate, but one of the goals of address 
> resolution is using the same routing tables as the IP stack 
> in order to determine the local port (IP address and SGID) 
> for a connection.
> 
> - Sean
>