[dpdk-dev] [PATCH v13 4/8] ethdev: rename link speed constants

2016-04-06 Thread Weglicki, MichalX
Hello, 

Thank you for your answer. 

I didn't mention that patch is cosmetic, rather naming. 

But all clear, I somehow missed it 9 months ago, and couldn't find it. 

Is there any official place where I can find upcoming ABI & API changes, or I 
have to dig through mailing list? 

Thank you in advance. 

Br, 
Michal. 

-Original Message-
From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] 
Sent: Wednesday, April 6, 2016 9:53 AM
To: Weglicki, MichalX 
Cc: Marc Sune ; Xu, Qian Q ; 
Xing, Beilei ; dev at dpdk.org; Ananyev, Konstantin 
; Lu, Wenzhuo ; 
Richardson, Bruce ; Glynn, Michael J 
; Gray, Mark D 
Subject: Re: [dpdk-dev] [PATCH v13 4/8] ethdev: rename link speed constants

2016-04-06 08:34, Weglicki, MichalX:
> Hello, 
> 
> I have a question about this patch. 
> 
> As far as I see changing ETH_LINK_SPEED_ to ETH_SPEED_NUM_ is rather cosmetic 
> change, am I right? 

No.
ETH_LINK_SPEED was used for configuration and reported speed.
Now the configuration is done with a bitmap filled with new ETH_LINK_SPEED
and the old numerical values are kept for other usages as ETH_SPEED_NUM.

> Disadvantage of that is that it breaks compatibility with OVS (compilation) 
> and thus it also breaks backward compatibility between OVS & DPDK. Is it 
> really necessary? 

Yes that's why this change was discussed 9 months ago and announced in the
previous release notes.

> It would be great to keep ABI & API stable if possible.

We try to keep it stable when possible and continue to bring some improvements.

--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.



[dpdk-dev] [PATCH v13 4/8] ethdev: rename link speed constants

2016-04-06 Thread Weglicki, MichalX
Hello, 

I have a question about this patch. 

As far as I see changing ETH_LINK_SPEED_ to ETH_SPEED_NUM_ is rather cosmetic 
change, am I right? 

Disadvantage of that is that it breaks compatibility with OVS (compilation) and 
thus it also breaks backward compatibility between OVS & DPDK. Is it really 
necessary? 

It would be great to keep ABI & API stable if possible. 

Br, 
Michal. 

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Marc Sune
Sent: Saturday, March 26, 2016 1:27 AM
To: Thomas Monjalon ; Xu, Qian Q ; Xing, Beilei ; dev at dpdk.org; Ananyev, 
Konstantin ; Lu, Wenzhuo ; Richardson, Bruce ; Glynn, Michael J 

Cc: Marc Sune 
Subject: [dpdk-dev] [PATCH v13 4/8] ethdev: rename link speed constants

The speed numbers ETH_LINK_SPEED_ are renamed ETH_SPEED_NUM_.
The prefix ETH_LINK_SPEED_ is kept for AUTONEG and will be used
for bit flags in next patch.

Signed-off-by: Marc Sune 
---
 app/test-pmd/cmdline.c| 10 +-
 app/test/virtual_pmd.c|  2 +-
 drivers/net/af_packet/rte_eth_af_packet.c |  2 +-
 drivers/net/bonding/rte_eth_bond_8023ad.c | 12 ++--
 drivers/net/cxgbe/base/t4_hw.c|  8 
 drivers/net/e1000/em_ethdev.c |  8 
 drivers/net/e1000/igb_ethdev.c|  8 
 drivers/net/ena/ena_ethdev.c  |  2 +-
 drivers/net/i40e/i40e_ethdev.c| 30 +++---
 drivers/net/i40e/i40e_ethdev_vf.c |  2 +-
 drivers/net/ixgbe/ixgbe_ethdev.c  | 22 +++---
 drivers/net/mpipe/mpipe_tilegx.c  |  4 ++--
 drivers/net/nfp/nfp_net.c |  2 +-
 drivers/net/null/rte_eth_null.c   |  2 +-
 drivers/net/pcap/rte_eth_pcap.c   |  2 +-
 drivers/net/ring/rte_eth_ring.c   |  2 +-
 drivers/net/szedata2/rte_eth_szedata2.c   |  8 
 drivers/net/vmxnet3/vmxnet3_ethdev.c  |  2 +-
 drivers/net/xenvirt/rte_eth_xenvirt.c |  2 +-
 lib/librte_ether/rte_ethdev.h | 29 ++---
 20 files changed, 83 insertions(+), 76 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index eb7bbb4..815b53b 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -1006,20 +1006,20 @@ parse_and_check_speed_duplex(char *speedstr, char 
*duplexstr, uint16_t *speed)
}

if (!strcmp(speedstr, "10")) {
-   *speed = ETH_LINK_SPEED_10;
+   *speed = ETH_SPEED_NUM_10M;
} else if (!strcmp(speedstr, "100")) {
-   *speed = ETH_LINK_SPEED_100;
+   *speed = ETH_SPEED_NUM_100M;
} else {
if (duplex != ETH_LINK_FULL_DUPLEX) {
printf("Invalid speed/duplex parameters\n");
return -1;
}
if (!strcmp(speedstr, "1000")) {
-   *speed = ETH_LINK_SPEED_1000;
+   *speed = ETH_SPEED_NUM_1G;
} else if (!strcmp(speedstr, "1")) {
-   *speed = ETH_LINK_SPEED_10G;
+   *speed = ETH_SPEED_NUM_10G;
} else if (!strcmp(speedstr, "4")) {
-   *speed = ETH_LINK_SPEED_40G;
+   *speed = ETH_SPEED_NUM_40G;
} else if (!strcmp(speedstr, "auto")) {
*speed = ETH_LINK_SPEED_AUTONEG;
} else {
diff --git a/app/test/virtual_pmd.c b/app/test/virtual_pmd.c
index b1d40d7..b4bd2f2 100644
--- a/app/test/virtual_pmd.c
+++ b/app/test/virtual_pmd.c
@@ -604,7 +604,7 @@ virtual_ethdev_create(const char *name, struct ether_addr 
*mac_addr,
TAILQ_INIT(&(eth_dev->link_intr_cbs));

eth_dev->data->dev_link.link_status = ETH_LINK_DOWN;
-   eth_dev->data->dev_link.link_speed = ETH_LINK_SPEED_1;
+   eth_dev->data->dev_link.link_speed = ETH_SPEED_NUM_10G;
eth_dev->data->dev_link.link_duplex = ETH_LINK_FULL_DUPLEX;

eth_dev->data->mac_addrs = rte_zmalloc(name, ETHER_ADDR_LEN, 0);
diff --git a/drivers/net/af_packet/rte_eth_af_packet.c 
b/drivers/net/af_packet/rte_eth_af_packet.c
index dee7b59..641f849 100644
--- a/drivers/net/af_packet/rte_eth_af_packet.c
+++ b/drivers/net/af_packet/rte_eth_af_packet.c
@@ -116,7 +116,7 @@ static const char *valid_arguments[] = {
 static const char *drivername = "AF_PACKET PMD";

 static struct rte_eth_link pmd_link = {
-   .link_speed = 1,
+   .link_speed = ETH_SPEED_NUM_10G,
.link_duplex = ETH_LINK_FULL_DUPLEX,
.link_status = ETH_LINK_DOWN,
 };
diff --git a/drivers/net/bonding/rte_eth_bond_8023ad.c 
b/drivers/net/bonding/rte_eth_bond_8023ad.c
index 1b7e93a..ac8306f 100644
--- a/drivers/net/bonding/rte_eth_bond_8023ad.c
+++ b/drivers/net/bonding/rte_eth_bond_8023ad.c
@@ -711,22 +711,22 @@ link_speed_key(uint16_t speed) {
case ETH_LINK_SPEED_AUTONEG:
key_speed = 0x00;

[dpdk-dev] DPDK2.1 (rc3 & rc4) major performance drop.

2015-08-11 Thread Weglicki, MichalX
Hello,

Currently I'm integrating OVS head with DPDK 2.1. Based on my tests performance 
in all scenarios (confirmed on Phy2Phy and Vhostuser) has dropped about 10%. 
Please find example results below:

PHY2PHY (Bidirectional)
DPDK 2.1:
Iteration 1: 14,164,987 pps
Iteration 2: 13,866,386 pps
Iteration 3: 14,093,153 pps
DPDK 2.0:
Iteration 1: 15,406,646 pps
Iteration 2: 15,410,182 pps
Iteration 3: 15,404,678 pps

VHOSTUser:
DPDK 2.1:
Iteration 1: 3,328,678 pps
Iteration 2: 3,367,130 pps
Iteration 3: 3,259,899 pps
DPDK 2.0:
Iteration 1: 3,786,969 pps
Iteration 2: 3,736,117 pps
Iteration 3: 3,557,150 pps

Based on my test last commit where performance was the same was: 
37f9a7270e800df5c603b2c76c73ed3bca3328d9
Bad commit: 1d493a49490fa90e09689d49280cff0d51d0193e

You can find diff in attachment.

Change is still compatible in OVS because in rte_pktmbuf_pool_init, NULL is 
passed as second argument.

Did anyone noticed such performance drop? Could anyone give me some information 
why this implementation has changed? Any hints how to get back to previous 
performance would be very appreciated.

Br,
Michal.


--
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). Any review or distribution by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies.