From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9EEF1A034F; Thu, 25 Feb 2021 08:32:31 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 10B1440692; Thu, 25 Feb 2021 08:32:31 +0100 (CET) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 121494067B for ; Thu, 25 Feb 2021 08:32:28 +0100 (CET) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 61C437F501; Thu, 25 Feb 2021 10:32:28 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 61C437F501 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1614238348; bh=04DFTPO3en3s9ImfYhX+mcft2+UKJRPxS+to7e/dH6E=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=cYmHNneezx2SAsz/reAKU/SdyYA4EdI6COEJji8hr5Y+ktoICr5GWw6GdyVs80OU2 SgLsB1Zdf6Q3G1FpZmQkxryC3ShJb4D4MOySlmkU4sX5gAHlCmqjHIMAihNsUh6gMV OXH+CpuVAIJqyM4TDAYH1RkbBtK9a5wGxhDnsad4= To: "Xueming(Steven) Li" Cc: "dev@dpdk.org" , Slava Ovsiienko , Asaf Penso , NBU-Contact-Thomas Monjalon , Ferruh Yigit , Ray Kinsella , Neil Horman References: <1613272907-22563-1-git-send-email-xuemingl@nvidia.com> <1613272907-22563-9-git-send-email-xuemingl@nvidia.com> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: <2fb8454f-0208-95e0-52d6-8f919386d132@oktetlabs.ru> Date: Thu, 25 Feb 2021 10:32:28 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v6 8/9] ethdev: representor iterator compare complete info X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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 2/16/21 7:35 PM, Xueming(Steven) Li wrote: > >> -----Original Message----- >> From: Andrew Rybchenko >> Sent: Monday, February 15, 2021 5:32 PM >> To: Xueming(Steven) Li >> Cc: dev@dpdk.org; Slava Ovsiienko ; Asaf Penso ; NBU-Contact-Thomas Monjalon >> ; Ferruh Yigit ; Ray Kinsella ; Neil Horman >> >> Subject: Re: [PATCH v6 8/9] ethdev: representor iterator compare complete info >> >> On 2/14/21 6:21 AM, Xueming Li wrote: >>> The NIC can have multiple PCIe links and can be attached to multiple >>> hosts, for example the same single NIC can be shared for multiple >>> server units in the rack. On each PCIe link NIC can provide multiple >>> PFs and VFs/SFs based on these ones. The full representor identifier >>> consists of three indices - controller index, PF index, and VF or SF index (if any). >>> >>> SR-IOV and SubFunction are created on top of PF. PF index is >>> introduced because there might be multiple PFs in the bonding >>> configuration and only bonding device is probed. >>> >>> In eth representor comparator callback, ethdev representor ID was >>> compared with devarg. Since controller index and PF index not >>> compared, callback returned representor from other PF or controller. >>> >>> This patch adds new API to convert representor controller, pf and >>> vf/sf index to representor ID. Representor comparer callback convert >>> representor info into ID and compare with device representor ID. >>> >>> Signed-off-by: Xueming Li [snip] >>> + } >>> + n = ret; >>> + size = sizeof(*info) + n * sizeof(info->ranges[0]); >>> + info = calloc(1, size); >>> + if (info == NULL) >>> + return -ENOMEM; >>> + ret = rte_eth_representor_info_get(ethdev->data->port_id, info); >>> + if (ret < 0) >>> + goto out; >>> + >>> + /* Default controller and pf to caller. */ >>> + if (controller == -1) >>> + controller = info->controller; >>> + if (pf == -1) >>> + pf = info->pf; >>> + >>> + /* Locate representor ID. */ >>> + for (i = 0; i < n; ++i) { >>> + if (info->ranges[i].type != type) >>> + continue; >>> + /* PMD hit: ignore controller if -1. */ >>> + if (info->ranges[i].controller != -1 && >>> + info->ranges[i].controller != (uint16_t)controller) >>> + continue; >> >> I think it is incorrect to ignore controller in range if controller is specified in request. It must match. > > This is a real requirement I'm facing from orchestration, before orchestration having knowledge on port > status, it always send "pf#vf#" to OVS->DPDK, although "pf#" is meaningless in standard mode. It will take > time for orchestration and OVS to evolve... PMD uses this option to decide ignore them or not. I'll take a look at it on the next version, but it still sounds wrong when something is specified, but ignored. May be I simply misunderstand. Thanks for working on the patch series.