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 DDF06A00E6 for ; Tue, 9 Jul 2019 01:32:51 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 07E0D1B958; Tue, 9 Jul 2019 01:32:51 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130048.outbound.protection.outlook.com [40.107.13.48]) by dpdk.org (Postfix) with ESMTP id F2CF21B953 for ; Tue, 9 Jul 2019 01:32:48 +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=Mr8o8J6c95fXEiNK/5OixJ+9/nVYcjazEMkqPX5N9po=; b=TaCo9A/CMRcJxCxmSToJizM1Z79tJ470Xmma24xNX5l2hGmTVgXomwOoKAwy//i2/Zm9c8efUFYAzJ8R2usOCQvBP5AphHiTcsXfimShStR9eXpwN1lX7mbvMNTipIb8PRcvRcc6LRdTHSVytnuVYNuAohzbGPdiacyz9dTPFX0= Received: from DB3PR0502MB3980.eurprd05.prod.outlook.com (52.134.72.27) by DB3PR0502MB4058.eurprd05.prod.outlook.com (52.134.68.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.18; Mon, 8 Jul 2019 23:32:46 +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.020; Mon, 8 Jul 2019 23:32:46 +0000 From: Yongseok Koh To: Adrien Mazarguil CC: Shahaf Shuler , Thomas Monjalon , Ferruh Yigit , Andrew Rybchenko , Olivier Matz , dev , Slava Ovsiienko Thread-Topic: [dpdk-dev] [PATCH] ethdev: add flow tag Thread-Index: AQHVMzke3qf0ca9JGES4nN+uqhRIuqa8UhsAgAUSVoA= Date: Mon, 8 Jul 2019 23:32:46 +0000 Message-ID: <83967DD4-0292-4078-8E33-63BEEA186390@mellanox.com> References: <20190603213231.27020-3-yskoh@mellanox.com> <20190704232302.19582-1-yskoh@mellanox.com> <20190705135404.GR4512@6wind.com> <6EE319CD-4BBC-47BF-AAE5-2165B8C1D491@mellanox.com> In-Reply-To: <6EE319CD-4BBC-47BF-AAE5-2165B8C1D491@mellanox.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: 6b45b6e8-84d6-4e8c-899e-08d703fc9561 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:DB3PR0502MB4058; x-ms-traffictypediagnostic: DB3PR0502MB4058: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00922518D8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(366004)(396003)(136003)(376002)(346002)(199004)(189003)(68736007)(2906002)(66066001)(478600001)(305945005)(316002)(25786009)(476003)(2616005)(11346002)(14444005)(486006)(91956017)(76116006)(66446008)(66946007)(256004)(5660300002)(66476007)(446003)(54906003)(64756008)(66556008)(8936002)(6916009)(81166006)(53936002)(6436002)(81156014)(6246003)(99286004)(6512007)(6486002)(229853002)(6116002)(186003)(26005)(36756003)(14454004)(4326008)(3846002)(7736002)(76176011)(71190400001)(107886003)(71200400001)(53546011)(6506007)(73956011)(8676002)(33656002)(102836004)(86362001)(130830200001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR0502MB4058; 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: ltVwBBEYZB+I3Hzo2Dd2qUl1+bkyNLAO3eXmHlY5DMmWIipcobZrIb1FMNM60pxbHEnSD4JdSej3mSmPWdLTNHxkq6Qyk+BmRAEr0vybzNU6OH+bMgUghLY3U8cev4x48JbqHZm59U999nOdtWtcoPZF4btMShV20EEVG8UyMp6/TYBaihMJVoC/kLvJ/qZxKol6crpPiPDihXQ2k08mhZV6XFyz08vyuXI1sHl4lunleI1rVRgJv4rxmeWJD9lofSawuplmtOKF+HL6eosHV/Tq3N+qEs7Jfo40vP+wm7Oh4B5noBEpltBDMsL34CftrIUC3z3QVmk1YY35u23cdcYXdajKWqOw2vz1wNZ12DQSCgTLJ1e99EEZn/GRJdJsv07i3+hkuffU/frOra3CkdQaW5GSCGzWU7v9VPbd2sA= Content-Type: text/plain; charset="us-ascii" Content-ID: <26D59F6BF518764AB7909103A12685DA@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6b45b6e8-84d6-4e8c-899e-08d703fc9561 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2019 23:32:46.8084 (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: DB3PR0502MB4058 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 11:05 AM, Yongseok Koh wrote: >=20 >=20 >=20 >> 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 patte= rn >>> 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 a= nd >>> those registers are quite useful for stateful connection tracking as it >>> keeps status of flow matching. Multiple tags are supported by specifyin= g >>> 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 n= ot >> 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 = to >> 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 constrain= t >> 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. >=20 >=20 > Thank you for review, Adrien. > Hope you are doing well. It's been long since we talked each other. :-) >=20 > Your approach will work too in general but we have a request from custome= r that > they want to partition this limited tag storage. Assuming that HW exposes= 32bit > tags (those are 'registers' in HW pipeline in mlx5 HW). Then, customers w= ant 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 tho= ught it > is better to provide mask when setting/matching the value. Even some cust= omer > wants to store multiple flags bit by bit like ol_flags. They do want to a= lter > only partial bits. >=20 > And for the index, it is to reference an entry of tags array as HW can pr= ovide > 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] Adrien, Are you okay with this? Thanks, Yongseok