[Openib-windows] IPoIB GUID to MAC conversion

[Fab Tillier]

> From: Tillier, Fabian
> Sent: Thursday, May 26, 2005 12:43 PM
> 
> Option (4) is also my preferred option.  I agree with the local LID of
> zero thing - that's a good suggestion.  I'll create a patch and submit it
> for review.

Looking at it some more, option 4 will require a little more work than I was
hoping for.  Currently, the IPoIB driver is pretty blunt about its error
handling - it tears everything down and starts over with a fresh set of IB
resources (PD, CQs, and QP).  Because the reset handler is invoked at
DISPATCH, it can't actually do any QP modifications, resource release, or
resource allocations from the handler (something I want to change, BTW - all
verbs should be able to be initiated at DISPATCH and follow async
processing).  IPoIB handles resource destruction asynchronously.  For
resource creation and configuration, it uses the access layer's PnP
notifications for port events - the callbacks are invoked at PASSIVE level,
so doing these operations is fine.

I don't know if there are any issues with just allocating the IB resources
up front in the miniport initialize function (and releasing them in the halt
handler).  The IBAL PnP notifications would then only be used to drive QP
state transitions.  This change would be required for option 4 to have a
fixed QPN for the lifetime of the IPoIB adapter instance (from
MiniportInitialize to MiniportHalt).

I would like to propose a two phase approach.  This would involve first
implementing option 2.  I'm envisioning the implementation having a global
value that it would keep incrementing to create new LAAs as needed.  This
does come with the price that addresses are inconsistent throughout the IB
subnet.  This is the easiest path to getting something working in the near
term.

The second phase would consist of "doing it right" and implement option 4
instead of option 2.  The second phase thus requires changing how resources
are allocated and destroyed - basically collapsing the adapter and port
objects into one.

I will therefore work to create a patch that implements option 2 unless I
hear otherwise from folks here.  The timeline to implement option 4 would be
TBD based on other development activities and requirements.

- Fab