From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mellanox.co.il (mail-il-dmz.mellanox.com [193.47.165.129]) by dpdk.org (Postfix) with ESMTP id 911AE1396 for ; Sun, 17 Sep 2017 14:12:42 +0200 (CEST) Received: from Internal Mail-Server by MTLPINE1 (envelope-from borisp@mellanox.com) with ESMTPS (AES256-SHA encrypted); 17 Sep 2017 15:06:50 +0300 Received: from gen-l-vrt-098.mtl.labs.mlnx (gen-l-vrt-098.mtl.labs.mlnx [10.137.170.1]) by labmailer.mlnx (8.13.8/8.13.8) with ESMTP id v8HC6oEh013909; Sun, 17 Sep 2017 15:06:50 +0300 From: Boris Pismenny To: dev@dpdk.org Cc: akhil.goyal@nxp.com, 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, nelio.laranjeiro@6wind.com, liranl@mellanox.com Date: Sun, 17 Sep 2017 15:06:29 +0300 Message-Id: <1505649991-3463-1-git-send-email-borisp@mellanox.com> X-Mailer: git-send-email 1.8.3.1 Subject: [dpdk-dev] [PATCH 0/2] Document rte_flow security action 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, 17 Sep 2017 12:12:42 -0000 This series updates the documentation regarding the use of rte_flow security actions for configuring crypto offload. This documentation attempts to provide guidelines for the use of security sessions with inline and protocol offloads. The documentation relfects my understanding of the current status of inline crypto offload. I've added some documentation for full protocol offload as well, even though I am not familiar with any existing implementation. Full protocol offload is the first encap/decap action in rte_flow. For example, in IPsec it implies ESP encap/decap. As an encap/decap offload, it offloads header construction to hardware. This raises the following question: Should the rte_flow pattern hold the pattern of headers to add/remove by hardware? My answer is yes, because it allows us to describe more complex encapsulation offloads and their order - [GRE | ESP | TCP] vs. [ESP | GRE | TCP]. By providing the full pattern we resolve the ambiguity and define the order of encapsulation. While actions describe the encapsulation operation related to each header. The patches are based on the integration branch of dpdk-draft-ipsec. Boris Pismenny (2): doc: add details of rte_flow security actions ethdev: update documentation for security action doc/guides/prog_guide/rte_flow.rst | 83 +++++++++++++++++++++++++++++++++++++- lib/librte_ether/rte_flow.h | 24 +++++++---- 2 files changed, 97 insertions(+), 10 deletions(-) -- 1.8.3.1