On Mon, Sep 04, 2017 at 01:59:26PM +0000, Yang, Zhiyong wrote:

Hi, Adrien:

quoted

-----Original Message-----
From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
Sent: Monday, September 4, 2017 9:37 PM
To: Richardson, Bruce <redacted>
Cc: Yang, Zhiyong <redacted>; Yigit, Ferruh
[off-list ref]; dev@dpdk.org; thomas@monjalon.net; Wiles, Keith
[off-list ref]; stephen@networkplumber.org; Nelio Laranjeiro
[off-list ref]
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:

quoted

quoted

-----Original Message-----
From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
Sent: Monday, September 4, 2017 2:12 PM
To: Yang, Zhiyong <redacted>
Cc: Yigit, Ferruh <redacted>; Richardson, Bruce
[off-list ref]; dev@dpdk.org; thomas@monjalon.net;
Wiles, Keith [off-list ref]; stephen@networkplumber.org;
Nelio Laranjeiro [off-list ref]
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:

quoted

Hi,  Ferruh, Bruce:

quoted

-----Original Message-----
From: Yigit, Ferruh
Sent: Monday, September 4, 2017 5:30 PM
To: Richardson, Bruce <redacted>; Yang,
Zhiyong [off-list ref]
Cc: dev@dpdk.org; thomas@monjalon.net; Wiles, Keith
[off-list ref]; 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:

quoted

On Mon, Sep 04, 2017 at 01:57:31PM +0800, Zhiyong Yang wrote:

quoted

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.

quoted

quoted

quoted

quoted

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.

quoted

quoted

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

quoted

quoted

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