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 CBAA9A00BE; Wed, 30 Oct 2019 16:20:26 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 06EBF1C011; Wed, 30 Oct 2019 16:20:26 +0100 (CET) Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by dpdk.org (Postfix) with ESMTP id 5515E1C010 for ; Wed, 30 Oct 2019 16:20:25 +0100 (CET) Received: by mail-wr1-f68.google.com with SMTP id e6so921414wrw.1 for ; Wed, 30 Oct 2019 08:20:25 -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:user-agent; bh=X4I+CrPQC+OvRWpsVw4JeuKV+Kec11hru+qJAVGkNwM=; b=MPWR2R6NhO7CCipuF9SQ3NaykzU1Hex1SC0ixiOMK9ifcfa356gbvQAyZxbO6tWHwm RqHZvR4r5ZK4KOZN0dwuVX1LMgSqud2/2rczuKx8eWHaY3SfJg5/om4QuFWH/vQKuSOr RH4wm5tNyKvnhyroPKcgRbROxpoE3NVxRqlsqirce6eoQYAWf0ac2YinN4fHLr1z7hhQ jSOm940nzGzLl1477f34T8KBCM0KCP8FjP1GVmGC4Amp8i9n3URGGBPYvhZDwMvu4pFA WvD3enImxkKhOVu9An/LNmtvXvinvgVqCboecOLndx6jm8thvW7rnld4ZNg0epEKDj57 zC9Q== 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:user-agent; bh=X4I+CrPQC+OvRWpsVw4JeuKV+Kec11hru+qJAVGkNwM=; b=jyN6xzqtcFpL7Xj4zgvPUwitzV083h8fRgXlswfxGd9ylGox4vuUExwOK5Bglcda2p dYp9MaNEjVroBw00GvuWM0LlxoeeM8frz8+dnL6XU1IkwC6mJ230pGP9RGNfm1SX8hlm KCbG4rMX0f6MY4vnPxCtpQCJYh1Rvew+RiEtsOTKIDO49ZMFA6E6Et7MUtkJBL2o30og VVmv5Hnkxcr8BAyVJ9Hdkh++0ardXH9dVfnuY9tBa2wNzovEAbfntAKawqD8laAyTEbX y8LbZ3x0kg4/13yddhN5uAKd/TseyUxmdPRn1JOt8NNrxhgNYc/IjCauVV6nsYJsZunt PL+Q== X-Gm-Message-State: APjAAAUj5xqnmmHut7JIBI291UlJAmtdEZYbBIrntb0M8XXxyAHkzbLS ays4mU9/ruXcv6zDSA8Gmfg2vw== X-Google-Smtp-Source: APXvYqwNj58EEspOhVQPewCt1cysR4xQQbO2zQDEHzndnOQeOYPwrfPDDJfjlqURB4w382hWVUiO1Q== X-Received: by 2002:adf:c105:: with SMTP id r5mr356780wre.125.1572448824895; Wed, 30 Oct 2019 08:20:24 -0700 (PDT) Received: from 6wind.com (2a01cb0c0005a6000226b0fffeed02fc.ipv6.abo.wanadoo.fr. [2a01:cb0c:5:a600:226:b0ff:feed:2fc]) by smtp.gmail.com with ESMTPSA id a13sm603537wrf.73.2019.10.30.08.20.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Oct 2019 08:20:24 -0700 (PDT) Date: Wed, 30 Oct 2019 16:20:23 +0100 From: Olivier Matz To: Slava Ovsiienko Cc: Andrew Rybchenko , "dev@dpdk.org" , Matan Azrad , Raslan Darawsheh , Thomas Monjalon Message-ID: <20191030152023.q3aubtc6u56afhvn@platinum> References: <1572201636-16374-1-git-send-email-viacheslavo@mellanox.com> <1572377502-13620-1-git-send-email-viacheslavo@mellanox.com> <0533b4e8-5bd8-2450-ac3a-b4b190423289@solarflare.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Subject: Re: [dpdk-dev] [PATCH v5] ethdev: extend flow metadata 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" Hi, On Wed, Oct 30, 2019 at 02:46:06PM +0000, Slava Ovsiienko wrote: > > -----Original Message----- > > From: Slava Ovsiienko > > Sent: Wednesday, October 30, 2019 16:41 > > To: Andrew Rybchenko ; dev@dpdk.org > > Cc: Matan Azrad ; Raslan Darawsheh > > ; Thomas Monjalon ; > > olivier.matz@6wind.com > > Subject: RE: [PATCH v5] ethdev: extend flow metadata > > > > > -----Original Message----- > > > From: Andrew Rybchenko > > > Sent: Wednesday, October 30, 2019 10:02 > > > To: Slava Ovsiienko ; dev@dpdk.org > > > Cc: Matan Azrad ; Raslan Darawsheh > > > ; Thomas Monjalon ; > > > olivier.matz@6wind.com; Yongseok Koh > > > Subject: Re: [PATCH v5] ethdev: extend flow metadata > > > > > > On 10/29/19 10:31 PM, Viacheslav Ovsiienko wrote: > > > > Currently, metadata can be set on egress path via mbuf tx_metadata > > > > field with PKT_TX_METADATA flag and RTE_FLOW_ITEM_TYPE_META > > > matches metadata. > > > > > > > > This patch extends the metadata feature usability. > > > > > > > > 1) RTE_FLOW_ACTION_TYPE_SET_META > > > > > > > > When supporting multiple tables, Tx metadata can also be set by a > > > > rule and matched by another rule. This new action allows metadata to > > > > be set as a result of flow match. > > > > > > > > 2) Metadata on ingress > > > > > > > > There's also need to support metadata on ingress. Metadata can be > > > > set by SET_META action and matched by META item like Tx. The final > > > > value set by the action will be delivered to application via > > > > metadata dynamic field of mbuf which can be accessed by > > > > RTE_FLOW_DYNF_METADATA() macro or with > > > > rte_flow_dynf_metadata_set() and rte_flow_dynf_metadata_get() helper > > > > routines. PKT_RX_DYNF_METADATA flag will be set along with the data. > > > > We have a problem with PKT_RX_DYNF_METADATA/ > > PKT_TX_DYNF_METADATA. > > These ones are referencing to global variable > > "rte_flow_dynf_metadata_mask". > > And there are routines in rte_mbuf.c (rte_get_rx_ol_flag_list) which show > > the names of flags. It is not good if rte_mbuf.c would require including of > > rte_flow.h and linking rte_flow.c (not all apps use rte_flow or even ethdev). > > > > What do you think? Should we rename rte_flow_dynf_xxxxx variables to > > rte_mbuf_dynf_flow_metadata_xxxx and put ones into the rte_mbuf_dyn.c? > > The same about PKT_RX_DYNF_METADATA definition, is it candidate to > > move to rte_mbuf_dyn.h ? It would allow not to link or include rte_flow.c/h > > into rte_mbuf.c > > In rte_mbuf_dyn.c, we maintain a list of registered flags. I think it wouldn't be too difficult to introduce the equivalent of rte_get_*_ol_flag_list() and *rte_get_*_ol_flag_name() for dynamic flags. There is already a dump function (which does both fields and flags), and a lookup by name function. Maybe we could split the dump into fields and flags, and add a lookup by offset/bitnum. Would it work for your use-case? > It is interesting to note that despite metadata field looks to be related to rte_flow, > there is no any reference to this field or flags inside rte_flow API implementation. > Only datapath references this field. Metadata is gateway between flow HW space and datapath, > it tends to be mostly on datapath side not on rte_flow. Yes, only the registration of the field is related to rte_flow. But I don't get where are you going with this. Is it a problem?