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 00452A046B for ; Mon, 19 Aug 2019 09:09:20 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1F6101B05; Mon, 19 Aug 2019 09:09:20 +0200 (CEST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20075.outbound.protection.outlook.com [40.107.2.75]) by dpdk.org (Postfix) with ESMTP id B34D2DE3 for ; Mon, 19 Aug 2019 09:09:18 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cwqe0cDP+Vzoc8MsN/UIZArtXFKHf8D76O3cDDdbA5vCxx2DZY2pE4zYoZFqQZjzYFgiipwFYwndazjTcCOK0JtIn0AoYHTsNS01Dd1FWYyEDXjJW/6Bv61clLXZqAFMFbe6Ns463yE3JS3PYVyQKYK1sAoRkMBWSdAv7o9oeRBuawxBSCMhId6ArERcZ8Y/Ap6WUalri+uhWA9z7SiQn62keIqR7dgvIJXvoDTgMFTLkZZjjnQMRDmPNexjXi2DlpClYY7epIlGU0odQKl4whnN/M22XvwaXm5dbnplyWR5/GYel6aYh2hvnCUTkzwJAUMueN22dSpmroGBh0nJPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FzeoEafqNXo4ZZc4FmfotfzgMz2g2V9UGWDqyMytrWw=; b=gppt3Pq5RwOUF7D9jP4K217A2ghois2+/+6KnhVf3H5RuBYl9ufAEn1wrFBwYr6LmN0S/+U/aOoHrDcm6O8Gxru0WtIRQ3SC/6xti6DWseQ1eibCfBhqP6seGJwMxuAplBzzQGtWqUSxkl21+2VpntruiGQMwMYUpjO2349aN65G2txoLxT4a2Dzcrq7N+wDr8uK8AV+iJQxnMudBtCOCmcvK1pGd7C043uHpp+E2fea+RjGDW7gH8GpwMhWaquo9T57Lpp0z3uMuhRQUuCByhU+nxQoez85zOGYO4fI3bnOlPVg+Ec4Ap5XbQQaf5PIzxcgMeXhVPnB5oU296TuwQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FzeoEafqNXo4ZZc4FmfotfzgMz2g2V9UGWDqyMytrWw=; b=ef/A4Q0JrFqlNtqDM+bAddzw6v6PtG+nTdO1d6AifQfozZRnqx07lAEyoJKTJsPXde82sFNcBckvwuzawP3sY+VlmzXuCjbDhUSqW5XT5c+yU7tabuq4O4OEzuSwJo3c9bp/z+QnGK/xV1BgkxXHTN0NvOgKmlIlm3BFmBt3yqI= Received: from VE1PR04MB6639.eurprd04.prod.outlook.com (20.179.235.82) by VE1PR04MB6655.eurprd04.prod.outlook.com (20.179.235.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.18; Mon, 19 Aug 2019 07:09:17 +0000 Received: from VE1PR04MB6639.eurprd04.prod.outlook.com ([fe80::49e5:67a2:3fa0:840]) by VE1PR04MB6639.eurprd04.prod.outlook.com ([fe80::49e5:67a2:3fa0:840%7]) with mapi id 15.20.2178.018; Mon, 19 Aug 2019 07:09:17 +0000 From: Akhil Goyal To: Anoob Joseph , Adrien Mazarguil , Declan Doherty , Pablo de Lara , Thomas Monjalon CC: Jerin Jacob Kollanukkaran , Narayana Prasad Raju Athreya , Ankur Dwivedi , Shahaf Shuler , Hemant Agrawal , Matan Azrad , Yongseok Koh , Wenzhuo Lu , Konstantin Ananyev , Radu Nicolau , "dev@dpdk.org" Thread-Topic: [RFC] ethdev: allow multiple security sessions to use one rte flow Thread-Index: AQHVQiqiQXkSuDRH0UWTk2TJNfxPTqbnY7gAgBMbf4CAABnksIABTd4AgAGUeFCAADaOgIAEgA5Q Date: Mon, 19 Aug 2019 07:09:17 +0000 Message-ID: References: <1563977848-30101-1-git-send-email-anoobj@marvell.com> In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=akhil.goyal@nxp.com; x-originating-ip: [92.120.1.65] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 073829ce-31af-4d76-6a97-08d724742646 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:VE1PR04MB6655; x-ms-traffictypediagnostic: VE1PR04MB6655: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0134AD334F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(39860400002)(396003)(346002)(136003)(189003)(199004)(186003)(6436002)(15650500001)(66066001)(7696005)(26005)(76176011)(3846002)(6506007)(14444005)(256004)(11346002)(229853002)(305945005)(86362001)(486006)(66476007)(2906002)(66446008)(476003)(64756008)(446003)(76116006)(66946007)(6116002)(66556008)(102836004)(99286004)(7416002)(6246003)(44832011)(55016002)(71200400001)(71190400001)(9686003)(14454004)(74316002)(316002)(110136005)(54906003)(81166006)(8676002)(81156014)(478600001)(8936002)(25786009)(4326008)(7736002)(561944003)(53936002)(33656002)(5660300002)(52536014); DIR:OUT; SFP:1101; SCL:1; SRVR:VE1PR04MB6655; H:VE1PR04MB6639.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: sO5rcZJ/QDeZM+wR71N5vxMSwS67jiZezcY7p08R/OW7+eq3TygD0hCAJf85fDhw1ICTJuXQMcqTgJ8GstyKYc4tRFVZIwhlHfuAJti8c2UrXjT+SqVqx2RwN6mLcZnlllxxaIS/R0r5mq63lX/37HdQKckcqqZ+hYXQfYyXLM2FTcrLphms7K4yBJdKCP3yNEAQ3H63A06EPWp1jLzTRvib4oOYv3MAdlAc6GsFNgJEYh8lqCcN46bnZwEbfcLUhp+6aSdRcTp0RD76Z/mX5K9e3kpAjA23/i0Ne0Rp33UTpyn7C5M4YwS+PpRTj3VofkVsBxH2ZipPZQ4HbGVmBBYJKa+Z4RWpp1cEuz9MtYQW0v8Pblw2qfQwfxnv4yfzKl+HhYxanDNANEDjbo/hm7KRShJLdj6z/O0b/M5uNMk= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: 073829ce-31af-4d76-6a97-08d724742646 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Aug 2019 07:09:17.2750 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vrsahO4ZBIwnXCLdcYsgHSVuF5xfLgJdwl7BN5fesGxcoMcZ6TMParlC1McWhG7UlqJRO8ylCSdTY3rI6Y/Dwg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR04MB6655 Subject: Re: [dpdk-dev] [RFC] 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" Hi Anoob, >=20 > Hi Akhil, >=20 > > > > > > > > > > > > > > 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. > > > > > > > > SPI values are normally used to uniquely identify the SA that need > > > > to be applied on a particular flow. > > > > I believe SPI value should not be a range for applying a particular > > > > SA or session. > > > > > > > > Plain packet IP addresses can be a range. That is not an issue. > > > > Multiple plain packet flows can use the same session/SA. > > > > > > > > Why do you feel that security session provided should be NULL to > > > > support multiple flows. > > > > How will the keys and other SA related info will be passed to the > > driver/HW. > > > > > > [Anoob] The SA configuration would be done via rte_security session. > > > The proposal here only changes the 1:1 dependency of rte_flow and > > > rte_security session. > > > > I don't see this dependency for rte_flow and security session. > > Multiple flows can be configured to use the same security session. > > > > > > > > The h/w could use SPI field in the received packet to identify SA(ie, > > > rte_security session). If the h/w allows to index into a table which > > > holds SA information, then per SPI rte_flow is not required. This is > > > in fact our case. And for PMDs which doesn't do it this way, > > > rte_flow_validate() would fail and then per SPI rte_flow would requir= e to > > be created. > > > > I am not able to understand the issue here. Flow are validated based on > > some pattern, You can identify the flow based on some parameter(current= ly > > it is spi in case of inline crypto and also your case). > > You can perform some action based on the security session that you have > > created before validating the flow And that session creation is nowhere > > linked to the type of flow. You can use the same session for as many fl= ows > > you want. > > > > > > > > In the present model, a security session is created, and then rte_flo= w > > > will connect ESP packets with one SPI to one security session. > > > Instead, when we create the security session, h/w can populate entrie= s > > > in a DB that would be accessed during data path handling. And the > > > rte_flow could say, all SPI in some range gets inline processed with = the > > security session identified with its SPI. > > > > > > Our PMD supports limited number of flow entries but our h/w can do SA > > > lookup without flow entries(using SPI instead). So the current > > > approach of one flow per session is creating an artificial limit to t= he number > > of SAs that can be supported. > > > > Ok now I got it. You want to configure a single flow with multiple sess= ions in > > it. > > But defining a range in SPI and tunnel IP addresses does not make sense= . In > > real world applications, Sessions can be created and destroyed at any t= ime > > with varied values of SPI and tunnel IPs. How can One put a range to th= at. > > > > I would rather say, you actually do not need the rte_flows to be config= ured > > for Inline protocol processing. You have configured all the session inf= o in the > > hw while Creating the session and your H/W will be able to identify on = the > > basis of SPI value which It has stored in the DB and do all the process= ing. >=20 > [Anoob] Yes. That is the model being followed right now. Concern is, whet= her > this would be deviating from the spec. In other words, we could have devi= ces > which would need rte_flow for every rte_security session (ixgbe needs for= inline > crypto), and then we could have devices which doesn't need per session > rte_flow (which is our case). What do you think is the right approach for > supporting both kinds of devices? Inline proto case is not using rte_flow at the moment. And as far as I understand, you also do not need rte_flow to be configured. Inline crypto cases are mainly for Intel and Mellanox cases which only supp= orted Inline crypto. For Protocol offload cases, I don't feel we need rte_flow as= all information related to ipsec is already there when we call the session create. Rte_flow= s are used For segregation of ethernet traffic for classification which can be configu= red for various factors as well. >=20 > > > > What are the changes that you need in the ipsec-secgw for inline proto = to > > work, there is No flow processing currently in the inline proto case. W= ill it not > > work as is for you? >=20 > [Anoob] In ipsec-secgw, a default flow would be created per security enab= led > port with 'conf=3DNULL' & SPI =3D 'ANY'. Flow validate would be done to m= ake sure > the underlying PMD supports it. For PMDs which doesn't support this model= , per > SA flow would be created. Why do you need that flow as well. You have all the information in the sess= ion already. You can process the packets based on that information. Isn't it? Current implementation in application is good enough in my opinion. >=20 > > Atleast for NXP devices we are able to work as is without any issue. >=20 > [Anoob] Just curious, would having such a dependency on rte_flow be an is= sue > for NXP devices? As of now I do not have any comment on this. We are not using rte_flow in o= ur work as of now. It is kind of POC for us, we may not upstream it. This will depend on the changes that will be done. >=20 > > > > > > > > > > > > > > > > > > > > > > > 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 f3a8fb1..4977d3c 100644 > > > > > > > --- a/lib/librte_ethdev/rte_flow.h > > > > > > > +++ b/lib/librte_ethdev/rte_flow.h > > > > > > > @@ -1879,6 +1879,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. > > > > What you intent here is " The rule thus created can enable multiple sec= urity > > sessions on a single rte flow" > > > > > > Regards, > > Akhil