From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by dpdk.org (Postfix) with ESMTP id 29488C5A4 for ; Tue, 28 Apr 2015 14:24:23 +0200 (CEST) Received: by widdi4 with SMTP id di4so137920237wid.0 for ; Tue, 28 Apr 2015 05:24:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8TeUYm657omTjtsnh/AH4PxhORnsgCShgAx30XZiFRY=; b=Bh86Hnioion/EYXmx/AV97j1xKX7iIA/GP/PHetwXxfXloDqAp1F5YqOTgBR7chUjY VXW4cJMs8Sw0n6jvPr6HRvOYKufLT2GPwjQueMsiUw19GIQXXGzE1h6ytWuXnoOiIpYC RL7Ukex5pwkoW9D3Ltkx/DYvPPmRae+E63BokyXiaebpw9eoSI/9RF/LLK5uZabw/pys qhoD2FOGbew64lrhC+0qISJvVeOuDW4DDRn0KCwkJ2ZxmeXeJJnUXHdXWZo759T7z42/ 5Jkm00RB1eTYbyPN47kqaaVUDqMn5820xZf6NCuyte57MTZ2Nn8K2PReumw9m63Mb+R9 ffmg== X-Gm-Message-State: ALoCoQlNpSizyHX1YwIxPsHwc2Q7lFzKuVtlSdBX1DkPHee04zZhPKFmt1DQO1uUzhg66Gt24ixq X-Received: by 10.180.79.227 with SMTP id m3mr29675356wix.71.1430223862969; Tue, 28 Apr 2015 05:24:22 -0700 (PDT) Received: from [192.168.0.101] ([90.152.119.35]) by mx.google.com with ESMTPSA id gu7sm16162884wib.21.2015.04.28.05.24.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Apr 2015 05:24:22 -0700 (PDT) Message-ID: <553F7BF9.1010505@linaro.org> Date: Tue, 28 Apr 2015 13:24:25 +0100 From: Zoltan Kiss User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Xie, Huawei" , Nikita Kalyazin , "dev@dpdk.org" References: <20150427115422.GI28809@kalyazin.rnd.samsung.ru> <553E6344.6030104@linaro.org> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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: Tue, 28 Apr 2015 12:24:23 -0000 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