From: Adrien Mazarguil <adrien.mazarguil@6wind.com>
To: "Yang, Zhiyong" <zhiyong.yang@intel.com>
Cc: "Richardson, Bruce" <bruce.richardson@intel.com>,
"Yigit, Ferruh" <ferruh.yigit@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>,
"thomas@monjalon.net" <thomas@monjalon.net>,
"Wiles, Keith" <keith.wiles@intel.com>,
"stephen@networkplumber.org" <stephen@networkplumber.org>,
Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
Subject: Re: [dpdk-dev] [PATCH v2 1/4] ethdev: increase port_id range
Date: Mon, 4 Sep 2017 16:41:12 +0200 [thread overview]
Message-ID: <20170904144112.GX4301@6wind.com> (raw)
In-Reply-To: <E182254E98A5DA4EB1E657AC7CB9BD2A8AF0D763@BGSMSX101.gar.corp.intel.com>
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 <bruce.richardson@intel.com>
> > Cc: Yang, Zhiyong <zhiyong.yang@intel.com>; Yigit, Ferruh
> > <ferruh.yigit@intel.com>; dev@dpdk.org; thomas@monjalon.net; Wiles, Keith
> > <keith.wiles@intel.com>; stephen@networkplumber.org; Nelio Laranjeiro
> > <nelio.laranjeiro@6wind.com>
> > 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 <zhiyong.yang@intel.com>
> > > > Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Richardson, Bruce
> > > > <bruce.richardson@intel.com>; dev@dpdk.org; thomas@monjalon.net;
> > > > Wiles, Keith <keith.wiles@intel.com>; stephen@networkplumber.org;
> > > > Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
> > > > 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 <bruce.richardson@intel.com>; Yang,
> > > > > > Zhiyong <zhiyong.yang@intel.com>
> > > > > > Cc: dev@dpdk.org; thomas@monjalon.net; Wiles, Keith
> > > > > > <keith.wiles@intel.com>; 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
next prev parent reply other threads:[~2017-09-04 14:41 UTC|newest]
Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-09 8:42 [dpdk-dev] [PATCH 0/2] " Zhiyong Yang
2017-08-09 8:42 ` [dpdk-dev] [PATCH 1/2] ethdev: " Zhiyong Yang
2017-08-09 12:52 ` Ferruh Yigit
2017-08-09 12:57 ` Wiles, Keith
2017-08-10 0:53 ` Yang, Zhiyong
2017-08-10 0:51 ` Yang, Zhiyong
2017-08-09 8:42 ` [dpdk-dev] [PATCH 2/2] examples: " Zhiyong Yang
2017-08-09 14:48 ` Stephen Hemminger
2017-08-10 1:03 ` Yang, Zhiyong
2017-08-09 9:00 ` [dpdk-dev] [PATCH 0/2] " De Lara Guarch, Pablo
2017-08-09 9:17 ` Yang, Zhiyong
2017-09-04 5:57 ` [dpdk-dev] [PATCH v2 0/4] " Zhiyong Yang
2017-09-04 5:57 ` [dpdk-dev] [PATCH v2 1/4] ethdev: " Zhiyong Yang
2017-09-04 9:06 ` Bruce Richardson
2017-09-04 9:29 ` Ferruh Yigit
2017-09-04 9:47 ` Yang, Zhiyong
2017-09-04 13:12 ` Adrien Mazarguil
2017-09-04 13:17 ` Richardson, Bruce
2017-09-04 13:36 ` Adrien Mazarguil
2017-09-04 13:59 ` Yang, Zhiyong
2017-09-04 14:41 ` Adrien Mazarguil [this message]
2017-09-05 6:51 ` Yang, Zhiyong
2017-09-06 8:32 ` Hemant Agrawal
2017-09-06 8:48 ` Yang, Zhiyong
[not found] ` <CALZ3Guikt9x8sz-oEKCuDCSp_wtKa64bSXTrMhqcWyg7f_dS7g@mail.gmail.com>
2017-09-07 0:45 ` Yang, Zhiyong
2017-09-04 5:57 ` [dpdk-dev] [PATCH v2 2/4] examples: " Zhiyong Yang
2017-09-04 14:15 ` Hunt, David
2017-09-04 15:01 ` Yang, Zhiyong
2017-09-04 5:57 ` [dpdk-dev] [PATCH v2 3/4] common_base: extend RTE_MAX_ETHPORTS from 32 to 1024 Zhiyong Yang
2017-09-04 7:46 ` Yao, Lei A
2017-09-04 7:59 ` Yang, Zhiyong
2017-09-04 9:09 ` Bruce Richardson
2017-09-04 10:05 ` Yang, Zhiyong
2017-09-04 10:27 ` Ananyev, Konstantin
2017-09-04 14:18 ` Yang, Zhiyong
2017-09-06 8:42 ` Hemant Agrawal
2017-09-06 8:52 ` Yang, Zhiyong
2017-09-04 10:29 ` Bruce Richardson
2017-09-04 9:27 ` Ananyev, Konstantin
2017-09-04 5:57 ` [dpdk-dev] [PATCH v2 4/4] testpmd: add flexibility to mbuf allocation Zhiyong Yang
2017-09-09 14:47 ` [dpdk-dev] [PATCH v3 0/4] increase port_id range Zhiyong Yang
2017-09-09 14:47 ` [dpdk-dev] [PATCH v3 1/4] ethdev: " Zhiyong Yang
2017-09-11 9:37 ` Adrien Mazarguil
2017-09-11 10:51 ` Yang, Zhiyong
2017-09-11 10:21 ` Ferruh Yigit
2017-09-13 2:26 ` Yang, Zhiyong
2017-09-13 11:56 ` Ferruh Yigit
2017-09-13 12:15 ` Yang, Zhiyong
2017-09-13 12:18 ` Thomas Monjalon
2017-09-13 13:33 ` Ferruh Yigit
2017-09-19 6:05 ` Yang, Zhiyong
2017-09-19 12:30 ` Wiles, Keith
2017-09-14 12:49 ` Ferruh Yigit
2017-09-15 5:11 ` Yang, Zhiyong
2017-09-09 14:47 ` [dpdk-dev] [PATCH v3 2/4] test: " Zhiyong Yang
2017-09-09 14:47 ` [dpdk-dev] [PATCH v3 3/4] examples: " Zhiyong Yang
2017-09-14 14:41 ` Ferruh Yigit
2017-09-09 14:47 ` [dpdk-dev] [PATCH v3 4/4] librte_mbuf: modify port initialization value Zhiyong Yang
2017-09-11 10:23 ` [dpdk-dev] [PATCH v3 0/4] increase port_id range Ferruh Yigit
2017-09-11 11:25 ` Yang, Zhiyong
2017-09-13 8:14 ` Matej Vido
2017-09-13 8:21 ` Yang, Zhiyong
2017-09-18 14:54 ` Laatz, Kevin
2017-09-19 1:39 ` Yang, Zhiyong
2017-09-11 10:26 ` Ferruh Yigit
2017-09-11 10:55 ` Yang, Zhiyong
2017-09-11 11:24 ` Ferruh Yigit
2017-09-21 8:32 ` [dpdk-dev] [PATCH v4 0/5] " Zhiyong Yang
2017-09-21 8:32 ` [dpdk-dev] [PATCH v4 1/5] net/bonding: remove bonding APIs using ABI versioning Zhiyong Yang
2017-09-21 10:36 ` Ferruh Yigit
2017-09-22 2:02 ` Yang, Zhiyong
2017-09-21 8:32 ` [dpdk-dev] [PATCH v4 2/5] ethdev: increase port_id range Zhiyong Yang
2017-09-21 11:49 ` Adrien Mazarguil
2017-10-06 14:34 ` Nélio Laranjeiro
2017-09-21 8:32 ` [dpdk-dev] [PATCH v4 3/5] examples: " Zhiyong Yang
2017-09-21 8:32 ` [dpdk-dev] [PATCH v4 4/5] test: " Zhiyong Yang
2017-09-21 8:32 ` [dpdk-dev] [PATCH v4 5/5] librte_mbuf: modify port initialization value Zhiyong Yang
2017-09-25 3:22 ` [dpdk-dev] [PATCH v5 0/5] increase port_id range Zhiyong Yang
2017-09-25 3:22 ` [dpdk-dev] [PATCH v5 1/5] net/bonding: remove bonding APIs using ABI versioning Zhiyong Yang
2017-09-25 11:34 ` Ferruh Yigit
2017-09-25 3:22 ` [dpdk-dev] [PATCH v5 2/5] ethdev: increase port_id range Zhiyong Yang
2017-09-25 11:37 ` Ferruh Yigit
2017-09-25 12:06 ` Ferruh Yigit
2017-09-26 7:01 ` Yang, Zhiyong
2017-09-27 18:44 ` Ferruh Yigit
2017-09-28 2:12 ` Yang, Zhiyong
2017-09-25 3:22 ` [dpdk-dev] [PATCH v5 3/5] examples: " Zhiyong Yang
2017-09-25 3:22 ` [dpdk-dev] [PATCH v5 4/5] test: " Zhiyong Yang
2017-09-25 3:22 ` [dpdk-dev] [PATCH v5 5/5] librte_mbuf: modify port initialization value Zhiyong Yang
2017-09-29 7:17 ` [dpdk-dev] [PATCH v6 0/5] increase port_id range Zhiyong Yang
2017-09-29 7:17 ` [dpdk-dev] [PATCH v6 1/5] net/bonding: remove bonding APIs using ABI versioning Zhiyong Yang
2017-09-29 7:17 ` [dpdk-dev] [PATCH v6 2/5] ethdev: increase port_id range Zhiyong Yang
2017-09-29 7:17 ` [dpdk-dev] [PATCH v6 3/5] examples: " Zhiyong Yang
2017-09-29 7:17 ` [dpdk-dev] [PATCH v6 4/5] test: " Zhiyong Yang
2017-09-29 7:17 ` [dpdk-dev] [PATCH v6 5/5] librte_mbuf: modify port initialization value Zhiyong Yang
2017-10-06 2:15 ` [dpdk-dev] [PATCH v6 0/5] increase port_id range Ferruh Yigit
2017-10-06 13:31 ` Gaëtan Rivet
2017-10-06 14:29 ` Thomas Monjalon
2017-10-06 16:02 ` Thomas Monjalon
2017-10-11 21:21 ` Ferruh Yigit
2017-10-12 1:33 ` Yang, Zhiyong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170904144112.GX4301@6wind.com \
--to=adrien.mazarguil@6wind.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=keith.wiles@intel.com \
--cc=nelio.laranjeiro@6wind.com \
--cc=stephen@networkplumber.org \
--cc=thomas@monjalon.net \
--cc=zhiyong.yang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).