On 11 February 2016 at 16:27, Nélio Laranjeiro [off-list ref]
wrote:

On Tue, Feb 02, 2016 at 11:30:59PM +0100, Marc wrote:

quoted

On 2 February 2016 at 03:20, Stephen Hemminger <

stephen@networkplumber.org>

quoted

wrote:

quoted

On Thu, 28 Jan 2016 17:33:20 +0000
Harish Patil [off-list ref] wrote:

quoted

* Added utility MACROs ETH_SPEED_NUM_XXX with the numeric
  values of all supported link speeds, in Mbps.

I would prefer that there were no speed value macros.
Linux used to have these, but people kept adding new hardware speeds
and it soon gets out of date.

I see what you mean, but I am not sure I agree. Link speeds are

generally a

quoted

reduced amount of items (~20). Though it is true it can eventually grow,
but at small rate. Having numeric constants all over the source seems

less

quoted

readable and less maintainable (e.g. less "grepable"/"sedable") to me.

quoted

If you are going to redo it, then just increase speed to 64 bit, and

allow

quoted

quoted

any non-zero value.

Value is now 32 bits, which I think is enough for future rates in mbps.
Since these constants were there, and before doing something to have to
revert it, can someone else give his/her opinion on this?

For non 64bit architecture it is better to keep it on 32 bit but, if this
field is only used on control plane we can afford 64 bit field and avoid
another ABI breakage (in a far future).

Even if this 32 bit field seems large enough you can already find on
Internet some reports of transmission of petabit/s [1], we can imagine a
NIC which provide this possibility by aggregating a lot of optical links
and DPDK only will see it as single one.

OK, since it is not performance critical I will change it to 64 bit value.

quoted

If there is consensus, I've no problem on removing it for v8

Still the question about numeric speed MACROs is open.

best
marc

quoted

Thanks
marc

[1] http://optics.org/news/4/1/29

--
Nélio Laranjeiro
6WIND