From: Anoob Joseph <anoob.joseph@caviumnetworks.com>
To: Adrien Mazarguil <adrien.mazarguil@6wind.com>,
Boris Pismenny <borisp@mellanox.com>
Cc: anoob.joseph@caviumnetworks.com,
"Nélio Laranjeiro" <nelio.laranjeiro@6wind.com>,
"Sergio Gonzalez Monroy" <sergio.gonzalez.monroy@intel.com>,
"Radu Nicolau" <radu.nicolau@intel.com>,
"Aviad Yehezkel" <aviadye@mellanox.com>,
"Liran Liss" <liranl@mellanox.com>, "dev@dpdk.org" <dev@dpdk.org>,
"Jerin Jacob" <jerin.jacob@caviumnetworks.com>,
"Narayana Prasad" <narayanaprasad.athreya@caviumnetworks.com>
Subject: Re: [dpdk-dev] [PATCH v3 2/2] examples/ipsec-secgw: add target queues in flow actions
Date: Fri, 5 Jan 2018 11:48:50 +0530 [thread overview]
Message-ID: <6de0bb26-11dc-f7b3-cc87-dd1f3a00723c@caviumnetworks.com> (raw)
In-Reply-To: <20171221142235.GL5377@6wind.com>
Hi Adrien,
On 12/21/2017 07:52 PM, Adrien Mazarguil wrote:
> On Thu, Dec 21, 2017 at 12:12:29PM +0200, Boris Pismenny wrote:
> <snip>
>> On 12/21/2017 10:06 AM, Anoob Joseph wrote:
> <snip>
>>> I can see the benefits of using rte_flow in both rx & tx, but this
>>> unnecessarily introduces hardware requirements for supporting inline.
>>> Rte_flow would do two operations:
>>> 1) Pattern matching
>>> 2) Perform some operation with the above matched packets
>>>
>>> Issue is with pattern matching, not about performing the operations
>>> specified. If we need rte_flow in the tx, the PMD should support pattern
>>> matching in software or hardware. Since the application will have to do
>>> a lookup in it's space to determine the SA, the secondary lookup in the
>>> PMD may not be necessary. But making rte_flow mandatory would make tx
>>> side pattern matching mandatory, which may not be supported on all
>>> hardware (with inline crypto/protocol). Also the pattern matching
>>> hardware module should be able to submit to inline performing module for
>>> this to work.
>>>
>>> May be the right approach is to decouple pattern matching from actions
>>> to be performed for the flow. In other words, add a new API to allow
>>> application to submit a packet to a flow. In such case, application
>>> could do the lookup and submit packet to a flow. The packet submitted
>>> could be validated to see if it is matching the flow properties. If it
>>> is matching, then the actions specified for the flow would be performed.
>>> Adding such an API will allow rte_flow to be used with hardware which
>>> doesn't have packet filtering features.
>>>
>>> The flow could have a "pattern item" which would say whether application
>>> can submit packets to the flow. Submit would be allowed only for those
>>> flows. flow_validate would give PMD the option to accept or reject such
>>> a model. This may need some thought before we can start implementing,
>>> like, whether we should support "submit" for flows which doesn't have
>>> terminating action.
>>>
>>> Any thoughts?
>> I think that your suggested API is more or less the intended use of rte_flow
>> egress actions with rte_security.
>>
>> Would it be wrong to say that you could use rte_flow without doing pattern
>> matching in HW or in the PMD in the data-path?
>> Suppose that your HW doesn't support pattern matching on tx. But, you do
>> support IPsec inline crypto on tx according to user provided pointers that
>> you set in the set_pkt_metadata callback. The user will call rte_create_flow
>> with some pattern, in response you check that the driver's set_pkt_metadata
>> could handle such patterns and actions on tx. If yes, then return success,
>> otherwise return false. The successful creation of the flow will indicate to
>> the user that packets with this format will be offloaded. Packets with other
>> formats will not get offload and set_pkt_metadata for such packets shouldn't
>> be called!
>>
>> When using rte_flow with IPsec, it is used not to indicate that HW must do
>> this pattern matching. But rather to indicate that software will send
>> packets that match a pattern with proper metadata and expect an action to be
>> applied. Software cannot expect this action to be applied unless the packet
>> matches the pattern and the proper metadata is provided. For example,
>> packets with IPv6 extension headers should not go through IPsec inline
>> crypto offload if the pattern is IPv6/ESP because the next IP protocol must
>> be ESP.
> I think there's already a way to satisfy everyone regarding context
> requirements on TX without the huge penalty of SW parsing in case HW doesn't
> support matching on egress.
>
> While seldom used at the moment, rte_flow patterns can match packet
> meta-data (see meta pattern items); for instance RTE_FLOW_ITEM_TYPE_PORT
> matches a physical port of the underlying device. This works both with
> ingress and egress.
>
> For ingress, RTE_FLOW_ACTION_TYPE_MARK can be used to add meta data to
> selected packets. While for egress such an action doesn't make much sense at
> the moment, the converse meta pattern item (RTE_FLOW_ITEM_TYPE_MARK) could
> be useful to let PMD know what needs to be done with packets submitted by
> the application and containing a given mark.
Good suggestion. For ingress this would help. The only problem with this
is the size of ID. Since it is 32 bit, this particular mark cannot be
used to save and retrieve application pointers. If it was 64 bit, this
could've solved all the metadata problems.
For egress, PMD would still need to do a lookup as, the mark ID would be
32 bit and has to be matched with the same in various flows. Though this
is better than what we have right now(with flows), this may still be
more costlier than "set_pkt_metadata" method.
>
> That way, PMDs that do not support egress packet matching wouldn't need to
> lie and would reject rules such as:
>
> flow create X egress pattern ip / udp / end actions whatever / end
>
> But would accept:
>
> flow create X egress pattern mark is 42 / end actions whatever / end
>
> PMDs could also support combinations (remember the position of meta items
> within a pattern is not significant) to only perform whatever for UDPv4
> packets marked with 42. Non-marked packets would go through unmodified:
>
> flow create X egress pattern ip / udp / mark is 42 / end actions whatever / end
>
> This is just to point out how leveraging meta pattern items on egress is one
> possibility using MARK as an example.
>
next prev parent reply other threads:[~2018-01-05 6:19 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-23 15:12 [dpdk-dev] [PATCH 1/2] examples/ipsec-secgw: fix missing ingress flow attribute Nelio Laranjeiro
2017-11-23 15:12 ` [dpdk-dev] [PATCH 2/2] examples/ipsec-secgw: add target queues in flow actions Nelio Laranjeiro
2017-11-29 12:30 ` Anoob
2017-11-29 12:50 ` Nelio Laranjeiro
2017-11-30 10:46 ` Anoob
2017-11-30 12:28 ` Nelio Laranjeiro
2017-12-01 15:04 ` Anoob Joseph
2017-12-01 16:26 ` Nelio Laranjeiro
2017-12-04 14:11 ` [dpdk-dev] [PATCH v2 1/2] examples/ipsec-secgw: fix missing ingress flow attribute Nelio Laranjeiro
2017-12-11 11:50 ` Radu Nicolau
2017-12-04 14:11 ` [dpdk-dev] [PATCH v2 2/2] examples/ipsec-secgw: add target queues in flow actions Nelio Laranjeiro
2017-12-07 9:47 ` Anoob
2017-12-07 12:22 ` Nelio Laranjeiro
2017-12-08 14:00 ` Anoob
2017-12-08 14:40 ` Nelio Laranjeiro
2017-12-08 16:40 ` Anoob Joseph
2017-12-11 8:21 ` Nelio Laranjeiro
2017-12-11 9:00 ` Anoob
2017-12-11 14:04 ` [dpdk-dev] [PATCH v3 1/2] examples/ipsec-secgw: fix missing ingress flow attribute Nelio Laranjeiro
2017-12-12 7:14 ` Anoob Joseph
2017-12-11 14:04 ` [dpdk-dev] [PATCH v3 2/2] examples/ipsec-secgw: add target queues in flow actions Nelio Laranjeiro
2017-12-12 12:43 ` Anoob Joseph
2017-12-12 13:44 ` Nelio Laranjeiro
2017-12-12 14:04 ` Anoob Joseph
2017-12-12 14:38 ` Nelio Laranjeiro
2017-12-13 6:41 ` Anoob Joseph
2017-12-13 10:02 ` Nelio Laranjeiro
2017-12-13 11:38 ` Anoob Joseph
2017-12-13 12:53 ` Nelio Laranjeiro
2017-12-13 13:53 ` Anoob Joseph
2017-12-13 14:47 ` Nelio Laranjeiro
2017-12-20 16:19 ` Boris Pismenny
2017-12-21 8:06 ` Anoob Joseph
2017-12-21 10:12 ` Boris Pismenny
2017-12-21 14:22 ` Adrien Mazarguil
2018-01-05 6:18 ` Anoob Joseph [this message]
2018-01-09 12:48 ` Nelio Laranjeiro
2018-01-10 6:21 ` Anoob Joseph
2018-01-05 5:52 ` Anoob Joseph
2017-12-14 15:14 ` [dpdk-dev] [PATCH v4 1/3] examples/ipsec-secgw: fix missing ingress flow attribute Nelio Laranjeiro
2017-12-14 15:14 ` [dpdk-dev] [PATCH v4 2/3] examples/ipsec-secgw: add target queues in flow actions Nelio Laranjeiro
2017-12-18 8:23 ` Anoob Joseph
2017-12-18 9:57 ` Nélio Laranjeiro
2017-12-14 15:14 ` [dpdk-dev] [PATCH v4 3/3] examples/ipsec-secgw: add Egress " Nelio Laranjeiro
2017-12-15 9:05 ` Anoob Joseph
2017-12-15 13:53 ` Nelio Laranjeiro
2017-12-15 15:39 ` Anoob Joseph
2017-12-15 16:53 ` Nelio Laranjeiro
2017-12-15 17:01 ` Anoob Joseph
2017-12-18 10:24 ` [dpdk-dev] [PATCH v5 1/3] examples/ipsec-secgw: fix missing ingress flow attribute Nelio Laranjeiro
2018-01-18 14:50 ` De Lara Guarch, Pablo
2017-12-18 10:24 ` [dpdk-dev] [PATCH v5 2/3] examples/ipsec-secgw: add target queues in flow actions Nelio Laranjeiro
2017-12-19 6:22 ` Anoob Joseph
2017-12-18 10:24 ` [dpdk-dev] [PATCH v5 3/3] examples/ipsec-secgw: add Egress " Nelio Laranjeiro
2018-01-08 16:13 ` De Lara Guarch, Pablo
2018-01-16 16:12 ` Nicolau, Radu
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=6de0bb26-11dc-f7b3-cc87-dd1f3a00723c@caviumnetworks.com \
--to=anoob.joseph@caviumnetworks.com \
--cc=adrien.mazarguil@6wind.com \
--cc=aviadye@mellanox.com \
--cc=borisp@mellanox.com \
--cc=dev@dpdk.org \
--cc=jerin.jacob@caviumnetworks.com \
--cc=liranl@mellanox.com \
--cc=narayanaprasad.athreya@caviumnetworks.com \
--cc=nelio.laranjeiro@6wind.com \
--cc=radu.nicolau@intel.com \
--cc=sergio.gonzalez.monroy@intel.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
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).