From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 468AB2BD1 for ; Fri, 16 Jun 2017 16:20:05 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id EC2B02085F; Fri, 16 Jun 2017 10:20:04 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 16 Jun 2017 10:20:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=L/UsK93MtLZYUG/ NCSEl1DHUMaohFgGnAzWU9X4drjM=; b=UUxpRutEah1T9/oHD9n/fzLzsq5vFX1 fFXsKbZIH8cu79Q+sm7pW+MUrYTu482yA2OCy1QoPiYMMUTZGioaCrReJU0kqSfW wTJKd0zyOyW/xGunRqRdZ9+5vCcYFwzp8/r76zhXkTKgPWrxAypcD1ju+dJuMAlp YGaYo8g5pBG0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=L/UsK93MtLZYUG/NCSEl1DHUMaohFgGnAzWU9X4drjM=; b=MhpO1+7m 5s7KKdKx0k30O3uov2e0puxcvdSnW5tv1SLUbiNGsfdM9qrqsWZHxK5hw95bdPw3 0oohVvCbYylsPUfAeBsgwN7+rXHZifWA5MpPgMACwjVhEzMFvpOPv8K56wsZ8FGy P9kM2b/sNRZr8IC7ntE8snGovU2wy0WPRtEKWX11FywrlCB85Sy7na5Egj2jfThd hlc3GZCGMySM4jwoNwb7n9245bEZ4shO3WJsYXVX8lenY9XLbqOAWwrxrh1PLfRE X6lDt0D7chBhylz8qc8EjyzsvK4J8/YMR/P0wZ4ehka6PheJwj6/Qhu1ATfctakx GFwEgYV/u2E/MQ== X-ME-Sender: X-Sasl-enc: kUoNsukbzDt480fuD4aFvv8LIzdIij9M2mriqlWxU6j/ 1497622804 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 910E37E9E4; Fri, 16 Jun 2017 10:20:04 -0400 (EDT) From: Thomas Monjalon To: Jan Blunck Cc: dev@dpdk.org, Ferruh Yigit , Gaetan Rivet , Tetsuya Mukawa , Declan Doherty Date: Fri, 16 Jun 2017 16:20:03 +0200 Message-ID: <23043433.nqfcUMGdDr@xps> In-Reply-To: <1eae2dda-3fb3-1d46-5d45-1493c1fe1cd4@intel.com> References: <20170510110104.70838-1-ferruh.yigit@intel.com> <136091512.oDuubpNRB2@xps> <1eae2dda-3fb3-1d46-5d45-1493c1fe1cd4@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] eal: remove vdev probe by dev args 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: Fri, 16 Jun 2017 14:20:05 -0000 Please Jan, could you comment? 09/06/2017 11:21, Ferruh Yigit: > On 6/8/2017 9:45 PM, Thomas Monjalon wrote: > > 10/05/2017 13:01, Ferruh Yigit: > >> Virtual device/driver probing done via name. > >> > >> A new alternative method introduced to probe the device with providing > >> driver name in devargs as "driver=". > >> > >> This patch removes alternative method and fixes virtual device usages > >> with proper device names. > >> > >> Fixes: 87c3bf29c642 ("test: do not short-circuit null device creation") > >> Fixes: d39670086a63 ("eal: parse driver argument before probing drivers") > >> > >> Signed-off-by: Ferruh Yigit > >> --- > > [...] > >> static int > >> vdev_probe_all_drivers(struct rte_vdev_device *dev) > >> { > >> const char *name; > >> - char *drv_name; > >> struct rte_vdev_driver *driver; > >> int ret = 1; > >> > >> - drv_name = parse_driver_arg(rte_vdev_device_args(dev)); > >> - name = drv_name ? drv_name : rte_vdev_device_name(dev); > >> + name = rte_vdev_device_name(dev); > > > > It seems you are reverting the commit d39670086a63: > > eal: parse driver argument before probing drivers > > Mostly yes. > > > > > In some cases the virtual device name should be totally different than > > the driver being used for the device. Therefore lets parse the devargs for > > the "driver" argument before probing drivers in vdev_probe_all_drivers(). > > > > Is this "driver" option useless? > > There is already a generic way to probe, why need another method, I > didn't get the motivation but this looks like a hack, only place I found > used is in bonding unit test, which can be switched to generic way > without this support. > > And this is a hidden / an undocumented feature. > > Thanks, > ferruh >