DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@amd.com>
To: Stephen Hemminger <stephen@networkplumber.org>,
	Michael Piszczek <mpiszczek@ddn.com>
Cc: dev@dpdk.org, Vipin.Varghese@amd.com
Subject: Re: [PATCH v5] pci: read amd iommu virtual address width
Date: Tue, 25 Oct 2022 08:56:49 +0100	[thread overview]
Message-ID: <67ed7c7a-ec77-98d6-3ec6-351c1fde75d1@amd.com> (raw)
In-Reply-To: <20221024110927.5ad71ed1@shemminger-XPS-13-9360>

On 10/24/2022 7:09 PM, Stephen Hemminger wrote:
> On Thu, 13 Oct 2022 20:16:02 +0200
> Michael Piszczek <mpiszczek@ddn.com> wrote:
> 
>> Add code to read the virtual address width for AMD processors.
>> Updated pci_device_iommu_support_va() to use glob to find iommu
>> capability files.
>>
>> Signed-off-by: Michael Piszczek <mpiszczek@ddn.com>
>> ---
>>   drivers/bus/pci/linux/pci.c | 58 ++++++++++++++++++++++---------------
>>   1 file changed, 35 insertions(+), 23 deletions(-)
>>
>> diff --git a/drivers/bus/pci/linux/pci.c b/drivers/bus/pci/linux/pci.c
>> index ebd1395502..291090ba7b 100644
>> --- a/drivers/bus/pci/linux/pci.c
>> +++ b/drivers/bus/pci/linux/pci.c
>> @@ -4,6 +4,7 @@
>>   
>>   #include <string.h>
>>   #include <dirent.h>
>> +#include <glob.h>
>>   
>>   #include <rte_log.h>
>>   #include <rte_pci.h>
>> @@ -480,42 +481,53 @@ rte_pci_scan(void)
>>   }
>>   
>>   #if defined(RTE_ARCH_X86)
>> +
>>   bool
>>   pci_device_iommu_support_va(const struct rte_pci_device *dev)
>>   {
>> -#define VTD_CAP_MGAW_SHIFT	16
>> -#define VTD_CAP_MGAW_MASK	(0x3fULL << VTD_CAP_MGAW_SHIFT)
>> +#define VTD_CAP_MGAW_SHIFT      16
>> +#define VTD_CAP_MGAW_MASK       (0x3fULL << VTD_CAP_MGAW_SHIFT)
>> +#define RD_AMD_CAP_VASIZE_SHIFT 15
>> +#define RD_AMD_CAP_VASIZE_MASK  (0x7F << RD_AMD_CAP_VASIZE_SHIFT)
>> +	int rc;
>>   	const struct rte_pci_addr *addr = &dev->addr;
>> -	char filename[PATH_MAX];
>> -	FILE *fp;
>> -	uint64_t mgaw, vtd_cap_reg = 0;
>> +	char pattern[PATH_MAX];
>> +	glob_t glob_results;
>> +	uint64_t mgaw = 0;
>>   
>> -	snprintf(filename, sizeof(filename),
>> -		 "%s/" PCI_PRI_FMT "/iommu/intel-iommu/cap",
>> +	snprintf(pattern, sizeof(pattern),
>> +		 "%s/" PCI_PRI_FMT "/iommu/*-iommu/cap",
>>   		 rte_pci_get_sysfs_path(), addr->domain, addr->bus, addr->devid,
>>   		 addr->function);
>>   
>> -	fp = fopen(filename, "r");
>> -	if (fp == NULL) {
>> -		/* We don't have an Intel IOMMU, assume VA supported */
>> -		if (errno == ENOENT)
>> -			return true;
>> +	rc = glob(pattern, 0, NULL, &glob_results);
>> +	if (rc != 0 && glob_results.gl_pathc == 1) {
>> +		const char *filename = glob_results.gl_pathv[0];
> 
> Why not use fnmatch() instead of glob()?
> Most of the places in DPDK use that to do this kind of matching.

Since glob() returns matching string, it can be useful to open the file.
Is there an advantage of fnmatch() against globe()?


  reply	other threads:[~2022-10-25  7:56 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-12 16:01 [PATCH 0/1] " Michael Piszczek
2022-09-12 16:01 ` [PATCH 1/1] " Michael Piszczek
2022-09-14 13:49   ` [PATCH v2] " Michael Piszczek
2022-10-03  7:48     ` David Marchand
2022-10-10 13:12       ` Varghese, Vipin
2022-10-10 21:47   ` [PATCH v3] " Michael Piszczek
2022-10-10 21:47     ` Michael Piszczek
2022-10-11 22:00     ` Ferruh Yigit
2022-10-11 14:08   ` [PATCH v4] " Michael Piszczek
2022-10-11 14:08     ` Michael Piszczek
2022-10-12  9:18     ` Ferruh Yigit
2022-10-12 15:15     ` Stephen Hemminger
2022-10-13 18:16   ` [PATCH v5] " Michael Piszczek
2022-10-13 18:16     ` Michael Piszczek
2022-10-24 18:09       ` Stephen Hemminger
2022-10-25  7:56         ` Ferruh Yigit [this message]
2022-10-17 15:45   ` [PATCH v6] " Michael Piszczek
2022-10-17 15:45     ` Michael Piszczek
2022-10-25 11:54       ` David Marchand
2023-08-08  7:31         ` David Marchand
2023-08-08 13:53           ` Michael Piszczek

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=67ed7c7a-ec77-98d6-3ec6-351c1fde75d1@amd.com \
    --to=ferruh.yigit@amd.com \
    --cc=Vipin.Varghese@amd.com \
    --cc=dev@dpdk.org \
    --cc=mpiszczek@ddn.com \
    --cc=stephen@networkplumber.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 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).