From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Tejasree Kondoj <ktejasree@marvell.com>,
Ori Kam <orika@nvidia.com>, Asaf Penso <asafp@nvidia.com>,
Stephen Hemminger <stephen@networkplumber.org>
Cc: Akhil Goyal <akhil.goyal@nxp.com>,
Radu Nicolau <radu.nicolau@intel.com>,
Declan Doherty <declan.doherty@intel.com>,
NBU-Contact-Thomas Monjalon <thomas@monjalon.net>,
Andrew Rybchenko <arybchenko@solarflare.com>,
Jerin Jacob Kollanukkaran <jerinj@marvell.com>,
Narayana Prasad Raju Athreya <pathreya@marvell.com>,
Anoob Joseph <anoobj@marvell.com>, "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] ethdev: add security flow item
Date: Tue, 20 Apr 2021 02:08:07 +0100 [thread overview]
Message-ID: <47d0904e-136e-69ef-e713-4fd3dc388849@intel.com> (raw)
In-Reply-To: <e37af563-4d98-2eee-2523-8ee7ccd41b63@intel.com>
On 2/17/2021 5:36 PM, Ferruh Yigit wrote:
> On 9/24/2020 11:07 AM, Tejasree Kondoj wrote:
>> Hi Ori,
>>
>> Please see inline.
>>
>> Thanks,
>> Tejasree
>>
>>> -----Original Message-----
>>> From: Ori Kam <orika@nvidia.com>
>>> Sent: Thursday, September 24, 2020 3:22 PM
>>> To: Tejasree Kondoj <ktejasree@marvell.com>; Asaf Penso
>>> <asafp@nvidia.com>; Stephen Hemminger <stephen@networkplumber.org>
>>> Cc: Akhil Goyal <akhil.goyal@nxp.com>; Radu Nicolau
>>> <radu.nicolau@intel.com>; Declan Doherty <declan.doherty@intel.com>;
>>> NBU-Contact-Thomas Monjalon <thomas@monjalon.net>; Ferruh Yigit
>>> <ferruh.yigit@intel.com>; Andrew Rybchenko
>>> <arybchenko@solarflare.com>; Jerin Jacob Kollanukkaran
>>> <jerinj@marvell.com>; Narayana Prasad Raju Athreya
>>> <pathreya@marvell.com>; Anoob Joseph <anoobj@marvell.com>;
>>> dev@dpdk.org
>>> Subject: [EXT] RE: [dpdk-dev] [PATCH] ethdev: add security flow item
>>>
>>> External Email
>>>
>>> ----------------------------------------------------------------------
>>> Thanks,
>>> Ori
>>>
>>>> -----Original Message-----
>>>> From: Tejasree Kondoj <ktejasree@marvell.com>
>>>> Sent: Thursday, September 24, 2020 8:31 AM
>>>>
>>>> Thanks,
>>>> Tejasree
>>>>
>>>>> -----Original Message-----
>>>>> From: Ori Kam <orika@nvidia.com>
>>>>> Sent: Wednesday, September 23, 2020 8:00 PM
>>>>> To: Tejasree Kondoj <ktejasree@marvell.com>; Asaf Penso
>>>>> <asafp@nvidia.com>; Stephen Hemminger
>>> <stephen@networkplumber.org>
>>>>> Cc: Akhil Goyal <akhil.goyal@nxp.com>; Radu Nicolau
>>>>> <radu.nicolau@intel.com>; Declan Doherty <declan.doherty@intel.com>;
>>>>> NBU-Contact-Thomas Monjalon <thomas@monjalon.net>; Ferruh Yigit
>>>>> <ferruh.yigit@intel.com>; Andrew Rybchenko
>>>>> <arybchenko@solarflare.com>; Jerin Jacob Kollanukkaran
>>>>> <jerinj@marvell.com>; Narayana Prasad Raju Athreya
>>>>> <pathreya@marvell.com>; Anoob Joseph <anoobj@marvell.com>;
>>>>> dev@dpdk.org
>>>>> Subject: [EXT] RE: [dpdk-dev] [PATCH] ethdev: add security flow item
>>>>>
>>>>> External Email
>>>>>
>>>>> --------------------------------------------------------------------
>>>>> --
>>>>> Hi
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Tejasree Kondoj <ktejasree@marvell.com>
>>>>>> Sent: Tuesday, September 22, 2020 5:18 PM
>>>>>> Subject: RE: [dpdk-dev] [PATCH] ethdev: add security flow item
>>>>>>
>>>>>> Hi Ori,
>>>>>>
>>>>>> Please see inline.
>>>>>>
>>>>>> Thanks,
>>>>>> Tejasree
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Tejasree Kondoj
>>>>>>> Sent: Tuesday, September 22, 2020 2:37 PM
>>>>>>> To: Ori Kam <orika@nvidia.com>; Asaf Penso <asafp@nvidia.com>;
>>>>>>> Stephen Hemminger <stephen@networkplumber.org>
>>>>>>> Cc: Akhil Goyal <akhil.goyal@nxp.com>; Radu Nicolau
>>>>>>> <radu.nicolau@intel.com>; Declan Doherty
>>>>>>> <declan.doherty@intel.com>; NBU-Contact-Thomas Monjalon
>>>>>>> <thomas@monjalon.net>; Ferruh Yigit <ferruh.yigit@intel.com>;
>>>>>>> Andrew Rybchenko <arybchenko@solarflare.com>; Jerin Jacob
>>>>>>> Kollanukkaran <jerinj@marvell.com>; Narayana Prasad Raju Athreya
>>>>>>> <pathreya@marvell.com>; Anoob Joseph <anoobj@marvell.com>;
>>>>>>> dev@dpdk.org
>>>>>>> Subject: RE: [dpdk-dev] [PATCH] ethdev: add security flow item
>>>>>>>
>>>>>>> Please see inline.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Tejasree
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Ori Kam <orika@nvidia.com>
>>>>>>>> Sent: Tuesday, September 22, 2020 1:22 PM
>>>>>>>> To: Asaf Penso <asafp@nvidia.com>; Tejasree Kondoj
>>>>>>>> <ktejasree@marvell.com>; Stephen Hemminger
>>>>>>>> <stephen@networkplumber.org>
>>>>>>>> Cc: Akhil Goyal <akhil.goyal@nxp.com>; Radu Nicolau
>>>>>>>> <radu.nicolau@intel.com>; Declan Doherty
>>>>>>>> <declan.doherty@intel.com>; NBU-Contact-Thomas Monjalon
>>>>>>>> <thomas@monjalon.net>; Ferruh Yigit <ferruh.yigit@intel.com>;
>>>>>>>> Andrew Rybchenko <arybchenko@solarflare.com>; Jerin Jacob
>>>>>>>> Kollanukkaran <jerinj@marvell.com>; Narayana Prasad Raju
>>>>>>>> Athreya <pathreya@marvell.com>; Anoob Joseph
>>>>>>>> <anoobj@marvell.com>; dev@dpdk.org
>>>>>>>> Subject: [EXT] RE: [dpdk-dev] [PATCH] ethdev: add security
>>>>>>>> flow item
>>>>>>>>
>>>>>>>> External Email
>>>>>>>>
>>>>>>>> --------------------------------------------------------------
>>>>>>>> ----
>>>>>>>> ----
>>>>>>>> Hi
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Asaf Penso <asafp@nvidia.com>
>>>>>>>>> Sent: Monday, September 21, 2020 7:09 PM
>>>>>>>>> Subject: RE: [dpdk-dev] [PATCH] ethdev: add security flow
>>>>>>>>> item
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Asaf Penso
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Tejasree Kondoj <ktejasree@marvell.com>
>>>>>>>>>> Sent: Monday, September 21, 2020 11:59 AM
>>>>>>>>>> To: Asaf Penso <asafp@nvidia.com>; Stephen Hemminger
>>>>>>>>>> <stephen@networkplumber.org>
>>>>>>>>>> Cc: Akhil Goyal <akhil.goyal@nxp.com>; Radu Nicolau
>>>>>>>>>> <radu.nicolau@intel.com>; Declan Doherty
>>>>>>>>>> <declan.doherty@intel.com>; Ori Kam <orika@nvidia.com>;
>>>>>>>>>> NBU-Contact-Thomas Monjalon <thomas@monjalon.net>;
>>> Ferruh
>>>>> Yigit
>>>>>>>>>> <ferruh.yigit@intel.com>; Andrew Rybchenko
>>>>>>>>>> <arybchenko@solarflare.com>; Jerin Jacob Kollanukkaran
>>>>>>>>>> <jerinj@marvell.com>; Narayana Prasad Raju Athreya
>>>>>>>>>> <pathreya@marvell.com>; Anoob Joseph
>>> <anoobj@marvell.com>;
>>>>>>>>>> dev@dpdk.org
>>>>>>>>>> Subject: RE: [dpdk-dev] [PATCH] ethdev: add security flow
>>>>>>>>>> item
>>>>>>>>>>
>>>>>>>>>> Please see inline.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Tejasree
>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Asaf Penso <asafp@nvidia.com>
>>>>>>>>>>> Sent: Thursday, September 17, 2020 3:09 PM
>>>>>>>>>>> To: Stephen Hemminger <stephen@networkplumber.org>;
>>>>> Tejasree
>>>>>>>>>> Kondoj
>>>>>>>>>>> <ktejasree@marvell.com>
>>>>>>>>>>> Cc: Akhil Goyal <akhil.goyal@nxp.com>; Radu Nicolau
>>>>>>>>>>> <radu.nicolau@intel.com>; Declan Doherty
>>>>>>>>>>> <declan.doherty@intel.com>; Ori Kam <orika@nvidia.com>;
>>>>>>>>>>> NBU-Contact-Thomas Monjalon <thomas@monjalon.net>;
>>> Ferruh
>>>>>>>>>>> Yigit <ferruh.yigit@intel.com>; Andrew Rybchenko
>>>>>>>>>>> <arybchenko@solarflare.com>; Jerin Jacob Kollanukkaran
>>>>>>>>>>> <jerinj@marvell.com>; Narayana Prasad Raju Athreya
>>>>>>>>>>> <pathreya@marvell.com>; Anoob Joseph
>>>>>>>>>>> <anoobj@marvell.com>; dev@dpdk.org
>>>>>>>>>>> Subject: [EXT] RE: [dpdk-dev] [PATCH] ethdev: add
>>>>>>>>>>> security flow item
>>>>>>>>>>>
>>>>>>>>>>> External Email
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------
>>>>>>>>>>> ----
>>>>>>>>>>> ----
>>>>>>>>>>> --
>>>>>>>>>>> ---
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: dev <dev-bounces@dpdk.org> On Behalf Of Stephen
>>>>>>>> Hemminger
>>>>>>>>>>>> Sent: Thursday, September 10, 2020 7:46 PM
>>>>>>>>>>>> To: Tejasree Kondoj <ktejasree@marvell.com>
>>>>>>>>>>>> Cc: Akhil Goyal <akhil.goyal@nxp.com>; Radu Nicolau
>>>>>>>>>>>> <radu.nicolau@intel.com>; Declan Doherty
>>>>>>>>>>>> <declan.doherty@intel.com>; Ori Kam
>>>>>>>>>>>> <orika@mellanox.com>; NBU-Contact-Thomas Monjalon
>>>>>>>>>>>> <thomas@monjalon.net>; Ferruh
>>>>>>> Yigit
>>>>>>>>>>>> <ferruh.yigit@intel.com>; Andrew Rybchenko
>>>>>>>>>>>> <arybchenko@solarflare.com>; Jerin Jacob
>>>>>>>>>>>> <jerinj@marvell.com>; Narayana Prasad
>>>>>>>>>>>> <pathreya@marvell.com>; Anoob Joseph
>>>>> <anoobj@marvell.com>;
>>>>>>>>>>>> dev@dpdk.org
>>>>>>>>>>>> Subject: Re: [dpdk-dev] [PATCH] ethdev: add security
>>>>>>>>>>>> flow item
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, 10 Sep 2020 22:14:41 +0530 Tejasree Kondoj
>>>>>>>>>>>> <ktejasree@marvell.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Introduce a new item type RTE_FLOW_ITEM_TYPE_SECURITY
>>>>>>>>>>>>> to
>>>>>>>>>>> distinguish
>>>>>>>>>>>>> plain packets from IPsec decrypted plain packets.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Signed-off-by: Tejasree Kondoj <ktejasree@marvell.com>
>>>>>>>>>>>>
>>>>>>>>>>>> Please provide an implementation, API's without any
>>>>>>>>>>>> driver support should not be accepted.
>>>>>>>>>>>>
>>>>>>>>>>>> Also, we need a test for this.
>>>>>>>>>>
>>>>>>>>>> [Tejasree] We would like to defer the patch and add
>>>>>>>>>> implementation, test case in next cycle.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> +1
>>>>>>>>>>> Also, I think the word SECURITY is too high-level, and if
>>>>>>>>>>> specifically you mention here an item for IPSec, perhaps
>>>>>>>>>>> you can
>>>>>>>> consider renaming.
>>>>>>>>>>
>>>>>>>>>> [Tejasree] This item matches security processed packets and
>>>>>>>>>> not specific to IPsec.
>>>>>>>>>> Will change commit description as follows:
>>>>>>>>>> " Introduce a new item type RTE_FLOW_ITEM_TYPE_SECURITY to
>>>>>>>>>> match packets that were security processed. For example, in
>>>>>>>>>> case of inline IPsec, it can be used to distinguish plain
>>>>>>>>>> packets from IPsec decrypted
>>>>>>>> plain packets"
>>>>>>>>>> Would that be fine?
>>>>>>>>>
>>>>>>>>> It would be more clear, yes, thank you, but in this case I
>>>>>>>>> suggest to have a field in the spec that you can match on it.
>>>>>>>>> For example, is it viable to know if the packet was
>>>>>>>>> processed by IPSec and not AES? Maybe you want to have 2
>>>>>>>>> flow with this new item, but still differentiate between the types.
>>>>>>>>
>>>>>>>> Why not use mark/tag/meta to set this value?
>>>>>>>> The application will insert a flow that sends to security and
>>>>>>>> mark the flow with some ID then the application can check this ID.
>>>>>>>
>>>>>>> [Tejasree] SECURITY itself wouldn't make distinction on protocol.
>>>>>>> It would be combined with MARK_ID to know if the packet was
>>>>>>> processed by IPsec and not AES.
>>>>>>>
>>>>>>> MARK_ID alone couldn't be used as we wouldn't know if it is
>>>>>>> plain packet or security processed plain packet.
>>>>>>>
>>>>>>> Rules would be as follows:
>>>>>>> Rule #1
>>>>>>> [ETH] [IP] [ESP] [SPI] → [SECURITY] [MARK_ID] [END] Rule #2
>>>>>>> [SECURITY] [MARK_ID] [ETH] [IP] → [QUEUE] [END]
>>>>>>>
>>>>>>> I don't understand why in rule #1 you can't have the mark value
>>>>>>> to also mark the security.
>>>>>>> From your patch I understand that security is just one bit This
>>>>>>> means that you can say if MSB bit in mark is set then it comes
>>>>>>> from security.
>>>>>>
>>>>>> [Tejasree] We can use MSB of MARK_ID but that would mean we would
>>>>>> be reserving it for security.
>>>>>>
>>>>> [Ori] but why does the PMD needs it? the application know what it
>>>>> needs so it can use it, It is the application decision to send to
>>>>> the security right? So it knows what values to set.
>>>>>
>>>>> Also the application can use tag or any other data item.
>>>>>
>>>> [Tejasree] PMD needs it to establish connection between security and
>>>> final action to be done (queue for example).
>>>>
>>>> First rule works on the outer packet where the inner packet would be
>>>> hidden by the protocol (like encrypted payload in IPsec) and the
>>>> second rule will act on the de-capsulated packet. So the packets
>>>> itself are different and we cannot have one rule.
>>>>
>>>> In IPsec it is valid (and a very trivial usage) to have one outer
>>>> flow constitute multiple inner flows. Without this, application will
>>>> not be able to configure hardware to treat inner flows differently.
>>>>
>>> Fully agree with you about the app needs to know if it passed security But
>>> this goes also for example simple tunnel where the app may decap the
>>> packet in the on the first flow and then do matching on the inner 5 tuple but
>>> it will need to know if the packet was decaped or what is the vni.
>>>
>>> So in your case the app will send traffic to security and mark it as one that
>>> was gone to security then in the second rule the app will match on the mark
>>> and do what it wants with it.
>>>
>>> I simply don't see why you need new metadata item just to mark if it passed
>>> security.
>>>
>>
>> [Tejasree] Plain packets need to be differentiated from protocol processed ones.
>> In case of regular tunnel, it may or may not be required to differentiate. But
>> with IPsec, it is mandatory to differentiate. So either we will need to
>> reserve MSB of MARK_ID or allow SECURITY.
>>
>
> Reserving a bit in MARK is same as using SECURITY item, I didn't get why any
> arbitrary MARK value can't be used for this as suggested.
>
> Can't application do as following:
> [flow A] -> [decrypt] [mark id=0x10 all processed packets]
> [packets with mark id=0x10] -> [queue 3]
>
> Since application knows the mark value for first rule, it can use same value for
> second rule.
>
> Or are we missing something? Like packets are decrypted without a specific rule,
> hence preventing to mark them, but you still want to apply an action to
> processed packets?
> Missing implementation makes it harder to understand your intention.
The patch is stale, rejecting it, please send a new version if required.
prev parent reply other threads:[~2021-04-20 1:08 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-10 16:44 Tejasree Kondoj
2020-09-10 16:45 ` Stephen Hemminger
2020-09-17 9:38 ` Asaf Penso
2020-09-21 8:58 ` Tejasree Kondoj
2020-09-21 16:09 ` Asaf Penso
2020-09-22 7:51 ` Ori Kam
2020-09-22 9:07 ` Tejasree Kondoj
2020-09-22 13:28 ` Ori Kam
2020-09-22 14:18 ` Tejasree Kondoj
2020-09-23 14:30 ` Ori Kam
2020-09-24 5:30 ` Tejasree Kondoj
2020-09-24 9:51 ` Ori Kam
2020-09-24 10:07 ` Tejasree Kondoj
2021-02-17 17:36 ` Ferruh Yigit
2021-04-20 1:08 ` Ferruh Yigit [this message]
Reply instructions:
You may reply publicly 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=47d0904e-136e-69ef-e713-4fd3dc388849@intel.com \
--to=ferruh.yigit@intel.com \
--cc=akhil.goyal@nxp.com \
--cc=anoobj@marvell.com \
--cc=arybchenko@solarflare.com \
--cc=asafp@nvidia.com \
--cc=declan.doherty@intel.com \
--cc=dev@dpdk.org \
--cc=jerinj@marvell.com \
--cc=ktejasree@marvell.com \
--cc=orika@nvidia.com \
--cc=pathreya@marvell.com \
--cc=radu.nicolau@intel.com \
--cc=stephen@networkplumber.org \
--cc=thomas@monjalon.net \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).