> Why should clients have to emulate asynchronous behavior when the > (Mellanox) HCA command interface is already asynchronous?
That's one HCA command model... others may not be (eg I believe ehca makes synchronous hypercalls to do things like modify QP, and ipath is pure software with no other asynchronous entity to talk to). > I would prefer any threading be added to the HCA driver in the > kernel, and not as threads in each process. That would enable a > seamless transition to a better driver model in the future. Of course Windows can (and should!) design the best API for Windows; however for Linux I would probably argue in favor of conservatism (follow the model we've had for years when it's not totally broken) and simplicity (it's hard for developers to get callback-based async APIs right, and I'd rather not have an API that tries to allow both async and sync ways of doing the same thing). - R. _______________________________________________ ofw mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
