All of lore.kernel.org
 help / color / mirror / Atom feed
From: Siwei Liu <loseweigh@gmail.com>
To: Cornelia Huck <cohuck@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	si-wei liu <si-wei.liu@oracle.com>,
	Roman Kagan <rkagan@virtuozzo.com>,
	Venu Busireddy <venu.busireddy@oracle.com>,
	Marcel Apfelbaum <marcel@redhat.com>,
	virtio-dev@lists.oasis-open.org, qemu-devel@nongnu.org,
	"Samudrala, Sridhar" <sridhar.samudrala@intel.com>,
	Alexander Duyck <alexander.h.duyck@intel.com>,
	Netdev <netdev@vger.kernel.org>
Subject: Re: Re: [Qemu-devel] [PATCH v3 0/3] Use of unique identifier for pairing virtio and passthrough devices...
Date: Thu, 12 Jul 2018 02:37:03 -0700	[thread overview]
Message-ID: <CADGSJ20A=sbwQQ-_YQEVwoCXwTvosCEnD2iKa0kS6ZGvbgy4rg@mail.gmail.com> (raw)
In-Reply-To: <20180711115344.633eba9e.cohuck@redhat.com>

On Wed, Jul 11, 2018 at 2:53 AM, Cornelia Huck <cohuck@redhat.com> wrote:
> On Tue, 10 Jul 2018 17:07:37 -0700
> Siwei Liu <loseweigh@gmail.com> wrote:
>
>> On Mon, Jul 9, 2018 at 6:54 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> > On Mon, Jul 09, 2018 at 06:11:53PM -0700, si-wei liu wrote:
>> >> The plan is to enable group ID based matching in the first place rather than
>> >> match by MAC, the latter of which is fragile and problematic.
>> >
>> > It isn't all that fragile - hyperv used same for a while, so if someone
>> > posts working patches with QEMU support but before this grouping stuff,
>> > I'll happily apply them.
>>
>> I wouldn't box the solution to very limited scenario just because of
>> matching by MAC, the benefit of having generic group ID in the first
>> place is that we save the effort of maintaining legacy MAC based
>> pairing that just adds complexity anyway. Currently the VF's MAC
>> address cannot be changed by either PF or by the guest user is a
>> severe limitation due to this. The other use case is that PT device
>> than VF would generally have different MAC than the standby virtio. We
>> shouldn't limit itself to VF specific scenario from the very
>> beginning.
>
> So, this brings me to a different concern: the semantics of
> VIRTIO_NET_F_STANDBY.
>
> * The currently sole user seems to be the virtio-net Linux driver.
> * The commit messages, code comments and Documentation/ all talk about
>   matching by MAC.
> * I could not find any proposed update to the virtio spec. (If there
>   had been an older proposal with a different feature name, it is not
>   discoverable.)

No, there was no such spec patch at all when the Linux patch was
submitted, hence match by MAC is the only means to pair device due to
lack of QEMU support.

Q: Does it work?
A: Well, it works for some.
Q: Does it work well to support all scenarios?
A: No, not as it claims to.
Q: Can it do better job to support all scenarios?
A: Yes, do pairing with the failover group ID instead.
Q: Does pairing still need to be MAC based if using failover group ID?
A: It depends, it's up to the implementation to verify MAC address
depending on the need (e.g. VF failover versus PT device replacement),
though MAC matching is no longer positioned as a requirement for
pairing or grouping.

There's no such stickiness for matching by MAC defined anywhere. The
semantics of VIRTIO_NET_F_STANDBY feature are mostly a failover
concept that the standby device should be used when the primary is not
present. We now have added the group ID on QEMU. I don't see why
bothering to get rid of the limitation: it's never been exposed. No
existing users. No API/ABI defined at all.

>
> VIRTIO_NET_F_STANDBY is a host <-> guest interface. As there's no
> official spec, you can only go by the Linux implementation, and by that
> its semantics seem to be 'match by MAC', not 'match by other criteria'.
>
> How is this supposed to work in the long run?

That group ID thing should work for all OS. Not just Linux.

I will change all the references to MAC matching in my upcoming patch.
Thank you for the note.

-Siwei

WARNING: multiple messages have this Message-ID (diff)
From: Siwei Liu <loseweigh@gmail.com>
To: Cornelia Huck <cohuck@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	si-wei liu <si-wei.liu@oracle.com>,
	Roman Kagan <rkagan@virtuozzo.com>,
	Venu Busireddy <venu.busireddy@oracle.com>,
	Marcel Apfelbaum <marcel@redhat.com>,
	virtio-dev@lists.oasis-open.org, qemu-devel@nongnu.org,
	"Samudrala, Sridhar" <sridhar.samudrala@intel.com>,
	Alexander Duyck <alexander.h.duyck@intel.com>,
	Netdev <netdev@vger.kernel.org>
Subject: Re: [Qemu-devel] [virtio-dev] Re: [PATCH v3 0/3] Use of unique identifier for pairing virtio and passthrough devices...
Date: Thu, 12 Jul 2018 02:37:03 -0700	[thread overview]
Message-ID: <CADGSJ20A=sbwQQ-_YQEVwoCXwTvosCEnD2iKa0kS6ZGvbgy4rg@mail.gmail.com> (raw)
In-Reply-To: <20180711115344.633eba9e.cohuck@redhat.com>

On Wed, Jul 11, 2018 at 2:53 AM, Cornelia Huck <cohuck@redhat.com> wrote:
> On Tue, 10 Jul 2018 17:07:37 -0700
> Siwei Liu <loseweigh@gmail.com> wrote:
>
>> On Mon, Jul 9, 2018 at 6:54 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> > On Mon, Jul 09, 2018 at 06:11:53PM -0700, si-wei liu wrote:
>> >> The plan is to enable group ID based matching in the first place rather than
>> >> match by MAC, the latter of which is fragile and problematic.
>> >
>> > It isn't all that fragile - hyperv used same for a while, so if someone
>> > posts working patches with QEMU support but before this grouping stuff,
>> > I'll happily apply them.
>>
>> I wouldn't box the solution to very limited scenario just because of
>> matching by MAC, the benefit of having generic group ID in the first
>> place is that we save the effort of maintaining legacy MAC based
>> pairing that just adds complexity anyway. Currently the VF's MAC
>> address cannot be changed by either PF or by the guest user is a
>> severe limitation due to this. The other use case is that PT device
>> than VF would generally have different MAC than the standby virtio. We
>> shouldn't limit itself to VF specific scenario from the very
>> beginning.
>
> So, this brings me to a different concern: the semantics of
> VIRTIO_NET_F_STANDBY.
>
> * The currently sole user seems to be the virtio-net Linux driver.
> * The commit messages, code comments and Documentation/ all talk about
>   matching by MAC.
> * I could not find any proposed update to the virtio spec. (If there
>   had been an older proposal with a different feature name, it is not
>   discoverable.)

No, there was no such spec patch at all when the Linux patch was
submitted, hence match by MAC is the only means to pair device due to
lack of QEMU support.

Q: Does it work?
A: Well, it works for some.
Q: Does it work well to support all scenarios?
A: No, not as it claims to.
Q: Can it do better job to support all scenarios?
A: Yes, do pairing with the failover group ID instead.
Q: Does pairing still need to be MAC based if using failover group ID?
A: It depends, it's up to the implementation to verify MAC address
depending on the need (e.g. VF failover versus PT device replacement),
though MAC matching is no longer positioned as a requirement for
pairing or grouping.

There's no such stickiness for matching by MAC defined anywhere. The
semantics of VIRTIO_NET_F_STANDBY feature are mostly a failover
concept that the standby device should be used when the primary is not
present. We now have added the group ID on QEMU. I don't see why
bothering to get rid of the limitation: it's never been exposed. No
existing users. No API/ABI defined at all.

>
> VIRTIO_NET_F_STANDBY is a host <-> guest interface. As there's no
> official spec, you can only go by the Linux implementation, and by that
> its semantics seem to be 'match by MAC', not 'match by other criteria'.
>
> How is this supposed to work in the long run?

That group ID thing should work for all OS. Not just Linux.

I will change all the references to MAC matching in my upcoming patch.
Thank you for the note.

-Siwei

WARNING: multiple messages have this Message-ID (diff)
From: Siwei Liu <loseweigh@gmail.com>
To: Cornelia Huck <cohuck@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	si-wei liu <si-wei.liu@oracle.com>,
	Roman Kagan <rkagan@virtuozzo.com>,
	Venu Busireddy <venu.busireddy@oracle.com>,
	Marcel Apfelbaum <marcel@redhat.com>,
	virtio-dev@lists.oasis-open.org, qemu-devel@nongnu.org,
	"Samudrala, Sridhar" <sridhar.samudrala@intel.com>,
	Alexander Duyck <alexander.h.duyck@intel.com>,
	Netdev <netdev@vger.kernel.org>
Subject: Re: [virtio-dev] Re: [Qemu-devel] [PATCH v3 0/3] Use of unique identifier for pairing virtio and passthrough devices...
Date: Thu, 12 Jul 2018 02:37:03 -0700	[thread overview]
Message-ID: <CADGSJ20A=sbwQQ-_YQEVwoCXwTvosCEnD2iKa0kS6ZGvbgy4rg@mail.gmail.com> (raw)
In-Reply-To: <20180711115344.633eba9e.cohuck@redhat.com>

On Wed, Jul 11, 2018 at 2:53 AM, Cornelia Huck <cohuck@redhat.com> wrote:
> On Tue, 10 Jul 2018 17:07:37 -0700
> Siwei Liu <loseweigh@gmail.com> wrote:
>
>> On Mon, Jul 9, 2018 at 6:54 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> > On Mon, Jul 09, 2018 at 06:11:53PM -0700, si-wei liu wrote:
>> >> The plan is to enable group ID based matching in the first place rather than
>> >> match by MAC, the latter of which is fragile and problematic.
>> >
>> > It isn't all that fragile - hyperv used same for a while, so if someone
>> > posts working patches with QEMU support but before this grouping stuff,
>> > I'll happily apply them.
>>
>> I wouldn't box the solution to very limited scenario just because of
>> matching by MAC, the benefit of having generic group ID in the first
>> place is that we save the effort of maintaining legacy MAC based
>> pairing that just adds complexity anyway. Currently the VF's MAC
>> address cannot be changed by either PF or by the guest user is a
>> severe limitation due to this. The other use case is that PT device
>> than VF would generally have different MAC than the standby virtio. We
>> shouldn't limit itself to VF specific scenario from the very
>> beginning.
>
> So, this brings me to a different concern: the semantics of
> VIRTIO_NET_F_STANDBY.
>
> * The currently sole user seems to be the virtio-net Linux driver.
> * The commit messages, code comments and Documentation/ all talk about
>   matching by MAC.
> * I could not find any proposed update to the virtio spec. (If there
>   had been an older proposal with a different feature name, it is not
>   discoverable.)

No, there was no such spec patch at all when the Linux patch was
submitted, hence match by MAC is the only means to pair device due to
lack of QEMU support.

Q: Does it work?
A: Well, it works for some.
Q: Does it work well to support all scenarios?
A: No, not as it claims to.
Q: Can it do better job to support all scenarios?
A: Yes, do pairing with the failover group ID instead.
Q: Does pairing still need to be MAC based if using failover group ID?
A: It depends, it's up to the implementation to verify MAC address
depending on the need (e.g. VF failover versus PT device replacement),
though MAC matching is no longer positioned as a requirement for
pairing or grouping.

There's no such stickiness for matching by MAC defined anywhere. The
semantics of VIRTIO_NET_F_STANDBY feature are mostly a failover
concept that the standby device should be used when the primary is not
present. We now have added the group ID on QEMU. I don't see why
bothering to get rid of the limitation: it's never been exposed. No
existing users. No API/ABI defined at all.

>
> VIRTIO_NET_F_STANDBY is a host <-> guest interface. As there's no
> official spec, you can only go by the Linux implementation, and by that
> its semantics seem to be 'match by MAC', not 'match by other criteria'.
>
> How is this supposed to work in the long run?

That group ID thing should work for all OS. Not just Linux.

I will change all the references to MAC matching in my upcoming patch.
Thank you for the note.

-Siwei

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


  reply	other threads:[~2018-07-12  9:37 UTC|newest]

Thread overview: 106+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-29 22:19 [Qemu-devel] [PATCH v3 0/3] Use of unique identifier for pairing virtio and passthrough devices Venu Busireddy
2018-06-29 22:19 ` [virtio-dev] " Venu Busireddy
2018-06-29 22:19 ` [Qemu-devel] [PATCH v3 1/3] Add "Group Identifier" support to virtio devices Venu Busireddy
2018-06-29 22:19   ` [virtio-dev] " Venu Busireddy
2018-06-29 22:19 ` [Qemu-devel] [PATCH v3 2/3] Add "Group Identifier" support to Red Hat PCI bridge Venu Busireddy
2018-06-29 22:19   ` [virtio-dev] " Venu Busireddy
2018-07-03  3:13   ` [Qemu-devel] " Siwei Liu
2018-07-03  3:13     ` Siwei Liu
2018-06-29 22:19 ` [Qemu-devel] [PATCH v3 3/3] Add "Group Identifier" support to Red Hat PCI Express bridge Venu Busireddy
2018-06-29 22:19   ` [virtio-dev] " Venu Busireddy
2018-07-07 12:14   ` [Qemu-devel] " Marcel Apfelbaum
2018-07-07 12:14     ` Marcel Apfelbaum
2018-07-31 15:58     ` [Qemu-devel] " Venu Busireddy
2018-07-31 15:58       ` Venu Busireddy
2018-07-31 16:03       ` [Qemu-devel] " Michael S. Tsirkin
2018-07-31 16:03         ` Michael S. Tsirkin
2018-07-31 19:11         ` [Qemu-devel] " Marcel Apfelbaum
2018-07-31 19:11           ` Marcel Apfelbaum
2018-06-29 22:19 ` [Qemu-devel] [PATCH v3 virtio 1/1] Add "Group Identifier" to virtio PCI capabilities Venu Busireddy
2018-06-29 22:19   ` [virtio-dev] " Venu Busireddy
2018-07-02 16:14 ` [Qemu-devel] [PATCH v3 0/3] Use of unique identifier for pairing virtio and passthrough devices Roman Kagan
2018-07-02 21:14   ` si-wei liu
2018-07-02 21:14     ` [virtio-dev] " si-wei liu
2018-07-03  9:58     ` Roman Kagan
2018-07-03 14:28       ` Venu Busireddy
2018-07-03 14:28         ` [virtio-dev] " Venu Busireddy
2018-07-03 14:52         ` [Qemu-devel] [virtio-dev] " Cornelia Huck
2018-07-03 14:52           ` [virtio-dev] Re: [Qemu-devel] " Cornelia Huck
2018-07-03 23:31           ` [Qemu-devel] [virtio-dev] " Siwei Liu
2018-07-03 23:31             ` [virtio-dev] Re: [Qemu-devel] " Siwei Liu
2018-07-04 12:15             ` [Qemu-devel] [virtio-dev] " Cornelia Huck
2018-07-04 12:15               ` [virtio-dev] Re: [Qemu-devel] " Cornelia Huck
2018-07-06  0:49               ` [Qemu-devel] [virtio-dev] " Siwei Liu
2018-07-06  0:49                 ` [virtio-dev] Re: [Qemu-devel] " Siwei Liu
2018-07-06 13:54                 ` [Qemu-devel] [virtio-dev] " Cornelia Huck
2018-07-06 13:54                   ` [virtio-dev] Re: [Qemu-devel] " Cornelia Huck
2018-07-06 15:07                   ` [Qemu-devel] [virtio-dev] " Michael S. Tsirkin
2018-07-06 15:07                     ` [virtio-dev] Re: [Qemu-devel] " Michael S. Tsirkin
2018-07-09 16:20                     ` [Qemu-devel] [virtio-dev] " Cornelia Huck
2018-07-09 16:20                       ` [virtio-dev] Re: [Qemu-devel] " Cornelia Huck
2018-07-06 23:37                   ` [Qemu-devel] [virtio-dev] " Siwei Liu
2018-07-06 23:37                     ` [virtio-dev] Re: [Qemu-devel] " Siwei Liu
2018-07-09 16:27                     ` [Qemu-devel] [virtio-dev] " Cornelia Huck
2018-07-09 16:27                       ` [virtio-dev] Re: [Qemu-devel] " Cornelia Huck
2018-07-09 13:14                   ` [Qemu-devel] [virtio-dev] " Roman Kagan
2018-07-09 13:14                     ` [virtio-dev] Re: [Qemu-devel] " Roman Kagan
2018-07-09 16:10                     ` [Qemu-devel] [virtio-dev] " Cornelia Huck
2018-07-09 16:10                       ` [virtio-dev] Re: [Qemu-devel] " Cornelia Huck
2018-07-03 15:34         ` Roman Kagan
2018-07-03 22:27       ` si-wei liu
2018-07-03 22:27         ` [virtio-dev] " si-wei liu
2018-07-09 13:00         ` Roman Kagan
2018-07-09 18:35           ` Michael S. Tsirkin
2018-07-09 18:35             ` [virtio-dev] " Michael S. Tsirkin
2018-07-10  1:11           ` si-wei liu
2018-07-10  1:11             ` [virtio-dev] " si-wei liu
2018-07-10  1:54             ` Michael S. Tsirkin
2018-07-10  1:54               ` [virtio-dev] " Michael S. Tsirkin
2018-07-11  0:07               ` Siwei Liu
2018-07-11  0:07                 ` [virtio-dev] " Siwei Liu
2018-07-11  0:07                 ` [Qemu-devel] [virtio-dev] " Siwei Liu
2018-07-11  9:53                 ` Re: [Qemu-devel] " Cornelia Huck
2018-07-11  9:53                   ` [virtio-dev] " Cornelia Huck
2018-07-11  9:53                   ` [Qemu-devel] [virtio-dev] " Cornelia Huck
2018-07-12  9:37                   ` Siwei Liu [this message]
2018-07-12  9:37                     ` [virtio-dev] Re: [Qemu-devel] " Siwei Liu
2018-07-12  9:37                     ` [Qemu-devel] [virtio-dev] " Siwei Liu
2018-07-12 11:31                     ` Re: [Qemu-devel] " Cornelia Huck
2018-07-12 11:31                       ` [virtio-dev] " Cornelia Huck
2018-07-12 11:31                       ` [Qemu-devel] [virtio-dev] " Cornelia Huck
2018-07-12 20:52                       ` Re: [Qemu-devel] " Siwei Liu
2018-07-12 20:52                         ` [virtio-dev] " Siwei Liu
2018-07-12 20:52                         ` [Qemu-devel] [virtio-dev] " Siwei Liu
2018-07-12 21:00                         ` Re: [Qemu-devel] " Michael S. Tsirkin
2018-07-12 21:00                           ` [virtio-dev] " Michael S. Tsirkin
2018-07-12 21:00                           ` [Qemu-devel] [virtio-dev] " Michael S. Tsirkin
2018-07-12 22:19                           ` Re: [Qemu-devel] " Siwei Liu
2018-07-12 22:19                             ` [virtio-dev] " Siwei Liu
2018-07-12 22:19                             ` [Qemu-devel] [virtio-dev] " Siwei Liu
2018-07-13  1:20                             ` Re: [Qemu-devel] " Samudrala, Sridhar
2018-07-13  1:20                               ` [virtio-dev] " Samudrala, Sridhar
2018-07-13  1:20                               ` [Qemu-devel] [virtio-dev] " Samudrala, Sridhar
2018-07-13  3:28                               ` Re: [Qemu-devel] " Michael S. Tsirkin
2018-07-13  3:28                                 ` [virtio-dev] " Michael S. Tsirkin
2018-07-13  3:28                                 ` [Qemu-devel] [virtio-dev] " Michael S. Tsirkin
2018-07-13  9:15                               ` Re: [Qemu-devel] " Cornelia Huck
2018-07-13  9:15                                 ` [virtio-dev] " Cornelia Huck
2018-07-13  9:15                                 ` [Qemu-devel] [virtio-dev] " Cornelia Huck
2018-07-12 19:18                   ` Re: [Qemu-devel] " Michael S. Tsirkin
2018-07-12 19:18                     ` [virtio-dev] " Michael S. Tsirkin
2018-07-12 19:18                     ` [Qemu-devel] [virtio-dev] " Michael S. Tsirkin
2018-07-10  1:58             ` [Qemu-devel] " Michael S. Tsirkin
2018-07-10  1:58               ` [virtio-dev] " Michael S. Tsirkin
2018-07-10 18:56               ` Siwei Liu
2018-07-10 18:56                 ` [virtio-dev] " Siwei Liu
2018-07-10 18:56                 ` [Qemu-devel] [virtio-dev] " Siwei Liu
2018-07-10  2:05           ` [Qemu-devel] " Michael S. Tsirkin
2018-07-10  2:05             ` [virtio-dev] " Michael S. Tsirkin
2018-07-04  5:43       ` Michael S. Tsirkin
2018-07-04  5:43         ` [virtio-dev] " Michael S. Tsirkin
2018-07-10  2:11 ` Michael S. Tsirkin
2018-07-10  2:11   ` [virtio-dev] " Michael S. Tsirkin
2018-07-10 14:28   ` [Qemu-devel] " Venu Busireddy
2018-07-10 14:28     ` [virtio-dev] " Venu Busireddy
2018-07-12 21:01     ` [Qemu-devel] " Michael S. Tsirkin
2018-07-12 21:01       ` [virtio-dev] " Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CADGSJ20A=sbwQQ-_YQEVwoCXwTvosCEnD2iKa0kS6ZGvbgy4rg@mail.gmail.com' \
    --to=loseweigh@gmail.com \
    --cc=alexander.h.duyck@intel.com \
    --cc=cohuck@redhat.com \
    --cc=marcel@redhat.com \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    --cc=rkagan@virtuozzo.com \
    --cc=si-wei.liu@oracle.com \
    --cc=sridhar.samudrala@intel.com \
    --cc=venu.busireddy@oracle.com \
    --cc=virtio-dev@lists.oasis-open.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.