All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Alexander Duyck <alexander.duyck@gmail.com>
Cc: "Daly, Dan" <dan.daly@intel.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	"Duyck, Alexander H" <alexander.h.duyck@intel.com>,
	linux-pci@vger.kernel.org, virtio-dev@lists.oasis-open.org,
	kvm@vger.kernel.org, Netdev <netdev@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-nvme@lists.infradead.org,
	Keith Busch <keith.busch@intel.com>,
	netanel@amazon.com, Don Dutile <ddutile@redhat.com>,
	Maximilian Heyne <mheyne@amazon.de>,
	"Wang, Liang-min" <liang-min.wang@intel.com>,
	"Rustad, Mark D" <mark.d.rustad@intel.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Christoph Hellwig <hch@lst.de>,
	dwmw@amazon.co.uk
Subject: Re: [virtio-dev] [pci PATCH v7 2/5] virtio_pci: Add support for unmanaged SR-IOV on virtio_pci devices
Date: Fri, 20 Apr 2018 18:28:50 +0300	[thread overview]
Message-ID: <20180420180839-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CAKgT0Ucpw9D1u8MYoEX5KOij6sxs-5O9gPFTmOVq=Dgt=HUJ=g@mail.gmail.com>

On Fri, Apr 20, 2018 at 07:56:14AM -0700, Alexander Duyck wrote:
> > I think for virtio it should include the feature bit, yes.
> > Adding feature bit is very easy - post a patch to the virtio TC mailing
> > list, wait about a week to give people time to respond (two weeks if it
> > is around holidays and such).
> 
> The problem is we are talking about hardware/FPGA, not software.
> Adding a feature bit means going back and updating RTL. The software
> side of things is easy, re-validating things after a hardware/FPGA
> change not so much.
> 
> If this is a hard requirement I may just drop the virtio patch, push
> what I have, and leave it to Mark/Dan to deal with the necessary RTL
> and code changes needed to support Virtio as I don't expect the
> turnaround to be as easy as just a patch.
> 
> Thanks.
> 
> - Alex

Let's focus on virtio in this thread.

Involving the virtio TC in host/guest interface changes is a
hard requirement. It's just too easy to create conflicts otherwise.

So you guys should have just sent the proposal to the TC when you
were doing your RTL and you would have been in the clear.

Generally adding a feature bit with any extension is a good idea:
this way you merely reserve a feature bit for your feature through
the TC and are more or less sure of forward and backward compatibility.
It's incredibly easy.

But maybe it's not needed here.  I am not making the decisions myself.
Not too late: post to the TC list and let's see what the response is.
Without a feature bit you are making a change affecting all future
implementations without exception so the bar is a bit higher: you need
to actually post a spec text proposal not just a patch showing how to
use the feature, and TC needs to vote on it. Voting takes a week,
review a week or two depending on change complexity.

Hope this helps,

-- 
MST

WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Alexander Duyck <alexander.duyck@gmail.com>
Cc: "Daly, Dan" <dan.daly@intel.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	"Duyck, Alexander H" <alexander.h.duyck@intel.com>,
	linux-pci@vger.kernel.org, virtio-dev@lists.oasis-open.org,
	kvm@vger.kernel.org, Netdev <netdev@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-nvme@lists.infradead.org,
	Keith Busch <keith.busch@intel.com>,
	netanel@amazon.com, Don Dutile <ddutile@redhat.com>,
	Maximilian Heyne <mheyne@amazon.de>,
	"Wang, Liang-min" <liang-min.wang@intel.com>,
	"Rustad, Mark D" <mark.d.rustad@intel.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Christoph Hellwig <hch@lst.de>,
	dwmw@amazon.co.uk
Subject: Re: [pci PATCH v7 2/5] virtio_pci: Add support for unmanaged SR-IOV on virtio_pci devices
Date: Fri, 20 Apr 2018 18:28:50 +0300	[thread overview]
Message-ID: <20180420180839-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CAKgT0Ucpw9D1u8MYoEX5KOij6sxs-5O9gPFTmOVq=Dgt=HUJ=g@mail.gmail.com>

On Fri, Apr 20, 2018 at 07:56:14AM -0700, Alexander Duyck wrote:
> > I think for virtio it should include the feature bit, yes.
> > Adding feature bit is very easy - post a patch to the virtio TC mailing
> > list, wait about a week to give people time to respond (two weeks if it
> > is around holidays and such).
> 
> The problem is we are talking about hardware/FPGA, not software.
> Adding a feature bit means going back and updating RTL. The software
> side of things is easy, re-validating things after a hardware/FPGA
> change not so much.
> 
> If this is a hard requirement I may just drop the virtio patch, push
> what I have, and leave it to Mark/Dan to deal with the necessary RTL
> and code changes needed to support Virtio as I don't expect the
> turnaround to be as easy as just a patch.
> 
> Thanks.
> 
> - Alex

Let's focus on virtio in this thread.

Involving the virtio TC in host/guest interface changes is a
hard requirement. It's just too easy to create conflicts otherwise.

So you guys should have just sent the proposal to the TC when you
were doing your RTL and you would have been in the clear.

Generally adding a feature bit with any extension is a good idea:
this way you merely reserve a feature bit for your feature through
the TC and are more or less sure of forward and backward compatibility.
It's incredibly easy.

But maybe it's not needed here.  I am not making the decisions myself.
Not too late: post to the TC list and let's see what the response is.
Without a feature bit you are making a change affecting all future
implementations without exception so the bar is a bit higher: you need
to actually post a spec text proposal not just a patch showing how to
use the feature, and TC needs to vote on it. Voting takes a week,
review a week or two depending on change complexity.

Hope this helps,

-- 
MST

WARNING: multiple messages have this Message-ID (diff)
From: mst@redhat.com (Michael S. Tsirkin)
Subject: [virtio-dev] [pci PATCH v7 2/5] virtio_pci: Add support for unmanaged SR-IOV on virtio_pci devices
Date: Fri, 20 Apr 2018 18:28:50 +0300	[thread overview]
Message-ID: <20180420180839-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CAKgT0Ucpw9D1u8MYoEX5KOij6sxs-5O9gPFTmOVq=Dgt=HUJ=g@mail.gmail.com>

On Fri, Apr 20, 2018@07:56:14AM -0700, Alexander Duyck wrote:
> > I think for virtio it should include the feature bit, yes.
> > Adding feature bit is very easy - post a patch to the virtio TC mailing
> > list, wait about a week to give people time to respond (two weeks if it
> > is around holidays and such).
> 
> The problem is we are talking about hardware/FPGA, not software.
> Adding a feature bit means going back and updating RTL. The software
> side of things is easy, re-validating things after a hardware/FPGA
> change not so much.
> 
> If this is a hard requirement I may just drop the virtio patch, push
> what I have, and leave it to Mark/Dan to deal with the necessary RTL
> and code changes needed to support Virtio as I don't expect the
> turnaround to be as easy as just a patch.
> 
> Thanks.
> 
> - Alex

Let's focus on virtio in this thread.

Involving the virtio TC in host/guest interface changes is a
hard requirement. It's just too easy to create conflicts otherwise.

So you guys should have just sent the proposal to the TC when you
were doing your RTL and you would have been in the clear.

Generally adding a feature bit with any extension is a good idea:
this way you merely reserve a feature bit for your feature through
the TC and are more or less sure of forward and backward compatibility.
It's incredibly easy.

But maybe it's not needed here.  I am not making the decisions myself.
Not too late: post to the TC list and let's see what the response is.
Without a feature bit you are making a change affecting all future
implementations without exception so the bar is a bit higher: you need
to actually post a spec text proposal not just a patch showing how to
use the feature, and TC needs to vote on it. Voting takes a week,
review a week or two depending on change complexity.

Hope this helps,

-- 
MST

WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Alexander Duyck <alexander.duyck@gmail.com>
Cc: "Daly, Dan" <dan.daly@intel.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	"Duyck, Alexander H" <alexander.h.duyck@intel.com>,
	linux-pci@vger.kernel.org, virtio-dev@lists.oasis-open.org,
	kvm@vger.kernel.org, Netdev <netdev@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-nvme@lists.infradead.org,
	Keith Busch <keith.busch@intel.com>,
	netanel@amazon.com, Don Dutile <ddutile@redhat.com>,
	Maximilian Heyne <mheyne@amazon.de>,
	"Wang, Liang-min" <liang-min.wang@intel.com>,
	"Rustad, Mark D" <mark.d.rustad@intel.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Christoph Hellwig <hch@lst.de>,
	dwmw@amazon.co.uk
Subject: Re: [virtio-dev] [pci PATCH v7 2/5] virtio_pci: Add support for unmanaged SR-IOV on virtio_pci devices
Date: Fri, 20 Apr 2018 18:28:50 +0300	[thread overview]
Message-ID: <20180420180839-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CAKgT0Ucpw9D1u8MYoEX5KOij6sxs-5O9gPFTmOVq=Dgt=HUJ=g@mail.gmail.com>

On Fri, Apr 20, 2018 at 07:56:14AM -0700, Alexander Duyck wrote:
> > I think for virtio it should include the feature bit, yes.
> > Adding feature bit is very easy - post a patch to the virtio TC mailing
> > list, wait about a week to give people time to respond (two weeks if it
> > is around holidays and such).
> 
> The problem is we are talking about hardware/FPGA, not software.
> Adding a feature bit means going back and updating RTL. The software
> side of things is easy, re-validating things after a hardware/FPGA
> change not so much.
> 
> If this is a hard requirement I may just drop the virtio patch, push
> what I have, and leave it to Mark/Dan to deal with the necessary RTL
> and code changes needed to support Virtio as I don't expect the
> turnaround to be as easy as just a patch.
> 
> Thanks.
> 
> - Alex

Let's focus on virtio in this thread.

Involving the virtio TC in host/guest interface changes is a
hard requirement. It's just too easy to create conflicts otherwise.

So you guys should have just sent the proposal to the TC when you
were doing your RTL and you would have been in the clear.

Generally adding a feature bit with any extension is a good idea:
this way you merely reserve a feature bit for your feature through
the TC and are more or less sure of forward and backward compatibility.
It's incredibly easy.

But maybe it's not needed here.  I am not making the decisions myself.
Not too late: post to the TC list and let's see what the response is.
Without a feature bit you are making a change affecting all future
implementations without exception so the bar is a bit higher: you need
to actually post a spec text proposal not just a patch showing how to
use the feature, and TC needs to vote on it. Voting takes a week,
review a week or two depending on change complexity.

Hope this helps,

-- 
MST

---------------------------------------------------------------------
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-04-20 15:28 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-15 18:40 [pci PATCH v7 0/5] Add support for unmanaged SR-IOV Alexander Duyck
2018-03-15 18:40 ` [virtio-dev] " Alexander Duyck
2018-03-15 18:40 ` Alexander Duyck
2018-03-15 18:41 ` [pci PATCH v7 1/5] pci: Add pci_sriov_configure_simple for PFs that don't manage VF resources Alexander Duyck
2018-03-15 18:41   ` [virtio-dev] " Alexander Duyck
2018-03-15 18:41   ` Alexander Duyck
2018-03-28 21:30   ` [virtio-dev] " Rustad, Mark D
2018-03-28 21:30     ` Rustad, Mark D
2018-03-28 21:30     ` Rustad, Mark D
2018-03-15 18:42 ` [pci PATCH v7 2/5] virtio_pci: Add support for unmanaged SR-IOV on virtio_pci devices Alexander Duyck
2018-03-15 18:42   ` [virtio-dev] " Alexander Duyck
2018-03-15 18:42   ` Alexander Duyck
2018-03-16 16:34   ` [virtio-dev] " Michael S. Tsirkin
2018-03-16 16:34     ` Michael S. Tsirkin
2018-03-16 16:34     ` Michael S. Tsirkin
2018-03-16 16:40     ` Alexander Duyck
2018-03-16 16:40       ` Alexander Duyck
2018-03-16 16:40       ` Alexander Duyck
2018-04-03 13:12       ` Michael S. Tsirkin
2018-04-03 13:12         ` Michael S. Tsirkin
2018-04-03 13:12         ` Michael S. Tsirkin
2018-04-03 17:32         ` Alexander Duyck
2018-04-03 17:32           ` Alexander Duyck
2018-04-03 17:32           ` Alexander Duyck
2018-04-03 17:32           ` Alexander Duyck
2018-04-03 18:27           ` [virtio-dev] " Michael S. Tsirkin
2018-04-03 18:27             ` Michael S. Tsirkin
2018-04-03 18:27             ` Michael S. Tsirkin
2018-04-03 19:06             ` Alexander Duyck
2018-04-03 19:06               ` Alexander Duyck
2018-04-03 19:06               ` Alexander Duyck
2018-04-20  0:40               ` Michael S. Tsirkin
2018-04-20  0:40                 ` Michael S. Tsirkin
2018-04-20  0:40                 ` Michael S. Tsirkin
2018-04-20  0:40                 ` Michael S. Tsirkin
2018-04-20 14:56                 ` [virtio-dev] " Alexander Duyck
2018-04-20 14:56                   ` Alexander Duyck
2018-04-20 14:56                   ` Alexander Duyck
2018-04-20 15:28                   ` Michael S. Tsirkin [this message]
2018-04-20 15:28                     ` Michael S. Tsirkin
2018-04-20 15:28                     ` Michael S. Tsirkin
2018-04-20 15:28                     ` Michael S. Tsirkin
2018-04-20 16:08                     ` [virtio-dev] " Alexander Duyck
2018-04-20 16:08                       ` Alexander Duyck
2018-04-20 16:08                       ` Alexander Duyck
2018-04-20 16:14                       ` Michael S. Tsirkin
2018-04-20 16:14                         ` Michael S. Tsirkin
2018-04-20 16:14                         ` Michael S. Tsirkin
2018-04-21  7:05                     ` Christoph Hellwig
2018-04-21  7:05                       ` Christoph Hellwig
2018-04-03 19:18             ` Rustad, Mark D
2018-04-03 19:18               ` Rustad, Mark D
2018-04-03 19:18               ` Rustad, Mark D
2018-03-28 21:31   ` Rustad, Mark D
2018-03-28 21:31     ` [virtio-dev] " Rustad, Mark D
2018-03-28 21:31     ` Rustad, Mark D
2018-03-28 21:31     ` Rustad, Mark D
2018-04-03 13:11   ` [virtio-dev] " Michael S. Tsirkin
2018-04-03 13:11     ` Michael S. Tsirkin
2018-04-03 13:11     ` Michael S. Tsirkin
2018-04-03 13:11     ` Michael S. Tsirkin
2018-03-15 18:43 ` [pci PATCH v7 3/5] ena: Migrate over to unmanaged SR-IOV support Alexander Duyck
2018-03-15 18:43   ` [virtio-dev] " Alexander Duyck
2018-03-15 18:43   ` Alexander Duyck
2018-03-15 18:43 ` [pci PATCH v7 4/5] nvme: " Alexander Duyck
2018-03-15 18:43   ` [virtio-dev] " Alexander Duyck
2018-03-15 18:43   ` Alexander Duyck
2018-03-15 18:44 ` [pci PATCH v7 5/5] pci-pf-stub: Add PF driver stub for PFs that function only to enable VFs Alexander Duyck
2018-03-15 18:44   ` [virtio-dev] " Alexander Duyck
2018-03-15 18:44   ` Alexander Duyck
2018-03-16 21:42 ` [pci PATCH v7 0/5] Add support for unmanaged SR-IOV Don Dutile
2018-03-16 21:42   ` Don Dutile
2018-04-19 22:54 ` Alexander Duyck
2018-04-19 22:54   ` [virtio-dev] " Alexander Duyck
2018-04-19 22:54   ` Alexander Duyck
2018-04-20  0:46   ` Michael S. Tsirkin
2018-04-20  0:46     ` [virtio-dev] " Michael S. Tsirkin
2018-04-20  0:46     ` 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=20180420180839-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=alexander.duyck@gmail.com \
    --cc=alexander.h.duyck@intel.com \
    --cc=bhelgaas@google.com \
    --cc=dan.daly@intel.com \
    --cc=ddutile@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=dwmw@amazon.co.uk \
    --cc=hch@lst.de \
    --cc=keith.busch@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=liang-min.wang@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mark.d.rustad@intel.com \
    --cc=mheyne@amazon.de \
    --cc=netanel@amazon.com \
    --cc=netdev@vger.kernel.org \
    --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.