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 23208A034F for ; Mon, 29 Mar 2021 10:38:14 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0E757140DE7; Mon, 29 Mar 2021 10:38:14 +0200 (CEST) Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) by mails.dpdk.org (Postfix) with ESMTP id 294FA40151 for ; Mon, 29 Mar 2021 10:38:13 +0200 (CEST) Received: by mail-wr1-f46.google.com with SMTP id j9so10213157wrx.12 for ; Mon, 29 Mar 2021 01:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G323zn58ifum+uonfXnveMuWH/v2pQRpBmHP+Wc+ijw=; b=JvoCvW31h3Mn1SzrlHBVnmDe59esMluHiqBU2hrdCUhpNo4+WpeDTD2Nwp75fb8sA1 IqWmPCkVU0yNFKvYV8lqob1qvcCXdWeiId4RGvXCJDjYw9HKo4deFviu8iLAsr26EDce 9C0ssDaUJ7Th9bPYS5Ag3b5OCN/TI6Yfftsx8XcVVlYKJPtf1J/VNLvPNcFqN9WPzZ+O sIFR+BNAtjgM8OBQSd1r4GczxQJZc5FhEV/WHPE4jndNrFT3TZgCOu/YuZgF64vo/y1v 58NHW3rCk67HajI+Io8mG+z5k+ZUmP4iCuBncWnBW+zXGpRu6IKhfaG+D84I2B6mbHfQ c/Ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=G323zn58ifum+uonfXnveMuWH/v2pQRpBmHP+Wc+ijw=; b=PR3Se9QW0+Ty2y/bffjogkiv/rBAKN/PLjxUuOWzp5bRkePH1zpoHbTDdKtHsu2mDk QpPOMwCtHcm53k9NIWtZ9wt/iUe9CzGD3IK9S2PJs7cPJB3HhITD5rF9RvV46h+EgIAy ZfNduEJYMOWU5q1RXbmLaMhLyJz/5WQFDWFSiMq6DGnefOyC7CORAXCrTW3GCzjPTkBB 8VYOxbS+pNyX18PA38I4ejclFx896O+B4UWm93p39gtrhCumJWAAz3fV9pcPr/LSd+AC 1vkWU7SPcaIPt/+ce/eTy1K9XYhBl/QKgg9zQIMctc/RiMDYnHBU/H+2F5Dv94pe91bZ O/ew== X-Gm-Message-State: AOAM530ntpRMMpazziMuhroe9CrEyD4njwDaUCm8+jDFj9V3SIlrj14U 8TJbjvOgF1wioA7o3NWhpCBv166OJa+KjCL8GuM= X-Google-Smtp-Source: ABdhPJza5ZGyuJIGTsbEenE6tpqcsk0/NdVTLjBxxiewm27PZKmNg5UJ8CtD5RchWo1JKTizecVDQuD+WoUlrUD7cuw= X-Received: by 2002:a5d:6b50:: with SMTP id x16mr26603697wrw.379.1617007092900; Mon, 29 Mar 2021 01:38:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Pavel Vazharov Date: Mon, 29 Mar 2021 11:38:00 +0300 Message-ID: To: Hao Chen Cc: "users@dpdk.org" Content-Type: text/plain; charset="UTF-8" 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, 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 nothing 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 layer was the same in both tests - a straightforward TCP proxy of port 80 traffic. - we observed much bigger performance gain for UDP traffic where the packets are more but smaller in our use case. Here we tested with UTP (uTorrent Traffic Protocol). We have our own stack for UTP traffic processing which works over UDP sockets and again we run the same application code once over standard 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 version handled on 8 cores with the same packet losses. So, here we observed about 4 times improvement here. However, take our measurements with a grain of salt because although the application layer was the same for the Linux case we do some packet inspection in the Linux kernel to filter out asymmetric TCP traffic, to match UTP traffic, 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 machines with the same type of CPUs and NICs but still they were two separate machines. Regards, Pavel.