From: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
To: Anoob Joseph <anoob.joseph@caviumnetworks.com>
Cc: Adrien Mazarguil <adrien.mazarguil@6wind.com>,
Boris Pismenny <borisp@mellanox.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: Tue, 9 Jan 2018 13:48:20 +0100 [thread overview]
Message-ID: <20180109124820.6t2cawqb5ot7difc@laranjeiro-vm.dev.6wind.com> (raw)
In-Reply-To: <6de0bb26-11dc-f7b3-cc87-dd1f3a00723c@caviumnetworks.com>
Hi Anoob,
On Fri, Jan 05, 2018 at 11:48:50AM +0530, Anoob Joseph wrote:
> 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.
It depends on how you implement it, it can be a simple table using it as
an index, it can be a simple hash based on the tunnel informations,
etc...
set_pkt_metada() has two issues:
1. it is device specific [1] as described in the API. For an
application it is unusable.
2. it is a function called per packet which is costly and don't give
any benefit for an application which can directly store the pointer
in the mbuf without calling such function.
> > 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.
> >
Regards,
[1] https://dpdk.org/browse/next/dpdk-next-crypto/tree/lib/librte_security/rte_security.h#n331
--
Nélio Laranjeiro
6WIND
next prev parent reply other threads:[~2018-01-09 12:48 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
2018-01-09 12:48 ` Nelio Laranjeiro [this message]
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=20180109124820.6t2cawqb5ot7difc@laranjeiro-vm.dev.6wind.com \
--to=nelio.laranjeiro@6wind.com \
--cc=adrien.mazarguil@6wind.com \
--cc=anoob.joseph@caviumnetworks.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=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).