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 5FE79A0528; Mon, 20 Jan 2020 10:51:16 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 55E1E1AFF; Mon, 20 Jan 2020 10:51:15 +0100 (CET) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) by dpdk.org (Postfix) with ESMTP id 5AE5B1252 for ; Mon, 20 Jan 2020 10:51:13 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id C290561C1; Mon, 20 Jan 2020 04:51:10 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Mon, 20 Jan 2020 04:51:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=SV6XM4c/y9uPVdMjHnanSpx63n2xMcZ/fu/jjc/qxVg=; b=E3crEpHSJ6A+ IyUZixPR8GZ+oPUWyHQFJJJZhtZoqkgov/nTI/GqGg50vQ2HQMZwpJ9yIzAYIHNI c5/EUCTPYoVdDd6h6um4hzoWrFGS8b2DfKCkGGmjVidOItzEkHgkGHWUBUa/Dseg IEJzatJYcB/mr6cp/vd2HRT0YMXFK+k= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=SV6XM4c/y9uPVdMjHnanSpx63n2xMcZ/fu/jjc/qx Vg=; b=YJDfGeviYuC3B3iRsPs1gwPJ3UDZNBYbysjbaa6G3G08pd6sBLu8V23p3 wmSnlHpXmcXVk7tKI4t8bQ5r4BQ+2MSrjMIQQlny83r2buV67NXmKMtjsnQGWmgj eWIcN5hH1Yf1Izcf6qjleFLJ5+FJY4VMZL0VLlO2Op6e5+UAZQqJCaXna8+NU/ZW VaK/QRO2Sjz/piuJlmX3mS6J/ivoVazuEoFKAxbh/qasLiYBrJ5Svpz8bBqNQYL3 HNiq8fgKZnWdxpIs5TD76A1kTeSHEy5YX14gJc26oh0WH97YmRqTcL9Jcoy017I1 niD04gNrkVwg2s+MVPeNT++dOdyIQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudehgddtiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epjeejrddufeegrddvtdefrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhho mhgrshesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 9E74730608F1; Mon, 20 Jan 2020 04:51:08 -0500 (EST) From: Thomas Monjalon To: Anoob Joseph Cc: Jerin Jacob , dev@dpdk.org, Akhil Goyal , Adrien Mazarguil , Declan Doherty , Ferruh Yigit , Jerin Jacob , Ankur Dwivedi , Hemant Agrawal , Konstantin Ananyev , Matan Azrad , Radu Nicolau , Shahaf Shuler , Narayana Prasad , dpdk-dev , Ori Kam Date: Mon, 20 Jan 2020 10:51:07 +0100 Message-ID: <2348030.Y4W8hZkJsM@xps> In-Reply-To: References: <1575801683-27269-1-git-send-email-anoobj@marvell.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] ethdev: allow multiple security sessions to use one rte flow 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" 10/12/2019 21:47, Ori Kam: > > > -----Original Message----- > > Subject: Re: [dpdk-dev] [PATCH] ethdev: allow multiple security sessions to > > use one rte flow > > > > On Sun, Dec 8, 2019 at 4:19 PM Anoob Joseph wrote: > > > > > > The rte_security API which enables inline protocol/crypto feature > > > mandates that for every security session an rte_flow is created. This > > > would internally translate to a rule in the hardware which would do > > > packet classification. > > > > > > In rte_securty, one SA would be one security session. And if an rte_flow > > > need to be created for every session, the number of SAs supported by an > > > inline implementation would be limited by the number of rte_flows the > > > PMD would be able to support. > > > > > > If the fields SPI & IP addresses are allowed to be a range, then this > > > limitation can be overcome. Multiple flows will be able to use one rule > > > for SECURITY processing. In this case, the security session provided as > > > conf would be NULL. > > > > > > Application should do an rte_flow_validate() to make sure the flow is > > > supported on the PMD. > > > > > > Signed-off-by: Anoob Joseph > > > > Reviewed-by: Jerin Jacob > > Acked-by: Ori Kam Reworded title: ethdev: allow multiple security sessions to use flow rule and converted "SECURITY" to lowercase, then Applied for -rc1