From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0077.outbound.protection.outlook.com [104.47.42.77]) by dpdk.org (Postfix) with ESMTP id B6F3A271 for ; Wed, 13 Dec 2017 14:53:39 +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=oZ9d/R4/G79cfUyqiMN/L8e/6jwxMzFTHasIb8rKAxQ=; b=KkEC0mlN9fhxdF9IygjeVpk51hIY3nwPy7sdq5QN7I896JCHcq3ORNzMET92/OhT4jjdjh+gNZV3JrUS4Fe7UpagZ8WKNj1QfXho3NGYxiVw9A6kreIpU2qeJ74lXBGVLd7rOrMpkk9ubgpM+T7IL8ZKHjCRQRDI970MhfGNrPE= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Anoob.Joseph@cavium.com; Received: from hyd1ajoseph-dt.caveonetworks.com (115.113.156.2) by DM5PR0701MB3637.namprd07.prod.outlook.com (2603:10b6:4:7d::38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Wed, 13 Dec 2017 13:53:25 +0000 Cc: anoob.joseph@caviumnetworks.com, Sergio Gonzalez Monroy , Radu Nicolau , dev@dpdk.org To: Nelio Laranjeiro 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> From: Anoob Joseph Message-ID: <577d100a-d021-1219-89e3-721e02b77b90@caviumnetworks.com> Date: Wed, 13 Dec 2017 19:23:19 +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: <20171213125353.2zyllxk7pwkncm76@laranjeiro-vm.dev.6wind.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [115.113.156.2] X-ClientProxiedBy: BN6PR08CA0081.namprd08.prod.outlook.com (2603:10b6:404:b6::19) To DM5PR0701MB3637.namprd07.prod.outlook.com (2603:10b6:4:7d::38) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: da2329be-f1aa-4fd3-db40-08d54230e297 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(7168020)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307); SRVR:DM5PR0701MB3637; X-Microsoft-Exchange-Diagnostics: 1; DM5PR0701MB3637; 3:2+iJZuGUNWouCey0qBJtUyUZUdaWMPhVRyYUCwNaChyFeU7C7UJwouAyjVhKdG2eKN6hoLNalVDTOcMvMj9j5/WzA/1E8HbdypF2y/RCbRKfL76fMBog2VkVMYAz1HPTFAF11/gsjVO5zdTEsrrh7Ph6J51Ng8rmJT0bfYOkq88DcZ9oSB3QZ40LtfEUC8qI+JTzUpYxyAUm7ihuLsP/znLOgrU6+d+P3PeYAwYDolM7/P7iiONXaQ/59465Ti+1; 25:8/i6/3VTpq5RZrYvhZyrUf/5Bc5C27dni0aORW8y1e1HtnSCwuUkXYOvaX08oVzg+WMSe8LZ7iGy8AJOYPmcwRRaagtSBilvTwdYRh97ZeK74jSYiYyUfsbC9QarvTGopksR4GJWLjva9XYU+D7HNMHV77fsMm9tO9Hj5vAOy4J/bdXJmbrI9VzS9S+SeN+hxW7ZXtW28V16xeHCXVirNicKhPskdZd6mGzGAwrOq+9vajs5a8jF5HszYix/kLqGXjC/sgSejUjz2Z50fKJBOWNBgBOaZJ/E6XDh1N2eBHhvCZQRYpQ90C+2+Uh9ir0YXKsO5GhLW5CbPxPVZDlgdw==; 31:B+h1kmLsLQwzRiNtc5agvbnmzhR4LoK0xdLeuYkccfG2oOxCXP2Y/ezMMe24BSx1cWKWRz8VWo5X+/ND1GBBi1RIyKIyH4RbchHW7BJ4AP/Wlx3HAt2Djr6K9pglmz+cTYDjaz0+ppA3zkdNUBZdF7ISHnyO2KZQzfnvgsL7bHtV3RXr6eaNMcS5EGbXVM0i8pEx3ujOQxRRfuE6Vmofjp7k9J3b0ghg/sDBbSoc4F4= X-MS-TrafficTypeDiagnostic: DM5PR0701MB3637: X-Microsoft-Exchange-Diagnostics: 1; DM5PR0701MB3637; 20:leERtiJ7gqO9UZdvcyyorrynyZpk8uT8zjvHYR4PRESnx8+X+961rXMcVZzn1lv4Ufkt8jtzOsZHN3J7JraIl1xK0p8xkoOa3niSJ83RyIMp+dcub6fckCuXdcdwUyyhJeVbNAVkaRVdLlMEuwSycI3fY9Lys0Qd001tx4bmF5SUw+ItRd/hvCLp6RiRBwA49oib8XXWce89ApDJei+sCtb0rr10HdqDGLBHSmcy/InSgjQSGSm8e0J60HEt6mh9VxPQ7FJii1+B8a9b1eeCc9GUIc3REV2pZ2EmWPZG8bCZlBZRtTMGo/E6OqQ+X+JkxRtfYXonMJ3eoLCotoW7NEzKuJaInzemFnSKjzDWLxeKc/o8A1QcLPdDAiFqGFLD85JO5TBV/fn1katstQSxRiKQSLAhmEdflRG4oMKbGN9f+W3DqH+Bpp3sR9V2tn7P9I8IZyRAc9jLumDxIQfOtx3HtiHkZavyXxpNmV9SCKS216mDcVcmsK5iQFeulUq+DlVSA2zVTPOePO9LLywG0Rxs3aaYhjQ0a5OHvQ2o810QG2L4GuDpwnYGujUhln+FHmAiR3Dpisi0dzdMwuUtvt2WBOpgCBfIf024xBoBji0=; 4:ANZ1Bk1fzjVDva64zcBleYcBrkGjJjloPe7F75qjhQAgeMk7hioCTGcqDgZjPUJnztciObWGercl00v+VsEoSdJ46MpgHUkujjWbsIkWVB91PnXv02fdPeGxjEeiPT/Nk/IHULzXWJgWnBj2zwPaAhM7t5PAN1Xvx8cQgLeyjmhFad8tZ7VoHGtK50U/baz//mc1c3Lxc2op7FVNEcurQGikDiLI3IhVELKzeEYvoh2/I4jBWjIo//gfsGuV+OfW3cv/DvEJ8n+Gk4++yUQQmjXc3sv/fUpFP12m0dNucYq7Pfbi5OHmeiTpyHbhotDE X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3231023)(10201501046)(93006095)(3002001)(6041248)(20161123562025)(20161123564025)(20161123555025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DM5PR0701MB3637; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR0701MB3637; X-Forefront-PRVS: 052017CAF1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(366004)(376002)(346002)(199004)(189003)(52314003)(24454002)(229853002)(66066001)(53936002)(8936002)(65956001)(6512007)(65806001)(53416004)(105586002)(305945005)(316002)(8676002)(31686004)(64126003)(3846002)(47776003)(6246003)(36756003)(4326008)(386003)(53546011)(6506007)(81156014)(230700001)(25786009)(81166006)(6116002)(6486002)(59450400001)(69596002)(478600001)(72206003)(7736002)(54906003)(31696002)(58126008)(2906002)(5660300001)(65826007)(67846002)(50466002)(16526018)(106356001)(52116002)(97736004)(6666003)(83506002)(2486003)(76176011)(68736007)(6916009)(23676004)(2950100002)(42882006)(93886005)(55236003)(52146003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR0701MB3637; H:hyd1ajoseph-dt.caveonetworks.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTVQUjA3MDFNQjM2Mzc7MjM6bEdNZ2tlMXY3dFRGOGNwZ2R3cFZudFpj?= =?utf-8?B?VStHZGNKK2YrbGxTd1kxT21sY1ZjSUp4Z0M1dGJ3ZzlJK25udnRTYXk4Qjd4?= =?utf-8?B?MGtjRzB1QXgzclVRZndNMzdsUmJyQmdKb0xQQlluNTRyK3plOUJMdFVILyty?= =?utf-8?B?R1dWOUJKRG9sTWt3elcrd1N6QnA4dHd6eXVjYjUvdFBpWi9PL0ZjbWJkN0FU?= =?utf-8?B?NHhadFJKWVdpcUZURXlYaUVNYWpJclBXUko3OE45bkFBZVNrczUyNkNjak1O?= =?utf-8?B?L1NaNFpWSTA1VVpxSmk0QTI5NzlkVk0xdUlFTWxxVGRWM0pOKzRUWWM0a1RV?= =?utf-8?B?NmxiL2JsSm9hSkhCWStZVFB3aUpxa0RXSzlja1h5OTF2dFdrVTc0T2FzQjFO?= =?utf-8?B?dWVzSmNGQ204Z2lUNWovbDNhMm1nSCtXNWQ5M3Y3NG1pUExHaDRXYlM4WHU4?= =?utf-8?B?YXV6VllrbGxSdlBmNmpiYVEycndTWk1VUTY2b1hlZmxyREdDOGF3cGxWOG1y?= =?utf-8?B?TDNzVWRiNUdYaXU2RUt3ZlQyUzlkbDlQNWF4cDJITmVmTXYxWEswcU5jejEr?= =?utf-8?B?SUVwTFYwR0hwazBWUFY3aExxVHRiTjZZL1o5bmJ1azhBbU9jZzhKTkYzWE9U?= =?utf-8?B?NE5aSmUvMnkzdmJqTm1scHNlOVdFdzMvd0djZ3ltN0N3SkJYM3J5Ly9OdW5H?= =?utf-8?B?bHE3TlowRkJ4YTgxa1JhZ3NybnZwWER3Zy9tdWRoMDFCSm9GeXBGT3dkcWlC?= =?utf-8?B?U09Kd01DNVovWStHWUFLL3BQbjFNVGtBSzJ4WkM3TjRnYW00ZVVTZGFEK25a?= =?utf-8?B?YVVsQ1FJdTVsVkpuNG93WnN1TS9RTytMZDljbmcraWVOMGtiSmQ2V29INlR0?= =?utf-8?B?QXRLN2dMb2lEWG92aEs4N3lFRnVYVXJZN0MwTGd2bEVMQUV2UEdzTDhyV1ZC?= =?utf-8?B?cXdxNHArNEJlNHdIQVdDRTdBcTk0YVFZUU0rR01HMkZvZWhvR0MyQmw2MUN6?= =?utf-8?B?cHVKd21Fc2NBUHQvYnp5aURuRUxiem1NT0t0VmhTRHcxekM4MWlpOTR1Rk5U?= =?utf-8?B?NHFWNmc2ZGQyV2VHcGtJa1dCUktiTmZUQStVakdvZnR4Mm9sTEFsNzFlblVB?= =?utf-8?B?Q09UWEhDS3AyU003dE0raVpVdFNnWkFKM0UvQ1JhcFJJWWQwc3hmQVFwakNF?= =?utf-8?B?N2hkSDE1NFUzaG5qRXVmcktUemxjVkFRRWFrQ3NxQzNpdXdRYThhYjA3N2xK?= =?utf-8?B?bWZ5LzBUMnMzNUN4TXZ4a3p2ZDF6bk43TGdZd3c5RTl3RUc1R3FkQ3NMTGdy?= =?utf-8?B?Vk5sMVFDdzBPcHdGWWcydkViMkFqN0JzYXNXcEcvZTM1Y0JSNkNCbmRLNHJU?= =?utf-8?B?WnduWGxqV2RxU3A5MURXU0tPM3R0RGtSd1BPL2ZQYmtqbTBNbllwM1VCZ0RD?= =?utf-8?B?TW9NRmR2UFFYTWRaZ08vSzNOeFp5NERmdDd3dE0yRkM2MWVJbEtKaFpnR3cx?= =?utf-8?B?U2xDTGNXYTVjMDkyUUxiU1JlUk4vMjlVdW02c1lwSERlRU9xTXRyNjVOZDhG?= =?utf-8?B?SFlOM1dPTi9nUXpCdVlteW5JNUVNMHdyMVFYTmF4V2FPVFhXVzU0dlp2ZmRl?= =?utf-8?B?TVA5eTgwSVdPUmZSMW9HWStkNjBPYkZnU3FobnBNWE9tUWd6VktBbmpHNk1Q?= =?utf-8?B?YWJscHFlVXE2MmwwK0VlRFBoaXAwYitPalVkSTZ1SFBMWlRmaWxXWG54V2Fw?= =?utf-8?B?cktLZmYramxRZ1pQN3FrRGlkZ0FVTEg2UlZ3TVNIQWFPMVhZbW56ZnRpdjEy?= =?utf-8?B?VUNMMGZCeHlVZGszYnFsS1VVWWR6NFo1VEY5eTc5U1FCQlAwL0tDK2tadWlw?= =?utf-8?B?bXo4SUhyRnhVTys0RURsMitvcUpvbWZ4dzJzWjVFb0tHcHE4NFhvVUc5bE1S?= =?utf-8?B?VURFdDZMQkIxN0pZNy84MUlsUUFDUzlTK3AycG00YXZSQUVKT1UvQ2lSWnR6?= =?utf-8?Q?DdQZ86x8?= X-Microsoft-Exchange-Diagnostics: 1; DM5PR0701MB3637; 6:RwIJpn3PY634j0+vnqHVGqEq7fboMMCrsz2K6hhqANUYtmiWm9AaSxV1T1ysx68KCnjfeYVhKrPASyI8hzPAcvpg9rnCY1ZX4CFL0Q31pHYEbmicgl/I+N19dqQHvJezryLdjknXPIVGTKxo9nHDvhUVF+CcHevo2mSEmv1Uu+SCgQ38GZpFE+0m8VXOqAnbc4LF6ufDdJl5CfmL+s7xsXI0A19qVmiqh8xfbAak0ItX9TnwLjT6XFxFk3V8KaIRAxRFV7lVNRERD2tohZL8MiBaTQLYHEgUWblKWdk98LCRid3f6vXOhIdSPoLyy7YMf9RHvUjNwmv0Vg6Pc6jH4YXomsbDbc0vDoNg10yf8DU=; 5:TLpZM6xXjRVtaIIDdXNKmf7+2mfb9yEAwg7PNUyPUxAL0rbzqqeqkjBVZxKzH0OikqJ5zjbCxKeYugIeSTezQfXL365jOODvRBcdBpMa0dQfXYLlPRw6s4eI2rLX4MbPVLkAagh2sQK9FouH2VKV3VARTi8VRoix4gU/SWGOl18=; 24:LQ9b9J4/BkoO89PA6qCbrNcfLcaE9YBgUSr8UhtDLLSjP+gPfRZm69ViCW7pnfYKHHrAndwlNY/9SbUeBKblmqYK/G9j3KeUxXXdBzhguCI=; 7:G0SY/3h1PFjNDtDnZlaSHyHen0lYIS2PhmhiEmJ78w4ynWvuvcTXU1jjYeJMXJAcnvnn7y66aKRC/zW/MlpagHaUBU2mFs1f7fmQVOAO0RW47202Ro2E4QI3kuyw0epyOmiHicXjtyg/MoyyTaIFdljMHGjHtWc94Qu2Az93rxOxy/diGqtGi8w2gVhWbXDUiJ2zKC15LvwvnN5OFT/J0dNssdByvFZLaAtSTjF8IVG99k3xic9pn/nRFa24tPX5 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Dec 2017 13:53:25.2603 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: da2329be-f1aa-4fd3-db40-08d54230e297 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR0701MB3637 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: Wed, 13 Dec 2017 13:53:40 -0000 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. > > 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. > >>>>>> I do agree that this is outside the scope of this patch, but I was just >>>>>> curious about the behavior since you touched the topic. >>>>>>>>> + } >>>>>>>>> +flow_create: >>>>>>>>> sa->flow = rte_flow_create(sa->portid, >>>>>>>>> &sa->attr, sa->pattern, sa->action, &err); >>>>>>>>> if (sa->flow == NULL) { >>>>>>>>> +flow_create_failure: >>>>>>>>> RTE_LOG(ERR, IPSEC, >>>>>>>>> "Failed to create ipsec flow msg: %s\n", >>>>>>>>> err.message); >>>>>>>>> diff --git a/examples/ipsec-secgw/ipsec.h b/examples/ipsec-secgw/ipsec.h >>>>>>>>> index 775b316ff..3c367d392 100644 >>>>>>>>> --- a/examples/ipsec-secgw/ipsec.h >>>>>>>>> +++ b/examples/ipsec-secgw/ipsec.h >>>>>>>>> @@ -133,7 +133,7 @@ struct ipsec_sa { >>>>>>>>> uint32_t ol_flags; >>>>>>>>> #define MAX_RTE_FLOW_PATTERN (4) >>>>>>>>> -#define MAX_RTE_FLOW_ACTIONS (2) >>>>>>>>> +#define MAX_RTE_FLOW_ACTIONS (3) >>>>>>>>> struct rte_flow_item pattern[MAX_RTE_FLOW_PATTERN]; >>>>>>>>> struct rte_flow_action action[MAX_RTE_FLOW_ACTIONS]; >>>>>>>>> struct rte_flow_attr attr; >>>>>>> Thanks, >>>>> Regards, >>>>> > Regards, >