From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f193.google.com (mail-wr0-f193.google.com [209.85.128.193]) by dpdk.org (Postfix) with ESMTP id ECD28A84E for ; Tue, 23 Jan 2018 17:08:29 +0100 (CET) Received: by mail-wr0-f193.google.com with SMTP id p6so1164452wrd.0 for ; Tue, 23 Jan 2018 08:08:29 -0800 (PST) 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=x/omKGMOXV2OwqnWyMQ0oGy7hKwWNVWcRjeGcMSTXlw=; b=zVjfPamQXRIInIsCQQlrGXsmjTX4SrOufkL0wsCoUBf+yXehI+3q0AtIRE17hh+p3q R5hw7NYJAiKcUHC/pR7NAX6TK7uIE5CUsOOvJ/5gXbImAjsL9/W3MLwc/DLP9LER1PJC sP/xw5XilAB/udM+VOfchoWZl/wmHx7ABwpOQzu+JtPkl2LDWJkl7uIbcOZIzzF8CXr0 zkZS1sleJiiUKl/y2Mp5KvsDH1zAD7Ur4dz6hhApZ5cAuDohUrZYZtO5xuDkqSTZTdEG o7dCwJlEshtSdhpKGfie3clEgaAfM6T0R9kMGAneYL4LY5tJO5gxnFsahHSM8/fjpTAS rMtg== 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=x/omKGMOXV2OwqnWyMQ0oGy7hKwWNVWcRjeGcMSTXlw=; b=FXeablW7A29jTWnSApLj7DCISSXfpRAqjJd/KCSJ7cG9o5z+ZCPbpiNXVUsE21C5Zg rgGtKAHDhbGZ6sPneCEE3G0I0FelPfGzWvN9WkI9CJrlHMW4NLc9aimsajidORHM1uvW f1VI5g4AOCaCwcikv2eG0YXhF7k+wMJjo/125E2vOd7voIECGRB4zxisCiyuooX7WMod tQMC7I8nNEDsPD1QB4A/vq3jYcUa18ys3Jf878Y4THGDUzRJyYjMpPpVLTJxYWNr7akl EHRyziH9sEzB0RED2EDblKC3ObwpyAtOQIziojk/5//483tV0v8uGFrIpQKxe/7VBvJo zdzw== X-Gm-Message-State: AKwxytfaKatz4G9UWjZVSkwlSX1rCmeqiG8h/IUFR4H6gfTmvX2NKpHe KqqZQ100JT44CTPK3v0E+Sh8cg== X-Google-Smtp-Source: AH8x224sTp0ky3qzMM2OyhotJHUx2bwcVaDsEq8kHH3twnrhfKJ6IrlpUbwa+nJFhMOmyxBM+Ol2eQ== X-Received: by 10.223.153.52 with SMTP id x49mr2881618wrb.195.1516723709298; Tue, 23 Jan 2018 08:08:29 -0800 (PST) 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 v198sm7450768wmv.39.2018.01.23.08.08.28 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 23 Jan 2018 08:08:28 -0800 (PST) Date: Tue, 23 Jan 2018 17:08:16 +0100 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Thomas Monjalon Cc: Yuanhan Liu , Ferruh Yigit , dev@dpdk.org Message-ID: <20180123160816.uvsvegtltmzrr4yi@bidouze.vm.6wind.com> References: <1516114218-21501-1-git-send-email-yliu@fridaylinux.org> <20180118094623.gu5ahrfd75b5gcct@bidouze.vm.6wind.com> <20180123124602.GS29540@yliu-mob> <17059484.9s6tGoQGou@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <17059484.9s6tGoQGou@xps> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [PATCH] doc: document the new devargs syntax 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: Tue, 23 Jan 2018 16:08:30 -0000 Hi Yuanhan, Thomas, On Tue, Jan 23, 2018 at 03:29:34PM +0100, Thomas Monjalon wrote: > 23/01/2018 13:46, Yuanhan Liu: > > On Thu, Jan 18, 2018 at 10:46:23AM +0100, Gaëtan Rivet wrote: > > > On Thu, Jan 18, 2018 at 09:46:29AM +0100, Thomas Monjalon wrote: > > > > 18/01/2018 08:35, Yuanhan Liu: > > > > > On Wed, Jan 17, 2018 at 12:34:08PM +0000, Ferruh Yigit wrote: > > > > > > So does it make sense to separate them logically? Perhaps as "device identifier" > > > > > > and "device args". > > > > > > > > > > Then I think it returns back to the old issue: how could we identify a > > > > > port when the bus id (say BDF for PCI bus) is not enough for identifying > > > > > a port? Such case could happen when a single NIC has 2 ports sharing > > > > > the same BDF. It could also happen with the VF representors that will > > > > > be introduced shortly. > > > > > > > > Yes, the device matching syntax must include bus category, class category > > > > and driver category. So any device can be identified in future. > > > > > > > > But I think Ferruh is talking about separating device matching > > > > (which is described in this proposal) and device settings > > > > (which are usually mixed in -w and --vdev options). > > > > I agree there are different things and may be separate. > > > > They could share the same syntax (bus/class/driver) but be separate > > > > with a semicolon: > > > > matching;settings > > > > > > Can you give an example? > > > > Let's take port addition in OVS-DPDK as an example. It happens in 2 > > steps: > > - port lookup (if port is already probed) > > - dev attachment (if lookup fails) > > > > And also let's assume we need probe a ConnectX-3 port. Note that for > > ConnectX-3, there are 2 ports sharing the same PCI addr. Thus, PCI > > BDF is not enough. And let's assume we use another extra property > > "port". > > > > If the proposal described in this patch is being used, the devarg > > would look like following: > > > > bus=pci,id=04:00.0/class=eth,port=0/driver=mlx4,mlx4_arg_A=val,... > > > > Then "bus=pci,id=04:00.0/class=eth,port=0" will be used for lookup, > > It means we are looking for a port with PCI BDF == 04:00.0 AND > > port == 0 (the first port of the 2 ports). > > > > Note that in my proposal the driver category is not intended for lookup. > > If any properties needed be looked in the driver category, they would > > probably need be elevated to the class category. > > It is not my thought. > I think we should be able to use bus, class and driver properties for lookup. > We can imagine doing a lookup on a driver specific id, which is not > candidate to elevation to the class category. > This means having a new set of ops for drivers to implement (get / set on specific properties -- configuration items). > > If port not found, then the whole string will be used for dev attachment. > > It means we are attaching a port with PCI BDF == 04.00.0 AND > > port == 0 (the 2nd port will not be attached). > > > > > > And here is how the devargs would look like if "matching;settings" is > > being used: > > > > bus=pci,id=04:00.0/class=eth,port=0;bus=pci,id=04:00.0/class=eth,port=0/driver=mlx4,mlx4_arg_A=val,... > > > > The part before ";" will be used for lookup and the later part will be > > used for attachment. It should work. It just looks redundant. > > It does not have to be redundant. > It can be: > bus=pci,id=04:00.0/class=eth,port=0;driver=mlx4,mlx4_arg1=settings1,... > Did you mean > bus=pci,id=04:00.0/class=eth,port=0;class=driver,name=mlx4,mlx4_arg1=settings1,... Here? Or is it that you "elevated" driver to be a property of the eth class, and then immediately chained with driver parameters without declaring the new driver class? > Another example, setting the MAC address: > bus=pci,id=04:00.0/class=eth,port=0;class=eth,mac=00:11:22:33:44:55 So, I guess this ";" syntax is meant for a user to provide once and for all a device string: perhaps on the command line, or programmatically. It would be used first for EAL init, then reused as-is (the entire string) for lookup / port matching afterward. I think this is forcing the user to keep in mind a logic that should be abstracted away ("Here I am writing for init time, here I am writing for matching -- but I need to put it at the same place for 'reasons'"). I think mashing those two concepts together introduce complexity, and I think keeping them separate is user hostile as the devargs that was used for initializing a device cannot be re-used afterward for matching the device that resulted from this initialization string. Drivers answers to a specific API (ethdev, cryptodev, ...), to create standardized objects in response to parameters that are given to them for init. I think matching properties should be restricted to higher classes (bus, eth/crypto), while the driver class should be left free-form and to the responsibility of the PMD itself (while having the proper libraries for helping parsing safely, thus driving developpers toward similar syntaxes, while not forcing them in those). Match could be performed on bus / eth classes only, while init could use elements of the three classes. For simplicity, the same syntax rules could be enforced at all level, or for flexibility some leeway could be left on the most specific (driver). -- Gaëtan Rivet 6WIND