[dpdk-dev] [PATCH v5 3/4] ethdev: redesign link speed config API

Marc marcdevel at gmail.com
Fri Feb 12 00:23:48 CET 2016


On 11 February 2016 at 16:27, Nélio Laranjeiro <nelio.laranjeiro at 6wind.com>
wrote:

> On Tue, Feb 02, 2016 at 11:30:59PM +0100, Marc wrote:
> > On 2 February 2016 at 03:20, Stephen Hemminger <
> stephen at networkplumber.org>
> > wrote:
> >
> > > On Thu, 28 Jan 2016 17:33:20 +0000
> > > Harish Patil <harish.patil at qlogic.com> wrote:
> > >
> > > > * 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.
> >
> >
> > >
> > > 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.
>

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


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

Still the question about numeric speed MACROs is open.

best
marc




> >
> > Thanks
> > marc
>
> [1] http://optics.org/news/4/1/29
>
> --
> Nélio Laranjeiro
> 6WIND
>


More information about the dev mailing list