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 BC509A0A03; Tue, 19 Jan 2021 09:40:47 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A006B140D4E; Tue, 19 Jan 2021 09:40:47 +0100 (CET) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 28AA9140D46 for ; Tue, 19 Jan 2021 09:40:44 +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 D1ACE7F5D5; Tue, 19 Jan 2021 11:40:43 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru D1ACE7F5D5 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1611045643; bh=zIqdnP1VB2zSTVjQ7hYXnoRvZobrI8NQHBfBZ7L9bCA=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=HFuBcIjzbGgib4rX2BiOR41sGoCyMXJXiSfprl4imkN6khUxz03NewFJQiQyZpCJz InJbM0mn5R59v6+onSKfyUs0AD/LNw/sSUEK1Gvyqc5fPjJjHjb+ovUvz1MJ4bjzoG JyoJulWoT0xEhM2HI4CJC0a7KE59TIcXfG+G2heo= To: Xueming Li Cc: dev@dpdk.org, Viacheslav Ovsiienko , Asaf Penso References: <1608303356-13089-2-git-send-email-xuemingl@nvidia.com> <1611040409-11548-1-git-send-email-xuemingl@nvidia.com> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: <27ae1146-50a9-7a56-bce8-b93740927389@oktetlabs.ru> Date: Tue, 19 Jan 2021 11:40:43 +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: <1611040409-11548-1-git-send-email-xuemingl@nvidia.com> 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 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. 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.