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 C4C0BA04F1; Sun, 8 Dec 2019 11:49:33 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id ED68D374E; Sun, 8 Dec 2019 11:49:32 +0100 (CET) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by dpdk.org (Postfix) with ESMTP id 7F1582C17 for ; Sun, 8 Dec 2019 11:49:31 +0100 (CET) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xB8AjHQB011927; Sun, 8 Dec 2019 02:49:28 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com; h=from : to : cc : subject : date : message-id : mime-version : content-transfer-encoding : content-type; s=pfpt0818; bh=b7aXM8NOpy65DqvqxgtOmEGHQ3pQHyRZrEAZxg8iUA4=; b=jYkbNOmSu0nf87fmE+ElhgSMiARBPUy3y1jpP/M5wqBcSo1LI5Q909vBmq8YVbvVvshQ PMEOLsCDPxiOkl2D+rTOTskeqS5bHNZTLmZTBXxH6ZuzJhoDVK9jCFUn1yeeLuFaXsIR rpIKp5vXJO7ngS8yLq+nA/XTmnfxPy+2ZXQpckNH9lzPKYK/Fbog2nWPd2dzPsBhtvK9 6dggmAY0g8BJ4AG7BNEcd1IWTHzYolJayL0eMMlEfjA+FqiOLpq8atGCewOH69U6RHZl T8j8ST0lsOh/KNfl4lLxsqmwRRnbE8DTkIetyICKf58j1eee3j4wkUfpaztOqZj5LqOY Lg== Received: from sc-exch03.marvell.com ([199.233.58.183]) by mx0a-0016f401.pphosted.com with ESMTP id 2wrbawje9x-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 08 Dec 2019 02:49:28 -0800 Received: from SC-EXCH03.marvell.com (10.93.176.83) by SC-EXCH03.marvell.com (10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Sun, 8 Dec 2019 02:49:27 -0800 Received: from maili.marvell.com (10.93.176.43) by SC-EXCH03.marvell.com (10.93.176.83) with Microsoft SMTP Server id 15.0.1367.3 via Frontend Transport; Sun, 8 Dec 2019 02:49:27 -0800 Received: from ajoseph83.caveonetworks.com.com (unknown [10.29.45.60]) by maili.marvell.com (Postfix) with ESMTP id EC7793F703F; Sun, 8 Dec 2019 02:49:15 -0800 (PST) From: Anoob Joseph To: Akhil Goyal , Adrien Mazarguil , Declan Doherty , Ferruh Yigit , Jerin Jacob , Thomas Monjalon CC: Anoob Joseph , Ankur Dwivedi , Hemant Agrawal , Konstantin Ananyev , Matan Azrad , "Radu Nicolau" , Shahaf Shuler , Narayana Prasad , Date: Sun, 8 Dec 2019 16:11:23 +0530 Message-ID: <1575801683-27269-1-git-send-email-anoobj@marvell.com> X-Mailer: git-send-email 2.7.4 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-08_02:2019-12-05,2019-12-08 signatures=0 Subject: [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" 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 --- lib/librte_ethdev/rte_flow.h | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h index 452d359..21fa7ed 100644 --- a/lib/librte_ethdev/rte_flow.h +++ b/lib/librte_ethdev/rte_flow.h @@ -2239,6 +2239,12 @@ struct rte_flow_action_meter { * direction. * * Multiple flows can be configured to use the same security session. + * + * The NULL value is allowed for security session. If security session is NULL, + * then SPI field in ESP flow item and IP addresses in flow items 'IPv4' and + * 'IPv6' will be allowed to be a range. The rule thus created can enable + * SECURITY processing on multiple flows. + * */ struct rte_flow_action_security { void *security_session; /**< Pointer to security session structure. */ -- 2.7.4