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

Nelio Laranjeiro nelio.laranjeiro at 6wind.com
Thu Nov 30 13:28:00 CET 2017


Hi Annob,

On Thu, Nov 30, 2017 at 04:16:23PM +0530, Anoob wrote:
> On 11/29/2017 06:20 PM, Nelio Laranjeiro wrote:
> > Hi Anoob,
> > 
> > On Wed, Nov 29, 2017 at 06:00:38PM +0530, Anoob wrote:
> > >     Hi Nelio,
> > > 
> > >     Since support of RSS with inline crypto/protocol is hardware
> > >     implementation dependent, it would be better if there is some sort of
> > >     capability check before setting the flow parameters in the application.
> > > 
> > >     If the hardware doesn't support RSS with inline processing, then the RSS
> > >     flow action will have to be ignored in the driver. This wouldn't look
> > >     right from application's point of view. And also the PMD would need
> > >     application-specific logic to handle such cases, which may not scale well.
> > There is a real issue here, RTE_FLOW API needs a terminal action, security is
> > not one [1] you must have one of the followings: QUEUE, DROP, RSS, PF,
> > VF or PASSTHRU.
> > 
> > Flow API does not work with "capabilities" as the application can verify
> > the rule using the validate().  If it cannot be validated the
> > application can test another kind of rule until the PMD returns a
> > success.
> > 
> > Here, I am proposing the RSS as RSS with a single queue is equivalent to queue.
> > 
> > On Mellanox NIC we need the RSS or QUEUE in ingress and for Egress PASSTHRU
> > is good.
> > 
> > What are your needs?
> Thanks for the clarification. Understood the issue here. On Cavium hardware
> SECURITY will be terminating.

You should finalise with PASSTHRU to be compliant with the API,
otherwise application makers won't understand why it does not work
according to the API implementation.

> So a better approach would be to first check from the application
> (using rte_flow_verify()) if SECURITY is terminating action. If it
> fails, then application can do RSS/QUEUE. That should solve
> the issue.
<snip>

I think we have an agreement here, in order the final action to be
tested:

 1. PASSTHRU
 2. RSS
 3. QUEUE

If those 3 fails, the functions fails to create the rule, the first
succeeding is the one applied.

Do you agree?

Thanks,

-- 
Nélio Laranjeiro
6WIND


More information about the dev mailing list