On Mon, Jul 10, 2023 at 9:37 AM Eugenio Perez Martin
<epere...@redhat.com> wrote:
>
> On Mon, Jul 10, 2023 at 5:54 AM Jason Wang <jasow...@redhat.com> wrote:
> >
> > On Fri, Jul 7, 2023 at 3:12 AM Eugenio Pérez <epere...@redhat.com> wrote:
> > >
> > > Now that we have add migration blockers if the device does not support
> > > all the needed features, remove the general blocker applied to all net
> > > devices with CVQ.
> > >
> > > Signed-off-by: Eugenio Pérez <epere...@redhat.com>
> >
> > I wonder what's the difference compared if we just start cvq first in
> > vhost_net_start()?
> >
>
> That's interesting. It would complicate the for loop in
> vhost_net_start, but I think it's less complicated than
> should_start_op.
>
> It would be something like moving from:
>
> for (i = 0; i < nvhosts; i++) {
>     if (i < data_queue_pairs) {
>         peer = qemu_get_peer(ncs, i);
>     } else {
>         peer = qemu_get_peer(ncs, n->max_queue_pairs);
>     }
>
>     ...
>
>     r = vhost_net_start_one(get_vhost_net(peer), dev);
>     if (r < 0) {
>         goto err_start;
>     }
> }
>
> To:
>
> for (i = 0; i < nvhosts; i++) {
>     if (i == 0 && cvq) {
>         peer = qemu_get_peer(ncs, n->max_queue_pairs);
>     } else {
>         peer = qemu_get_peer(ncs, i - cvq);
>     }
>
>     ...
>
>     r = vhost_net_start_one(get_vhost_net(peer), dev);
>     if (r < 0) {
>         goto err_start;
>     }
> }
>
> Is this what you have in mind?
>

Friendly ping.

Thanks!


Reply via email to