From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout3.w1.samsung.com (mailout3.w1.samsung.com [210.118.77.13]) by dpdk.org (Postfix) with ESMTP id 4E4FDC776 for ; Wed, 29 Apr 2015 09:42:01 +0200 (CEST) Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245]) by mailout3.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0NNK00GMY5DZ3R70@mailout3.w1.samsung.com> for dev@dpdk.org; Wed, 29 Apr 2015 08:41:59 +0100 (BST) X-AuditID: cbfec7f5-f794b6d000001495-57-55408b4c37b3 Received: from eusync2.samsung.com ( [203.254.199.212]) by eucpsbgm2.samsung.com (EUCPMTA) with SMTP id DA.75.05269.C4B80455; Wed, 29 Apr 2015 08:42:04 +0100 (BST) Received: from localhost ([106.109.131.58]) by eusync2.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPA id <0NNK00DJ35DY6P80@eusync2.samsung.com>; Wed, 29 Apr 2015 08:41:59 +0100 (BST) Date: Wed, 29 Apr 2015 10:41:51 +0300 From: Nikita Kalyazin To: Zoltan Kiss Message-id: <20150429074151.GA17375@kalyazin.rnd.samsung.ru> References: <20150427115422.GI28809@kalyazin.rnd.samsung.ru> <553E6344.6030104@linaro.org> <553F7BF9.1010505@linaro.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-disposition: inline In-reply-to: <553F7BF9.1010505@linaro.org> X-Priority: 3 User-Agent: Mutt/1.5.23 (2014-03-12) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsVy+t/xK7o+3Q6hBut3ali8+7SdyaJ95lkm i23Hqh2YPX4tWMrqsXjPSyaPO9f2sAUwR3HZpKTmZJalFunbJXBlrJ91k7HgskDFxL6zTA2M TbxdjBwcEgImEvsanLoYOYFMMYkL99azdTFycQgJLGWUuP7uHzOE85VRYsGmM+wgVSwCqhLX bn5lB2lmE9CTOH06GCQsIqAhseLNPTYQm1nAXWLdv0lg5cIC+hLzz+8Cs3kFbCSW32lggph5 jFHi298mFoiEoMSPyfdYQGYyC6hLTJmSCzFHWuLR3xlgqzgFtCSmf1eGuJNXYkb7U7BOUQEV iSsT3rJPYBSchWTQLIRBs5AMWsDIvIpRNLU0uaA4KT3XSK84Mbe4NC9dLzk/dxMjJHS/7mBc eszqEKMAB6MSD6+EiUOoEGtiWXFl7iFGCQ5mJRHeT41AId6UxMqq1KL8+KLSnNTiQ4zSHCxK 4rwzd70PERJITyxJzU5NLUgtgskycXBKNTAyKRjpLBMXkDgxPzh8pfDRn5c0fQy4r+/+cao8 wsPmpp3eHFept4WTFc/uMPL31rXbn+3wyuJSs3Xt5hMPd/EvDJg8/f9OvRypjpprjfkfta5G HFh6pU7qcduPDLHKUwcv/1Sa9Tu+YqP/4af7AgKmMPQWmOxcFpuzyNBznWTZ2nm77jJ333mm xFKckWioxVxUnAgAFxT2gVkCAAA= Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] data copy in vhost-user 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, 29 Apr 2015 07:42:01 -0000 Zoltan, Huawei, Thank you for your replies. -- Best regards, Nikita Kalyazin, n.kalyazin@samsung.com CE OS Group Samsung R&D Institute Russia Tel: +7 (495) 797-25-00 #3816 Tel: +7 (495) 797-25-03 Office #1501, 12-1, Dvintsev str., Moscow, 127018, Russia On Tue, Apr 28, 2015 at 01:24:25PM +0100, Zoltan Kiss wrote: > > > On 28/04/15 02:22, Xie, Huawei wrote: > > > > > >> -----Original Message----- > >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Zoltan Kiss > >> Sent: Tuesday, April 28, 2015 12:27 AM > >> To: Nikita Kalyazin; dev@dpdk.org > >> Subject: Re: [dpdk-dev] data copy in vhost-user > >> > >> > >> > >> On 27/04/15 12:54, Nikita Kalyazin wrote: > >>> Hi, > >>> > >>> > >>> As far as I understand, DPDK vhost-user implementation requires data copy > >> for either RX or TX (rte_vhost_dequeue_burst() and > >> rte_vhost_enqueue_burst()). It means that two data copies are needed to > >> transfer a packet from one VM to another. > >>> > >>> Why is not it possible to eliminate one of the copies (e.g., > >> rte_vhost_enqueue_burst() might set up a reference at vring descriptor to > >> mbuf's data rather than copying the data)? > > This had been added to the to-do list. We could delay the copy until the real copy is needed. > >> > >> I'm just guessing, but in case of VM-to-VM traffic the receiving one > >> could hold onto the buffer indefinitely, preventing the sender to reuse > >> the buffer. That could lead to a DoS in some cases, and shutting down > >> the sender would be also tricky. At least in case of Xen > >> netback/netfront that's the reason. A reasonable solution for this > >> problem is to make sure the buffer is swapped out with a copy after a > >> finite time. > > Do you mean we associate a timeout for the buffer? > Yes, I think xen-netback had such a version once, but it was removed. As > far as I know the overhead and complexity of handling these timeouts > were too severe. > I might be wrong about this, I don't know if this problem applies here > as well or not. > > >> > >> Regards, > >> > >> Zoltan