From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f180.google.com (mail-wr0-f180.google.com [209.85.128.180]) by dpdk.org (Postfix) with ESMTP id E969F28EE for ; Thu, 30 Nov 2017 13:27:58 +0100 (CET) Received: by mail-wr0-f180.google.com with SMTP id o2so6396835wro.5 for ; Thu, 30 Nov 2017 04:27:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=7HXI/O7F3+dUAZCqodAMAr5pC3EZFM1YxtSnBa5PmTA=; b=0+4F8ixOXzd+d916oFU84KhNfY1HwCSRfNxOts49FdjJ6E4TGJRlj3Rcbp9x0QSSLY YYZAmDugNwpNmevIw+BJEtSmrfecaC4E1cML+fkG3RwjpDHX/JNoT6+Lu7Q5pfPoicBe dt8NeIlApQliFc1D9pLmlOtyqtTBP9HqTQf/h6aqHItZOp4lNmT7jGK+IUIucOt1o1Mt lRRq9NQwxgVmhDvQBLCuVBdAgTPmS7P8p+nImiZ5vKXTR/uClsf4FNxFBGBCqsi5S+NE 3beA+73L516gRuC1fkaotlDXRpf6ys3Nuz9ooeIjnWD3u3kPx+e8xTdWFQ42lNi+6VeB JZYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=7HXI/O7F3+dUAZCqodAMAr5pC3EZFM1YxtSnBa5PmTA=; b=YSD9KR+hkiksDQYpX+CYl8X+vg0cIoCSBAhrfKCYYce9Ayg6Izi9sT1PGpH5lOrUMc K1vKIyWDCiCpdH1qFuyL4N92WujidQ9CZhkzHwJzH12pSRLs0/7UY4NmRETvAl2dmjWq dLY8wHRUp/DWYNnvhtcszZndWisueizZyZ4de1jk6i4MxhKCJEJWpAWWfaHlKsMJG0hW RgULyYe4NNYUgoYmNnM5sriN1FkZbDdeVTqgkTv2nDU9n+KPUtyEOLAHh4elCzl3EUDS pWjMiVstsH/bjCk1g/tIgdbEY9xfxZDB9u/5drN/wDU+LULXPI2UFtYtpddPfMrz8YpT TjSg== X-Gm-Message-State: AJaThX62U8/8QF5zzyXYboO4k74Hyc5Ls/QOocY0k95FTxmaR5PvinoJ YZ1CnoRIiyiPOyNViLArqXqM X-Google-Smtp-Source: AGs4zMbgkE/W8wEV7N4VVXvc1Cc0ztkspyXWxg1xTRHVgaYWZ6rrgQEpQaJyYoLEBDq257pnEdyMNw== X-Received: by 10.223.166.103 with SMTP id k94mr1868201wrc.22.1512044878631; Thu, 30 Nov 2017 04:27:58 -0800 (PST) Received: from laranjeiro-vm.dev.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id c2sm5174345wrg.57.2017.11.30.04.27.57 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 30 Nov 2017 04:27:58 -0800 (PST) Date: Thu, 30 Nov 2017 13:28:00 +0100 From: Nelio Laranjeiro To: Anoob Cc: Sergio Gonzalez Monroy , Radu Nicolau , dev@dpdk.org, Narayana Prasad , Jerin Jacob Message-ID: <20171130122800.2cotiud5rdcaqzkm@laranjeiro-vm.dev.6wind.com> References: <6ac80a2be156911ee35c894924a02f04c43f49fc.1511449894.git.nelio.laranjeiro@6wind.com> <532499c2-b00e-870e-625d-9aa13302a8a3@caviumnetworks.com> <20171129125045.lqfs6xmqradolz4x@laranjeiro-vm.dev.6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [PATCH 2/2] examples/ipsec-secgw: add target queues in flow actions X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 12:27:59 -0000 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. 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