DPDK patches and discussions
 help / color / Atom feed
From: Akhil Goyal <akhil.goyal@nxp.com>
To: Anoob Joseph <anoobj@marvell.com>,
	Adrien Mazarguil <adrien.mazarguil@6wind.com>,
	Declan Doherty <declan.doherty@intel.com>,
	Pablo de Lara <pablo.de.lara.guarch@intel.com>,
	Thomas Monjalon <thomas@monjalon.net>
Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>,
	Narayana Prasad Raju Athreya <pathreya@marvell.com>,
	Ankur Dwivedi <adwivedi@marvell.com>,
	Shahaf Shuler <shahafs@mellanox.com>,
	Hemant Agrawal <hemant.agrawal@nxp.com>,
	Matan Azrad <matan@mellanox.com>,
	Yongseok Koh <yskoh@mellanox.com>,
	Wenzhuo Lu <wenzhuo.lu@intel.com>,
	Konstantin Ananyev <konstantin.ananyev@intel.com>,
	Radu Nicolau <radu.nicolau@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [RFC] ethdev: allow multiple security sessions to use one rte flow
Date: Fri, 16 Aug 2019 08:32:06 +0000
Message-ID: <VE1PR04MB66392005959ED915EFD3C230E6AF0@VE1PR04MB6639.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <MN2PR18MB2877466B2274596C237DD26ADFAC0@MN2PR18MB2877.namprd18.prod.outlook.com>

Hi Anoob,
> 
> Hi Akhil,
> 
> > > > >
> > > > > 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 require 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(currently 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 flows you want.

> 
> 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.

Ok now I got it. You want to configure a single flow with multiple sessions 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 time with varied values of SPI and tunnel IPs. How can
One put a range to that.

I would rather say, you actually do not need the rte_flows to be configured for 
Inline protocol processing. You have configured all the session info 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 processing.

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. Will it not work as is for you? 
Atleast for NXP devices we are able to work as is without any issue.

> 
> >
> > > > >
> > > > > Application should do an rte_flow_validate() to make sure the flow
> > > > > is supported on the PMD.
> > > > >
> > > > > Signed-off-by: Anoob Joseph <anoobj@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.

What you intent here is " The rule thus created can enable multiple security sessions on a single rte flow"


Regards,
Akhil

  parent reply index

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-24 14:17 Anoob Joseph
2019-08-02  5:35 ` Anoob Joseph
2019-08-14  9:22   ` Anoob Joseph
2019-08-14 11:07     ` Akhil Goyal
2019-08-15  6:49       ` Anoob Joseph
2019-08-15  9:48         ` Ananyev, Konstantin
2019-08-16  3:24           ` Anoob Joseph
2019-08-16  8:32         ` Akhil Goyal [this message]
2019-08-16 10:12           ` Anoob Joseph
2019-08-19  7:09             ` Akhil Goyal
2019-10-08 13:00               ` Yigit, Ferruh
2019-10-09 10:55                 ` [dpdk-dev] [EXT] " Anoob Joseph
2019-12-03  5:32                   ` Anoob Joseph

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=VE1PR04MB66392005959ED915EFD3C230E6AF0@VE1PR04MB6639.eurprd04.prod.outlook.com \
    --to=akhil.goyal@nxp.com \
    --cc=adrien.mazarguil@6wind.com \
    --cc=adwivedi@marvell.com \
    --cc=anoobj@marvell.com \
    --cc=declan.doherty@intel.com \
    --cc=dev@dpdk.org \
    --cc=hemant.agrawal@nxp.com \
    --cc=jerinj@marvell.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=matan@mellanox.com \
    --cc=pablo.de.lara.guarch@intel.com \
    --cc=pathreya@marvell.com \
    --cc=radu.nicolau@intel.com \
    --cc=shahafs@mellanox.com \
    --cc=thomas@monjalon.net \
    --cc=wenzhuo.lu@intel.com \
    --cc=yskoh@mellanox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

DPDK patches and discussions

Archives are clonable:
	git clone --mirror http://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ http://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev


Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/ public-inbox