[ofw] [PATCH 7/7] librdmacm: provide OFED compatability library

[Tzachi Dar]

> -----Original Message-----
> From: Sean Hefty [mailto:sean.hefty at intel.com] 
> Sent: Monday, January 19, 2009 7:49 AM
> To: Tzachi Dar; ofw at lists.openfabrics.org
> Subject: RE: [ofw] [PATCH 7/7] librdmacm: provide OFED 
> compatability library
> 
> >> Because of the use of overlapped structures and events, 
> the library 
> >> has a scalability limitation of about 60 connections.  
> Since the only 
> >> known way around this limitation that I'm aware of requires adding 
> >> threads to the library, the scalability limit will be 
> addressed in a 
> >> subsequent version, once the needs of a real application are 
> >> determined.
> >>
> >I guess that you are talking about the limitation of 
> >WaitForMultipleObjects ?
> 
> Yes
> 
> >In that case, there is another workaround that is possibale 
> and that is 
> >to use the kernel function KeWaitForMultipleObjects which 
> doesn't have 
> >this limitation. Not exactly straight forward, but if we see 
> that there 
> >is a real need for biger scales than I guess that this is also an 
> >option to consider.
> 
> Thanks - I've started looking at how to work around the 
> problem, and I'll see what it'll take to use this option.
> 
> - Sean

I guess that the basic should be simple. Add a function in IBAL (or
actually whatever driver you want) that will simply do the wait. The
only thing to note is that in your user code you have handles to events
which should be translated to events that can be used by the kernel. The
kernel api that does this is ObReferenceObjectByHandle().
The one question that remains open is weather to do the user to kernel
mapping per wait operation or to have a cache of these kernel objects.

There is a very good example to such code at:
WINDDK\6001.18001\src\general\event

And the last thing (which you probably know) is making sure that the
kernel code never trusts the user code to pass correct arguments.

Thanks
Tzachi