[dpdk-dev] [RFC] ethdev: allow multiple security sessions to use one rte flow

Anoob Joseph anoobj at marvell.com
Thu Aug 15 08:49:58 CEST 2019


Hi Akhil,

Please see inline.

Thanks,
Anoob

> -----Original Message-----
> From: Akhil Goyal <akhil.goyal at nxp.com>
> Sent: Wednesday, August 14, 2019 4:37 PM
> To: Anoob Joseph <anoobj at marvell.com>; Adrien Mazarguil
> <adrien.mazarguil at 6wind.com>; Declan Doherty
> <declan.doherty at intel.com>; Pablo de Lara
> <pablo.de.lara.guarch at intel.com>; Thomas Monjalon
> <thomas at monjalon.net>
> Cc: Jerin Jacob Kollanukkaran <jerinj at marvell.com>; Narayana Prasad Raju
> Athreya <pathreya at marvell.com>; Ankur Dwivedi
> <adwivedi at marvell.com>; Shahaf Shuler <shahafs at mellanox.com>;
> Hemant Agrawal <hemant.agrawal at nxp.com>; Matan Azrad
> <matan at mellanox.com>; Yongseok Koh <yskoh at mellanox.com>; Wenzhuo
> Lu <wenzhuo.lu at intel.com>; Konstantin Ananyev
> <konstantin.ananyev at intel.com>; Radu Nicolau <radu.nicolau at intel.com>;
> dev at dpdk.org
> Subject: RE: [RFC] ethdev: allow multiple security sessions to use one rte
> flow
> 
> Hi Anoob,
> 
> >
> > Hi all,
> >
> > Reminder...!
> >
> Sorry for a delayed response.
> 
> > If there are no concerns, I'll send the patch after adding the
> > required changes in ipsec-secgw as well.
> >
> > Thanks,
> > Anoob
> >
> > > -----Original Message-----
> > > From: Anoob Joseph <anoobj at marvell.com>
> > > Sent: Friday, August 2, 2019 11:05 AM
> > > To: Anoob Joseph <anoobj at marvell.com>; Akhil Goyal
> > > <akhil.goyal at nxp.com>; Adrien Mazarguil
> > > <adrien.mazarguil at 6wind.com>; Declan Doherty
> > > <declan.doherty at intel.com>; Pablo de Lara
> > > <pablo.de.lara.guarch at intel.com>; Thomas Monjalon
> > > <thomas at monjalon.net>
> > > Cc: Jerin Jacob Kollanukkaran <jerinj at marvell.com>; Narayana Prasad
> > > Raju Athreya <pathreya at marvell.com>; Ankur Dwivedi
> > > <adwivedi at marvell.com>; Shahaf Shuler <shahafs at mellanox.com>;
> Hemant
> > > Agrawal <hemant.agrawal at nxp.com>; Matan Azrad
> <matan at mellanox.com>;
> > > Yongseok Koh <yskoh at mellanox.com>; Wenzhuo Lu
> > > <wenzhuo.lu at intel.com>; Konstantin Ananyev
> > > <konstantin.ananyev at intel.com>; Radu Nicolau
> > > <radu.nicolau at intel.com>; dev at dpdk.org
> > > Subject: RE: [RFC] ethdev: allow multiple security sessions to use
> > > one rte flow
> > >
> > > Hi Akhil, Adrien, Declan, Pablo,
> > >
> > > Can you review this proposal and share your feedback?
> > >
> > > Thanks,
> > > Anoob
> > >
> > > > -----Original Message-----
> > > > From: Anoob Joseph <anoobj at marvell.com>
> > > > Sent: Wednesday, July 24, 2019 7:47 PM
> > > > To: Akhil Goyal <akhil.goyal at nxp.com>; Adrien Mazarguil
> > > > <adrien.mazarguil at 6wind.com>; Declan Doherty
> > > > <declan.doherty at intel.com>; Pablo de Lara
> > > > <pablo.de.lara.guarch at intel.com>; Thomas Monjalon
> > > > <thomas at monjalon.net>
> > > > Cc: Anoob Joseph <anoobj at marvell.com>; Jerin Jacob Kollanukkaran
> > > > <jerinj at marvell.com>; Narayana Prasad Raju Athreya
> > > > <pathreya at marvell.com>; Ankur Dwivedi <adwivedi at marvell.com>;
> > > Shahaf
> > > > Shuler <shahafs at mellanox.com>; Hemant Agrawal
> > > > <hemant.agrawal at nxp.com>; Matan Azrad <matan at mellanox.com>;
> > > Yongseok
> > > > Koh <yskoh at mellanox.com>; Wenzhuo Lu <wenzhuo.lu at intel.com>;
> > > > Konstantin Ananyev <konstantin.ananyev at intel.com>; Radu Nicolau
> > > > <radu.nicolau at intel.com>; dev at dpdk.org
> > > > Subject: [RFC] 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.
> 
> 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. 

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 require to be created.

In the present model, a security session is created, and then rte_flow will connect ESP packets with one SPI to one security session. Instead, when we create the security session, h/w can populate entries 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 the number of SAs that can be supported.
 
> 
> > > >
> > > > 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 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.
> > > > + *
> > > >   */
> > > >  struct rte_flow_action_security {
> > > >  	void *security_session; /**< Pointer to security session structure.
> > > > */
> > > > --
> > > > 2.7.4



More information about the dev mailing list