From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 0EDA11BA60 for ; Thu, 26 Oct 2017 10:53:31 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Oct 2017 01:53:29 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.43,434,1503385200"; d="scan'208,217";a="1210301205" Received: from tanjianf-mobl.ccr.corp.intel.com (HELO [10.67.64.53]) ([10.67.64.53]) by fmsmga001.fm.intel.com with ESMTP; 26 Oct 2017 01:53:27 -0700 To: =?UTF-8?B?546L5b+X5YWL?= , "avi.cohen@huawei.com" , "users@dpdk.org" References: <6DAF063A35010343823807B082E5681F41D22305@mbx05.360buyAD.local> <0d678703-5fbc-c999-0009-4b4b1dfcb20a@intel.com> <6DAF063A35010343823807B082E5681F41D2BFCA@mbx05.360buyAD.local> <6DAF063A35010343823807B082E5681F41D2C525@mbx05.360buyAD.local> From: "Tan, Jianfeng" Message-ID: <030b706c-1566-36de-79cb-74af834f6a65@intel.com> Date: Thu, 26 Oct 2017 16:53:27 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <6DAF063A35010343823807B082E5681F41D2C525@mbx05.360buyAD.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-users] VIRTIO for containers 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: Thu, 26 Oct 2017 08:53:33 -0000 Hi, > [Wang Zhike] I once saw you mentioned that something like mmap > solution may be used. Is it still on your roadmap? I am not sure > whether it is same as the “vhost tx zero copy”. > > Can I know the forecasted day that the optimization can be done? Some > Linux kernel upstream module would be updated, or DPDK module? Just > want to know which modules will be touched. > Yes, I was planning to do that. But found out it helps on user->kernel path; not so easy for kernel->user path. It’s not the same as “vhost tx zero copy” (there are some restrictions BTW). The packet mmap would share a bulk of memory with user and kernel space, so that we don’t need to copy (the effect is the same with “vhost tx zero copy”). As for the date, it still lack of detailed design and feasibility analysis. > 1) Yes, we have done some initial tests internally, with testpmd as > the vswitch instead of OVS-DPDK; and we were comparing with KNI for > exceptional path. > > [Wang Zhike]Can you please kindly indicate how to configure for KNI > mode? I would like to also compare it. > Now KNI is a vdev now. You can refer to this link: http://dpdk.org/doc/guides/nics/kni.html > 2) We also see similar asymmetric result. For user->kernel path, it > not only copies data from mbuf to skb, but also might go above to tcp > stack (you can check using perf). > > [Wang Zhike] Yes, indeed. User->kernel path, tcp/ip related work is > done by vhost thread, while kernel to userthread, tcp/ip related work > is done by the app (my case netperf) in syscall. > > To put tcp/ip rx into app thread, actually, might avoid that with a little change on tap driver. Currently, we use netif_rx/netif_receive_skb() to rx in tap, which could result in going up to the tcp/ip stack in the vhost kthread. Instead, we could backlog the packets into other cpu (application thread's cpu?). Thanks, Jianfeng