Hi Ori,

Please see inline.

Thanks,
Anoob

-----Original Message-----
From: dev <redacted> On Behalf Of Ori Kam
Sent: Thursday, January 16, 2020 5:06 PM
To: Anoob Joseph <redacted>; Medvedkin, Vladimir
[off-list ref]; Ananyev, Konstantin
[off-list ref]; Akhil Goyal [off-list ref]; Adrien
Mazarguil [off-list ref]; Doherty, Declan
[off-list ref]; Yigit, Ferruh [off-list ref]; Jerin Jacob
Kollanukkaran [off-list ref]; Thomas Monjalon
[off-list ref]
Cc: Ankur Dwivedi <redacted>; Hemant Agrawal
[off-list ref]; Matan Azrad [off-list ref]; Nicolau,
Radu [off-list ref]; Shahaf Shuler [off-list ref];
Narayana Prasad Raju Athreya [off-list ref]; dev@dpdk.org
Subject: Re: [dpdk-dev] [EXT] Re: [PATCH] ethdev: allow multiple security
sessions to use one rte flow

quoted

-----Original Message-----
From: dev <redacted> On Behalf Of Anoob Joseph
Sent: Tuesday, January 14, 2020 11:28 AM
To: Ori Kam <redacted>; Medvedkin, Vladimir
[off-list ref]; Ananyev, Konstantin
[off-list ref]; Akhil Goyal [off-list ref];
Adrien Mazarguil [off-list ref]; Doherty, Declan
[off-list ref]; Yigit, Ferruh [off-list ref];
Jerin Jacob Kollanukkaran [off-list ref]; Thomas Monjalon
[off-list ref]
Cc: Ankur Dwivedi <redacted>; Hemant Agrawal
[off-list ref]; Matan Azrad [off-list ref];

Nicolau,

quoted

Radu [off-list ref]; Shahaf Shuler [off-list ref];
Narayana Prasad Raju Athreya [off-list ref]; dev@dpdk.org
Subject: Re: [dpdk-dev] [EXT] Re: [PATCH] ethdev: allow multiple
security sessions to use one rte flow

Hi Ori,

Please see inline.

Thanks,
Anoob

quoted

-----Original Message-----
From: Ori Kam <redacted>
Sent: Thursday, January 9, 2020 1:06 PM
To: Medvedkin, Vladimir <redacted>; Ananyev,
Konstantin [off-list ref]; Anoob Joseph
[off-list ref]; Akhil Goyal [off-list ref]; Adrien
Mazarguil [off-list ref]; Doherty, Declan
[off-list ref]; Yigit, Ferruh [off-list ref];
Jerin Jacob Kollanukkaran [off-list ref]; Thomas Monjalon
[off-list ref]
Cc: Ankur Dwivedi <redacted>; Hemant Agrawal
[off-list ref]; Matan Azrad [off-list ref];

Nicolau,

quoted

quoted

Radu [off-list ref]; Shahaf Shuler [off-list ref];
Narayana Prasad Raju Athreya [off-list ref]; dev@dpdk.org
Subject: RE: [dpdk-dev] [EXT] Re: [PATCH] ethdev: allow multiple
security sessions to use one rte flow

Hi
sorry for jumping in late.

quoted

-----Original Message-----
From: dev <redacted> On Behalf Of Medvedkin, Vladimir
Sent: Wednesday, January 8, 2020 4:30 PM
To: Ananyev, Konstantin <redacted>; Anoob

Joseph

quoted

quoted

[off-list ref]; Akhil Goyal [off-list ref]; Adrien
Mazarguil [off-list ref]; Doherty, Declan
[off-list ref]; Yigit, Ferruh
[off-list ref];

Jerin

quoted

quoted

Jacob Kollanukkaran [off-list ref]; Thomas Monjalon
[off-list ref]
Cc: Ankur Dwivedi <redacted>; Hemant Agrawal
[off-list ref]; Matan Azrad [off-list ref];
Nicolau, Radu [off-list ref]; Shahaf Shuler
[off-list ref]; Narayana Prasad Raju Athreya
[off-list ref]; dev@dpdk.org
Subject: Re: [dpdk-dev] [EXT] Re: [PATCH] ethdev: allow multiple
security sessions to use one rte flow

Hi Anoob,

On 23/12/2019 13:34, Ananyev, Konstantin wrote:

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

The rte_security API which enables inline

protocol/crypto

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

feature mandates that for every security session an

rte_flow

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

is

created.

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

This would internally translate to a rule in the

hardware

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

which would do packet classification.

In rte_securty, one SA would be one security session.

And

quoted

if

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

an rte_flow need to be created for every session,
the

number

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

of SAs supported by an inline implementation would

be

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

limited by the number of rte_flows the PMD would be

able to

quoted

quoted

quoted

support.

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

If the fields SPI & IP addresses are allowed to be
a

range,

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

then this limitation can be overcome. Multiple
flows

will

quoted

quoted

be

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

able to use one rule for SECURITY processing. In
this

case,

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

the security session provided as conf would be NULL.

Why is that?
If the rte flow can have a range then this means that we need one
security_session for the entire range, Am I missing something? As it
is stated in the rte_fow.h  security_session

can

quoted

be used for multiple flows.

[Anoob] One SA would mean one security_session. So if we have one
security_session for the entire range, then it will be like having
single SA for a range of IP & SPI. Do you think we should allow that?

[Ori] I'm less familiar with security, but this is what I understand you are trying to
do right?

[Anoob] Not exactly. In our implementation, h/w can index into a table which would hold security_sessions. So we can have one rte_flow rule, which will enable the packet steering in the hardware. Which session need to be used will be determined by the SPI.
 

quoted

Also, the intent of the patch is to minimize the number of rte_flow
rules required for inline ipsec processing. Since the security session
is per SA, and if we need multiple SPIs to use same rte_flow rule,
then the security_session field in the rte_flow rule need to be NULL.
Having a non-zero security_session when SPI is a range would be incorrect.

[Ori] I'm all in favor decreasing number of flows.
Sorry for the basic question, what is the security_session /SA dependent on?

[Anoob] No prob! In case of unicast IPsec, every SA would have a unique SPI. So we cannot have multiple SPI's referring to the same SA. And one SA would mean one security_session.

Can one SA include number of different SPI?

[Anoob] No.

May be we need to reimagine this.

Currently, an rte_flow with SECURITY enables ipsec processing with a specific security_session on the packet. This is enabled on a specific IP/SPI specified in the rule.

My proposal: an rte_flow with SECURITY (and session = NULL), would enable ipsec processing on a range and SPI from the packet can be used by the h/w to further figure out the security_session.
 

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

Wonder what will be the usage model for it?
AFAIK,  RFC 4301 clearly states that either SPI
value

alone

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

or in conjunction with dst (and src) IP should
clearly identify SA for inbound SAD

lookup.

quoted

quoted

Am I missing something obvious here?

[Anoob] Existing SECURITY action type requires

application

quoted

to

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

create an 'rte_flow' per SA, which is not really
required if h/w can use SPI to uniquely

identify the security session/SA.

quoted

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.

quoted

quoted

But

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

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

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

rte_flow per SA is not required.

quoted

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

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

SA's which are indexed by SPI+DIP+SIP?

quoted

quoted

quoted

Now h/w could use SPI to index into a pre-populated

table

quoted

quoted

to

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

get security session. Please do note that, SPI is not

ignored

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

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

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

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

quoted

be

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

I'll explain

how it's done in OCTEONTX2 PMD.

quoted

The application would create security_session for every SA.

SPI

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

etc would be

available to PMD (in conf) when the session is created.
Now

the

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

PMD would populate SA related params in a specific
location

that

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

h/w would access. This memory is allocated during device
configure and h/w would have the pointer after the

initialization

quoted

is

quoted

quoted

quoted

done.

quoted

quoted

quoted

quoted

quoted

quoted

If memory is allocated during device configure what is
upper limit for number of sessions? What if app needs more?

quoted

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

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

at, this scheme would

work.

quoted

[Anoob] Yes. But we need to allow application to control
the

h/w

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

ipsec

processing as well. Let's say, application wants to handle
a specific SPI range in lookaside mode (may be because of

unsupported

quoted

quoted

quoted

quoted

quoted

quoted

quoted

capabilities?), in that case having rte_flow will help in
fine tuning how the

h/w packet steering happens.

quoted

quoted

Also, rte_flow enables H/w parsing on incoming packets.
This

info

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

is useful even after IPsec processing is complete. Or if
application wants to give higher priority to a range of
SPIs, rte_flow would allow doing

so.

quoted

quoted

quoted

quoted

What algorithm of indexing by SPI is there? Could I use
any arbitrary SPI? If some kind of hashing is used, what
about

collisions?

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

[Anoob] That is implementation dependent. In our PMD, we

map

quoted

it

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

one

to one.

quoted

quoted

As in, SPI is used as index in the table.
So, as far as you are mapping one to one and using SPI as
an

index,

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

a lot of memory is wasted in the table for unused SPI's.
Also,

you

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

are not able to have a table with 2^32 sessions. It is
likely that some number of SPI's least significant bits are used as

an index.

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

And it raises a question - what if application needs two
sessions with different

SPI's which have the same lsb's?

quoted

[Anoob] rte_security_session_create() would fail. Why do
you

say

quoted

quoted

we

quoted

quoted

quoted

quoted

quoted

cannot support 2^32 sessions? If it's memory limitation, the
same memory limitation would apply even if you have dynamic

allocation

quoted

of

quoted

quoted

quoted

quoted

quoted

quoted

memory for sessions. So at some point session creation would

start

quoted

quoted

quoted

quoted

quoted

quoted

quoted

failing. In our PMD, we allow user to specify the range it
requires

using

quoted

quoted

quoted

quoted

devargs.

quoted

quoted

quoted

Also, collision of LSBs can be avoided by introducing a "MARK"

rule

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

in

addition to "SECURITY" for the rte_flow created for inline ipsec.
Currently that model is not supported (in the library), but
that is one solution to the collisions that can be pursued later.

quoted

quoted

Moreover, what about
two sessions with same SPI but different dst and src ip

addresses?

quoted

quoted

quoted

quoted

quoted

quoted

quoted

[Anoob] Currently our PMD only support UCAST IPSEC. So

another

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

session

with same SPI would result in session creation failure.

Aha, I see, thanks for the explanation. So my suggestion
here

would

quoted

quoted

be:

quoted

quoted

quoted

quoted

quoted

- Application defines that some subset of SA's would be
inline protocol processed. And this SA's will be indexed by SPI only.

- App defines special range for SPI values of this SA's
(size of this range is defined using devargs) and first SPI
value (from

configuration?).

quoted

quoted

quoted

quoted

quoted

- App installs rte_flow only for this range (from first SPI
to first SPI
+ range size), not for all SPI values.

[Anoob] This is exactly what this patch proposes. Allowing
the SPI

and

quoted

quoted

the

quoted

quoted

quoted

IP addresses to be range and have security_session provided as

NULL.

quoted

quoted

What

quoted

quoted

quoted

you have described would be achievable only if we can allow
this modification in the lib.

quoted

So can I assume you are in agreement with this patch?

Not exactly. I meant it is better to make more specified flow like:

...

struct rte_flow_item_esp esp_spec = {

          .hdr = {
                  .spi = rte_cpu_to_be_32(first_spi),
          },

};

struct rte_flow_item_esp esp_mask = {

          .hdr = {
                  .spi = rte_cpu_to_be_32(nb_ipsec_in_sa - 1),
          },

};

pattern[0].type = RTE_FLOW_ITEM_TYPE_ESP;

pattern[0].spec = & esp_spec;

pattern[0].mask = &esp_mask;

...

So this means inline proto device would process only special
subset

of

quoted

quoted

SPI's.

quoted

quoted

quoted

All other will be processed as usual. Sure, you can assign all
2^32 SPI range and it work as you intended earlier. I think we
need to

have

quoted

quoted

quoted

finer grained control here.

[Anoob] Allowing a range for SPI is what you have also described.

What

quoted

quoted

you described is one way to define a range. That will come as

quoted

quoted

part of the implementation, ie, a change in the example application.

This

quoted

quoted

patch intends to allow using a range for SPI than a fixed

quoted

quoted

value. I believe you are also in agreement there.

I also don't have objections for that patch.
The only obseravion from reading your replies to that at
ipsec-secgw

patches:

quoted

Extra API to retrieve size of that HW table seems to be needed.
Though I suppose it could be a subject of separate patch/discussion.

Acked-by: Konstantin Ananyev <redacted>

I also don't have objections.

Acked-by: Vladimir Medvedkin <redacted>

quoted

quoted

quoted

quoted

quoted

- Other SPI values would be processed non inline.

In this case we would be able to have SA addressed by longer

tuple

quoted

quoted

(i.e.

quoted

quoted

quoted

quoted

quoted

SPI+DIP+SIP) outside of before mentioned range, as well as
SPI+DIP+SA

with

quoted

quoted

quoted

quoted

quoted

quoted

quoted

unsupported capabilities by inline protocol device.

quoted

quoted

quoted

quoted

quoted

quoted

quoted

The usage of one 'rte_flow' for multiple SAs is not

mandatory.

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

It is only required when application requires large

number

quoted

of

quoted

quoted

quoted

quoted

SAs.

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

The proposed

change is to allow more efficient usage of h/w
resources

where

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

it's permitted by the PMD.

quoted

quoted

quoted

Application should do an rte_flow_validate() to
make

sure

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

the flow is supported on the PMD.

Signed-off-by: Anoob Joseph <redacted>
---
      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

quoted

quoted

quoted

quoted

quoted

100644

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

--- a/lib/librte_ethdev/rte_flow.h
+++ b/lib/librte_ethdev/rte_flow.h

@@ -2239,6 +2239,12 @@ struct

rte_flow_action_meter

quoted

{

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

       * direction.
       *
       * Multiple flows can be configured to use
the same security

session.

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

+ *
+ * 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

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

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

quoted

quoted

quoted

quoted

quoted

quoted

quoted

*/
--
2.7.4

--
Regards,
Vladimir

--
Regards,
Vladimir

--
Regards,
Vladimir

--
Regards,
Vladimir

--
Regards,
Vladimir