From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zoltan Kiss Subject: Re: data copy in vhost-user Date: Mon, 27 Apr 2015 17:26:44 +0100 Message-ID: <553E6344.6030104@linaro.org> References: <20150427115422.GI28809@kalyazin.rnd.samsung.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit To: Nikita Kalyazin , dev-VfR2kkLFssw@public.gmane.org Return-path: In-Reply-To: <20150427115422.GI28809-dOcb+p3lB4ioPJ7u4KOs7jOMi+9Jb/nM@public.gmane.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" 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)? 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. Regards, Zoltan