[Rdma-developers] Re: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMAAPIs and ULPs for Linux

[Grant Grundler]

On Sat, May 28, 2005 at 04:26:43PM -0700, Caitlin Bestler wrote:
...
> if so what the best strategy for
> achieving it is (try to plan an IB/iWARP merge immediately
> or wait until there is an iWARP code base).

If there is no iWARP code base, I fail to see how one can merge.
Having a specification is one basis for communication.
Linux developers normally use existing code as the basis.
Committees submit CRs (Change Requests) to update specs.
The CRs get voted on by the committee.
Linux developers submit patches.
The Linux subsystems maintainer(s) decide if patches are ok or not.


> Claiming that an InfiniBand-specific  interface is somehow
> thinking "long term" is just plain ludicrous.

"It Works" is worth 10x more to *any* customer than a transport
neutral API that only exists as a spec.

The specs are guides to how something *should* work and
linux tries to comply with them (e.g. 802.3 or T10) where
HW implementations actually follow the spec. That doesn't
mean linux has to implement every brain damaged spec that
some committee comes up with....OTOH, rdmaconsortium.org
does have a fair shot given I2O made it into the kernel. :^/

(I'm willing to have a conversation about why I think I2O
is brain damaged if someone else is buying drinks. It's
not total crap, but it certainly has it's downside.)

> Now it may be that the short term interest of the InfiniBand
> vendors is such that they cannot commit resources to
> helping build a transport neutral API. That is always a
> legitimate tradeoff, but it is "short term corporate thinking".

Please, that horse is already dead.
They have offered to review patches to make the API transport neutral.
Test that offer. Submit patches and move the conversation
on to something that is more constructive.

> Last time I looked most of the commits being made to
> OpenIB (or sourceforge DAPL) were from being drawing
> paychecks from those "evil corporations".

Yes, so?
The issue isn't the funding - it's the goals.

Compare the "gen1" stack (I'm being careful to not pick on
any IB vendors) to the gen2 stack. The difference is between
corporate code and "linux" code - mostly funded by the
same corporation with several of the same programmers.
"gen1" stack came from somehing that attempted to build/run
a shared user/kernel space on every distro. The Makefiles
are just a mess - nevermind the code.

grant