[ofw] RE: Release IBA resources in DISPATCH_LEVEL ?

[Tzachi Dar]

Hi James,

If all that you want is to only allow releasing of elements in dispatch
level than I guess that this can be achieved easily:

Create some kind of a queue mechanism and when in DPC queue the objects
to the queue. The queue will be served by one of IBAL threads (or create
your own thread). Once releasing the objects is done the thread can do
the callback.

This is relatively a simple task.

Thanks
Tzachi

> -----Original Message-----
> From: ofw-bounces at lists.openfabrics.org 
> [mailto:ofw-bounces at lists.openfabrics.org] On Behalf Of James Yang
> Sent: Wednesday, June 11, 2008 1:55 AM
> To: Fab Tillier; ofw at lists.openfabrics.org
> Subject: [ofw] RE: Release IBA resources in DISPATCH_LEVEL ?
> 
> Hi Fab,
> 
> I think asynchronous mode with callback could be one of the solutions.
> One of the examples is that I want to do it at power IRP 
> which is at IRQL_2.
> 
> Thanks,
> James
> 
> 
> -----Original Message-----
> From: Fab Tillier [mailto:ftillier at windows.microsoft.com]
> Sent: Tuesday, June 10, 2008 3:35 PM
> To: James Yang; ofw at lists.openfabrics.org
> Subject: RE: Release IBA resources in DISPATCH_LEVEL ?
> 
> Hi James,
> 
> > Hi,
> >
> > My understanding with current WinOF1.2 code is that it can 
> not allow 
> > drivers to call ibbus to release IBA 
> > resources(close/unregister/disconnect etc) at DISPATCH_LEVEL.
> 
> That is correct - no actions that perform any HW resource 
> state change can be done at DISPATCH_LEVEL, with the 
> exception of allocating/freeing address vectors.
> 
> > Will this
> > restriction being remove in WinOF 1.2 or any later version? 
> With this 
> > restriction it will cause a lot of troubles for devices 
> boot over IB.
> 
> The HCA driver is what imposes this usage model on the stack, 
> so you'd have to effectively turn the whole call model upside 
> down to fix this.
> Pretty much a re-write of the whole stack.  Of course, you 
> could support the IBAL APIs on top of an async lower level, 
> so IBAL kernel clients wouldn't necessarily require changes, 
> but the guts of IBAL and everything below it would need to 
> change significantly.
> 
> How would you envision this working?  Would you expect 
> asynchronous operations?  Would you want completions to be 
> notified via callbacks or IRP completions?
> 
> -Fab
> 
> _______________________________________________
> ofw mailing list
> ofw at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
>