From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f193.google.com (mail-wr0-f193.google.com [209.85.128.193]) by dpdk.org (Postfix) with ESMTP id 6F7F61CC82 for ; Fri, 6 Apr 2018 22:33:54 +0200 (CEST) Received: by mail-wr0-f193.google.com with SMTP id s12so2826941wrc.8 for ; Fri, 06 Apr 2018 13:33:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=eI8zQ57+TJz+UFhEhKe3dA3Jnt6zhJojwDJfchv5P0s=; b=DQ9VizCXVP59Vh2PDaqFzPjalnMD0wQOX7WnBMNb5A23f5zYOfD2nNCpw8PMHbNpx9 MK43lReLJUVel4/hpV8uvOx2xVMIg9o2jF+2moZamYrpM2vVt1t/am/WIXgP7Kb39otv tgBSF4A00rJpxXyB8FRD4WaQQiheQQXnucqPONLnRcP19ArMyyMIzxUmu7PbjLwzGKwe F3NQwTAkjjDbOWxV37lTEO71QKD7weSKW3Q8/c/BMV3bDlfidyRcrJi9e78rzqYCydvG ADQgA5PIHIxgZeObTFqtn6CCTnuDiA7jH6KcQy539EDVuw4pNS9qBHz7S+0Jds/Mffl2 PWUA== 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=eI8zQ57+TJz+UFhEhKe3dA3Jnt6zhJojwDJfchv5P0s=; b=GKhMeXdpHevN0zopkxqIkBqquoHm1g5dBUZyX1Qs+2PHEU8KlOCDkoWbFEgoWTzgLQ G+q6VSy516sPeGxr6+MdBEmGwHheRQpV0G5be6CsEFfF9iJ0envMtRuqQK0JCvkuc2J8 x4UVFuh1eaCctjOLKYu1gHz1EQKo74IZAVzqzZFrzPUTjxaJCClXr577n/scZTAzDjLG 5XZ+fzRwQKkfCCQpV0iTZX8HB2+F9zjFa82QKuY0FqVQRRtEryAQH7HjbMKZh0OlfruN GJRALsiqO9PF1JWpi/mELb/VPGYT8wUO4sV4uU3p5xY92VrriwEb2G5fWvnPzeE3m54m J6rQ== X-Gm-Message-State: AElRT7Gf+bZBCJJAyX0Id7R/kG9P1myjKD3husvBCpHFLfRyySKZ3ZeD ikOxtkmo1k/kHEf8KX0s233Yvg== X-Google-Smtp-Source: AIpwx4+E3erPzw3jqVN2KCofqvi6gtPfllL8Y0KHrqkVf0NFKSWOWfpUupnfqGdPHtcu4vHurcgfeA== X-Received: by 10.223.182.13 with SMTP id f13mr19379023wre.262.1523046435011; Fri, 06 Apr 2018 13:27:15 -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 x9sm21878797wrb.18.2018.04.06.13.27.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Apr 2018 13:27:14 -0700 (PDT) Date: Fri, 6 Apr 2018 22:27:01 +0200 From: Adrien Mazarguil To: Declan Doherty Cc: dev@dpdk.org Message-ID: <20180406202701.GU4957@6wind.com> References: <1523017443-12414-1-git-send-email-declan.doherty@intel.com> <1523017443-12414-5-git-send-email-declan.doherty@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1523017443-12414-5-git-send-email-declan.doherty@intel.com> Subject: Re: [dpdk-dev] [PATCH v3 4/4] ethdev: Add metadata flow and action items support 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: , X-List-Received-Date: Fri, 06 Apr 2018 20:33:54 -0000 On Fri, Apr 06, 2018 at 01:24:03PM +0100, Declan Doherty wrote: > Introduces a new action type RTE_FLOW_ACTION_TYPE_METADATA which enables > metadata extraction from a packet into a specified metadata container > for consumption on further pipeline stages or for propagation to the host > interface. > > As complementary function to the new metadata action type this patch also > introduces a new flow item type which enables flow patterns to specify a > specific metadata container as a matching criteria for a flow rule. > > Signed-off-by: Declan Doherty Is there already HW support for extraction and subsequent matching? Otherwise it looks overkill. If it's meant to be implemented in software by PMDs, isn't the existing MARK action with arbitrary value good enough? All it needs is a corresponding MARK pattern item (which reminds me I forgot to add it...) My suggestion would be to submit this new item/action combo at the same time as the first actual PMD implementation. In the meantime I think a much simpler MARK pattern item could satisfy the most pressing needs. > --- > doc/guides/prog_guide/rte_flow.rst | 85 ++++++++++++++++++++++++++++++++++++++ > lib/librte_ether/rte_flow.h | 42 +++++++++++++++++++ > 2 files changed, 127 insertions(+) > > diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst > index 2f0a47a..9b2b0e3 100644 > --- a/doc/guides/prog_guide/rte_flow.rst > +++ b/doc/guides/prog_guide/rte_flow.rst > @@ -1580,6 +1580,91 @@ group on that device. > +--------------+---------------------------------+ > > > + You keep adding these empty lines :) > +Action: ``METADATA`` > +^^^^^^^^^^^^^^^^^^^^ > + > +Action extracts data from packet into user specified metadata field in pipeline > +for use in downstream processing stages or for propagation to host interface. > + > +The pattern mask is used to define the data which is to be extracted from the > +packet. The mask pattern types defined in the action metadata pattern must > +match the flow pattern definitions up to the last flow item from which data is > +to be extracted. > + > +- Non-terminating by default. Usual comment [1] regarding this property. [1] "ethdev: alter behavior of flow API actions" http://dpdk.org/ml/archives/dev/2018-April/095779.html > + > +.. _table_rte_flow_action_metadata: > + > +.. table:: METADATA > + > + +--------------+---------------------------+ > + | Field | Value | > + +==============+===========================+ > + | ``id`` | Metadata field Identifier | > + +--------------+---------------------------+ > + | ``pattern`` | Extraction mask pattern | > + +--------------+---------------------------+ > + > +The example below demonstrates how the extraction mask to extract the source/ > +destination IPv4 address, the UDP destination port and and the VxLAN VNI can be > +specified. > + > +.. _table_rte_flow_action_metadata_example: > + > +.. table:: IPv4 VxLAN metadata extraction > + > + +-------+--------------------------+-----------------------------------+ > + | Index | Flow Item Type | Flow Mask | > + +=======+==========================+===================================+ > + | 0 | RTE_FLOW_ITEM_TYPE_ETH | .dst = "\x00\x00\x00\x00\x00\x00" | > + | | +-----------------------------------+ > + | | | .src = "\x00\x00\x00\x00\x00\x00" | > + | | +-----------------------------------+ > + | | | .type = RTE_BE16(0x0) | > + +-------+--------------------------+-----------------------------------+ > + | 1 | RTE_FLOW_ITEM_TYPE_IPV4 | .src_addr = RTE_BE32(0xffffffff) | > + | | +-----------------------------------+ > + | | | .dst_addr = RTE_BE32(0xffffffff) | > + +-------+--------------------------+-----------------------------------+ > + | 2 | RTE_FLOW_ITEM_TYPE_UDP | .src_port = RTE_BE16(0x0) | > + | | +-----------------------------------+ > + | | | .dst_port = RTE_BE16(0xffff) | > + +-------+--------------------------+-----------------------------------+ > + | 3 | RTE_FLOW_ITEM_TYPE_VXLAN | .vni = "\xff\xff\xff" | > + +-------+--------------------------+-----------------------------------+ > + | 4 | RTE_FLOW_ITEM_TYPE_END | NULL | > + +-------+--------------------------+-----------------------------------+ > + > +If only the VxLAN VNI extraction was required then the extraction mask would be > +as follows. VxLAN => VXLAN > + > +.. _table_rte_flow_action_metadata_example_2: > + > +.. table:: VxLAN VNI metadata extraction > + > + +-------+--------------------------+-----------------------------------+ > + | Index | Flow Item Type | Flow Mask | > + +=======+==========================+===================================+ > + | 0 | RTE_FLOW_ITEM_TYPE_ETH | .dst = "\x00\x00\x00\x00\x00\x00" | > + | | +-----------------------------------+ > + | | | .src = "\x00\x00\x00\x00\x00\x00" | > + | | +-----------------------------------+ > + | | | .type = RTE_BE16(0x0) | > + +-------+--------------------------+-----------------------------------+ > + | 1 | RTE_FLOW_ITEM_TYPE_IPV4 | .src_addr = RTE_BE32(0x0) | > + | | +-----------------------------------+ > + | | | .dst_addr = RTE_BE32(0x0) | > + +-------+--------------------------+-----------------------------------+ > + | 2 | RTE_FLOW_ITEM_TYPE_UDP | .src_port = RTE_BE16(0x0) | > + | | +-----------------------------------+ > + | | | .dst_port = RTE_BE16(0x0) | > + +-------+--------------------------+-----------------------------------+ > + | 3 | RTE_FLOW_ITEM_TYPE_VXLAN | .vni = "\xff\xff\xff" | > + +-------+--------------------------+-----------------------------------+ > + | 4 | RTE_FLOW_ITEM_TYPE_END | NULL | > + +-------+--------------------------+-----------------------------------+ > + > Negative types > ~~~~~~~~~~~~~~ > > diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h > index 968a23b..f75dee7 100644 > --- a/lib/librte_ether/rte_flow.h > +++ b/lib/librte_ether/rte_flow.h > @@ -323,6 +323,13 @@ enum rte_flow_item_type { > * See struct rte_flow_item_geneve. > */ > RTE_FLOW_ITEM_TYPE_GENEVE, > + > + /** > + * Matches specified pipeline metadata field. > + * > + * See struct rte_flow_item_metadata. > + */ > + RTE_FLOW_ITEM_TYPE_METADATA Please add the trailing comma to ease subsequent contributions. > }; > > /** > @@ -815,6 +822,17 @@ static const struct rte_flow_item_geneve rte_flow_item_geneve_mask = { > #endif > > /** > + * RTE_FLOW_ITEM_TYPE_METADATA > + * > + * Allow arbitrary pipeline metadata to be used in specification flow pattern > + */ > +struct rte_flow_item_metadata { > + uint32_t id; /**< field identifier */ > + uint32_t size; /**< field size */ > + uint8_t *bytes; /**< field value */ > +}; One last nit regarding this definition (assuming we keep it), please remove extra spacing before comments (no alignment) and add caps to format it like the rest of that file. > + > +/** > * Matching pattern item definition. > * > * A pattern is formed by stacking items starting from the lowest protocol > @@ -1266,6 +1284,30 @@ struct rte_flow_action_group { > }; > > /** > + * RTE_FLOW_ACTION_TYPE_METADATA Definition in enum rte_flow_action_type should be part of this commit. > + * > + * Action extracts data from packet into specified metadata field in pipeline > + * for use in downstream processing stages or for propagation to host interface. > + * > + * Pattern mask is use to define the extraction data for packet. The mask > + * pattern types defined in the action metadata pattern must match the flow > + * pattern definitions up to the last item from which data is to be extracted. > + * > + * Non-terminating by default. > + */ > +struct rte_flow_action_metadata { > + uint32_t id; /**< field identifier */ > + > + struct rte_flow_action_mask_item { > + enum rte_flow_item_type type; > + /**< Flow item type. */ > + const void *mask; > + /**< Flow item mask. */ > + } *pattern; > + /** metadata extraction pattern mask specification */ > +}; Same comment as in prior commit regarding this structure. You should use struct rte_flow_item directly, except this time a pointer to a pattern with multiple items seems warranted. > + > +/** > * Definition of a single action. > * > * A list of actions is terminated by a END action. > -- > 2.7.4 > -- Adrien Mazarguil 6WIND