From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6B1F6A04B5; Thu, 10 Sep 2020 19:22:09 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 51E841BFB4; Thu, 10 Sep 2020 19:22:08 +0200 (CEST) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id 74D301BFA2 for ; Thu, 10 Sep 2020 19:22:06 +0200 (CEST) IronPort-SDR: VsgrI+0i95LNJ+VYi4dD40nOuWrOMJ9h/ap4VT8SUcuSdg3iFp6TbsM0+wmhN9xZEs7qYPAbFR ldslsSJEuHVQ== X-IronPort-AV: E=McAfee;i="6000,8403,9740"; a="146311841" X-IronPort-AV: E=Sophos;i="5.76,413,1592895600"; d="scan'208";a="146311841" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Sep 2020 10:22:03 -0700 IronPort-SDR: jDsR+kNcflLBKdpZ0kSqpcZmnpFb+Qn129nBW1v+LSP982rHNIiv4o1M6NV8F4zynXjVy8fQFS giiEC1eW/CYQ== X-IronPort-AV: E=Sophos;i="5.76,413,1592895600"; d="scan'208";a="304951841" Received: from rmenon-desk.amr.corp.intel.com (HELO [10.166.30.253]) ([10.166.30.253]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Sep 2020 10:22:03 -0700 To: Tal Shnaiderman , Narcisa Ana Maria Vasile Cc: "dev@dpdk.org" , NBU-Contact-Thomas Monjalon , "pallavi.kadam@intel.com" , "dmitry.kozliuk@gmail.com" , "harini.ramakrishnan@microsoft.com" References: <20200825114316.10712-1-talshn@nvidia.com> <20200909232121.GB13311@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> From: "Menon, Ranjit" Message-ID: <0897c65e-a90c-e02e-e1f4-44a28993615f@intel.com> Date: Thu, 10 Sep 2020 10:21:50 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Subject: Re: [dpdk-dev] [PATCH] bus/pci: support segment value as address domain on Windows X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 9/10/2020 12:30 AM, Tal Shnaiderman wrote: >> Subject: Re: [PATCH] bus/pci: support segment value as address domain on >> Windows >> >> On Tue, Aug 25, 2020 at 02:43:16PM +0300, Tal Shnaiderman wrote: >>> Set the domain value for rte_pci_addr probing on Windows to the value >>> of the PCI segment returned by SPDRP_BUSNUMBER. >>> >>> Signed-off-by: Tal Shnaiderman >>> --- >>> drivers/bus/pci/windows/pci.c | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/drivers/bus/pci/windows/pci.c >>> b/drivers/bus/pci/windows/pci.c index 489aa7902a..a40acec609 100644 >>> --- a/drivers/bus/pci/windows/pci.c >>> +++ b/drivers/bus/pci/windows/pci.c >>> @@ -195,8 +195,8 @@ get_device_pci_address(HDEVINFO dev_info, >>> return -1; >>> } >>> >>> - addr->domain = 0; >>> - addr->bus = bus_num; >>> + addr->domain = bus_num >> 8; >>> + addr->bus = bus_num & 0xff; >>> addr->devid = dev_and_func >> 16; >>> addr->function = dev_and_func & 0xffff; >>> return 0; >>> -- >> Is this needed to avoid collision of devices with the same B:D:F? > Right, it can happen in virtualization setups when several virtual functions can have the same BDF, e.g.: > > PS > Get-NetAdapterHardwareInfo > > Name Segment Bus Device Function Slot NumaNode PcieLinkSpeed > ---- ------- --- ------ -------- ---- -------- ------------- > Ethernet 0 0 10 0 Unknown > Ethernet 4 58601 0 2 0 0 Unknown > Ethernet 5 52956 0 2 0 0 Unknown > > DPDK currently can detect either Ethernet 4 or ethernet 5 if only BDF is checked. > Unix uses the Domain value, the equivalent value for Windows is Segment. Thanks for the explanation, Tal. I had always been curious how Windows stores the PCIe segment (domain) number. On VMs hosted on Hyper-V, the VF segment numbers are always in the high 16-bit values. Is this documented somewhere, or did you find this by experimentation? ranjit m.