From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45]) by dpdk.org (Postfix) with ESMTP id D374E3777 for ; Mon, 4 Sep 2017 16:41:22 +0200 (CEST) Received: by mail-wm0-f45.google.com with SMTP id f145so5019635wme.0 for ; Mon, 04 Sep 2017 07:41:22 -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=8OfHS6WMXju8uP6UF0pP3g4vbCLUZp00yUXKUHwcAjU=; b=Ulb+oqcYjIsT8JerI1FkeMb4VnzD+fy9n8MBRu64SBVXoyQUSWQ6NNlnSy4SNo3/kq hb08UNVTRQd2WlpYLdSyyddg4PTRob5RgB+sUqbZZWCXJZGm9aSMSV2LeTfIIHGdpHO1 CaK9JMC5YWp9vgqn7IlBuO+n2jVnqi0ix7HRKkgf7sjl8J3WDvS6aZR8qXcKrXR9qSOs NU/QPqpvs7JEt84TXyJCHrFd+DW01CoDYS4LHDH23886nqf7S0a7NeJ7OWeshg1UmWii 435Mg+1Qfi1maG7S2GQhyCKRMx4ougCCqcxqmO1Xkh72XQORd6h0b6O7hF49VG+eHBB9 +Bjw== 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=8OfHS6WMXju8uP6UF0pP3g4vbCLUZp00yUXKUHwcAjU=; b=nW8pxdkRT7RDYaMSbkW2sQMNroXDgJAyKvKJUdJhggrS1ZzluebuHzGf4F8CgjDDMc ms5eydNir9ykc+yRDkry2AFgoYCYqTz15DK9VL6fvdG3lqE94KhC7YNtGM9e8EX4ZoGq gmVp9BV+q930Ud41NEphK3G+4PD0mIc32c76sVy+8/71Br5fNRaVAHdER0JaBQZ/824w RlrSG2HA0RSWRp1m6Lmnz2l12VTyMk6NGRYZhMZz0yVTJhZwqvJprAhT2vLLoOlwoj63 y/uJZVZ/tjLVpxwzyAxGpZIwvEgT/8TyNyBj2zKZPjsuBz7FDFYQp8yxCJnlSePJjS7+ Hxaw== X-Gm-Message-State: AHPjjUg2UQCY0E5jHPz3yw8+PFWJRax4uJcF2x/lmzEpN9Mu9a88j3jj NJU0ypn6k5Gg8Ou7RB0= X-Google-Smtp-Source: ADKCNb4iYCJ+dOMpIRW20VHaflqEyvxRPxQ2YkX6B2YgyJ+f7A+BTxqLIJAKK9bCXNRcQzKvLu7nOQ== X-Received: by 10.28.188.5 with SMTP id m5mr389364wmf.166.1504536082559; Mon, 04 Sep 2017 07:41:22 -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 1sm5201423wrz.76.2017.09.04.07.41.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Sep 2017 07:41:21 -0700 (PDT) Date: Mon, 4 Sep 2017 16:41:12 +0200 From: Adrien Mazarguil To: "Yang, Zhiyong" Cc: "Richardson, Bruce" , "Yigit, Ferruh" , "dev@dpdk.org" , "thomas@monjalon.net" , "Wiles, Keith" , "stephen@networkplumber.org" , Nelio Laranjeiro Message-ID: <20170904144112.GX4301@6wind.com> References: <20170809084203.17562-1-zhiyong.yang@intel.com> <20170904055734.21354-1-zhiyong.yang@intel.com> <20170904055734.21354-2-zhiyong.yang@intel.com> <20170904090658.GA17464@bricha3-MOBL3.ger.corp.intel.com> <20170904131222.GV4301@6wind.com> <59AF69C657FD0841A61C55336867B5B0721CFC11@IRSMSX103.ger.corp.intel.com> <20170904133652.GW4301@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 1/4] ethdev: increase port_id range 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: Mon, 04 Sep 2017 14:41:23 -0000 On Mon, Sep 04, 2017 at 01:59:26PM +0000, Yang, Zhiyong wrote: > Hi, Adrien: > > > -----Original Message----- > > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com] > > Sent: Monday, September 4, 2017 9:37 PM > > To: Richardson, Bruce > > Cc: Yang, Zhiyong ; Yigit, Ferruh > > ; dev@dpdk.org; thomas@monjalon.net; Wiles, Keith > > ; stephen@networkplumber.org; Nelio Laranjeiro > > > > Subject: Re: [dpdk-dev] [PATCH v2 1/4] ethdev: increase port_id range > > > > On Mon, Sep 04, 2017 at 01:17:56PM +0000, Richardson, Bruce wrote: > > > > > > > > > > -----Original Message----- > > > > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com] > > > > Sent: Monday, September 4, 2017 2:12 PM > > > > To: Yang, Zhiyong > > > > Cc: Yigit, Ferruh ; Richardson, Bruce > > > > ; dev@dpdk.org; thomas@monjalon.net; > > > > Wiles, Keith ; stephen@networkplumber.org; > > > > Nelio Laranjeiro > > > > Subject: Re: [dpdk-dev] [PATCH v2 1/4] ethdev: increase port_id > > > > range > > > > > > > > Hi Zhiyong, > > > > > > > > On Mon, Sep 04, 2017 at 09:47:10AM +0000, Yang, Zhiyong wrote: > > > > > Hi, Ferruh, Bruce: > > > > > > > > > > > -----Original Message----- > > > > > > From: Yigit, Ferruh > > > > > > Sent: Monday, September 4, 2017 5:30 PM > > > > > > To: Richardson, Bruce ; Yang, > > > > > > Zhiyong > > > > > > Cc: dev@dpdk.org; thomas@monjalon.net; Wiles, Keith > > > > > > ; stephen@networkplumber.org > > > > > > Subject: Re: [dpdk-dev] [PATCH v2 1/4] ethdev: increase port_id > > > > > > range > > > > > > > > > > > > On 9/4/2017 10:06 AM, Bruce Richardson wrote: > > > > > > > On Mon, Sep 04, 2017 at 01:57:31PM +0800, Zhiyong Yang wrote: > > > > > > >> Extend port_id definition from uint8_t to uint16_t in lib and > > > > > > >> drivers data structures, specifically rte_eth_dev_data. > > > > > > >> Modify the APIs, drivers and app using port_id at the same > > > > > > >> time except some drivers such as MLX4 and MLX5 due to fail to > > > > > > >> compile them in > > > > my server. > > > > > > >> > > > > > > > I think you can change those drivers too - it's not hard to > > > > > > > set up compilation for MLX drivers (instruction in DPDK docs > > > > > > > on the website), and even if you can't compile test them, e.g. > > > > > > > dpaa2 drivers, or other SoC ones, others can do so on your > > > > > > > behalf. If you are going to change drivers, I think you should > > > > > > > change all of > > > > them across the board. > > > > > > > > > > > > +1 > > > > > > > > > > OK. I will change them. > > > > > > > > I haven't applied the series yet but I think mlx4 doesn't need any > > > > modification to support the new width. mlx5, on the other hand, at > > > > least uses the following field in its data path: > > > > > > > > unsigned int port_id:8; > > > > > > > > One related question, why not define a new type (like testpmd's > > > > portid_t) part of rte_ethdev.h? (rte_portid_t?) > > > > > > > > I think uint16_t may not last long with virtual ports and all, and > > > > when it becomes necessary, the switch to uint32_t will be painful. A > > > > typedef should also ease the conversion of user applications. > > > > > > > > If you choose to use a typedef, I suggest to do so in a separate > > > > patch first (uint8_t => rte_portid_t) before upgrading rte_portid_t > > > > to 16 bits in the subsequent patch. It means the first patch is > > > > large but trivial while the second one is shorter but deals with the > > > > complex changes such as the one needed for mlx5. > > Your suggestion is another solution. > Many people discussed the topic in the thread > http://www.dpdk.org/dev/patchwork/patch/23208/ > Most of people agree to use basic type directly and think uint16_t is enough. Thanks for pointing the discussion again, looks like I missed it. I don't mind using a basic-ish type, so no problem with uint16_t either way. However even after reading the discussion, I still think having a dedicated type would be better, so let me throw in another reason for the sake of the argument. This is optional, you can ignore it but here it is anyway. What is currently known as "port ID" in DPDK may refer to: 1. ID corresponding to one port in the global namespace comprising all ports from all detected devices. 2. Physical port of a device exposing multiple ports (device-specific namespace). 3. Application-internal numbering for ports, since they do not necessarily use all ports detected by DPDK (e.g. testpmd port 1 may be actually bound to port ID 42). Having a dedicated type for 1. can avoid confusion between all these things and related bugs. The goal in this sense would not be to hide but to clarify. That's the purpose of typedefs on basic types in public APIs (it's not like typedef'ing structures which are usually already named). Again, this is optional, if you change your mind, I suggest moving first to a dedicated type before increasing its width in a separate commit. > > > The downside of hiding the size is that it becomes harder to reason about the > > layout of key structures like mbuf. Probably not a huge issue, though. A better > > question would be whether we would see the port id ever needing to increase in > > size to 32-bits? Even with virtual ports, I find it hard to see us needing more 64k > > ports in a single application. > > > > Right, I also think 16-bit is actually enough for now, but we never know. > > We see more and more applications using virtual ports, talking to and > > controlling other DPDK applications, the total number of ports in such scenarios > > at any given time may exceed uint16_t. > > > > I just think that as a fundamental DPDK object, port IDs probably need a > > dedicated type for clarity. -- Adrien Mazarguil 6WIND