From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 2D65C567E for ; Thu, 3 Dec 2015 07:02:42 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga101.jf.intel.com with ESMTP; 02 Dec 2015 22:02:42 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,376,1444719600"; d="scan'208";a="699275942" Received: from yliu-dev.sh.intel.com ([10.239.66.49]) by orsmga003.jf.intel.com with ESMTP; 02 Dec 2015 22:02:39 -0800 From: Yuanhan Liu To: dev@dpdk.org Date: Thu, 3 Dec 2015 14:06:08 +0800 Message-Id: <1449122773-25510-1-git-send-email-yuanhan.liu@linux.intel.com> X-Mailer: git-send-email 1.9.0 Cc: "Michael S. Tsirkin" , Victor Kaplansky Subject: [dpdk-dev] [PATCH 0/5 for 2.3] vhost rxtx refactor 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: Thu, 03 Dec 2015 06:02:42 -0000 Vhost rxtx code is derived from vhost-switch example, which is very likely the most messy code in DPDK. Unluckily, the move also brings over the bad merits: twisted logic, bad comments. When I joined this team firstly, I was quite scared off by the messy and long vhost rxtx code. While adding the vhost-user live migration support, that I have to make fews changes to it, I then ventured to look at it again, to understand it better, in the meantime, to see if I can refactor it. And, here you go. The first 3 patches refactor 3 major functions at vhost_rxtx.c, respectively. It simplifies the code logic, making it more readable. On the other hand, it reduces code size, due to a lot of same code are removed. Patch 4 gets rid of the rte_memcpy for virtio_hdr copy, which nearly saves 12K bytes of code size! Till now, the code has been greatly reduced: 39348 vs 24179. Patch 5 removes "unlikely" for VIRTIO_NET_F_MRG_RXBUF detection. Note that the code could be further simplified or reduced. However, judging that it's a first try and it's the *key* data path, I guess it's okay to not be radical and stop here so far. Another note is that we should add more secure checks at rxtx side. It could be a standalone task for v2.3, and this series is more about refactor, hence I leave it for future enhancement. --- Yuanhan Liu (5): vhost: refactor rte_vhost_dequeue_burst vhost: refactor virtio_dev_rx vhost: refactor virtio_dev_merge_rx vhost: do not use rte_memcpy for virtio_hdr copy vhost: don't use unlikely for VIRTIO_NET_F_MRG_RXBUF detection lib/librte_vhost/vhost_rxtx.c | 959 ++++++++++++++++++------------------------ 1 file changed, 407 insertions(+), 552 deletions(-) -- 1.9.0