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 43B80A0A05; Tue, 19 Jan 2021 12:15:42 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C0DCE140D38; Tue, 19 Jan 2021 12:15:41 +0100 (CET) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 5ED9C140D22 for ; Tue, 19 Jan 2021 12:15:39 +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 CB79F7F56C; Tue, 19 Jan 2021 14:15:38 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru CB79F7F56C DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1611054938; bh=5EPz4SniWZKwqFY3ATon0vRvnqwII2iirRWhuH7Wj1c=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=Boi5VbeZNY8PI4WYV2UVk7dJt/iNi4B/ytuf6CZ8ri4gvlbMvtb0IjyZMMCV4/4k8 b5bZ7oXRkJTWcSfoiSisYm+Tik2CN1pM29TDx5tgclX+CKYCRZ8XDLawfa6xNmwQpe rUb6xBzkba+BtKsTVxKjPA7S/SglmD1Idk5oc46o= To: "Xueming(Steven) Li" Cc: "dev@dpdk.org" , Slava Ovsiienko , Asaf Penso , Ajit Khaparde , Somnath Kotur , John Daley , Hyong Youb Kim , Beilei Xing , Jeff Guo , Haiyue Wang , Matan Azrad , Shahaf Shuler , NBU-Contact-Thomas Monjalon , Ferruh Yigit , Ray Kinsella , Neil Horman References: <1611040501-11666-1-git-send-email-xuemingl@nvidia.com> <1611040501-11666-7-git-send-email-xuemingl@nvidia.com> <7309bfb0-63bb-e0c6-bd0d-2258cc94ad74@oktetlabs.ru> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: Date: Tue, 19 Jan 2021 14:15:38 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 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 v5 7/9] devarg: change representor ID to bitmap 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 1/19/21 2:04 PM, Xueming(Steven) Li wrote: > >> -----Original Message----- >> From: Andrew Rybchenko >> Sent: Tuesday, January 19, 2021 4:21 PM >> To: Xueming(Steven) Li >> Cc: dev@dpdk.org; Slava Ovsiienko ; Asaf Penso >> ; Ajit Khaparde ; >> Somnath Kotur ; John Daley >> ; Hyong Youb Kim ; Beilei Xing >> ; Jeff Guo ; Haiyue Wang >> ; Matan Azrad ; Shahaf Shuler >> ; NBU-Contact-Thomas Monjalon >> ; Ferruh Yigit ; Ray Kinsella >> ; Neil Horman >> Subject: Re: [PATCH v5 7/9] devarg: change representor ID to bitmap >> >> On 1/19/21 10:14 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 was compared with devarg. >>> Since ethdev representor port didn't contain controller index and PF >>> index information, callback returned representor from other PF or >>> controller. >>> >>> This patch changes representor ID to bitmap so that the ethdev >>> representor comparer callback returns correct ethdev by comparing full >>> representor information including: controller index, PF index, >>> representor type, SF or VF index. >>> >>> Representor ID bitmap definition: >>> xxxx xxxx xxxx xxxx >>> |||| |LLL LLLL LLLL vf/sf id >>> |||| L 1:sf, 0:vf >>> ||LL pf id >>> LL controller(host) id >> >> What about PF representor case? I.e. representor for entire PF. >> >> Also it implies that controller ID 0 is the caller. I.e. >> special meaning. So, space for just 3 specific contoller left >> >> Similar for PF. In fact it is worse. E.g. PMD is bound to the second PF (PF >> number 1). If so, vf0 means the first VF of the PF itself, i.e. PF 1 VF 0. But, >> pf0vf0 should mean PF 1 VF 1. > > Agree, need to extend bits width in LTS release. See my reply to cover mail. > PF representor is not considered here, how about moving one bit from vf/sf id? > 1k SF devices should be fine for me so far. We could reserve max VF/SF number to denote PF itself. > The controller ID and PF ID is related to the context device, how device configured > and bonding state is critical for PMD to interpret the IDs. For example: > ",representor=pf1vf1" is valid for bonding device, invalid for standalone device. I guess it is mlx5 specific. IMHO, pf1vf1 makes sense even without bonding. > "c#" is meaningful for multi-host scenario, invalid for normal NIC. PMD is responsible to > encode representor ID correctly according to device configuration to make Device+ReprID > unique, because the ReprID is used in device iterator. So the user app should specify > representor syntax with necessary parts to cover device configuration, PMD should > extract required info according to device state. See cover mail reply.