netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Ethan Zhao <ethan.kernel@gmail.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"e1000-devel@lists.sourceforge.net"
	<e1000-devel@lists.sourceforge.net>,
	"vaughan.cao@oracle.com" <vaughan.cao@oracle.com>,
	"jesse.brandeburg@intel.com" <jesse.brandeburg@intel.com>,
	Ethan Zhao <ethan.zhao@oracle.com>,
	"linux.nics@intel.com" <linux.nics@intel.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"gleb@kernel.org" <gleb@kernel.org>,
	"bhelgaas@google.com" <bhelgaas@google.com>,
	"boris.ostrovsky@oracle.com" <boris.ostrovsky@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"bruce.w.allan@intel.com" <bruce.w.allan@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"john.ronciak@intel.com" <john.ronciak@intel.com>,
	"david.vrabel@citrix.com" <david.vrabel@citrix.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>
Subject: Re: [PATCH 1/2 V3] PCI: introduce device assignment interface and refactory related code
Date: Fri, 11 Jul 2014 09:25:10 -0600	[thread overview]
Message-ID: <1405092310.4098.90.camel@ul30vt.home> (raw)
In-Reply-To: <F2B2A07D-B9A9-4CE0-9679-50D7768ACDE6@gmail.com>

On Fri, 2014-07-11 at 23:19 +0800, Ethan Zhao wrote:
> 
> > 在 2014年7月11日,下午10:54,Alex Williamson <alex.williamson@redhat.com> 写道:
> > 
> >> On Fri, 2014-07-11 at 22:37 +0800, Ethan Zhao wrote:
> >> 
> >>>> 在 2014年7月11日,下午10:15,Alex Williamson <alex.williamson@redhat.com> 写道:
> >>>> 
> >>>>> On Fri, 2014-07-11 at 07:13 -0600, Alex Williamson wrote:
> >>>>> On Fri, 2014-07-11 at 20:30 +0800, Ethan Zhao wrote:
> >>>>> This patch introduces two new device assignment functions
> >>>>> 
> >>>>> pci_iov_assign_device(),
> >>>>> pci_iov_deassign_device()
> >>>>> 
> >>>>> along with the existed one
> >>>>> 
> >>>>> pci_vfs_assigned()
> >>>>> 
> >>>>> They construct the VFs assignment management interface, used to assign/
> >>>>> deassign device to VM and query the VFs reference counter. instead of
> >>>>> direct manipulation of device flag.
> >>>>> 
> >>>>> This patch refashioned the related code and make them atomic.
> >>>>> 
> >>>>> v3: change the naming of device assignment helpers, because they work
> >>>>> for all kind of PCI device, not only SR-IOV (david.vrabel@citrix.com)
> >>>>> 
> >>>>> v2: reorder the patchset and make it bisectable and atomic, steps clear
> >>>>> between interface defination and implemenation according to the
> >>>>> suggestion from alex.williamson@redhat.com
> >>>>> 
> >>>>> Signed-off-by: Ethan Zhao <ethan.zhao@oracle.com>
> >>>>> ---
> >>>> 
> >>>> - Use a cover patch to describe the series
> >>>> 
> >>>> - Version information goes here, below the "---", not above it
> >>>> 
> >>>> - I stand by the patch breakdown I suggested originally, there are too
> >>>> many logical changes here in patch 1.  There are easily 3 separate
> >>>> patches here.
> >>>> 
> >>>> - Renaming s/sriov/iov/ doesn't address the problem David raised.  The
> >>>> name is still synonymous with SR-IOV and it's defined on
> >>>> drivers/pci/iov.c, which is only built with CONFIG_PCI_IOV.
> >>>> 
> >>>> - PCI_DEV_FLAGS_ASSIGNED should be unused after this series, why is it
> >>>> not removed?
> >>> 
> >>> I guess it's still used, which is even worse because now we have
> >>> separate data elements, one tracking how many VFs are assigned from a PF
> >>> and another tracking each device that's assigned.  What are we actually
> >>> gaining or fixing by doing this?
> >> 
> >> Of course it is used to tracking PF/VF assigned,  what we gained are - we hide the details
> >> In assignment helpers, we wouldn't bother the users anymore and implement what inside
> >> The helpers, my initial purpose is to simplify the ugly  pci_vfs_assigned() with counter.
> >> 
> >> I don't want to push more change in one step, that would out of control to get perfect result.
> > 
> > But a counter means that we're tracking the data in two separate places,
> > which is generally a bad idea.  Cleaning up direct access to flags is
> > fine, but creating a separate counter doesn't really seem to add any
> > value.
> 
> If you are asked how many apples in your bag , you like to count them one by one and
> Give the answer ? What are you doing when you put them into the bag ?

If performance mattered, then yes, keeping a count may be advantageous.
Performance does not matter in any path where this is used.

> >>>>> drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c |   17 ++---------------
> >>>>> drivers/pci/iov.c                                  |   20 ++++++++++++++++++++
> >>>>> drivers/xen/xen-pciback/pci_stub.c                 |    4 ++--
> >>>>> include/linux/pci.h                                |    4 ++++
> >>>>> virt/kvm/assigned-dev.c                            |    2 +-
> >>>>> virt/kvm/iommu.c                                   |    4 ++--
> >>>> 
> >>>> - This patch touch 4 separate logical code areas, who do you expect to
> >>>> ack and commit it?  Split it up.
> >>>> 
> >>>>> 6 files changed, 31 insertions(+), 20 deletions(-)
> >>>>> 
> >>>>> diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
> >>>>> index 02c11a7..781040e 100644
> >>>>> --- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
> >>>>> +++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
> >>>>> @@ -693,22 +693,9 @@ complete_reset:
> >>>>> static bool i40e_vfs_are_assigned(struct i40e_pf *pf)
> >>>>> {
> >>>>>   struct pci_dev *pdev = pf->pdev;
> >>>>> -    struct pci_dev *vfdev;
> >>>>> -
> >>>>> -    /* loop through all the VFs to see if we own any that are assigned */
> >>>>> -    vfdev = pci_get_device(PCI_VENDOR_ID_INTEL, I40E_DEV_ID_VF , NULL);
> >>>>> -    while (vfdev) {
> >>>>> -        /* if we don't own it we don't care */
> >>>>> -        if (vfdev->is_virtfn && pci_physfn(vfdev) == pdev) {
> >>>>> -            /* if it is assigned we cannot release it */
> >>>>> -            if (vfdev->dev_flags & PCI_DEV_FLAGS_ASSIGNED)
> >>>>> -                return true;
> >>>>> -        }
> >>>>> 
> >>>>> -        vfdev = pci_get_device(PCI_VENDOR_ID_INTEL,
> >>>>> -                       I40E_DEV_ID_VF,
> >>>>> -                       vfdev);
> >>>>> -    }
> >>>>> +    if (pci_vfs_assigned(pdev))
> >>>>> +        return true;
> >>>>> 
> >>>>>   return false;
> >>>>> }
> >>>>> diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
> >>>>> index de7a747..090f827 100644
> >>>>> --- a/drivers/pci/iov.c
> >>>>> +++ b/drivers/pci/iov.c
> >>>>> @@ -644,6 +644,26 @@ int pci_vfs_assigned(struct pci_dev *dev)
> >>>>> EXPORT_SYMBOL_GPL(pci_vfs_assigned);
> >>>>> 
> >>>>> /**
> >>>>> + * pci_iov_assign_device - assign device to VM
> >>>>> + * @pdev: the device to be assigned.
> >>>>> + */
> >>>>> +void pci_iov_assign_device(struct pci_dev *pdev)
> >>>>> +{
> >>>>> +    pdev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED;
> >>>>> +}
> >>>>> +EXPORT_SYMBOL_GPL(pci_iov_assign_device);
> >>>>> +
> >>>>> +/**
> >>>>> + * pci_iov_deassign_device - deasign device from VM
> >>>>> + * @pdev: the device to be deassigned.
> >>>>> + */
> >>>>> +void pci_iov_deassign_device(struct pci_dev *pdev)
> >>>>> +{
> >>>>> +    pdev->dev_flags &= ~PCI_DEV_FLAGS_ASSIGNED;
> >>>>> +}
> >>>>> +EXPORT_SYMBOL_GPL(pci_iov_deassign_device);
> >>>>> +
> >>>>> +/**
> >>>>> * pci_sriov_set_totalvfs -- reduce the TotalVFs available
> >>>>> * @dev: the PCI PF device
> >>>>> * @numvfs: number that should be used for TotalVFs supported
> >>>>> diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
> >>>>> index 62fcd48..27e00d1 100644
> >>>>> --- a/drivers/xen/xen-pciback/pci_stub.c
> >>>>> +++ b/drivers/xen/xen-pciback/pci_stub.c
> >>>>> @@ -133,7 +133,7 @@ static void pcistub_device_release(struct kref *kref)
> >>>>>   xen_pcibk_config_free_dyn_fields(dev);
> >>>>>   xen_pcibk_config_free_dev(dev);
> >>>>> 
> >>>>> -    dev->dev_flags &= ~PCI_DEV_FLAGS_ASSIGNED;
> >>>>> +    pci_iov_deassign_device(dev);
> >>>>>   pci_dev_put(dev);
> >>>>> 
> >>>>>   kfree(psdev);
> >>>>> @@ -404,7 +404,7 @@ static int pcistub_init_device(struct pci_dev *dev)
> >>>>>   dev_dbg(&dev->dev, "reset device\n");
> >>>>>   xen_pcibk_reset_device(dev);
> >>>>> 
> >>>>> -    dev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED;
> >>>>> +    pci_iov_assign_device(dev);
> >>>>>   return 0;
> >>>>> 
> >>>>> config_release:
> >>>>> diff --git a/include/linux/pci.h b/include/linux/pci.h
> >>>>> index aab57b4..5ece6d6 100644
> >>>>> --- a/include/linux/pci.h
> >>>>> +++ b/include/linux/pci.h
> >>>>> @@ -1603,6 +1603,8 @@ int pci_num_vf(struct pci_dev *dev);
> >>>>> int pci_vfs_assigned(struct pci_dev *dev);
> >>>>> int pci_sriov_set_totalvfs(struct pci_dev *dev, u16 numvfs);
> >>>>> int pci_sriov_get_totalvfs(struct pci_dev *dev);
> >>>>> +void pci_iov_assign_device(struct pci_dev *dev);
> >>>>> +void pci_iov_deassign_device(struct pci_dev *dev);
> >>>>> #else
> >>>>> static inline int pci_enable_sriov(struct pci_dev *dev, int nr_virtfn)
> >>>>> { return -ENODEV; }
> >>>>> @@ -1614,6 +1616,8 @@ static inline int pci_sriov_set_totalvfs(struct pci_dev *dev, u16 numvfs)
> >>>>> { return 0; }
> >>>>> static inline int pci_sriov_get_totalvfs(struct pci_dev *dev)
> >>>>> { return 0; }
> >>>>> +static inline void pci_iov_assign_device(struct pci_dev *dev) { }
> >>>>> +static inline void pci_iov_deassign_device(struct pci_dev *dev) { }
> >>>>> #endif
> >>>>> 
> >>>>> #if defined(CONFIG_HOTPLUG_PCI) || defined(CONFIG_HOTPLUG_PCI_MODULE)
> >>>>> diff --git a/virt/kvm/assigned-dev.c b/virt/kvm/assigned-dev.c
> >>>>> index bf06577..7fac58d 100644
> >>>>> --- a/virt/kvm/assigned-dev.c
> >>>>> +++ b/virt/kvm/assigned-dev.c
> >>>>> @@ -302,7 +302,7 @@ static void kvm_free_assigned_device(struct kvm *kvm,
> >>>>>   else
> >>>>>       pci_restore_state(assigned_dev->dev);
> >>>>> 
> >>>>> -    assigned_dev->dev->dev_flags &= ~PCI_DEV_FLAGS_ASSIGNED;
> >>>>> +    pci_iov_deassign_device(assigned_dev->dev);
> >>>>> 
> >>>>>   pci_release_regions(assigned_dev->dev);
> >>>>>   pci_disable_device(assigned_dev->dev);
> >>>>> diff --git a/virt/kvm/iommu.c b/virt/kvm/iommu.c
> >>>>> index 0df7d4b..641ee73 100644
> >>>>> --- a/virt/kvm/iommu.c
> >>>>> +++ b/virt/kvm/iommu.c
> >>>>> @@ -194,7 +194,7 @@ int kvm_assign_device(struct kvm *kvm,
> >>>>>           goto out_unmap;
> >>>>>   }
> >>>>> 
> >>>>> -    pdev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED;
> >>>>> +    pci_iov_assign_device(pdev);
> >>>>> 
> >>>>>   dev_info(&pdev->dev, "kvm assign device\n");
> >>>>> 
> >>>>> @@ -220,7 +220,7 @@ int kvm_deassign_device(struct kvm *kvm,
> >>>>> 
> >>>>>   iommu_detach_device(domain, &pdev->dev);
> >>>>> 
> >>>>> -    pdev->dev_flags &= ~PCI_DEV_FLAGS_ASSIGNED;
> >>>>> +    pci_iov_deassign_device(pdev);
> >>>>> 
> >>>>>   dev_info(&pdev->dev, "kvm deassign device\n");
> > 
> > 
> > 




------------------------------------------------------------------------------
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel&#174; Ethernet, visit http://communities.intel.com/community/wired

  reply	other threads:[~2014-07-11 15:25 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-11 12:30 [PATCH 1/2 V3] PCI: introduce device assignment interface and refactory related code Ethan Zhao
2014-07-11 12:30 ` [PATCH 2/2 V3] PCI: implement VFs assignment reference counter Ethan Zhao
2014-07-11 12:42   ` Varka Bhadram
2014-07-11 12:51     ` Ethan Zhao
2014-07-11 12:56       ` Varka Bhadram
2014-07-11 13:01         ` Ethan Zhao
2014-07-11 13:13 ` [PATCH 1/2 V3] PCI: introduce device assignment interface and refactory related code Alex Williamson
2014-07-11 14:15   ` Alex Williamson
2014-07-11 14:37     ` Ethan Zhao
2014-07-11 14:54       ` Alex Williamson
2014-07-11 15:19         ` Ethan Zhao
2014-07-11 15:25           ` Alex Williamson [this message]
2014-07-11 16:06             ` Ethan Zhao
2014-07-11 16:13               ` Alex Williamson
2014-07-12  0:27                 ` Ethan Zhao
2014-07-12  0:40                 ` Ethan Zhao
2014-07-20 14:48     ` Yuval Mintz
2014-07-21  1:58       ` Alex Williamson
2014-07-21  3:17         ` Ethan Zhao
2014-07-21 13:17           ` Yuval Mintz
2014-07-21 14:01             ` Alex Williamson
2014-07-21 14:11               ` Yuval Mintz
2014-07-21 14:39                 ` Alex Williamson
2014-07-21 15:10                   ` Ethan Zhao
2014-07-21 22:41                   ` Alexander Duyck
2014-07-22  0:35                     ` Ethan Zhao
2014-07-21  3:28       ` Ethan Zhao
2014-07-11 14:20   ` Ethan Zhao
2014-07-11 14:50     ` Alex Williamson
2014-07-11 15:07       ` Ethan Zhao
2014-07-11 15:23         ` Alex Williamson
2014-07-11 16:02           ` Ethan Zhao
2014-07-21 22:29 ` Alexander Duyck
2014-07-22  0:38   ` Ethan Zhao

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=1405092310.4098.90.camel@ul30vt.home \
    --to=alex.williamson@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=bruce.w.allan@intel.com \
    --cc=david.vrabel@citrix.com \
    --cc=e1000-devel@lists.sourceforge.net \
    --cc=ethan.kernel@gmail.com \
    --cc=ethan.zhao@oracle.com \
    --cc=gleb@kernel.org \
    --cc=jesse.brandeburg@intel.com \
    --cc=john.ronciak@intel.com \
    --cc=konrad.wilk@oracle.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux.nics@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=vaughan.cao@oracle.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).