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 BE48E1C00 for ; Wed, 10 May 2017 23:59:34 +0200 (CEST) Received: by mail-wm0-f52.google.com with SMTP id b84so20057776wmh.0 for ; Wed, 10 May 2017 14:59:34 -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=zzHosQ888c9GRuLdexy2m+uvLwfHVXZHQWiDJdgXoAE=; b=jySmwanWJv8UnZIKajB2881Y5CoBBVRIVsAXvUhjDXiK+TPGvEQRXVExJMggBHEoLJ SqUFhFbkL5SfhWW3zo/xhRpbDofJtTvY+xUnabVAkz+LaC1wpcKjdcwkxxNsaYaq/w/+ 6d5k7J2Xm4fA9FPl78QBt1vjb+uRZyFzPoo6orXJQIzgaPf511WoQ7ULzSd2E+lnhOhp /vInn2Lih8HFtGEWOB9R+vAdq5Z0b7n8kmjoZCWMuQsy6d6/Prs83p8OA0w/HGIZXe81 /Au1q6PLjfYxQ+R/88qdBg8J1zlVCit/F85LO4AywQvwJMUbuuOxl1O7NMftQKmgXZrb 7CBQ== 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=zzHosQ888c9GRuLdexy2m+uvLwfHVXZHQWiDJdgXoAE=; b=Ean2P8fHnjosLa4EFTo9YOagXxv2J2oiGGvdqUBrgzc0NLXdZV/Q13aersvBFPWpbB 5VD721+i9D7YcH+/ErrbNpdfrxLWhfaCcixtkV/v56pkFu/a/JtaUBZNj5EZd9aHCRNP WvUhAmkmtLWzPKAKHWy5IDnMW0w4idtSwuHp+B8/pGQnOiBjfD56LkvKiNtzkpHPo4/7 5mx8Mw/KlDEx6mvxUDMHDCuMCK5Cq50OoqgYf/uTPjJ+JUjkqbEQBrldLYDrr7ySscmD 3fIL4N2s0DUjbeqjA9ateLFh5MCWFbuNYDknsNAGz6BaHqoDH+3K/u5MHKtKlZCY8Ysv oBNQ== X-Gm-Message-State: AODbwcA3Zklke7p07MemBOWAZ1nTWIYWMqcOZEIKoqYtSHyYgAFb+in7 aA62wlRrvgDSlFHt X-Received: by 10.28.206.67 with SMTP id e64mr2216457wmg.104.1494453574173; Wed, 10 May 2017 14:59:34 -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 a73sm182648wrc.58.2017.05.10.14.59.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 May 2017 14:59:33 -0700 (PDT) Date: Wed, 10 May 2017 23:59:27 +0200 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Stephen Hemminger Cc: dev@dpdk.org, Maxime Coquelin Message-ID: <20170510215927.GG14914@bidouze.vm.6wind.com> References: <4b1edeb12ff61bdb04a0189be30395589c713dbb.1494420483.git.gaetan.rivet@6wind.com> <1bb0b4a6403e42157ef983f0ee63320ce87a3996.1494430911.git.gaetan.rivet@6wind.com> <20170510105407.0377a27c@xeon-e3> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170510105407.0377a27c@xeon-e3> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH v2] devargs: announce ABI change for device parameters 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: Wed, 10 May 2017 21:59:35 -0000 On Wed, May 10, 2017 at 10:54:07AM -0700, Stephen Hemminger wrote: >On Wed, 10 May 2017 17:46:10 +0200 >Gaetan Rivet wrote: > >> The PCI and virtual bus are planned to be moved to the generic >> drivers/bus directory in v17.08. For this change to be possible, the EAL >> must be made completely independent. >> >> The rte_devargs structure currently holds device representation internal >> to those two busses. It must be made generic before this work can be >> completed. >> >> Instead of using either a driver name for a vdev or a PCI address for a >> PCI device, a devargs structure will have to be able to describe any >> possible device on all busses, without introducing dependencies on >> any bus-specific device representation. This will break the ABI for this >> structure. >> >> Additionally, an evolution will occur regarding the device parsing >> from the command-line. A user must be able to set which bus will handle >> which device, and this setting is integral to the definition of a >> device. >> >> The format has not yet been formally defined, but a proposition will >> follow soon for a new command line parameter format for all devices. >> >> Signed-off-by: Gaetan Rivet > >I understand why having a union of all bus types is an issues since it >means that if a new bus type (like VMBUS with GUID) has a bigger value >then the existing representation would break. > >Perhaps give an example of what the new model would look like? Two functionalities from the EAL are currently still dependent on bus-specific implementation from vdev and PCI: attach/detach and device argument parsing. attach/detach is currently being reworked by Jan Blunck. I am handling the device parsing. Device parsing consists in two core functionalities: parsing a device name and storing the resulting information. The semantic of validating a device from a bus PoV is to report whether it would be able to parse the given name and generate information relevant to its implementation. The model is thus similar to that of the driver probe within a bus: if a bus returns success on validate, then we register this bus as the handler for this device. Otherwise, we try other busses. We only have to keep the textual representation of the device within the devargs, given that the bus is the one capable later on to parse it and re-generate its internal representation for scanning / probing purposes. So the model is pretty straightforward: a new rte_bus method and a purely textual representation of devices within rte_devargs. One problem that remains is the possible ambiguity regarding device names. Several separate teams will maintain their busses and nothing prevents the device syntax of one bus to conflict with that of another one. Two possible approaches regarding a generic device name syntax: * Explicit bus-name header + Non-ambiguous, future-proof. - Forces scripts, tests and users to be updated everywhere. eg. --dev "virtual:net_ring0" --dev "pci:0000:00:02.0" * Best effort + Maintains backward compatibility for device parameters. - Possible ambiguities if conflicting device name syntaxes. eg. --dev "net_ring0" --dev "pci:0000:00:02.0" The bus name separator must be carefully considered. ':' plays nice in scripts and complex command lines, but obviously conflicts with the PCI device syntax. The compromise option seems appealing, but I think that the probability of conflicts between bus names and device syntax is pretty high. What's missing is the "whitelisted/blacklisted" flag. This is considered in the design, but this email is starting to get long (using -w and -b instead of --dev is always possible, the question is whether an evolution here could be useful). This new syntax will be proposed alongside the new rte_bus method. I will send the relevant patches pretty soon. I have a dependency on the work from Jan Blunck however and I might wait for him to submit his patches first. Probably next week. -- Gaëtan Rivet 6WIND