From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 73C115913 for ; Tue, 12 Jan 2016 09:51:06 +0100 (CET) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 12 Jan 2016 00:51:05 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,556,1444719600"; d="scan'208";a="858751178" Received: from shwdeisgchi083.ccr.corp.intel.com (HELO [10.239.67.119]) ([10.239.67.119]) by orsmga001.jf.intel.com with ESMTP; 12 Jan 2016 00:51:02 -0800 To: Pavel Fedin , 'Rich Lane' References: <1446748276-132087-1-git-send-email-jianfeng.tan@intel.com> <1452426182-86851-1-git-send-email-jianfeng.tan@intel.com> <058a01d14c7b$5cdc60d0$16952270$@samsung.com> <5693CFE4.4060405@intel.com> <009a01d14d0c$3ab6cd60$b0246820$@samsung.com> <00b101d14d14$bab82510$30286f30$@samsung.com> From: "Tan, Jianfeng" Message-ID: <5694BE75.7010708@intel.com> Date: Tue, 12 Jan 2016 16:51:01 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <00b101d14d14$bab82510$30286f30$@samsung.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: nakajima.yoshihiro@lab.ntt.co.jp, "'Michael S. Tsirkin'" , dev@dpdk.org, ann.zhuangyanying@huawei.com Subject: Re: [dpdk-dev] [PATCH 0/4] virtio support for container 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, 12 Jan 2016 08:51:06 -0000 Hi Fedin, On 1/12/2016 4:39 PM, Pavel Fedin wrote: > Hello! > >> See my reply to "mem: add API to obstain memory-backed file info" for a workaround. With fixes for that and the TUNSETVNETHDRSZ issue I was able to >> get traffic running over vhost-user. > With ovs or test apps? I still have problems with ovs after this. Packets go from host to container, but not back. Here is host-side log (i added also GPA display in order to debug the problem you pointed at): > --- cut --- > ... > --- cut --- > > Note that during multiqueue setup host state reverts back from "now ready for processing" to "not ready for processing". I guess this is the reason for the problem. Your guess makes sense because current implementation does not support multi-queues. From you log, only 0 and 1 are "ready for processing"; others are "not ready for processing". Thanks, Jianfeng > Kind regards, > Pavel Fedin > Expert Engineer > Samsung Electronics Research center Russia > >