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:
> > On Mon, Sep 21, 2015 at 10:22:52AM +0800, Yuanhan Liu wrote:
> > > On Sun, Sep 20, 2015 at 12:37:35PM +0300, Michael S. Tsirkin wrote:
> > > > On Fri, Sep 18, 2015 at 11:10:54PM +0800, Yuanhan Liu wrote:
> > > > > From: Changchun Ouyang <changchun.ouyang at intel.com>
> > > > >
> > > > > 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 <changchun.ouyang at intel.com>
> > > > > Signed-off-by: Yuanhan Liu <yuanhan.liu at linux.intel.com>
> > > > > ---
> > > [snip...]
> > > > > 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
