Re: [dpdk-dev] [PATCH v2 1/4] ethdev: increase port_id range

[Adrien Mazarguil <adrien.mazarguil@6wind.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