[dpdk-dev] [PATCH] ethdev: allow multiple security sessions to use one rte flow
Anoob Joseph
anoobj at marvell.com
Mon Dec 9 14:57:14 CET 2019
Hi Konstantin,
Please see inline.
Thanks,
Anoob
> -----Original Message-----
> From: Ananyev, Konstantin <konstantin.ananyev at intel.com>
> Sent: Monday, December 9, 2019 6:49 PM
> To: Anoob Joseph <anoobj at marvell.com>; Akhil Goyal <akhil.goyal at nxp.com>;
> Adrien Mazarguil <adrien.mazarguil at 6wind.com>; Doherty, Declan
> <declan.doherty at intel.com>; Yigit, Ferruh <ferruh.yigit at intel.com>; Jerin Jacob
> Kollanukkaran <jerinj at marvell.com>; Thomas Monjalon
> <thomas at monjalon.net>
> Cc: Ankur Dwivedi <adwivedi at marvell.com>; Hemant Agrawal
> <hemant.agrawal at nxp.com>; Matan Azrad <matan at mellanox.com>; Nicolau,
> Radu <radu.nicolau at intel.com>; Shahaf Shuler <shahafs at mellanox.com>;
> Narayana Prasad Raju Athreya <pathreya at marvell.com>; dev at dpdk.org
> Subject: [EXT] RE: [PATCH] ethdev: allow multiple security sessions to use one
> rte flow
>
> External Email
>
> ----------------------------------------------------------------------
>
> >
> > 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
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'.
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 <anoobj at 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
More information about the dev
mailing list