[dpdk-dev] [PATCH v3 2/2] examples/ipsec-secgw: add target queues in flow actions

[Adrien Mazarguil]

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.

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.

-- 
Adrien Mazarguil
6WIND