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 F32322BE5 for ; Mon, 2 Apr 2018 06:08:38 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Apr 2018 21:08:37 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,393,1517904000"; d="scan'208";a="28809789" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by fmsmga007.fm.intel.com with ESMTP; 01 Apr 2018 21:08:37 -0700 Received: from fmsmsx119.amr.corp.intel.com (10.18.124.207) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 1 Apr 2018 21:08:37 -0700 Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by FMSMSX119.amr.corp.intel.com (10.18.124.207) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 1 Apr 2018 21:08:37 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.166]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.235]) with mapi id 14.03.0319.002; Mon, 2 Apr 2018 12:08:34 +0800 From: "Wang, Xiao W" To: Thomas Monjalon , Maxime Coquelin CC: "Yigit, Ferruh" , "dev@dpdk.org" , "Wang, Zhihong" , "yliu@fridaylinux.org" , "Tan, Jianfeng" , "Bie, Tiwei" , "Liang, Cunming" , "Daly, Dan" , "gaetan.rivet@6wind.com" , "Burakov, Anatoly" Thread-Topic: [PATCH v3 2/4] net/virtio: skip device probe in vdpa mode Thread-Index: AQHTyFBpMBlOrH6bt0Oe8cOgOPTggKPpq7oAgAAicwCAAw8+AA== Date: Mon, 2 Apr 2018 04:08:33 +0000 Message-ID: References: <20180321132108.52464-4-xiao.w.wang@intel.com> <20180331022929.42172-3-xiao.w.wang@intel.com> <1496487c-f3ea-dc34-dee7-dbaf40d54a97@redhat.com> <2836028.8kLeaZ6SVA@xps> In-Reply-To: <2836028.8kLeaZ6SVA@xps> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYTUxZjFkOTYtNjg3NS00Y2RjLWJkNWUtODQ2YzY0OTA0ZTNiIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjIuNS4xOCIsIlRydXN0ZWRMYWJlbEhhc2giOiJJayttYnJJXC8zMXF5b1ZudkYxN2l2M0FjUkpJeDJ5RHZjQU0rMzJ1RkJoTXUwaExJSUFcL2xOQjFDUzZ4bG44bFwvIn0= dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v3 2/4] net/virtio: skip device probe in vdpa mode X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 04:08:41 -0000 Hi Thomas, > -----Original Message----- > From: Thomas Monjalon [mailto:thomas@monjalon.net] > Sent: Saturday, March 31, 2018 9:16 PM > To: Maxime Coquelin > Cc: Wang, Xiao W ; Yigit, Ferruh > ; dev@dpdk.org; Wang, Zhihong > ; yliu@fridaylinux.org; Tan, Jianfeng > ; Bie, Tiwei ; Liang, Cunmin= g > ; Daly, Dan ; > gaetan.rivet@6wind.com; Burakov, Anatoly > Subject: Re: [PATCH v3 2/4] net/virtio: skip device probe in vdpa mode >=20 > Hi, >=20 > 31/03/2018 13:13, Maxime Coquelin: > > On 03/31/2018 04:29 AM, Xiao Wang wrote: > > > If we want a virtio device to work in vDPA (vhost data path accelerat= ion) > > > mode, we could add a "vdpa=3D1" devarg for this device to specify the= mode. > > > > > > This patch let virtio pmd skip device probe when detecting this param= eter. > > > > As we discussed, I would prefer a generic solution at EAL level. >=20 > Please could you explain the requirement and the context? > Can we use RTE_ETH_DEV_DEFERRED state and device ownership? >=20 > Without knowing what's behind, I would say that a PMD should > never skip a device by itself, but let other entities decide > what to do with the probed device (thanks to probe notifications). >=20 IFCVF's vendor ID and device ID are the same as that of virtio net pci devi= ce, with its specific subsystem vendor ID and device ID. The context is IFCVF can be driven by both virtio pmd and IFCVF driver, so we add this devarg to specify if we want the device to work in vDPA mode or not. For vdpa-mode IFCVF, virtio pmd should not take over it, so we let it skip. BRs, Xiao