From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f67.google.com (mail-wm0-f67.google.com [74.125.82.67]) by dpdk.org (Postfix) with ESMTP id C9C691B25B for ; Sun, 15 Oct 2017 14:50:19 +0200 (CEST) Received: by mail-wm0-f67.google.com with SMTP id m72so28731260wmc.1 for ; Sun, 15 Oct 2017 05:50:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dev-mellanox-co-il.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=hMMI9hc0gX+GlSDywcPqmereIWEQQX6zqjicaZly2Sc=; b=f7mCA+7XwuqHQPqmlYxbpDURlX4RQb5xzqWuTXmk15CzK6WlHXQqzGtxek+jtoJRSM 29iJo2XufumAaIf79GN9WLshzDfZsj59+7iTNcLwD7LRKd+XaFz8PDBm1FGg+xYwFiY3 GQY+vpCzOaqVcmIOUUt4l5iqjwSp1mbJE4FJBysRPcNkecAobHbGUvc4RgEqBlwCxwu+ QFq5Jv4VdqinMjYfv67UTAoJmhrPKFl7ZryzCVTv8X7er/a+FqvxQW4j/5rur71saUAH 2+AmnHEiH7gtOtQu/y4hmx3t5/dFWMfcr6xpzpN25jEtP2bQSt0mUpjkp+l/u4IgqDeP dlsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=hMMI9hc0gX+GlSDywcPqmereIWEQQX6zqjicaZly2Sc=; b=cqegmd3D2Z+4bPKfvdOa1pLezn1TJfpMa5+MBoW6G8c0Wc2qnCpqzCh/2ggJhrgozS A0kY4d9Y6+MxqNBHHOSS4bWg0qLt4cs2mxkAgpVIfm0lgJc+2dTteEXMWspMHykOC4zn AwlPHQLlgCN0VfeppAoEKOTKtpjrWGKaOJCbdkFenbMS/BHrk2eYY8zjYcY7d4YrNWOu T9wD4uJzjh07TwbLLY33AEzPlY1fD1nJHCDN0zfvlqwkhEUkZU54bwk10H5EpezCYLMV wj7Igc85HWgP5PZ/ypJaqE0SA2bnntUP/noHMmxHwZWhczJXvZ3W4SHD/kxuhYcE0+jU 9fuA== X-Gm-Message-State: AMCzsaVi2umaw+9aTH3GCA6boZxWfyDxu1/GguXCFg89cTjeqXaMlGdj poJUvIq8a2uEGNg7hshHD5x4Iw== X-Google-Smtp-Source: AOwi7QCwURJN5W3RSRe8Bzh/pOlImIHVQVG9N0AQ1i9B1FKzxjlVtgJrLJLTg506Wr6Szb3pRS1tAA== X-Received: by 10.28.143.130 with SMTP id r124mr5813636wmd.122.1508071819450; Sun, 15 Oct 2017 05:50:19 -0700 (PDT) Received: from [10.0.38.219] ([193.47.165.251]) by smtp.gmail.com with ESMTPSA id o18sm9102145wrc.45.2017.10.15.05.50.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Oct 2017 05:50:18 -0700 (PDT) To: Akhil Goyal , dev@dpdk.org Cc: declan.doherty@intel.com, pablo.de.lara.guarch@intel.com, hemant.agrawal@nxp.com, radu.nicolau@intel.com, borisp@mellanox.com, aviadye@mellanox.com, thomas@monjalon.net, sandeep.malik@nxp.com, jerin.jacob@caviumnetworks.com, john.mcnamara@intel.com, konstantin.ananyev@intel.com, shahafs@mellanox.com, olivier.matz@6wind.com References: <20171006181151.4758-1-akhil.goyal@nxp.com> <20171014221734.15511-1-akhil.goyal@nxp.com> <20171014221734.15511-9-akhil.goyal@nxp.com> From: Aviad Yehezkel Message-ID: Date: Sun, 15 Oct 2017 15:50:16 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171014221734.15511-9-akhil.goyal@nxp.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Subject: Re: [dpdk-dev] [PATCH v4 08/12] doc: add details of rte_flow security actions 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: Sun, 15 Oct 2017 12:50:20 -0000 On 10/15/2017 1:17 AM, Akhil Goyal wrote: > From: Boris Pismenny > > Signed-off-by: Boris Pismenny > Reviewed-by: John McNamara > --- > doc/guides/prog_guide/rte_flow.rst | 84 +++++++++++++++++++++++++++++++++++++- > 1 file changed, 82 insertions(+), 2 deletions(-) > > diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst > index 13e3dbe..ac1adf9 100644 > --- a/doc/guides/prog_guide/rte_flow.rst > +++ b/doc/guides/prog_guide/rte_flow.rst > @@ -187,7 +187,7 @@ Pattern item > Pattern items fall in two categories: > > - Matching protocol headers and packet data (ANY, RAW, ETH, VLAN, IPV4, > - IPV6, ICMP, UDP, TCP, SCTP, VXLAN, MPLS, GRE and so on), usually > + IPV6, ICMP, UDP, TCP, SCTP, VXLAN, MPLS, GRE, ESP and so on), usually > associated with a specification structure. > > - Matching meta-data or affecting pattern processing (END, VOID, INVERT, PF, > @@ -972,6 +972,14 @@ flow rules. > - ``teid``: tunnel endpoint identifier. > - Default ``mask`` matches teid only. > > +Item: ``ESP`` > +^^^^^^^^^^^^^ > + > +Matches an ESP header. > + > +- ``hdr``: ESP header definition (``rte_esp.h``). > +- Default ``mask`` matches SPI only. > + > Actions > ~~~~~~~ > > @@ -989,7 +997,7 @@ They fall in three categories: > additional processing by subsequent flow rules. > > - Other non-terminating meta actions that do not affect the fate of packets > - (END, VOID, MARK, FLAG, COUNT). > + (END, VOID, MARK, FLAG, COUNT, SECURITY). > > When several actions are combined in a flow rule, they should all have > different types (e.g. dropping a packet twice is not possible). > @@ -1371,6 +1379,78 @@ rule or if packets are not addressed to a VF in the first place. > | ``vf`` | VF ID to redirect packets to | > +--------------+--------------------------------+ > > +Action: ``SECURITY`` > +^^^^^^^^^^^^^^^^^^^^ > + > +Perform the security action on flows matched by the pattern items > +according to the configuration of the security session. > + > +This action modifies the payload of matched flows. For INLINE_CRYPTO, the > +security protocol headers and IV are fully provided by the application as > +specified in the flow pattern. The payload of matching packets is > +encrypted on egress, and decrypted and authenticated on ingress. > +For INLINE_PROTOCOL, the security protocol is fully offloaded to HW, > +providing full encapsulation and decapsulation of packets in security > +protocols. The flow pattern specifies both the outer security header fields > +and the inner packet fields. The security session specified in the action > +must match the pattern parameters. > + > +The security session specified in the action must be created on the same > +port as the flow action that is being specified. > + > +The ingress/egress flow attribute should match that specified in the > +security session if the security session supports the definition of the > +direction. > + > +Multiple flows can be configured to use the same security session. > + > +- Non-terminating by default. > + > +.. _table_rte_flow_action_security: > + > +.. table:: SECURITY > + > + +----------------------+--------------------------------------+ > + | Field | Value | > + +======================+======================================+ > + | ``security_session`` | security session to apply | > + +----------------------+--------------------------------------+ > + > +The following is an example of configuring IPsec inline using the > +INLINE_CRYPTO security session: > + > +The encryption algorithm, keys and salt are part of the opaque > +``rte_security_session``. The SA is identified according to the IP and ESP > +fields in the pattern items. > + > +.. _table_rte_flow_item_esp_inline_example: > + > +.. table:: IPsec inline crypto flow pattern items. > + > + +-------+----------+ > + | Index | Item | > + +=======+==========+ > + | 0 | Ethernet | > + +-------+----------+ > + | 1 | IPv4 | > + +-------+----------+ > + | 2 | ESP | > + +-------+----------+ > + | 3 | END | > + +-------+----------+ > + > +.. _table_rte_flow_action_esp_inline_example: > + > +.. table:: IPsec inline flow actions. > + > + +-------+----------+ > + | Index | Action | > + +=======+==========+ > + | 0 | SECURITY | > + +-------+----------+ > + | 1 | END | > + +-------+----------+ > + > Negative types > ~~~~~~~~~~~~~~ > Tested-by: Aviad Yehezkel