From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by dpdk.org (Postfix) with ESMTP id 0DDD13005 for ; Wed, 9 Nov 2016 13:42:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3412; q=dns/txt; s=iport; t=1478695362; x=1479904962; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=u9BfwvHW/fQQj/C9pcbI0eop49B7Kpl6JkfK1+JA6Cs=; b=j1ho5ZX4OJ4cIj8viUX68MzMI2YSgVbjOcl1X6fKX7FaMpOKYqs1kLk/ NOQo2KkNPbnSIopbiFmG3xI8uqdIxMRhQzZVG5Xn37mKDm0D317CdfSjn PYk7u4ispZRtVOoKlc5aKHzc8tbKy15Ev5TD7QT77VUrt1DH1EmCTQjzL o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BrAQCQGCNY/5xdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgy8BAQEBAR+BVweNNpcKkkeCD4IIhiQCgh4/FAECAQEBAQEBAWIohGE?= =?us-ascii?q?BAQEDASdSBQsCAQgYLjIlAgQOBYhUCLMnUotGAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBHIY+gX2CXYQQCDCDMYIvAQSUToViAZBOkBlJjG2EBgEeN3yDNhyBXXKEfA8?= =?us-ascii?q?XgQqBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,614,1473120000"; d="scan'208";a="345588570" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Nov 2016 12:42:41 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id uA9CgeYr008681 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 9 Nov 2016 12:42:41 GMT Received: from xch-aln-017.cisco.com (173.36.7.27) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 9 Nov 2016 06:42:40 -0600 Received: from xch-aln-017.cisco.com ([173.36.7.27]) by XCH-ALN-017.cisco.com ([173.36.7.27]) with mapi id 15.00.1210.000; Wed, 9 Nov 2016 06:42:40 -0600 From: "Pierre Pfister (ppfister)" To: Maxime Coquelin CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH] virtio: tx with can_push when VERSION_1 is set Thread-Index: AQHSOaLaE7xRhw3lm06CE4fIwNUKH6DPOrsAgAHEGAA= Date: Wed, 9 Nov 2016 12:42:40 +0000 Message-ID: <1FAE01C3-B03F-443A-A77C-579254A07E0E@cisco.com> References: <82834CFE-767C-41B0-9327-E64B8210E076@cisco.com> <46762894-5016-f634-c355-77af881685e6@redhat.com> In-Reply-To: <46762894-5016-f634-c355-77af881685e6@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.42.84] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] virtio: tx with can_push when VERSION_1 is set X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 12:42:42 -0000 Hello Maxime, Sorry for the late reply. > Le 8 nov. 2016 =E0 10:44, Maxime Coquelin a = =E9crit : >=20 > Hi Pierre, >=20 > On 11/08/2016 10:31 AM, Pierre Pfister (ppfister) wrote: >> Current virtio driver advertises VERSION_1 support, >> but does not handle device's VERSION_1 support when >> sending packets (it looks for ANY_LAYOUT feature, >> which is absent). >>=20 >> This patch enables 'can_push' in tx path when VERSION_1 >> is advertised by the device. >>=20 >> This significantly improves small packets forwarding rate >> towards devices advertising VERSION_1 feature. > I think it depends whether offloading is enabled or not. > If no offloading enabled, I measured significant drop. > Indeed, when no offloading is enabled, the Tx path in Virtio > does not access the virtio header before your patch, as the header is mem= set to zero at device init time. > With your patch, it gets memset to zero at every transmit in the hot > path. Right. On the virtio side that is true, but on the device side, we have to = access the header anyway. And accessing two descriptors (with the address resolution and memory fetch= which comes with it) is a costy operation compared to a single one. In the case indirect descriptors are used, this is 1 desc access instead or= 3. And in the case chained descriptors are used, this doubles the number of pa= ckets that you can put in your queue. Those are the results in my PHY -> VM (testpmd) -> PHY setup Traffic is flowing bidirectionally. Numbers are for lossless-rates. When chained buffers are used for dpdk's TX: 2x2.13Mpps When indirect descriptors are used for dpdk's TX: 2x2.38Mpps When shallow buffers are used for dpdk's TX (with this patch): 2x2.42Mpps I must also note that qemu 2.5 does not seem to deal with VERSION_1 and ANY= _LAYOUT correctly. The patch I am proposing here works for qemu 2.7, but with qemu 2.5, testpm= d still behaves as if ANY_LAYOUT (or VERSION_1) was not available. This is = not catastrophic. But just note that you will not see performance in some c= ases with qemu 2.5. Cheers - Pierre >=20 > With offloading enabled, it does makes sense though, as the header will > be accessed. >=20 > This patch is for v17.02 anyway, and we may provide a way to enable and > disable features at Virtio PMD init time by this release. >=20 > Thanks, > Maxime >=20 >>=20 >> Signed-off-by: Pierre Pfister >> --- >> drivers/net/virtio/virtio_rxtx.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >>=20 >> diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virti= o_rxtx.c >> index 724517e..2fe0338 100644 >> --- a/drivers/net/virtio/virtio_rxtx.c >> +++ b/drivers/net/virtio/virtio_rxtx.c >> @@ -925,7 +925,8 @@ virtio_xmit_pkts(void *tx_queue, struct rte_mbuf **t= x_pkts, uint16_t nb_pkts) >> } >>=20 >> /* optimize ring usage */ >> - if (vtpci_with_feature(hw, VIRTIO_F_ANY_LAYOUT) && >> + if ((vtpci_with_feature(hw, VIRTIO_F_ANY_LAYOUT) || >> + vtpci_with_feature(hw, VIRTIO_F_VERSION_1)) && >> rte_mbuf_refcnt_read(txm) =3D=3D 1 && >> RTE_MBUF_DIRECT(txm) && >> txm->nb_segs =3D=3D 1 && >> -- >> 2.7.4 (Apple Git-66) >>=20