All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roland Dreier <roland@topspin.com>
To: "Woodruff, Robert J" <woody@co.intel.com>
Cc: "Greg KH" <greg@kroah.com>,
	"Woodruff, Robert J" <woody@jf.intel.com>,
	<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: 15 Mar 2004 17:41:50 -0800	[thread overview]
Message-ID: <52oeqxo9ep.fsf@topspin.com> (raw)
In-Reply-To: <1AC79F16F5C5284499BB9591B33D6F000B4805@orsmsx408.jf.intel.com>

I understand that you've only had a short time to review the code, and
many of your comments are points well taken.  I think most of the
technical comments can wait to be debated on the openib.org mailing
lists (which I am assured are coming soon).  However, since this is
being preserved for posterity in the linux-kernel archive, I wanted to
correct a few inaccuracies.

    Robert> 3.) The code is not compliant with the InfiniBand
    Robert> specification and has proprietary implementations of
    Robert> things like "path records" so it will only work with the
    Robert> TopSpin subnet manager that requires you to buy a topspin
    Robert> switch.

This is definitely not our intent, and we fix whatever IB compliancy
bugs we find as soon as we know about them.  In addition, I know that
people have been able to use the Topspin/Mellanox code from OpenIB
with OpenSM and no Topspin switch (this did require some compliance
fixes to both OpenSM and the Topspin code).

    Robert> 6.)The VAPI code has extra propietary verbs that are not
    Robert> specified by the InfiniBand Specification.

True, but I'm not sure why this is a deficiency.  We found certain
things that were required for good performance were not specified by
the IBTA, and we added them.  The Linux way is definitely not to
follow a spec when the spec is wrong.

    Robert> 9.) The CM does not support reliable datagrams.

Fair enough but I'm sure we can easily add RD support before any
hardware supporting RD is ready.  We took a pragmatic approach and
didn't implement "speculative" features.

    Robert> 10) There is no built in support for plug and play events,
    Robert> port up/down, LID change, SM change

I'm not sure what plug and play events are (certainly they're not part
of the IB spec).  However, we did add extended IB asynchronous events
for LID/SM changes and P_Key changes (port up and down are already
part of the IB spec).

As I said above, the rest of your points are well taken (although of
course there are two sides to every story) and we can talk about them
when we get the openib.org mailing lists up.

 - Roland

  parent reply	other threads:[~2004-03-16  1:45 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-15 22:52 PATCH - InfiniBand Access Layer (IBAL) 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 [this message]
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
  -- 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-14 23:14 Nivedita Singhvi
2004-03-14  3:46 Woodruff, Robert J
2004-03-15  2:10 ` Greg KH
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=52oeqxo9ep.fsf@topspin.com \
    --to=roland@topspin.com \
    --cc=arlin.r.davis@intel.com \
    --cc=greg@kroah.com \
    --cc=jerrie.l.coffman@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sean.hefty@intel.com \
    --cc=woody@co.intel.com \
    --cc=woody@jf.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.