Skip to content

Split virtio-queue into multiple submodules for maintenance #120

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

Merged
merged 11 commits into from
Nov 26, 2021

Conversation

jiangliu
Copy link
Member

@jiangliu jiangliu commented Nov 21, 2021

Fix #87 by split the lib.rs of virtio-queue into multiple submodules:

  1. split it into several submodules for maintenance
  2. use setter/getter to avoid direct access to data structure fields
  3. refine unit test cases to improve code coverage, now it reaches 90% code coverage.

Refine doc for constant definitions to make them symmetric.

Signed-off-by: Liu Jiang <[email protected]>
Move Descriptor to a dedicated file as a submodule. Also avoid direct
accesses to Descriptor's fields.

Signed-off-by: Liu Jiang <[email protected]>
Move DescriptorChain/DescriptorChainRwIter to a dedicated file as a
submodule.

Signed-off-by: Liu Jiang <[email protected]>
Move VirtqUsedElem into descriptor.rs and add more unit test cases.

Signed-off-by: Liu Jiang <[email protected]>
Split `struct AvialIter` into a submodule.

Signed-off-by: Liu Jiang <[email protected]>
@bonzini
Copy link
Member

bonzini commented Nov 21, 2021

The QueueStateSync API is absolutely not ready for being published.

Split `struct QueueState` into a submodule.

Signed-off-by: Liu Jiang <[email protected]>
Split `struct QueueStateSync` into a submodule.

Signed-off-by: Liu Jiang <[email protected]>
Split `struct Queue` into a submodule.

Signed-off-by: Liu Jiang <[email protected]>
Change unit test cases to directly use Queue methods.

Signed-off-by: Liu Jiang <[email protected]>
Add unit test cases for QueueStateSync to show the sample usage and
improve code coverage.

Signed-off-by: Liu Jiang <[email protected]>
@jiangliu jiangliu force-pushed the refine branch 2 times, most recently from d22bcee to 1df099c Compare November 21, 2021 14:52
Adjust code coverage for x86_64. Also modify git ignore file to
ignore .idea directories.

Signed-off-by: Liu Jiang <[email protected]>
@jiangliu
Copy link
Member Author

The QueueStateSync API is absolutely not ready for being published.

Well formed API designs are always welcomed:)
But we hope we could publish the virtio-queue crate sooner than later, because several other projects depend on it. The situation has last more than one year. We have tried several times during the past year to migrate to the upstream vm-virtio implementation but failed. Then the cloud hypervisor, virtiofsd and our projects turned to maintain their own private versions, it's really a burden for us:(

@jiangliu
Copy link
Member Author

The QueueStateSync API is absolutely not ready for being published.

BTW, I have one more patch to convert QueueStateGuard from an enum into a trait, just as one of your previous patch did. It does help to make the API clear and extensible:)

@jiangliu jiangliu changed the title [WIP] Prepare virtio-queue for publishing Split virtio-queue into multiple submodules for maintenance Nov 21, 2021
@bonzini
Copy link
Member

bonzini commented Nov 21, 2021

The problem is that Queue is not solving the problem in a way that works for the vhost-backend crate for example.

I think we don't even need Queue or QueueSync. What we need is a good guard object so that one doesn't have to use the flexible API with GuestMemory arguments, when the easier one can be used.

In addition, signal_used_queue must definitely be a trait and the guard should know about it. I'll try to come up with something later this week.

@jiangliu
Copy link
Member Author

The problem is that Queue is not solving the problem in a way that works for the vhost-backend crate for example.

Actually we need to support several use cases:

  1. support normal virtio devices, such as virtio-blk/virtio-net
  2. support vhost daemons with vhost-user-backend
  3. support rust async io to improve performance

I think we don't even need Queue or QueueSync. What we need is a good guard object so that one doesn't have to use the flexible API with GuestMemory arguments, when the easier one can be used.

Is this something you are thinking of? #121 It introduces two changes:

  • convert enum QueueStateGuard to trait QueueStateGuard for extensibility and zero-cost abstraction.
  • introduce "struct QueueGuard` to encapsulate a QueueStateGuard object and associated guest memory object.

In addition, signal_used_queue must definitely be a trait and the guard should know about it. I'll try to come up with something later this week.

Copy link
Collaborator

@alexandruag alexandruag left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This def looks good as breaking up the code into separate modules is something that's been long overdue. Thanks Gerry! Left just one comment regarding some of the tests.

}

#[cfg(test)]
mod tests {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, looks like most of the tests here would apply to other QueueStateT implementations just as well. It would actually be great to have a battery of tests for the QueueStateT interface that can then be reused to test all implementations (so far there's QueueState and QueueStateSync), and then separate tests for stuff that's specific to QueueStateSync in particular (altho there's not that much truly specific stuff IMO; even the test where multiple threads are spawned can be seen as generic due to lock being part of the high level interface).

Not sure exactly just how much effort that would require, so maybe doing it as part of this PR is not the best approach, but then I think we should at least have an issue and tackle it b4 publishing.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will open one issue for it once the PR get merged:)

Copy link
Collaborator

@alexandruag alexandruag left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool, I think the refactoring here is def helpful while we work to wrap up the other ongoing discussions.

Copy link
Collaborator

@slp slp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks @jiangliu

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

Successfully merging this pull request may close these issues.

[virtio-queue] Split the code in multiple modules
4 participants