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 98B30A0487 for ; Fri, 5 Jul 2019 20:05:55 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B15B21BE44; Fri, 5 Jul 2019 20:05:54 +0200 (CEST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20063.outbound.protection.outlook.com [40.107.2.63]) by dpdk.org (Postfix) with ESMTP id D36A41BE31 for ; Fri, 5 Jul 2019 20:05:53 +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=rZTJoyYpyaGa5suGSxMnBkrQVrvTnRrd2uCw/hSdBTk=; b=SiiftEyVbU+8itlsPtdPJG5yXcgUFh0F8HIDlwWFnO5N6/Cv8Vw5P3tQYkJAA9SSWYjyInwmrQYGnXV4nH+s0vytzcmRIM+8tfdJglxjKMkV1s4bdAoUqr3iOrDWSohJOJYIPWZPgOizDFqFeZ7spoZm3f+ULPYaOicKO52CEOQ= Received: from DB3PR0502MB3980.eurprd05.prod.outlook.com (52.134.72.27) by DB3PR0502MB4060.eurprd05.prod.outlook.com (52.134.72.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.18; Fri, 5 Jul 2019 18:05:51 +0000 Received: from DB3PR0502MB3980.eurprd05.prod.outlook.com ([fe80::69c1:c0d7:1fa1:f89f]) by DB3PR0502MB3980.eurprd05.prod.outlook.com ([fe80::69c1:c0d7:1fa1:f89f%6]) with mapi id 15.20.2052.019; Fri, 5 Jul 2019 18:05:50 +0000 From: Yongseok Koh To: Adrien Mazarguil CC: Shahaf Shuler , Thomas Monjalon , Ferruh Yigit , Andrew Rybchenko , Olivier Matz , dev , Slava Ovsiienko Thread-Topic: [PATCH] ethdev: add flow tag Thread-Index: AQHVMzke3qf0ca9JGES4nN+uqhRIuqa8UhsA Date: Fri, 5 Jul 2019 18:05:50 +0000 Message-ID: <6EE319CD-4BBC-47BF-AAE5-2165B8C1D491@mellanox.com> References: <20190603213231.27020-3-yskoh@mellanox.com> <20190704232302.19582-1-yskoh@mellanox.com> <20190705135404.GR4512@6wind.com> In-Reply-To: <20190705135404.GR4512@6wind.com> 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: 2b5d64d3-e801-4d38-2b13-08d701736a1f 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:DB3PR0502MB4060; x-ms-traffictypediagnostic: DB3PR0502MB4060: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 008960E8EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(346002)(376002)(136003)(396003)(39860400002)(199004)(189003)(305945005)(6512007)(6436002)(86362001)(7736002)(2906002)(81156014)(81166006)(8936002)(486006)(6916009)(76176011)(68736007)(33656002)(186003)(26005)(6506007)(53546011)(102836004)(229853002)(6486002)(6116002)(476003)(256004)(14444005)(2616005)(11346002)(36756003)(8676002)(3846002)(446003)(14454004)(99286004)(66476007)(66556008)(64756008)(66446008)(53936002)(91956017)(76116006)(66946007)(6246003)(54906003)(316002)(5660300002)(25786009)(71190400001)(71200400001)(4326008)(73956011)(66066001)(107886003)(478600001)(130830200001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR0502MB4060; 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: nBb0AF85rnGOp9CP5sM3pC7hnPyGoJJYYMzaAusA5OmPCbblTRJ1WJjIg55jUQPpN5pxILrI8LsEZ04VHjMVAp4DzIVoNbZ0YmdUir47ZGV5p+XgiVmmK83lVLMiS2q4DPJQnePgMvQZwChnjMxSdIZ7OGRD6Zw6hocncVT9Nqv+vQLWqUyz6qVyAZN541qxg0KDccqVS5B/hDaUDXpHARlbBmRO0fUZe8qf6Csp4O51zjoICO2Gnk3PgMsTJCXH+/IsnzSTM70Iz+ZtbsWguRuMM9/ygugrtlUVGDhOOXrHYM08NCseWO+n0KDnyeLUTCw9VGFyV/Aafj+Wo3kl/pPfBvHq+BCezquH3SCD/5A72lppmOQpUbmAmJ3/JGtJUDWay+9j/FYEN6DLPJeYpxGZgm4BGuoE/VTRr8GONYs= Content-Type: text/plain; charset="us-ascii" Content-ID: <04D1C1F5508B66479A424D6E42FD49D6@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2b5d64d3-e801-4d38-2b13-08d701736a1f X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2019 18:05:50.8459 (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: DB3PR0502MB4060 Subject: Re: [dpdk-dev] [PATCH] ethdev: add flow tag 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 Jul 5, 2019, at 6:54 AM, Adrien Mazarguil = wrote: >=20 > On Thu, Jul 04, 2019 at 04:23:02PM -0700, Yongseok Koh wrote: >> A tag is a transient data which can be used during flow match. This can = be >> used to store match result from a previous table so that the same patter= n >> need not be matched again on the next table. Even if outer header is >> decapsulated on the previous match, the match result can be kept. >>=20 >> Some device expose internal registers of its flow processing pipeline an= d >> those registers are quite useful for stateful connection tracking as it >> keeps status of flow matching. Multiple tags are supported by specifying >> index. >>=20 >> Example testpmd commands are: >>=20 >> flow create 0 ingress pattern ... / end >> actions set_tag index 2 value 0xaa00bb mask 0xffff00ff / >> set_tag index 3 value 0x123456 mask 0xffffff / >> vxlan_decap / jump group 1 / end >>=20 >> flow create 0 ingress pattern ... / end >> actions set_tag index 2 value 0xcc00 mask 0xff00 / >> set_tag index 3 value 0x123456 mask 0xffffff / >> vxlan_decap / jump group 1 / end >>=20 >> flow create 0 ingress group 1 >> pattern tag index is 2 value spec 0xaa00bb value mask 0xffff00ff / >> eth ... / end >> actions ... jump group 2 / end >>=20 >> flow create 0 ingress group 1 >> pattern tag index is 2 value spec 0xcc00 value mask 0xff00 / >> tag index is 3 value spec 0x123456 value mask 0xffffff / >> eth ... / end >> actions ... / end >>=20 >> flow create 0 ingress group 2 >> pattern tag index is 3 value spec 0x123456 value mask 0xffffff / >> eth ... / end >> actions ... / end >>=20 >> Signed-off-by: Yongseok Koh >=20 > Hi Yongseok, >=20 > Only high level questions for now, while it unquestionably looks useful, > from a user standpoint exposing the separate index seems redundant and no= t > necessarily convenient. Using the following example to illustrate: >=20 > actions set_tag index 3 value 0x123456 mask 0xfffff >=20 > pattern tag index is 3 value spec 0x123456 value mask 0xffffff >=20 > I might be missing something, but why isn't this enough: >=20 > pattern tag index is 3 # match whatever is stored at index 3 >=20 > Assuming it can work, then why bother with providing value spec/mask on > set_tag? A flow rule pattern matches something, sets some arbitrary tag t= o > be matched by a subsequent flow rule and that's it. It even seems like > relying on the index only on both occasions is enough for identification. >=20 > Same question for the opposite approach; relying on the value, never > mentioning the index. >=20 > I'm under the impression that the index is a hardware-specific constraint > that shouldn't be exposed (especially since it's an 8-bit field). If so, = a > PMD could keep track of used indices without having them exposed through = the > public API. Thank you for review, Adrien. Hope you are doing well. It's been long since we talked each other. :-) Your approach will work too in general but we have a request from customer = that they want to partition this limited tag storage. Assuming that HW exposes 3= 2bit tags (those are 'registers' in HW pipeline in mlx5 HW). Then, customers wan= t to store multiple data even in a 32-bit storage. For example, 16bit vlan tag, = 8bit table id and 8bit flow id. As they want to split one 32bit storage, I thoug= ht it is better to provide mask when setting/matching the value. Even some custom= er wants to store multiple flags bit by bit like ol_flags. They do want to alt= er only partial bits. And for the index, it is to reference an entry of tags array as HW can prov= ide larger registers than 32-bit. For example, mlx5 HW would provide 4 of 32b storage which users can use for their own sake. tag[0], tag[1], tag[2], tag[3] Thanks, Yongseok