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 8883DA0548 for ; Fri, 23 Apr 2021 10:32:49 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DAF8441DC8; Fri, 23 Apr 2021 10:32:45 +0200 (CEST) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11olkn2096.outbound.protection.outlook.com [40.92.19.96]) by mails.dpdk.org (Postfix) with ESMTP id DAB7B162014 for ; Thu, 15 Apr 2021 07:59:48 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IgAGNOKi/C5wxINBbA5Sko/fZWnKpSC4xPebwq0o0ojSt9fQ96w+JynZ40xd5Xh10kV06IFZKsfrVxqS0GhZF8RWDEYSaEGUqoLAqraktM5Pjk9PDtdBvKmAD1A5yXMxnku2Gd2nn5IptxEduGizvJZMPuLVMnaCsqEh3bWgN1bFTlbOrdYT4SW7WWOzH2Ck7g9GgNGi22Sy3Uus+MP5NFepIaiIONU9rkX1rwzvM7BSM2sp7tzUF4bA81TRhjphH1makilHyUUzszVpuYsEPTjxbEuC7Tv3ZDGb3sp9GhdkjCfZwdDSVgasnHYxGR/jjTnSqgaEQXdbJQvr+7rM6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8/MkbihQFRCtm/hgWCg2MoPkfD76RPNeYswslhH+CoM=; b=TQuh+FjkPDK5O6j20NO4kR3VwmdbpkkdcHCAHmF8l+4QKMPaM/hesqJTzJsH2xuOA/eclstjZ77eDBI34b6GAYkM6J7FcIPgM+oeEKp5aueCqn7mMexQs34QESuMrXMgtKrbYBu1ICoplPjX9oSmRys0HFvXjdL8Kid+X3BXzyLyU3dl6ZWJG8v7By23jCa6jMB8rYOeciVaovsJGGdF9NMKYCmddA+mLSiz1/5DnkHAVRdqAIARZWtolDB0JH0TtC7pIef3bsN3R2jbBiSr+BA+FkH6WSCHC1gpZoaPpH3lnLpAyFsf6AGWXGRFi24iMBUt5uegc9cwiyuUNRyIiQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8/MkbihQFRCtm/hgWCg2MoPkfD76RPNeYswslhH+CoM=; b=OVdHqC/+naTspSZGi5VjLQhq42CtE0z3hP/g7Tb9c5odPAnmKKmQzHsn/21zhGiN+Z++xbKwirp+eDbZSX4kfQGiqMogu+zx/YnoYxWoewlhcSNHARnnzyYtnYdDlp8JetgGjK9RZAJ+ckWMAII4CQm/AcWZgS27QiiQMgmcKT+uhBSDx6Ox9qE8mmUS1ORB4Ad6Z8spV5nW5dNEatjh/5H6ACAoL9nLOaVhaoy4Ysgl9LUqp8mi5wb11jYQHExwjpZfqTQG3SkkqM8PAhdzwKmjdI6Pil54S/vakVudXFYG3jvBf3aXNXPQpvXFZd6cCcfMgsxwDfaxpC7mfnWqUQ== Received: from DM6NAM11FT026.eop-nam11.prod.protection.outlook.com (2a01:111:e400:fc4d::4c) by DM6NAM11HT095.eop-nam11.prod.protection.outlook.com (2a01:111:e400:fc4d::385) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.17; Thu, 15 Apr 2021 05:59:47 +0000 Received: from BYAPR04MB4167.namprd04.prod.outlook.com (2a01:111:e400:fc4d::45) by DM6NAM11FT026.mail.protection.outlook.com (2a01:111:e400:fc4d::161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.16 via Frontend Transport; Thu, 15 Apr 2021 05:59:47 +0000 Received: from BYAPR04MB4167.namprd04.prod.outlook.com ([fe80::81de:50a5:6526:950b]) by BYAPR04MB4167.namprd04.prod.outlook.com ([fe80::81de:50a5:6526:950b%5]) with mapi id 15.20.4020.023; Thu, 15 Apr 2021 05:59:47 +0000 From: Hao Chen To: Pavel Vazharov CC: "users@dpdk.org" Thread-Topic: [dpdk-users] What is TCP read performance by using DPDK? Thread-Index: AQHXIDh4H8QknstLlk6mzOwh2+wPdKqarTUAgBqIIwg= Date: Thu, 15 Apr 2021 05:59:47 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:DE44712D18AC0640365BCE5BD4A873F51E14333F8CC5F6A3C1ABC42DF78E8135; UpperCasedChecksum:5B0ECDBBB3CF5C4AFD9FB2B15884F9BDD5BC07F6D8974B619E9141113E6FAE93; SizeAsReceived:7011; Count:45 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [yMKy+pZwilD5ES6qw9rSUdXo8htwm/bJ] x-ms-publictraffictype: Email x-incomingheadercount: 45 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 0d9c2426-69d5-4979-ae6e-08d8ffd3acdb x-ms-traffictypediagnostic: DM6NAM11HT095: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +aJz02t0P9oN9O7Mrzy9yX0N5AyCnVDkCnX3axxRWZ98cYy2th75+we6NByhtqB4mTPE+ig1j6o+hM3CS4GLOUMvRc/xMDjbfwkuyUiNPb66qCI0HO7lZCeVCFCe5glahCcp6FVgzFgYRxRptFNMT9Zz9d0dAQs1LBKVzqTsrneJANJdMpc6iywi3trVcGiZOpJoQUaDR23uK+Xm6kze1pa5gUbl2+Mc4OlWmeNlbZTu5Ztoc+D1a311+LOZ8+LSX3jy/CPFcrD7i/Xj+b+qmZ3r3xa38nBCdzp4xxKUC7Lf8darcSBxHgf7GvDzMyxRHv7yplRI5H1c9TzvKEvLi6ha9mdg+bs8NJ3a8PUJpL759tkvj6E0IFXGqORGcZUIhNal1pH2CZl4MzjTRC42SgcMBvLRfdwkwvMhVW2Jay0= x-ms-exchange-antispam-messagedata: gYnAwttJ+Kkq0iUycycvI2CC1L6czfn+NakCbEeBY+9OKfeqygzmHAzv0nuOpnaTR6/KQmTtYfJLeCvdLTYj7nGjzeH6pVA7rJgZYrnAncIgqyF0OwTDxO0xUDmaOoziC6ThIrZ0qnKPQG0PPn9kfA== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-AuthSource: DM6NAM11FT026.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 0d9c2426-69d5-4979-ae6e-08d8ffd3acdb X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2021 05:59:47.5875 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6NAM11HT095 X-Mailman-Approved-At: Fri, 23 Apr 2021 10:32:43 +0200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [dpdk-users] What is TCP read performance by using DPDK? X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org Sender: "users" Hi Pavel, Appreciate for your help. 1. You wrote "we work in proxy mode". Does it mean your code just look at IPHeader and TCPheader without handling= TCP payload? In our use case, we need to decrypt TLS traffic(handle full TCP payload). 2. You wrote "much bigger performance gain for UDP traffic where the packets a= re more but smaller in our use case". Does it mean UDP-payload-size is NOT 1400 bytes (MTU size)? And it is as sm= aller as 64 bytes for example? I looked at https://www.bittorrent.org/beps/bep_0029.html for UTP protocol. Do you handle UTP payload, or just "relay" it like proxy? 3. Again, appreciate for your response. Thanks ________________________________ From: Pavel Vazharov Sent: Monday, March 29, 2021 1:38 To: Hao Chen Cc: users@dpdk.org Subject: Re: [dpdk-users] What is TCP read performance by using DPDK? Hi, You can look at F-stack or Seastar for some performance measurements. The first one uses the networking stack from FreeBSD 11, AFAIK. The second = one has their own networking stack. Both of them work over DPDK. We also started with F-stack but later modified it to extract the DPDK code= out of it so that now we use a separate TCP stack per thread with shared n= othing design. I can share with you our performance measurements with real traffic from an= ISP provider but they are not very relevant because we work in proxy mode,= not as a server. However, our experience is roughly the following: - for TCP (port 80) traffic the proxy over DPDK was about 1.5 times faster = than the same proxy working over standard Linux kernel. The application lay= er was the same in both tests - a straightforward TCP proxy of port 80 traf= fic. - we observed much bigger performance gain for UDP traffic where the packet= s are more but smaller in our use case. Here we tested with UTP (uTorrent T= raffic Protocol). We have our own stack for UTP traffic processing which wo= rks over UDP sockets and again we run the same application code once over s= tandard Linux and over DPDK. The DPDK version was able to handle the same = amount of traffic on 2 cores with about 0.7% packet losses as the Linux ver= sion handled on 8 cores with the same packet losses. So, here we observed a= bout 4 times improvement here. However, take our measurements with a grain of salt because although the ap= plication layer was the same for the Linux case we do some packet inspectio= n in the Linux kernel to filter out asymmetric TCP traffic, to match UTP tr= affic, etc. This filtration and matching was done in the DPDK layer of the new proxy so= the code under test was not 100% the same, more like 95% the same. In addition to that, the UDP measurements were done on two separate machine= s with the same type of CPUs and NICs but still they were two separate mach= ines. Regards, Pavel.