From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 2B3052BD3 for ; Wed, 19 Sep 2018 07:09:22 +0200 (CEST) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Sep 2018 22:09:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,392,1531810800"; d="scan'208";a="71147467" Received: from btwcube1.sh.intel.com (HELO debian) ([10.67.104.151]) by fmsmga007.fm.intel.com with ESMTP; 18 Sep 2018 22:09:20 -0700 Date: Wed, 19 Sep 2018 13:08:15 +0800 From: Tiwei Bie To: Eric Tremblay Cc: "users@dpdk.org" , "zhihong.wang@intel.com" , "maxime.coquelin@redhat.com" Message-ID: <20180919050815.GA20551@debian> References: <20180918052951.GA1658@debian> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [dpdk-users] Virtio-user exceptional path performance X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2018 05:09:23 -0000 On Tue, Sep 18, 2018 at 02:45:24PM +0000, Eric Tremblay wrote: > Thanks for the reply. >=20 > With the patch, the tap interface is created in the kernel even when spec= ifying the --enable-lro and --enable-rx-cksum options. However, the behavio= ur is the same as without these options. That is, ethtool shows LRO and rx-= checksum as off (and [fixed]) and TCP traffic gets dropped unless tx-checks= um is turned off. The difference is that testpmd now says that LRO and RX c= hecksum are on (even though they don't seem to be). Are you using csum fwd in testpmd? You also need to enable the hw csum offload. You can do it via: testpmd> csum set tcp hw 0 testpmd> csum set tcp hw 1 And make sure you get below output: TCP checksum offload is hw >=20 > Eric=20 >=20 > -----Original Message----- > From: Tiwei Bie =20 > Sent: September 18, 2018 1:30 AM > To: Eric Tremblay ; users@dpdk.org > Cc: zhihong.wang@intel.com; maxime.coquelin@redhat.com > Subject: Re: [dpdk-users] Virtio-user exceptional path performance >=20 > On Tue, Sep 04, 2018 at 05:54:20PM +0000, Eric Tremblay wrote: > > Hello, > >=20 > > I am testing the performance capabilities of the virtio-user exceptiona= l path for use in container networking scenarios. I am trying to reproduce = the results obtained in Test Case 1 described in the paper "VIRTIO-USER: A = New Versatile Channel for Kernel-Bypass Networks". That is, I am creating = two virtio-user vdevs in testpmd, putting each one in separate network name= spaces and running iperf3 between the two. However, I am unable to obtain t= he near 25Gbps throughput shown in the paper. Instead, I obtained a mere 3G= bps. Has anyone else been able to reproduce these results? My understanding= is that this type of virtual device takes advantage of both checksum offlo= ading and LRO in order to get such high throughput. However, for some reaso= n, I am unable to use RX checksum offloading nor LRO in my setup. If I spec= ify the --enable-lro and --enable-rx-cksum options in testpmd (as shown her= e https://doc.dpdk.org/guides-17.11/howto/virtio_user_as_exceptional_path.h= tml), the tap device is never created in the kernel. If I do not specify th= ese options, the tap is created correctly but the rx-checksum and LRO are o= ff and cannot be turned on using ethtool (they are marked as [fixed]). >=20 > Somehow below fix isn't backported to 17.11 while the commit it fixed was= backported. >=20 > https://git.dpdk.org/dpdk/commit/?id=3Dbce7e9050f9b > commit bce7e9050f9b ("net/virtio-user: fix start with kernel vhost") >=20 > Please apply above fix locally and see if it works. >=20 > Thanks >=20 > >=20 > > Does anyone have any idea what may be preventing me from taking advanta= ge of checksum offloading and LRO? Also, I am I right in assuming that this= is the reason why the performance is so poor or could there be another pro= blem with my setup? I am using DPDK 17.11 on CentOS 7.5. Any help would be = appreciated. > >=20 > > Regards, > >=20 > > Eric > >=20