From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by dpdk.org (Postfix) with ESMTP id 42DC37E75 for ; Fri, 14 Nov 2014 03:42:57 +0100 (CET) Received: by mail-pa0-f46.google.com with SMTP id lf10so16609922pab.33 for ; Thu, 13 Nov 2014 18:52:58 -0800 (PST) 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 :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=66K88+0nuK1q7xt8rbjr9dXvY0aAtvus99gfj6/hXhc=; b=hMiw0sc2J600KULzHDy5/2FmO0DxtPw99MC5Mxnu5GjxRrF5U9heEqtTA5RmD+ijpn q34sUyF/iR8GwxbHtmU/dv4SUh4EVLy5se81m4WZ6EKv7kbB0A54yvZwKQrpsjULu3UZ zCUx3phvGWTW74Pc8/Vazpp5TdQ8UGA77ePDZwDzuglEgkbOpd7WbgOGcg/gKGIfA1tN zvqKbrx4SFQrbGPPw1twtUZem75HICc6NQ8qXMyZXHR54tNGc1jITYBl7vCXEbe4f2W6 64PZHrvqBUe9LQOo63awtTBvP/KSpOO1wL+KIf6yCefYB/Dq/aYJW/1jQLxvAcoEbo/G B+2Q== X-Gm-Message-State: ALoCoQnJokQ5aZEb7iL1ZmPZVyG5aIaVMVTsA6S3rZhIrkSmoupalM51nU5zjz4zE2uPmhSvRjle X-Received: by 10.70.27.225 with SMTP id w1mr7161728pdg.40.1415933578041; Thu, 13 Nov 2014 18:52:58 -0800 (PST) Received: from [10.16.129.101] (napt.igel.co.jp. [219.106.231.132]) by mx.google.com with ESMTPSA id ql6sm18732819pbb.39.2014.11.13.18.52.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Nov 2014 18:52:57 -0800 (PST) Message-ID: <54656E87.8090801@igel.co.jp> Date: Fri, 14 Nov 2014 11:52:55 +0900 From: Tetsuya Mukawa User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Xie, Huawei" , "dev@dpdk.org" References: <5462DE39.1070006@igel.co.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] vhost-user technical isssues 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: Fri, 14 Nov 2014 02:42:57 -0000 Hi Xie, (2014/11/14 9:22), Xie, Huawei wrote: >> I think so. I guess we need to consider 2 types of restarting. One is >> virtio-net driver restarting, the other is vhost-user backend >> restarting. But, so far, it's nice to start to think about virtio-net >> driver restarting first. Probably we need to implement a way to let >> vhost-user backend know virtio-net driver is restarted. I am not sure >> what is good way to let vhost-user backend know it. But how about >> followings RFC?=20 > I checked your code today, and didn't find the logic to deal with virti= o reconfiguration. Yes. I guess the first implementation of librte_vhost may just replace vhost-example function. Probably vhost-example doesn't think about restarting. Because of this, I haven't implemented. > My thought without new message support: When vhost-user receives > another configuration message since last time it is ready for > processing, then we could release it from data core, and process the > next reconfiguration message, and then re-add it to data core when it > is ready again(check new kick message as before). The candidate > message is set_mem_table. It is ok we keep the device on data core > until we receive the new reconfiguration message. Just waste vhost > some cycles checking the avail idx. For example, let's assume DPDK app1 is started on guest with virtio-net device port. If DPDK app1 on guest is stopped, and other DPDK app2 on guest is started without virtio-net device port. Hugepages DPDK app1 used will be used by DPDK app2. It means the memory accessed by vhost-user backend might be changed by DPDK app2. And vhost-user backend will be crashed. So I guess we need some kinds of reset message. Thanks, Tetsuya