Re: [2.6] The List, pass #2

[Roland Dreier <roland@topspin.com>]

>>>>> "Albert" == Albert D Cahalan <acahalan@cs.uml.edu> writes:

    Albert> As I said, "one could get fancy", thus missing the 2.6.xx
    Albert> kernel.  It's pretty obvious that you could do SCSI and IP
    Albert> with much less code. What's with the "HCA DDK" anyway, UDI
    Albert> reborn? I see all sorts of layers for IPC and what looks
    Albert> like VI/VIA, etc.

    Albert> Ditch the lofty goals, and you might make the 2.6.xx
    Albert> kernel.  You can stick to being a FireWire alternative for
    Albert> now.

The idea behind the HCA DDK is to let IB hardware drivers only
implement the details of the hardware they support, while keeping the
generic code generic.  It's similar in spirit to the way Linux doesn't
force ethernet drivers to implement the whole TCP stack.

Unfortunately the "VI layer" you mention is just about the lowest
level it makes sense to talk to IB hardware.  IB chips really do
operate in terms of queue pairs, completion queues, memory regions and
so on.  Other stuff like path record lookup is a necessary to use an
IB fabric (nodes are identify by a GUID, but packets need to be sent
to a LID, and the mapping of GUID->LID is not necessarily fixed).

I agree that it's a shame that the IB spec is so absurdly complex.
And it probably is true that you could come up with a simplified way
of using IB hardware that would be easier to code for.  However, I
don't think you'll find much interest in the IB world in implementing
Linux-specific, non-interoperable, non-IB-spec-compliant software.

Best,
  Roland