From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0062.outbound.protection.outlook.com [104.47.41.62]) by dpdk.org (Postfix) with ESMTP id 3F2ED1B223 for ; Thu, 21 Dec 2017 09:06:54 +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=1Mp/OzoRZr9R0Fext09K6qhGnbc72pVIXNH4lZeNs58=; b=M7yJOaJaEk07JptH8Xy9d9QrPinng8sb5hwJnUeSQ5kJ/GOjmxNSW2KmIcwkeqyPIyKSA1twUS+jf95wWKhrN+KqwZlYXMt2vfbVW5OJk+vCFyRoSDK92SgKc7zSZQAn52RAVEvFO33Adh3dFpb/8i9rpf2u90gJ8+d/V04A5eg= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Anoob.Joseph@cavium.com; Received: from hyd1ajoseph-dt.caveonetworks.com (115.113.156.2) by DM5PR0701MB3640.namprd07.prod.outlook.com (2603:10b6:4:7e::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.15; Thu, 21 Dec 2017 08:06:49 +0000 Cc: anoob.joseph@caviumnetworks.com, "dev@dpdk.org" 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> From: Anoob Joseph Message-ID: Date: Thu, 21 Dec 2017 13:36:43 +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: 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: CY4PR1101CA0005.namprd11.prod.outlook.com (2603:10b6:910:15::15) To DM5PR0701MB3640.namprd07.prod.outlook.com (2603:10b6:4:7e::12) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5e4f219a-c889-4185-eb02-08d54849cb17 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307)(7153060); SRVR:DM5PR0701MB3640; X-Microsoft-Exchange-Diagnostics: 1; DM5PR0701MB3640; 3:it+mQvh5pEbToRaScuq+s2YycGJlhYRsJJcE2ZBt4DtCvucfh9+hPXvm+KNsA8BrhzLeZ0fLGH4/bQNQjOs+rbEuMnFnRIbDNKr2LoIOFwWf6+RLvxJ+NMD3K1oO4RxqsHBcM2KIt5ThEtwjEYnJX82U01HbgBTlDF7BRStGsdBNZ7+tTCld8a+MLvDu7AePtfdhNVnBfiQjTRVrZSum96I/zme7C1061pMMmNW9JcpVizFpCFAw3DoWHurtZGWA; 25:i2u1ocSXHRQUNcWCvZljUHmC0iAmbPtF6MmBfCmFllr5mIhwUg9KRpKuGsC8Hfqgge8E081ciizgigFU/dQIQitGYloRa5tgxCWk2InZm1uMQ7i4hs0vFeFRtXvXkS7r34Fn15+3Ix3qTPcbF7TtCcYEQZoKcgdg7BMMM+y3Wnff+Zk7++zCn/10x52IFE+9dM3CnNQMThhdUZKGnnxxHIekaPBXFt6UyY5ZnhvSzOJgW87May6yfLPA3LuRrj7ZJLfSteQFoNMHUlpuNPIx0eOgOTMMyQMfsev3ITz83S5WIO+G4ywpmpyk5lVE4fjDvlg33TWoWGAlJ+veRx1NFA==; 31:rAR/ktv4qLSA0oyej1WxqSAJfgPZ5dRxii99cEibYEdWNm+IEOBW6g2QLc76W++PrbY2F59tcSYfBcg7H+X2Sgga1c+O65TxVeh6Mw31nKh7zviwO5h99XBAemV0Nl+JhlgIoSvDdGg1E4at7ahQ+XlC9b8l0SXzymOdTKbbIcIvSqKvHv17ovjuxbMxJ7SAoqfe1evi0H51oZEHbcECzu21lj1ieLp9U5kT6+MCyfE= X-MS-TrafficTypeDiagnostic: DM5PR0701MB3640: X-Microsoft-Exchange-Diagnostics: 1; DM5PR0701MB3640; 20:lXZRWqjtYQfaWj91mxGw6WPL8M7GnF9rwY2umpUMz8W11RYXAKvb6LTCtOiMRcUUfOIRTaLJ7UVFY7nDcVdP0FLgjRX+rsuYcY0ZnqR9CrUx5Su2PFU4s9hZ6t4gf+/Of6EYzcLIuihqDfDyRx9FhNdjyJSE0bbZtV4pIoXyrlrX9vt1IUcNyL3pMXgbOWV10o52ctk5db3GDcjDH19VH8N9sxG+vcUCjqkETPZhlXkP7yz8HngoYgOuU44yKQ95uhxGwZAP5yTRYIZZuDtdUIsTs4VXUshsVSCxafj/xX7YGBhNjAng85oeNHETZb5p2CoIgxZ5nAYP5LRSFrP7D7hApzNEiFB++VMc3lTq0sXua/CZXPVDT/HHws6T8eYGzRQGGFKqt/wVsEZNfoLp5EZzZ3XZASiOyhocFfTBhQwKBDibbNZvMIdBjlKFhOxIDpM8JchjeKNTX3kdZu2YPl0fpemBlr3C2B72z6q6NopsR2+e3aA0zOj/VcoClambSWFVXzehwsJHjc4PY6ZHj7rKyUQrLMUngwYCO+tDdUmzXgw7EJ26SIHAB1YVCP/LQthDroJNId44MKR7aPg/zc8ma3KAHiwzywKQZ8Wi3O4= 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)(10201501046)(3002001)(6041268)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR0701MB3640; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR0701MB3640; X-Microsoft-Exchange-Diagnostics: 1; DM5PR0701MB3640; 4:C5PxG3qdcWUX08bg5/xXWanL8usNCOQr9bwxe+5rP7FQsg2F6hP0qsD6LjnAmsp2PKG1UbQax7Kx8w0kxqCqQlrltwf0SY/s8J/EygV52u570Z0Avrp9MVi2dIKlZ8qsurXJdlWVKpk5YGcAMmRHy7ZFVHRjcHWrM+KVrFB+bSytIt90A2T07uNla+CmeMik0y0T24FsLz7qlPDz5HWSu9k65kXIUAnxAcODcfN/Zs4RqtGwzrV+tdMyKEXubj1mKUOjGizENFhDP14rKaIWlNrvgKikn1KkSPX54mKhxpJ+43RoVn+ttTvnbohNbP9kWhQu54IL5tqs3iedg+pAeJEmxDtfUlD5LnFkJXDsQAsMiDwRBAf7LO2scqfi99ly X-Forefront-PRVS: 0528942FD8 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(39380400002)(366004)(39850400004)(346002)(376002)(396003)(52314003)(199004)(189003)(24454002)(76176011)(8936002)(53936002)(6512007)(59450400001)(52146003)(23676004)(72206003)(2486003)(4326008)(478600001)(16526018)(97736004)(83506002)(2906002)(81166006)(31696002)(36756003)(2950100002)(31686004)(53416004)(67846002)(42882006)(5660300001)(8676002)(65826007)(52116002)(110136005)(81156014)(6666003)(66066001)(6246003)(105586002)(68736007)(65806001)(93886005)(65956001)(6116002)(230700001)(316002)(58126008)(3846002)(305945005)(50466002)(106356001)(47776003)(7736002)(25786009)(6486002)(64126003)(53546011)(229853002)(6506007)(386003)(69596002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR0701MB3640; 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?MTtETTVQUjA3MDFNQjM2NDA7MjM6b0ZPblk2VWR4dGcxNEdhcytDNWJaVDBF?= =?utf-8?B?SlJTNzdKVW5EMmxDZjlXam4yUkZZNzBzcXh0NzFqc0pmaGZ1Vmk1VWxvNFpv?= =?utf-8?B?YmpSbFRQM1RVZEpMMC9yQi9NNEo0RUJVZ0JrTUlmOTE3VTl4Yld2eFZjTTJj?= =?utf-8?B?RlR5ZUVvSEdwNFpJYWFCNVFRSGl1aEtSTVl0ZTQ1VXVheGNlcStuYVN6S2RL?= =?utf-8?B?d1l3eVJuajRBUERNc1J4dzV2U1ZmMng4dEMxcCtjQ0lrc2RDUDRrQ1FhbkVq?= =?utf-8?B?ZDJLOXlXVTZua004OWwzcDVFallKT2VjRU8vcmFRTTBvRkxwZG9OSW92NWh2?= =?utf-8?B?SVZYTGZZTlhlV1VnYllZaXJVYkZlak52NnIrVWdNdm5VUGRFckdSWkpaVnJn?= =?utf-8?B?MHhpUzNhUHhSZW56TGtBT3E3bFo0RkNWcVRNRmFkRzdBSFFacWNmejB5M053?= =?utf-8?B?cXhTbDZBRThHRm9iVjMrRlpLT1JWT1Zac2JRS0xrek5FbWl3cXl5cG5CaXpC?= =?utf-8?B?blhYNkJNQ21acXZlZ1VwQjVnMkZUdHdxV3FONTJyRVpTVnd4UHllS2pYb1Mr?= =?utf-8?B?bHhobUVhd0EyNmFYRVJpUnBsbElwdVluTUZ4QTU0VmoyaTNrT1pPRDhJKy9j?= =?utf-8?B?cGFJUkNzSHVNaE5EWFBEbXNpSkdsVkhNTCtmVXk2Q0lZUTRYK3RKZWc0M0lE?= =?utf-8?B?QnRsYzBRVGlBQjhGcGlZY0FCTHAzT2JHUjl2SnY3cWhRMXZuNGhEWGtiMjEz?= =?utf-8?B?RTNESmpha09iUENMc1dSQmY1ZXZkRGdZZ2VHTm1CWkhyUzFZbVZCRDJDc2hS?= =?utf-8?B?QjczOHRoL2ppS3dHWUFXZ0Z5OEl3YkhGRExxWU5YQnErRmJON1NwWXZSbEE4?= =?utf-8?B?K3NsUzBPeVVwNGF2RURGbEFqMXpsYjZyQ0RuZjN4eTZqUExLamhsWnR0ZWdC?= =?utf-8?B?bFNJaHdMZHpTTHJSblMvRERmVEd5a0IraWZSYmZJV1JJeW9hTWVOZ0FtcG9a?= =?utf-8?B?MHdiWk5oS3BObFFmRG1LRUJwajkyYUwwbGdXSllSU3FIQS95V0p6M1EvYzFB?= =?utf-8?B?eTdrZ2pMK2hlNDFHOG9NY0ZhclIwQ09IaEZ3VEZaNDVVN1hmOW5vK2kxbitH?= =?utf-8?B?eHhJTE04eXpJODN6czJiVWNwOFM4Znp0NDV6WUtJSUpuUzRFMUlhVVNhZFFv?= =?utf-8?B?UTluaUNaYS9QMTRweVRFaWFGVHkwWk04bHV5VFRwSDBGNmRUNDNPb2E3Ulk0?= =?utf-8?B?VGxKZ0p2UVVDZlRsUHh1c0M4Wk5wMWE5ckhYL05tMGNDOVkvWml6cVRhb0Nn?= =?utf-8?B?bk1kYS9CaE1oaFlyMEVrOEJ6eFpWQ1FUMDNpVk1aM1NNajNQVXJYaDZxMmpH?= =?utf-8?B?blE5RmwzKzBCTVVUNTlWcjZ0YmtZZFlCT1lLVVlXbkVoNXd3QSt4Z1ZiNjRs?= =?utf-8?B?VHFzbVpwOGxoVXZONm1OYlBab1dDN1dVWTR2ZlNkeldhcDRuL1hGSFJ4ekU4?= =?utf-8?B?VzRvNDYxR1I3cXJXWXJKM21mVThROFZUZUFFdzMxV05MZkh2QXZ0Zzl4NmQ2?= =?utf-8?B?cWFBZ251Tk5HRXhqMUZaMHdYbWFHQTB4YzQ0dGg1SjVheTUrSGhwVG04L2d5?= =?utf-8?B?c2R0NmRyQ1lSRkhXQy9NK2o3NVB1MjUvMUZkMVEweTRBaHp4ak5pYW56MDhx?= =?utf-8?B?OTJmWUhwSk0rS0xjbjlWa2hnRjNyeU1EUnlEZEJNYzRkclRkWHgyY0V5Rmwz?= =?utf-8?B?SnlJbE9TcjRSMEcvSjhpekNHL3BVWXl6cFFzL3Q1ditQMndlYnlucHJKQ3hO?= =?utf-8?B?OHdWMVEwNDJSWmxyR1ExYk5ib0JZVDEwZVlLWWJaUE9QaEp0S1pwQ3haNWVP?= =?utf-8?B?SWhMb2R1NmVQUUsrd1N5ZW9lWGh2a3JCRTRTeHVjUEN3WXBQVS9obVc2RTA0?= =?utf-8?B?WTZHM1FDems2SmdjSG8vZ1JVdnVrNlpXUSs0K1ZpR3FYTFM1U1QraXdORStG?= =?utf-8?B?MGltZDZzRW5GUURFQm1YSDd2ZnAxcnhlMFA2QmhBPT0=?= X-Microsoft-Exchange-Diagnostics: 1; DM5PR0701MB3640; 6:LOk3tV9trtDI3DwDN6YtH959qgVfSWmkK4aW8BFR84nosZSPZFezWbjRIXYOjr0PfhqRbxXuVNLxxo/XqyHtY59kZmIEUIhCrPpPVGdbemQ6rVGsX4Agjwd29ETw1it5nildpsdJoIuD+dQC8crcWw2/2uSROBbjSULmUil1o/U09EOx3GNqd3bT+48evKfaW23yVZgCJghNrxnjNe9ks9ZS7VTf9yFaKDnnMUmn9zu9dh48WvrTRNSS8SyM8NbUJOZ4qqaMn+O1PsLgM+DeOUdtWy838W4+9m7pM35vPLFayKGSsEt401LfXe5vHdUmAur8QiXIrQK6Yph/6UStH/Byjd+QUdyWLby1aIgzj+A=; 5:vEVx+dHmDSjP6WPz04LT24moTyg1Fq2MfLiXvr2/ciXdWRe07sjyKq1s3KxdODCR3a/iC3uCMwa+Iu26EkJoiWEO7mlJQCajvuRYiPq8/ktK7ZMdQlHcdOBaxhKt6GnoaKa+OKNmJYfIPCJuLH4svfe5cUtszWrlRXP6rLhKF8s=; 24:tbs5YAOFt9STQO0YIZWAv3RgDBk5uK2Bb/aHjGjyyUk7ZA+kiflLciqz0RRmx2dn4A8JTGw93S+C8BITQJYUqKAvpLvLnUJPxYd/ilK0I7g=; 7:I/lR8aIdg40V0bb1pZftyLJvLxUxSSBEnFldfNJy5F8PoHEL5pi6YLLtsuVdvTXPrmI2n+eNBVy2aIxD5fG3hO4o2yJa/QshK9GuGoRhZBggM9dEhk+wK3KCZXQXimikF1i30UyovHB5HtzpGX/LEYwNyYklgXndUrSlemPqiqXReX5feky1t4AzNr9jkp6DjEt3FH+BTQ2pxgZsFUb0hrIh/pxqCBvni8ycMDva7wlWvSDVbXhBtQ6oXL/VI/js SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Dec 2017 08:06:49.2916 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5e4f219a-c889-4185-eb02-08d54849cb17 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR0701MB3640 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: Thu, 21 Dec 2017 08:06:54 -0000 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? Thanks, Anoob > > Currently, the SPI is provided in the rte_security_session_conf. I think this is a mistake. > The rte_security session is not using this field and it should be provided only via rte_flow. > This field should be provided only when protocol offload is used. > Moreover, according to the IPsec RFC, the SPI can be used to identify the SA in conjunction with > the destination IP and the source IP. Both are provided in rte_flow. If you decide to use only the > information from rte_security_session_conf to identify the SA, then you are limiting yourself. > > Best, > Boris. >