Hi Anoob,
On 11/12/2019 17:33, Anoob Joseph wrote:
Hi Konstantin,
Please see inline.
Thanks,
Anoob
-----Original Message-----
From: dev <dev-boun...@dpdk.org> On Behalf Of Ananyev, Konstantin
Sent: Wednesday, December 11, 2019 4:36 PM
To: Anoob Joseph <ano...@marvell.com>; Akhil Goyal <akhil.go...@nxp.com>;
Adrien Mazarguil <adrien.mazarg...@6wind.com>; Doherty, Declan
<declan.dohe...@intel.com>; Yigit, Ferruh <ferruh.yi...@intel.com>; Jerin Jacob
Kollanukkaran <jer...@marvell.com>; Thomas Monjalon
<tho...@monjalon.net>
Cc: Ankur Dwivedi <adwiv...@marvell.com>; Hemant Agrawal
<hemant.agra...@nxp.com>; Matan Azrad <ma...@mellanox.com>; Nicolau,
Radu <radu.nico...@intel.com>; Shahaf Shuler <shah...@mellanox.com>;
Narayana Prasad Raju Athreya <pathr...@marvell.com>; dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] ethdev: allow multiple security sessions to use
one rte flow
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.
Wonder what will be the usage model for it?
AFAIK, RFC 4301 clearly states that either SPI value alone or in
conjunction with dst (and src) IP should clearly identify SA for inbound SAD
lookup.
Am I missing something obvious here?
[Anoob] Existing SECURITY action type requires application to create
an 'rte_flow' per SA, which is not really required if h/w can use SPI to
uniquely
identify the security session/SA.
Existing rte_flow usage: IP (dst,src) + ESP + SPI -> security
processing enabled on one security session (ie on SA)
The above rule would uniquely identify packets for an SA. But with the
above usage, we would quickly exhaust entries available in h/w lookup
tables (which are limited on our hardware). But if h/w can use SPI field to
index
into a table (for example), then the above requirement of one rte_flow per SA is
not required.
Proposed rte_flow usage: IP (any) + ESP + SPI (any) -> security
processing enabled on all ESP packets
So this means that SA will be indexed only by spi? What about SA's which
are indexed by SPI+DIP+SIP?
Now h/w could use SPI to index into a pre-populated table to get
security session. Please do note that, SPI is not ignored during the actual
lookup. Just that it is not used while creating 'rte_flow'.
And this table will be prepopulated by user and pointer to it will be somehow
passed via rte_flow API?
If yes, then what would be the mechanism?
[Anoob] I'm not sure what exactly you meant by user. But may be I'll explain
how it's done in OCTEONTX2 PMD.
The application would create security_session for every SA. SPI etc would be
available to PMD (in conf) when the session is created. Now the PMD would
populate SA related params in a specific location that h/w would access. This
memory is allocated during device configure and h/w would have the pointer
after the initialization is done.
If memory is allocated during device configure what is upper limit for
number of sessions? What if app needs more?
PMD uses SPI as index to write into specific locations(during session create)
and h/w would use it when it sees an ESP packet eligible for SECURITY (in
receive path, per packet). As long as session creation could populate at memory
locations that h/w would look at, this scheme would work.
What algorithm of indexing by SPI is there? Could I use any arbitrary
SPI? If some kind of hashing is used, what about collisions?
The usage of one 'rte_flow' for multiple SAs is not mandatory. It is
only required when application requires large number of SAs. The proposed
change is to allow more efficient usage of h/w resources where it's permitted by
the PMD.
Application should do an rte_flow_validate() to make sure the flow
is supported on the PMD.
Signed-off-by: Anoob Joseph <ano...@marvell.com>
---
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
--
Regards,
Vladimir
