From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f180.google.com (mail-pf0-f180.google.com [209.85.192.180]) by dpdk.org (Postfix) with ESMTP id E23438E93 for ; Mon, 4 Jan 2016 18:24:58 +0100 (CET) Received: by mail-pf0-f180.google.com with SMTP id 65so160140914pff.3 for ; Mon, 04 Jan 2016 09:24:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=M0XwegkP0lL4PgyA3iCcrskCe+/U6T6Wqo4CfQ3mzzI=; b=tcgnsz1Ftqp2hwFMkiuRJBuhPUE82UKwQ6XB8OG+TqlafTD1cltH9jJhVnw0jMevY/ JNKOOxqXrNMrXfh+LlpVKI9fi+KKkr+ko3VEjfWA7/Wy3pK58qJVlxvvlWmEghizz4W2 pbGNre8jLQFcg/WR/HZs07//u69xBpCCUVS9zZQCtVr8MTtYz7nW2zlYmr1y/f9uHGoO 9ggoevalo69hu8QgJOcWDPvUosIgX2L1F+7Oa6n8q+PWpD9tzhBPvrlR1pYiA8QWnnTA Gog2foVixMogIs2Oa1pTRLpGxgRiWaDdppA5nZOdsTnBo4JwQM2xkguCoycW2YA1q1Wr v9nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=M0XwegkP0lL4PgyA3iCcrskCe+/U6T6Wqo4CfQ3mzzI=; b=MBIs4HjyTdkVF35137edkP6jO5psqjk4nNv7xlGf18RK+aP8MOhLy+UagtUE85uX9U HZpYz6//PcC26wfNpTVe/C86Utos4ZKIUHU9oK5kPqGSZKmw2go6280DPRumSV+hqJAB VOaMpxUalMvuJBNQcCO+KMp+PwEjHraa+EiVmDctlZaF4sJWFv3wJleFP9eDztQTvX8A yYKiRt+g4/GaTEjLAkpXLrz47Plg/LxSMmd/apQSXocAjF4Z60oMHHauo3SVSHPYyiow z07BRbLBTOGjAktltcUlGTxUQQ+LnEj6Utd93Ms0csB+zcA7igp6M0bp2XMXYoHP1beA zxmQ== X-Gm-Message-State: ALoCoQnVKI1VLPX2HGZT0c6Yg9ggh+QQORbjxoQu9MuJUvYnmLHAWR0gXJJp1JRo/nunK32EXC5Mb1GEo7ItvSG7LwmZltj6KA== X-Received: by 10.98.44.209 with SMTP id s200mr120023495pfs.2.1451928298201; Mon, 04 Jan 2016 09:24:58 -0800 (PST) Received: from xeon-e3 (static-50-53-82-155.bvtn.or.frontiernet.net. [50.53.82.155]) by smtp.gmail.com with ESMTPSA id xr8sm127518367pab.26.2016.01.04.09.24.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Jan 2016 09:24:58 -0800 (PST) Date: Mon, 4 Jan 2016 09:25:07 -0800 From: Stephen Hemminger To: Huawei Xie Message-ID: <20160104092507.297de1df@xeon-e3> In-Reply-To: <1451843773-103006-1-git-send-email-huawei.xie@intel.com> References: <20151222035041.GA7532@pxdev.xzpeter.org> <1451843773-103006-1-git-send-email-huawei.xie@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v2 0/4] fix the issue that DPDK takes over virtio device blindly 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: Mon, 04 Jan 2016 17:24:59 -0000 On Mon, 4 Jan 2016 01:56:09 +0800 Huawei Xie wrote: > v2 changes: > Remove unnecessary assignment of NULL to dev->data->mac_addrs > Ajust one comment's position > change LOG level from ERR to INFO > > virtio PMD doesn't set RTE_PCI_DRV_NEED_MAPPING in drv_flags of its > eth_driver. It will try igb_uio and PORT IO in turn to configure > virtio device. Even user in guest VM doesn't want to use virtio for > DPDK, virtio PMD will take over the device blindly. > > The more serious problem is kernel driver is still manipulating the > device, which causes driver conflict. > > This patch checks if there is any kernel driver manipulating the > virtio device before virtio PMD uses port IO to configure the device. > > Huawei Xie (4): > eal: make the comment more accurate > eal: set kdrv to RTE_KDRV_NONE if kernel driver isn't manipulating the device. > virtio: return 1 to tell the kernel we don't take over this device > virtio: check if any kernel driver is manipulating the virtio device > > drivers/net/virtio/virtio_ethdev.c | 16 ++++++++++++++-- > lib/librte_eal/common/eal_common_pci.c | 8 ++++---- > lib/librte_eal/linuxapp/eal/eal_pci.c | 2 +- > 3 files changed, 19 insertions(+), 7 deletions(-) > Overall looks good, thanks for addressing this. It would be good to note that VFIO no-IOMMU mode should work for this as well.