[openib-general] Upstream submission

[Roland Dreier]

    Paul> Has the code been used in anger enough?
    Paul> There seem to be a lot of bugs still being discovered daily.

I think in most scenarios IPoIB is quite stable.  I've run many
gigabytes of traffic without trouble.  There may still be corner cases
with module unloading and the like, but I think the best way to fix
those is to get enough testers so that we can start to see a pattern
to the problems.

    Paul> Wouldn't having at least a preliminary set of user
    Paul> capabilities help assessment of the low level code and allow
    Paul> a wider set of people to evaluate it.

I think we're better served in starting with as small and digestible a
chunk of code as possible and building on that.  Getting a foot in the
door and all that...

    Paul> Perhaps over the next month Doug could be a 'dry run guinea
    Paul> pig' for kernel inclusion and highlight the documentation
    Paul> and coding areas of difficulty prior to submission for a
    Paul> wider audience.

I think we're really at the point where we're ready for a full lkml
code review.  Certainly I think we're at a level of stability and
functionality that is appropriate for inclusion in an -mm kernel if
not Linus's tree.  The code doesn't need to be perfect before it gets
in the kernel -- just good enough to be usable and benefit from the
increased test coverage.

I do plan on marking the InfiniBand Kconfig options as EXPERIMENTAL,
so that should help set expectations.

    Paul> I am concerned that an overly changeable or buggy submission
    Paul> may do more harm than good.

In the past there certainly have been submissions to lkml that were
far too early.  However our current tree is definitely not an
embarrassment: there aren't any gross violations of coding standards,
we use modern interfaces like sysfs correctly, and so on.

Thanks,
  Roland