Linux Virtualization - Jun 2018 - [virtio-dev] Re: [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net

On Thu, Jun 21, 2018 at 06:07:18PM -0700, Siwei Liu
wrote:
> On Thu, Jun 21, 2018 at 11:14 AM, Michael S. Tsirkin <mst at
redhat.com> wrote:
> > On Wed, Jun 13, 2018 at 01:40:59PM +0800, Jason Wang wrote:
> >>
> >>
> >> On 2018?06?13? 12:24, Samudrala, Sridhar wrote:
> >> > On 6/12/2018 7:38 PM, Jason Wang wrote:
> >> > >
> >> > >
> >> > > On 2018?06?12? 19:54, Michael S. Tsirkin wrote:
> >> > > > On Wed, Jun 06, 2018 at 10:29:03AM +0800, Jason
Wang wrote:
> >> > > > >
> >> > > > > On 2018?06?05? 20:33, Michael S. Tsirkin
wrote:
> >> > > > > > I don't think this is sufficient.
> >> > > > > >
> >> > > > > > If both primary and standby devices are
present, a
> >> > > > > > legacy guest without
> >> > > > > > support for the feature might see two
devices with same mac and get
> >> > > > > > confused.
> >> > > > > >
> >> > > > > > I think that we should only make primary
visible after
> >> > > > > > guest acked the
> >> > > > > > backup feature bit.
> >> > > > > I think we want exactly the reverse? E.g fail
the
> >> > > > > negotiation when guest
> >> > > > > does not ack backup feature.
> >> > > > >
> >> > > > > Otherwise legacy guest won't even have the
chance to see
> >> > > > > primary device in
> >> > > > > the guest.
> >> > > > That's by design.
> >> > >
> >> > > So management needs to know the capability of guest to
set the
> >> > > backup feature. This looks a chicken or egg problem to
me.
> >> >
> >> > I don't think so. If the tenant requests 'accelerated
datapath feature',
> >> > the management
> >> > will set 'standby' feature bit on virtio-net
interface and if the guest
> >> > virtio-net driver
> >> > supports this feature, then the tenant VM will get that
capability via a
> >> > hot-plugged
> >> > primary device.
> >>
> >> Ok, I thought exactly the reverse because of the commit title is
"enable
> >> virtio_net to act as a standby for a passthru device". But
re-read the
> >> commit log content, I understand the case a little bit. Btw, VF is
not
> >> necessarily faster than virtio-net, especially consider virtio-net
may have
> >> a lot of queues.
> >
> > Don't do that then, right?
> 
> I don't understand. Where did the standby feature come to imply the
> "accelerated datapath" thing?
> Isn't failover/standby a generic high
> availblity term, rather than marry it to the concept of device model
> specifics? Do we expect scsi to work exactly the same way with
> "accelerated datapath"?
That's not what I said.
The semantics are that the primary is always used if present in
preference to standby.
Jason said virtio net is sometimes preferable.
If that's the case don't make it a standby.

More advanced use-cases do exist and e.g. Alexander Duyck
suggested using a switch-dev. failover isn't it though.

-- 
MST

On Thu, Jun 21, 2018 at 7:30 PM, Michael S. Tsirkin <mst at redhat.com>
wrote:
> On Thu, Jun 21, 2018 at 06:07:18PM -0700, Siwei Liu wrote:
>> On Thu, Jun 21, 2018 at 11:14 AM, Michael S. Tsirkin <mst at
redhat.com> wrote:
>> > On Wed, Jun 13, 2018 at 01:40:59PM +0800, Jason Wang wrote:
>> >>
>> >>
>> >> On 2018?06?13? 12:24, Samudrala, Sridhar wrote:
>> >> > On 6/12/2018 7:38 PM, Jason Wang wrote:
>> >> > >
>> >> > >
>> >> > > On 2018?06?12? 19:54, Michael S. Tsirkin wrote:
>> >> > > > On Wed, Jun 06, 2018 at 10:29:03AM +0800, Jason
Wang wrote:
>> >> > > > >
>> >> > > > > On 2018?06?05? 20:33, Michael S. Tsirkin
wrote:
>> >> > > > > > I don't think this is sufficient.
>> >> > > > > >
>> >> > > > > > If both primary and standby devices
are present, a
>> >> > > > > > legacy guest without
>> >> > > > > > support for the feature might see two
devices with same mac and get
>> >> > > > > > confused.
>> >> > > > > >
>> >> > > > > > I think that we should only make
primary visible after
>> >> > > > > > guest acked the
>> >> > > > > > backup feature bit.
>> >> > > > > I think we want exactly the reverse? E.g
fail the
>> >> > > > > negotiation when guest
>> >> > > > > does not ack backup feature.
>> >> > > > >
>> >> > > > > Otherwise legacy guest won't even have
the chance to see
>> >> > > > > primary device in
>> >> > > > > the guest.
>> >> > > > That's by design.
>> >> > >
>> >> > > So management needs to know the capability of guest
to set the
>> >> > > backup feature. This looks a chicken or egg problem
to me.
>> >> >
>> >> > I don't think so. If the tenant requests
'accelerated datapath feature',
>> >> > the management
>> >> > will set 'standby' feature bit on virtio-net
interface and if the guest
>> >> > virtio-net driver
>> >> > supports this feature, then the tenant VM will get that
capability via a
>> >> > hot-plugged
>> >> > primary device.
>> >>
>> >> Ok, I thought exactly the reverse because of the commit title
is "enable
>> >> virtio_net to act as a standby for a passthru device".
But re-read the
>> >> commit log content, I understand the case a little bit. Btw,
VF is not
>> >> necessarily faster than virtio-net, especially consider
virtio-net may have
>> >> a lot of queues.
>> >
>> > Don't do that then, right?
>>
>> I don't understand. Where did the standby feature come to imply the
>> "accelerated datapath" thing?
>> Isn't failover/standby a generic high
>> availblity term, rather than marry it to the concept of device model
>> specifics? Do we expect scsi to work exactly the same way with
>> "accelerated datapath"?
>
> That's not what I said.
> The semantics are that the primary is always used if present in
> preference to standby.
OK. If this is the only semantics of what "standby" refers to in
general, that is fine.

I just don't want to limit the failover/standby semantics to the
device model specifics, the "accelerated datapath" thing or whatever.
I really don't know where the requirements of the "accelerated
datapath" came from, as the originial problem is migrating vfio
devices which is in match of QEMU's live migration model. Hyper-V has
it's limitation to do 1-netdev should not impact how KVM/QEMU should
be doing it.
> Jason said virtio net is sometimes preferable.
> If that's the case don't make it a standby.
>
> More advanced use-cases do exist and e.g. Alexander Duyck
> suggested using a switch-dev.
The switchdev case would need a new feature bit, right?

-Siwei
> failover isn't it though.
>
> --
> MST

On Fri, Jun 22, 2018 at 12:43:26PM -0700, Siwei Liu
wrote:
> > The semantics are that the primary is always used if present in
> > preference to standby.
> OK. If this is the only semantics of what "standby" refers to in
> general, that is fine.
> 
> I just don't want to limit the failover/standby semantics to the
> device model specifics, the "accelerated datapath" thing or
whatever.
> I really don't know where the requirements of the "accelerated
> datapath" came from,
It's a way to put it that matches what failover actually provides.
> as the originial problem is migrating vfio
> devices which is in match of QEMU's live migration model.
If you put it this way then it's natural to require that we have a
config with a working vfio device, and that we somehow add virtio for
duration of migration.
> Hyper-V has
> it's limitation to do 1-netdev should not impact how KVM/QEMU should
> be doing it.
That's a linux thing and pretty orthogonal to host/guest interface.
> > Jason said virtio net is sometimes preferable.
> > If that's the case don't make it a standby.
> >
> > More advanced use-cases do exist and e.g. Alexander Duyck
> > suggested using a switch-dev.
> 
> The switchdev case would need a new feature bit, right?
> 
> -Siwei
I think it would need to be a completely new device.
> > failover isn't it though.
> >
> > --
> > MST