From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 184B943686; Mon, 11 Dec 2023 13:36:47 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9446641148; Mon, 11 Dec 2023 13:36:46 +0100 (CET) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by mails.dpdk.org (Postfix) with ESMTP id 59069402E9 for ; Mon, 11 Dec 2023 13:36:45 +0100 (CET) Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailout.nyi.internal (Postfix) with ESMTP id DD6C75C01D7; Mon, 11 Dec 2023 07:36:44 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Mon, 11 Dec 2023 07:36:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fridaylinux.org; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; t=1702298204; x= 1702384604; bh=JkKtdK7I67AzQKD40YUsJ32dIixoqdSMyH7TlW8P038=; b=Z C4IcrSlm7CLWus3bl03o7MCrh6fBNR7w8kp+S2uNFtXPyz4h4wrFmsGb1tfmnuGv gzYj6sJn+ZTYO2rihiokYjzyfFlxJmbfbGL69RCqwCiSCOharRBNglkDel49l9Pu n6XiVF2PYO6nnLvXpduRUHCc5+A7M14/4zbBkIkGPSR8vsP3ls8UCMzKsA5Wf69u XLvyks/W9S+uve2TzjTnPJVa03hbHCyHUNw9W+5EtOSwflKgiH7KMwVr7ZkCtxaS S/Ivy+gc+7Xxzt1HarBNs/9GbX9MLX2QJPaR/hcuqRsiFgWHKeLEkYX0xg4HhUg2 GEANzI0AHm8uCJUmaegAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1702298204; x=1702384604; bh=JkKtdK7I67AzQ KD40YUsJ32dIixoqdSMyH7TlW8P038=; b=etzoKASUccLkZasDh51PjfkSDKXTN MdKoUPW0GNVwtaoXRRRjxzwqaBcVjiyi530j/YzTbM4pj9YPsMXS1ppYErBZGNtH 0NuMg/oXkZZ5SeBrVKMZ6evtxqcUD4uRNje9rGmcz/IO3z3ZQVcXkeWlM5+E2rb2 uqCaUuITGEubBN8xYVuh546oSDhfCkDH4t4EcQxzDLovTXp3HhNpok0nnA6Zddkq CEZa7hWdQeRt4lUEX2OQPODWeX8Zdnlzqw3Hq6MR9ZBy1Dk/2sGNQuSSrMiP/6RO qNFekB8S66YMy/gBBRGsZ02g5Vin1SCKBAtRW1lAjWo/MxJ1UXyNGHA0g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudelvddggeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepjghurghn hhgrnhcunfhiuhcuoeihlhhiuhesfhhrihgurgihlhhinhhugidrohhrgheqnecuggftrf grthhtvghrnhepieetudetfeeftddvgfevgeeiiefgieevheeiieethfekleekvdekffet vdduteeknecuffhomhgrihhnpeguphgukhdrohhrghenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpeihlhhiuhesfhhrihgurgihlhhinhhugidr ohhrgh X-ME-Proxy: Feedback-ID: ibfc945b4:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 11 Dec 2023 07:36:43 -0500 (EST) Date: Mon, 11 Dec 2023 20:36:40 +0800 From: Yuanhan Liu To: Thomas Monjalon Cc: Yuanhan Liu , "libtpa@googlegroups.com" , dev@dpdk.org, Jerin Jacob Kollanukkaran Subject: Re: [EXT] Libtpa: a DPDK based userspace TCP stack implementation Message-ID: References: <3376556.iZASKD2KPV@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3376556.iZASKD2KPV@thomas> X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Mon, Dec 11, 2023 at 01:16:52PM +0100, Thomas Monjalon wrote: > 11/12/2023 12:32, Jerin Jacob Kollanukkaran: > > From: Yuanhan Liu > > > Hi all, > > > > > > I'd like to share a new DPDK open source project, libtpa(Transport Protocol > > > Acceleration)[0], which is just another userspace TCP stack implementation so > > > far, written from scratch. > > > > > > I started this project 3 years ago, while I was searching for a feasible open > > > source project with no luck. There were indeed quite a few options, but none of > > > them actually met my needs. I then started writing one. Likely, there are still > > > other guys out there looking for a high performance and stable userspace TCP > > > stack. This is what this email and libtpa for. > > > > Great Yuanhan. > > > > If you have time and willing to put effort, I suggest make this part of dpdk code base > > as new library (tcp or so) and leverage + improve another existing library such ip_frag. > > > > I believe, that is only way. > > - This code soon won't soon outdated based on new DPDK version > > - More community review and contributors > > - More review and features from NIC vendors PoV. > > - More arch and driver support. > > - More quality > > As Yuanhan said, there are many TCP stacks running on top of DPDK. > We should add this one to the list: > https://www.dpdk.org/ecosystem/#projects > Also a discussion has started recently about integrating one in DPDK. > As Jerin suggests, libtpa looks like a very good candidate to focus efforts on it. > > Regarding performance, how does it compare with F-Stack? TLDK? Seastar? I think it should be fair to say (I haven't done the testing though; I never tried to run those stacks), libtpa is the userspace tcp stack with the best performance I'm aware of. The redis numbers showed in this email thread is just one example. Libtpa also ships an performance benchmark, tperf. With tperf write test (and without jumboframe), libtpa can achieve 200G linerate with only one physical core for write. The read test is not that good though, because of missing hardware acceleration features like TSO. Although performance is very important to an userspace stack, I still want to point out that, during the design, performance is not my major goal. I spent most of my effort on shaping the testing system and the debug-ablity initially. Libtpa has been deployed in bytedance for more than two years, till now, there is no single TCP protocol bug reported. (I do get very few bugs reported though, but most of them are related to the OS environment, such as sigbus due to wrong API used when running out of tmpfs). Thanks, Yuanhan Liu