On Tue, Sep 22, 2015 at 10:21:22AM +0800, Yuanhan Liu wrote:

On Mon, Sep 21, 2015 at 12:02:20PM +0300, Michael S. Tsirkin wrote:

quoted

On Mon, Sep 21, 2015 at 10:22:52AM +0800, Yuanhan Liu wrote:

quoted

On Sun, Sep 20, 2015 at 12:37:35PM +0300, Michael S. Tsirkin wrote:

quoted

On Fri, Sep 18, 2015 at 11:10:54PM +0800, Yuanhan Liu wrote:

quoted

From: Changchun Ouyang <redacted>

This message is used to enable/disable a specific vring queue pair.
The first queue pair is enabled by default.

Signed-off-by: Changchun Ouyang <redacted>
Signed-off-by: Yuanhan Liu <redacted>
---

[snip...]

quoted

quoted

 void
 user_destroy_device(struct vhost_device_ctx ctx)
 {

It might be a good idea to flush any packets being processed
on relevant cores at this point.

They are offloaded to the application (examples/vhost/vhost-switch in
this case).

user_destroy_device will invoke the application's "destroy_device()"
callback in the end, which, in our case, will set "remove" flag. The
core worker will then drain and free the RX queue and free TX queue
once the "remove" flag is set.

	--yliu

Oh, I really meant user_set_vring_enable.

Will a per-vring callback help then?

We may prototype the callback to "vring_state_changed(dev, vring_index)"

It should be "vring_state_changed(dev, vring_index, enable)".

so that the application could either, as you suggested, flushes any packets
haven't been processed yet, or simply drops them.

After putting more thoughts on that, I guess it's also necessary to
inform the application that before receiving an "enabled" state for
a specific vring, we should never use it for data transferring, as
we just enable one queue pair by default.

And I think we could do both in vring_state_changed() callback.

Michael, what do you think of it?


	--yliu