[openib-general] RFC on SDP checkin

[Libor Michalek]

On Fri, Feb 04, 2005 at 08:04:10PM -0000, Paul Baxter wrote:
> > On Fri, Feb 04, 2005 at 11:33:18AM -0800, Tom Duffy wrote:
> >> On Fri, 2005-02-04 at 11:21 -0800, Libor Michalek wrote:
> >> >   3) Since the rest of the tree is not destabilized or effected in
> >> >      any other way by the code, just check it into tree itself.
> >> >      (e.g. gen2/trunk/src/linux-kernel/infiniband/ulp/sdp)
> >> >
> >> >   Anyone have thoughts on this? Personally I'm leaning towards #3,
> >> > but that's because it's the least amount of work for me. :)
> >>
> >> I would like #3 as well.  Libor, would it be possible to get a preview
> >> of what is going to be checked in?  Maybe with a small one-pager about
> >> how to use it, etc?
> >
> >  You mean a quick description of the code, like the primary contents of
> > each file and how to get it to do something ?
> 
> I would be interested in knowing whether zero copy, asynchronous sockets 
> made it into the code and, much like the SDP performance tests last year, a 
> set of netperf figures and a comparison of cpu utilisation with bandwidth 
> would be nice to whet my appetite.

  Linux AIO sockets support is in place, but AIO plus RDMA is waiting
on FMR support in mthca. Once the intial code is in place one of the
features I was planning in this area was SDP RDMA support for blocking
synchronous sockets. This should be much easier in 2.6 since the sync
and async APIs now have the same socket entry points.

  I was hoping to do the performance figures on PCIe systems, but I
seem to be having 2.6 sata support issues on the systems I have, so I
might provide some numbers on the older PCI-X systems.

> I guess the main issue with location is in regard to what constitutes the 
> kernel submission. AFAIK its still uncertain as to the legal position of 
> using SDP code, is that right? or did it get resolved to everyone's 
> satisfaction (esp greg kh :) )

  Well, unlike the previous submission, I was planning on making this
submission using the exact same license as the rest of the OpenIB code,
without reference to any other "possible" IP. 

  I'm not sure what will be required for different people's satisfaction
on the legal position, and I suspect that it will evolve over time.
However, I believe the best way to make that happen is for everyone to be
able to look at and comment of the code itself. 


-Libor