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 9BFA0A0487 for ; Fri, 5 Jul 2019 15:54:09 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 11D451BEC9; Fri, 5 Jul 2019 15:54:08 +0200 (CEST) Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by dpdk.org (Postfix) with ESMTP id 5C13E1BEC7 for ; Fri, 5 Jul 2019 15:54:07 +0200 (CEST) Received: by mail-wr1-f66.google.com with SMTP id z1so5406344wru.13 for ; Fri, 05 Jul 2019 06:54:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=x4NX296Q6bAL6fhuYEVTK6IR36LtgLbVQznAlLG3RZU=; b=aH4kmG3bw/QIyqiJR3wqJc08sDfsXUAu7pe5FyxGIuLvaYp8BcD8aGSiyXjsZ007p8 RyYO3AK6WBjTolYVR7ZNS5e0e7/+SJl3dpEsyh25zV3Nc8lua7KZtwNHrHKpNhVc4QEV cGdqIzYGXUFI/YIWsJrc8dIx9rkEQKf1T8twl4eAh+Mh+4t8Mv2rxkKRZl4JsKZs1uSG HTga5KTqQwtPSyHrYmpRvM43W33tKUBVe4GSsw610f6l3NSImDdKS/MSv1IwwiXSjcgq R8wQ9T3VgqNweCB5/qq7VN0fc7znX/6BFTpYh8LrL/toBPLB188K2itCDTB2y2dEHtr9 2MrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=x4NX296Q6bAL6fhuYEVTK6IR36LtgLbVQznAlLG3RZU=; b=aIcICICNozD88yo/469duROVYI9G+p9dShQdYtUCcJPTJQoDwO+11ryo+NuAbCUlB6 mdCgPo2QbZaGNkygB3iwkTdWSpgZxmBpIl4pjpbbjKkziTU/PZeJGRYCnBL64CoyafmJ C8O464XDqyiJpO8TjEm0be4ovXCODcFV4/2yoNiujZjqUOZkbQ0DBMxo1u22PPse8X2d GcsAd5OGFhqhVZ5seCOx+FBOuS9xRNyYYfggmH0Ue+tgZQxu6Mc0rtJGAtprTPitAh8Q KFdoGuuxLwyKVtqglX6Nq8QQN0pQLqZ68IXOtyMfEVxGEDXQFTtAVbYWcDykj+vfdFza 2SfA== X-Gm-Message-State: APjAAAWqvKO86V3bam+jhiYvuqxp0b2EDmsORs2zIiJJI7016EkfXe3b 7cgSQyWCjD43DIJMS4Ls3Vf5lA== X-Google-Smtp-Source: APXvYqyWI1LScYBicExlwoboY1sZexh++zGRz+mfSTMxNsWaJ3XtTHaQQuA+xD7CCPWcidtW5L5u7Q== X-Received: by 2002:adf:db0b:: with SMTP id s11mr2886205wri.7.1562334847040; Fri, 05 Jul 2019 06:54:07 -0700 (PDT) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id l8sm14472232wrg.40.2019.07.05.06.54.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jul 2019 06:54:06 -0700 (PDT) Date: Fri, 5 Jul 2019 15:54:04 +0200 From: Adrien Mazarguil To: Yongseok Koh Cc: shahafs@mellanox.com, thomas@monjalon.net, ferruh.yigit@intel.com, arybchenko@solarflare.com, olivier.matz@6wind.com, dev@dpdk.org, viacheslavo@mellanox.com Message-ID: <20190705135404.GR4512@6wind.com> References: <20190603213231.27020-3-yskoh@mellanox.com> <20190704232302.19582-1-yskoh@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190704232302.19582-1-yskoh@mellanox.com> 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 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 pattern > 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. > > Some device expose internal registers of its flow processing pipeline and > those registers are quite useful for stateful connection tracking as it > keeps status of flow matching. Multiple tags are supported by specifying > index. > > Example testpmd commands are: > > 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 > > 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 > > flow create 0 ingress group 1 > pattern tag index is 2 value spec 0xaa00bb value mask 0xffff00ff / > eth ... / end > actions ... jump group 2 / end > > 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 > > flow create 0 ingress group 2 > pattern tag index is 3 value spec 0x123456 value mask 0xffffff / > eth ... / end > actions ... / end > > Signed-off-by: Yongseok Koh Hi Yongseok, Only high level questions for now, while it unquestionably looks useful, from a user standpoint exposing the separate index seems redundant and not necessarily convenient. Using the following example to illustrate: actions set_tag index 3 value 0x123456 mask 0xfffff pattern tag index is 3 value spec 0x123456 value mask 0xffffff I might be missing something, but why isn't this enough: pattern tag index is 3 # match whatever is stored at index 3 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. Same question for the opposite approach; relying on the value, never mentioning the index. 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. -- Adrien Mazarguil 6WIND