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 5CE323770 for ; Mon, 4 Sep 2017 15:37:03 +0200 (CEST) Received: by mail-wr0-f182.google.com with SMTP id y15so1701992wrc.2 for ; Mon, 04 Sep 2017 06:37:03 -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=Ep5a2x2/KwM+PiN7PeVGkq8xD4hVIyUWpSMMpHg2BpE=; b=nsZnxIwpM2yMtC0UxWZ1HdXESL+xzwq4/V24JqTXZPoNPmr1Cf2qDs4vemCWuVktSa SQFk0RPJlG2pIOVw1oS8tyxQO/YeaSPQRoqyGuLfOzPhxpK/QE6t3uh5O8W8S4hWRWX+ 5Dh6UAkKOTn34kr96/L1da+6AaxETEAVBwaAAeXB4CRwGDNhSkLeydIELw4el/bVO2zQ U1Pbe9/9DVj5ZWeRox7UgjlNCdRHU1ch7p2/kxUtkfye1slTMHKCaUMTJYGwlXFIThoS Ui2BNAAI633Zpp0h3GHtSvon0JH/kMTkFAwRBwYtV85d9C5XygsDsVxjqSmywXPHy6O2 1kcQ== 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=Ep5a2x2/KwM+PiN7PeVGkq8xD4hVIyUWpSMMpHg2BpE=; b=I+/K66kpAOiQ809l6EWBT9EkWC0l/GwJj9F68lGVkeYC8aa2slNyDyw5/AIXTttvVd WhMAHz7XOfCmdWeQ6cFQbCEwWs62DbXIxFlMwM9HrFnIQk26XBcOWUWaIzY/O/JzviTl 9c3VdN4omVdWXalVhfkYwyNkklRNTwTOaqhNMnNZ+jk2ByrOXMftH+M18MaHdXA0uhgf IeQM0S9YZesdp97RL6djOnovrI3IaScIdTJPckw38muXQxumFbJX2tNlYTHTfKp9uvRH Dbr6wg8c2tSqiMD0ezgJhOerbFnw/5vzrI9k0pl2Yxm1GytSfonInHqVI8T08n9ZJ/Vm pI7A== X-Gm-Message-State: AHPjjUhzSIt6DuqCTnVmfy5YUbqxLDhId2wpDaFrX9mWY8sBE/J63qOm 5qQXxs7xuCq7UvOT X-Google-Smtp-Source: ADKCNb6vbydncKlKQ87h/XjgujShaueWUucyCClF5aGhTKYvRv9mP0IMcu4bCQUM3Q1l+yhT9IRcdA== X-Received: by 10.223.152.117 with SMTP id v108mr408484wrb.76.1504532222903; Mon, 04 Sep 2017 06:37:02 -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 q186sm634953wmb.29.2017.09.04.06.37.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Sep 2017 06:37:02 -0700 (PDT) Date: Mon, 4 Sep 2017 15:36:52 +0200 From: Adrien Mazarguil To: "Richardson, Bruce" Cc: "Yang, Zhiyong" , "Yigit, Ferruh" , "dev@dpdk.org" , "thomas@monjalon.net" , "Wiles, Keith" , "stephen@networkplumber.org" , Nelio Laranjeiro Message-ID: <20170904133652.GW4301@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <59AF69C657FD0841A61C55336867B5B0721CFC11@IRSMSX103.ger.corp.intel.com> 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 13:37:03 -0000 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. > > > > Thanks. > > 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