From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <prvs=68864e2f6=franck.baudin@qosmos.com>
Received: from mc28.lon.server.colt.net (mc28.lon.server.colt.net
 [212.74.77.108]) by dpdk.org (Postfix) with ESMTP id ADB9E5A64
 for <dev@dpdk.org>; Thu, 10 Sep 2015 14:30:15 +0200 (CEST)
Received: from mc28.lon.server.colt.net (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 3C55FF0270
 for <dev@dpdk.org>; Thu, 10 Sep 2015 13:30:15 +0100 (BST)
Received: from mx3.qosmos.com (unknown [195.68.92.43])
 by mc28.lon.server.colt.net (Postfix) with ESMTPS id 15CFEF026D
 for <dev@dpdk.org>; Thu, 10 Sep 2015 13:30:14 +0100 (BST)
X-IronPort-AV: E=Sophos;i="5.17,504,1437429600"; 
   d="scan'208";a="1867609"
Received: from unknown (HELO cercis.foret) ([10.10.2.42])
 by mx3.qosmos.com with ESMTP; 10 Sep 2015 14:30:12 +0200
To: "Ouyang, Changchun" <changchun.ouyang@intel.com>,
 "dev@dpdk.org" <dev@dpdk.org>
References: <55EE9AFE.1070202@qosmos.com>
 <F52918179C57134FAEC9EA62FA2F962511D06B61@shsmsx102.ccr.corp.intel.com>
From: Franck Baudin <franck.baudin@qosmos.com>
Message-ID: <55F177D4.5010701@qosmos.com>
Date: Thu, 10 Sep 2015 14:30:12 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <F52918179C57134FAEC9EA62FA2F962511D06B61@shsmsx102.ccr.corp.intel.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1383-8.0.0.1202-21806.005
X-TM-AS-Result: No--6.157-5.0-31-10
X-imss-scan-details: No--6.157-5.0-31-10
X-TM-AS-User-Approved-Sender: No
X-TMASE-Version: IMSVA-9.0.0.1383-8.0.1202-21806.005
X-TMASE-Result: 10--6.156900-5.000000
X-TMASE-MatchedRID: 4y9/ylYYqyYtjw5zGtj91ALZZHfPgUBPjLOy13Cgb4/adW4iYSMjUae7
 nmhJA6kzXvTfF9EoV2BVL7IDUyWdLu+Qm7Tg9jG3sK+WWVTsOXW4vBuE2X0HlWHZ+cd7VyKXKE8
 l2MCqEIyg2S5zrILUY0sCfbxhzlYc6qLlkd1ucwYdxBAG5/hkW4LLh2/Jcc7eIBaUSuDVWU+oBf
 Cx2HzmBjl9leUjypxeGoJWc9BoyE+Lcas+aYa3DXQEQEU5OIefsEf8CpnIYtlUjspoiX02F2WWd
 1VBI96HqYB+kyCYtxSRk6XtYogiau9c69BWUTGwVnRXm1iHN1bEQdG7H66TyJ8TMnmE+d0Zc3ow
 ORrKFYw1OBEPJrsOlEFxyeujNss8t/O0lHKBysWiX2kxVf4/CR3as+0qcUp74vnDK612+TTbYHY
 GhwUcavyHZFvGhgB7Fffqa+k6LO2hQj5dvZalT5D7leOOMGGE35Kq2sB4VgdWXGvUUmKP2w==
X-TMASE-SNAP-Result: 1.801202.0001-0-1-22:0,12:0
Subject: Re: [dpdk-dev] virtio-net: bind systematically on all non
 blacklisted virtio-net devices
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
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>
X-List-Received-Date: Thu, 10 Sep 2015 12:30:15 -0000

On 09/09/15 04:11, Ouyang, Changchun wrote:
>
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Franck Baudin
>> Sent: Tuesday, September 8, 2015 4:23 PM
>> To: dev@dpdk.org
>> Subject: [dpdk-dev] virtio-net: bind systematically on all non blacklisted
>> virtio-net devices
>>
>> Hi,
>>
>> virtio-net driver bind on all virtio-net devices, even if the devices are used by
>> the kernel (leading to kernel soft-lookup/panic). One way around is to
>> blacklist the ports in use by Linux. This is the case since v2.0.0, in fact since
>> commit da978dfdc43b59e290a46d7ece5fd19ce79a1162
>> and the removal of the RTE_PCI_DRV_NEED_MAPPING driver flag.
> It allows virtio-pmd not necessarily depend on igb_uio, this is which characteristic other pmd drivers don't have.
Thanks for your answer,

So this is the expected behaviour: all virtio interfaces are bound to 
the pmd driver.

Don't you think that dpdk_nic_bind.py should reflect the driver 
behaviour, and that the virtio documentation (still referencing igb_uio) 
be amended?

Regards,
Franck

>
>> Questions:
>>       1/ Is it the expected behaviour?
>>       2/ Why is it different from vmxnet3 pmd? In other words, should't we re-
>> add the RTE_PCI_DRV_NEED_MAPPING to virtio pmd or remove it from
>> pmxnet3 pmd?
>>       3/ If this is the expected behaviour, shouldn't we update
>> dpdk_nic_bind.py (binding status irrelevant for virtio) tool and the
>> documentation (mentioning igb_uio while misleading and useless)?
>>
>> Thanks!
>>
>> Best Regards,
>> Franck
>>
>>
>>