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
_______________________________________________ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
