From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f182.google.com (mail-wr0-f182.google.com [209.85.128.182]) by dpdk.org (Postfix) with ESMTP id 16DE32B99 for ; Tue, 5 Dec 2017 18:22:17 +0100 (CET) Received: by mail-wr0-f182.google.com with SMTP id k61so1125614wrc.4 for ; Tue, 05 Dec 2017 09:22:17 -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:in-reply-to; bh=GYU0PMPznrZeWZRDYXVLL/wpaJOa3zgyC2mvpLU11t8=; b=UmokdNy2Asfj1F0O6BXX4jEicHaMMNK2lYWY4XlTyoX0Xy7cuCSdqlIvnlb5JVHS7D XYGaOurszt8Nei42EHnt/WEJd3prxvLHQZyVGNPIVZIWhiWinfV4Vcq0bpolPTeHb3AC Ovg8LAMdejUTP/oWXlVh2dyQ4LgtMuYfUj6xpZYzi5m4cHyugUW0kq+ECYRVQGsGn4MY 2w2vFP/LD5NAOYAv7JjmBsh7tsPUqLw2ZDgnvlXrR0ddUgJ7EJSHipGC9Dg5Ue8LMbn2 7LVSxLfGxFSVW4d03ow9wUlP7RJfoo+iqRzsb1yO7q0O/uYUJOHDGRNh4T97am3fM6Dm 3keQ== 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:in-reply-to; bh=GYU0PMPznrZeWZRDYXVLL/wpaJOa3zgyC2mvpLU11t8=; b=Nsq6Pj+ec7YXaH3bMGxytBKjR47G0hp96r5i1O+CJLmn3Bg6L8IEaoMTSAp8jblrFa KIMkZiZgEzk8110nIBMvfHL+c5UkUdNI2Boe412jNJkUjyJVQ5EQ8dkjcB6mTzDoTVb0 MpJ43XAONzGt+NtF2o9eIIVeC+CWckdMJsvVW79qWxi/pCh6WQ8kHgj63SgAK1LOWYUF bhpb3vfTrXiMwkteQ4JGzosQe0IRejoqx/kNm4cghrcogrr+TnXy+S6WxS3a6Zy2aEjY qQ1DzXfXwnOkVhbeNIVuQ6dndjkGJLgE+8s3ugt0RPgKK+XhNix7J2YX6lFaxIW945sV z5GA== X-Gm-Message-State: AJaThX70GyqC5UblOG20l8ZM4RR4kUiOSYuu8tt5U7/uXirQOZRzPszn fOjzRFk3vcuuEnStVoTTslgUCw== X-Google-Smtp-Source: AGs4zMaUbd/Es7t00lgkjOH9+d8bDyPoLAjWDDUM14hU9knVJknfyztujZqr8qvhFJV0LbxVbCQldw== X-Received: by 10.223.156.146 with SMTP id d18mr17220472wre.161.1512494537625; Tue, 05 Dec 2017 09:22:17 -0800 (PST) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id x133sm1100693wmd.44.2017.12.05.09.22.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Dec 2017 09:22:16 -0800 (PST) Date: Tue, 5 Dec 2017 18:22:05 +0100 From: Adrien Mazarguil To: Thomas Monjalon , Yuanhan Liu Cc: =?utf-8?Q?Ga=C3=ABtan?= Rivet , Stephen Hemminger , dev@dpdk.org, Ciara Loftus , Kevin Traynor , hemant.agrawal@nxp.com, Mohammad Abdul Awal , Declan Doherty Message-ID: <20171205172205.GQ4062@6wind.com> References: <1512027330-30030-1-git-send-email-yliu@fridaylinux.org> <4433948.XFY0rnHxgs@xps> <20171205135831.GC9111@yliu-dev> <12208973.eJueFS28lF@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <12208973.eJueFS28lF@xps> Subject: Re: [dpdk-dev] [PATCH] [RFC] ether: standardize getting the port by name 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, 05 Dec 2017 17:22:18 -0000 On Tue, Dec 05, 2017 at 04:28:00PM +0100, Thomas Monjalon wrote: > 05/12/2017 14:58, Yuanhan Liu: > > On Tue, Dec 05, 2017 at 02:20:05PM +0100, Thomas Monjalon wrote: > > > 05/12/2017 12:04, Adrien Mazarguil: > > > > > > > Hi Yuanhan, > > > > > > > > > > > > > > On Mon, Dec 04, 2017 at 09:55:31PM +0800, Yuanhan Liu wrote: > > > > > rte_devargs is identified by the name (pci id for pci device). It also > > > > > includes other driver specific key-value options. It's not clear for the > > > > > user to know which one (or few) of them should be used together with the > > > > > PCI id to identify a specific port. For example, as you mentioned, in > > > > > mlx4, it's "pci_id,port=x". It could be something else in other drivers. > > > > > > > Just for information, this "port=x" argument in mlx4 is consistent with the > > > > value found in /sys/class/net/ethX/dev_port under Linux. If we choose to use > > > > a port index (instead of a MAC or something else), it would make sense to > > > > standardize it on the same order as given by the host OS for consistency > > > > across all PMDs. > > > > Thanks for the info. > > > > But FYI, for most of other PMDs, such sys file won't exist, as the host > > driver should have been unbind and bind with something like uio. So I > > don't think it applies to all other nics. Sure, I only meant PMDs must implement the same numbering scheme the kernel driver they replace would have used (as exposed through dev_port) for consistency. Note dev_port is always present since Linux 3.15, even with single port/bus address devices, so applications that want to construct -w/-b arguments can rely on that before unbinding devices. > > > Good idea, thanks. > > > > > > > > > > > > I think we will MAC in some cases and port number in others. > > > > Could you list some examples? > > Port number could be used for Mellanox devices. > MAC could be used when devices are already probed in DPDK, > but can it be used for blacklisting? Do we know the MAC address? Problem as described in a prior message (below) is that once a device is initialized, its MAC can be modified while the device name cannot. This will lead to confusion and probably bug reports. Besides, it conflicts with the tap PMD that already takes a "mac" argument to assign a default MAC address, not look for a device with the given MAC. > > > It is important to have identifiers available even without initializing > > > the device. > > > > I don't object that. I think that's good for whitelisting/blacklisting > > before the device initialization. However, once the initialization is > > done, everything could be used to identify a port (say, the mac this patch > > mentioned). > > > > > > Devices with a single port per PCI address would simply use/allow "0". > > > > Yes. > > > > > > > > > > > > > > Actually, this patch also proposes a devarg like naming style: "name[,mac] > > > ". > > > > > What it does try to do is to define a standard syntax, so that the user > > > > > doesn't have to know any driver specific options. > > > > > > > > > > However, the mac address is changeable, leaving this naming inconsistent. > > > > > Well, in practice, PCI id is also changeable. > > > > > > > > > > > > > > > > OTOH, having a consistent naming seems a bit far away from this patch's > > > > > goal: define a standard ethdev naming and leave less harassment to the > > > users. > > > > > > > > > > > > > > I'm not a fan of the MAC naming scheme either, a kind of per-device physical > > > > port index seems more robust and doesn't require much initialization to > > > > determine how many ports are supported by the device and whether the index is > > > > known/valid (particularly given the vast majority exposes only one per bus > > > > address). > > > > I'm not a fan of the MAC naming, neither. The reason this patch proposes mac > > naming is that it's more clear for the user to specify a port. I also agree > > that the port index could be another good option. > > > > One thing I really haven't considered yet is how it becomes when the VF > > reprenstor comes to play? (more guys are cc'ed). Won't VFs come through a separate PCI bus address anyway? Not sure extra care is needed for those. > > > > Would it make sense to have this name usable unmodified as a valid device > > > > (-w) argument, including parameters? > > > > > > Yes we must provide some new key/value arguments for devargs. > > > So it can be used anywhere, including -w/-b options in DPDK > > > or port configuration in OVS. > > > > > > > > > > If so, PMDs could append parameters while probing the underlying device, by > > > > appending ",port=x", ",mac=x" followed by other unspecified parameters with > > > > default values. This could uniquely identify the port _and_ its > > > > configuration in a reusable fashion. > > > > > > > > > > > > Question: should we separate device identification and configuration > > > in the syntax? > > > > Yes, we should. I think we should parse the identification generically, > > and leave the left to the driver. > > So we must take care of a syntax to separate them. > For instance, MAC can be used for identification or configuration (changing > the MAC by user input). Is it worth the hassle though? Simply documenting that "port" and/or "mac" devargs are special and interpreted by both ethdev and the PMD to pinpoint the exact port(s) to use, right? (although I don't recommend "mac" for the above reasons) Keep in mind that with mlx4, the port argument can be provided multiple times to enable them all and generate several ethdev out of a single device argument. Each of them should retain a single "port=X" value in their name. > > > > Otherwise if all we need is unique names, we can use the opposite and much > > > > simpler approach. Let librte_ether assign them sequentially > > > > (e.g. "rte_eth%d", no need for consistency with OS netdevices), applications > > > > can figure the rest based on data structures if needed. > > > > > > No, unique names are not useful / not usable by users. > > > > Agree. We don't really need another unique name, since the port id is > > already unique. > > > > However, I think a consistent naming might be useful: user doesn't have > > to worry it even though MAC is changed or the PCI slot is changed. Contrary to MAC, PCI bus addresses are unlikely to change from within DPDK, there are no devops to modify them. Such an event would be triggered by external means and should be handled through the hot-plug subsystem. The same goes for a physical port ID in my opinion. I think we can only rely on this kind of non-configurable properties. -- Adrien Mazarguil 6WIND