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

["Yang, Zhiyong" <zhiyong.yang@intel.com>]

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
Zhiyong

> > >
> > > 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