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

On 2 February 2016 at 03:20, Stephen Hemminger [off-list ref]
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
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
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
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.

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

Thanks
marc

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

-- 
Nélio Laranjeiro
6WIND