Re: [Infiniband-access_layer] SourceForge integration with OpenIB

[Ashok R. <ash...@in...>]

On Tue, May 18, 2004 at 03:55:26PM -0700, Hefty, Sean wrote:
> 
>    We  are  now ready to begin the integration process of the SourceForge
>    Infiniband Access Layer into openib.  As part of this process, we will
>    start taking all necessary steps to prepare the code for consideration
>    by  the  Linux  kernel  development community.  (E.g. reformatting the
>    code, integrating complib, removing OS abstractions, etc.)  While this
>    is  occurring,  we  would like to ask that all non-critical patches be
>    delayed  until these changes are complete and then recreated using the
>    updated code base.

One suggestion is when you do these, please do them in consolidated group
of changes.
	- Fix formatting and checkin as a separate changeset
	- Fix complib dependency as a separate change set
	- etc.. so that you can avoid looking at a huge change that looks
	  entirely different.

on complib: i think for IB code if the groups interest is portablity, you would
want to retain that. But what might appease the lkml community (if not 
completely) is not to export outside of IBAL infrastructure code.

so if we dont export new spinlock, or other abstractions to outside of ibal 
that may be acceptable (???) only downside is other channel drivers such as
SRP/IPOIB would be completely linux native, which probably is OK? I guess
the SRP code may be able to share a big chunk of code amount other
implementations, not sure exactly how the Best of breed SRP looks like today.

Hopefully you will do this on the top version of 2.6.6 or greater. If so
in complib there are some abstractions like creating a single kernel
thread, creating a pool of threads which should be changed to use native 
mechanisms in 2.6 instead for better use. For e.g create_workqueue(),
create_singlethread_workqueue() etc depending on use, that can 
automatically handle creating on each cpu. There is also code for
handling hotplug CPU, that can scale the kernel threads depending on a new
CPU arrival.

As far as possible use the system service threads already in place, without creating too many new ones...

... my 2c worth...

Cheers,
ashok