There's no rdma_migrate_id, so an accepted cm_id (from a ConnectRequest) stays on the listener's EventChannel. Since the raw cm_id is private, it can't be migrated from outside the crate either.
Why it's useful
A server that accepts on one thread and runs each connection on its own thread needs each connection's CM events (Established, Disconnected) on its own channel. On a shared listener channel, a worker's establish-wait races the acceptor's next get_cm_event, and an event can be delivered to the wrong waiter. rdma_migrate_id is the standard fix (it's what rping does to hand an accepted id to a per-connection channel). Today a single, serial acceptor works fine, but a concurrent one doesn't.
Suggested API
impl Identifier {
pub fn migrate(&self, channel: &Arc<EventChannel>) -> Result<(), MigrateError>;
}rdma_migrate_id is already in rdma-mummy-sys's bindings, so this is wrapper-only AFAIK.
There's no
rdma_migrate_id, so an acceptedcm_id(from aConnectRequest) stays on the listener'sEventChannel. Since the rawcm_idis private, it can't be migrated from outside the crate either.Why it's useful
A server that accepts on one thread and runs each connection on its own thread needs each connection's CM events (
Established,Disconnected) on its own channel. On a shared listener channel, a worker's establish-wait races the acceptor's nextget_cm_event, and an event can be delivered to the wrong waiter.rdma_migrate_idis the standard fix (it's whatrpingdoes to hand an accepted id to a per-connection channel). Today a single, serial acceptor works fine, but a concurrent one doesn't.Suggested API
rdma_migrate_idis already inrdma-mummy-sys's bindings, so this is wrapper-only AFAIK.