[openib-general] openib gen2 architecture

[Michael Krause]

At 09:41 AM 11/18/2004, Grant Grundler wrote:
>On Thu, Nov 18, 2004 at 06:14:47PM +0200, shaharf wrote:
> > Personally, I think that IB verbs (vapi) are so complicated that
> > another level of abstraction is required. PDs, MRs, QPs QP state machine,
> > PKEYs, MLIDs and other "curses", why should a module such as IPoIB
> > knows about it?
> > If the answer is performance then I have to disagree. In the same fashion
> > you can say that in order to achieve efficient disk IO applications
> > should know the disks geometry and to able to do direct IO to the disk
> > firmware, or that applications should talk SCSI verbs to optimize their
> > data transfers.

In general, there is very little that IP over IB must know to operate.  It 
really comes down to the design implementation and the choices people want 
to make.   Given this is an open source project, one might suggest that if 
there is a better way to structure the design, then implement and propose 
it as a replacement.

> > I wonder if this is not the right time to come up with much better
> > abstraction - for user mode and for kernel mode. For example, it
> > seems that the abstraction layer should abstract the IB networking
> > objects and not the IB hca interface. In other words - why not to build
> > the abstraction around IB networking types - UD, RC, RD, MADS?

Some designs are modular in nature and keep consumers such as IP over IB 
from having to know much more than the QP / work queue / completion queue 
to operate.  It again comes down to design as some focus on maximum code 
re-use.  For example, there is nothing that precludes an implementation 
from using a kernel IT API / DAPL interface for most subsystems in order to 
free itself from all of these details.

Mike 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20041118/1727046d/attachment.html>