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 33819A034F; Tue, 23 Feb 2021 02:54:37 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6FAF94067A; Tue, 23 Feb 2021 02:54:36 +0100 (CET) Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) by mails.dpdk.org (Postfix) with ESMTP id AA2CA40041 for ; Tue, 23 Feb 2021 02:54:35 +0100 (CET) Received: by mail-pl1-f173.google.com with SMTP id z7so8880820plk.7 for ; Mon, 22 Feb 2021 17:54:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=bAK+XxWnpdmT2hIdX/bliQhpc1nUswLAc3dhoPp8Mv8=; b=MRqgVVKtmuvvzpVoKV2+q4vakBmt6duCbkedfd1dUauh6UDfFbOV2vs+moLD/2ICaD 7jtauwS6SzfPuUBUkqU8EHqflk8H9lRej8ulWQwHnf7r38VmbTmBZWVTc6DaNDrjw5oc q1Xov4QGld93+GKziYskusaZniRK9odExL59NX/zGtO5XCT5oAyhj24X1jbdwXUqOUId hnY3Z1Wrc/wHbWVsxPWGmufek0L09jFPj+DATb6pzxPwD7w0X7MckdVyiAIGGkrbZ4QZ /gYWF1U18CwW3GwrnmIvJa/Lpqs2AsLNCFojm6qRypCgi8fMojkF4tk02pC8I1d6MAZ9 hGwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=bAK+XxWnpdmT2hIdX/bliQhpc1nUswLAc3dhoPp8Mv8=; b=c/nqNqmhxN1wWvSiSqq8VqHYdRa+22naDeSR7U3jm5RaW5Bc47JTfJsaxtY+MNTIVH ZCKbpO6ZGAMTYdF+t8i3j2aR+ItMt5t1QgikTSxGjBFxEpeVTC3UjI1UaH4TEoH7IyiY kkmjKRLWLCEwPrj90VTAos0/VT10CW16OMsgqx1DJRTNuXM/uLyVvIiGNgBbQzk859Mx 8zLG4xYT50LoU2rhryZaaHyLOez4V17lFbZ2sF15hNcv8nmb1HwFTox114JALUP25yUH opAYNrEHyfdh692VDBEP/5lG6UM1Q+qIGBNxwQ9amv+w/CWMRy3OXhWrXmoVnnS0aiDV XKZw== X-Gm-Message-State: AOAM530bvAQLodfq27R73YLWO1iTGDxkNTbuXC/ZRxoacvg3X5y69MB9 Yz0XachOCtY47LTATBrnWqm7oQ== X-Google-Smtp-Source: ABdhPJxLay+HSoaEZPsPZcF+o9ps4Glu31drwuol6ldP2ucDqKPezaHxuXsZtadwFB0TTXWbTgLECQ== X-Received: by 2002:a17:902:c211:b029:e3:88d6:3e0c with SMTP id 17-20020a170902c211b02900e388d63e0cmr24569305pll.68.1614045274684; Mon, 22 Feb 2021 17:54:34 -0800 (PST) Received: from hermes.local (76-14-218-44.or.wavecable.com. [76.14.218.44]) by smtp.gmail.com with ESMTPSA id i25sm18364811pgb.33.2021.02.22.17.54.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Feb 2021 17:54:34 -0800 (PST) Date: Mon, 22 Feb 2021 17:54:31 -0800 From: Stephen Hemminger To: Xueming Li Cc: dev@dpdk.org, Viacheslav Ovsiienko , Asaf Penso Message-ID: <20210222175431.05de1f2b@hermes.local> In-Reply-To: <1613272907-22563-1-git-send-email-xuemingl@nvidia.com> References: <1608303356-13089-2-git-send-email-xuemingl@nvidia.com> <1613272907-22563-1-git-send-email-xuemingl@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v6 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 Sun, 14 Feb 2021 03:21:30 +0000 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 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. > > Version history: > RFC: > initial version [2] > V2: > - separate patch for represnetor infrastructure, controller, pf and > sf. > - replace representor ID macro with functions: > rte_eth_representor_id_encode() > rte_eth_representor_id_parse() > - new patch to allow devargs with same PCI BDF but different > representors. > - other minor code updates according to comments, thanks Andrew! > - update document > V3: > - improve probing of allowed devargs with same name. > - parse single word of kvargs as key. > - update kvargs test cases. > V4: > - split first representor refactor patch into > 1: add representor type > 2: refector representor list parsing > - push the patch supporting multi-devargs for same device. > V5: > - add comments for parsing functions > - update switch_representation.rst - Thanks Ajit > V6: > - split representor types into different patches, move to > rte_ethdev.h > - improvements of rte_eth_devargs_process_list() according to > Andrew's suggestion > - fixed PF probe failure for Intel i40e > - replace ethdev SF capability with rte_eth_representor_info_get() > - add new ethdev ops api to get representor info from PMD > - replace representor ID encode/decode with conversion from > representor info > - change ethdev representor iterator to use new ID encoding > > > Xueming Li (9): > ethdev: introduce representor type > ethdev: support representor port list > ethdev: support new VF representor syntax > ethdev: support sub function representor > ethdev: support PF index in representor > ethdev: support multi-host in representor > ethdev: new API to get representor info > ethdev: representor iterator compare complete info > kvargs: update parser to support lists > > app/test/test_kvargs.c | 46 ++++- > config/rte_config.h | 1 + > doc/guides/prog_guide/poll_mode_drv.rst | 13 +- > .../prog_guide/switch_representation.rst | 35 +++- > drivers/net/bnxt/bnxt_ethdev.c | 7 + > drivers/net/enic/enic_ethdev.c | 6 + > drivers/net/i40e/i40e_ethdev.c | 7 + > drivers/net/ixgbe/ixgbe_ethdev.c | 7 + > drivers/net/mlx5/linux/mlx5_os.c | 11 ++ > lib/librte_ethdev/ethdev_driver.h | 49 ++++- > lib/librte_ethdev/ethdev_private.c | 173 ++++++++++++------ > lib/librte_ethdev/ethdev_private.h | 3 - > lib/librte_ethdev/rte_class_eth.c | 40 ++-- > lib/librte_ethdev/rte_ethdev.c | 102 ++++++++++- > lib/librte_ethdev/rte_ethdev.h | 53 ++++++ > lib/librte_ethdev/version.map | 4 + > lib/librte_kvargs/rte_kvargs.c | 101 +++++++--- > 17 files changed, 535 insertions(+), 123 deletions(-) > A couple of higher level design questions: 1. How does Linux and other OS handle this in their API? 2. This solution seems quite tied into a specific implementation on your hardware. Is there a PCI standard for this? 3. Maybe a more general solution where these were represented as buses would allow for other connection methods in the future?