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 B89ECA09FF; Wed, 30 Dec 2020 12:07:37 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 612732B8E; Wed, 30 Dec 2020 12:07:35 +0100 (CET) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by dpdk.org (Postfix) with ESMTP id 613DA2B83 for ; Wed, 30 Dec 2020 12:07:33 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 924F5B70; Wed, 30 Dec 2020 06:07:30 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 30 Dec 2020 06:07:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm3; bh= LQDYO32m1oDrdQVzRy71/yvfb4HvmD7XIau+7tKkJ9I=; b=ONSaL/Hxe/ncBVgM FeZ3OnZMNSZk7M9uJCjtp8k4OnvRUVmeXgUkhNTxYupWx2D1AzSVJ4cXI8nM6nX8 cV2p6RjebPKT+JS3Gg7Uzcxuv7rgC1mdM/BahPXZJoEl9zAfYILRo3kQ7RPseooj 36LpHgVpyBaYNKIWxm4vGiLcos4dd3RToXmeVvw9MGBzhl76/fs5XorajQ9znyvB upKb3MalkH/GacBaRzULFVl3iJts7mNApVAqRet7M5ZsQwqLDiCZZzbwtJGVBV6v nLj+VJ+YmtsJJAqAzql1rqDhzVOVff2Tji9TwkUuPwJ3S4n7dk0gUt6QMV0IzpDo twLAGw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=LQDYO32m1oDrdQVzRy71/yvfb4HvmD7XIau+7tKkJ 9I=; b=dwTfS6RRFk4uXAR5iPWQi/8eijsu1IRweHbxadqIjQwofwaBXawbavZH7 MsD5ppSvGyKIG22snNGtgmL3vXdAHsywoyQNZin0+Mo2DTE+bafKB11B3+mROJuA zCJqpQlX6CWYbkLacWgSl6ff0PPa3lE5tU0sNsOVmx4AM407DlWikVlMjoSgUnAj ww4icH631iTXT0G/bsZDXaRqq2kw+oiqQmGD+OYF+6zKcCoJtthuu89mUS0NkGDI Q1yYu7WHOG1uUa+Jm+jMjAgwzqeqSCMeLAx+eI6Iv1f2FapzuequJoRR6ZhYNgL1 45XsLU545xLh+3lxQs2SBD+pGW85A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvddvfedgvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 2A565108006A; Wed, 30 Dec 2020 06:07:28 -0500 (EST) From: Thomas Monjalon To: Andrew Rybchenko , "Xueming(Steven) Li" Cc: Slava Ovsiienko , Ferruh Yigit , Olivier Matz , Matan Azrad , "dev@dpdk.org" , Asaf Penso Date: Wed, 30 Dec 2020 12:07:26 +0100 Message-ID: <7664483.JXlCD7vbcM@thomas> In-Reply-To: References: <1608303356-13089-1-git-send-email-xuemingl@nvidia.com> <4748b2dc-bc77-b769-a865-00e19f2ffc45@oktetlabs.ru> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [RFC 0/7] support SubFunction representor 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" 30/12/2020 09:54, Xueming(Steven) Li: > Hi Andrew, > > From: Andrew Rybchenko > >On 12/18/20 5:55 PM, Xueming Li wrote: > >> SubFunction [1] is a portion of the PCI device, a SF netdev has its > >> own dedicated queues(txq, rxq). A SF netdev supports eswitch > >> 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 flexibility, this patch also introduces new netdev capability to > >> indicate the capability to support new representor types. > > > >Many thanks for sharing the patchset. Looks very interesting. > >I've already sent my comments and questions for individual patches. > > Appreciate for the wonderful review, will address them next week. I agree, good review, thanks. I am waiting for a v2.