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 3A2225F34 for ; Thu, 28 Jun 2018 10:46:01 +0200 (CEST) Received: by mail-wr0-f182.google.com with SMTP id h10-v6so4612877wrq.8 for ; Thu, 28 Jun 2018 01:46:01 -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:in-reply-to; bh=yN+l4vV3kmdvYznuP+/P2R0SdEhQzVESJ/q1ayoDS8Q=; b=koTYLITpolHvsZnTszOXCkIaSJ9IW5VI4bvTR6+A0zlwvjF0bOjrqn0/yoWZEtUZEi fRv/5I6Il+TB6vJCBpwlEA3C+MuJigUPCXsdDFTpGi6v57pG2Yi6KoMDWlHDoyB8ZZfB Hcag/SxEGQde79/v1fI+wZziqYqZQ8s8ZqLpHqCXEmnAHmwD3UnwB+HSdsbZQXSbPl45 uq3+wY9gmPNXkJE8FaQthHnFszpJ6YPqgklmSInIH4ek4uCMkUj2mBZXm5PIBYhVks6T StlJtRaBlyeuj+RNsMWs77OIXFG+yeiL5HECBG5C4LaMA88sEDgKyFjRh2CTEgyea8lR p7iA== 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=yN+l4vV3kmdvYznuP+/P2R0SdEhQzVESJ/q1ayoDS8Q=; b=dC0xpJIyOrYoHLTSDQzcimWakDgIHRSMKdJPUYmIegYxm8SXE7n08nJTuIiF8tvU++ uEnYuo56AQFtqDiJyi5q5lrUlATVSE2qM2Da52RPE5MKZzBn1u8XN+4HrYjAdaAK90ct O6wW/K56spBAcHYvErXTI8ty/sciO+xeC8qs0wGn9hnGMNHP3Sf2Ga0i5yk+pADp6nHi dT8itmDGgIj/muZ0TrzC+njylMbiRDFfdUU8LzyFeULyFD+pveZqwMcGj8l9d+39y364 AknuBwKLTY9AhW+Ay5hjp0bNE1CzqDwYrOKfi7aCEawTIQ60C1ldyR6csuQKMJ8OHl93 rkAA== X-Gm-Message-State: APt69E3DcNklranHeh7nVpNEZTM+Ul+XF9qubiNAO+LWRQExOYNqdLqG FaU9vcpMjHkoqXBCMzW+D7Yyrg== X-Google-Smtp-Source: AAOMgpf8x7u4J/ww7va6jymvNSI4N4hvIsS8ezkpk8O06evXa04g8IalsvOs68u2pobVV7rqE81SoA== X-Received: by 2002:adf:90e9:: with SMTP id i96-v6mr8060616wri.93.1530175560994; Thu, 28 Jun 2018 01:46:00 -0700 (PDT) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id 137-v6sm12511705wmv.28.2018.06.28.01.45.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Jun 2018 01:46:00 -0700 (PDT) Date: Thu, 28 Jun 2018 10:45:44 +0200 From: Adrien Mazarguil To: Shahaf Shuler Cc: "Xueming(Steven) Li" , "dev@dpdk.org" Message-ID: <20180628084543.GA4025@6wind.com> References: <20180525161814.13873-1-adrien.mazarguil@6wind.com> <20180614083047.10812-1-adrien.mazarguil@6wind.com> <20180614083047.10812-7-adrien.mazarguil@6wind.com> <20180627133228.GV4025@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] [PATCH v2 6/7] net/mlx5: probe all port representors 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: Thu, 28 Jun 2018 08:46:01 -0000 On Thu, Jun 28, 2018 at 06:01:54AM +0000, Shahaf Shuler wrote: > Wednesday, June 27, 2018 4:32 PM, Adrien Mazarguil: > > Subject: Re: [dpdk-dev] [PATCH v2 6/7] net/mlx5: probe all port representors > > > > On Sun, Jun 17, 2018 at 10:15:07AM +0000, Shahaf Shuler wrote: > > > Hi Adrien, > > > > > > Saturday, June 16, 2018 11:58 AM, Xueming(Steven) Li: > > > > Subject: RE: [dpdk-dev] [PATCH v2 6/7] net/mlx5: probe all port > > > > representors > > > > > > > > > -----Original Message----- > > > > > From: dev On Behalf Of Adrien Mazarguil > > > > > Sent: Thursday, June 14, 2018 4:35 PM > > > > > To: Shahaf Shuler > > > > > Cc: dev@dpdk.org > > > > > Subject: [dpdk-dev] [PATCH v2 6/7] net/mlx5: probe all port > > > > > representors > > > > > > > > > > Probe existing port representors in addition to their master > > > > > device and > > > > associate them automatically. > > > > > > > > > > To avoid name collision between Ethernet devices, their names use > > > > > the same convention as ixgbe and i40e PMDs, that is, instead of > > > > > only a PCI > > > > address in DBDF notation: > > > > > > > > > > - "net_{DBDF}_0" for master/switch devices. > > > > > > This is breaking compatibility for application using the device names in > > order to attach them to the application (e.g. OVS-DPDK). > > > Before this patch the naming scheme for non-representor port is "{DBDF}". > > > > > > Can we preserve the compatibility and add appropriate suffix for the > > representor case? > > > > There's one issue if representors are hot-plugged. The name of the master > > device, which happens to be that of the switch domain, cannot be updated. > > The form "net_{DBDF}_0" seems expected for PMDs that support > > representors (see ixgbe and i40e). > > > > Now since representor hot-plugging is not supported yet, I guess we could > > postpone this problem by keeping the old format in the meantime, however > > ideally, these applications should not rely on it. The only safe assumption > > they can make is the uniqueness of any given name among ethdevs. > > > > PCI bus addresses, if needed, should be retrieved by looking at the > > underlying bus object. > > Am not sure I understand. Those application attach the device to the application based on its name, which happens to be the PCI address in case of mlx5. I'm only saying it's not future-proof seeing what happens when they rely on it. Moreover this forces them to convert the name to some binary form instead of e.g. simply checking RTE_DEV_TO_PCI(dev->device)->addr where needed and only use the name as some kind of opaque identifier. > > By the way, while thinking again about a past comment from Xueming [1], > > maybe it's finally time to remove support for multiple Verbs ports on mlx5 > > after all. This should drop another unnecessary loop and the need for the > > unused "port %u" suffix at all while naming the device. > > > > So how about the following plan for v3: > > > > - Adding a patch that drops support for multiple Verbs ports (note for > > Xueming, yes I changed my mind *again* :) > > I am OK w/ that. > > > > > - If you really think this will break OVS (please confirm), > > It will. Out of curiosity, can you point me to the relevant code in OVS? Maybe something can be done on their side. Either ixgbe and i40e are unaffected by the very same change, or they also break OVS, in which case there's an issue we need to solve with the representor interface in DPDK before it's too late. > then when no > > "representor" parameter is provided (regardless of the presence of any > > representors), name format will use the usual "{DBDF}" notation as you > > suggested. > > > > - Otherwise as soon as a "representor" is found on the command line, the > > new > > format will be used, again regardless of the presence of any representors. > > > > - In both cases, representors if any, will be named according to the format > > specified in this patch. > > Can we do the following? > In case representor is found the naming will be DBDF_representor_%d > In case no-representor naming will be DBDF > > Just removing the net prefix. Yes, I'll remove it. We'll standardize on the naming used for ixgbe/i40e only once the above concerns are addressed. -- Adrien Mazarguil 6WIND