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

[Venkata Jagana]

Exactly, the code matters from Linux community standpoint
and the discussion around the convergence of common PI is
mute until we have that header file definition but which will come
out soon. 

However, I am quite glad to see the OpenIB and
OpenRDMA communities in agreement on common
ULP's and DAPL/IT-API (even though, there are some
disagreements on these APIs).

Also, as you pointed out, I absolutely agree the differences between 
Gen1 and Gen2 but which is exactly what I wanted to avoid
with OpenRDMA and rather start from a clean slate right from
the beginning through "opensource" fashion - basically,
don't want the code to be dumped by some corporate
developers. 

Thanks
Venkat



rdma-developers-admin at lists.sourceforge.net wrote on 05/31/2005 09:38:51 
AM:

> 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
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit 
http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> _______________________________________________
> Rdma-developers mailing list
> Rdma-developers at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rdma-developers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20050531/334db43f/attachment.html>