From: Alex Williamson <alex.williamson@redhat.com>
To: Alexander Duyck <alexander.duyck@gmail.com>
Cc: bhelgaas@google.com, alexander.h.duyck@intel.com,
linux-pci@vger.kernel.org, virtio-dev@lists.oasis-open.org,
kvm@vger.kernel.org, netdev@vger.kernel.org, dan.daly@intel.com,
linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org,
keith.busch@intel.com, netanel@amazon.com, mheyne@amazon.de,
liang-min.wang@intel.com, mark.d.rustad@intel.com,
dwmw2@infradead.org, hch@lst.de, dwmw@amazon.co.uk
Subject: Re: [pci PATCH v4 1/4] pci-iov: Add support for unmanaged SR-IOV
Date: Sun, 11 Mar 2018 21:59:09 -0600 [thread overview]
Message-ID: <20180311215909.16ed4bf1@t450s.home> (raw)
In-Reply-To: <20180308190047.5433.77952.stgit@localhost.localdomain>
On Thu, 08 Mar 2018 11:02:29 -0800
Alexander Duyck <alexander.duyck@gmail.com> wrote:
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> This patch is meant to add some basic functionality to support for SR-IOV
> on devices when the VFs are not managed by some other entity in the device
> other than the kernel.
>
> A new sysfs value called sriov_unmanaged_autoprobe has been added. This
> value is used as the drivers_autoprobe setting of the VFs when they are
> being managed by an external entity such as device firmware instead of
> being managed by the kernel.
>
> One side effect of this change is that the sriov_drivers_autoprobe and
> sriov_unmanaged_autoprobe will only apply their updates when SR-IOV VFs
> are allocated. Attempts to update them when SR-IOV is in use will only
> update the local value and will not update sriov->autoprobe.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> ---
I still struggle to understand why we need this "unmanaged"
complication and how a user of the sysfs API is expected to have any
idea whether a PF is managed or unmanaged and why they should care.
Can't we just have a pci_simple_sriov_configure() helper and ignore
this unmanaged business? Thanks,
Alex
WARNING: multiple messages have this Message-ID (diff)
From: alex.williamson@redhat.com (Alex Williamson)
Subject: [pci PATCH v4 1/4] pci-iov: Add support for unmanaged SR-IOV
Date: Sun, 11 Mar 2018 21:59:09 -0600 [thread overview]
Message-ID: <20180311215909.16ed4bf1@t450s.home> (raw)
In-Reply-To: <20180308190047.5433.77952.stgit@localhost.localdomain>
On Thu, 08 Mar 2018 11:02:29 -0800
Alexander Duyck <alexander.duyck@gmail.com> wrote:
> From: Alexander Duyck <alexander.h.duyck at intel.com>
>
> This patch is meant to add some basic functionality to support for SR-IOV
> on devices when the VFs are not managed by some other entity in the device
> other than the kernel.
>
> A new sysfs value called sriov_unmanaged_autoprobe has been added. This
> value is used as the drivers_autoprobe setting of the VFs when they are
> being managed by an external entity such as device firmware instead of
> being managed by the kernel.
>
> One side effect of this change is that the sriov_drivers_autoprobe and
> sriov_unmanaged_autoprobe will only apply their updates when SR-IOV VFs
> are allocated. Attempts to update them when SR-IOV is in use will only
> update the local value and will not update sriov->autoprobe.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck at intel.com>
> ---
I still struggle to understand why we need this "unmanaged"
complication and how a user of the sysfs API is expected to have any
idea whether a PF is managed or unmanaged and why they should care.
Can't we just have a pci_simple_sriov_configure() helper and ignore
this unmanaged business? Thanks,
Alex
next prev parent reply other threads:[~2018-03-12 3:59 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-08 19:00 [pci PATCH v4 0/4] Add support for unmanaged SR-IOV Alexander Duyck
2018-03-08 19:00 ` [virtio-dev] " Alexander Duyck
2018-03-08 19:00 ` Alexander Duyck
2018-03-08 19:02 ` [pci PATCH v4 1/4] pci-iov: " Alexander Duyck
2018-03-08 19:02 ` [virtio-dev] " Alexander Duyck
2018-03-08 19:02 ` Alexander Duyck
2018-03-12 3:59 ` Alex Williamson [this message]
2018-03-12 3:59 ` Alex Williamson
2018-03-12 7:59 ` Christoph Hellwig
2018-03-12 7:59 ` Christoph Hellwig
2018-03-12 16:01 ` Alexander Duyck
2018-03-12 16:01 ` [virtio-dev] " Alexander Duyck
2018-03-12 16:01 ` Alexander Duyck
2018-03-12 16:28 ` Alex Williamson
2018-03-12 16:28 ` Alex Williamson
2018-03-08 19:03 ` [pci PATCH v4 2/4] virtio_pci: Add support for unmanaged SR-IOV on virtio_pci devices Alexander Duyck
2018-03-08 19:03 ` [virtio-dev] " Alexander Duyck
2018-03-08 19:03 ` Alexander Duyck
2018-03-08 19:03 ` [pci PATCH v4 3/4] ena: Migrate over to "unmanaged SR-IOV" support Alexander Duyck
2018-03-08 19:03 ` [virtio-dev] " Alexander Duyck
2018-03-08 19:03 ` Alexander Duyck
2018-03-08 19:04 ` [pci PATCH v4 4/4] nvme: " Alexander Duyck
2018-03-08 19:04 ` [virtio-dev] " Alexander Duyck
2018-03-08 19:04 ` Alexander Duyck
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=20180311215909.16ed4bf1@t450s.home \
--to=alex.williamson@redhat.com \
--cc=alexander.duyck@gmail.com \
--cc=alexander.h.duyck@intel.com \
--cc=bhelgaas@google.com \
--cc=dan.daly@intel.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.