On Tue, Sep 15, 2015 at 11:20:03PM +0200, Marc Sune wrote:
> Adrien,
>
> 2015-09-15 12:04 GMT+02:00 Adrien Mazarguil :
[...]
> > It's not so much about the way PMDs recover link information, rather about
> > the amount of changes required to switch to a bit-field API for the current
> > link speed
Adrien,
2015-09-15 12:04 GMT+02:00 Adrien Mazarguil :
> Hi Marc,
>
> Adding my thoughts to the discussion, see below.
>
> On Tue, Sep 15, 2015 at 10:48:03AM +0200, Marc Sune wrote:
> > I will answer Morten in another mail, because I got his point on the
> > AUTONEG as a separate bit, and it _make
Adrien Mazarguil [mailto:adrien.mazarguil at 6wind.com] on 15. september 2015
12:05:
> A given link cannot be simultaneously at 10 Gbps and 1 Gbps right? Using a
> bit-field for the current link speed is confusing at best. Output values do
> not need to be included in the unified API, they are
Hi Marc,
Adding my thoughts to the discussion, see below.
On Tue, Sep 15, 2015 at 10:48:03AM +0200, Marc Sune wrote:
> I will answer Morten in another mail, because I got his point on the
> AUTONEG as a separate bit, and it _makes_ sense to me.
>
> But Neilo,
>
> 2015-09-15 10:25 GMT+02:00 N?li
: 15. september 2015 10:48
To: N?lio Laranjeiro
Cc: Morten Br?rup; Thomas Monjalon; dev at dpdk.org; Olga Shern; Adrien
Mazarguil
Subject: Re: [dpdk-dev] [PATCH v4 0/2] ethdev: add port speed capability bitmap
I will answer Morten in another mail, because I got his point on the AUTONEG as
a
dpdk.org; Olga Shern; Adrien
Mazarguil
Subject: RE: [dpdk-dev] [PATCH v4 0/2] ethdev: add port speed capability bitmap
Comments inline, marked MB>.
Med venlig hilsen / kind regards
- Morten Br?rup
Marc Sune on 14. september 2015 23:34 wrote:
2015-09-14 12:52 GMT+02:00 Morten Br?rup :
> It
I will answer Morten in another mail, because I got his point on the
AUTONEG as a separate bit, and it _makes_ sense to me.
But Neilo,
2015-09-15 10:25 GMT+02:00 N?lio Laranjeiro :
> On Tue, Sep 15, 2015 at 12:50:11AM +0200, Morten Br?rup wrote:
> > Comments inline, marked MB>.
> >
> > Med venli
On Tue, Sep 15, 2015 at 12:50:11AM +0200, Morten Br?rup wrote:
> Comments inline, marked MB>.
>
> Med venlig hilsen / kind regards
> - Morten Br?rup
>
> Marc Sune on 14. september 2015 23:34 wrote:
>
> 2015-09-14 12:52 GMT+02:00 Morten Br?rup :
> > It is important to consider that a multipath l
omas.monja...@6wind.com]
Sent: 15. september 2015 09:05
To: Marc Sune
Cc: Morten Br?rup; N?lio Laranjeiro; dev at dpdk.org; Olga Shern; Adrien
Mazarguil
Subject: Re: [dpdk-dev] [PATCH v4 0/2] ethdev: add port speed capability bitmap
2015-09-14 23:33, Marc Sune:
> 2015-09-14 12:52 GMT+02:00 Morten Br?r
2015-09-14 23:33, Marc Sune:
> 2015-09-14 12:52 GMT+02:00 Morten Br?rup :
> > This support function will be able to determine which speed is higher when
> > exotic speeds are added to the bitmap. Please extend this conversion
> > function to give three output parameters: speed, full/half duplex, au
Comments inline, marked MB>.
Med venlig hilsen / kind regards
- Morten Br?rup
Marc Sune on 14. september 2015 23:34 wrote:
2015-09-14 12:52 GMT+02:00 Morten Br?rup :
> It is important to consider that a multipath link (bonding etc.) is not a
> physical link, but a logical link (built on top of
bool rte_eth_duplex_from_bm(int val_bm).
Marc
>
> Med venlig hilsen / kind regards
> - Morten Br?rup
>
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: 13. september 2015 23:19
> To: Marc Sune
> Cc: N?lio Laranjeiro; dev at
l; Morten
Br?rup
Subject: Re: [dpdk-dev] [PATCH v4 0/2] ethdev: add port speed capability bitmap
2015-09-13 21:14, Marc Sune:
> 2015-09-09 15:33 GMT+02:00 Thomas Monjalon :
> > 2015-09-09 15:10, N?lio Laranjeiro:
> > > I think V2 is better, maybe you can add a function to
On Sun, Sep 13, 2015 at 11:18:33PM +0200, Thomas Monjalon wrote:
> 2015-09-13 21:14, Marc Sune:
> > 2015-09-09 15:33 GMT+02:00 Thomas Monjalon :
> > > 2015-09-09 15:10, N?lio Laranjeiro:
> > > > I think V2 is better, maybe you can add a function to convert a single
> > > > bitmap value to the equiv
2015-09-13 21:14, Marc Sune:
> 2015-09-09 15:33 GMT+02:00 Thomas Monjalon :
> > 2015-09-09 15:10, N?lio Laranjeiro:
> > > I think V2 is better, maybe you can add a function to convert a single
> > > bitmap value to the equivalent integer and get rid of ETH_SPEED_XXX
> > macros.
> > >
> > > Thomas w
Thomas,
2015-09-09 15:33 GMT+02:00 Thomas Monjalon :
> 2015-09-09 15:10, N?lio Laranjeiro:
> > I think V2 is better, maybe you can add a function to convert a single
> > bitmap value to the equivalent integer and get rid of ETH_SPEED_XXX
> macros.
> >
> > Thomas what is your opinion?
>
> Your pro
2015-09-09 15:10, N?lio Laranjeiro:
> I think V2 is better, maybe you can add a function to convert a single
> bitmap value to the equivalent integer and get rid of ETH_SPEED_XXX macros.
>
> Thomas what is your opinion?
Your proposal looks good Nelio.
Thanks
Marc,
(making this discussion public again)
On Wed, Sep 09, 2015 at 12:07:01PM +0200, Marc Sune wrote:
> Hi Nelio
>
> 2015-09-09 11:08 GMT+02:00 N?lio Laranjeiro :
>
> Marc,
>
> On Tue, Sep 08, 2015 at 10:24:36PM +0200, Marc Sune wrote:
> > Neilo,
> >
> > 2015-09-08 12:03 G
Neilo,
2015-09-08 12:03 GMT+02:00 N?lio Laranjeiro :
> On Mon, Sep 07, 2015 at 10:52:53PM +0200, Marc Sune wrote:
> > 2015-08-29 2:16 GMT+02:00 Marc Sune :
> >
> > > The current rte_eth_dev_info abstraction does not provide any
> mechanism to
> > > get the supported speed(s) of an ethdev.
> > >
On Mon, Sep 07, 2015 at 10:52:53PM +0200, Marc Sune wrote:
> 2015-08-29 2:16 GMT+02:00 Marc Sune :
>
> > The current rte_eth_dev_info abstraction does not provide any mechanism to
> > get the supported speed(s) of an ethdev.
> >
> > For some drivers (e.g. ixgbe), an educated guess can be done base
2015-08-29 2:16 GMT+02:00 Marc Sune :
> The current rte_eth_dev_info abstraction does not provide any mechanism to
> get the supported speed(s) of an ethdev.
>
> For some drivers (e.g. ixgbe), an educated guess can be done based on the
> driver's name (driver_name in rte_eth_dev_info), see:
>
> ht
The current rte_eth_dev_info abstraction does not provide any mechanism to
get the supported speed(s) of an ethdev.
For some drivers (e.g. ixgbe), an educated guess can be done based on the
driver's name (driver_name in rte_eth_dev_info), see:
http://dpdk.org/ml/archives/dev/2013-August/000412.ht
22 matches
Mail list logo
