Quoting r. Sean Hefty <[EMAIL PROTECTED]>: > >>The alternative is to have the API behave one way for destination addresses > >>that > >>are local, versus those that are remote, but this complicates applications > >>that > >>are not aware if an address belongs to the local or a remote system. > > > > So, maybe we can reuse the ib_addr wq? Having all requests complete from > > a single thread could help applications, I think.
> I did consider pushing this down into ib_addr because it has an existing work > queue, and it would have been easier to implement, but ib_addr simply > converts > an IP address into a GID/pkey. To keep the CMA RDMA centric, rather than > IB-specific, it seemed better to me to map lookback addresses to an RDMA > device > outside of IB specific code. For example, if the mapping were moved into > ib_addr, then loopback addresses would not work for a system containing only > iWarp devices. Does it really matter in which module doe sthe function reside? > If there's concern about using too many work queues in the IB stack, we could > export a single work queue from ib_core that's accessible to multiple > modules. > Work queues appear to be used by these modules: ib_mad, rdma_cm, ib_cm, > ib_addr, > sdp, and ipoib. > > - Sean > Sounds good, I would start with just rdma_cm ib_cm and ib_addr. But note that exposing the wq means you must be explicit on what runs on this queue, since otehrwise a user can flush the queue from inside it or other such deadlocking silliness. Need to be careful. -- MST _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
