From mboxrd@z Thu Jan 1 00:00:00 1970 From: Siwei Liu Subject: Re: Re: [Qemu-devel] [PATCH v3 0/3] Use of unique identifier for pairing virtio and passthrough devices... Date: Thu, 12 Jul 2018 13:52:53 -0700 Message-ID: References: <20180629221907.3662-1-venu.busireddy@oracle.com> <20180702161404.GA2339@rkaganb.sw.ru> <449f1449-ddf6-cd95-976c-14d04d8d503a@oracle.com> <20180703095825.GC30904@rkaganb.sw.ru> <20180709130035.GA6271@rkaganb.sw.ru> <9136094e-a510-4201-7c71-d1c49226fa5f@oracle.com> <20180710045101-mutt-send-email-mst@kernel.org> <20180711115344.633eba9e.cohuck@redhat.com> <20180712133121.3b5f2bae.cohuck@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: "Michael S. Tsirkin" , si-wei liu , Roman Kagan , Venu Busireddy , Marcel Apfelbaum , virtio-dev@lists.oasis-open.org, qemu-devel@nongnu.org, "Samudrala, Sridhar" , Alexander Duyck , Netdev To: Cornelia Huck Return-path: Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: In-Reply-To: <20180712133121.3b5f2bae.cohuck@redhat.com> List-Id: netdev.vger.kernel.org _ On Thu, Jul 12, 2018 at 4:31 AM, Cornelia Huck wrote: > On Thu, 12 Jul 2018 02:37:03 -0700 > Siwei Liu wrote: > >> On Wed, Jul 11, 2018 at 2:53 AM, Cornelia Huck wrote: >> > On Tue, 10 Jul 2018 17:07:37 -0700 >> > Siwei Liu wrote: >> > >> >> On Mon, Jul 9, 2018 at 6:54 PM, Michael S. Tsirkin 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. > > We need to know what the device offers if it offers the feature bit, > and what it is supposed to do when the driver negotiates it. Currently, > we can only go by what the Linux driver does and what it expects. IOW, > we need a spec update proposal. Obviously, this should be discussed in > conjunction with the rest. The definition is incomplete due to lack of spec. There's no "host" part defined yet in the host-guest interface. If match by MAC is an interface, the same must be done on the host(device) side as well, which has been agreed not the way to go. However, I don't think that's what the author intends to do by interpreting his QEMU patch - it missed the other parts as well, such as the feature negotiation and how it interacts with the paired device. What I said is that match by MAC is just a guest implementation that one can change at any time. We now have the group ID on QEMU, why still sticking to matching by MAC? It shoulnd't be a host-guest interface in the first place anyway. > >> >> 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. > > Whether matching by MAC is good or sufficient is a different > discussion. It is, however, what the code currently *does*, and in > absence of a spec update, it is the only reference for this feature. Not really, it's the same discussion. Before the group ID discussion I explicitly asked for the spec for VIRTIO_NET_F_STANDBY about the semantics. Since no one come up with a spec, I assumed it is still being worked on and it was all right to have the initial Linux implementation to be in. I assume that is a formal process while working on a complicated feature the spec can come later once everything becomes clear along with the discussions. https://www.spinics.net/lists/netdev/msg499011.html I made the same claim at the time that we shouldn't go with what's been implemented in Linux, but instead should look at the entire picture to decide what should be the right semantics for VIRTIO_NET_F_STANDBY. I agree with you we need a spec. I can work on a spec but I'd like to clarify that there was nothing defined yet for VIRTIO_NET_F_STANDBY so it shouldn't be called as spec update. It's still a work-in-progress feature that IMHO it's different than the situation that there used to be pre-spec virtio implementation already working on both host and guest side. The current VIRTIO_NET_F_STANDBY implementation in Linux is pretty much dead code without a spec followed by a host/device side implementation. -Siwei > >> >> 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. > > This is scheduled to be released with the next Linux version, which is > right now in the -rc phase. It *is* API (a guest <-> host API). > > No corresponding code is present in QEMU 3.0, which is in freeze right > now. Anything that goes into QEMU 3.1 or later needs to accommodate > Linux 4.18 as a guest. > >> >> > >> > 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. > > That's exactly my point: We need to care about not-Linux. And about > not-QEMU as well. A virtio feature bit should not be defined by what > Linux and QEMU do, but needs a real spec. > > So, currently we have a Linux driver implementation that matches by > MAC. If a Linux version with this is released, every device that offers > VIRTIO_NET_F_STANDBY needs to support matching by MAC so that this > Linux driver will not break. Adding further matching methods should be > fine, but might need additional features (needs to be discussed). From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38336) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fdia9-0006Ou-1Z for qemu-devel@nongnu.org; Thu, 12 Jul 2018 16:52:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fdia7-0000Pm-Be for qemu-devel@nongnu.org; Thu, 12 Jul 2018 16:52:57 -0400 Received: from mail-it0-x243.google.com ([2607:f8b0:4001:c0b::243]:38840) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fdia7-0000Nv-2b for qemu-devel@nongnu.org; Thu, 12 Jul 2018 16:52:55 -0400 Received: by mail-it0-x243.google.com with SMTP id v71-v6so8666528itb.3 for ; Thu, 12 Jul 2018 13:52:54 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20180712133121.3b5f2bae.cohuck@redhat.com> References: <20180629221907.3662-1-venu.busireddy@oracle.com> <20180702161404.GA2339@rkaganb.sw.ru> <449f1449-ddf6-cd95-976c-14d04d8d503a@oracle.com> <20180703095825.GC30904@rkaganb.sw.ru> <20180709130035.GA6271@rkaganb.sw.ru> <9136094e-a510-4201-7c71-d1c49226fa5f@oracle.com> <20180710045101-mutt-send-email-mst@kernel.org> <20180711115344.633eba9e.cohuck@redhat.com> <20180712133121.3b5f2bae.cohuck@redhat.com> From: Siwei Liu Date: Thu, 12 Jul 2018 13:52:53 -0700 Message-ID: Content-Type: text/plain; charset="UTF-8" Subject: Re: [Qemu-devel] [virtio-dev] Re: [PATCH v3 0/3] Use of unique identifier for pairing virtio and passthrough devices... List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cornelia Huck Cc: "Michael S. Tsirkin" , si-wei liu , Roman Kagan , Venu Busireddy , Marcel Apfelbaum , virtio-dev@lists.oasis-open.org, qemu-devel@nongnu.org, "Samudrala, Sridhar" , Alexander Duyck , Netdev _ On Thu, Jul 12, 2018 at 4:31 AM, Cornelia Huck wrote: > On Thu, 12 Jul 2018 02:37:03 -0700 > Siwei Liu wrote: > >> On Wed, Jul 11, 2018 at 2:53 AM, Cornelia Huck wrote: >> > On Tue, 10 Jul 2018 17:07:37 -0700 >> > Siwei Liu wrote: >> > >> >> On Mon, Jul 9, 2018 at 6:54 PM, Michael S. Tsirkin 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. > > We need to know what the device offers if it offers the feature bit, > and what it is supposed to do when the driver negotiates it. Currently, > we can only go by what the Linux driver does and what it expects. IOW, > we need a spec update proposal. Obviously, this should be discussed in > conjunction with the rest. The definition is incomplete due to lack of spec. There's no "host" part defined yet in the host-guest interface. If match by MAC is an interface, the same must be done on the host(device) side as well, which has been agreed not the way to go. However, I don't think that's what the author intends to do by interpreting his QEMU patch - it missed the other parts as well, such as the feature negotiation and how it interacts with the paired device. What I said is that match by MAC is just a guest implementation that one can change at any time. We now have the group ID on QEMU, why still sticking to matching by MAC? It shoulnd't be a host-guest interface in the first place anyway. > >> >> 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. > > Whether matching by MAC is good or sufficient is a different > discussion. It is, however, what the code currently *does*, and in > absence of a spec update, it is the only reference for this feature. Not really, it's the same discussion. Before the group ID discussion I explicitly asked for the spec for VIRTIO_NET_F_STANDBY about the semantics. Since no one come up with a spec, I assumed it is still being worked on and it was all right to have the initial Linux implementation to be in. I assume that is a formal process while working on a complicated feature the spec can come later once everything becomes clear along with the discussions. https://www.spinics.net/lists/netdev/msg499011.html I made the same claim at the time that we shouldn't go with what's been implemented in Linux, but instead should look at the entire picture to decide what should be the right semantics for VIRTIO_NET_F_STANDBY. I agree with you we need a spec. I can work on a spec but I'd like to clarify that there was nothing defined yet for VIRTIO_NET_F_STANDBY so it shouldn't be called as spec update. It's still a work-in-progress feature that IMHO it's different than the situation that there used to be pre-spec virtio implementation already working on both host and guest side. The current VIRTIO_NET_F_STANDBY implementation in Linux is pretty much dead code without a spec followed by a host/device side implementation. -Siwei > >> >> 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. > > This is scheduled to be released with the next Linux version, which is > right now in the -rc phase. It *is* API (a guest <-> host API). > > No corresponding code is present in QEMU 3.0, which is in freeze right > now. Anything that goes into QEMU 3.1 or later needs to accommodate > Linux 4.18 as a guest. > >> >> > >> > 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. > > That's exactly my point: We need to care about not-Linux. And about > not-QEMU as well. A virtio feature bit should not be defined by what > Linux and QEMU do, but needs a real spec. > > So, currently we have a Linux driver implementation that matches by > MAC. If a Linux version with this is released, every device that offers > VIRTIO_NET_F_STANDBY needs to support matching by MAC so that this > Linux driver will not break. Adding further matching methods should be > fine, but might need additional features (needs to be discussed). From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-4695-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 19B1D984416 for ; Thu, 12 Jul 2018 20:52:56 +0000 (UTC) MIME-Version: 1.0 In-Reply-To: <20180712133121.3b5f2bae.cohuck@redhat.com> References: <20180629221907.3662-1-venu.busireddy@oracle.com> <20180702161404.GA2339@rkaganb.sw.ru> <449f1449-ddf6-cd95-976c-14d04d8d503a@oracle.com> <20180703095825.GC30904@rkaganb.sw.ru> <20180709130035.GA6271@rkaganb.sw.ru> <9136094e-a510-4201-7c71-d1c49226fa5f@oracle.com> <20180710045101-mutt-send-email-mst@kernel.org> <20180711115344.633eba9e.cohuck@redhat.com> <20180712133121.3b5f2bae.cohuck@redhat.com> From: Siwei Liu Date: Thu, 12 Jul 2018 13:52:53 -0700 Message-ID: Content-Type: text/plain; charset="UTF-8" Subject: Re: [virtio-dev] Re: [Qemu-devel] [PATCH v3 0/3] Use of unique identifier for pairing virtio and passthrough devices... To: Cornelia Huck Cc: "Michael S. Tsirkin" , si-wei liu , Roman Kagan , Venu Busireddy , Marcel Apfelbaum , virtio-dev@lists.oasis-open.org, qemu-devel@nongnu.org, "Samudrala, Sridhar" , Alexander Duyck , Netdev List-ID: _ On Thu, Jul 12, 2018 at 4:31 AM, Cornelia Huck wrote: > On Thu, 12 Jul 2018 02:37:03 -0700 > Siwei Liu wrote: > >> On Wed, Jul 11, 2018 at 2:53 AM, Cornelia Huck wrote: >> > On Tue, 10 Jul 2018 17:07:37 -0700 >> > Siwei Liu wrote: >> > >> >> On Mon, Jul 9, 2018 at 6:54 PM, Michael S. Tsirkin 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. > > We need to know what the device offers if it offers the feature bit, > and what it is supposed to do when the driver negotiates it. Currently, > we can only go by what the Linux driver does and what it expects. IOW, > we need a spec update proposal. Obviously, this should be discussed in > conjunction with the rest. The definition is incomplete due to lack of spec. There's no "host" part defined yet in the host-guest interface. If match by MAC is an interface, the same must be done on the host(device) side as well, which has been agreed not the way to go. However, I don't think that's what the author intends to do by interpreting his QEMU patch - it missed the other parts as well, such as the feature negotiation and how it interacts with the paired device. What I said is that match by MAC is just a guest implementation that one can change at any time. We now have the group ID on QEMU, why still sticking to matching by MAC? It shoulnd't be a host-guest interface in the first place anyway. > >> >> 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. > > Whether matching by MAC is good or sufficient is a different > discussion. It is, however, what the code currently *does*, and in > absence of a spec update, it is the only reference for this feature. Not really, it's the same discussion. Before the group ID discussion I explicitly asked for the spec for VIRTIO_NET_F_STANDBY about the semantics. Since no one come up with a spec, I assumed it is still being worked on and it was all right to have the initial Linux implementation to be in. I assume that is a formal process while working on a complicated feature the spec can come later once everything becomes clear along with the discussions. https://www.spinics.net/lists/netdev/msg499011.html I made the same claim at the time that we shouldn't go with what's been implemented in Linux, but instead should look at the entire picture to decide what should be the right semantics for VIRTIO_NET_F_STANDBY. I agree with you we need a spec. I can work on a spec but I'd like to clarify that there was nothing defined yet for VIRTIO_NET_F_STANDBY so it shouldn't be called as spec update. It's still a work-in-progress feature that IMHO it's different than the situation that there used to be pre-spec virtio implementation already working on both host and guest side. The current VIRTIO_NET_F_STANDBY implementation in Linux is pretty much dead code without a spec followed by a host/device side implementation. -Siwei > >> >> 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. > > This is scheduled to be released with the next Linux version, which is > right now in the -rc phase. It *is* API (a guest <-> host API). > > No corresponding code is present in QEMU 3.0, which is in freeze right > now. Anything that goes into QEMU 3.1 or later needs to accommodate > Linux 4.18 as a guest. > >> >> > >> > 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. > > That's exactly my point: We need to care about not-Linux. And about > not-QEMU as well. A virtio feature bit should not be defined by what > Linux and QEMU do, but needs a real spec. > > So, currently we have a Linux driver implementation that matches by > MAC. If a Linux version with this is released, every device that offers > VIRTIO_NET_F_STANDBY needs to support matching by MAC so that this > Linux driver will not break. Adding further matching methods should be > fine, but might need additional features (needs to be discussed). --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org