<html>
<body>
<font size=3>At 09:41 AM 11/18/2004, Grant Grundler wrote:<br>
<blockquote type=cite class=cite cite="">On Thu, Nov 18, 2004 at
06:14:47PM +0200, shaharf wrote:<br>
> Personally, I think that IB verbs (vapi) are so complicated
that<br>
> another level of abstraction is required. PDs, MRs, QPs QP state
machine,<br>
> PKEYs, MLIDs and other "curses", why should a module such
as IPoIB<br>
> knows about it?<br>
> If the answer is performance then I have to disagree. In the same
fashion<br>
> you can say that in order to achieve efficient disk IO
applications<br>
> should know the disks geometry and to able to do direct IO to the
disk<br>
> firmware, or that applications should talk SCSI verbs to optimize
their<br>
> data transfers.</font></blockquote><br>
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.<br><br>
<blockquote type=cite class=cite cite=""><font size=3>> I wonder if
this is not the right time to come up with much better<br>
> abstraction - for user mode and for kernel mode. For example,
it<br>
> seems that the abstraction layer should abstract the IB
networking<br>
> objects and not the IB hca interface. In other words - why not to
build<br>
> the abstraction around IB networking types - UD, RC, RD,
MADS?</blockquote><br>
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.
<br><br>
Mike</font></body>
</html>