From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f179.google.com (mail-wr0-f179.google.com [209.85.128.179]) by dpdk.org (Postfix) with ESMTP id 7DE747CB5 for ; Sun, 9 Jul 2017 13:30:02 +0200 (CEST) Received: by mail-wr0-f179.google.com with SMTP id c11so102505314wrc.3 for ; Sun, 09 Jul 2017 04:30:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=7PdrHpBvo+lwfWeNXQCeKD9SnFQ64ibgBy0VK+ecVjs=; b=FA9y2bSyNY1yGDHsJQGWnlzAAEra16DFQ0Oq9TVoYygSpHkvb2ddis2RUcGLkZ/MjP 6W0pFvFDwPE7h6Xfh3Ff7UZNgszc5Xwlire/p3nH0nekRVwUxJ/3XkUbOOkuOUdmgxax 61n+2xSuHQrsJRC4BUdJdzqh9JVbc+Lf/9QipXH+55AvR7PT7Euykf+BkL9VylM5kkhH Z3WaWrjWTuXzUtXjqwqELYr0jGFGFRZKiN/YYTtPITb8TsTUQh67dVU8wwpICcSDigxJ aAdTiVgHmsgblTSeppgJRRjsRynqKDpod3nbtBT7+yz0Jho7t30dHkoafgISMuxjXnTt qYIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=7PdrHpBvo+lwfWeNXQCeKD9SnFQ64ibgBy0VK+ecVjs=; b=r0RcriRpBrL0z5SgTMF25GuPSH7YPlk8C5Cl5o9W8mRb0yCg36mJih2FF8awwGI+h9 DMnf4Riantfw0BzTJ3EhrVCXa36ssu8WW/lx0GDb66wnxzCeqIGhcxbq1ITiGynKvvMV ItcPsBiKNkwHRXvmY+OnDNe0iyFeuvDFxVpjrq2bm/gs7apMPgU5LtBLrrRB+AA6Lw8n ufx4i1jZ5WosihfJSxWf1ga3fGrv/0zvx7jG96hUlVp1YZ7ndnLAfRukZaFvBu6tig/Y u4v3NEW9PyytPlCtLvAu9qSyRWWz/WXJgybHOaNFLeNwcG80hyIMtBvrxZAkjV8GOoiH EH4w== X-Gm-Message-State: AIVw110l7YjDS7VNGOSzfPjqc9thv5E56SYOdQEy/R2IWBXXvn62SH8i 3pypArFTuDEIalGw X-Received: by 10.28.213.75 with SMTP id m72mr4508223wmg.41.1499599801973; Sun, 09 Jul 2017 04:30:01 -0700 (PDT) Received: from bidouze.vm.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id v2sm12232310wrb.68.2017.07.09.04.30.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Jul 2017 04:30:01 -0700 (PDT) Date: Sun, 9 Jul 2017 13:29:53 +0200 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Jan Blunck Cc: Thomas Monjalon , dev , Stephen Hemminger , Bruce Richardson Message-ID: <20170709112953.GT11154@bidouze.vm.6wind.com> References: <3893726.oUZ9cfT8R6@xps> <4219460.8ez8IeSCfv@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH v7 00/17] Generic devargs parsing 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: Sun, 09 Jul 2017 11:30:02 -0000 On Sun, Jul 09, 2017 at 07:16:45AM -0400, Jan Blunck wrote: > On Sun, Jul 9, 2017 at 6:17 AM, Thomas Monjalon wrote: > > 09/07/2017 10:37, Jan Blunck: > >> On Sat, Jul 8, 2017 at 6:28 PM, Thomas Monjalon wrote: > >> > 07/07/2017 02:04, Gaetan Rivet: > >> >> In this patchset, the representation of devices in rte_devargs is made generic > >> >> to remove some dependencies of the EAL on specific buses implementations. > >> >> Following the device types being characterized by their bus, the DEVTYPE > >> >> flags are updated not to reference virtual / PCI devices anymore. > >> > [...] > >> >> Gaetan Rivet (16): > >> >> net/bonding: properly reference PCI header > >> >> net/bnxt: properly reference PCI header > >> >> net/mlx5: properly reference PCI header > >> >> net/e1000: properly reference PCI header > >> >> net/ixgbe: properly reference PCI header > >> >> net/sfc: properly reference PCI header > >> >> app/testpmd: properly reference PCI header > >> >> test: properly reference PCI header > >> >> dev: device kernel module is a device attribute > >> >> bus: introduce bus scan policies > >> >> devargs: parse bus policies > >> >> devargs: generic device representation > >> >> net/virtio: do not reference device type > >> >> devargs: generic device types > >> >> devargs: introduce cleaner parsing helper > >> >> eal: change whitelist / blacklist command line doc > >> >> > >> >> Thomas Monjalon (1): > >> >> examples/ethtool: properly reference PCI header > >> > > >> > Series applied, except last patch (17), as explained before. Thanks > >> > > >> > >> I wonder why you complain about not having enough reviewers if you > >> anyway ignoring their feedback! > > > > I am not ignoring your feedback at all. > > There are 2 things in this series: > > 1/ decouple devargs and PCI/vdev > > 2/ couple devargs policies to rte_bus > > I agree that we should not have policies in rte_bus (2). > > However it is the only patches we have for now to achieve (1), > > which is a required step to move PCI and vdev as real bus drivers. > > (1) is easy to achieve. I've explained multiple times that devargs shoudl be: > - bus name > - device name > - device arguments > > Somehow I expected that giving suggestions and review comments will > lead to people actively working on this picking up the ideas. I guess > I was mistaken. I'll save my breath and fix it myself. > > The goal is to restrict the devargs to this trifecta, eventually. In the meantime however, the way things have been designed previously forces having the "devtype" (now limited to bus scan policy) coupled with it. It is not possible to remove it without changing the API / usage of EAL parameters. This functionality was not added to other buses. The latent default whitelist mode was simply made explicit. This does not preclude changing it next release. In any case, it makes the issue obvious and allows comments from reviewer to point out those issue clearly. > > As explained in the following email, I prefer progressing on (1) > > and rework (2) in 17.11: > > http://dpdk.org/ml/archives/dev/2017-July/070203.html > > What do you think of my proposal, adding a callback in probe? > > > >> I pointed out multiple times that parsing a device name to deduce the > >> bus is not the right thing to do. > > > > Yes, so we need to change the parameter syntax to make the bus name > > explicit and mandatory. We need a deprecation notice. > > > >> This series also tightly couples rte_devargs to rte_bus. > >> It adds hidden functionality to have > >> blacklist/whitelist mode for all busses and even sticks that > >> functionality on the wrong object (devargs). > > > > Yes, as said above, we must rework it in 17.11. > > -- Gaëtan Rivet 6WIND