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 CB62DA04BA; Thu, 8 Oct 2020 04:56:41 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2A1F85681; Thu, 8 Oct 2020 04:56:40 +0200 (CEST) Received: from hqnvemgate24.nvidia.com (hqnvemgate24.nvidia.com [216.228.121.143]) by dpdk.org (Postfix) with ESMTP id 3C8AC5323 for ; Thu, 8 Oct 2020 04:56:38 +0200 (CEST) Received: from hqmail.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate24.nvidia.com (using TLS: TLSv1.2, AES256-SHA) id ; Wed, 07 Oct 2020 19:54:46 -0700 Received: from HQMAIL111.nvidia.com (172.20.187.18) by HQMAIL105.nvidia.com (172.20.187.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 8 Oct 2020 02:56:33 +0000 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.42) by HQMAIL111.nvidia.com (172.20.187.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 8 Oct 2020 02:56:33 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lTqjHHroHmx6P5niI3TdvPGiUALHlq48lA+wlA/GB1He9NQa5BGYfp7/j7zcs+92lOhSdHK4hIRLil+CnB/CKg2yfA2JIJrc5Hz9c4PuH6pl/qTRu9/nzNedIbmWtue4skZLvsCm54zS1iBGR/T13IQgzL8HYJSyUw/IqARGD1YKTTN5Zasy+DexcajW0bCfmJc02ydLGbLRz04AWQ1O55o8vl6GcPP93xUUeY7rRCJfsHJGQdc4Lus9aVZ5l9w8F74tgirha1DX3Q9364gwLWV3L//TcKxhcl2uhQ7z8Vg0vrxzCUyIEbSkAna2vX5LpIUgSq6Qy7v7EgLpHyjVhw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lqQ2Ol/VujO6wTz0dHrgPQEjfsy+7wJuU+l8Z+9ZvCc=; b=IQghtKdxuPmK7eHe7RXAV7MmrO7qqyLG/NP73Dbq39RMGB36aVObVEaFHBlIkWbI5WRaXlhuSdBt+GVk3J2vHkSrOTjpRmgoFyBv7H6m1kV9/kniynWn6TkVVxjwdB6GzBnR6tJJ9hCWpGIId01AAGe8j2mT5BoxxMpdigePy7g8Te749qBrmZD5iNp1uu2iINtakB1Wy7FT/GCzDP4cfRWlhTaEJZI9ULu0d0yKVZQ8QE8lWiDy5VukYa8uKxE2IOzOcr/gM3/5jWszOA1oNzwnm5ZQ0xaVtn0cyUw1Qe5aXHytRpiywNjE410J6uj0AFGyk9hecEzztb0FqNYQ8w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none Received: from MWHPR12MB1743.namprd12.prod.outlook.com (2603:10b6:300:113::8) by MWHPR1201MB0045.namprd12.prod.outlook.com (2603:10b6:301:5a::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.21; Thu, 8 Oct 2020 02:56:31 +0000 Received: from MWHPR12MB1743.namprd12.prod.outlook.com ([fe80::9dae:c530:883a:b4dc]) by MWHPR12MB1743.namprd12.prod.outlook.com ([fe80::9dae:c530:883a:b4dc%9]) with mapi id 15.20.3433.046; Thu, 8 Oct 2020 02:56:31 +0000 From: Suanming Mou To: Matan Azrad , Ori Kam , NBU-Contact-Thomas Monjalon , Ferruh Yigit , Andrew Rybchenko CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH v3 2/2] ethdev: make rte_flow API thread safe Thread-Index: AQHWnOX3KxPD7j67fkasn2aEK9P+i6mNAlCw Date: Thu, 8 Oct 2020 02:56:30 +0000 Message-ID: References: <1601194817-208834-1-git-send-email-suanmingm@nvidia.com> <1602080249-36533-1-git-send-email-suanmingm@nvidia.com> <1602080249-36533-3-git-send-email-suanmingm@nvidia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nvidia.com; dkim=none (message not signed) header.d=none;nvidia.com; dmarc=none action=none header.from=nvidia.com; x-originating-ip: [36.27.56.50] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 535cd870-2af3-410e-6c7f-08d86b35c29f x-ms-traffictypediagnostic: MWHPR1201MB0045: x-ld-processed: 43083d15-7273-40c1-b7db-39efd9ccc17a,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1923; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: TFRDaKj5j1hfdj6y77UXewoknDUEA5Phie33mfYXHv6Fpb3GP2u8Tc6ijbZAvbLlopNS63ax1XZ4+IV0dNbIk/+CPrqdxrBfJGYtRomXl0ldsq4bUVLO7KLPaSxJxeSjmnVcH2WpPG7FwwXAhDVHZjM3mpAyn4+6aOKPUPZjhYPf2mhENwCjLjbHC7GicH+EMMU+V71sagta9DUHmhQ/4WSiB+I+pLme5VWQ5/KprdI+6SD0roy/GBy9SizIgg+uoFyK29QESmaPN3YCWtpzlSpTvmYVZoZzgxWkpK1/lFYZ0EgygrUCK53aNSU97y7IauxBVoEox9zE/uLslg1Ocw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR12MB1743.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(136003)(346002)(39860400002)(396003)(376002)(83380400001)(478600001)(4326008)(9686003)(33656002)(55016002)(26005)(186003)(7696005)(6506007)(52536014)(110136005)(53546011)(64756008)(66446008)(66556008)(86362001)(66476007)(5660300002)(76116006)(66946007)(316002)(71200400001)(8676002)(8936002)(2906002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: l4jvZ6nDfM3Fnq2D+2flVCCiBCbQFpO+Oq4m+fd4oJwy5NDRwn2JdCvNvp6fHOW6ojE3oO2PK25fErGdPweq6Q+4ZFUMCWQnVjwrLvwJdBkrCZoT+8HVuSPK5xm7rp50ME6nR2BvErTCOtHB91cSlTk7lVayxTHCfkQVQXuQ151D0A3Uc9OQuYvvJ3XRDtYIKbcNA+hSDROJ6TjVcurG9QUvfV8JGjLdRIqtXHteNyH/kwEV9S58bIksFE+M6pFmXWTaKEldMeiujA0bgPqIWXoFmMazfp/6gOp31DYryK7TWhGu29+6IBm0cKrrXlE2JVVBCOHFfe7hBXzeoAWX88Asv0j1wIrLpfblskP/FhNzWYGGR9oqRowlMHYHXOJTNJULJo1Em8IMnw/lWWXW9nLekTiD3Thf275xAI2DtYaScpy7lQMts3yyou0yW69ulrOPu1z/fbSoVYtyxWPRnwvxwuTtAhs6+vBDkyL1wlbpuVpVKUhmB1lJTf1WMX7QslwJMKNxy2aUWXxwhfpkYJTIwB5YzC9ZW+TWac/T6yisWmOlDdbVelVL743uJXhUCwJXxOeUp1rjpUAv8FYTZq+s95Eck2q6Ktm6ka0JnbzkvWjrx9hhxvIo7u1TCpGCp5obQmVEXz2Gm7LAuH9PJw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MWHPR12MB1743.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 535cd870-2af3-410e-6c7f-08d86b35c29f X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2020 02:56:30.6735 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: KW396l7OeAQtN7MQla5al6FgUFfX0VzVwWOY0fT1EM1OPIYqbTHA6gwfbxDAoEVCIVmCcMSymPTqTzAvWwXHvw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1201MB0045 X-OriginatorOrg: Nvidia.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1602125686; bh=lqQ2Ol/VujO6wTz0dHrgPQEjfsy+7wJuU+l8Z+9ZvCc=; h=ARC-Seal:ARC-Message-Signature:ARC-Authentication-Results:From:To: CC:Subject:Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:authentication-results:x-originating-ip: x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-ms-traffictypediagnostic:x-ld-processed: x-ms-exchange-transport-forked:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-ms-exchange-senderadcheck: x-microsoft-antispam:x-microsoft-antispam-message-info: x-forefront-antispam-report:x-ms-exchange-antispam-messagedata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-AuthAs: X-MS-Exchange-CrossTenant-AuthSource: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped:X-OriginatorOrg; b=Qim171pyADURYy1ZD5M2UMWdCfazWxGLH9v1eLSksMj9hA0tDn5O8L/tCGyTVLJHv MfX0G0NMM4p3GA/P8ASy2Z6L1YgUXYcRf3DLUAYaguS+i8p4/G39aSp2V04LmkS0u1 O8Z09ElpYFjRXorFllmptonwgjT7n4skRCavcIQLBmE3GDMPgPwCOAkk9ntbl9Tj7K fNtrv7UtUYvzMvHRPuNAdEsxydX5mf/+ERJhuzn3g6c2Yv9G1Sl5IIfe5RKHE5hw9/ dkHJHVsohNY7nocrVJ9BlP2Z23CC5fOXA/i7dshZQ5NSfQqP+2z+ub+WD2wC7SQAaM hdjlVahBnBDig== Subject: Re: [dpdk-dev] [PATCH v3 2/2] ethdev: make rte_flow API thread safe 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" > -----Original Message----- > From: Matan Azrad > Sent: Thursday, October 8, 2020 4:11 AM > To: Suanming Mou ; Ori Kam ; > NBU-Contact-Thomas Monjalon ; Ferruh Yigit > ; Andrew Rybchenko > Cc: dev@dpdk.org > Subject: RE: [dpdk-dev] [PATCH v3 2/2] ethdev: make rte_flow API thread s= afe >=20 >=20 >=20 > From: Suanming Mou > > Currently, the rte_flow functions are not defined as thread safe. > > DPDK applications either call the functions in single thread or add > > locks around the functions for the critical section. > > >=20 > Better to write here "or protect any concurrent calling for the rte_flow > operations using a lock." >=20 > > For PMDs support the flow operations thread safe natively, the > > redundant protection in application hurts the performance of the > > rte_flow operation functions. > > > > And the restriction of thread safe not guaranteed for the rte_flow > > functions >=20 > not =3D> is not >=20 > > also limits the applications' expectation. > > > > This feature is going to change the rte_flow functions to be thread > > safe. As different PMDs have different flow operations, some may > > support thread safe already and others may not. For PMDs don't support > > flow thread safe operation, a new lock is defined in ethdev in order > > to protects thread unsafe PMDs from rte_flow level. > > > > A new RTE_ETH_DEV_FLOW_OPS_THREAD_SAFE device flag is added to > > determine whether the PMD supports thread safe flow operation or not. > > For PMDs support thread safe flow operations, set the > > RTE_ETH_DEV_FLOW_OPS_THREAD_SAFE flag, rte_flow level functions will > > skip the thread safe helper lock for these PMDs. Again the rte_flow > > level thread safe lock only works when PMD operation functions are not > > thread safe. > > > > For the PMDs which don't want the default mutex lock, just set the > > flag in the PMD, and add the prefer type of lock in the PMD. Then the > > default mutex lock is easily replaced by the PMD level lock. > > > > The change has no effect on the current DPDK applications. No change > > is required for the current DPDK applications. For the standard posix > > pthread_mutex, if no lock contention with the added rte_flow level > > mutex, the mutex only does the atomic increasing in > > pthread_mutex_lock() and decreasing in pthread_mutex_unlock(). No > > futex() syscall will be involved. > > > > Signed-off-by: Suanming Mou > > --- > > > > v3: > > - update flow_lock/unlock -> fts_enter/exit > > > > v2: > > - Update commit info and description doc. > > - Add inline for the flow lock and unlock functions. > > - Remove the PMD sample part flag configuration. > > > > --- > > > > doc/guides/prog_guide/rte_flow.rst | 9 ++-- > > lib/librte_ethdev/rte_ethdev.c | 2 + > > lib/librte_ethdev/rte_ethdev.h | 2 + > > lib/librte_ethdev/rte_ethdev_core.h | 4 ++ > > lib/librte_ethdev/rte_flow.c | 84 ++++++++++++++++++++++++++++-= -- > > ------ > > 5 files changed, 78 insertions(+), 23 deletions(-) > > > > diff --git a/doc/guides/prog_guide/rte_flow.rst > > b/doc/guides/prog_guide/rte_flow.rst > > index 119b128..ae2ddb3 100644 > > --- a/doc/guides/prog_guide/rte_flow.rst > > +++ b/doc/guides/prog_guide/rte_flow.rst > > @@ -3046,10 +3046,6 @@ Caveats > > - API operations are synchronous and blocking (``EAGAIN`` cannot be > > returned). > > > > -- There is no provision for re-entrancy/multi-thread safety, although > > nothing > > - should prevent different devices from being configured at the same > > - time. PMDs may protect their control path functions accordingly. > > - > > - Stopping the data path (TX/RX) should not be necessary when > > managing flow > > rules. If this cannot be achieved naturally or with workarounds (suc= h as > > temporarily replacing the burst function pointers), an appropriate > > error @@ > > -3101,6 +3097,11 @@ This interface additionally defines the following > > helper > > function: > > - ``rte_flow_ops_get()``: get generic flow operations structure from a > > port. > > > > +If PMD interfaces do not support re-entrancy/multi-thread safety, > > +rte_flow level functions will do it by mutex. The application can > > +test >=20 > Good to mention mutex per port. >=20 > > +the dev_flags with RTE_ETH_DEV_FLOW_OPS_THREAD_SAFE in struct > > +rte_eth_dev_data to know if the rte_flow thread-safe works under > > rte_flow level or PMD level. > > + >=20 > If think it will be helpful to add here a note saying that it is unsafe t= o call other > control commands In parallel to rte_flow operations. >=20 > > More will be added over time. > > > > Device compatibility [snip] > > 1.8.3.1 >=20 > Besides the above (not must) suggestion, looks good, > Acked-by: Matan Azrad Thanks for the suggestions, I will update that in the next version.