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 564EE436C8; Mon, 11 Dec 2023 10:57:06 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 43C4140ED2; Mon, 11 Dec 2023 10:57:06 +0100 (CET) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by mails.dpdk.org (Postfix) with ESMTP id A58B240E5E for ; Mon, 11 Dec 2023 10:57:04 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id E9DE83202A25; Mon, 11 Dec 2023 04:57:02 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 11 Dec 2023 04:57:03 -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:message-id:mime-version:reply-to:sender:subject :subject:to:to; s=fm3; t=1702288622; x=1702375022; bh=VmK2usdsqP St8qgvqirMWwldM3b5wkvf6V5PE4UffJQ=; b=E546MzimMhEILX42wkQcunuL5t LVVbc+XvDBzLVEfl63v0qgKDcZA4UAY0hrcv4SeIj/dbZmneiHSgeNq9kpYCCUU7 b93ekZne1DpJ6SnEMOfvm0Aa8SlLTqnCbfCqgaqgQOnljYlKAY9UC4gxeMss8x1H 0JoVSqP+JZFsyP6mRJ/9pRcGT8aFqGNEDILz4PWynyejEebp+K0lyWf8jRD0x6sh l08mOMK8x3bo1yfMK8TItdR6HLigFxHrB47KlZ80283vI5ON2GODI3A4PpxMtzpR atcyZ9gfDkIT8DcxVjKxGYsh2x2BgUtJm7q0STMtoGKuJJoRtcZcdx2ZwK/g== 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:message-id :mime-version: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= 1702288622; x=1702375022; bh=VmK2usdsqPSt8qgvqirMWwldM3b5wkvf6V5 PE4UffJQ=; b=Ul+gIBLJkpxIhNyFCthMDWYN8l0CPtah5nNs4yrlzXNDH6ftRQg 5wAkKt03G5hkIes/lteqNUW9yeXYyKaOUS7p9qR6JF0D5H8UTtbeIk48yWVSOSv2 RpmgZnzpPykU2aG+sp7n9J/LoifQ+R60C6O0WNJ9swWOlNI/LJcEUKqwX7lMBTvT MDjPyJRWk2lcJvtipECvROM6KJVB+6QAQANXCUOiB69HSZBnrcH3fVD9bhT9PPqs tmmpq5kBsBu2M7h1BzdRGMjF81dgLmAbVgKwH5dvI6A77hXvB6jtkmZjyG6nKr0I B3BJ6mT/Q770MiBo7ao/7AySxW83IGymPCQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudelvddguddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvvefukfggtggusehttdertd dttddvnecuhfhrohhmpegjuhgrnhhhrghnucfnihhuuceohihlihhusehfrhhiuggrhihl ihhnuhigrdhorhhgqeenucggtffrrghtthgvrhhnpeeffefgheduvdeghffftdefvefgtd dtleegffehhedvteduudehtdeigfevgfdvueenucffohhmrghinhepghhithhhuhgsrdgt ohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhephi hlihhusehfrhhiuggrhihlihhnuhigrdhorhhg X-ME-Proxy: Feedback-ID: ibfc945b4:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 11 Dec 2023 04:57:01 -0500 (EST) Date: Mon, 11 Dec 2023 17:56:54 +0800 From: Yuanhan Liu To: libtpa@googlegroups.com Cc: dev@dpdk.org, Yuanhan Liu Subject: Libtpa: a DPDK based userspace TCP stack implementation Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 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. Libtpa is fast. To demonstrate that, we did a hacky redis integration. The benchmark shows that libtpa can boost the performance more than 5 times, from 0.21m rps to 1.14m rps[1]. Right, it can achieve 1 million rps just with one CPU thread. Meanwhile, the p99 latency decreases from 0.815ms to 0.159ms. Regarding the stableness, I'd say it's not bad, all kudos to the comprehensive testing. I've written more than 200 tests. Together with the testing arguments matrix[2], it can result in a big variety of test cases. Therefore, most of the bugs are captured before deployment. Having said that, I'd still suggest you to do as much testing as you can if you want to use it, for libtpa is still under active development and it's just v1.0-rc0 being released. Tons of changes have been made since the last stable release. There is one more thing I'm a bit proud of about libtpa: as a DPDK based project, libtpa has rich set of debug tools[3]. The sock tracing is particularly handy on debugging that libtpa doesn't ship a tcpdump like tool, simply for we don't really need one. The TCP part then may not sound that exciting. It's basically just an initial TCP implementation, with standard congestion avoid algorithm (New Reno). Libtpa implements slightly more than that though, such as SACK, congestion window validation, spurious retransmission detection, keepalive, etc. That's all. Comments, questions, patches and testing are all welcome! Thanks, Yuanhan Liu --- [0]: libtpa: https://github.com/bytedance/libtpa [1]: redis: https://github.com/bytedance/libtpa/tree/main/doc/redis.rst [2]: matrix shell: https://github.com/bytedance/libtpa/tree/main/doc/internals.rst [3]: user guide: https://github.com/bytedance/libtpa/tree/main/doc/user_guide.rst