From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id D010BA0539; Thu, 23 Jan 2020 14:33:31 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A75E0374E; Thu, 23 Jan 2020 14:33:30 +0100 (CET) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id 1E5EB2C6D; Thu, 23 Jan 2020 14:33:29 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6E6F221F32; Thu, 23 Jan 2020 08:33:28 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 23 Jan 2020 08:33:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=6pa5s0fTDnmOoK/QUYFQqiLEyUlVFpyCcHQ0Y9E21Zk=; b=XeHxH1jj/hly vamFu7O73NQBcFwF3faoJ65ONOKbPRl3cX/xvh6YrajgzsFXvzohhYd26SBo5/qZ X0OUcWlKFBe0dO+hr/jzhDpsBeOwqAsIunDD5hat4Qt7l1YMP5QehUE2eKDcA7w8 JcZx4I6mrmcFzCxX0OCLqqAFdkmqas8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=6pa5s0fTDnmOoK/QUYFQqiLEyUlVFpyCcHQ0Y9E21 Zk=; b=KLq1CbKlx3sZ+sviO9V4dPyLMUZb5vqeGBZ4CqLaG25SVooDSe2KmomIN TgmF8Y085GsftwukU6xpu8Blfno+nCln99+yCY9NuRmppTVLjkHoVgZbvV8sLOV2 GvJboGk7lAzH+szMJO+EQhNZRB6VrHWLBOLlSOjwplQllxCGUajqEHRUyiE4dr1i GLF5QBd9oFWxKhTNcilyfYpAw45s9Xjq/2FShbqx4tGzKl5mMqEnk5Z9JbCdcMK4 td/RHd/jtjQah6J0tyUxMvo9Iak3XvFqw2Rsu8GX2cZ91e1XKXheoROUjWA7iYPJ jJq4mMEgnMbP14gYRPpIiggS+IM0w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrvddvgdeftdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id B2392328005D; Thu, 23 Jan 2020 08:33:26 -0500 (EST) From: Thomas Monjalon To: "Ananyev, Konstantin" , dpdk-techboard , Akhil Goyal Cc: "dev@dpdk.org" , "Medvedkin, Vladimir" , Anoob Joseph , Ravi Kumar , Ruifeng Wang Date: Thu, 23 Jan 2020 14:33:25 +0100 Message-ID: <2115897.ZQ0cqP7t2B@xps> In-Reply-To: References: <1578920122-228017-1-git-send-email-vladimir.medvedkin@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v4 0/5] integrate librte_ipsec SAD into ipsec-secgw 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 23/01/2020 13:56, Akhil Goyal: > Hi Konstantin, > >=20 > > Hi Akhil, > >=20 > > > > > > Hi Vladimir, > > > > > > The SA lookup logic and management is purely requirement based = for the > > > > > application. > > > > > >The application may only cater to <128 SAs which can > > > > > > be handled based on the current logic. > > > > > > > > > > Not always, current implementation can handle < 128 SA, > > > > > whose SPI%128 never match (let say it cant't handle SPI=3D1 and S= PI=3D129). > > > > > Yes, what we have right now has nearly zero overhead, > > > > > and might be ok for some really simple show-cases. > > > > > But for majority of production IPsec implementations, > > > > > I believe that definitely wouldn't be enough. > > > > > > > > > > > =E2=80=93single-sa option cannot handle this. > > > > > > Sample applications in DPDK are there to showcase the best a ha= rdware > > can > > > > > deliver. > > > > > > > > > > My thought was - that's the reason we have single-sa option - > > > > > demonstrate best possible HW perf without minimal SW intervention. > > > > > For something more serious than that, we use generic SAD implemen= tation. > > > > > > > > > > > IMO, we cannot allow this logic on NXP hardwares. We > > > > > > give performance numbers based on IPSec app to customers and we > > cannot > > > > > allow 15% degradation. > > > > > > > > > > As Vladimir said, we are looking how to improve current SAD numbe= rs > > > > > and minimize the drop. > > > > > But with same equals - plain array will always be faster than has= h table, > > > > > so not sure we will be able to match existing performance. > > > > > So two questions: > > > > > 1. What exact case you use for perf testing > > > > > (total number of SAs, packets per burst belong to the same/di= fferent SAs)? > > > > > Might be there is a way to speedup it. > > > > > Again if 10-15% is not an affordable drop, which one is: zero= or ...? > > > > > > > > We should add features judiciously, we cannot drop the performance = of a > > > > benchmarking > > > > Application in lieu of adding functionality. We should only add fea= tures which > > > > are not > > > > Impacting the performance significantly. > > > > Every vendor may have different cases. We cannot tune for everybody. > > > > However, I see drop in 64 outbound 64 inbound SAs all with differen= t SPI and > > IPs. > > > > Packets per burst =3D 32 all with different SAs. > > > > > > > > > > We can have two modes of lookup similar to l3fwd - EM and LPM. > > > LPM is O(1) while EM is more realistic. Similar logic can be added he= re as well. > > > With L3fwd also we showcase performance for best case(lpm) and the wo= rst > > case(em) > > > What Say? > >=20 > > We discussed it off-line with Vladimir and came up with similar idea: > > Have a proper/generic SAD implementation and add limited size plain-arr= ay > > on top of it as 1xway associative cache. > > So for the case when all active SAs fit into the cache and no SPI colli= sions, > > we should have same performance as now (with plain array). > > From other side, we'll still have generic/scalable/rfc compliant implem= entation. > > Sort of best sides from two words. > > Plans are to submit v4 with such approach in next few days. >=20 > OK lets check the v4 before moving the discussion to techboard.=20 > @Thomas: Do you have more thoughts on this? Should we get it added in the= agenda > Or wait for the v4? If v4 is good for both cases, it lowers the priority of the discussion. But still, it would be interesting to state the objectives of the examples: - show API usage? - show feature performance? - show best hardware performance? - what else?