From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id C18A0A0096 for ; Thu, 6 Jun 2019 20:33:47 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id AE2B31B9B2; Thu, 6 Jun 2019 20:33:31 +0200 (CEST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70050.outbound.protection.outlook.com [40.107.7.50]) by dpdk.org (Postfix) with ESMTP id 145111B9AB for ; Thu, 6 Jun 2019 20:33:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kg3Hu0JRVMbgE4l09wEueEq9hEwsxwmqsi7cxeemWEE=; b=j47RS50xSScg/E1jgpwcJ/gQS4MAh0O3jbwJZEE3WntAqt/Hm8a1xI0BvUoTImlJtP+FprTqTx1H4wDNTyKiNXrbKPpQ10DDy+NCqYYInWI+FaucTL0P3ZhYDTSPs66mkKE4FtTRdtaFPteJSPC3dSkpTpJijpYAmFzHb6XOdYE= Received: from DB3PR0502MB3980.eurprd05.prod.outlook.com (52.134.72.27) by DB3PR0502MB3964.eurprd05.prod.outlook.com (52.134.65.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1943.21; Thu, 6 Jun 2019 18:33:29 +0000 Received: from DB3PR0502MB3980.eurprd05.prod.outlook.com ([fe80::24ee:49a5:d686:cbc4]) by DB3PR0502MB3980.eurprd05.prod.outlook.com ([fe80::24ee:49a5:d686:cbc4%3]) with mapi id 15.20.1965.011; Thu, 6 Jun 2019 18:33:29 +0000 From: Yongseok Koh To: Jerin Jacob Kollanukkaran CC: Shahaf Shuler , Thomas Monjalon , "ferruh.yigit@intel.com" , "arybchenko@solarflare.com" , Adrien Mazarguil , "olivier.matz@6wind.com" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [RFC 2/3] ethdev: add flow modify mark action Thread-Index: AQHVGlPqwab7ivtxwkW+yEQOezePWqaOcoYAgACFfAA= Date: Thu, 6 Jun 2019 18:33:29 +0000 Message-ID: References: <20190603213231.27020-1-yskoh@mellanox.com> <20190603213231.27020-2-yskoh@mellanox.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=yskoh@mellanox.com; x-originating-ip: [209.116.155.178] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a1707edc-82df-4d7d-411b-08d6eaad78d9 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:DB3PR0502MB3964; x-ms-traffictypediagnostic: DB3PR0502MB3964: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 00603B7EEF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(136003)(346002)(376002)(396003)(13464003)(199004)(189003)(53936002)(305945005)(86362001)(6246003)(6512007)(14444005)(229853002)(316002)(73956011)(66556008)(76116006)(66946007)(66066001)(4326008)(66476007)(66446008)(64756008)(91956017)(6436002)(33656002)(6486002)(8676002)(81156014)(81166006)(8936002)(36756003)(25786009)(3846002)(6116002)(7736002)(486006)(476003)(446003)(53546011)(11346002)(2616005)(54906003)(6506007)(76176011)(102836004)(99286004)(256004)(26005)(82746002)(186003)(2906002)(68736007)(83716004)(71190400001)(478600001)(6916009)(5660300002)(71200400001)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR0502MB3964; H:DB3PR0502MB3980.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: JfFwjepWUgSs5ai+qsAVtbGVrRBe9DND6yNFzIFyhQyulwRqpu3CdJtnxK4qC5bhCEVSUdF2w9dW+zB1tWCdywNtMZ/W+bw+PzfOGvWI6UKXaA8HMCie5dYwS+CizWCUyumMUTlti8U0KSbLLeyDPyFP41md7uoL4YDYLIC0AfHiXtklaA+tA/gtuv7T1EWHPauYfcluI71GHNvjYgjkSSi5hnDfLnN+9MKB27oTU4474NwedAg/qI/WFKlAKIlF4YLto6MzYPvjRTNF+WzEZLLkrfpDOhDYxRtj1bZFSdbW7gycRxrGcREXpl7nH2yvvsiEvxPahEKIuAFLW1ucyUHaNrlRn81+RIFj/yk6v2YDhYSAPC4U9SV5EZUvPWXvezSqwBgztCD6Vw53nKmKR7sdpkL/7IHJ65c0iA4z6g4= Content-Type: text/plain; charset="us-ascii" Content-ID: <85F615961DA46D46B8B609D2CC27B0B6@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: a1707edc-82df-4d7d-411b-08d6eaad78d9 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2019 18:33:29.5890 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yskoh@mellanox.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR0502MB3964 Subject: Re: [dpdk-dev] [RFC 2/3] ethdev: add flow modify mark action 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" > On Jun 6, 2019, at 3:35 AM, Jerin Jacob Kollanukkaran wrote: >=20 >> -----Original Message----- >> From: dev On Behalf Of Yongseok Koh >> Sent: Tuesday, June 4, 2019 3:03 AM >> To: shahafs@mellanox.com; thomas@monjalon.net; ferruh.yigit@intel.com; >> arybchenko@solarflare.com; adrien.mazarguil@6wind.com; >> olivier.matz@6wind.com >> Cc: dev@dpdk.org >> Subject: [dpdk-dev] [RFC 2/3] ethdev: add flow modify mark action >>=20 >> Mark ID can be modified when supporting multiple tables. Partial bit >> alteration is supported to preserve some bit-fields set by previous matc= h. >>=20 >> Signed-off-by: Yongseok Koh >> --- >> doc/guides/prog_guide/rte_flow.rst | 21 +++++++++++++++++++++ >> lib/librte_ethdev/rte_flow.h | 24 ++++++++++++++++++++++++ >> 2 files changed, 45 insertions(+) >>=20 >> diff --git a/doc/guides/prog_guide/rte_flow.rst >> b/doc/guides/prog_guide/rte_flow.rst >> index 016cd90e52..2907edfff4 100644 >> --- a/doc/guides/prog_guide/rte_flow.rst >> +++ b/doc/guides/prog_guide/rte_flow.rst >> @@ -1463,6 +1463,27 @@ depends on the underlying implementation. It is >> returned in the >> | ``id`` | integer value to return with packets | >> +--------+--------------------------------------+ >>=20 >> +Action: ``MODIFY_MARK`` >> +^^^^^^^^^^^^^^^^^^^^^^^ >> + >> +Alter partial bits of mark ID set by ``MARK`` action. >> + >> +``mask`` indicates which bits are modified. For bits which have never >> +been set by ``MARK`` or ``MODIFY_MARK``, unpredictable value will be >> +seen depending on driver implementation. >> + >> +.. _table_rte_flow_action_modify_mark: >> + >> +.. table:: MODIFY_MARK >> + >> + +----------+--------------------------------------+ >> + | Field | Value | >> + +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D+ >> + | ``id`` | integer value to return with packets | >> + +----------+--------------------------------------+ >> + | ``mask`` | bit-mask applies to "id" | >> + +----------+--------------------------------------+ >> + >> Action: ``FLAG`` >> ^^^^^^^^^^^^^^^^ >>=20 >> diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h= index >> cda8628183..d811f8a06e 100644 >> --- a/lib/librte_ethdev/rte_flow.h >> +++ b/lib/librte_ethdev/rte_flow.h >> @@ -1316,6 +1316,13 @@ enum rte_flow_action_type { >> */ >> RTE_FLOW_ACTION_TYPE_MARK, >>=20 >> + /** >> + * Alter partial bits of mark ID set by >> RTE_FLOW_ACTION_TYPE_MARK. >> + * >> + * See struct rte_flow_action_modify_mark. >> + */ >> + RTE_FLOW_ACTION_TYPE_MODIFY_MARK, >> + >=20 > I think, we need to define the case where application calls MODIFY_MARK f= irst on given pattern before MARK Good input.=20 > I think, either we can=20 > # Introduce an error number for that? Practically, it would be impossible to keep track of MARK action to check i= f it is set or not prior to MODIFY_MARK. When creating flows with multiple tables, we can't say a flow having MODIFY= _MARK action will have prior MARK action or not. > # Treat first MODIFY_MARK as MARK So, I took similar approach. In the documentation above, unset bits would have arbitrary value depending= on driver/device implementation. User can't assume mark ID is initially zeroed but rather need to check it w= ith vendors. > Just to understand, in this absence of this new action, an application ne= eds > to destroy the given pattern with associated existing MARK action and > add the same pattern with updated value as MARK action? Right? Application would have to override it by second MARK action. But it has to be validated by user anyway to check if device allows overrid= e. Thanks, Yongseok