[dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API refactoring
On 28 March 2016 at 15:42, Thomas Monjalon wrote: > Hi Marc, > > 2016-03-27 21:39, Marc: > > On 27 March 2016 at 11:53, Thomas Monjalon > > wrote: > > > 2016-03-26 11:24, Marc: > > > > On 26 March 2016 at 09:08, Thomas Monjalon < > thomas.monjalon at 6wind.com> > > > > wrote: > > > > > 2016-03-25 22:30, Marc: > > > > > > From v9 to v10 patchset the values ETH_LINK_SPEED_AUTONEG and > > > > > ETH_LINK_SPEED_FIXED were flipped. Reverting this makes it work: > [...] > > > > > > I think having autoneg == 0 is better. Do you agree Thomas? > > > > > > > > > > No I do not agree, because this flag is now used also for > > > > > rte_eth_link.link_autoneg. > > > > > So it is more logic to set it to 1. > > > > > > > > Having to explicitly specify ETH_LINK_SPEED_AUTONEG in link_speeds > during > > > > port configuration for achieving auto-negociation, which is what 98% > of > > > > applications will use, seems anti-natural to me and breaks existing > > > > applications. > > > > > > Yes, you're right. We have to avoid apps modifications. > > > By keeping autoneg the default behaviour (value 0), we avoid issues. > > > > > > > The only benefit of your approach is not to have another macro > #define > > > > ETH_LINK_AUTONEG 1, which is marginal IMHO. > > > > > > Yes, you're right. > > > I suggest adding 2 macros for rte_eth_link.link_autoneg: > > > #define ETH_LINK_FIXED 0 /**< No autonegotiation. */ > > > #define ETH_LINK_AUTONEG1 /**< Autonegotiated. */ > > > > > > and keep these ones to use with rte_eth_conf.link_speeds and > > > rte_eth_dev_info.speed_capa: > > > #define ETH_LINK_SPEED_AUTONEG (0 << 0) /**< Autonegotiate (all > speeds) */ > > > #define ETH_LINK_SPEED_FIXED(1 << 0) /**< Disable autoneg (fixed > speed) */ > > > > > > Opinions? > > > > Agree on all of them. I can add them in the (hopefully) final v14, once > all > > or main drivers have been tested. > > It would be better to make the v14 as soon as possible to let others test > the latest revision. > Thanks > Adding these MACROs (ETH_LINK_FIXED, ETH_LINK_AUTONEG) are the only changes to be done for v14 so far. The rest were there already (v13). There is no point on doing this re-spin now, because these MACROs are anyway not used by applications yet (autoneg flag in rte_link is an addition to this patch set). So I would go for testing drivers on this v13 and collect any changes, eventually, for v14. marc
[dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API refactoring
Hi Marc, 2016-03-27 21:39, Marc: > On 27 March 2016 at 11:53, Thomas Monjalon > wrote: > > 2016-03-26 11:24, Marc: > > > On 26 March 2016 at 09:08, Thomas Monjalon > > > wrote: > > > > 2016-03-25 22:30, Marc: > > > > > From v9 to v10 patchset the values ETH_LINK_SPEED_AUTONEG and > > > > ETH_LINK_SPEED_FIXED were flipped. Reverting this makes it work: [...] > > > > > I think having autoneg == 0 is better. Do you agree Thomas? > > > > > > > > No I do not agree, because this flag is now used also for > > > > rte_eth_link.link_autoneg. > > > > So it is more logic to set it to 1. > > > > > > Having to explicitly specify ETH_LINK_SPEED_AUTONEG in link_speeds during > > > port configuration for achieving auto-negociation, which is what 98% of > > > applications will use, seems anti-natural to me and breaks existing > > > applications. > > > > Yes, you're right. We have to avoid apps modifications. > > By keeping autoneg the default behaviour (value 0), we avoid issues. > > > > > The only benefit of your approach is not to have another macro #define > > > ETH_LINK_AUTONEG 1, which is marginal IMHO. > > > > Yes, you're right. > > I suggest adding 2 macros for rte_eth_link.link_autoneg: > > #define ETH_LINK_FIXED 0 /**< No autonegotiation. */ > > #define ETH_LINK_AUTONEG1 /**< Autonegotiated. */ > > > > and keep these ones to use with rte_eth_conf.link_speeds and > > rte_eth_dev_info.speed_capa: > > #define ETH_LINK_SPEED_AUTONEG (0 << 0) /**< Autonegotiate (all speeds) > > */ > > #define ETH_LINK_SPEED_FIXED(1 << 0) /**< Disable autoneg (fixed > > speed) */ > > > > Opinions? > > Agree on all of them. I can add them in the (hopefully) final v14, once all > or main drivers have been tested. It would be better to make the v14 as soon as possible to let others test the latest revision. Thanks
[dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API refactoring
On 27 March 2016 at 11:53, Thomas Monjalon
wrote:
> 2016-03-26 11:24, Marc:
> > On 26 March 2016 at 09:08, Thomas Monjalon
> > wrote:
> > > 2016-03-25 22:30, Marc:
> > > > From v9 to v10 patchset the values ETH_LINK_SPEED_AUTONEG and
> > > ETH_LINK_SPEED_FIXED were flipped. Reverting this makes it work:
> > > >
> > > > marc at Beluga:~/personal/dpdk/tools$ git diff
> > > > diff --git a/lib/librte_ether/rte_ethdev.h
> > > b/lib/librte_ether/rte_ethdev.h
> > > > index ef2502a..fb247a7 100644
> > > > --- a/lib/librte_ether/rte_ethdev.h
> > > > +++ b/lib/librte_ether/rte_ethdev.h
> > > > @@ -244,8 +244,8 @@ struct rte_eth_stats {
> > > > /**
> > > > * Device supported speeds bitmap flags
> > > > */
> > > > -#define ETH_LINK_SPEED_FIXED(0 << 0) /**< Disable autoneg
> (fixed
> > > speed) */
> > > > -#define ETH_LINK_SPEED_AUTONEG (1 << 0) /**< Autonegotiate (all
> > > speeds) */
> > > > +#define ETH_LINK_SPEED_AUTONEG (0 << 0) /**< Autonegotiate (all
> > > speeds) */
> > > > +#define ETH_LINK_SPEED_FIXED(1 << 0) /**< Disable autoneg
> (fixed
> > > speed) */
> > > > #define ETH_LINK_SPEED_10M_HD (1 << 1) /**< 10 Mbps
> half-duplex */
> > > > #define ETH_LINK_SPEED_10M (1 << 2) /**< 10 Mbps
> full-duplex */
> > > > #define ETH_LINK_SPEED_100M_HD (1 << 3) /**< 100 Mbps
> half-duplex */
> > > >
> > > > I think having autoneg == 0 is better. Do you agree Thomas?
> > >
> > > No I do not agree, because this flag is now used also for
> > > rte_eth_link.link_autoneg.
> > > So it is more logic to set it to 1.
> >
> > Having to explicitly specify ETH_LINK_SPEED_AUTONEG in link_speeds during
> > port configuration for achieving auto-negociation, which is what 98% of
> > applications will use, seems anti-natural to me and breaks existing
> > applications.
>
> Yes, you're right. We have to avoid apps modifications.
> By keeping autoneg the default behaviour (value 0), we avoid issues.
>
> > The only benefit of your approach is not to have another macro #define
> > ETH_LINK_AUTONEG 1, which is marginal IMHO.
>
> Yes, you're right.
> I suggest adding 2 macros for rte_eth_link.link_autoneg:
> #define ETH_LINK_FIXED 0 /**< No autonegotiation. */
> #define ETH_LINK_AUTONEG1 /**< Autonegotiated. */
>
> and keep these ones to use with rte_eth_conf.link_speeds and
> rte_eth_dev_info.speed_capa:
> #define ETH_LINK_SPEED_AUTONEG (0 << 0) /**< Autonegotiate (all speeds)
> */
> #define ETH_LINK_SPEED_FIXED(1 << 0) /**< Disable autoneg (fixed
> speed) */
>
> Opinions?
>
Agree on all of them. I can add them in the (hopefully) final v14, once all
or main drivers have been tested.
Regards
marc
[dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API refactoring
2016-03-26 11:24, Marc:
> On 26 March 2016 at 09:08, Thomas Monjalon
> wrote:
> > 2016-03-25 22:30, Marc:
> > > From v9 to v10 patchset the values ETH_LINK_SPEED_AUTONEG and
> > ETH_LINK_SPEED_FIXED were flipped. Reverting this makes it work:
> > >
> > > marc at Beluga:~/personal/dpdk/tools$ git diff
> > > diff --git a/lib/librte_ether/rte_ethdev.h
> > b/lib/librte_ether/rte_ethdev.h
> > > index ef2502a..fb247a7 100644
> > > --- a/lib/librte_ether/rte_ethdev.h
> > > +++ b/lib/librte_ether/rte_ethdev.h
> > > @@ -244,8 +244,8 @@ struct rte_eth_stats {
> > > /**
> > > * Device supported speeds bitmap flags
> > > */
> > > -#define ETH_LINK_SPEED_FIXED(0 << 0) /**< Disable autoneg (fixed
> > speed) */
> > > -#define ETH_LINK_SPEED_AUTONEG (1 << 0) /**< Autonegotiate (all
> > speeds) */
> > > +#define ETH_LINK_SPEED_AUTONEG (0 << 0) /**< Autonegotiate (all
> > speeds) */
> > > +#define ETH_LINK_SPEED_FIXED(1 << 0) /**< Disable autoneg (fixed
> > speed) */
> > > #define ETH_LINK_SPEED_10M_HD (1 << 1) /**< 10 Mbps half-duplex */
> > > #define ETH_LINK_SPEED_10M (1 << 2) /**< 10 Mbps full-duplex */
> > > #define ETH_LINK_SPEED_100M_HD (1 << 3) /**< 100 Mbps half-duplex */
> > >
> > > I think having autoneg == 0 is better. Do you agree Thomas?
> >
> > No I do not agree, because this flag is now used also for
> > rte_eth_link.link_autoneg.
> > So it is more logic to set it to 1.
>
> Having to explicitly specify ETH_LINK_SPEED_AUTONEG in link_speeds during
> port configuration for achieving auto-negociation, which is what 98% of
> applications will use, seems anti-natural to me and breaks existing
> applications.
Yes, you're right. We have to avoid apps modifications.
By keeping autoneg the default behaviour (value 0), we avoid issues.
> The only benefit of your approach is not to have another macro #define
> ETH_LINK_AUTONEG 1, which is marginal IMHO.
Yes, you're right.
I suggest adding 2 macros for rte_eth_link.link_autoneg:
#define ETH_LINK_FIXED 0 /**< No autonegotiation. */
#define ETH_LINK_AUTONEG1 /**< Autonegotiated. */
and keep these ones to use with rte_eth_conf.link_speeds and
rte_eth_dev_info.speed_capa:
#define ETH_LINK_SPEED_AUTONEG (0 << 0) /**< Autonegotiate (all speeds) */
#define ETH_LINK_SPEED_FIXED(1 << 0) /**< Disable autoneg (fixed speed) */
Opinions?
[dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API refactoring
On 26 March 2016 at 09:08, Thomas Monjalon
wrote:
> Hi Marc,
>
> Thanks for finding time to help.
>
> 2016-03-25 22:30, Marc:
> > From v9 to v10 patchset the values ETH_LINK_SPEED_AUTONEG and
> ETH_LINK_SPEED_FIXED were flipped. Reverting this makes it work:
> >
> > marc at Beluga:~/personal/dpdk/tools$ git diff
> > diff --git a/lib/librte_ether/rte_ethdev.h
> b/lib/librte_ether/rte_ethdev.h
> > index ef2502a..fb247a7 100644
> > --- a/lib/librte_ether/rte_ethdev.h
> > +++ b/lib/librte_ether/rte_ethdev.h
> > @@ -244,8 +244,8 @@ struct rte_eth_stats {
> > /**
> > * Device supported speeds bitmap flags
> > */
> > -#define ETH_LINK_SPEED_FIXED(0 << 0) /**< Disable autoneg (fixed
> speed) */
> > -#define ETH_LINK_SPEED_AUTONEG (1 << 0) /**< Autonegotiate (all
> speeds) */
> > +#define ETH_LINK_SPEED_AUTONEG (0 << 0) /**< Autonegotiate (all
> speeds) */
> > +#define ETH_LINK_SPEED_FIXED(1 << 0) /**< Disable autoneg (fixed
> speed) */
> > #define ETH_LINK_SPEED_10M_HD (1 << 1) /**< 10 Mbps half-duplex */
> > #define ETH_LINK_SPEED_10M (1 << 2) /**< 10 Mbps full-duplex */
> > #define ETH_LINK_SPEED_100M_HD (1 << 3) /**< 100 Mbps half-duplex */
> >
> > I think having autoneg == 0 is better. Do you agree Thomas?
>
> No I do not agree, because this flag is now used also for
> rte_eth_link.link_autoneg.
> So it is more logic to set it to 1.
>
Having to explicitly specify ETH_LINK_SPEED_AUTONEG in link_speeds during
port configuration for achieving auto-negociation, which is what 98% of
applications will use, seems anti-natural to me and breaks existing
applications.
The only benefit of your approach is not to have another macro #define
ETH_LINK_AUTONEG 1, which is marginal IMHO.
>
> Would it be possible to fix without reverting?
>
At least, all existing applications will have to be modified. I would have
to go through v12 again to see if there are other issues still to be fixed,
and also apply the 2 fixes I found for e1000.
Marc
[dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API refactoring
Hi Marc,
Thanks for finding time to help.
2016-03-25 22:30, Marc:
> From v9 to v10 patchset the values ETH_LINK_SPEED_AUTONEG and
> ETH_LINK_SPEED_FIXED were flipped. Reverting this makes it work:
>
> marc at Beluga:~/personal/dpdk/tools$ git diff
> diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
> index ef2502a..fb247a7 100644
> --- a/lib/librte_ether/rte_ethdev.h
> +++ b/lib/librte_ether/rte_ethdev.h
> @@ -244,8 +244,8 @@ struct rte_eth_stats {
> /**
> * Device supported speeds bitmap flags
> */
> -#define ETH_LINK_SPEED_FIXED(0 << 0) /**< Disable autoneg (fixed
> speed) */
> -#define ETH_LINK_SPEED_AUTONEG (1 << 0) /**< Autonegotiate (all speeds) */
> +#define ETH_LINK_SPEED_AUTONEG (0 << 0) /**< Autonegotiate (all speeds) */
> +#define ETH_LINK_SPEED_FIXED(1 << 0) /**< Disable autoneg (fixed
> speed) */
> #define ETH_LINK_SPEED_10M_HD (1 << 1) /**< 10 Mbps half-duplex */
> #define ETH_LINK_SPEED_10M (1 << 2) /**< 10 Mbps full-duplex */
> #define ETH_LINK_SPEED_100M_HD (1 << 3) /**< 100 Mbps half-duplex */
>
> I think having autoneg == 0 is better. Do you agree Thomas?
No I do not agree, because this flag is now used also for
rte_eth_link.link_autoneg.
So it is more logic to set it to 1.
Would it be possible to fix without reverting?
[dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API refactoring
toneg && (num_speeds > 1)))
goto error_invalid_config;
}
@@ -2063,12 +2063,13 @@ eth_igb_link_update(struct rte_eth_dev *dev, int
wait_to_complete)
if (link_check) {
uint16_t duplex, speed;
hw->mac.ops.get_link_up_info(hw, &speed, &duplex);
- link.link_duplex = duplex ? ETH_LINK_FULL_DUPLEX :
+ link.link_duplex = (duplex == FULL_DUPLEX) ?
+ ETH_LINK_FULL_DUPLEX :
ETH_LINK_HALF_DUPLEX;
link.link_speed = speed;
link.link_status = ETH_LINK_UP;
- link.link_autoneg = (dev->data->dev_conf.link_speeds &
- ETH_LINK_SPEED_AUTONEG);
+ link.link_autoneg = !(dev->data->dev_conf.link_speeds &
+ ETH_LINK_SPEED_FIXED);
} else if (!link_check) {
link.link_speed = 0;
link.link_duplex = ETH_LINK_HALF_DUPLEX;
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 87bc767..c9ef417 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -1422,7 +1422,7 @@ i40e_apply_link_speed(struct rte_eth_dev *dev)
speed = i40e_parse_link_speeds(conf->link_speeds);
abilities |= I40E_AQ_PHY_ENABLE_ATOMIC_LINK;
- if (conf->link_speeds & ETH_LINK_SPEED_AUTONEG)
+ if (!(conf->link_speeds & ETH_LINK_SPEED_FIXED))
abilities |= I40E_AQ_PHY_AN_ENABLED;
else
abilities |= I40E_AQ_PHY_LINK_ENABLED;
@@ -1442,7 +1442,7 @@ i40e_dev_start(struct rte_eth_dev *dev)
hw->adapter_stopped = 0;
- if (!(dev->data->dev_conf.link_speeds & ETH_LINK_SPEED_AUTONEG)) {
+ if (dev->data->dev_conf.link_speeds & ETH_LINK_SPEED_FIXED) {
PMD_INIT_LOG(ERR, "Invalid link_speeds for port %hhu; autonegotiation
disabled",
dev->data->port_id);
return -EINVAL;
@@ -1806,8 +1806,8 @@ i40e_dev_link_update(struct rte_eth_dev *dev,
break;
}
- link.link_autoneg = (dev->data->dev_conf.link_speeds &
- ETH_LINK_SPEED_AUTONEG);
+ link.link_autoneg = !(dev->data->dev_conf.link_speeds &
+ ETH_LINK_SPEED_FIXED);
out:
rte_i40e_dev_atomic_write_link_status(dev, &link);
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
b/drivers/net/ixgbe/ixgbe_ethdev.c
index ff23d7d..6cc2da0 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -2098,9 +2098,12 @@ ixgbe_dev_start(struct rte_eth_dev *dev)
PMD_INIT_FUNC_TRACE();
- /* IXGBE devices don't support half duplex */
- if (!(dev->data->dev_conf.link_speeds & ETH_LINK_SPEED_AUTONEG)) {
- PMD_INIT_LOG(ERR, "Invalid link_speeds for port %hhu; autonegotiation
disabled",
+ /* IXGBE devices don't support:
+ *- half duplex (checked afterwards for valid speeds)
+ *- fixed speed: TODO implement
+ */
+ if (dev->data->dev_conf.link_speeds & ETH_LINK_SPEED_FIXED) {
+ PMD_INIT_LOG(ERR, "Invalid link_speeds for port %hhu; fix speed not
supported",
dev->data->port_id);
return -EINVAL;
}
diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index 43ac763..81528c9 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -4721,8 +4721,8 @@ mlx4_link_update_unlocked(struct rte_eth_dev *dev,
int wait_to_complete)
dev_link.link_speed = link_speed;
dev_link.link_duplex = ((edata.duplex == DUPLEX_HALF) ?
ETH_LINK_HALF_DUPLEX : ETH_LINK_FULL_DUPLEX);
- dev_link.link_autoneg = (dev->data->dev_conf.link_speeds &
- ETH_LINK_SPEED_AUTONEG);
+ dev_link.link_autoneg = !(dev->data->dev_conf.link_speeds &
+ ETH_LINK_SPEED_FIXED);
if (memcmp(&dev_link, &dev->data->dev_link, sizeof(dev_link))) {
/* Link status changed. */
dev->data->dev_link = dev_link;
diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index 477939f..36b369e 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -630,6 +630,8 @@ mlx5_link_update_unlocked(struct rte_eth_dev *dev, int
wait_to_complete)
dev_link.link_speed = link_speed;
dev_link.link_duplex = ((edata.duplex == DUPLEX_HALF) ?
ETH_LINK_HALF_DUPLEX : ETH_LINK_FULL_DUPLEX);
+ dev_link.link_autoneg = !(dev->data->dev_conf.link_speeds &
+ ETH_LINK_SPEED_FIXED);
if (memcmp(&dev_link, &dev->data->dev_link, sizeof(dev_link))) {
/* Link status changed. */
dev->data->dev_link = dev_link;
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index ef2502a..fb247a7 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -244,8 +244,8 @@ struct rte_eth_stats {
/**
* Device supported speeds bitmap flags
*/
-#define ETH_LINK_SPEED_FIXED(0 << 0) /**< Disable autoneg (fixed
speed) */
-#define ETH_LINK_SPEED_AUTONEG (1 << 0) /**< Autonegotiate (all speeds)
*/
+#define ETH_LINK_SPEED_AUTONEG (0 << 0) /**< Autonegotiate (all speeds)
*/
+#define ETH_LINK_SPEED_FIXED (1 << 0) /**< Disable autoneg (fixed
speed) */
#define ETH_LINK_SPEED_10M_HD (1 << 1) /**< 10 Mbp
[dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API refactoring
t; > Cc: dev at dpdk.org; Marc ; Ananyev, Konstantin >> > ; Lu, Wenzhuo ; >> > Zhang, Helin ; Richardson, Bruce >> > ; Glynn, Michael J < >> michael.j.glynn at intel.com> >> > Subject: Re: [dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API >> > refactoring >> > >> > Is there someone investigating the issue? >> > I think it should be simple to fix for someone mastering these Intel >> drivers. >> > >> > 2016-03-25 01:02, Xu, Qian Q: >> > > Marc >> > > #Test1 is just a simple test. Just launch testpmd with these nic port. >> > > ./testpmd ?c 0x3 ?n 4 -- -i >> > > >> > > Thanks >> > > Qian >> > > >> > > From: marc.sune at gmail.com [mailto:marc.sune at gmail.com] On Behalf Of >> > > Marc >> > > Sent: Thursday, March 24, 2016 3:48 PM >> > > To: Xu, Qian Q >> > > Cc: Thomas Monjalon; Ananyev, Konstantin; Lu, Wenzhuo; Zhang, Helin; >> > > Richardson, Bruce; dev at dpdk.org >> > > Subject: Re: [dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed >> > > API refactoring >> > > >> > > >> > > >> > > On 24 March 2016 at 07:21, Xu, Qian Q >> > mailto:qian.q.xu at intel.com>> wrote: >> > > Marc >> > > I didn?t quite get your points, I observed that after applying this >> patchset, all >> > intel nic can?t be started, maybe something wrong happened when you >> check >> > the duplex/autoneg value for different NICs. If we want to merge the >> patchset in >> > RC2, we need fix them. Maybe not an easy job in several days. >> > > >> > > Is this test#1 one of the tests contained in the DPDK repository or >> is it an >> > internal test? >> > > >> > > Marc >> > > >> > > >> > > >> > > Thanks >> > > Qian >> > > >> > > From: marc.sune at gmail.com<mailto:marc.sune at gmail.com> >> > > [mailto:marc.sune at gmail.com<mailto:marc.sune at gmail.com>] On Behalf >> > > Of >> > > Marc >> > > Sent: Thursday, March 24, 2016 4:54 AM >> > > To: Xu, Qian Q >> > > Cc: Thomas Monjalon; Ananyev, Konstantin; Lu, Wenzhuo; Zhang, Helin; >> > > Richardson, Bruce; dev at dpdk.org<mailto:dev at dpdk.org> >> > > >> > > Subject: Re: [dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed >> > > API refactoring >> > > >> > > Qian, >> > > >> > > On 23 March 2016 at 02:18, Xu, Qian Q >> > mailto:qian.q.xu at intel.com>> wrote: >> > > We have tested with intel nic and found port can't be started for all >> > nics:ixgbe/i40e/igb/bonding, see attached mail for more details. Please >> check >> > and fix it. >> > > >> > > >> > > Thanks >> > > Qian >> > > >> > > -Original Message- >> > > From: dev [mailto:dev-bounces at dpdk.org<mailto:dev-bounces at >> > > dpdk.org>] >> > > On Behalf Of Thomas Monjalon >> > > Sent: Wednesday, March 23, 2016 3:59 AM >> > > To: Ananyev, Konstantin; Lu, Wenzhuo; Zhang, Helin >> > > Cc: marcdevel at gmail.com<mailto:marcdevel at gmail.com>; Richardson, >> > > Bruce; dev at dpdk.org<mailto:dev at dpdk.org> >> > > Subject: Re: [dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed >> > > API refactoring >> > > >> > > 2016-03-17 19:08, Thomas Monjalon: >> > > > There are still too few tests and reviews, especially for >> > > > autonegotiation with Intel devices (patch #6). >> > > > I would not be surprised to see some bugs in this rework. >> > > >> > > Any feedback about autoneg in e1000/ixgbe/i40e? >> > > Has it been tested before its integration in RC2? >> > > >> > > > The capabilities must be adapted per device. It can be improved in a >> > > > separate patch. >> > > > >> > > > It will be integrated in 16.04-rc2. >> > > > Please test and review shortly, thanks! >> > > >> > > >> > > -- Forwarded message -- >> > > From: "Xu, Qian Q" mailto:qian.q.xu at >> > > intel.com>> >> > > To: "Cao, Waterman" >> > > mail
[dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API refactoring
On 25 March 2016 at 16:07, Zhang, Helin wrote: > Hi Thomas > > Beilei is investigating that, she will give her findings soon later, and > possibly a fix after validating that. > Thanks! > > I will try to reproduce this on my side too with the latest v12. I could not try latest patchsets, but i40 (XL710) and igb (82540EM) were working on my side for previous versions. Which exact NICs were used to test the patchset for igb? Marc > Regards, > Helin > > > -Original Message- > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > Sent: Friday, March 25, 2016 5:36 PM > > To: Xu, Qian Q > > Cc: dev at dpdk.org; Marc ; Ananyev, Konstantin > > ; Lu, Wenzhuo ; > > Zhang, Helin ; Richardson, Bruce > > ; Glynn, Michael J < > michael.j.glynn at intel.com> > > Subject: Re: [dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API > > refactoring > > > > Is there someone investigating the issue? > > I think it should be simple to fix for someone mastering these Intel > drivers. > > > > 2016-03-25 01:02, Xu, Qian Q: > > > Marc > > > #Test1 is just a simple test. Just launch testpmd with these nic port. > > > ./testpmd ?c 0x3 ?n 4 -- -i > > > > > > Thanks > > > Qian > > > > > > From: marc.sune at gmail.com [mailto:marc.sune at gmail.com] On Behalf Of > > > Marc > > > Sent: Thursday, March 24, 2016 3:48 PM > > > To: Xu, Qian Q > > > Cc: Thomas Monjalon; Ananyev, Konstantin; Lu, Wenzhuo; Zhang, Helin; > > > Richardson, Bruce; dev at dpdk.org > > > Subject: Re: [dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed > > > API refactoring > > > > > > > > > > > > On 24 March 2016 at 07:21, Xu, Qian Q > > mailto:qian.q.xu at intel.com>> wrote: > > > Marc > > > I didn?t quite get your points, I observed that after applying this > patchset, all > > intel nic can?t be started, maybe something wrong happened when you check > > the duplex/autoneg value for different NICs. If we want to merge the > patchset in > > RC2, we need fix them. Maybe not an easy job in several days. > > > > > > Is this test#1 one of the tests contained in the DPDK repository or is > it an > > internal test? > > > > > > Marc > > > > > > > > > > > > Thanks > > > Qian > > > > > > From: marc.sune at gmail.com<mailto:marc.sune at gmail.com> > > > [mailto:marc.sune at gmail.com<mailto:marc.sune at gmail.com>] On Behalf > > > Of > > > Marc > > > Sent: Thursday, March 24, 2016 4:54 AM > > > To: Xu, Qian Q > > > Cc: Thomas Monjalon; Ananyev, Konstantin; Lu, Wenzhuo; Zhang, Helin; > > > Richardson, Bruce; dev at dpdk.org<mailto:dev at dpdk.org> > > > > > > Subject: Re: [dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed > > > API refactoring > > > > > > Qian, > > > > > > On 23 March 2016 at 02:18, Xu, Qian Q > > mailto:qian.q.xu at intel.com>> wrote: > > > We have tested with intel nic and found port can't be started for all > > nics:ixgbe/i40e/igb/bonding, see attached mail for more details. Please > check > > and fix it. > > > > > > > > > Thanks > > > Qian > > > > > > -Original Message- > > > From: dev [mailto:dev-bounces at dpdk.org<mailto:dev-bounces at dpdk.org>] > > > On Behalf Of Thomas Monjalon > > > Sent: Wednesday, March 23, 2016 3:59 AM > > > To: Ananyev, Konstantin; Lu, Wenzhuo; Zhang, Helin > > > Cc: marcdevel at gmail.com<mailto:marcdevel at gmail.com>; Richardson, > > > Bruce; dev at dpdk.org<mailto:dev at dpdk.org> > > > Subject: Re: [dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed > > > API refactoring > > > > > > 2016-03-17 19:08, Thomas Monjalon: > > > > There are still too few tests and reviews, especially for > > > > autonegotiation with Intel devices (patch #6). > > > > I would not be surprised to see some bugs in this rework. > > > > > > Any feedback about autoneg in e1000/ixgbe/i40e? > > > Has it been tested before its integration in RC2? > > > > > > > The capabilities must be adapted per device. It can be improved in a > > > > separate patch. > > > > > > > > It will be integrated in 16.04-rc2. > > > > Please test and review shortly, thanks! > > > > > > &g
[dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API refactoring
2016-03-25 15:07, Zhang, Helin: > From: Thomas Monjalon > > Is there someone investigating the issue? > > Beilei is investigating that, she will give her findings soon later, and > possibly a fix after validating that. > Thanks! Great thanks! After talking with Bruce, we have decided to close RC2 without this patch and make it a prerequisite for RC3.
[dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API refactoring
Hi Thomas Beilei is investigating that, she will give her findings soon later, and possibly a fix after validating that. Thanks! Regards, Helin > -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Friday, March 25, 2016 5:36 PM > To: Xu, Qian Q > Cc: dev at dpdk.org; Marc ; Ananyev, Konstantin > ; Lu, Wenzhuo ; > Zhang, Helin ; Richardson, Bruce > ; Glynn, Michael J intel.com> > Subject: Re: [dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API > refactoring > > Is there someone investigating the issue? > I think it should be simple to fix for someone mastering these Intel drivers. > > 2016-03-25 01:02, Xu, Qian Q: > > Marc > > #Test1 is just a simple test. Just launch testpmd with these nic port. > > ./testpmd ?c 0x3 ?n 4 -- -i > > > > Thanks > > Qian > > > > From: marc.sune at gmail.com [mailto:marc.sune at gmail.com] On Behalf Of > > Marc > > Sent: Thursday, March 24, 2016 3:48 PM > > To: Xu, Qian Q > > Cc: Thomas Monjalon; Ananyev, Konstantin; Lu, Wenzhuo; Zhang, Helin; > > Richardson, Bruce; dev at dpdk.org > > Subject: Re: [dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed > > API refactoring > > > > > > > > On 24 March 2016 at 07:21, Xu, Qian Q > mailto:qian.q.xu at intel.com>> wrote: > > Marc > > I didn?t quite get your points, I observed that after applying this > > patchset, all > intel nic can?t be started, maybe something wrong happened when you check > the duplex/autoneg value for different NICs. If we want to merge the patchset > in > RC2, we need fix them. Maybe not an easy job in several days. > > > > Is this test#1 one of the tests contained in the DPDK repository or is it an > internal test? > > > > Marc > > > > > > > > Thanks > > Qian > > > > From: marc.sune at gmail.com<mailto:marc.sune at gmail.com> > > [mailto:marc.sune at gmail.com<mailto:marc.sune at gmail.com>] On Behalf Of > > Marc > > Sent: Thursday, March 24, 2016 4:54 AM > > To: Xu, Qian Q > > Cc: Thomas Monjalon; Ananyev, Konstantin; Lu, Wenzhuo; Zhang, Helin; > > Richardson, Bruce; dev at dpdk.org<mailto:dev at dpdk.org> > > > > Subject: Re: [dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed > > API refactoring > > > > Qian, > > > > On 23 March 2016 at 02:18, Xu, Qian Q > mailto:qian.q.xu at intel.com>> wrote: > > We have tested with intel nic and found port can't be started for all > nics:ixgbe/i40e/igb/bonding, see attached mail for more details. Please check > and fix it. > > > > > > Thanks > > Qian > > > > -----Original Message- > > From: dev [mailto:dev-bounces at dpdk.org<mailto:dev-bounces at dpdk.org>] > > On Behalf Of Thomas Monjalon > > Sent: Wednesday, March 23, 2016 3:59 AM > > To: Ananyev, Konstantin; Lu, Wenzhuo; Zhang, Helin > > Cc: marcdevel at gmail.com<mailto:marcdevel at gmail.com>; Richardson, > > Bruce; dev at dpdk.org<mailto:dev at dpdk.org> > > Subject: Re: [dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed > > API refactoring > > > > 2016-03-17 19:08, Thomas Monjalon: > > > There are still too few tests and reviews, especially for > > > autonegotiation with Intel devices (patch #6). > > > I would not be surprised to see some bugs in this rework. > > > > Any feedback about autoneg in e1000/ixgbe/i40e? > > Has it been tested before its integration in RC2? > > > > > The capabilities must be adapted per device. It can be improved in a > > > separate patch. > > > > > > It will be integrated in 16.04-rc2. > > > Please test and review shortly, thanks! > > > > > > -- Forwarded message -- > > From: "Xu, Qian Q" mailto:qian.q.xu at intel.com>> > > To: "Cao, Waterman" > > mailto:waterman.cao at intel.com>>, "Glynn, > > Michael J" > > mailto:michael.j.glynn at intel.com>> > > Cc: "Richardson, Bruce" > > mailto:bruce.richardson at intel.com>>, "Zhu, > > Heqing" mailto:heqing.zhu at intel.com>>, > > "O'Driscoll, Tim" > > mailto:tim.odriscoll at intel.com>>, "Mcnamara, > > John" mailto:john.mcnamara at intel.com>>, "Xu, > > HuilongX" mailto:huilongx.xu at intel.com>>, "Fu, > > JingguoX" mailto:jingguox.fu at intel.com>>, "Xu, > > Qian Q" mailto:qian.q.xu at intel.com>&
[dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API refactoring
Is there someone investigating the issue? I think it should be simple to fix for someone mastering these Intel drivers. 2016-03-25 01:02, Xu, Qian Q: > Marc > #Test1 is just a simple test. Just launch testpmd with these nic port. > ./testpmd ?c 0x3 ?n 4 -- -i > > Thanks > Qian > > From: marc.sune at gmail.com [mailto:marc.sune at gmail.com] On Behalf Of Marc > Sent: Thursday, March 24, 2016 3:48 PM > To: Xu, Qian Q > Cc: Thomas Monjalon; Ananyev, Konstantin; Lu, Wenzhuo; Zhang, Helin; > Richardson, Bruce; dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API > refactoring > > > > On 24 March 2016 at 07:21, Xu, Qian Q intel.com<mailto:qian.q.xu at intel.com>> wrote: > Marc > I didn?t quite get your points, I observed that after applying this patchset, > all intel nic can?t be started, maybe something wrong happened when you check > the duplex/autoneg value for different NICs. If we want to merge the patchset > in RC2, we need fix them. Maybe not an easy job in several days. > > Is this test#1 one of the tests contained in the DPDK repository or is it an > internal test? > > Marc > > > > Thanks > Qian > > From: marc.sune at gmail.com<mailto:marc.sune at gmail.com> [mailto:marc.sune > at gmail.com<mailto:marc.sune at gmail.com>] On Behalf Of Marc > Sent: Thursday, March 24, 2016 4:54 AM > To: Xu, Qian Q > Cc: Thomas Monjalon; Ananyev, Konstantin; Lu, Wenzhuo; Zhang, Helin; > Richardson, Bruce; dev at dpdk.org<mailto:dev at dpdk.org> > > Subject: Re: [dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API > refactoring > > Qian, > > On 23 March 2016 at 02:18, Xu, Qian Q intel.com<mailto:qian.q.xu at intel.com>> wrote: > We have tested with intel nic and found port can't be started for all > nics:ixgbe/i40e/igb/bonding, see attached mail for more details. Please check > and fix it. > > > Thanks > Qian > > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org<mailto:dev-bounces at dpdk.org>] On > Behalf Of Thomas Monjalon > Sent: Wednesday, March 23, 2016 3:59 AM > To: Ananyev, Konstantin; Lu, Wenzhuo; Zhang, Helin > Cc: marcdevel at gmail.com<mailto:marcdevel at gmail.com>; Richardson, Bruce; > dev at dpdk.org<mailto:dev at dpdk.org> > Subject: Re: [dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API > refactoring > > 2016-03-17 19:08, Thomas Monjalon: > > There are still too few tests and reviews, especially for > > autonegotiation with Intel devices (patch #6). > > I would not be surprised to see some bugs in this rework. > > Any feedback about autoneg in e1000/ixgbe/i40e? > Has it been tested before its integration in RC2? > > > The capabilities must be adapted per device. It can be improved in a > > separate patch. > > > > It will be integrated in 16.04-rc2. > > Please test and review shortly, thanks! > > > -- Forwarded message -- > From: "Xu, Qian Q" mailto:qian.q.xu at intel.com>> > To: "Cao, Waterman" mailto:waterman.cao at > intel.com>>, "Glynn, Michael J" intel.com<mailto:michael.j.glynn at intel.com>> > Cc: "Richardson, Bruce" intel.com<mailto:bruce.richardson at intel.com>>, "Zhu, Heqing" at intel.com<mailto:heqing.zhu at intel.com>>, "O'Driscoll, Tim" > mailto:tim.odriscoll at intel.com>>, "Mcnamara, > John" mailto:john.mcnamara at intel.com>>, "Xu, > HuilongX" mailto:huilongx.xu at intel.com>>, "Fu, > JingguoX" mailto:jingguox.fu at intel.com>>, "Xu, > Qian Q" mailto:qian.q.xu at intel.com>>, "Zhang, > Helin" mailto:helin.zhang at intel.com>> > Date: Tue, 22 Mar 2016 06:41:37 + > Subject: RE: DPDK link speed with Intel devices > Hi, all > We have worked out the basic test cases for the patchset. > 1. Test the link speed on major Intel NICs to see if the speed is right. > 2. Test the auto-negoation on major Intel NICs to ensure it's working. > Nic covered: ixgbe, igb, i40e, fm10k, bonding(SW), virtio(SW) > > When we run the Test#1 for all major NICs. We found that all these NIC > port(igb, ixgbe, i40e, fm10k) can't be started. Pls check, if the patch is > applied, all INTEL port can't be start, terrible things! > > Interactive-mode selected > Configuring Port 0 (socket 0) > PMD: ixgbe_dev_tx_queue_setup(): sw_ring=0x7f13e99e3440 > hw_ring=0x7f13e99e5480 dma_addr=0x8299e5480 > PMD: ixgbe_set_tx_function(): Using simple tx code path > PMD: ixgbe_set_tx_function()
[dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API refactoring
Marc #Test1 is just a simple test. Just launch testpmd with these nic port. ./testpmd ?c 0x3 ?n 4 -- -i Thanks Qian From: marc.sune at gmail.com [mailto:marc.s...@gmail.com] On Behalf Of Marc Sent: Thursday, March 24, 2016 3:48 PM To: Xu, Qian Q Cc: Thomas Monjalon; Ananyev, Konstantin; Lu, Wenzhuo; Zhang, Helin; Richardson, Bruce; dev at dpdk.org Subject: Re: [dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API refactoring On 24 March 2016 at 07:21, Xu, Qian Q mailto:qian.q.xu at intel.com>> wrote: Marc I didn?t quite get your points, I observed that after applying this patchset, all intel nic can?t be started, maybe something wrong happened when you check the duplex/autoneg value for different NICs. If we want to merge the patchset in RC2, we need fix them. Maybe not an easy job in several days. Is this test#1 one of the tests contained in the DPDK repository or is it an internal test? Marc Thanks Qian From: marc.sune at gmail.com<mailto:marc.sune at gmail.com> [mailto:marc.sune at gmail.com<mailto:marc.s...@gmail.com>] On Behalf Of Marc Sent: Thursday, March 24, 2016 4:54 AM To: Xu, Qian Q Cc: Thomas Monjalon; Ananyev, Konstantin; Lu, Wenzhuo; Zhang, Helin; Richardson, Bruce; dev at dpdk.org<mailto:dev at dpdk.org> Subject: Re: [dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API refactoring Qian, On 23 March 2016 at 02:18, Xu, Qian Q mailto:qian.q.xu at intel.com>> wrote: We have tested with intel nic and found port can't be started for all nics:ixgbe/i40e/igb/bonding, see attached mail for more details. Please check and fix it. Thanks Qian -Original Message- From: dev [mailto:dev-bounces at dpdk.org<mailto:dev-boun...@dpdk.org>] On Behalf Of Thomas Monjalon Sent: Wednesday, March 23, 2016 3:59 AM To: Ananyev, Konstantin; Lu, Wenzhuo; Zhang, Helin Cc: marcdevel at gmail.com<mailto:marcdevel at gmail.com>; Richardson, Bruce; dev at dpdk.org<mailto:dev at dpdk.org> Subject: Re: [dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API refactoring 2016-03-17 19:08, Thomas Monjalon: > There are still too few tests and reviews, especially for > autonegotiation with Intel devices (patch #6). > I would not be surprised to see some bugs in this rework. Any feedback about autoneg in e1000/ixgbe/i40e? Has it been tested before its integration in RC2? > The capabilities must be adapted per device. It can be improved in a > separate patch. > > It will be integrated in 16.04-rc2. > Please test and review shortly, thanks! -- Forwarded message -- From: "Xu, Qian Q" mailto:qian.q...@intel.com>> To: "Cao, Waterman" mailto:waterman.cao at intel.com>>, "Glynn, Michael J" mailto:michael.j.glynn at intel.com>> Cc: "Richardson, Bruce" mailto:bruce.richardson at intel.com>>, "Zhu, Heqing" mailto:heqing.zhu at intel.com>>, "O'Driscoll, Tim" mailto:tim.odriscoll at intel.com>>, "Mcnamara, John" mailto:john.mcnamara at intel.com>>, "Xu, HuilongX" mailto:huilongx.xu at intel.com>>, "Fu, JingguoX" mailto:jingguox.fu at intel.com>>, "Xu, Qian Q" mailto:qian.q.xu at intel.com>>, "Zhang, Helin" mailto:helin.zhang at intel.com>> Date: Tue, 22 Mar 2016 06:41:37 + Subject: RE: DPDK link speed with Intel devices Hi, all We have worked out the basic test cases for the patchset. 1. Test the link speed on major Intel NICs to see if the speed is right. 2. Test the auto-negoation on major Intel NICs to ensure it's working. Nic covered: ixgbe, igb, i40e, fm10k, bonding(SW), virtio(SW) When we run the Test#1 for all major NICs. We found that all these NIC port(igb, ixgbe, i40e, fm10k) can't be started. Pls check, if the patch is applied, all INTEL port can't be start, terrible things! Interactive-mode selected Configuring Port 0 (socket 0) PMD: ixgbe_dev_tx_queue_setup(): sw_ring=0x7f13e99e3440 hw_ring=0x7f13e99e5480 dma_addr=0x8299e5480 PMD: ixgbe_set_tx_function(): Using simple tx code path PMD: ixgbe_set_tx_function(): Vector tx enabled. PMD: ixgbe_dev_rx_queue_setup(): sw_ring=0x7f13ffcb8080 sw_sc_ring=0x7f13ffcbaac0 hw_ring=0x7f13e99d3380 dma_addr=0x8299d3380 PMD: ixgbe_dev_start(): Invalid link_speeds for port 0; autonegotiation disabled Fail to start port 0 Configuring Port 1 (socket 0) PMD: i40e_set_tx_function_flag(): Vector tx can be enabled on this txq. PMD: i40e_dev_rx_queue_setup(): Rx Burst Bulk Alloc Preconditions are satisfied. Rx Burst Bulk Alloc function will be used on port=1, queue=0. PMD: i40e_dev_start(): Invalid link_speeds for port 1; autonegotiation disabled Just to double-check; is the test#1 adapted to the _new_ API that ethdev has to set link speeds? For the output it seems autoneg is disabled => fixed speed, hence the new bitmaps have to be used.
[dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API refactoring
D?a 17.03.2016 o 19:08 Thomas Monjalon nap?sal(a): > There are still too few tests and reviews, especially for > autonegotiation with Intel devices (patch #6). > I would not be surprised to see some bugs in this rework. > > The capabilities must be adapted per device. It can be > improved in a separate patch. > > It will be integrated in 16.04-rc2. > Please test and review shortly, thanks! > > [...] Tested-by: Matej Vido Correct speed is displayed for COMBO-100G card. Regards, Matej
[dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API refactoring
On 24 March 2016 at 07:21, Xu, Qian Q wrote: > Marc > > I didn?t quite get your points, I observed that after applying this > patchset, all intel nic can?t be started, maybe something wrong happened > when you check the duplex/autoneg value for different NICs. If we want to > merge the patchset in RC2, we need fix them. Maybe not an easy job in > several days. > Is this test#1 one of the tests contained in the DPDK repository or is it an internal test? Marc > > > > > Thanks > > Qian > > > > *From:* marc.sune at gmail.com [mailto:marc.sune at gmail.com] *On Behalf Of * > Marc > *Sent:* Thursday, March 24, 2016 4:54 AM > *To:* Xu, Qian Q > *Cc:* Thomas Monjalon; Ananyev, Konstantin; Lu, Wenzhuo; Zhang, Helin; > Richardson, Bruce; dev at dpdk.org > > *Subject:* Re: [dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API > refactoring > > > > Qian, > > > > On 23 March 2016 at 02:18, Xu, Qian Q wrote: > > We have tested with intel nic and found port can't be started for all > nics:ixgbe/i40e/igb/bonding, see attached mail for more details. Please > check and fix it. > > > Thanks > Qian > > > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > Sent: Wednesday, March 23, 2016 3:59 AM > To: Ananyev, Konstantin; Lu, Wenzhuo; Zhang, Helin > Cc: marcdevel at gmail.com; Richardson, Bruce; dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API > refactoring > > 2016-03-17 19:08, Thomas Monjalon: > > There are still too few tests and reviews, especially for > > autonegotiation with Intel devices (patch #6). > > I would not be surprised to see some bugs in this rework. > > Any feedback about autoneg in e1000/ixgbe/i40e? > Has it been tested before its integration in RC2? > > > The capabilities must be adapted per device. It can be improved in a > > separate patch. > > > > It will be integrated in 16.04-rc2. > > Please test and review shortly, thanks! > > > > -- Forwarded message -- > From: "Xu, Qian Q" > To: "Cao, Waterman" , "Glynn, Michael J" < > michael.j.glynn at intel.com> > Cc: "Richardson, Bruce" , "Zhu, Heqing" < > heqing.zhu at intel.com>, "O'Driscoll, Tim" , > "Mcnamara, John" , "Xu, HuilongX" < > huilongx.xu at intel.com>, "Fu, JingguoX" , "Xu, > Qian > Q" , "Zhang, Helin" > Date: Tue, 22 Mar 2016 06:41:37 + > Subject: RE: DPDK link speed with Intel devices > Hi, all > We have worked out the basic test cases for the patchset. > 1. Test the link speed on major Intel NICs to see if the speed is right. > 2. Test the auto-negoation on major Intel NICs to ensure it's working. > Nic covered: ixgbe, igb, i40e, fm10k, bonding(SW), virtio(SW) > > When we run the Test#1 for all major NICs. We found that all these NIC > port(igb, ixgbe, i40e, fm10k) can't be started. Pls check, if the patch is > applied, all INTEL port can't be start, terrible things! > > Interactive-mode selected > Configuring Port 0 (socket 0) > PMD: ixgbe_dev_tx_queue_setup(): sw_ring=0x7f13e99e3440 > hw_ring=0x7f13e99e5480 dma_addr=0x8299e5480 > PMD: ixgbe_set_tx_function(): Using simple tx code path > PMD: ixgbe_set_tx_function(): Vector tx enabled. > PMD: ixgbe_dev_rx_queue_setup(): sw_ring=0x7f13ffcb8080 > sw_sc_ring=0x7f13ffcbaac0 hw_ring=0x7f13e99d3380 dma_addr=0x8299d3380 > PMD: ixgbe_dev_start(): Invalid link_speeds for port 0; autonegotiation > disabled > Fail to start port 0 > Configuring Port 1 (socket 0) > PMD: i40e_set_tx_function_flag(): Vector tx can be enabled on this txq. > PMD: i40e_dev_rx_queue_setup(): Rx Burst Bulk Alloc Preconditions are > satisfied. Rx Burst Bulk Alloc function will be used on port=1, queue=0. > PMD: i40e_dev_start(): Invalid link_speeds for port 1; autonegotiation > disabled > > > > > > Just to double-check; is the test#1 adapted to the _new_ API that ethdev > has to set link speeds? For the output it seems autoneg is disabled => > fixed speed, hence the new bitmaps have to be used. > > > > (I am not claiming patchset is bug free; there might be issues still) > > > > Regards > > marc > > > > Fail to start port 1 > Please stop the ports first > Done > > Thanks > Qian > > > -Original Message- > From: Cao, Waterman > Sent: Tuesday, March 22, 2016 11:06 AM > To: Glynn, Michael J > Cc: Richardson, Bruce; Zhu, Heqing; O'Driscoll, Tim; Mcnamara, John; Xu, > Qian Q; Cao, Waterman > Subjec
[dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API refactoring
Marc I didn?t quite get your points, I observed that after applying this patchset, all intel nic can?t be started, maybe something wrong happened when you check the duplex/autoneg value for different NICs. If we want to merge the patchset in RC2, we need fix them. Maybe not an easy job in several days. Thanks Qian From: marc.sune at gmail.com [mailto:marc.s...@gmail.com] On Behalf Of Marc Sent: Thursday, March 24, 2016 4:54 AM To: Xu, Qian Q Cc: Thomas Monjalon; Ananyev, Konstantin; Lu, Wenzhuo; Zhang, Helin; Richardson, Bruce; dev at dpdk.org Subject: Re: [dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API refactoring Qian, On 23 March 2016 at 02:18, Xu, Qian Q mailto:qian.q.xu at intel.com>> wrote: We have tested with intel nic and found port can't be started for all nics:ixgbe/i40e/igb/bonding, see attached mail for more details. Please check and fix it. Thanks Qian -Original Message- From: dev [mailto:dev-bounces at dpdk.org<mailto:dev-boun...@dpdk.org>] On Behalf Of Thomas Monjalon Sent: Wednesday, March 23, 2016 3:59 AM To: Ananyev, Konstantin; Lu, Wenzhuo; Zhang, Helin Cc: marcdevel at gmail.com<mailto:marcdevel at gmail.com>; Richardson, Bruce; dev at dpdk.org<mailto:dev at dpdk.org> Subject: Re: [dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API refactoring 2016-03-17 19:08, Thomas Monjalon: > There are still too few tests and reviews, especially for > autonegotiation with Intel devices (patch #6). > I would not be surprised to see some bugs in this rework. Any feedback about autoneg in e1000/ixgbe/i40e? Has it been tested before its integration in RC2? > The capabilities must be adapted per device. It can be improved in a > separate patch. > > It will be integrated in 16.04-rc2. > Please test and review shortly, thanks! -- Forwarded message -- From: "Xu, Qian Q" mailto:qian.q...@intel.com>> To: "Cao, Waterman" mailto:waterman.cao at intel.com>>, "Glynn, Michael J" mailto:michael.j.glynn at intel.com>> Cc: "Richardson, Bruce" mailto:bruce.richardson at intel.com>>, "Zhu, Heqing" mailto:heqing.zhu at intel.com>>, "O'Driscoll, Tim" mailto:tim.odriscoll at intel.com>>, "Mcnamara, John" mailto:john.mcnamara at intel.com>>, "Xu, HuilongX" mailto:huilongx.xu at intel.com>>, "Fu, JingguoX" mailto:jingguox.fu at intel.com>>, "Xu, Qian Q" mailto:qian.q.xu at intel.com>>, "Zhang, Helin" mailto:helin.zhang at intel.com>> Date: Tue, 22 Mar 2016 06:41:37 + Subject: RE: DPDK link speed with Intel devices Hi, all We have worked out the basic test cases for the patchset. 1. Test the link speed on major Intel NICs to see if the speed is right. 2. Test the auto-negoation on major Intel NICs to ensure it's working. Nic covered: ixgbe, igb, i40e, fm10k, bonding(SW), virtio(SW) When we run the Test#1 for all major NICs. We found that all these NIC port(igb, ixgbe, i40e, fm10k) can't be started. Pls check, if the patch is applied, all INTEL port can't be start, terrible things! Interactive-mode selected Configuring Port 0 (socket 0) PMD: ixgbe_dev_tx_queue_setup(): sw_ring=0x7f13e99e3440 hw_ring=0x7f13e99e5480 dma_addr=0x8299e5480 PMD: ixgbe_set_tx_function(): Using simple tx code path PMD: ixgbe_set_tx_function(): Vector tx enabled. PMD: ixgbe_dev_rx_queue_setup(): sw_ring=0x7f13ffcb8080 sw_sc_ring=0x7f13ffcbaac0 hw_ring=0x7f13e99d3380 dma_addr=0x8299d3380 PMD: ixgbe_dev_start(): Invalid link_speeds for port 0; autonegotiation disabled Fail to start port 0 Configuring Port 1 (socket 0) PMD: i40e_set_tx_function_flag(): Vector tx can be enabled on this txq. PMD: i40e_dev_rx_queue_setup(): Rx Burst Bulk Alloc Preconditions are satisfied. Rx Burst Bulk Alloc function will be used on port=1, queue=0. PMD: i40e_dev_start(): Invalid link_speeds for port 1; autonegotiation disabled Just to double-check; is the test#1 adapted to the _new_ API that ethdev has to set link speeds? For the output it seems autoneg is disabled => fixed speed, hence the new bitmaps have to be used. (I am not claiming patchset is bug free; there might be issues still) Regards marc Fail to start port 1 Please stop the ports first Done Thanks Qian -Original Message- From: Cao, Waterman Sent: Tuesday, March 22, 2016 11:06 AM To: Glynn, Michael J Cc: Richardson, Bruce; Zhu, Heqing; O'Driscoll, Tim; Mcnamara, John; Xu, Qian Q; Cao, Waterman Subject: RE: DPDK link speed with Intel devices Hi Mike, We just knew this patch set last week. Since this patch set is required to test with a lot of NIC, we need more document from Dev about this patch. Currently, Qian is working on with Wenzhuo on it now. Waterman -Original Message- From: Glynn, Michael J Sent: Tuesda
[dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API refactoring
Qian, On 23 March 2016 at 02:18, Xu, Qian Q wrote: > We have tested with intel nic and found port can't be started for all > nics:ixgbe/i40e/igb/bonding, see attached mail for more details. Please > check and fix it. > > > Thanks > Qian > > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > Sent: Wednesday, March 23, 2016 3:59 AM > To: Ananyev, Konstantin; Lu, Wenzhuo; Zhang, Helin > Cc: marcdevel at gmail.com; Richardson, Bruce; dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API > refactoring > > 2016-03-17 19:08, Thomas Monjalon: > > There are still too few tests and reviews, especially for > > autonegotiation with Intel devices (patch #6). > > I would not be surprised to see some bugs in this rework. > > Any feedback about autoneg in e1000/ixgbe/i40e? > Has it been tested before its integration in RC2? > > > The capabilities must be adapted per device. It can be improved in a > > separate patch. > > > > It will be integrated in 16.04-rc2. > > Please test and review shortly, thanks! > > > > -- Forwarded message -- > From: "Xu, Qian Q" > To: "Cao, Waterman" , "Glynn, Michael J" < > michael.j.glynn at intel.com> > Cc: "Richardson, Bruce" , "Zhu, Heqing" < > heqing.zhu at intel.com>, "O'Driscoll, Tim" , > "Mcnamara, John" , "Xu, HuilongX" < > huilongx.xu at intel.com>, "Fu, JingguoX" , "Xu, > Qian > Q" , "Zhang, Helin" > Date: Tue, 22 Mar 2016 06:41:37 + > Subject: RE: DPDK link speed with Intel devices > Hi, all > We have worked out the basic test cases for the patchset. > 1. Test the link speed on major Intel NICs to see if the speed is right. > 2. Test the auto-negoation on major Intel NICs to ensure it's working. > Nic covered: ixgbe, igb, i40e, fm10k, bonding(SW), virtio(SW) > > When we run the Test#1 for all major NICs. We found that all these NIC > port(igb, ixgbe, i40e, fm10k) can't be started. Pls check, if the patch is > applied, all INTEL port can't be start, terrible things! > > Interactive-mode selected > Configuring Port 0 (socket 0) > PMD: ixgbe_dev_tx_queue_setup(): sw_ring=0x7f13e99e3440 > hw_ring=0x7f13e99e5480 dma_addr=0x8299e5480 > PMD: ixgbe_set_tx_function(): Using simple tx code path > PMD: ixgbe_set_tx_function(): Vector tx enabled. > PMD: ixgbe_dev_rx_queue_setup(): sw_ring=0x7f13ffcb8080 > sw_sc_ring=0x7f13ffcbaac0 hw_ring=0x7f13e99d3380 dma_addr=0x8299d3380 > PMD: ixgbe_dev_start(): Invalid link_speeds for port 0; autonegotiation > disabled > Fail to start port 0 > Configuring Port 1 (socket 0) > PMD: i40e_set_tx_function_flag(): Vector tx can be enabled on this txq. > PMD: i40e_dev_rx_queue_setup(): Rx Burst Bulk Alloc Preconditions are > satisfied. Rx Burst Bulk Alloc function will be used on port=1, queue=0. > PMD: i40e_dev_start(): Invalid link_speeds for port 1; autonegotiation > disabled > Just to double-check; is the test#1 adapted to the _new_ API that ethdev has to set link speeds? For the output it seems autoneg is disabled => fixed speed, hence the new bitmaps have to be used. (I am not claiming patchset is bug free; there might be issues still) Regards marc Fail to start port 1 > Please stop the ports first > Done > > Thanks > Qian > > > -Original Message- > From: Cao, Waterman > Sent: Tuesday, March 22, 2016 11:06 AM > To: Glynn, Michael J > Cc: Richardson, Bruce; Zhu, Heqing; O'Driscoll, Tim; Mcnamara, John; Xu, > Qian Q; Cao, Waterman > Subject: RE: DPDK link speed with Intel devices > > Hi Mike, > > We just knew this patch set last week. > Since this patch set is required to test with a lot of NIC, we > need more document from Dev about this patch. > Currently, Qian is working on with Wenzhuo on it now. > > Waterman > > > -Original Message- > From: Glynn, Michael J > Sent: Tuesday, March 22, 2016 1:31 AM > To: Cao, Waterman > Cc: Richardson, Bruce ; Zhu, Heqing < > heqing.zhu at intel.com>; O'Driscoll, Tim ; > Mcnamara, John > Subject: FW: DPDK link speed with Intel devices > Importance: High > > Hi Waterman, all > > See below - are you aware? And if so where are we with testing/resolution? > > Regards > Mike > > > > -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Monday, March 21, 2016 2:19 PM > To: O'Driscoll, Tim ; Glynn, Michael J < > michael.j.glynn at intel.com>; Zhu, Heqing > Cc: vincent.jardin at 6wind.com > Subject: DPDK link speed with Intel devices > > Hi, > > We are still waiting for test feedbacks for this important patchset: > ethdev: 100G and link speed API refactoring It is possible that it > breaks the autonegotiation in e1000/ixgbe/i40e. > > Thanks for taking care. > >
[dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API refactoring
2016-03-23 01:18, Xu, Qian Q: > We have tested with intel nic and found port can't be started for all > nics:ixgbe/i40e/igb/bonding, see attached mail for more details. > Please check and fix it. Thanks for testing. This patchset was in the air for several months but unfortunately there was no test of Intel devices until now. Please Intel drivers maintainers, help to fix it quickly. Thanks
[dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API refactoring
We have tested with intel nic and found port can't be started for all nics:ixgbe/i40e/igb/bonding, see attached mail for more details. Please check and fix it. Thanks Qian -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Thomas Monjalon Sent: Wednesday, March 23, 2016 3:59 AM To: Ananyev, Konstantin; Lu, Wenzhuo; Zhang, Helin Cc: marcdevel at gmail.com; Richardson, Bruce; dev at dpdk.org Subject: Re: [dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API refactoring 2016-03-17 19:08, Thomas Monjalon: > There are still too few tests and reviews, especially for > autonegotiation with Intel devices (patch #6). > I would not be surprised to see some bugs in this rework. Any feedback about autoneg in e1000/ixgbe/i40e? Has it been tested before its integration in RC2? > The capabilities must be adapted per device. It can be improved in a > separate patch. > > It will be integrated in 16.04-rc2. > Please test and review shortly, thanks!
[dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API refactoring
2016-03-17 19:08, Thomas Monjalon: > There are still too few tests and reviews, especially for > autonegotiation with Intel devices (patch #6). > I would not be surprised to see some bugs in this rework. Any feedback about autoneg in e1000/ixgbe/i40e? Has it been tested before its integration in RC2? > The capabilities must be adapted per device. It can be > improved in a separate patch. > > It will be integrated in 16.04-rc2. > Please test and review shortly, thanks!
[dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API refactoring
There are still too few tests and reviews, especially for autonegotiation with Intel devices (patch #6). I would not be surprised to see some bugs in this rework. The capabilities must be adapted per device. It can be improved in a separate patch. It will be integrated in 16.04-rc2. Please test and review shortly, thanks! This series of patches adds the following capabilities: * speed_capa bitmap in rte_eth_dev_info, which is filled by the PMDs according to the physical device capabilities. * refactors link API in ethdev to allow the definition of the advertised link speeds, fix speed (no auto-negociation) or advertise all supported speeds (default). v11: - rebase on 16.04-rc1 - replace on more link status value in e1000 driver - merge szedata2 patches - remove szedata2 temporary comments in code and doc v10: - rebase - rework release notes - rearrange patch splitting - fix doxygen comments - fix typos - removed log format of link.link_speed as %d (keep %u) - complete ETH_LINK_[DOWN/UP] replacement from 0/1 - change ETH_LINK_SPEED_AUTONEG to 1 - replace ETH_LINK_SPEED_NEG by ETH_LINK_SPEED_AUTONEG (1) - replace ETH_LINK_SPEED_NO_AUTONEG by ETH_LINK_SPEED_FIXED (0) - rework rte_eth_speed_to_bm_flag to rte_eth_speed_bitflag - complete 100G support in testpmd v9: rebased to current HEAD. Reverted numeric speed to 32 bit in struct rte_eth_link (no atomic link get > 64bit). Fixed mlx5 driver compilation and link speeds. Moved documentation to release_16_04.rst and fixed several issues. Upgrade NIC notes with speed capabilities. v8: Rebased to current HEAD. Modified em driver impl. to not touch base files. Merged patch 5 into 3 (map file). Changed numeric speed to a 64 bit value. Filled-in speed capabilities for drivers bnx2x, cxgbe, mlx5 and nfp in addition to the ones of previous patch sets. v7: Rebased to current HEAD. Moved documentation to v2.3. Still needs testing from PMD maintainers. v6: Move link_duplex to be part of bitfield. Fixed i40 autoneg flag link update code. Added rte_eth_speed_to_bm_flag() to .map file. Fixed other spelling issues. Rebased to current HEAD. v5: revert to v2 speed capabilities patch. Fixed MLX4 speed capabilities (thanks N. Laranjeiro). Refactored link speed API to allow setting advertised speeds (3/4). Added NO_AUTONEG option to explicitely disable auto-negociation. Updated 2.2 rel. notes (4/4). Rebased to current HEAD. v4: fixed errata in the documentation of field speeds of rte_eth_conf, and commit 1/2 message. rebased to v2.1.0. v3 was incorrectly based on ~2.1.0-rc1. v3: rebase to v2.1. unified ETH_LINK_SPEED and ETH_SPEED_CAP into ETH_SPEED. Converted field speed in struct rte_eth_conf to speed, to allow a bitmap for defining the announced speeds, as suggested M. Brorup. Fixed spelling issues. v2: rebase, converted speed_capa into 32 bits bitmap, fixed alignment (checkpatch). Marc Sune (6): ethdev: use constants for link duplex app/testpmd: move speed and duplex parsing in a function ethdev: rename link speed constants ethdev: add speed capabilities ethdev: redesign link speed config ethdev: convert speed number to bitmap flag Thomas Monjalon (2): ethdev: use constants for link state ethdev: add 100G link speed app/test-pipeline/init.c | 2 +- app/test-pmd/cmdline.c | 125 ++--- app/test-pmd/testpmd.c | 2 +- app/test/test_pmd_perf.c | 2 +- app/test/virtual_pmd.c | 8 +- doc/guides/nics/overview.rst | 1 + doc/guides/nics/szedata2.rst | 6 - doc/guides/rel_notes/release_16_04.rst | 22 doc/guides/testpmd_app_ug/testpmd_funcs.rst| 2 +- drivers/net/af_packet/rte_eth_af_packet.c | 9 +- drivers/net/bnx2x/bnx2x_ethdev.c | 7 +- drivers/net/bnx2x/elink.c | 2 +- drivers/net/bonding/rte_eth_bond_8023ad.c | 14 +-- drivers/net/bonding/rte_eth_bond_api.c | 4 +- drivers/net/bonding/rte_eth_bond_pmd.c | 12 +- drivers/net/cxgbe/base/t4_hw.c | 8 +- drivers/net/cxgbe/cxgbe_ethdev.c | 1 + drivers/net/e1000/em_ethdev.c | 113 +-- drivers/net/e1000/igb_ethdev.c | 104 + drivers/net/fm10k/fm10k_ethdev.c | 6 +- drivers/net/i40e/i40e_ethdev.c | 76 +++-- drivers/net/i40e/i40e_ethdev_vf.c | 11 +- drivers/net/ixgbe/ixgbe_ethdev.c | 76 ++--- drivers/net/mlx4/mlx4.c| 4 + drivers/net/mlx5/mlx5_ethdev.c |
