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 C9151A0A0A; Fri, 22 Jan 2021 09:21:23 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id ACA2D140D41; Fri, 22 Jan 2021 09:21:23 +0100 (CET) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 9353F140D29 for ; Fri, 22 Jan 2021 09:21:22 +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 2B0BE7F4E3; Fri, 22 Jan 2021 11:21:22 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 2B0BE7F4E3 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1611303682; bh=3wMBCFc9tp7FP/Ax3VHD3AglpuJg5bB7jsU7xHPLx/g=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=EQzg/M0KXl79iSsfShemSneF1GmbetcijQ2XQ/ZnKxh6m2hZmKnmkwCglxVWH9egs K8bYJIebaXpgLjTTkHRbcT+ZIS9fjV8+M7wBtsBleRKrrqJxcUx/yLAmy8pkF11u4v XGodsjhsfw7dymL2zaH42mq4/xwogZ5wv0B2aTBo= To: "Xueming(Steven) Li" Cc: "dev@dpdk.org" , Slava Ovsiienko , Asaf Penso References: <1608303356-13089-2-git-send-email-xuemingl@nvidia.com> <1611040409-11548-1-git-send-email-xuemingl@nvidia.com> <27ae1146-50a9-7a56-bce8-b93740927389@oktetlabs.ru> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: <8afffbdd-c822-bf63-8c74-a77fe78002f8@oktetlabs.ru> Date: Fri, 22 Jan 2021 11:21:21 +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 0/9] ethdev: support SubFunction representor 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 5:24 PM, Xueming(Steven) Li wrote: > >> -----Original Message----- >> From: Andrew Rybchenko >> Sent: Tuesday, January 19, 2021 4:41 PM >> To: Xueming(Steven) Li >> Cc: dev@dpdk.org; Slava Ovsiienko ; Asaf Penso >> >> Subject: Re: [dpdk-dev] [PATCH v5 0/9] ethdev: support SubFunction >> representor >> >> On 1/19/21 10:13 AM, Xueming Li wrote: >>> dedicated queues(txq, rxq). A SF netdev supports E-Switch >>> representation offload similar to existing PF and VF representors. A >>> SF shares PCI level resources with other SFs and/or with its parent PCI >> function. >>> >>> >From SmartNIC perspective, when PCI device is shared for multi-host, >>> representors for host controller and host PF is required. >>> >>> This patch set introduces new representor types in addtion to existing >>> VF representor. Syntax: >>> >>> [[c#]pf#]vf#: VF port representor/s from controller/pf >>> [[c#]pf#]sf#: SF port representor/s from controller/pf >>> #: VF representor - for backwards compatibility >>> >>> "#" is number instance, list or range, valid examples: >>> 1, [1,3,5], [0-3], [0,2-4,6] >>> >>> For backward compatibility, this patch also introduces new netdev >>> capability to indicate the capability of supportting SF representor. >> >> The patch series looks really nice. Thanks. >> >> As before, my biggest concern is making representor ID a bitmap. See my >> comments to a specific patch. >> Plus absence of defined semantics of caller function. >> Basically it is looks like it is assumed that controller #0 and PF #0 is the caller. >> However, it could be wrong. > > From devargs syntax perspective, a VF representor on PF1 could be referenced either way: > 1: ,representor=pf1vfX > 2: ,representor=vfX > 3: ,representor=pf0vfX // works but not suggested, use PF0 BDF as caller > If probe a device with PF0 BDF and locate it with PF1 BDF, the device iterator will fail, > devargs is parsed by api, EAL layer simply compare PCI BDF and then representor ID, > i.e. "c#pf#vf#". The caller device should be consistent, better to use the first device. > > Devrg ",representor=vfX" will work, representor controller ID and pf ID > default to #0, relative to caller context PF1 BDF. > > Is it good to add such suggestion/behavior on rte_eth_devargs comments? Sorry, but I disagree. Solution with vf1 and pf0vf1 making the same representor ID sounds not acceptable to me. It is definitely different things if I pass it to PF1. >> >> The next biggest concert is the absence of capability reporting API. How many >> controller are available? >> How many PFs on each controller are available? >> How many VFs on each controller/PF are available? >> How many SFs? >> >>>From the first sight it sounds not that important right now and an extra >> feature which could be added in the follow up patches, but IMHO addition of >> the API would allow to avoid making representor ID a bitmap. >> Basically capabilities API can provide an array of available functions with >> representor ID assigned to each entry. Also it could make the entire patch >> series optional since it would allow to interpret numbers in representor=[....] >> as representor IDs which are mapped to controller/PF/VF/SF by the >> capabilities reporting API. >> >> I realize that sometimes it could be more convenient to use syntax suggested >> here. Mainly for human. > > Agree, mostly for human. Regarding to capability reporting API, how about remove > current one and enhance it later with a complete patch set? > Current one? Sorry I don't understand. Andrew.