[ofw] port RDS to OFW - request for input...

Fab Tillier ftillier at microsoft.com
Thu Jul 23 10:42:37 PDT 2009


> >How is it that a kernel interface to IBAT would not solve the address
> >resolution problem?
>
> IBAT looks like it can do:
>
> local IP <-> local port
> remote MAC <-> remote GID

You need the local port as input too here.

> local port, remote MAC -> path record
>
> We need to get to:
>
> remote IP -> local IP, remote GID
>
> It's not clear to me looking at ib_at_ioctl.h that it can do this, but
> maybe the interface can be extended to provide this functionality if
> it doesn't.

IPoIB doesn't track the IP addresses, only Ethernet MAC to IPoIB MAC (simplified as GID + QPN).  Tracking IP addresses in IPoIB ends up raising cache coherency issues with OS-managed ARP tables.  Even static ARP entries can cause problems for IPoIB, since no ARP resolution would occur to give it the GID.  This means that if you configure two systems with static ARP entries for one another, you will likely not have any connectivity (I haven't actually double checked this, so I could be wrong.)

For remote IP to local IP, you really want to go through the OS.  You also need remote IP to remote Ethernet MAC.  The OS can give you both relatively easily starting in Windows Vista/Server 2008 for kernel clients.

Once you have local IP and remote Ethernet MAC, you can use IBAT to get you a path.

I would suggest that any kernel WinVerbs driver would be targeted at Server 2008 and beyond, so that you don't have to jump through hoops.  Then you can create backports if possible/needed to older OS versions.

-Fab




More information about the ofw mailing list