Sean Hefty wrote:
I said "clean way to do it". ;-)
I'm referring to an rdma cm connection protocol for iWarp. We have one
for IB. I mentioned uDAPL as a possibility because it abstracts the
transport, QP, CQ, etc. anyway, and one could argue that the uDAPL iWarp
provider should take necessary steps to support the uDAPL API.
There is one OpenFabrics uDAPL provider for all OFA devices. Sure, we
could add some logic in the DAPL abstraction layer to check for iWARP
devices and possibly hide the restriction. Say we do that, what about
the applications that sit directly on top of OFA verbs and rdma_cm? Say
we add some iWARP abstraction at this layer, what about the WinOF stack?
I don't know that there's a need to change the iWarp architecture.
If you think customers are willing to work around this restriction then
by all means leave the architecture alone and simply document the rdma
API's. I would think that this put's iWARP vendors at a disadvantage.
I am guessing that energy and time spent changing the iWARP protocol
specification is a better use of everyone's time then hacking every
iWARP stack out there to hide the restriction.
-arlin
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
