[ofw] [patch] [winverb] fix BS in WinVerbs when getting an event for non IB port

[Fab Tillier]

I thought the VPI device (the actual HW driver, mlx4_bus) created child devices based on the configuration (IB vs. ETH) of the ports.  The mxl4_hca driver gets loaded for the IB functionality.  I would expect any filtering to be done in the HCA driver - that way any assumptions that need to be made are done in that particular hardware's driver, not a more general driver.  WinVerbs should not receive a callback for a device for which it has no context.  I'm surprised IBAL handled the event gracefully.

That said,  you bring up a good question: how is RoCE going to be handled with this stack?  Is it going to show up as another HCA?  How will WinVerbs work over RoCE ports?

-Fab

-----Original Message-----
From: Hefty, Sean [mailto:sean.hefty at intel.com] 
Sent: Sunday, December 12, 2010 3:07 PM
To: Uri Habusha; 'ofw at lists.openfabrics.org'; Fab Tillier
Cc: Galina Tcharny; Eitan Peretz; Gilad Margalit
Subject: RE: [ofw] [patch] [winverb] fix BS in WinVerbs when getting an event for non IB port

> During our testing we got a BS in WinVerbs. It happens when we running a
> VPI scenario in which one port is IB and the second port is ETH.  The test
> bring down the ETH link, as a result an event is created and low level
> driver calls to winverbs to handle it.

We need to find the right way to handle this, and I'm not sure what that is.  Winverbs layers as a filter device for an IB device.  If an HCA acts as two different types of devices, then maybe it should report itself as two different devices to Windows..?  Then all ports from that device would be the same, with the HCA driver making whatever adjustments and mappings are necessary between a port number viewed by a user versus the physical port of the HCA.  Or winverbs may need to be fully extended to handle different link layers.

Whatever solution is chosen needs to apply to winmad as well.  How are other dual-port devices reported in Windows?

> Since the IB always should be the first port, the simple fix is to check
> that port number of the event is less or equal for PortCount this promise
> that port object is exist for the port.

I don't like this assumption.