Refactor vring abstraction

[jiangliu]

Add trait VringT and provide three implementation of it: VringState, VringMutex, VringRwLock,
so clients could choose different implementation.

[stefano-garzarella]

The refactor looks great, just a couple of simple copy&paste typos :-)

[slp]

Thanks for working on this. I must be missing something, but I can't find a way to access the underlying Queue in VringState to iterate over it. What's the pattern to lock the Vring and iterate on the Queue to get the descriptor chains?

[jiangliu]

Thanks for working on this. I must be missing something, but I can't find a way to access the underlying Queue in VringState to iterate over it. What's the pattern to lock the Vring and iterate on the Queue to get the descriptor chains?

I realized this issue and have updated the patch yesterday. Now we have "VringState::get_queue()" and "VringState::get_queue_mut()" for that purpose.
https://github.com/rust-vmm/vhost-user-backend/pull/30/files#diff-04f224919b2745af8bfb2d2aea4be7d9100e861a8a16f2cd0263cb1021b44c4dR151

[slp]

Thanks for working on this. I must be missing something, but I can't find a way to access the underlying Queue in VringState to iterate over it. What's the pattern to lock the Vring and iterate on the Queue to get the descriptor chains?

I realized this issue and have updated the patch yesterday. Now we have "VringState::get_queue()" and "VringState::get_queue_mut()" for that purpose.
https://github.com/rust-vmm/vhost-user-backend/pull/30/files#diff-04f224919b2745af8bfb2d2aea4be7d9100e861a8a16f2cd0263cb1021b44c4dR151

Great, thanks!

I've tested this crate with virtiofsd, and was able to implement both a multi-threaded method and a single-threaded method for processing the queue, so I think this model should work for most consumers of this crate.

One change that I think could be interesting, is publishing VringStateGuard and VringStateMutGuard in the root of the crate (since vring is private). That allows consumers to acquire a reference to VringState (and thus, the underlying lock, if using VringMutex or VringRwLock) once and pass it around to other methods. What do you think about this?

[jiangliu]

Thanks for working on this. I must be missing something, but I can't find a way to access the underlying Queue in VringState to iterate over it. What's the pattern to lock the Vring and iterate on the Queue to get the descriptor chains?

I realized this issue and have updated the patch yesterday. Now we have "VringState::get_queue()" and "VringState::get_queue_mut()" for that purpose.
https://github.com/rust-vmm/vhost-user-backend/pull/30/files#diff-04f224919b2745af8bfb2d2aea4be7d9100e861a8a16f2cd0263cb1021b44c4dR151

Great, thanks!

I've tested this crate with virtiofsd, and was able to implement both a multi-threaded method and a single-threaded method for processing the queue, so I think this model should work for most consumers of this crate.

One change that I think could be interesting, is publishing VringStateGuard and VringStateMutGuard in the root of the crate (since vring is private). That allows consumers to acquire a reference to VringState (and thus, the underlying lock, if using VringMutex or VringRwLock) once and pass it around to other methods. What do you think about this?

Done:)

[slp]

Thanks again! :-)

[slp]

@jiangliu Could you please rebase this on top of f0af5f7 ?

That should fix CI.

[slp]

LGTM (again), thanks!