From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 7BA80A0096 for ; Mon, 8 Apr 2019 21:36:24 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1FA6A2BCE; Mon, 8 Apr 2019 21:36:24 +0200 (CEST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60079.outbound.protection.outlook.com [40.107.6.79]) by dpdk.org (Postfix) with ESMTP id 8A63F2BCE; Mon, 8 Apr 2019 21:36:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QTPRnlgzrtI9kMKj7+QeU3j5XGbe7ZEB+KMrl5mLjtc=; b=mREufDbgBqNQFUDJCfl2V4kxIlbAmn7fAVaYUmqEAwaWREp9eM4YiYvdUlfkkW1Vy7GHFHQvBc4e/PEZjI8duAVYZBtj0XkuxrZXr3brAIgVN2iSmGOolDvwq6N6ZSos+a0h5TtMP9PlAlUpZVXXMyNUl59lPAC+1bU5sRd5AjE= Received: from DB3PR0502MB3980.eurprd05.prod.outlook.com (52.134.72.27) by DB3PR0502MB4044.eurprd05.prod.outlook.com (52.134.72.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.15; Mon, 8 Apr 2019 19:36:17 +0000 Received: from DB3PR0502MB3980.eurprd05.prod.outlook.com ([fe80::6072:43be:7c2d:103a]) by DB3PR0502MB3980.eurprd05.prod.outlook.com ([fe80::6072:43be:7c2d:103a%3]) with mapi id 15.20.1771.014; Mon, 8 Apr 2019 19:36:17 +0000 From: Yongseok Koh To: "Ananyev, Konstantin" CC: "Nicolau, Radu" , "akhil.goyal@nxp.com" , "dev@dpdk.org" , Aviad Yehezkel , "stable@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH] examples/ipsec-secgw: fix coherency of ESP sequence number Thread-Index: AQHU7kJVpQwH8M6DVkaI9XLZznv+ig== Date: Mon, 8 Apr 2019 19:36:17 +0000 Message-ID: <20190408193608.GA18021@yongseok-MBP.local> References: <20190406003512.1291-1-yskoh@mellanox.com> <2601191342CEEE43887BDE71AB9772580148A943CB@irsmsx105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB9772580148A943CB@irsmsx105.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: BYAPR01CA0059.prod.exchangelabs.com (2603:10b6:a03:94::36) To DB3PR0502MB3980.eurprd05.prod.outlook.com (2603:10a6:8:10::27) authentication-results: spf=none (sender IP is ) smtp.mailfrom=yskoh@mellanox.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [209.116.155.178] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 15761afe-1157-4885-74c9-08d6bc597820 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:DB3PR0502MB4044; x-ms-traffictypediagnostic: DB3PR0502MB4044: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(396003)(376002)(136003)(366004)(52314003)(189003)(199004)(446003)(3846002)(6116002)(5660300002)(11346002)(102836004)(33656002)(476003)(7736002)(305945005)(26005)(186003)(14444005)(256004)(71200400001)(71190400001)(2906002)(486006)(386003)(6506007)(1076003)(76176011)(316002)(8676002)(81166006)(81156014)(6246003)(9686003)(8936002)(6436002)(68736007)(66066001)(97736004)(6486002)(53936002)(6512007)(52116002)(45080400002)(86362001)(54906003)(105586002)(4326008)(98436002)(14454004)(99286004)(966005)(25786009)(229853002)(6916009)(478600001)(106356001)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR0502MB4044; H:DB3PR0502MB3980.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: viPKuTj1bD2bNhgu4ZJ2vnHzVtl3Ax/3ZyKDpn+tjCvMZ92ADAV85KGvb/0UzoN8dRe5gNpgHYYsM4yx9YYwpSSJORw1mlianaOq/93YeCu/vczfeMPnkqfG6lTYy+NE7/Vt33iki2bdc8dz6xEy3H2I/t9fMttdUQBwXLo1rcuYD0y8cU+omouN9e/fFjito3eXlC7+oxJRqdla7POcj8ghEcW5hULcDdJvZ7R8Osor+B0h2FDpi/2Jl9C6+Bum28tXC7EOlSZ+jt3pjZ2hpGNwvv+Srk7V12NODaFjgnzjTx/19LkDgMQfcNx9rvkAoQ9z0hB+0O27S4XI45pb+CSrO2keK1CtMkST8c/1ll5ctl3Jkn07Q+d/BBgMBnO+DdwSzyBEtBQjewvuq7BRZAZbjTGBjHaegPgUTPal5bo= Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: 15761afe-1157-4885-74c9-08d6bc597820 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2019 19:36:17.6360 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR0502MB4044 Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH] examples/ipsec-secgw: fix coherency of ESP sequence number X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" On Mon, Apr 08, 2019 at 10:41:29AM +0000, Ananyev, Konstantin wrote: >=20 > Hi Yongseok, >=20 > > Outbound ESP sequence number should be incremented atomically and refee= nced > > indirectly. Otherwise, concurrent access by multiple threads will break > > coherency. >=20 > I think MT mode per SA is not supported right now by ipsec-secgw. > From https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2F= doc.dpdk.org%2Fguides%2Fsample_app_ug%2Fipsec_secgw.html&data=3D02%7C01= %7Cyskoh%40mellanox.com%7C92fcdccccff446f9f93708d6bc0ec532%7Ca652971c7d2e4d= 9ba6a4d149256f461b%7C0%7C0%7C636903168953772804&sdata=3D8l1b79cFf7Jodlk= %2Bup3b8uRUUSU2IyglmFxhmXqsbCI%3D&reserved=3D0: > 49.2. Constraints > ... > Each SA must be handle by a unique lcore (1 RX queue per port). I wasn't aware of this limitation. If it is already documented, I'll take b= ack my patch. Actually, I have done some performance testing with this example = and it worked fine with single SA in each direction. That's why I thought it wa= s supported. > Also the changes you proposed wouldn't handle inbound case. No seq number check for inbound direction in this example code.. > Anyway, if you still like to have atomic sqn updates for outbound, > then probably better to make it configurable > (otherwise it would introduce unnecessary slowdown). > There is '-a' (atomic) command-line option. > Right now it works for librte_ipsec mode only, but I suppose it wouldn't > be big deal to make legacy mode to take it into account too. >=20 [...] > > diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c > > index a7298a30c2..adf6ac3f9a 100644 > > --- a/examples/ipsec-secgw/sa.c > > +++ b/examples/ipsec-secgw/sa.c > > @@ -795,7 +795,7 @@ sa_add_rules(struct sa_ctx *sa_ctx, const struct ip= sec_sa entries[], > > return -EINVAL; > > } > > *sa =3D entries[i]; > > - sa->seq =3D 0; > > + rte_atomic64_set(&sa->seq, -1); >=20 > I think initial value should remain zero. The reason was because there's no rte_atomic64_return_add() but rte_atomic64_add_return(). Would be better to have it with __sync_fetch_and_add() later. Anyway, I'm taking back this patch like I mentioned. Thanks, Yongseok