Message ID | 1608303356-13089-1-git-send-email-xuemingl@nvidia.com (mailing list archive) |
---|---|
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 4BD01A09FD; Fri, 18 Dec 2020 15:56:11 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 28D7CCAD1; Fri, 18 Dec 2020 15:56:09 +0100 (CET) Received: from mellanox.co.il (mail-il-dmz.mellanox.com [193.47.165.129]) by dpdk.org (Postfix) with ESMTP id 325BCCACF for <dev@dpdk.org>; Fri, 18 Dec 2020 15:56:08 +0100 (CET) Received: from Internal Mail-Server by MTLPINE1 (envelope-from xuemingl@nvidia.com) with SMTP; 18 Dec 2020 16:56:06 +0200 Received: from nvidia.com (pegasus05.mtr.labs.mlnx [10.210.16.100]) by labmailer.mlnx (8.13.8/8.13.8) with ESMTP id 0BIEu65Q013340; Fri, 18 Dec 2020 16:56:06 +0200 From: Xueming Li <xuemingl@nvidia.com> To: Viacheslav Ovsiienko <viacheslavo@nvidia.com>, Thomas Monjalon <thomas@monjalon.net>, Ferruh Yigit <ferruh.yigit@intel.com>, Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>, Olivier Matz <olivier.matz@6wind.com>, Matan Azrad <matan@nvidia.com> Cc: dev@dpdk.org, xuemingl@nvidia.com, Asaf Penso <asafp@nvidia.com> Date: Fri, 18 Dec 2020 14:55:49 +0000 Message-Id: <1608303356-13089-1-git-send-email-xuemingl@nvidia.com> X-Mailer: git-send-email 1.8.3.1 Subject: [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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Series |
support SubFunction representor
|
|
Message
Xueming Li
Dec. 18, 2020, 2:55 p.m. UTC
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. [1]: https://lore.kernel.org/netdev/20201112192424.2742-1-parav@nvidia.com/ Xueming Li (7): ethdev: support sub function representor ethdev: support multi-host representor devarg: change reprsentor ID to bitmap ethdev: capability for new representor syntax kvargs: update parser for new representor syntax common/mlx5: update representor name parsing net/mlx5: support representor of sub function 0000-cover-letter.patch | 44 ++++++ config/rte_config.h | 1 + drivers/common/mlx5/linux/mlx5_common_os.c | 32 ++-- drivers/common/mlx5/linux/mlx5_nl.c | 2 + drivers/common/mlx5/mlx5_common.h | 2 + drivers/net/mlx5/linux/mlx5_ethdev_os.c | 5 + drivers/net/mlx5/linux/mlx5_os.c | 69 ++++++++- drivers/net/mlx5/mlx5_ethdev.c | 2 + lib/librte_ethdev/ethdev_private.c | 164 ++++++++++++++------- lib/librte_ethdev/ethdev_private.h | 3 - lib/librte_ethdev/rte_class_eth.c | 7 +- lib/librte_ethdev/rte_ethdev.c | 5 +- lib/librte_ethdev/rte_ethdev.h | 2 + lib/librte_ethdev/rte_ethdev_driver.h | 35 +++++ lib/librte_kvargs/rte_kvargs.c | 82 +++++++---- 15 files changed, 351 insertions(+), 104 deletions(-) create mode 100644 0000-cover-letter.patch
Comments
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. > [1]: > https://lore.kernel.org/netdev/20201112192424.2742-1-parav@nvidia.com/ [snip]
Hi Andrew, >-----Original Message----- >From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru> >Sent: Monday, December 28, 2020 9:45 PM >To: Xueming(Steven) Li <xuemingl@nvidia.com>; Slava Ovsiienko ><viacheslavo@nvidia.com>; NBU-Contact-Thomas Monjalon ><thomas@monjalon.net>; Ferruh Yigit <ferruh.yigit@intel.com>; Olivier Matz ><olivier.matz@6wind.com>; Matan Azrad <matan@nvidia.com> >Cc: dev@dpdk.org; Asaf Penso <asafp@nvidia.com> >Subject: Re: [RFC 0/7] support SubFunction representor > >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. > >> [1]: >> https://lore.kernel.org/netdev/20201112192424.2742-1-parav@nvidia.com/ > >[snip]
30/12/2020 09:54, Xueming(Steven) Li: > Hi Andrew, > > From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru> > >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.