From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Tan, Jianfeng" <jianfeng.tan@intel.com>
Subject: Re: [PATCH 0/4] virtio support for container
Date: Tue, 12 Jan 2016 16:51:01 +0800
Message-ID: <5694BE75.7010708@intel.com>
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>
 <CAGSMBPMTCmPvOfCv1RzrCzPK5xNE7oP_WfieyB8gaqD+dNJmGA@mail.gmail.com>
 <00b101d14d14$bab82510$30286f30$@samsung.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: nakajima.yoshihiro@lab.ntt.co.jp, "'Michael S. Tsirkin'" <mst@redhat.com>,
 dev@dpdk.org, ann.zhuangyanying@huawei.com
To: Pavel Fedin <p.fedin@samsung.com>, 'Rich Lane' <rich.lane@bigswitch.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mga09.intel.com (mga09.intel.com [134.134.136.24])
 by dpdk.org (Postfix) with ESMTP id 73C115913
 for <dev@dpdk.org>; Tue, 12 Jan 2016 09:51:06 +0100 (CET)
In-Reply-To: <00b101d14d14$bab82510$30286f30$@samsung.com>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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
>
>