All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: "Woodruff, Robert J" <woody@co.intel.com>
Cc: linux-kernel@vger.kernel.org, "Hefty,
	Sean" <sean.hefty@intel.com>,
	"Coffman, Jerrie L" <jerrie.l.coffman@intel.com>,
	"Davis, Arlin R" <arlin.r.davis@intel.com>
Subject: Re: PATCH - InfiniBand Access Layer (IBAL)
Date: Sun, 14 Mar 2004 18:10:09 -0800	[thread overview]
Message-ID: <20040315021009.GA18106@kroah.com> (raw)
In-Reply-To: <1AC79F16F5C5284499BB9591B33D6F000B630B@orsmsx408.jf.intel.com>

On Sat, Mar 13, 2004 at 07:46:12PM -0800, Woodruff, Robert J wrote:
> On Sat, Mar 13, 2004 at 02:07:13PM -0800, Greg KH wrote:
> >I think you need to work with the openib.org people as they seem to
> >have:
> >	- working code with support for a number of different devices
> I have code that has been running MPI NBPs, Pallas benchmark, and IPoIB
> stress tests for almost 10 days now on multiple vendors equipment. We
> are also close to having a major data base vendor's DAPL stress test
> running very well.  I'm thinkin this code could be running 1000 nodes
> clusters within a couple of months, if people wanted to try it, but
> that would require Mellanox to open source their TVPD. 

Hm, without open source drivers, the Intel stack doesn't seem very
viable, correct?

> >	- developers with extensive kernel programming experience
> As if we don't. 

Former kernel subsystem maintainers?  I did not realize that.

> >	  working on cleaning up the code to fit properly into the
> >	  kernel tree.
> The comments you have given on IBAL would probably only take a few weeks
> to change.

Is that work already underway?  Finished?  If neither, why not?

> >	- their code showing up in at least one distro which will expose
> >	  them to a much wider range of testing than Intel's project so
> >	  far has had.
> Ok, the OEMS pushed for and got a distro to accept a TTM solution,
> that's OK for getting InfiniBand jumpstarted, but does that mean we
> have to accept it into Linux and live with that solution forever. 

We constantly change the kernel.  Look at the USB stack.  It has been
rewritten completely almost 3 times now.  Did anyone really notice
besides the wonderful speed improvements?  :)

We never have to "live with a solution forever."

> I guess I just wish they had started working with us on this open source
> project 2 years ago when we started it, rather than developing a
> complete stack behind closed doors and then releasing it without any
> input from anyone.

There have been numerous closed source IB stacks for Linux.  Just like
there were numerous Bluetooth stacks for Linux in the past.  Over time
the closed ones are weeded out as everyone relies on the in-kernel one.

> Now there are serious issues that will take a lot of work to fix.

What are the issues with the OpenIB stack?  If there are any, how does
the Intel stack solve those issues?  Could the Intel solutions be merged
into the OpenIB stack to solve these issues?

> At least our project was totally open from the start and anyone could
> have provided input at any time. 

I understand your frustrations, I've been there before.

Good luck,

greg k-h

  reply	other threads:[~2004-03-15  2:10 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-14  3:46 PATCH - InfiniBand Access Layer (IBAL) Woodruff, Robert J
2004-03-15  2:10 ` Greg KH [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-03-20 19:15 Acker, Dave
2004-03-20 17:15 Acker, Dave
2004-03-20 17:55 ` Ulrich Drepper
2004-03-21 22:16   ` Roland Dreier
2004-03-15 22:52 Woodruff, Robert J
2004-03-15 23:17 ` Christoph Hellwig
2004-03-15 23:44   ` Johannes Erdfelt
2004-03-15 23:48     ` Christoph Hellwig
2004-03-15 23:54       ` Johannes Erdfelt
2004-03-16  0:09         ` Christoph Hellwig
2004-03-16  0:18           ` Johannes Erdfelt
2004-03-16  1:41 ` Roland Dreier
2004-03-19 18:47 ` Ulrich Drepper
2004-03-19 19:21   ` Fab Tillier
2004-03-19 20:20     ` Ulrich Drepper
2004-03-19 20:47   ` Roland Dreier
2004-03-14 23:14 Nivedita Singhvi
2004-03-13 22:07 Woodruff, Robert J
2004-03-14  1:13 ` Andrew Morton
2004-03-14  2:28 ` Greg KH
2004-02-24 23:02 Woodruff, Robert J
2004-02-25  3:32 ` Rik van Riel
2004-02-24 22:18 Woodruff, Robert J
2004-02-24 21:33 Woodruff, Robert J
2004-02-24 19:29 Woodruff, Robert J
2004-02-24 19:44 ` Greg KH
2004-02-24 19:50   ` Christoph Hellwig
2004-02-24 19:57     ` Greg KH
2004-02-24 22:29       ` Rik van Riel
2004-02-25  0:28         ` Matti Aarnio
2004-02-25  3:39           ` Rik van Riel
2004-02-25 16:25             ` Timothy Miller
2004-02-25 17:34               ` Roland Dreier
2004-02-25 18:55               ` Sam Ravnborg
2004-02-25 18:05                 ` Linus Torvalds
2004-02-25 19:09                   ` Timothy Miller
2004-02-25 19:55                   ` Sam Ravnborg
2004-02-25 19:05                     ` Linus Torvalds
2004-02-25 13:19           ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040315021009.GA18106@kroah.com \
    --to=greg@kroah.com \
    --cc=arlin.r.davis@intel.com \
    --cc=jerrie.l.coffman@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sean.hefty@intel.com \
    --cc=woody@co.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.