Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid CQ drop failures #14

Closed
kykosic opened this issue Jun 7, 2021 · 1 comment
Closed

Avoid CQ drop failures #14

kykosic opened this issue Jun 7, 2021 · 1 comment

Comments

@kykosic
Copy link

kykosic commented Jun 7, 2021

I was running into an issue related to the Drop implementation for CompletionQueue objects. I am unsure if there is a good way to handle it, or if an API improvement can be made to avoid panic. Example:

fn main() {
    let ctx = ibverbs::devices()
        .unwrap()
        .iter()
        .next()
        .expect("no rdma device available")
        .open()
        .unwrap();

    let cq = ctx.create_cq(16, 0).unwrap();
    let pd = ctx.alloc_pd().unwrap();

    let _qp_builder = pd
        .create_qp(&cq, &cq, ibverbs::ibv_qp_type::IBV_QPT_RC)
        .build()
        .unwrap();

    // something bad happens, perhaps returning Err(...)

   
}  // CompletionQueue::Drop -> panic!

A common example of "something bad happens" is an application fails to send the serialized QueuePairEndpoint. In this case, I would like the function to return gracefully and everything resume operation. However, here the Drop of CompletionQueue will panic, I believe because the queue pair is still associated with it.

Is there any existing way to make the above drop happen gracefully?

@daniel-noland
Copy link
Contributor

A common example of "something bad happens" is an application fails to send the serialized QueuePairEndpoint. In this case, I would like the function to return gracefully and everything resume operation. However, here the Drop of CompletionQueue will panic, I believe because the queue pair is still associated with it.

I have noticed this as well. I have been debugging it a bit (this issue is one of the reasons I am working on #13).

@jonhoo jonhoo closed this as completed in 4fd1f49 Oct 17, 2021
jonhoo added a commit that referenced this issue Oct 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants