From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0043.outbound.protection.outlook.com [104.47.34.43]) by dpdk.org (Postfix) with ESMTP id 17C587D19 for ; Fri, 5 Jan 2018 06:52:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wmPFOVx4+i8pTk4LmE2qmQrh+Aax7hb60eKjYnB64vI=; b=cJk0VPH6FcCApabMHUs0nu5kJyejWgPLqtIq9jlzfGO36dJDOKcQIkJiS3sVRoEDs8TXfz67lQK8WOvX1hxx1OHlWGi9FgDK1kZORAkj/ZTj8ZmjfUKj4zTST9si1nB4RhvhzlMgf39ZXBVIT/MWaPe0E8QGNvEaJVSdkLR4zSQ= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Anoob.Joseph@cavium.com; Received: from hyd1ajoseph-dt.caveonetworks.com (115.113.156.2) by CO2PR0701MB1062.namprd07.prod.outlook.com (10.160.8.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.5; Fri, 5 Jan 2018 05:52:10 +0000 Cc: anoob.joseph@caviumnetworks.com, "dev@dpdk.org" , Jerin Jacob , Narayana Prasad To: Boris Pismenny , =?UTF-8?Q?N=c3=a9lio_Laranjeiro?= , Sergio Gonzalez Monroy , Radu Nicolau , Aviad Yehezkel , Liran Liss References: <5d3fdd0c05d5f8afd3f8e38ca03eaf25187d5c98.1513000931.git.nelio.laranjeiro@6wind.com> <5777791b-3dd6-f746-aa37-d572c108f042@caviumnetworks.com> <20171212134456.4x3uaus2poovddlf@laranjeiro-vm.dev.6wind.com> <20171212143800.ggdtdfnbknttr45g@laranjeiro-vm.dev.6wind.com> <047cadcf-13dc-5368-4ad5-a27ff25c42f8@caviumnetworks.com> <20171213100237.uvpbg2qewhxqgaln@laranjeiro-vm.dev.6wind.com> <817bec1f-4bff-ebdc-07b4-f8f24ec2084a@caviumnetworks.com> <20171213125353.2zyllxk7pwkncm76@laranjeiro-vm.dev.6wind.com> <577d100a-d021-1219-89e3-721e02b77b90@caviumnetworks.com> <20171213144710.tyqvcvpkrymzqriv@laranjeiro-vm.dev.6wind.com> <3a91e865-ca96-09d4-b842-7e5d0a5ad6e1@mellanox.com> From: Anoob Joseph Message-ID: <0a07d09f-0797-fb4a-7f32-13afefed3fa6@caviumnetworks.com> Date: Fri, 5 Jan 2018 11:22:05 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <3a91e865-ca96-09d4-b842-7e5d0a5ad6e1@mellanox.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [115.113.156.2] X-ClientProxiedBy: DM5PR1601CA0002.namprd16.prod.outlook.com (10.174.111.15) To CO2PR0701MB1062.namprd07.prod.outlook.com (10.160.8.141) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7a7028ba-24a0-41eb-4288-08d5540078a4 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(7168020)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307)(7153060); SRVR:CO2PR0701MB1062; X-Microsoft-Exchange-Diagnostics: 1; CO2PR0701MB1062; 3:U6796v5RYdxRGySADeqGnRpbP7XlXEiJD5v2w8oijQUYn+2F4npwTAsZ97eGsNcXLeB54i+oe/CB9jnXXRGmbe0oXPioNB+vIn6fl8tS2NUVU3ZcUMWKAOCJuzlB166DOYWdmBEOqo2VTqFWjCtwgVn2PPEhCpSlc+bj9+x0YPmHb9fQj/lOQiLTRHb7ccJ565GeeJVFnFhiPLX1mcTuaQqV/MWRib7NwmpVjQMp6rr+H0gV5m4f/377iXIgqiO7; 25:JvN8gEa44SHI/GH65c5jgeZsB0+Oc/KkzhqUfFDTTGqnVWmSxZyUZ0YDD2xEuG1cu6uGDyz3AjKaM/kj7ggzQydSX5yIa6jMZaQJI6OHnqjoZG+j/osBHZpUKR+PtD8lx/nDC4vvtU5Db0Z/NEFk/9WoG86iPXwbXKTErx8TESpXDHTdwVtLlj/Z4IuB7w9a/f2Hv2jDdKs4l7wh7sSr0ugjRSiA7cxtrsYDO2Z/bXBMqAbjbyU6R2fvgOBQUcaesfSFZIpIauJyh1ZcpXT1fZCEqTm9RTmAzZD2xIbKVmiFnC3F+ixdrgavRi0A9SlYA1GSDk/jeunG2Vf60mL7nA==; 31:NTmr4chbxAl7/t/BGKxBUXNTTw6/zD9lXwBxRyyPV9/I14RxirvPGTEU/V0oLjx5yDSEut322Lm4X6Sv/jqUz7S6OOzOFYSVzH1j1FWGOjL25clrKMXwmx1xTGZTqi27FvxR2ZQ1Ni8ldiUhIppXGf1ArOshEDJNUUWghvtgbt3dX3PuoVhjJEvjWLmeSyx3fo54aGfWauegXnZ9a2Cdocr457bycHv02zuD1S2cgXQ= X-MS-TrafficTypeDiagnostic: CO2PR0701MB1062: X-Microsoft-Exchange-Diagnostics: 1; CO2PR0701MB1062; 20:bfj53DC+URALS0otiPCq1VdYyeXK5dTGlsngYLv5zSPMKuy9ZgyA4f6mzOKElyk7cFTjTMTO/OhBPiQNcaHasheS0+RPmSYa/vx9GQDmCQQpDnAjxMwGiYv2NgmFMZFVmMA3udR8jb6FAQBog3/72grC7/KRGXWtzaC6hc3ynZz6eWc1irgTR+ko7hMKNqgMuh8OTJLT4kt7RHKGTa98PFR9c1MnSAalwsdBTWrn4dWVdxhUKWM8dViC6qznaRym59N2N6+LiU2KtCo0WLLmrtTsq+7KmBmvzbadUU9J2k0QZwD/ibYrwAR08ZxwUK8eCA760uKlO2QuISTlQgEmB6ObDaZJeiRyHmO5Ql2l7jZDUj/vwCrwzHnAyx4vP34p50T+Nd7DrPOVcTpVLSJUBOD84jZfU9bX4Xjg+Sb02+DI1heyVRmn2llj9ZdKG/9uyUwJ1oIe6vgiJnVrSowbKB//6qwoJV3y+uZovjtkF9bfQMo3ZNwtEMhpSGHj+betwK8wOOx0pTN0Fc460CuKAf5QF/1Mvj9Dgb+HQyCQly0N4hwncAUQ/xfh1ed42ua9IGYItxqf22FZ/vre/oh+fF0qvti1+Xckv9sskI2p4hs= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(192374486261705)(17755550239193); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(93006095)(3231023)(944501075)(3002001)(10201501046)(6041268)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:CO2PR0701MB1062; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CO2PR0701MB1062; X-Microsoft-Exchange-Diagnostics: 1; CO2PR0701MB1062; 4:xK1SLCanHgGzK+U9oPwq22bYG+ggOWBm207tB/v01SsWjVW3aiP8z7OEObrZ62VmvhpIRz2jeHPq/rzgCEuPSDeWajwIAUtXSHdfdFD0ejAIUdsVhE+q/uCDQzEvacUv9acMqcL/6UtfMM2E9HkBEzFXOB8Dd7Zs0RaW1H+6D+5wZFpuJQt+WSZ+EjaMMyUWdT1UrkjOymO5/0UA42al7ezEXrDhemk2GL817ZGy/kdmsERn1RxmiMU4GlSg6xz2+R4nbQXcWUPN07367BXZXEUoz6E36B3Opi9jFrBIhwhMWlWqQ+8yKfb848mSKz0pJMh9UOGaYpeZWv8J92rCQyCcSV96WIEMiI9/rm0CAPHOAb4wBe3ChQl1pKoa3AMw X-Forefront-PRVS: 05437568AA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(376002)(396003)(366004)(39850400004)(39380400002)(346002)(51444003)(52314003)(24454002)(189003)(199004)(81166006)(53416004)(106356001)(65826007)(6246003)(4326008)(31686004)(316002)(6486002)(107886003)(50466002)(72206003)(2486003)(81156014)(478600001)(52146003)(97736004)(31696002)(23676004)(5660300001)(2870700001)(58126008)(25786009)(8676002)(6666003)(3846002)(6116002)(7736002)(76176011)(305945005)(47776003)(67846002)(36756003)(16526018)(229853002)(42882006)(52116002)(55236004)(105586002)(53546011)(110136005)(8936002)(2906002)(69596002)(53936002)(68736007)(6506007)(6512007)(83506002)(66066001)(386003)(65956001)(65806001)(59450400001)(2950100002)(93886005)(64126003)(54906003); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR0701MB1062; H:hyd1ajoseph-dt.caveonetworks.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDTzJQUjA3MDFNQjEwNjI7MjM6djVKU1dvTGgweldKb0NxLzZHd3ZXR0Jl?= =?utf-8?B?WjI0VWZrc0lXZVBhTjBPMjRoL09YbHF2VFJnT0VQU01maHl5MEp3cVp0QjRV?= =?utf-8?B?K1hweVNoRnljTnFyNit5RGdlOGVWVzFON3plbm1HVFlZbmRSVHZyY25LZjl3?= =?utf-8?B?Z3hhblpzMVBVYjhaZnhMWkJBclBTZ1dUMHZ1NzNqSDN3clExK09mU3gyWkJK?= =?utf-8?B?UUh3bW5NaDE4V2RMMVNYKzN4Y2FPdmR1akRreFRKSkZuQk4wd21hQlg2MUJ0?= =?utf-8?B?ZGlsR0lYV0c4TStGdk54UUY4UmMyTlZNWmFzYXR1NGhaeVBkL0xDNjBVUjVo?= =?utf-8?B?SWJkemxPSnBFZVV5M3c2OHNXOFBYTVQwbVc0eTFYVVNSeGdWTXZDcTliR1pG?= =?utf-8?B?dDdkWXFLWk40RkxLMnFJT2YxMGtRdTROenhxQmZ0VGZKUFA4eUZaaUVXUTlj?= =?utf-8?B?Z3ZxZ2U0Ty9vbXdIWDdySDByc2x3UHByQ29Gc0FhOUgzemMrU3FrM2lyUDRF?= =?utf-8?B?bUlxQ1Z6YkUzNGIvOWhlRGFwQ3JBSTU0bjlxRW03aTRQQnZucEFDaTJnUW8v?= =?utf-8?B?ZnlJanAwaGFRVU5VRTVsdXBLNzVXbVZkL0M2M0NLUXJ5eHYrWGpGWHpoc28y?= =?utf-8?B?L21sWk1VaGF6RlQ3Z3NCd3NjU2hydzdaWGFYc1VMTXdnRU40NGtUMlNPT2xI?= =?utf-8?B?c0dtTHlIemhtZVRiL3ZtbDMzeXNMdHgrWE10TDVTZUxLdHlGNEpGR21YQllC?= =?utf-8?B?Sjh3NFpOeUpIQTJYaFQ4QU4yY2RjS0U4WWh5bS90N0I5ZGhVeCtFUUdKcXNj?= =?utf-8?B?cUdyYjdWYXM5OHhybnlnYUhPM1Q2b1FSMU1tdDFoalR6Q1AxVE9VclpRend0?= =?utf-8?B?K2c0SEUrQnlKZGt3U280emRyWUJvYjhlWERKNUlXL0hjTFhZb3RPTW5PeVpj?= =?utf-8?B?NkFNdHNMdTMwT0JGRkhOVkFHNE8xd2hjSHorWmpOL1hMSTJpRmJYNzExTHJ0?= =?utf-8?B?WWVvVEcxdC9BVG15MmlxdmJBaTZGcGRGNGFEL0Y1eUwrU3JWcW1mNy9tT3Q2?= =?utf-8?B?a2YyZU5wdG4wNG4vb2owZ1ZRRUJDM3IwZVU5aTJQOEdMVS9DbysraTBTOXlv?= =?utf-8?B?VVlYM3dYeHo5K3NTL202dGVJZERpdUMzVGs5dnk0RXJTMzd4OHhrQXNXRmZ1?= =?utf-8?B?eWltbTBQRHJrRGwyRmRKSVJoeUVEV2J1TXErTW91Uk9aZ1E1b1dlYzZKVmhp?= =?utf-8?B?L2sybEVBYm9ReG9aejNxODRLQnBpQVhyU0xQeTNXaFZqWWl4MlQ2ZFhIbWll?= =?utf-8?B?WWpQb2RwT292OHpjSVBTckhFbk1JejM4Q28rekVOMnNoTnFJei9TMDdtT0xH?= =?utf-8?B?eS9tWjdlWlREcUZiaWNrMXd6QUgveU1hL01BSGZUdm1pYkk0YXRZZkt3dG5n?= =?utf-8?B?OFdlOXVwelozUmIxL21neG1pNTlWL09FM3NxeFFoR0ZmeGN3NTY3Q3krRUF4?= =?utf-8?B?LzZhcGtIWFlJTmpiQWRoQndnRTB4dVBhcEp3QkRsWkJkZGdPNmZrZEw0alJ4?= =?utf-8?B?TzdpRkFJWVgxQ3QzMVJmL2hpcU9peE9BQ3VXNjNTYkI0RmJwSGRaRUE0bzB3?= =?utf-8?B?eVE1RDVMS3hLSHNSQlg2QVBoSjgrOU5aNHBpanZqcDFuTERvSERJNmp3cTdT?= =?utf-8?B?QTY5TGVybm84akU1VFNDRWNKUmZTL2k4VE9EaytYS01JQnI1cTVkVU1qYUE5?= =?utf-8?B?Q0N5RFFkV2ZhMkJsQW5mdlVVZzVzSGFlOGRranNCTStMS1dWMVFzRlFWeFc1?= =?utf-8?B?aDRXRS9lUVVqbkxvcVVTaVhLOTJ4ZDRGRFdCY25lK2xFQklObHpmbUZPNmtk?= =?utf-8?B?NmtrTUx6K3NIaTlnUVpoWFBzL3gzaW1RczdWeFlOOW5GRVdQSU9qWFIvUVQy?= =?utf-8?B?YU51em1US3A0eWt0V1k4NzdGVDViU0E5YmNXNFBWREVPdzhFeStobXRMUGpI?= =?utf-8?B?Yi85aEx3dTBCQk5tWklFUUVxNFd1RWpzTmRpMmZTL2lNdkpzRVpnMVgzYmJp?= =?utf-8?B?S1VxMURwY2Y3WmV3VktaOWZUVEhHMW53NWtweGVoNTdVMm9sZytMMHJqU3B2?= =?utf-8?Q?V2su89QLfZmkuQmEzUdOLjyUc=3D?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR0701MB1062; 6:W3Xj5jpn2HDXxpjyJcAiGy/ZJsc5J8T63jP2/2Pv7HcrZ+eIfkcEfbSkcN0c6wifApaLKM9Uskr0nY8l4T1OaoUUXy69NzvZ5sSXabimiU6kuNrhC6df6sJFpbWYKMNVoYQo/Xb98GEWFKelq4Q5autSzmWqOO+nI3/ey1fEXpwSzBsfjglUPloMBmnT7Wqd7Q2IVMW5m2vMie1GA6GMtFZm8B5mcKzCpbOQiiSc007OCh6UuZ2PDo/Px9tMLEnkuC5vSwfK1ZIJCnABfBlCrRJG8CvpD9kUJPmVuaI9+SbZanUV3j29bjlg+VC8U+6A8N2WYDx0EegCBzOVgeBCq4FP86SvOJ7Qjy7rK3L+2xo=; 5:sH2xV+Rucm9AYa3i7Awu0N8qgPZFoDootL5Bdf60a/2/OO2QzZ5NScffz4GcQVr3Dzg4aBUWzz74fd8C0zfZIaAcm63Gj0K7PSBkvwN+Hu1FoxHBIck30+o3WIksefYlBlDYJnMZuew6yDv7kM+DTxynIi/4Tp4IQa9NXIgd940=; 24:It7S9HGK0ds22XrIXgeKAsDo+PW12QRbDFOK0OTigtuvScNFaepQiKopq4FD4eW9h9xU0AqCnuKu6LZoNLHkmsHc5WYHUZdpYzSDl1ZpJQM=; 7:IFJ8P4Nw3bA0OGSer1Dx6ujNVszkH9PIsbRDfqjO6baLJc+bzS5SXJdWv2NuNJaUhceQIoPMrn6R/TS7G0OECtZINepNiP7087HCYzA7Bvq4Gw1JX8Pdgq37kniYCqNPDZdkrgEdZBKbVHTVJ+PmpMsdtnyG7pDa/SzY5YQkaM2hZwB7cTVia9dCHJ9rn74q3Zgkk+c4pkOTWtjgC5RTJ70PhM0grFIxtvMEAWzbJKOlCSy5BcnrNr0ItrEZpJ0f SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jan 2018 05:52:10.7151 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7a7028ba-24a0-41eb-4288-08d5540078a4 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR0701MB1062 Subject: Re: [dpdk-dev] [PATCH v3 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: Fri, 05 Jan 2018 05:52:18 -0000 Hi Boris, On 12/21/2017 03:42 PM, Boris Pismenny wrote: > Hi Anoob, > > > On 12/21/2017 10:06 AM, Anoob Joseph wrote: >> HI Boris, >> >> >> On 12/20/2017 09:49 PM, Boris Pismenny wrote: >>> Hi, >>> >>>> On Wed, Dec 13, 2017 at 07:14:19PM, Nelio Laranjeiro wrote: >>>> >>>> Hi, >>>> >>>> On Wed, Dec 13, 2017 at 07:23:19PM +0530, Anoob Joseph wrote: >>>>> Hi Nelio, >>>>> >>>>> >>>>> On 12/13/2017 06:23 PM, Nelio Laranjeiro wrote: >>>>>> Hi Anoob, >>>>>> >>>>>> On Wed, Dec 13, 2017 at 05:08:19PM +0530, Anoob Joseph wrote: >>>>>>> Hi Nelio, >>>>>>> >>>>>>> >>>>>>> On 12/13/2017 03:32 PM, Nelio Laranjeiro wrote: >>>>>>>> Hi Anoob, >>>>>>>> >>>>>>>> On Wed, Dec 13, 2017 at 12:11:18PM +0530, Anoob Joseph wrote: >>>>>>>>> Hi Nelio, >>>>>>>>> >>>>>>>>> >>>>>>>>> On 12/12/2017 08:08 PM, Nelio Laranjeiro wrote: >>>>>>>>>> Hi Anoob, >>>>>>>>>> >>>>>>>>>> On Tue, Dec 12, 2017 at 07:34:31PM +0530, Anoob Joseph wrote: >>>>>>>>>>> Hi Nelio, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 12/12/2017 07:14 PM, Nelio Laranjeiro wrote: >>>>>>>>>>>> Hi Anoob, >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Dec 12, 2017 at 06:13:08PM +0530, Anoob Joseph >>>> wrote: >>>>>>>>>>>>> Hi Nelio, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 12/11/2017 07:34 PM, Nelio Laranjeiro wrote: >>>>>>>>>>>>>> Mellanox INNOVA NIC needs to have final target queue >>>>>>>>>>>>>> actions to perform inline crypto. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Signed-off-by: Nelio Laranjeiro >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> >>>>>>>>>>>>>> Changes in v3: >>>>>>>>>>>>>> >>>>>>>>>>>>>>        * removed PASSTHRU test for ingress. >>>>>>>>>>>>>>        * removed check on configured queues for the queue >>>> action. >>>>>>>>>>>>>> Changes in v2: >>>>>>>>>>>>>> >>>>>>>>>>>>>>        * Test the rule by PASSTHRU/RSS/QUEUE and apply the >>>> first one validated. >>>>>>>>>>>>>> --- >>>>>>>>>>>>>>        examples/ipsec-secgw/ipsec.c | 57 >>>> ++++++++++++++++++++++++++++++++++++++++++-- >>>>>>>>>>>>>> examples/ipsec-secgw/ipsec.h |  2 +- >>>>>>>>>>>>>>        2 files changed, 56 insertions(+), 3 >>>>>>>>>>>>>> deletions(-) >>>>>>>>>>>>>> >>>>>>>>>>>>>> diff --git a/examples/ipsec-secgw/ipsec.c >>>>>>>>>>>>>> b/examples/ipsec-secgw/ipsec.c index >>>>>>>>>>>>>> 17bd7620d..1b8b251c8 100644 >>>>>>>>>>>>>> --- a/examples/ipsec-secgw/ipsec.c >>>>>>>>>>>>>> +++ b/examples/ipsec-secgw/ipsec.c >>>>>>>>>>>>>> @@ -142,6 +142,7 @@ create_session(struct ipsec_ctx >>>> *ipsec_ctx, struct ipsec_sa *sa) >>>>     rte_eth_dev_get_sec_ctx( >>>>>>>>>>>>>> sa- >>>>> portid); >>>>>>>>>>>>>> const struct rte_security_capability >>>>>>>>>>>>>> *sec_cap; >>>>>>>>>>>>>> +            int ret = 0; >>>>>>>>>>>>>>                    sa->sec_session = >>>> rte_security_session_create(ctx, >>>>>>>>>>>>>> &sess_conf, >>>> ipsec_ctx->session_pool); @@ >>>>>>>>>>>>>> -201,15 +202,67 @@ create_session(struct ipsec_ctx >>>> *ipsec_ctx, struct ipsec_sa *sa) >>>>>>>>>>>>>> sa->action[0].type = >>>> RTE_FLOW_ACTION_TYPE_SECURITY; >>>>>>>>>>>>>> sa->action[0].conf = sa->sec_session; >>>>>>>>>>>>>> -            sa->action[1].type = >>>> RTE_FLOW_ACTION_TYPE_END; >>>>>>>>>>>>>> - >>>>>>>>>>>>>>                    sa->attr.egress = (sa->direction == >>>>>>>>>>>>>> >>>>     RTE_SECURITY_IPSEC_SA_DIR_EGRESS); >>>>>>>>>>>>>> sa->attr.ingress = (sa->direction == >>>>>>>>>>>>>> >>>>     RTE_SECURITY_IPSEC_SA_DIR_INGRESS); >>>>>>>>>>>>>> +            if (sa->attr.ingress) { >>>>>>>>>>>>>> +                uint8_t rss_key[40]; >>>>>>>>>>>>>> +                struct rte_eth_rss_conf >>>> rss_conf = { >>>>>>>>>>>>>> + .rss_key = rss_key, >>>>>>>>>>>>>> +                    .rss_key_len = 40, >>>>>>>>>>>>>> +                }; >>>>>>>>>>>>>> +                struct rte_eth_dev >>>> *eth_dev; >>>>>>>>>>>>>> + union { >>>>>>>>>>>>>> +                    struct >>>> rte_flow_action_rss rss; >>>>>>>>>>>>>> + struct { >>>>>>>>>>>>>> +                    const struct >>>> rte_eth_rss_conf *rss_conf; >>>>>>>>>>>>>> + uint16_t num; >>>>>>>>>>>>>> +                    uint16_t >>>> queue[RTE_MAX_QUEUES_PER_PORT]; >>>>>>>>>>>>>> + } local; >>>>>>>>>>>>>> +                } action_rss; >>>>>>>>>>>>>> +                unsigned int i; >>>>>>>>>>>>>> +                unsigned int j; >>>>>>>>>>>>>> + >>>>>>>>>>>>>> +                sa->action[2].type = >>>> RTE_FLOW_ACTION_TYPE_END; >>>>>>>>>>>>>> + /* Try RSS. */ >>>>>>>>>>>>>> +                sa->action[1].type = >>>> RTE_FLOW_ACTION_TYPE_RSS; >>>>>>>>>>>>>> + sa->action[1].conf = >>>> &action_rss; >>>>>>>>>>>>>> + eth_dev = ctx->device; >>>>>>>>>>>>>> + >>>>     rte_eth_dev_rss_hash_conf_get(sa->portid, >>>>>>>>>>>>>> + >>>> &rss_conf); >>>>>>>>>>>>>> + for (i = 0, j = 0; >>>>>>>>>>>>>> +                     i < eth_dev->data- >>>>> nb_rx_queues; ++i) >>>>>>>>>>>>>> + if (eth_dev->data- >>>>> rx_queues[i]) >>>>>>>>>>>>>> + >>>>     action_rss.local.queue[j++] = i; >>>>>>>>>>>>>> + action_rss.local.num = j; >>>>>>>>>>>>>> + action_rss.local.rss_conf = >>>> &rss_conf; >>>>>>>>>>>>>> + ret = rte_flow_validate(sa- >>>>> portid, &sa->attr, >>>>>>>>>>>>>> + sa- >>>>> pattern, sa->action, >>>>>>>>>>>>>> + &err); >>>>>>>>>>>>>> +                if (!ret) >>>>>>>>>>>>>> +                    goto flow_create; >>>>>>>>>>>>>> +                /* Try Queue. */ >>>>>>>>>>>>>> +                sa->action[1].type = >>>> RTE_FLOW_ACTION_TYPE_QUEUE; >>>>>>>>>>>>>> + sa->action[1].conf = >>>>>>>>>>>>>> +                    &(struct >>>> rte_flow_action_queue){ >>>>>>>>>>>>>> + .index = 0, >>>>>>>>>>>>>> +                }; >>>>>>>>>>>>>> +                ret = rte_flow_validate(sa- >>>>> portid, &sa->attr, >>>>>>>>>>>>>> + sa- >>>>> pattern, sa->action, >>>>>>>>>>>>>> + &err); >>>>>>>>>>>>>> +                if (ret) >>>>>>>>>>>>>> +                    goto >>>> flow_create_failure; >>>>>>>>>>>>>> +            } else { >>>>>>>>>>>>>> +                sa->action[1].type = >>>>>>>>>>>>>> + >>>>     RTE_FLOW_ACTION_TYPE_PASSTHRU; >>>>>>>>>>>>>> + sa->action[2].type = >>>> RTE_FLOW_ACTION_TYPE_END; >>>>>>>>>>>>> We would need flow validate here also. And, for >>>>>>>>>>>>> egress, the application will be able to set metadata >>>>>>>>>>>>> (set_pkt_metadata API) per packet. So flow may not be >>>>>>>>>>>>> required for such cases. But if the flow create fails, >>>>>>>>>>>>> the session create would also fail. It might be better if we >>>> check whether the PMD would need metadata (part of the sec_cap- >>>>> ol_flags). >>>>>>>>>>>> Seems what you are describing is outside of this scope >>>>>>>>>>>> which is only related to correctly implement the generic >>>>>>>>>>>> flow API with terminal actions. >>>>>>>>>>> Since SECURITY+PASSTHRU won't be terminal, this code >>>>>>>>>>> segment might be misleading. >>>>>>>>>> Well, I don't mind adding an extra verification even if the >>>>>>>>>> create should fail if the validate fails, as there is no >>>>>>>>>> other option it is just like adding another if statement >>>>>>>>>> considering  the validate() cannot guarantee the flow will >>>>>>>>>> be created(), other errors like ENOMEM are still possible in the >>>> creation stage. >>>>>>>>> Good point. I was thinking of a scenario when flow for egress >>>>>>>>> itself would be optional. >>>>>>>>>>>> I'll suggest to add it in another patch. >>>>>>>>>>>> >>>>>>>>>>>> Anyway, the flow validate is useful in the ingress to >>>>>>>>>>>> select the best behavior RSS/Queue, if the flow validate >>>>>>>>>>>> may fail, the flow create should also fail for the same >>>>>>>>>>>> reasons. >>>>>>>>>>>> >>>>>>>>>>>>> If the driver doesn't need metadata and the flow >>>>>>>>>>>>> create fails, then the create session should fail. Any >>>> thoughts? >>>>>>>>>>>> How the create_session() can fail without having all the >>>>>>>>>>>> informations (pattern, metadata, ...) the application wants to >>>> offload? >>>>>>>>>>> Is flow mandatory for the egress traffic? My understanding is, >>>> it's not. >>>>>>>>>>> "set_pkt_metadata" API gives application the ability to do >>>>>>>>>>> the lookup and pass the info along with the packet. In >>>>>>>>>>> such cases, flow creation is not necessary. >>>>>>>>>> Some NIC need to apply a flow rule for Egress and they don't >>>>>>>>>> need metadata for the packet. >>>>>>>>> Understood. In that case, what I proposed could be a separate >>>>>>>>> patch. The ingress path is proper with this patch, but we can >>>>>>>>> keep egress open for improvements. >>>>>>>> What do you mean with "keep egrees open for improvements"? >>>>>>> In egress side, this set of flow actions won't be having any >>>>>>> terminating action. And addition of PASSTHRU won't be required, >>>>>>> as it >>>> will be implicit. >>>>>> Flow API does not define any behavior on Egress.  We have to >>>>>> define it. >>>>> Understood. >>>>>>> Creating flow for egress would allow hardware to perform the SA >>>>>>> lookup. But we cannot remove the lookup in application, as it's >>>>>>> the SA which has the information whether the packet need to be >>>>>>> completely offloaded. Once this lookup is done, this information >>>>>>> could be communicated to hardware using the set_pkt_metadata. >>>>>>> >>>>>>> This will eliminate the second lookup in the hardware. So the flow >>>>>>> could be optional. The current patch assumes flow is mandatory for >>>>>>> egress as well. >>>>>>> For Cavium hardware, egress side flow is not required and we will >>>>>>> be using "set_pkt_metadata" API. May be Radu can give his thoughts >>>> on this. >>>>>> Got it, what is missing here is a verification on the sa->ol_flags >>>>>> and only use the rte_flow for RTE_SECURITY_TX_HW_TRAILER_OFFLOAD >>>> as >>>>>> other NICs are using the RTE_SECURITY_TX_OLOAD_NEED_MDATA. >>>>> Precisely. >>>> I'll make the changes discussed here, splitting this patch into >>>> ingress/Egress >>>> and use the of_flags. >>>> >>>>>> Do you know why such difference is not hidden by the library?  It >>>>>> won't help application which will need to have different >>>>>> configuration path depending on the NIC capabilities. >>>>> I can only speculate the reasons. I think, application will have to >>>>> know the NIC capabilities as the usage of rte_flow would be a one >>>>> time >>>>> configuration while using set_pkt_metadata would be per packet API >>>>> call. If library is to hide this, it would incur unwanted checks >>>>> in the data >>>> path. >>>> >>>> Why not embedding all the configuration part necessary for all PMD >>>> (as this >>>> example is making though this modifications) inside rte_security >>>> library and >>>> in et_dev add a new Tx burst API with another array containing the >>>> metadata >>>> for the each packet. >>>> >>>> PMD who needs such metadata have it along with the packet they are >>>> processing, others can ignore it. >>>> >>>>  From an application point of view, this become transparent and >>>> friendly, one >>>> function to set the offload request, one function to send packets and >>>> another one in Rx for the symmetry if necessary. >>>> >>> The call to rte_flow is necessary both on Tx and Rx. >>> >>> The reason for using setting the flow on Tx is to provide the packet >>> header fields >>> which are required to identify the SA. This use enables >>> extensibility. For instance, >>> we could describe ESP over VXLAN simply be providing the appropriate >>> rte_flow >>> configuration. If the flow creation fails, then this is not supported. >>> A similar use-case is the use of VLANs with ESP traffic. >>> >>> I understand that it is possible to use the metadata to provide >>> applications with all >>> information. But, a user is better served by an API that indicates >>> an error when the >>> control operation is executed (e.g. rte_flow) and not during the >>> data-path (e.g. metadata). >> 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? But the documentation says pattern matching is mandatory. > 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! This would be more misleading to the application. If the flow_create is successful, the application would expect pattern matching in PMD/hardware. And in this case, PMD should lie about it's behavior when the upper application is doing inline. That also might not scale well. > > 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. Following are the two options I could think of 1) In the control path,         if (capability & HW_SUPPORTS_FLOW)               sa->flow = create_flow();         if (sa->flow == NULL && !(capability & HW_NEEDS_METADATA))               /* error */ 2) Add a new submit API (submit a packet to a flow). This effectively decouples pattern matching from performing actions on a flow. If we have submit API, we could make flow mandatory for Rx & Tx. Thanks, Anoob