linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: Wei Yang <weiyang@linux.vnet.ibm.com>,
	gwshan@linux.vnet.ibm.com, benh@kernel.crashing.org
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH V4 5/6] powerpc/powernv: boundary the total VF BAR size instead of the individual one
Date: Fri, 2 Oct 2015 19:51:17 +1000	[thread overview]
Message-ID: <560E5395.7080601@ozlabs.ru> (raw)
In-Reply-To: <1439949704-8023-6-git-send-email-weiyang@linux.vnet.ibm.com>

On 08/19/2015 12:01 PM, Wei Yang wrote:
> Each VF could have 6 BARs at most. When the total BAR size exceeds the
> gate, after expanding it will also exhaust the M64 Window.
>
> This patch limits the boundary by checking the total VF BAR size instead of
> the individual BAR.

The gate is the biggest segment size in PE in shared mode, right? And this 
is 64MB. Also, BARs with the same number of all VFs of the same physical 
adapter will be mapper contiguously (as one huge IOV BAR), for example, 2 
VFs, 2 BARs each, mapping will look like:
VF0-BAR0, VF1-BAR0, VF0-BAR1, VF1-BAR1
but not like this:
VF0-BAR0, VF0-BAR1, VF1-BAR0, VF1-BAR1
Is this correct?



>
> Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com>
> Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
> ---
>   arch/powerpc/platforms/powernv/pci-ioda.c |   14 ++++++++------
>   1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
> index b8bc51f..4bc83b8 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -2701,7 +2701,7 @@ static void pnv_pci_ioda_fixup_iov_resources(struct pci_dev *pdev)
>   	const resource_size_t gate = phb->ioda.m64_segsize >> 2;
>   	struct resource *res;
>   	int i;
> -	resource_size_t size;
> +	resource_size_t size, total_vf_bar_sz;
>   	struct pci_dn *pdn;
>   	int mul, total_vfs;
>
> @@ -2714,6 +2714,7 @@ static void pnv_pci_ioda_fixup_iov_resources(struct pci_dev *pdev)
>
>   	total_vfs = pci_sriov_get_totalvfs(pdev);
>   	mul = phb->ioda.total_pe;
> +	total_vf_bar_sz = 0;
>
>   	for (i = 0; i < PCI_SRIOV_NUM_BARS; i++) {
>   		res = &pdev->resource[i + PCI_IOV_RESOURCES];
> @@ -2726,7 +2727,8 @@ static void pnv_pci_ioda_fixup_iov_resources(struct pci_dev *pdev)
>   			return;
>   		}
>
> -		size = pci_iov_resource_size(pdev, i + PCI_IOV_RESOURCES);
> +		total_vf_bar_sz += pci_iov_resource_size(pdev,
> +				i + PCI_IOV_RESOURCES);


Is @pdev a physical device in this context? I assume it is so 
pci_iov_resource_size() returns the entire IOV BAR size.
For example, I have a Mellanox card with 16 VFs, each has a single 32MB BAR 
so total_vf_bar_sz will be 16*32=512MB and this will exceed the @gate size 
and we end up having m64_single_mode = true. What do I miss here?


>
>   		/*
>   		 * If bigger than quarter of M64 segment size, just round up
> @@ -2740,11 +2742,11 @@ static void pnv_pci_ioda_fixup_iov_resources(struct pci_dev *pdev)
>   		 * limit the system flexibility.  This is a design decision to
>   		 * set the boundary to quarter of the M64 segment size.
>   		 */
> -		if (size > gate) {
> -			dev_info(&pdev->dev, "PowerNV: VF BAR%d: %pR IOV size "
> -				"is bigger than %lld, roundup power2\n",
> -				 i, res, gate);
> +		if (total_vf_bar_sz > gate) {
>   			mul = roundup_pow_of_two(total_vfs);
> +			dev_info(&pdev->dev,
> +				"VF BAR Total IOV size %llx > %llx, roundup to %d VFs\n",
> +				total_vf_bar_sz, gate, mul);
>   			pdn->m64_single_mode = true;
>   			break;
>   		}
>


-- 
Alexey

  reply	other threads:[~2015-10-02  9:51 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-19  2:01 [PATCH V4 0/6] Redesign SR-IOV on PowerNV Wei Yang
2015-08-19  2:01 ` [PATCH V4 1/6] powerpc/powernv: don't enable SRIOV when VF BAR has non 64bit-prefetchable BAR Wei Yang
2015-10-02  8:55   ` Alexey Kardashevskiy
2015-10-08  6:29     ` Wei Yang
2015-08-19  2:01 ` [PATCH V4 2/6] powerpc/powernv: simplify the calculation of iov resource alignment Wei Yang
2015-10-02  8:58   ` Alexey Kardashevskiy
2015-10-08  6:39     ` Wei Yang
2015-08-19  2:01 ` [PATCH V4 3/6] powerpc/powernv: use one M64 BAR in Single PE mode for one VF BAR Wei Yang
2015-08-19  2:21   ` Gavin Shan
2015-10-02  9:29   ` Alexey Kardashevskiy
2015-10-08  7:06     ` Wei Yang
2015-08-19  2:01 ` [PATCH V4 4/6] powerpc/powernv: replace the hard coded boundary with gate Wei Yang
2015-08-19  2:01 ` [PATCH V4 5/6] powerpc/powernv: boundary the total VF BAR size instead of the individual one Wei Yang
2015-10-02  9:51   ` Alexey Kardashevskiy [this message]
2015-10-08  7:13     ` Wei Yang
2015-08-19  2:01 ` [PATCH V4 6/6] powerpc/powernv: allocate sparse PE# when using M64 BAR in Single PE mode Wei Yang
2015-08-19  2:21   ` Gavin Shan
2015-10-02 10:05   ` Alexey Kardashevskiy
2015-10-08  7:19     ` Wei Yang
2015-08-26  5:11 ` [PATCH V4 0/6] Redesign SR-IOV on PowerNV Alexey Kardashevskiy
2015-08-26  8:06   ` Alexey Kardashevskiy
2015-10-02 10:07 ` Alexey Kardashevskiy
2015-10-07  2:43   ` Michael Ellerman

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=560E5395.7080601@ozlabs.ru \
    --to=aik@ozlabs.ru \
    --cc=benh@kernel.crashing.org \
    --cc=gwshan@linux.vnet.ibm.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=weiyang@linux.vnet.ibm.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).