From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) by dpdk.org (Postfix) with ESMTP id 6F6112E83 for ; Fri, 22 Apr 2016 09:36:47 +0200 (CEST) Received: by mail-wm0-f52.google.com with SMTP id u206so12925621wme.1 for ; Fri, 22 Apr 2016 00:36:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=X93ldklw/A84mB+aWrGJwnmLb+KqkpesRn7YbhAUvcM=; b=t8m2gIryey3PbYvFghrr1yo5AGwC9mN0Z7FNKpf2ohSio8qkuc2nD6P8wjnWSUo6c/ 6PoZ54F6XhpfNu+8sDs5lxwt3lMBuAsetQoIBG7mDJWw6SjStE2tnRWhNF+YPxqJ0QXX MqPd2QnHEslNBsLpmw7WhG49P3Wa6oe2WeVAuOUuZY8jcKHYzBlsSuSRXfgCPlPQ6l/A odrUYUpR+14uOn+vcvjG+r4ZIvOqzwZ81x8nZ58as9YkWZRMOxAiYe00OrJyynTIj5Ow mMPjTIs6hmffGBrSoaRnRty15wofWJmoCcVLeJT7VeIxM4HszCRWG0AYbKuiO4gUXKnR TEug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=X93ldklw/A84mB+aWrGJwnmLb+KqkpesRn7YbhAUvcM=; b=hIEoL+T4qGKYEBsFWeBVz6ZzXSKozdKV2SdV0BN7wZOTVN9eVR4CmtWGzMmi8iniYh Lyy1rb77y3WH7iN07bFpDRLJQrdAkOc+ueMdMLx9m7JkdO9wjddQPcqXz9ZQm6gNrzyI jibcN1byET99LsxwuZ6Kw/h+brjesXndaL2XeV6jtDfcAoFkf9PcTVff1Q7Qg/JXxYk1 oouXRqV70PX5Dii/+zpfdYwptgHUI0c22sGnl6wYJOcIeKDh5nd0R2D/g/1xn9sJ57T8 wV68pYKA2ocsqp4c9mpOJmzvMC03Hh9v83+svnkJY2uNa+oHTEKxXQnZAQJPgxM7oe3G 56mw== X-Gm-Message-State: AOPr4FXxpzJVf085HCiHgxN4UKFmbKwIVGj/BOIDhFOLDzYri+TgkRlCsgMzg81r+JxuaSmOKbXqXmPRHuayeIcA X-Received: by 10.194.103.98 with SMTP id fv2mr19750727wjb.23.1461310607238; Fri, 22 Apr 2016 00:36:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.96.2 with HTTP; Fri, 22 Apr 2016 00:36:27 -0700 (PDT) In-Reply-To: <5719B370.8070107@intel.com> References: <1446748276-132087-1-git-send-email-jianfeng.tan@intel.com> <1461207396-42742-1-git-send-email-jianfeng.tan@intel.com> <1461207396-42742-3-git-send-email-jianfeng.tan@intel.com> <5719B370.8070107@intel.com> From: David Marchand Date: Fri, 22 Apr 2016 09:36:27 +0200 Message-ID: To: "Tan, Jianfeng" Cc: "dev@dpdk.org" , Huawei Xie , Rich Lane , Yuanhan Liu , "Michael S. Tsirkin" , nakajima.yoshihiro@lab.ntt.co.jp, p.fedin@samsung.com, "Qiu, Michael" , ann.zhuangyanying@huawei.com, Tetsuya Mukawa , nhorman@tuxdrver.com Content-Type: text/plain; charset=UTF-8 Subject: Re: [dpdk-dev] [PATCH v3 2/2] virtio/vdev: add a new vdev named eth_cvio 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, 22 Apr 2016 07:36:47 -0000 Hello, On Fri, Apr 22, 2016 at 7:15 AM, Tan, Jianfeng wrote: > On 4/21/2016 4:51 PM, David Marchand wrote: >> virtio code relies on drv_flags (even updating it while this should be >> per-device). >> So first, virtio should rely on dev_flags. > > > Mainly drv_flags's RTE_PCI_DRV_INTR_LSC, and RTE_PCI_DRV_DETACHABLE bit is > used. I understand the issue, pointed out by you here, that if two virtio > devices are used in a VM, one with feature VIRTIO_NET_F_STATUS, and the > other without feature VIRTIO_NET_F_STATUS (under the case that two vhost > backends are used). Then it leads to uncertainty of the behavior. > > Since the flags has been copied into dev_flags after features negotiated, I > believe we should use dev_flags instead of drv_flags. A patch to fix this > will be sent. Ok. >> The rest needs to be astracted in some virtio ops ? > So with that fix goes, we may make it more clear now. Do you mean this? Well, here, we have what looks like to be two drivers (one pci and one vdev). You tried to keep all this code together, to avoid duplicating it, which sounds sane. But in the end, you are trying to make this work by adding checks where this can't. I am not saying we should duplicate the code, but maybe having some internal virtio ops / abstraction would do the trick and avoid those checks. The reason of those comments is that dev_type in ethdev is going to disappear, see [1] and [2]. Drivers are called through their own specific ethdev/crypto ops and so, those drivers know implicitely that their are either pci or vdev (or whatever in the future) drivers. [1]: http://dpdk.org/ml/archives/dev/2016-April/037686.html [2]: http://dpdk.org/ml/archives/dev/2016-January/031390.html -- David Marchand