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
