[RFC] define common trait for cq and cq_ex

[FujiZ]

A CQ object is required when creating QP. However, since we have 2 variants of CQ (ibv_cq, ibv_cq_ex), it would be more appropriate to have a trait of CQ to interact with other components rather than specifying a concrete type.

Things to discuss:

1. The name of the trait: CompletionQueue has been taken by the ibv_cq wrappper. Maybe we can rename the original CompletionQueue and name the trait CompletionQueue, or maybe we can pick a new name for the trait instead?
2. Methods that should be supported by this trait. Maybe a method returning NonNull<ibv_cq> is necessary.

The same discussion applys for QP as well.

[dragonJACson]

1. I would suggest CompletionQueueOps for an AIO name. As a non-official convention, we should name a trait with verb. > noun. > adj.
   Or we could just add a bound Into<CompletionQueue>.

2. I agree, but that API would be unsafe right?

[FujiZ]

1. I would suggest CompletionQueueOps for an AIO name. As a non-official convention, we should name a trait with verb. > noun. > adj.

Cool, is there any example for this XXOps-style naming convertion?

[dragonJACson]

1. I would suggest CompletionQueueOps for an AIO name. As a non-official convention, we should name a trait with verb. > noun. > adj.

Cool, is there any example for this XXOps-style naming convertion?

As far as I know, no. But in axum, such trait would be named XXXExt, but it would be confusing when used with CompletionQueueExtended I guess

[FujiZ]

How about naming the trait CompletionQueue and naming the wrapper struct of ibv_cq and ibv_cq_ex BasicCompletionQueue and ExtendedCompletionQueue, respectively?

If a common trait is defined for these two structs, then we can easily tell the relationship between them through the Implementors of that trait in doc, thus making the suffix naming trick mentioned in #9 (comment) unnecessary.

Take the AsyncRead trait in tokio as an example: https://docs.rs/tokio/latest/tokio/io/trait.AsyncRead.html#implementors We can see that structs like TcpStream, UnixStream, DuplexStream implement AsyncRead, and they are not named after StreamTcp, SteamUnix and StreamDuplex.

[dragonJACson]

How about naming the trait CompletionQueue and naming the wrapper struct of ibv_cq and ibv_cq_ex BasicCompletionQueue and ExtendedCompletionQueue, respectively?

If a common trait is defined for these two structs, then we can easily tell the relationship between them through the Implementors of that trait in doc, thus making the suffix naming trick mentioned in #9 (comment) unnecessary.

Take the AsyncRead trait in tokio as an example: https://docs.rs/tokio/latest/tokio/io/trait.AsyncRead.html#implementors We can see that structs like TcpStream, UnixStream, DuplexStream implement AsyncRead, and they are not named after StreamTcp, SteamUnix and StreamDuplex.

That sounds reasonable, so let's rename them and change the corresponding parameters to generic type in our next PR.