[dpdk-dev] On DPDK ABI policy

2016-04-08 Thread Marc Sune
2016-04-07 13:51 GMT+02:00 Panu Matilainen :

> [ change of subject since this is about ABI policy, not namespacing ]
>
> On 04/07/2016 01:16 PM, Marc Sune wrote:
>
>>
>>
>> 2016-04-07 11:33 GMT+02:00 Panu Matilainen > <mailto:pmatilai at redhat.com>>:
>>
>> On 04/07/2016 12:18 PM, Thomas Monjalon wrote:
>>
>> Thank you everyone for the feedbacks.
>>
>> 2016-04-05 15:56, Thomas Monjalon:
>>
>> The goal of this email is to get some feedback on how
>> important it is
>> to fix the DPDK namespace.
>>
>>
>> Everybody agree every symbols must be prefixed. Checking and
>> fixing the
>> namespace consistency will be in the roadmap.
>>
>> It seems most of you agree renaming would be a nice improvement
>> but not
>> so important.
>> The main drawback is the induced backporting pain, even if we have
>> some scripts to convert the patches to the old namespace.
>> Note: the backports can be in DPDK itself or in the applications.
>>
>> If there is enough agreement that we should do something, I
>> suggest to
>> introduce the "dpdk_" prefix slowly and live with both
>> "rte_" and "dpdk_"
>> during some time.
>> We could start using the new prefix for the new APIs
>> (example: crypto)
>> or when there is a significant API break (example: mempool).
>>
>>
>> The slow change has been clearly rejected in favor of a complete
>> change
>> in one patch.
>> The timing was also discussed as it could impact the pending
>> patches.
>> So it would be done at the end or the beginning of a release.
>> Marc suggests to do it for 16.04 as the numbering scheme has
>> changed.
>>
>>
>> Just noting that it cannot be done in 16.04 because the ABI policy
>> requires a deprecation cycle of at least one major release for every
>> breakage. And we're discussing a total 100% breakage of everything
>> here, even if its just a simple rename.
>>
>>
>> I keep not understanding the ABI policy, and particularly why ABI
>> changes have to be announced once cycle before _if_ there is already at
>> least one ABI change proposed. DPDK applications will have to recompile
>> anyway.
>>
>
> The point is to allow API/ABI consumers to assess in advance what sort of
> pains can they expect when moving their applications from one version to
> another. Otherwise all sorts of massive changes could ride the wave of
> whatever "change 16bit struct member to 32bit" trivialities that are
> nevertheless ABI breaks.
>
> There have already been quite a few exceptions to the rule when the ABI is
> already being broken, so its not entirely rigid. Another point that migth
> warrant some tweaking to the policy is the "core" libraries depending on
> each other so an ABI break in any one of them forces recompile of
> everything anyway.
>

In addition to what Matthew said:

I don't understand which sort of pains an announcement saying "we are going
to change this structure and this other, for those high level reasons, but
we don't know exactly how yet, because it is not fully implemented" can be
of any help to a DPDK user. At least it does not to me. This information
has to be in the release notes and users can read that before deciding to
upgrade to a new release.

On the other side, bug fixes still go to NEXT_VERSION. So in 1 ouf ot 2
cases (so far), next release is breaking ABI, so you will have to anyway
recompile your application.

And about ABI breakages; DPDK is not a standard library/library set. For
performance reasons it has a lot of inline code and other optimizations, so
even for small bug fixings can brake ABI, or to be precise, some bug fixes
in inline functions may be silently ignored. I don't know how many users
really use dynamic libraries for DPDK and if there is some warning
somewhere in the documentation for that.


> This aspect of the policy only slows down DPDK development and it
>>
>
> One could also think that slowing down development and forcing people to
> think ahead are not entirely unintentional or unwanted side-effects :)
>
> Look at the latest librte_vhost initiative to remove unnecessarily exposed
> structs to avoid having to deal with ABI breakages all the time: the policy
> is effectively encouraging people into better library design.
>
> pollutes th

[dpdk-dev] On DPDK ABI policy

2016-04-08 Thread Marc Sune
2016-04-07 23:52 GMT+02:00 Matthew Hall :

> On Thu, Apr 07, 2016 at 02:51:35PM +0300, Panu Matilainen wrote:
> > LTS releases could help the situation somewhat, but then again
> > people tend to still want those new fancy things backported (you
> > know, have the cake and eat it too) but that can't be done because
> > of ABI breakage, so they're forced to run the latest version anyway.
>
> RH and Debian / Ubuntu don't put features in LTS except extremely rarely.
> Generally only if there's severe functionality breakage or security issues
> and
> the rest is ignored, and for good reason, as this is much more reliable and
> simple and predictable.
>
> If people are so irrational they can't deal with that simple of a policy,
> NEXT_ABI, LTS, etc. is never going to help them.
>
> If people like to have backported stuff, yes of course we can make trees
> and
> branches for this, they are basically free in Git. But at that point
> community
> people in need of LTS forks of features need to step up to the plate to
> help
> out.
>

Completely agree.

Marc


>
> Matthew.
>


[dpdk-dev] Port 0 Link Down - L2fwd sample application

2016-04-07 Thread Marc Sune
2016-04-07 14:50 GMT+02:00 Vivek Gupta :

> Hi
>
> I have binded eth0 and eth1 with DPDK and then tried to run the l2fwd
> example as below
>
> ./build/l2fwd -c f -n 4 -- -q 8 -p 0x11  but each time I get error
> *
> Checking link status..
> Port 0 Link Down
> Port 1 Link Down
> 
>
> I tried with test-pmd example but same result.Could you please help to up
> the link?
>
> Port status is as below-
> Network devices using DPDK-compatible driver
> 
> :01:00.0 'Ethernet Controller 10-Gigabit X540-AT2' drv=uio_pci_generic
> unused=igb_uio
> :01:00.1 'Ethernet Controller 10-Gigabit X540-AT2' drv=uio_pci_generic
> unused=igb_uio
> :06:00.0 'Ethernet Controller 10-Gigabit X540-AT2' drv=uio_pci_generic
> unused=igb_uio
> :06:00.1 'Ethernet Controller 10-Gigabit X540-AT2' drv=uio_pci_generic
> unused=igb_uio
>
> Network devices using kernel driver
> ===
> :81:00.0 'Ethernet Controller 10-Gigabit X540-AT2' if=eth4 drv=ixgbe
> unused=igb_uio,uio_pci_generic
> :81:00.1 'Ethernet Controller 10-Gigabit X540-AT2' if=eth5 drv=ixgbe
> unused=igb_uio,uio_pci_generic
>
> Other network devices
> =
> 
>
>
> Thanks & Regards
> Vivek Gupta
>

In which commit or version are you?

Marc


>
>
> ::DISCLAIMER::
>
> 
>
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only.
> E-mail transmission is not guaranteed to be secure or error-free as
> information could be intercepted, corrupted,
> lost, destroyed, arrive late or incomplete, or may contain viruses in
> transmission. The e mail and its contents
> (with or without referred errors) shall therefore not attach any liability
> on the originator or HCL or its affiliates.
> Views or opinions, if any, presented in this email are solely those of the
> author and may not necessarily reflect the
> views or opinions of HCL or its affiliates. Any form of reproduction,
> dissemination, copying, disclosure, modification,
> distribution and / or publication of this message without the prior
> written consent of authorized representative of
> HCL is strictly prohibited. If you have received this email in error
> please delete it and notify the sender immediately.
> Before opening any email and/or attachments, please check them for viruses
> and other defects.
>
>
> 
>
>


[dpdk-dev] DPDK namespace

2016-04-07 Thread Marc Sune
2016-04-07 11:33 GMT+02:00 Panu Matilainen :

> On 04/07/2016 12:18 PM, Thomas Monjalon wrote:
>
>> Thank you everyone for the feedbacks.
>>
>> 2016-04-05 15:56, Thomas Monjalon:
>>
>>> The goal of this email is to get some feedback on how important it is
>>> to fix the DPDK namespace.
>>>
>>
>> Everybody agree every symbols must be prefixed. Checking and fixing the
>> namespace consistency will be in the roadmap.
>>
>> It seems most of you agree renaming would be a nice improvement but not
>> so important.
>> The main drawback is the induced backporting pain, even if we have
>> some scripts to convert the patches to the old namespace.
>> Note: the backports can be in DPDK itself or in the applications.
>>
>> If there is enough agreement that we should do something, I suggest to
>>> introduce the "dpdk_" prefix slowly and live with both "rte_" and "dpdk_"
>>> during some time.
>>> We could start using the new prefix for the new APIs (example: crypto)
>>> or when there is a significant API break (example: mempool).
>>>
>>
>> The slow change has been clearly rejected in favor of a complete change
>> in one patch.
>> The timing was also discussed as it could impact the pending patches.
>> So it would be done at the end or the beginning of a release.
>> Marc suggests to do it for 16.04 as the numbering scheme has changed.
>>
>
> Just noting that it cannot be done in 16.04 because the ABI policy
> requires a deprecation cycle of at least one major release for every
> breakage. And we're discussing a total 100% breakage of everything here,
> even if its just a simple rename.


I keep not understanding the ABI policy, and particularly why ABI changes
have to be announced once cycle before _if_ there is already at least one
ABI change proposed. DPDK applications will have to recompile anyway.

This aspect of the policy only slows down DPDK development and it pollutes
the repository with commits announcing ABI changes that are irrelevant
after 2 cycles, as (code) diffs show that already (not mentioning NEXT_ABI
complexity and extra LOCs).

Maintaining LTS releases, and enforcing bug fixing in old LTS first,
upstreaming bugfixes is to me a much better approach to solve backwards
compatibility issues.

But this is probably another discussion.

Marc


>
> - Panu -
>
>
> There is no strong conclusion at this point because we need to decide
>> wether the renaming deserves to be done or never.
>> I suggest to take the inputs from the technical board.
>>
>> Do not hesitate to comment. Thanks
>>
>>
>


[dpdk-dev] [PATCH v14 8/8] ethdev: add 100G link speed

2016-04-01 Thread Marc Sune
From: Thomas Monjalon <thomas.monja...@6wind.com>

The link speed configuration is now done with bitmaps so 100G speed
requires only a new bit flag.
The actual link speed is a number so its size must be increased from
16-bit to 32-bit.

Signed-off-by: Marc Sune 
Signed-off-by: Thomas Monjalon 
Tested-by: Nelio Laranjeiro 
Tested-by: Matej Vido 
---
 app/test-pmd/cmdline.c  | 12 +++-
 doc/guides/nics/szedata2.rst|  6 --
 doc/guides/rel_notes/release_16_04.rst  |  5 +
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  2 +-
 drivers/net/ena/ena_ethdev.c|  3 ++-
 drivers/net/fm10k/fm10k_ethdev.c|  2 +-
 drivers/net/mlx5/mlx5_ethdev.c  |  3 ++-
 drivers/net/nfp/nfp_net.c   |  2 +-
 drivers/net/szedata2/rte_eth_szedata2.c |  9 ++---
 lib/librte_ether/rte_ethdev.c   |  2 ++
 lib/librte_ether/rte_ethdev.h   |  4 +++-
 11 files changed, 26 insertions(+), 24 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 741cac3..c5b9479 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -549,7 +549,7 @@ static void cmd_help_long_parsed(void *parsed_result,
"Detach physical or virtual dev by port_id\n\n"

"port config (port_id|all)"
-   " speed (10|100|1000|1|4|auto)"
+   " speed (10|100|1000|1|4|10|auto)"
" duplex (half|full|auto)\n"
"Set speed and duplex for all ports or port_id\n\n"

@@ -1022,6 +1022,8 @@ parse_and_check_speed_duplex(char *speedstr, char 
*duplexstr, uint32_t *speed)
*speed = ETH_LINK_SPEED_10G;
} else if (!strcmp(speedstr, "4")) {
*speed = ETH_LINK_SPEED_40G;
+   } else if (!strcmp(speedstr, "10")) {
+   *speed = ETH_LINK_SPEED_100G;
} else if (!strcmp(speedstr, "auto")) {
*speed = ETH_LINK_SPEED_AUTONEG;
} else {
@@ -1069,7 +1071,7 @@ cmdline_parse_token_string_t cmd_config_speed_all_item1 =
TOKEN_STRING_INITIALIZER(struct cmd_config_speed_all, item1, "speed");
 cmdline_parse_token_string_t cmd_config_speed_all_value1 =
TOKEN_STRING_INITIALIZER(struct cmd_config_speed_all, value1,
-   "10#100#1000#1#4#auto");
+   
"10#100#1000#1#4#10#auto");
 cmdline_parse_token_string_t cmd_config_speed_all_item2 =
TOKEN_STRING_INITIALIZER(struct cmd_config_speed_all, item2, "duplex");
 cmdline_parse_token_string_t cmd_config_speed_all_value2 =
@@ -1079,7 +1081,7 @@ cmdline_parse_token_string_t cmd_config_speed_all_value2 =
 cmdline_parse_inst_t cmd_config_speed_all = {
.f = cmd_config_speed_all_parsed,
.data = NULL,
-   .help_str = "port config all speed 10|100|1000|1|4|auto duplex "
+   .help_str = "port config all speed 10|100|1000|1|4|10|auto 
duplex "
"half|full|auto",
.tokens = {
(void *)_config_speed_all_port,
@@ -1143,7 +1145,7 @@ cmdline_parse_token_string_t 
cmd_config_speed_specific_item1 =
"speed");
 cmdline_parse_token_string_t cmd_config_speed_specific_value1 =
TOKEN_STRING_INITIALIZER(struct cmd_config_speed_specific, value1,
-   "10#100#1000#1#4#auto");
+   
"10#100#1000#1#4#10#auto");
 cmdline_parse_token_string_t cmd_config_speed_specific_item2 =
TOKEN_STRING_INITIALIZER(struct cmd_config_speed_specific, item2,
"duplex");
@@ -1154,7 +1156,7 @@ cmdline_parse_token_string_t 
cmd_config_speed_specific_value2 =
 cmdline_parse_inst_t cmd_config_speed_specific = {
.f = cmd_config_speed_specific_parsed,
.data = NULL,
-   .help_str = "port config X speed 10|100|1000|1|4|auto duplex "
+   .help_str = "port config X speed 10|100|1000|1|4|10|auto 
duplex "
"half|full|auto",
.tokens = {
(void *)_config_speed_specific_port,
diff --git a/doc/guides/nics/szedata2.rst b/doc/guides/nics/szedata2.rst
index 77c15b3..741b400 100644
--- a/doc/guides/nics/szedata2.rst
+++ b/doc/guides/nics/szedata2.rst
@@ -148,9 +148,3 @@ Example output:
  TX threshold registers: 

[dpdk-dev] [PATCH v14 7/8] ethdev: convert speed number to bitmap flag

2016-04-01 Thread Marc Sune
It is a helper for the bitmap configuration.

Signed-off-by: Marc Sune 
Signed-off-by: Thomas Monjalon 
---
 lib/librte_ether/rte_ethdev.c  | 31 +++
 lib/librte_ether/rte_ethdev.h  | 13 +
 lib/librte_ether/rte_ether_version.map |  1 +
 3 files changed, 45 insertions(+)

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 76a30fd..695b475 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -866,6 +866,37 @@ rte_eth_dev_tx_queue_config(struct rte_eth_dev *dev, 
uint16_t nb_queues)
return 0;
 }

+uint32_t
+rte_eth_speed_bitflag(uint32_t speed, int duplex)
+{
+   switch (speed) {
+   case ETH_SPEED_NUM_10M:
+   return duplex ? ETH_LINK_SPEED_10M : ETH_LINK_SPEED_10M_HD;
+   case ETH_SPEED_NUM_100M:
+   return duplex ? ETH_LINK_SPEED_100M : ETH_LINK_SPEED_100M_HD;
+   case ETH_SPEED_NUM_1G:
+   return ETH_LINK_SPEED_1G;
+   case ETH_SPEED_NUM_2_5G:
+   return ETH_LINK_SPEED_2_5G;
+   case ETH_SPEED_NUM_5G:
+   return ETH_LINK_SPEED_5G;
+   case ETH_SPEED_NUM_10G:
+   return ETH_LINK_SPEED_10G;
+   case ETH_SPEED_NUM_20G:
+   return ETH_LINK_SPEED_20G;
+   case ETH_SPEED_NUM_25G:
+   return ETH_LINK_SPEED_25G;
+   case ETH_SPEED_NUM_40G:
+   return ETH_LINK_SPEED_40G;
+   case ETH_SPEED_NUM_50G:
+   return ETH_LINK_SPEED_50G;
+   case ETH_SPEED_NUM_56G:
+   return ETH_LINK_SPEED_56G;
+   default:
+   return 0;
+   }
+}
+
 int
 rte_eth_dev_configure(uint8_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
  const struct rte_eth_conf *dev_conf)
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index b88300d..1342b3a 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -1878,6 +1878,19 @@ struct eth_driver {
 void rte_eth_driver_register(struct eth_driver *eth_drv);

 /**
+ * Convert a numerical speed in Mbps to a bitmap flag that can be used in
+ * the bitmap link_speeds of the struct rte_eth_conf
+ *
+ * @param speed
+ *   Numerical speed value in Mbps
+ * @param duplex
+ *   ETH_LINK_[HALF/FULL]_DUPLEX (only for 10/100M speeds)
+ * @return
+ *   0 if the speed cannot be mapped
+ */
+uint32_t rte_eth_speed_bitflag(uint32_t speed, int duplex);
+
+/**
  * Configure an Ethernet device.
  * This function must be invoked first before any other function in the
  * Ethernet API. This function can also be re-invoked when a device is in the
diff --git a/lib/librte_ether/rte_ether_version.map 
b/lib/librte_ether/rte_ether_version.map
index b1f4475..214ecc7 100644
--- a/lib/librte_ether/rte_ether_version.map
+++ b/lib/librte_ether/rte_ether_version.map
@@ -125,6 +125,7 @@ DPDK_16.04 {
rte_eth_dev_set_vlan_ether_type;
rte_eth_dev_udp_tunnel_port_add;
rte_eth_dev_udp_tunnel_port_delete;
+   rte_eth_speed_bitflag;
rte_eth_tx_buffer_count_callback;
rte_eth_tx_buffer_drop_callback;
rte_eth_tx_buffer_init;
-- 
2.1.4



[dpdk-dev] [PATCH v14 6/8] ethdev: redesign link speed config

2016-04-01 Thread Marc Sune
This patch redesigns the API to set the link speed/s configuration
of an ethernet port. Specifically:

- it allows to define a set of advertised speeds for
  auto-negociation.
- it allows to disable link auto-negociation (single fixed speed).
- default: auto-negociate all supported speeds.

A flag autoneg in struct rte_eth_link indicates if link speed was a
result of auto-negociation or was fixed by configuration.

Signed-off-by: Marc Sune 
Tested-by: Nelio Laranjeiro 
Signed-off-by: Thomas Monjalon 
---
 app/test-pmd/cmdline.c|  26 
 doc/guides/rel_notes/deprecation.rst  |   3 -
 doc/guides/rel_notes/release_16_04.rst|   9 +++
 drivers/net/af_packet/rte_eth_af_packet.c |   1 +
 drivers/net/bnx2x/bnx2x_ethdev.c  |   4 +-
 drivers/net/bonding/rte_eth_bond_8023ad.c |   2 +-
 drivers/net/e1000/em_ethdev.c | 103 +++---
 drivers/net/e1000/igb_ethdev.c|  95 ++-
 drivers/net/i40e/i40e_ethdev.c|  48 +++---
 drivers/net/i40e/i40e_ethdev_vf.c |   7 +-
 drivers/net/ixgbe/ixgbe_ethdev.c  |  53 ---
 drivers/net/mlx4/mlx4.c   |   2 +
 drivers/net/mlx5/mlx5_ethdev.c|   2 +
 drivers/net/mpipe/mpipe_tilegx.c  |   2 +
 drivers/net/null/rte_eth_null.c   |   1 +
 drivers/net/pcap/rte_eth_pcap.c   |   1 +
 drivers/net/ring/rte_eth_ring.c   |   1 +
 drivers/net/szedata2/rte_eth_szedata2.c   |   2 +
 drivers/net/vmxnet3/vmxnet3_ethdev.c  |   1 +
 drivers/net/xenvirt/rte_eth_xenvirt.c |   1 +
 examples/ip_pipeline/config_parse.c   |   3 +-
 lib/librte_ether/rte_ethdev.h |  31 +
 22 files changed, 213 insertions(+), 185 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 815b53b..741cac3 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -989,7 +989,7 @@ struct cmd_config_speed_all {
 };

 static int
-parse_and_check_speed_duplex(char *speedstr, char *duplexstr, uint16_t *speed)
+parse_and_check_speed_duplex(char *speedstr, char *duplexstr, uint32_t *speed)
 {

int duplex;
@@ -1006,20 +1006,22 @@ parse_and_check_speed_duplex(char *speedstr, char 
*duplexstr, uint16_t *speed)
}

if (!strcmp(speedstr, "10")) {
-   *speed = ETH_SPEED_NUM_10M;
+   *speed = (duplex == ETH_LINK_HALF_DUPLEX) ?
+   ETH_LINK_SPEED_10M_HD : ETH_LINK_SPEED_10M;
} else if (!strcmp(speedstr, "100")) {
-   *speed = ETH_SPEED_NUM_100M;
+   *speed = (duplex == ETH_LINK_HALF_DUPLEX) ?
+   ETH_LINK_SPEED_100M_HD : ETH_LINK_SPEED_100M;
} else {
if (duplex != ETH_LINK_FULL_DUPLEX) {
printf("Invalid speed/duplex parameters\n");
return -1;
}
if (!strcmp(speedstr, "1000")) {
-   *speed = ETH_SPEED_NUM_1G;
+   *speed = ETH_LINK_SPEED_1G;
} else if (!strcmp(speedstr, "1")) {
-   *speed = ETH_SPEED_NUM_10G;
+   *speed = ETH_LINK_SPEED_10G;
} else if (!strcmp(speedstr, "4")) {
-   *speed = ETH_SPEED_NUM_40G;
+   *speed = ETH_LINK_SPEED_40G;
} else if (!strcmp(speedstr, "auto")) {
*speed = ETH_LINK_SPEED_AUTONEG;
} else {
@@ -1037,8 +1039,7 @@ cmd_config_speed_all_parsed(void *parsed_result,
__attribute__((unused)) void *data)
 {
struct cmd_config_speed_all *res = parsed_result;
-   uint16_t link_speed = ETH_LINK_SPEED_AUTONEG;
-   uint16_t link_duplex = 0;
+   uint32_t link_speed;
portid_t pid;

if (!all_ports_stopped()) {
@@ -1051,8 +1052,7 @@ cmd_config_speed_all_parsed(void *parsed_result,
return;

FOREACH_PORT(pid, ports) {
-   ports[pid].dev_conf.link_speed = link_speed;
-   ports[pid].dev_conf.link_duplex = link_duplex;
+   ports[pid].dev_conf.link_speeds = link_speed;
}

cmd_reconfig_device_queue(RTE_PORT_ALL, 1, 1);
@@ -1110,8 +1110,7 @@ cmd_config_speed_specific_parsed(void *parsed_result,
__attribute__((unused)) void *data)
 {
struct cmd_config_speed_specific *res = parsed_result;
-   uint16_t link_speed = ETH_LINK_SPEED_AUTONEG;
-   uint16_t link_duplex = 0;
+   uint32_t link_speed;

if (!all_ports_stopped()) {
printf("Please stop all ports first\n");
@@ -1125,8 +1124,7 @@ cmd_config_speed_specific_parsed(void *parsed_result,
_speed) < 0)
return;

-   ports[res->id].dev_c

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

2016-04-01 Thread Marc Sune
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;
break;
-   case ETH_LINK_SPEED_10:
+   case ETH_SPEED_NUM_10M:
key_speed = BOND_LINK_SPEED_KEY_10M;
break;
-   case ETH_LINK_SPEED_100:
+   case ETH_SPEED_NUM_100M:
key_speed = BOND_LINK_SPEED_KEY_100M;
break;
-   case ETH_LINK_SPEED_1000:
+   case ETH_SPEED_NUM_1G:
key_speed = BOND_LINK_SPEED_KEY_1000M;
break;
-   case ETH_LINK_SPEED_10G:
+   case ETH_SPEED_NUM_10G:
key_speed = BOND_LINK_SPEED_KEY_10G;
break;
-   case ETH_LINK_SPEED_20G:
+   case ETH_SPEED

[dpdk-dev] [PATCH v14 3/8] app/testpmd: move speed and duplex parsing in a function

2016-04-01 Thread Marc Sune
The code for checking and parsing speed/duplex was duplicated.
The new function is also checking the speed/duplex combination.

Signed-off-by: Marc Sune 
---
 app/test-pmd/cmdline.c | 99 --
 1 file changed, 47 insertions(+), 52 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 93203f4..eb7bbb4 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -988,6 +988,49 @@ struct cmd_config_speed_all {
cmdline_fixed_string_t value2;
 };

+static int
+parse_and_check_speed_duplex(char *speedstr, char *duplexstr, uint16_t *speed)
+{
+
+   int duplex;
+
+   if (!strcmp(duplexstr, "half")) {
+   duplex = ETH_LINK_HALF_DUPLEX;
+   } else if (!strcmp(duplexstr, "full")) {
+   duplex = ETH_LINK_FULL_DUPLEX;
+   } else if (!strcmp(duplexstr, "auto")) {
+   duplex = ETH_LINK_FULL_DUPLEX;
+   } else {
+   printf("Unknown duplex parameter\n");
+   return -1;
+   }
+
+   if (!strcmp(speedstr, "10")) {
+   *speed = ETH_LINK_SPEED_10;
+   } else if (!strcmp(speedstr, "100")) {
+   *speed = ETH_LINK_SPEED_100;
+   } else {
+   if (duplex != ETH_LINK_FULL_DUPLEX) {
+   printf("Invalid speed/duplex parameters\n");
+   return -1;
+   }
+   if (!strcmp(speedstr, "1000")) {
+   *speed = ETH_LINK_SPEED_1000;
+   } else if (!strcmp(speedstr, "1")) {
+   *speed = ETH_LINK_SPEED_10G;
+   } else if (!strcmp(speedstr, "4")) {
+   *speed = ETH_LINK_SPEED_40G;
+   } else if (!strcmp(speedstr, "auto")) {
+   *speed = ETH_LINK_SPEED_AUTONEG;
+   } else {
+   printf("Unknown speed parameter\n");
+   return -1;
+   }
+   }
+
+   return 0;
+}
+
 static void
 cmd_config_speed_all_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1003,33 +1046,9 @@ cmd_config_speed_all_parsed(void *parsed_result,
return;
}

-   if (!strcmp(res->value1, "10"))
-   link_speed = ETH_LINK_SPEED_10;
-   else if (!strcmp(res->value1, "100"))
-   link_speed = ETH_LINK_SPEED_100;
-   else if (!strcmp(res->value1, "1000"))
-   link_speed = ETH_LINK_SPEED_1000;
-   else if (!strcmp(res->value1, "1"))
-   link_speed = ETH_LINK_SPEED_10G;
-   else if (!strcmp(res->value1, "4"))
-   link_speed = ETH_LINK_SPEED_40G;
-   else if (!strcmp(res->value1, "auto"))
-   link_speed = ETH_LINK_SPEED_AUTONEG;
-   else {
-   printf("Unknown parameter\n");
+   if (parse_and_check_speed_duplex(res->value1, res->value2,
+   _speed) < 0)
return;
-   }
-
-   if (!strcmp(res->value2, "half"))
-   link_duplex = ETH_LINK_HALF_DUPLEX;
-   else if (!strcmp(res->value2, "full"))
-   link_duplex = ETH_LINK_FULL_DUPLEX;
-   else if (!strcmp(res->value2, "auto"))
-   link_duplex = ETH_LINK_AUTONEG_DUPLEX;
-   else {
-   printf("Unknown parameter\n");
-   return;
-   }

FOREACH_PORT(pid, ports) {
ports[pid].dev_conf.link_speed = link_speed;
@@ -1102,33 +1121,9 @@ cmd_config_speed_specific_parsed(void *parsed_result,
if (port_id_is_invalid(res->id, ENABLED_WARN))
return;

-   if (!strcmp(res->value1, "10"))
-   link_speed = ETH_LINK_SPEED_10;
-   else if (!strcmp(res->value1, "100"))
-   link_speed = ETH_LINK_SPEED_100;
-   else if (!strcmp(res->value1, "1000"))
-   link_speed = ETH_LINK_SPEED_1000;
-   else if (!strcmp(res->value1, "1"))
-   link_speed = ETH_LINK_SPEED_1;
-   else if (!strcmp(res->value1, "4"))
-   link_speed = ETH_LINK_SPEED_40G;
-   else if (!strcmp(res->value1, "auto"))
-   link_speed = ETH_LINK_SPEED_AUTONEG;
-   else {
-   printf("Unknown parameter\n");
-   return;
-   }
-
-   if (!strcmp(res->value2, "half"))
-   link_duplex = ETH_LINK_HALF_DUPLEX;
-   else if (!strcmp(res->value2, "full"))
-   link_duplex = ETH_LINK_FULL_DUPLEX;
-   else if (!strcmp(res->value2, "auto"))
-   link_duplex = ETH_LINK_AUTONEG_DUPLEX;
-   else {
-   printf("Unknown parameter\n");
+   if (parse_and_check_speed_duplex(res->value1, res->value2,
+   _speed) < 0)
return;
-   }

ports[res->id].dev_conf.link_speed = link_speed;
ports[res->id].dev_conf.link_duplex = link_duplex;
-- 
2.1.4



[dpdk-dev] [PATCH v14 2/8] ethdev: use constants for link duplex

2016-04-01 Thread Marc Sune
Some duplex values are replaced from 0 to half-duplex when link is down.

Some drivers are still using their own constants for duplex modes.

Signed-off-by: Marc Sune 
---
 drivers/net/e1000/em_ethdev.c  | 2 +-
 drivers/net/e1000/igb_ethdev.c | 2 +-
 drivers/net/ixgbe/ixgbe_ethdev.c   | 2 +-
 drivers/net/virtio/virtio_ethdev.c | 2 +-
 drivers/net/virtio/virtio_ethdev.h | 2 --
 lib/librte_ether/rte_ethdev.h  | 2 +-
 6 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index 9c50674..b78ac04 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -1108,7 +1108,7 @@ eth_em_link_update(struct rte_eth_dev *dev, int 
wait_to_complete)
link.link_status = ETH_LINK_UP;
} else if (!link_check && (link.link_status == ETH_LINK_UP)) {
link.link_speed = 0;
-   link.link_duplex = 0;
+   link.link_duplex = ETH_LINK_HALF_DUPLEX;
link.link_status = ETH_LINK_DOWN;
}
rte_em_dev_atomic_write_link_status(dev, );
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index 045fc63..4dfa7e3 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -2062,7 +2062,7 @@ eth_igb_link_update(struct rte_eth_dev *dev, int 
wait_to_complete)
link.link_status = ETH_LINK_UP;
} else if (!link_check) {
link.link_speed = 0;
-   link.link_duplex = 0;
+   link.link_duplex = ETH_LINK_HALF_DUPLEX;
link.link_status = ETH_LINK_DOWN;
}
rte_igb_dev_atomic_write_link_status(dev, );
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 8bcd0d8..5721882 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -3066,7 +3066,7 @@ ixgbe_dev_link_update(struct rte_eth_dev *dev, int 
wait_to_complete)

link.link_status = ETH_LINK_DOWN;
link.link_speed = 0;
-   link.link_duplex = 0;
+   link.link_duplex = ETH_LINK_HALF_DUPLEX;
memset(, 0, sizeof(old));
rte_ixgbe_dev_atomic_read_link_status(dev, );

diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c
index 3ebc221..63a368a 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -1401,7 +1401,7 @@ virtio_dev_link_update(struct rte_eth_dev *dev, 
__rte_unused int wait_to_complet
memset(, 0, sizeof(link));
virtio_dev_atomic_read_link_status(dev, );
old = link;
-   link.link_duplex = FULL_DUPLEX;
+   link.link_duplex = ETH_LINK_FULL_DUPLEX;
link.link_speed  = SPEED_10G;

if (vtpci_with_feature(hw, VIRTIO_NET_F_STATUS)) {
diff --git a/drivers/net/virtio/virtio_ethdev.h 
b/drivers/net/virtio/virtio_ethdev.h
index fed9571..66423a0 100644
--- a/drivers/net/virtio/virtio_ethdev.h
+++ b/drivers/net/virtio/virtio_ethdev.h
@@ -42,8 +42,6 @@
 #define SPEED_100  100
 #define SPEED_1000 1000
 #define SPEED_10G  1
-#define HALF_DUPLEX1
-#define FULL_DUPLEX2

 #ifndef PAGE_SIZE
 #define PAGE_SIZE 4096
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index c5a215a..2d13f92 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -246,7 +246,7 @@ struct rte_eth_stats {
  */
 struct rte_eth_link {
uint16_t link_speed;  /**< ETH_LINK_SPEED_[10, 100, 1000, 1] */
-   uint16_t link_duplex; /**< ETH_LINK_[HALF_DUPLEX, FULL_DUPLEX] */
+   uint16_t link_duplex; /**< ETH_LINK_[HALF/FULL]_DUPLEX */
uint8_t  link_status : 1; /**< ETH_LINK_[DOWN/UP] */
 }__attribute__((aligned(8))); /**< aligned for atomic64 read/write */

-- 
2.1.4



[dpdk-dev] [PATCH v14 1/8] ethdev: use constants for link state

2016-04-01 Thread Marc Sune
From: Thomas Monjalon <thomas.monja...@6wind.com>

Define and use ETH_LINK_UP and ETH_LINK_DOWN where appropriate.

Signed-off-by: Marc Sune 
Signed-off-by: Thomas Monjalon 
---
 app/test-pipeline/init.c |  2 +-
 app/test-pmd/testpmd.c   |  2 +-
 app/test/test_pmd_perf.c |  2 +-
 app/test/virtual_pmd.c   |  6 +++---
 drivers/net/af_packet/rte_eth_af_packet.c|  6 +++---
 drivers/net/bnx2x/bnx2x_ethdev.c |  2 +-
 drivers/net/bnx2x/elink.c|  2 +-
 drivers/net/bonding/rte_eth_bond_api.c   |  4 ++--
 drivers/net/bonding/rte_eth_bond_pmd.c   | 12 ++--
 drivers/net/e1000/em_ethdev.c|  8 
 drivers/net/e1000/igb_ethdev.c   |  4 ++--
 drivers/net/fm10k/fm10k_ethdev.c |  2 +-
 drivers/net/i40e/i40e_ethdev_vf.c|  2 +-
 drivers/net/ixgbe/ixgbe_ethdev.c |  4 ++--
 drivers/net/mpipe/mpipe_tilegx.c | 12 ++--
 drivers/net/nfp/nfp_net.c|  2 +-
 drivers/net/null/rte_eth_null.c  |  6 +++---
 drivers/net/pcap/rte_eth_pcap.c  |  6 +++---
 drivers/net/ring/rte_eth_ring.c  | 10 +-
 drivers/net/szedata2/rte_eth_szedata2.c  |  2 +-
 drivers/net/vhost/rte_eth_vhost.c|  6 +++---
 drivers/net/virtio/virtio_ethdev.c   |  6 +++---
 drivers/net/vmxnet3/vmxnet3_ethdev.c |  2 +-
 drivers/net/xenvirt/rte_eth_xenvirt.c|  6 +++---
 examples/exception_path/main.c   |  2 +-
 examples/ip_fragmentation/main.c |  2 +-
 examples/ip_pipeline/init.c  |  2 +-
 examples/ip_reassembly/main.c|  2 +-
 examples/ipsec-secgw/ipsec-secgw.c   |  2 +-
 examples/ipv4_multicast/main.c   |  2 +-
 examples/kni/main.c  |  2 +-
 examples/l2fwd-crypto/main.c |  2 +-
 examples/l2fwd-ivshmem/host/host.c   |  2 +-
 examples/l2fwd-jobstats/main.c   |  2 +-
 examples/l2fwd-keepalive/main.c  |  2 +-
 examples/l2fwd/main.c|  2 +-
 examples/l3fwd-acl/main.c|  2 +-
 examples/l3fwd-power/main.c  |  2 +-
 examples/l3fwd/main.c|  2 +-
 examples/link_status_interrupt/main.c|  2 +-
 examples/load_balancer/init.c|  2 +-
 examples/multi_process/client_server_mp/mp_server/init.c |  2 +-
 examples/multi_process/l2fwd_fork/main.c |  2 +-
 examples/multi_process/symmetric_mp/main.c   |  2 +-
 examples/performance-thread/l3fwd-thread/main.c  |  2 +-
 lib/librte_ether/rte_ethdev.h|  5 -
 46 files changed, 83 insertions(+), 80 deletions(-)

diff --git a/app/test-pipeline/init.c b/app/test-pipeline/init.c
index db2196b..aef082f 100644
--- a/app/test-pipeline/init.c
+++ b/app/test-pipeline/init.c
@@ -205,7 +205,7 @@ app_ports_check_link(void)
link.link_speed / 1000,
link.link_status ? "UP" : "DOWN");

-   if (link.link_status == 0)
+   if (link.link_status == ETH_LINK_DOWN)
all_ports_up = 0;
}

diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 8605e62..1398c6c 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -1641,7 +1641,7 @@ check_all_ports_link_status(uint32_t port_mask)
continue;
}
/* clear all_ports_up flag if any link down */
-   if (link.link_status == 0) {
+   if (link.link_status == ETH_LINK_DOWN) {
all_ports_up = 0;
break;
}
diff --git a/app/test/test_pmd_perf.c b/app/test/test_pmd_perf.c
index 48e16c9..59803f7 100644
--- a/app/test/test_pmd_perf.c
+++ b/app/test/test_pmd_perf.c
@@ -192,7 +192,7 @@ check_all_ports_link_status(uint8_t port_num, uint32_t 
port_mask)
continue;
}
/* clear all_ports_up flag if any link down */
-   if (link.link_status == 0) {
+   if (link.link_status == ETH_LINK_DOWN) {
all_ports_up = 0;
   

[dpdk-dev] [PATCH v14 0/8] ethdev: 100G and link speed API refactoring

2016-04-01 Thread Marc Sune
From: Marc Sune <m...@voltanet.io>

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).

v14:
- Rebase to master HEAD
- Add ETH_LINK_FIXED / ETH_LINK_AUTONEG MACROs in rte_ethdev.h
- Fix NFP speed capability (50G -> 40G)
- Fix ixgbe full AUTONEG

v13:
- Fix startup regression; revert flip of ETH_LINK_SPEED_FIXED and
  ETH_LINK_SPEED_AUTONEG values. ETH_LINK_SPEED_AUTONEG is now 0.
- Fix incorrect duplex link reporting for e1000.
- Do not allow more than one speed in the bitmap when
  ETH_LINK_SPEED_FIXED is used for e1000.

v12:
- rebase on 16.04-rc2
- fix mlx capabilities
- update ENA driver

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).
*** BLURB HERE ***

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/deprecation.rst   |   3 -
 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  | 117 +--
 drivers/net/e1000/igb_ethdev.c | 105 +
 drivers/net/ena/ena_ethdev.c

[dpdk-dev] e1000: randomly loosing link change events triggered by the peer

2016-03-26 Thread Marc Sune
I found that in the current HEAD in master testing it with an I218-LM in
autoneg mode, when link is forced to be renegociated by the peer (e.g. via
ethtool on a peer Linux box) _some_ change events are lost.

It is quite random, but it seems to happen more while changing the speed
than when changing the duplex mode.

However, when one or more link change events have been lost and the phy
medium is disconnected and reconnected, the link speed and duplex mode are
then correctly updated.

Marc


[dpdk-dev] [PATCH v13 8/8] ethdev: add 100G link speed

2016-03-26 Thread Marc Sune
From: Thomas Monjalon <thomas.monja...@6wind.com>

The link speed configuration is now done with bitmaps so 100G speed
requires only a new bit flag.
The actual link speed is a number so its size must be increased from
16-bit to 32-bit.

Signed-off-by: Marc Sune 
Signed-off-by: Thomas Monjalon 
Tested-by: Nelio Laranjeiro 
Tested-by: Matej Vido 
---
 app/test-pmd/cmdline.c  | 12 +++-
 doc/guides/nics/szedata2.rst|  6 --
 doc/guides/rel_notes/release_16_04.rst  |  5 +
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  2 +-
 drivers/net/ena/ena_ethdev.c|  3 ++-
 drivers/net/fm10k/fm10k_ethdev.c|  2 +-
 drivers/net/mlx5/mlx5_ethdev.c  |  3 ++-
 drivers/net/nfp/nfp_net.c   |  2 +-
 drivers/net/szedata2/rte_eth_szedata2.c |  9 ++---
 lib/librte_ether/rte_ethdev.c   |  2 ++
 lib/librte_ether/rte_ethdev.h   |  4 +++-
 11 files changed, 26 insertions(+), 24 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 741cac3..c5b9479 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -549,7 +549,7 @@ static void cmd_help_long_parsed(void *parsed_result,
"Detach physical or virtual dev by port_id\n\n"

"port config (port_id|all)"
-   " speed (10|100|1000|1|4|auto)"
+   " speed (10|100|1000|1|4|10|auto)"
" duplex (half|full|auto)\n"
"Set speed and duplex for all ports or port_id\n\n"

@@ -1022,6 +1022,8 @@ parse_and_check_speed_duplex(char *speedstr, char 
*duplexstr, uint32_t *speed)
*speed = ETH_LINK_SPEED_10G;
} else if (!strcmp(speedstr, "4")) {
*speed = ETH_LINK_SPEED_40G;
+   } else if (!strcmp(speedstr, "10")) {
+   *speed = ETH_LINK_SPEED_100G;
} else if (!strcmp(speedstr, "auto")) {
*speed = ETH_LINK_SPEED_AUTONEG;
} else {
@@ -1069,7 +1071,7 @@ cmdline_parse_token_string_t cmd_config_speed_all_item1 =
TOKEN_STRING_INITIALIZER(struct cmd_config_speed_all, item1, "speed");
 cmdline_parse_token_string_t cmd_config_speed_all_value1 =
TOKEN_STRING_INITIALIZER(struct cmd_config_speed_all, value1,
-   "10#100#1000#1#4#auto");
+   
"10#100#1000#1#4#10#auto");
 cmdline_parse_token_string_t cmd_config_speed_all_item2 =
TOKEN_STRING_INITIALIZER(struct cmd_config_speed_all, item2, "duplex");
 cmdline_parse_token_string_t cmd_config_speed_all_value2 =
@@ -1079,7 +1081,7 @@ cmdline_parse_token_string_t cmd_config_speed_all_value2 =
 cmdline_parse_inst_t cmd_config_speed_all = {
.f = cmd_config_speed_all_parsed,
.data = NULL,
-   .help_str = "port config all speed 10|100|1000|1|4|auto duplex "
+   .help_str = "port config all speed 10|100|1000|1|4|10|auto 
duplex "
"half|full|auto",
.tokens = {
(void *)_config_speed_all_port,
@@ -1143,7 +1145,7 @@ cmdline_parse_token_string_t 
cmd_config_speed_specific_item1 =
"speed");
 cmdline_parse_token_string_t cmd_config_speed_specific_value1 =
TOKEN_STRING_INITIALIZER(struct cmd_config_speed_specific, value1,
-   "10#100#1000#1#4#auto");
+   
"10#100#1000#1#4#10#auto");
 cmdline_parse_token_string_t cmd_config_speed_specific_item2 =
TOKEN_STRING_INITIALIZER(struct cmd_config_speed_specific, item2,
"duplex");
@@ -1154,7 +1156,7 @@ cmdline_parse_token_string_t 
cmd_config_speed_specific_value2 =
 cmdline_parse_inst_t cmd_config_speed_specific = {
.f = cmd_config_speed_specific_parsed,
.data = NULL,
-   .help_str = "port config X speed 10|100|1000|1|4|auto duplex "
+   .help_str = "port config X speed 10|100|1000|1|4|10|auto 
duplex "
"half|full|auto",
.tokens = {
(void *)_config_speed_specific_port,
diff --git a/doc/guides/nics/szedata2.rst b/doc/guides/nics/szedata2.rst
index 77c15b3..741b400 100644
--- a/doc/guides/nics/szedata2.rst
+++ b/doc/guides/nics/szedata2.rst
@@ -148,9 +148,3 @@ Example output:
  TX threshold registers: 

[dpdk-dev] [PATCH v13 7/8] ethdev: convert speed number to bitmap flag

2016-03-26 Thread Marc Sune
It is a helper for the bitmap configuration.

Signed-off-by: Marc Sune 
Signed-off-by: Thomas Monjalon 
---
 lib/librte_ether/rte_ethdev.c  | 31 +++
 lib/librte_ether/rte_ethdev.h  | 13 +
 lib/librte_ether/rte_ether_version.map |  1 +
 3 files changed, 45 insertions(+)

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 76a30fd..695b475 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -866,6 +866,37 @@ rte_eth_dev_tx_queue_config(struct rte_eth_dev *dev, 
uint16_t nb_queues)
return 0;
 }

+uint32_t
+rte_eth_speed_bitflag(uint32_t speed, int duplex)
+{
+   switch (speed) {
+   case ETH_SPEED_NUM_10M:
+   return duplex ? ETH_LINK_SPEED_10M : ETH_LINK_SPEED_10M_HD;
+   case ETH_SPEED_NUM_100M:
+   return duplex ? ETH_LINK_SPEED_100M : ETH_LINK_SPEED_100M_HD;
+   case ETH_SPEED_NUM_1G:
+   return ETH_LINK_SPEED_1G;
+   case ETH_SPEED_NUM_2_5G:
+   return ETH_LINK_SPEED_2_5G;
+   case ETH_SPEED_NUM_5G:
+   return ETH_LINK_SPEED_5G;
+   case ETH_SPEED_NUM_10G:
+   return ETH_LINK_SPEED_10G;
+   case ETH_SPEED_NUM_20G:
+   return ETH_LINK_SPEED_20G;
+   case ETH_SPEED_NUM_25G:
+   return ETH_LINK_SPEED_25G;
+   case ETH_SPEED_NUM_40G:
+   return ETH_LINK_SPEED_40G;
+   case ETH_SPEED_NUM_50G:
+   return ETH_LINK_SPEED_50G;
+   case ETH_SPEED_NUM_56G:
+   return ETH_LINK_SPEED_56G;
+   default:
+   return 0;
+   }
+}
+
 int
 rte_eth_dev_configure(uint8_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
  const struct rte_eth_conf *dev_conf)
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 9a1466b..0b436d9 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -1876,6 +1876,19 @@ struct eth_driver {
 void rte_eth_driver_register(struct eth_driver *eth_drv);

 /**
+ * Convert a numerical speed in Mbps to a bitmap flag that can be used in
+ * the bitmap link_speeds of the struct rte_eth_conf
+ *
+ * @param speed
+ *   Numerical speed value in Mbps
+ * @param duplex
+ *   ETH_LINK_[HALF/FULL]_DUPLEX (only for 10/100M speeds)
+ * @return
+ *   0 if the speed cannot be mapped
+ */
+uint32_t rte_eth_speed_bitflag(uint32_t speed, int duplex);
+
+/**
  * Configure an Ethernet device.
  * This function must be invoked first before any other function in the
  * Ethernet API. This function can also be re-invoked when a device is in the
diff --git a/lib/librte_ether/rte_ether_version.map 
b/lib/librte_ether/rte_ether_version.map
index b1f4475..214ecc7 100644
--- a/lib/librte_ether/rte_ether_version.map
+++ b/lib/librte_ether/rte_ether_version.map
@@ -125,6 +125,7 @@ DPDK_16.04 {
rte_eth_dev_set_vlan_ether_type;
rte_eth_dev_udp_tunnel_port_add;
rte_eth_dev_udp_tunnel_port_delete;
+   rte_eth_speed_bitflag;
rte_eth_tx_buffer_count_callback;
rte_eth_tx_buffer_drop_callback;
rte_eth_tx_buffer_init;
-- 
2.1.4



[dpdk-dev] [PATCH v13 6/8] ethdev: redesign link speed config

2016-03-26 Thread Marc Sune
This patch redesigns the API to set the link speed/s configuration
of an ethernet port. Specifically:

- it allows to define a set of advertised speeds for
  auto-negociation.
- it allows to disable link auto-negociation (single fixed speed).
- default: auto-negociate all supported speeds.

A flag autoneg in struct rte_eth_link indicates if link speed was a
result of auto-negociation or was fixed by configuration.

Signed-off-by: Marc Sune 
Tested-by: Nelio Laranjeiro 
Signed-off-by: Thomas Monjalon 
---
 app/test-pmd/cmdline.c|  26 
 doc/guides/rel_notes/deprecation.rst  |   3 -
 doc/guides/rel_notes/release_16_04.rst|   9 +++
 drivers/net/af_packet/rte_eth_af_packet.c |   1 +
 drivers/net/bnx2x/bnx2x_ethdev.c  |   4 +-
 drivers/net/bonding/rte_eth_bond_8023ad.c |   2 +-
 drivers/net/e1000/em_ethdev.c | 103 +++---
 drivers/net/e1000/igb_ethdev.c|  95 ++-
 drivers/net/i40e/i40e_ethdev.c|  48 +++---
 drivers/net/i40e/i40e_ethdev_vf.c |   7 +-
 drivers/net/ixgbe/ixgbe_ethdev.c  |  51 ++-
 drivers/net/mlx4/mlx4.c   |   2 +
 drivers/net/mlx5/mlx5_ethdev.c|   2 +
 drivers/net/mpipe/mpipe_tilegx.c  |   2 +
 drivers/net/null/rte_eth_null.c   |   1 +
 drivers/net/pcap/rte_eth_pcap.c   |   1 +
 drivers/net/ring/rte_eth_ring.c   |   1 +
 drivers/net/szedata2/rte_eth_szedata2.c   |   2 +
 drivers/net/vmxnet3/vmxnet3_ethdev.c  |   1 +
 drivers/net/xenvirt/rte_eth_xenvirt.c |   1 +
 examples/ip_pipeline/config_parse.c   |   3 +-
 lib/librte_ether/rte_ethdev.h |  29 +
 22 files changed, 207 insertions(+), 187 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 815b53b..741cac3 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -989,7 +989,7 @@ struct cmd_config_speed_all {
 };

 static int
-parse_and_check_speed_duplex(char *speedstr, char *duplexstr, uint16_t *speed)
+parse_and_check_speed_duplex(char *speedstr, char *duplexstr, uint32_t *speed)
 {

int duplex;
@@ -1006,20 +1006,22 @@ parse_and_check_speed_duplex(char *speedstr, char 
*duplexstr, uint16_t *speed)
}

if (!strcmp(speedstr, "10")) {
-   *speed = ETH_SPEED_NUM_10M;
+   *speed = (duplex == ETH_LINK_HALF_DUPLEX) ?
+   ETH_LINK_SPEED_10M_HD : ETH_LINK_SPEED_10M;
} else if (!strcmp(speedstr, "100")) {
-   *speed = ETH_SPEED_NUM_100M;
+   *speed = (duplex == ETH_LINK_HALF_DUPLEX) ?
+   ETH_LINK_SPEED_100M_HD : ETH_LINK_SPEED_100M;
} else {
if (duplex != ETH_LINK_FULL_DUPLEX) {
printf("Invalid speed/duplex parameters\n");
return -1;
}
if (!strcmp(speedstr, "1000")) {
-   *speed = ETH_SPEED_NUM_1G;
+   *speed = ETH_LINK_SPEED_1G;
} else if (!strcmp(speedstr, "1")) {
-   *speed = ETH_SPEED_NUM_10G;
+   *speed = ETH_LINK_SPEED_10G;
} else if (!strcmp(speedstr, "4")) {
-   *speed = ETH_SPEED_NUM_40G;
+   *speed = ETH_LINK_SPEED_40G;
} else if (!strcmp(speedstr, "auto")) {
*speed = ETH_LINK_SPEED_AUTONEG;
} else {
@@ -1037,8 +1039,7 @@ cmd_config_speed_all_parsed(void *parsed_result,
__attribute__((unused)) void *data)
 {
struct cmd_config_speed_all *res = parsed_result;
-   uint16_t link_speed = ETH_LINK_SPEED_AUTONEG;
-   uint16_t link_duplex = 0;
+   uint32_t link_speed;
portid_t pid;

if (!all_ports_stopped()) {
@@ -1051,8 +1052,7 @@ cmd_config_speed_all_parsed(void *parsed_result,
return;

FOREACH_PORT(pid, ports) {
-   ports[pid].dev_conf.link_speed = link_speed;
-   ports[pid].dev_conf.link_duplex = link_duplex;
+   ports[pid].dev_conf.link_speeds = link_speed;
}

cmd_reconfig_device_queue(RTE_PORT_ALL, 1, 1);
@@ -1110,8 +1110,7 @@ cmd_config_speed_specific_parsed(void *parsed_result,
__attribute__((unused)) void *data)
 {
struct cmd_config_speed_specific *res = parsed_result;
-   uint16_t link_speed = ETH_LINK_SPEED_AUTONEG;
-   uint16_t link_duplex = 0;
+   uint32_t link_speed;

if (!all_ports_stopped()) {
printf("Please stop all ports first\n");
@@ -1125,8 +1124,7 @@ cmd_config_speed_specific_parsed(void *parsed_result,
_speed) < 0)
return;

-   ports[res->id].dev_c

[dpdk-dev] [PATCH v13 5/8] ethdev: add speed capabilities

2016-03-26 Thread Marc Sune
The speed capabilities of a device can be retrieved with
rte_eth_dev_info_get().

The new field speed_capa is initialized in the drivers without
taking care of device characteristics in this patch.
When the capabilities of a driver are accurate, the table in
overview.rst must be filled.

Signed-off-by: Marc Sune 
---
 doc/guides/nics/overview.rst   |  1 +
 doc/guides/rel_notes/release_16_04.rst |  8 
 drivers/net/bnx2x/bnx2x_ethdev.c   |  1 +
 drivers/net/cxgbe/cxgbe_ethdev.c   |  1 +
 drivers/net/e1000/em_ethdev.c  |  4 
 drivers/net/e1000/igb_ethdev.c |  4 
 drivers/net/ena/ena_ethdev.c   |  9 +
 drivers/net/fm10k/fm10k_ethdev.c   |  4 
 drivers/net/i40e/i40e_ethdev.c |  8 
 drivers/net/ixgbe/ixgbe_ethdev.c   |  8 
 drivers/net/mlx4/mlx4.c|  6 ++
 drivers/net/mlx5/mlx5_ethdev.c |  8 
 drivers/net/nfp/nfp_net.c  |  2 ++
 lib/librte_ether/rte_ethdev.h  | 21 +
 14 files changed, 85 insertions(+)

diff --git a/doc/guides/nics/overview.rst b/doc/guides/nics/overview.rst
index 542479a..62f1868 100644
--- a/doc/guides/nics/overview.rst
+++ b/doc/guides/nics/overview.rst
@@ -86,6 +86,7 @@ Most of these differences are summarized below.
   e   e   e   e   e
 e
   c   c   c   c   c
 c
 = = = = = = = = = = = = = = = = = = = = = = = = = = = 
= = = = = =
+   speed capabilities
link status  X   X X   
X X
link status eventX X
 X
queue status event  
 X
diff --git a/doc/guides/rel_notes/release_16_04.rst 
b/doc/guides/rel_notes/release_16_04.rst
index 79d76e1..9e7b0b7 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -47,6 +47,11 @@ This section should contain new features added in this 
release. Sample format:
   A new function ``rte_pktmbuf_alloc_bulk()`` has been added to allow the user
   to allocate a bulk of mbufs.

+* **Added device link speed capabilities.**
+
+  The structure ``rte_eth_dev_info`` has now a ``speed_capa`` bitmap, which
+  allows the application to know the supported speeds of each device.
+
 * **Added new poll-mode driver for Amazon Elastic Network Adapters (ENA).**

   The driver operates variety of ENA adapters through feature negotiation
@@ -456,6 +461,9 @@ This section should contain API changes. Sample format:
   All drivers are now counting the missed packets only once, i.e. drivers will
   not increment ierrors anymore for missed packets.

+* The ethdev structure ``rte_eth_dev_info`` was changed to support device
+  speed capabilities.
+
 * The functions ``rte_eth_dev_udp_tunnel_add`` and 
``rte_eth_dev_udp_tunnel_delete``
   have been renamed into ``rte_eth_dev_udp_tunnel_port_add`` and
   ``rte_eth_dev_udp_tunnel_port_delete``.
diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c b/drivers/net/bnx2x/bnx2x_ethdev.c
index a3c6c01..897081f 100644
--- a/drivers/net/bnx2x/bnx2x_ethdev.c
+++ b/drivers/net/bnx2x/bnx2x_ethdev.c
@@ -327,6 +327,7 @@ bnx2x_dev_infos_get(struct rte_eth_dev *dev, __rte_unused 
struct rte_eth_dev_inf
dev_info->min_rx_bufsize = BNX2X_MIN_RX_BUF_SIZE;
dev_info->max_rx_pktlen  = BNX2X_MAX_RX_PKT_LEN;
dev_info->max_mac_addrs  = BNX2X_MAX_MAC_ADDRS;
+   dev_info->speed_capa = ETH_LINK_SPEED_10G | ETH_LINK_SPEED_20G;
 }

 static void
diff --git a/drivers/net/cxgbe/cxgbe_ethdev.c b/drivers/net/cxgbe/cxgbe_ethdev.c
index 8845c76..bb134e5 100644
--- a/drivers/net/cxgbe/cxgbe_ethdev.c
+++ b/drivers/net/cxgbe/cxgbe_ethdev.c
@@ -171,6 +171,7 @@ static void cxgbe_dev_info_get(struct rte_eth_dev *eth_dev,

device_info->rx_desc_lim = cxgbe_desc_lim;
device_info->tx_desc_lim = cxgbe_desc_lim;
+   device_info->speed_capa = ETH_LINK_SPEED_10G | ETH_LINK_SPEED_40G;
 }

 static void cxgbe_dev_promiscuous_enable(struct rte_eth_dev *eth_dev)
diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index 473d77f..d5f8c7f 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -1054,6 +1054,10 @@ eth_em_infos_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
.nb_min = E1000_MIN_RING_DESC,
.nb_align = EM_TXD_ALIGN,
};
+
+   dev_info->speed_capa = ETH_LINK_SPEED_10M_HD | ETH_LINK_SPEED_10M |
+   ETH_LINK_SPEED_100M_HD | ETH_LINK_SPEED_100M |
+   ETH_LINK_SPEED_1G;
 }

 /* return 0 means link status changed, -1 means not changed */
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index 86f25f6..95d1711 100644

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

2016-03-26 Thread Marc Sune
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;
break;
-   case ETH_LINK_SPEED_10:
+   case ETH_SPEED_NUM_10M:
key_speed = BOND_LINK_SPEED_KEY_10M;
break;
-   case ETH_LINK_SPEED_100:
+   case ETH_SPEED_NUM_100M:
key_speed = BOND_LINK_SPEED_KEY_100M;
break;
-   case ETH_LINK_SPEED_1000:
+   case ETH_SPEED_NUM_1G:
key_speed = BOND_LINK_SPEED_KEY_1000M;
break;
-   case ETH_LINK_SPEED_10G:
+   case ETH_SPEED_NUM_10G:
key_speed = BOND_LINK_SPEED_KEY_10G;
break;
-   case ETH_LINK_SPEED_20G:
+   case ETH_SPEED

[dpdk-dev] [PATCH v13 3/8] app/testpmd: move speed and duplex parsing in a function

2016-03-26 Thread Marc Sune
The code for checking and parsing speed/duplex was duplicated.
The new function is also checking the speed/duplex combination.

Signed-off-by: Marc Sune 
---
 app/test-pmd/cmdline.c | 99 --
 1 file changed, 47 insertions(+), 52 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 93203f4..eb7bbb4 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -988,6 +988,49 @@ struct cmd_config_speed_all {
cmdline_fixed_string_t value2;
 };

+static int
+parse_and_check_speed_duplex(char *speedstr, char *duplexstr, uint16_t *speed)
+{
+
+   int duplex;
+
+   if (!strcmp(duplexstr, "half")) {
+   duplex = ETH_LINK_HALF_DUPLEX;
+   } else if (!strcmp(duplexstr, "full")) {
+   duplex = ETH_LINK_FULL_DUPLEX;
+   } else if (!strcmp(duplexstr, "auto")) {
+   duplex = ETH_LINK_FULL_DUPLEX;
+   } else {
+   printf("Unknown duplex parameter\n");
+   return -1;
+   }
+
+   if (!strcmp(speedstr, "10")) {
+   *speed = ETH_LINK_SPEED_10;
+   } else if (!strcmp(speedstr, "100")) {
+   *speed = ETH_LINK_SPEED_100;
+   } else {
+   if (duplex != ETH_LINK_FULL_DUPLEX) {
+   printf("Invalid speed/duplex parameters\n");
+   return -1;
+   }
+   if (!strcmp(speedstr, "1000")) {
+   *speed = ETH_LINK_SPEED_1000;
+   } else if (!strcmp(speedstr, "1")) {
+   *speed = ETH_LINK_SPEED_10G;
+   } else if (!strcmp(speedstr, "4")) {
+   *speed = ETH_LINK_SPEED_40G;
+   } else if (!strcmp(speedstr, "auto")) {
+   *speed = ETH_LINK_SPEED_AUTONEG;
+   } else {
+   printf("Unknown speed parameter\n");
+   return -1;
+   }
+   }
+
+   return 0;
+}
+
 static void
 cmd_config_speed_all_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1003,33 +1046,9 @@ cmd_config_speed_all_parsed(void *parsed_result,
return;
}

-   if (!strcmp(res->value1, "10"))
-   link_speed = ETH_LINK_SPEED_10;
-   else if (!strcmp(res->value1, "100"))
-   link_speed = ETH_LINK_SPEED_100;
-   else if (!strcmp(res->value1, "1000"))
-   link_speed = ETH_LINK_SPEED_1000;
-   else if (!strcmp(res->value1, "1"))
-   link_speed = ETH_LINK_SPEED_10G;
-   else if (!strcmp(res->value1, "4"))
-   link_speed = ETH_LINK_SPEED_40G;
-   else if (!strcmp(res->value1, "auto"))
-   link_speed = ETH_LINK_SPEED_AUTONEG;
-   else {
-   printf("Unknown parameter\n");
+   if (parse_and_check_speed_duplex(res->value1, res->value2,
+   _speed) < 0)
return;
-   }
-
-   if (!strcmp(res->value2, "half"))
-   link_duplex = ETH_LINK_HALF_DUPLEX;
-   else if (!strcmp(res->value2, "full"))
-   link_duplex = ETH_LINK_FULL_DUPLEX;
-   else if (!strcmp(res->value2, "auto"))
-   link_duplex = ETH_LINK_AUTONEG_DUPLEX;
-   else {
-   printf("Unknown parameter\n");
-   return;
-   }

FOREACH_PORT(pid, ports) {
ports[pid].dev_conf.link_speed = link_speed;
@@ -1102,33 +1121,9 @@ cmd_config_speed_specific_parsed(void *parsed_result,
if (port_id_is_invalid(res->id, ENABLED_WARN))
return;

-   if (!strcmp(res->value1, "10"))
-   link_speed = ETH_LINK_SPEED_10;
-   else if (!strcmp(res->value1, "100"))
-   link_speed = ETH_LINK_SPEED_100;
-   else if (!strcmp(res->value1, "1000"))
-   link_speed = ETH_LINK_SPEED_1000;
-   else if (!strcmp(res->value1, "1"))
-   link_speed = ETH_LINK_SPEED_1;
-   else if (!strcmp(res->value1, "4"))
-   link_speed = ETH_LINK_SPEED_40G;
-   else if (!strcmp(res->value1, "auto"))
-   link_speed = ETH_LINK_SPEED_AUTONEG;
-   else {
-   printf("Unknown parameter\n");
-   return;
-   }
-
-   if (!strcmp(res->value2, "half"))
-   link_duplex = ETH_LINK_HALF_DUPLEX;
-   else if (!strcmp(res->value2, "full"))
-   link_duplex = ETH_LINK_FULL_DUPLEX;
-   else if (!strcmp(res->value2, "auto"))
-   link_duplex = ETH_LINK_AUTONEG_DUPLEX;
-   else {
-   printf("Unknown parameter\n");
+   if (parse_and_check_speed_duplex(res->value1, res->value2,
+   _speed) < 0)
return;
-   }

ports[res->id].dev_conf.link_speed = link_speed;
ports[res->id].dev_conf.link_duplex = link_duplex;
-- 
2.1.4



[dpdk-dev] [PATCH v13 2/8] ethdev: use constants for link duplex

2016-03-26 Thread Marc Sune
Some duplex values are replaced from 0 to half-duplex when link is down.

Some drivers are still using their own constants for duplex modes.

Signed-off-by: Marc Sune 
---
 drivers/net/e1000/em_ethdev.c  | 2 +-
 drivers/net/e1000/igb_ethdev.c | 2 +-
 drivers/net/ixgbe/ixgbe_ethdev.c   | 2 +-
 drivers/net/virtio/virtio_ethdev.c | 2 +-
 drivers/net/virtio/virtio_ethdev.h | 2 --
 lib/librte_ether/rte_ethdev.h  | 2 +-
 6 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index dc9ed38..fad8f2f 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -1107,7 +1107,7 @@ eth_em_link_update(struct rte_eth_dev *dev, int 
wait_to_complete)
link.link_status = ETH_LINK_UP;
} else if (!link_check && (link.link_status == ETH_LINK_UP)) {
link.link_speed = 0;
-   link.link_duplex = 0;
+   link.link_duplex = ETH_LINK_HALF_DUPLEX;
link.link_status = ETH_LINK_DOWN;
}
rte_em_dev_atomic_write_link_status(dev, );
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index 045fc63..4dfa7e3 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -2062,7 +2062,7 @@ eth_igb_link_update(struct rte_eth_dev *dev, int 
wait_to_complete)
link.link_status = ETH_LINK_UP;
} else if (!link_check) {
link.link_speed = 0;
-   link.link_duplex = 0;
+   link.link_duplex = ETH_LINK_HALF_DUPLEX;
link.link_status = ETH_LINK_DOWN;
}
rte_igb_dev_atomic_write_link_status(dev, );
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 129f36a..21a3b8c 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -3061,7 +3061,7 @@ ixgbe_dev_link_update(struct rte_eth_dev *dev, int 
wait_to_complete)

link.link_status = ETH_LINK_DOWN;
link.link_speed = 0;
-   link.link_duplex = 0;
+   link.link_duplex = ETH_LINK_HALF_DUPLEX;
memset(, 0, sizeof(old));
rte_ixgbe_dev_atomic_read_link_status(dev, );

diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c
index 3ebc221..63a368a 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -1401,7 +1401,7 @@ virtio_dev_link_update(struct rte_eth_dev *dev, 
__rte_unused int wait_to_complet
memset(, 0, sizeof(link));
virtio_dev_atomic_read_link_status(dev, );
old = link;
-   link.link_duplex = FULL_DUPLEX;
+   link.link_duplex = ETH_LINK_FULL_DUPLEX;
link.link_speed  = SPEED_10G;

if (vtpci_with_feature(hw, VIRTIO_NET_F_STATUS)) {
diff --git a/drivers/net/virtio/virtio_ethdev.h 
b/drivers/net/virtio/virtio_ethdev.h
index fed9571..66423a0 100644
--- a/drivers/net/virtio/virtio_ethdev.h
+++ b/drivers/net/virtio/virtio_ethdev.h
@@ -42,8 +42,6 @@
 #define SPEED_100  100
 #define SPEED_1000 1000
 #define SPEED_10G  1
-#define HALF_DUPLEX1
-#define FULL_DUPLEX2

 #ifndef PAGE_SIZE
 #define PAGE_SIZE 4096
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index c5a215a..2d13f92 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -246,7 +246,7 @@ struct rte_eth_stats {
  */
 struct rte_eth_link {
uint16_t link_speed;  /**< ETH_LINK_SPEED_[10, 100, 1000, 1] */
-   uint16_t link_duplex; /**< ETH_LINK_[HALF_DUPLEX, FULL_DUPLEX] */
+   uint16_t link_duplex; /**< ETH_LINK_[HALF/FULL]_DUPLEX */
uint8_t  link_status : 1; /**< ETH_LINK_[DOWN/UP] */
 }__attribute__((aligned(8))); /**< aligned for atomic64 read/write */

-- 
2.1.4



[dpdk-dev] [PATCH v13 1/8] ethdev: use constants for link state

2016-03-26 Thread Marc Sune
From: Thomas Monjalon <thomas.monja...@6wind.com>

Define and use ETH_LINK_UP and ETH_LINK_DOWN where appropriate.

Signed-off-by: Marc Sune 
Signed-off-by: Thomas Monjalon 
---
 app/test-pipeline/init.c |  2 +-
 app/test-pmd/testpmd.c   |  2 +-
 app/test/test_pmd_perf.c |  2 +-
 app/test/virtual_pmd.c   |  6 +++---
 drivers/net/af_packet/rte_eth_af_packet.c|  6 +++---
 drivers/net/bnx2x/bnx2x_ethdev.c |  2 +-
 drivers/net/bnx2x/elink.c|  2 +-
 drivers/net/bonding/rte_eth_bond_api.c   |  4 ++--
 drivers/net/bonding/rte_eth_bond_pmd.c   | 12 ++--
 drivers/net/e1000/em_ethdev.c|  8 
 drivers/net/e1000/igb_ethdev.c   |  4 ++--
 drivers/net/fm10k/fm10k_ethdev.c |  2 +-
 drivers/net/i40e/i40e_ethdev_vf.c|  2 +-
 drivers/net/ixgbe/ixgbe_ethdev.c |  4 ++--
 drivers/net/mpipe/mpipe_tilegx.c | 12 ++--
 drivers/net/nfp/nfp_net.c|  2 +-
 drivers/net/null/rte_eth_null.c  |  6 +++---
 drivers/net/pcap/rte_eth_pcap.c  |  6 +++---
 drivers/net/ring/rte_eth_ring.c  | 10 +-
 drivers/net/szedata2/rte_eth_szedata2.c  |  2 +-
 drivers/net/vhost/rte_eth_vhost.c|  6 +++---
 drivers/net/virtio/virtio_ethdev.c   |  6 +++---
 drivers/net/vmxnet3/vmxnet3_ethdev.c |  2 +-
 drivers/net/xenvirt/rte_eth_xenvirt.c|  6 +++---
 examples/exception_path/main.c   |  2 +-
 examples/ip_fragmentation/main.c |  2 +-
 examples/ip_pipeline/init.c  |  2 +-
 examples/ip_reassembly/main.c|  2 +-
 examples/ipsec-secgw/ipsec-secgw.c   |  2 +-
 examples/ipv4_multicast/main.c   |  2 +-
 examples/kni/main.c  |  2 +-
 examples/l2fwd-crypto/main.c |  2 +-
 examples/l2fwd-ivshmem/host/host.c   |  2 +-
 examples/l2fwd-jobstats/main.c   |  2 +-
 examples/l2fwd-keepalive/main.c  |  2 +-
 examples/l2fwd/main.c|  2 +-
 examples/l3fwd-acl/main.c|  2 +-
 examples/l3fwd-power/main.c  |  2 +-
 examples/l3fwd/main.c|  2 +-
 examples/link_status_interrupt/main.c|  2 +-
 examples/load_balancer/init.c|  2 +-
 examples/multi_process/client_server_mp/mp_server/init.c |  2 +-
 examples/multi_process/l2fwd_fork/main.c |  2 +-
 examples/multi_process/symmetric_mp/main.c   |  2 +-
 examples/performance-thread/l3fwd-thread/main.c  |  2 +-
 lib/librte_ether/rte_ethdev.h|  5 -
 46 files changed, 83 insertions(+), 80 deletions(-)

diff --git a/app/test-pipeline/init.c b/app/test-pipeline/init.c
index db2196b..aef082f 100644
--- a/app/test-pipeline/init.c
+++ b/app/test-pipeline/init.c
@@ -205,7 +205,7 @@ app_ports_check_link(void)
link.link_speed / 1000,
link.link_status ? "UP" : "DOWN");

-   if (link.link_status == 0)
+   if (link.link_status == ETH_LINK_DOWN)
all_ports_up = 0;
}

diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 8605e62..1398c6c 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -1641,7 +1641,7 @@ check_all_ports_link_status(uint32_t port_mask)
continue;
}
/* clear all_ports_up flag if any link down */
-   if (link.link_status == 0) {
+   if (link.link_status == ETH_LINK_DOWN) {
all_ports_up = 0;
break;
}
diff --git a/app/test/test_pmd_perf.c b/app/test/test_pmd_perf.c
index 48e16c9..59803f7 100644
--- a/app/test/test_pmd_perf.c
+++ b/app/test/test_pmd_perf.c
@@ -192,7 +192,7 @@ check_all_ports_link_status(uint8_t port_num, uint32_t 
port_mask)
continue;
}
/* clear all_ports_up flag if any link down */
-   if (link.link_status == 0) {
+   if (link.link_status == ETH_LINK_DOWN) {
all_ports_up = 0;
   

[dpdk-dev] [PATCH v13 0/8] ethdev: 100G and link speed API refactoring

2016-03-26 Thread Marc Sune
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-rc3.
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).



v13:
- Fix startup regression; revert flip of ETH_LINK_SPEED_FIXED and
  ETH_LINK_SPEED_AUTONEG values. ETH_LINK_SPEED_AUTONEG is now 0.
- Fix incorrect duplex link reporting for e1000.
- Do not allow more than one speed in the bitmap when
  ETH_LINK_SPEED_FIXED is used for e1000.

v12:
- rebase on 16.04-rc2
- fix mlx capabilities
- update ENA driver

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/deprecation.rst   |   3 -
 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  | 117 +--
 drivers/net/e1

[dpdk-dev] [PATCH v9 0/4] ethdev: add speed capabilities and refactor link API

2016-03-08 Thread Marc Sune
2016-03-01 1:45 GMT+01: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 could 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.html
>
> However, i) doing string comparisons is annoying, and can silently
> break existing applications if PMDs change their names ii) it does not
> provide all the supported capabilities of the ethdev iii) for some drivers
> it
> is impossible determine correctly the (max) speed by the application
> (e.g. in i40, distinguish between XL710 and X710).
>
> In addition, the link APIs do not allow to define a set of advertised link
> speeds for autonegociation.
>
> 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).
>
> WARNING: this patch series, specifically 3/4, is NOT tested for most of the
> PMDs, due to the lack of hardware. Only generic EM is tested (VM).
> Reviewing
> and testing required by PMD maintainers.
>
> * * * * *
>
> v2: rebase, converted speed_capa into 32 bits bitmap, fixed alignment
> (checkpatch).
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> v7: Rebased to current HEAD. Moved documentation to v2.3. Still needs
> testing
> from PMD maintainers.
>
> 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.
>
> 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.
>

Anyone interested in reviewing and _testing_ this series?

Thank you
Marc


>
> Marc Sune (4):
>   ethdev: Added ETH_SPEED_CAP bitmap for ports
>   ethdev: Fill speed capability bitmaps in the PMDs
>   ethdev: redesign link speed config API
>   doc: update with link changes
>
>  app/test-pipeline/init.c  |   2 +-
>  app/test-pmd/cmdline.c| 124
> +++---
>  app/test-pmd/config.c |   4 +-
>  app/test/virtual_pmd.c|   4 +-
>  doc/guides/nics/overview.rst  |   1 +
>  doc/guides/rel_notes/release_16_04.rst|  27 +++
>  drivers/net/af_packet/rte_eth_af_packet.c |   5 +-
>  drivers/net/bnx2x/bnx2x_ethdev.c  |   7 +-
>  drivers/net/bonding/rte_eth_bond_8023ad.c |  14 ++--
>  drivers/net/cxgbe/base/t4_hw.c|   8 +-
>  drivers/net/cxgbe/cxgbe_ethdev.c  |   1 +
>  drivers/net/e1000/em_ethdev.c | 112
> ++-
>  drivers/net/e1000/igb_ethdev.c| 107 +++---
>  drivers/net/fm10k/fm10k_ethdev.c  |   6 +-
>  drivers/net/i40e/i40e_ethdev.c|  78 +++
>  drivers/net/i40e/i40e_ethdev_vf.c |  11 +--
>  drivers/net/ixgbe/ixgbe_ethdev.c  |  80 +--
>  drivers/net/mlx4/mlx4.c   |   6 ++
>  drivers/net/mlx5/mlx5_ethdev.c|   7 ++
>  drivers/net/mpipe/mpipe_tilegx.c  |   6 +-
>  drivers/net/nfp/nfp_net.c |   4 +-

[dpdk-dev] [PATCH] cmdline: include missing cmdline_parse.h

2016-03-03 Thread Marc Sune
cmdline_parse_*.h headers use struct cmdline_token_hdr /
cmdline_parse_token_hdr_t which is defined in cmdline_parse.h, but
do not include it, forcing manual inclusion.

This commit includes cmdline_parse.h in all cmdline_parse_*.h.
---
 lib/librte_cmdline/cmdline_parse_etheraddr.h | 2 ++
 lib/librte_cmdline/cmdline_parse_ipaddr.h| 1 +
 lib/librte_cmdline/cmdline_parse_num.h   | 2 ++
 lib/librte_cmdline/cmdline_parse_portlist.h  | 2 ++
 lib/librte_cmdline/cmdline_parse_string.h| 2 ++
 5 files changed, 9 insertions(+)

diff --git a/lib/librte_cmdline/cmdline_parse_etheraddr.h 
b/lib/librte_cmdline/cmdline_parse_etheraddr.h
index 0085bb3..e539fb6 100644
--- a/lib/librte_cmdline/cmdline_parse_etheraddr.h
+++ b/lib/librte_cmdline/cmdline_parse_etheraddr.h
@@ -61,6 +61,8 @@
 #ifndef _PARSE_ETHERADDR_H_
 #define _PARSE_ETHERADDR_H_

+#include 
+
 #ifdef __cplusplus
 extern "C" {
 #endif
diff --git a/lib/librte_cmdline/cmdline_parse_ipaddr.h 
b/lib/librte_cmdline/cmdline_parse_ipaddr.h
index 46c6e1b..2b4266f 100644
--- a/lib/librte_cmdline/cmdline_parse_ipaddr.h
+++ b/lib/librte_cmdline/cmdline_parse_ipaddr.h
@@ -61,6 +61,7 @@
 #ifndef _PARSE_IPADDR_H_
 #define _PARSE_IPADDR_H_

+#include 
 #include 

 #ifdef __cplusplus
diff --git a/lib/librte_cmdline/cmdline_parse_num.h 
b/lib/librte_cmdline/cmdline_parse_num.h
index 5376806..2558cbf 100644
--- a/lib/librte_cmdline/cmdline_parse_num.h
+++ b/lib/librte_cmdline/cmdline_parse_num.h
@@ -61,6 +61,8 @@
 #ifndef _PARSE_NUM_H_
 #define _PARSE_NUM_H_

+#include 
+
 #ifdef __cplusplus
 extern "C" {
 #endif
diff --git a/lib/librte_cmdline/cmdline_parse_portlist.h 
b/lib/librte_cmdline/cmdline_parse_portlist.h
index 8505059..73d70e0 100644
--- a/lib/librte_cmdline/cmdline_parse_portlist.h
+++ b/lib/librte_cmdline/cmdline_parse_portlist.h
@@ -61,6 +61,8 @@
 #ifndef _PARSE_PORTLIST_H_
 #define _PARSE_PORTLIST_H_

+#include 
+
 #ifdef __cplusplus
 extern "C" {
 #endif
diff --git a/lib/librte_cmdline/cmdline_parse_string.h 
b/lib/librte_cmdline/cmdline_parse_string.h
index c205622..94aa1f1 100644
--- a/lib/librte_cmdline/cmdline_parse_string.h
+++ b/lib/librte_cmdline/cmdline_parse_string.h
@@ -61,6 +61,8 @@
 #ifndef _PARSE_STRING_H_
 #define _PARSE_STRING_H_

+#include 
+
 #ifdef __cplusplus
 extern "C" {
 #endif
-- 
2.1.4



[dpdk-dev] [PATCH] cryptodev: fix RTE_PMD_DEBUG_TRACE redefinition

2016-03-03 Thread Marc Sune
RTE_PMD_DEBUG_TRACE used RTE_FUNC_PTR_OR_ERR_RET was redefined
in rte_cryptodev_pmd.h which produced MACRO redefinition warnings
when including both rte_cryptodev_pmd.h and rte_ethdev.h.

This commit moves MACRO definition to rte_cryptodev.c to prevent
this warning.
---
 lib/librte_cryptodev/rte_cryptodev.c | 7 +++
 lib/librte_cryptodev/rte_cryptodev_pmd.h | 7 ---
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/lib/librte_cryptodev/rte_cryptodev.c 
b/lib/librte_cryptodev/rte_cryptodev.c
index 2838852..90d2c30 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -71,6 +71,13 @@
 #include "rte_cryptodev.h"
 #include "rte_cryptodev_pmd.h"

+#ifdef RTE_LIBRTE_CRYPTODEV_DEBUG
+#define RTE_PMD_DEBUG_TRACE(...) \
+   rte_pmd_debug_trace(__func__, __VA_ARGS__)
+#else
+#define RTE_PMD_DEBUG_TRACE(fmt, args...)
+#endif
+
 struct rte_cryptodev rte_crypto_devices[RTE_CRYPTO_MAX_DEVS];

 struct rte_cryptodev *rte_cryptodevs = _crypto_devices[0];
diff --git a/lib/librte_cryptodev/rte_cryptodev_pmd.h 
b/lib/librte_cryptodev/rte_cryptodev_pmd.h
index 8270afa..c43680f 100644
--- a/lib/librte_cryptodev/rte_cryptodev_pmd.h
+++ b/lib/librte_cryptodev/rte_cryptodev_pmd.h
@@ -62,13 +62,6 @@ struct rte_cryptodev_qp_conf;

 enum rte_cryptodev_event_type;

-#ifdef RTE_LIBRTE_CRYPTODEV_DEBUG
-#define RTE_PMD_DEBUG_TRACE(...) \
-   rte_pmd_debug_trace(__func__, __VA_ARGS__)
-#else
-#define RTE_PMD_DEBUG_TRACE(fmt, args...)
-#endif
-
 struct rte_cryptodev_session {
struct {
uint8_t dev_id;
-- 
2.1.4



[dpdk-dev] [PATCH v9 4/4] doc: update with link changes

2016-03-01 Thread Marc Sune
Add new features, ABI changes and resolved issues notice for
the refactored link patch.

Signed-off-by: Marc Sune 
---
 doc/guides/nics/overview.rst   |  1 +
 doc/guides/rel_notes/release_16_04.rst | 27 +++
 2 files changed, 28 insertions(+)

diff --git a/doc/guides/nics/overview.rst b/doc/guides/nics/overview.rst
index d4c6ff4..6c1ae33 100644
--- a/doc/guides/nics/overview.rst
+++ b/doc/guides/nics/overview.rst
@@ -88,6 +88,7 @@ Most of these differences are summarized below.
 = = = = = = = = = = = = = = = = = = = = = = = = = = = 
= = = =
link status
link status event
+   Speed capabilities
Rx interrupt
queue start/stop
MTU update
diff --git a/doc/guides/rel_notes/release_16_04.rst 
b/doc/guides/rel_notes/release_16_04.rst
index 64e913d..fd2d3cc 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -20,6 +20,18 @@ Build the docs and view the output file to ensure the 
changes are correct::
 New Features
 

+* **ethdev: define a set of advertised link speeds.**
+
+  Added functionality to Allow defining a set of advertised speeds for
+  auto-negociation, explicitely disabling link auto-negociation (single speed)
+  and full auto-negociation.
+
+* **ethdev: add speed_cap bitmap for link speed capabilities.**
+
+  ``struct rte_eth_dev_info`` has now ``speed_cap`` bitmap, which allows the
+  application to recover the supported speeds for that ethernet device.
+
+
 This section should contain new features added in this release. Sample format:

 * **Add a title in the past tense with a full stop.**
@@ -55,6 +67,11 @@ This section should contain new features added in this 
release. Sample format:
 Resolved Issues
 ---

+* **ethdev: Fixed link_speed overflow in rte_eth_link for 100Gbps.**
+
+  100Gbps in Mbps (10) exceeds 16 bit max value of ``link_speed`` in
+  ``rte_eth_link``.
+
 This section should contain bug fixes added to the relevant sections. Sample 
format:

 * **code/section Fixed issue in the past tense with a full stop.**
@@ -87,6 +104,9 @@ Drivers
 Libraries
 ~

+* New API call, ``rte_eth_speed_to_bm_flag`` in ethdev to, map numerical speeds
+  to bitmap fields.
+

 Examples
 
@@ -119,6 +139,13 @@ This section should contain API changes. Sample format:
 ABI Changes
 ---

+* The ethdev ``rte_eth_link`` and ``rte_eth_conf`` structures were changed to
+  support the new link API, as well as ``ETH_LINK_HALF``/``FULL_DUPLEX``.
+
+* The ethdev ``rte_eth_dev_info`` was changed to support device speed
+  capabilities.
+
+
 * Add a short 1-2 sentence description of the ABI change that was announced in
   the previous releases and made in this release. Use fixed width quotes for
   ``rte_function_names`` or ``rte_struct_names``. Use the past tense.
-- 
2.1.4



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

2016-03-01 Thread Marc Sune
This patch redesigns the API to set the link speed/s configure
for an ethernet port. Specifically:

- it allows to define a set of advertised speeds for
  auto-negociation.
- it allows to disable link auto-negociation (single fixed speed).
- default: auto-negociate all supported speeds.

Other changes:

* Added utility MACROs ETH_SPEED_NUM_XXX with the numeric
  values of all supported link speeds, in Mbps.
* Converted link_speed to uint32_t to accomodate 100G speeds
  and beyond (bug).
* Added autoneg flag in struct rte_eth_link to indicate if
  link speed was a result of auto-negociation or was fixed
  by configuration.
* Added utility function to convert numeric speeds to bitmap
  fields.
* Added rte_eth_speed_to_bm_flag() to version map.

Signed-off-by: Marc Sune 
---
 app/test-pipeline/init.c  |   2 +-
 app/test-pmd/cmdline.c| 124 +++---
 app/test-pmd/config.c |   4 +-
 app/test/virtual_pmd.c|   4 +-
 drivers/net/af_packet/rte_eth_af_packet.c |   5 +-
 drivers/net/bnx2x/bnx2x_ethdev.c  |   8 +-
 drivers/net/bonding/rte_eth_bond_8023ad.c |  14 ++--
 drivers/net/cxgbe/base/t4_hw.c|   8 +-
 drivers/net/cxgbe/cxgbe_ethdev.c  |   2 +-
 drivers/net/e1000/em_ethdev.c | 116 ++--
 drivers/net/e1000/igb_ethdev.c| 111 +-
 drivers/net/fm10k/fm10k_ethdev.c  |   8 +-
 drivers/net/i40e/i40e_ethdev.c|  73 +-
 drivers/net/i40e/i40e_ethdev_vf.c |  11 +--
 drivers/net/ixgbe/ixgbe_ethdev.c  |  78 ---
 drivers/net/mlx4/mlx4.c   |   6 +-
 drivers/net/mlx5/mlx5_ethdev.c|  10 +--
 drivers/net/mpipe/mpipe_tilegx.c  |   6 +-
 drivers/net/nfp/nfp_net.c |   4 +-
 drivers/net/null/rte_eth_null.c   |   5 +-
 drivers/net/pcap/rte_eth_pcap.c   |   9 ++-
 drivers/net/ring/rte_eth_ring.c   |   5 +-
 drivers/net/virtio/virtio_ethdev.c|   2 +-
 drivers/net/virtio/virtio_ethdev.h|   2 -
 drivers/net/vmxnet3/vmxnet3_ethdev.c  |   5 +-
 drivers/net/xenvirt/rte_eth_xenvirt.c |   5 +-
 examples/ip_pipeline/config_parse.c   |   3 +-
 lib/librte_ether/rte_ethdev.c |  49 
 lib/librte_ether/rte_ethdev.h | 113 +--
 lib/librte_ether/rte_ether_version.map|   6 ++
 30 files changed, 448 insertions(+), 350 deletions(-)

diff --git a/app/test-pipeline/init.c b/app/test-pipeline/init.c
index db2196b..6a69fe2 100644
--- a/app/test-pipeline/init.c
+++ b/app/test-pipeline/init.c
@@ -200,7 +200,7 @@ app_ports_check_link(void)
port = (uint8_t) app.ports[i];
memset(, 0, sizeof(link));
rte_eth_link_get_nowait(port, );
-   RTE_LOG(INFO, USER1, "Port %u (%u Gbps) %s\n",
+   RTE_LOG(INFO, USER1, "Port %u (%d Gbps) %s\n",
port,
link.link_speed / 1000,
link.link_status ? "UP" : "DOWN");
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 52e9f5f..57ad25f 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -956,14 +956,65 @@ struct cmd_config_speed_all {
cmdline_fixed_string_t value2;
 };

+static int
+parse_and_check_speed_duplex(char *value1, char *value2, uint32_t *link_speed)
+{
+
+   int duplex;
+
+   if (!strcmp(value2, "half")) {
+   duplex = 0;
+   } else if (!strcmp(value2, "full")) {
+   duplex = 1;
+   } else if (!strcmp(value2, "auto")) {
+   duplex = 1;
+   } else {
+   printf("Unknown parameter\n");
+   return -1;
+   }
+
+   if (!strcmp(value1, "10")) {
+   *link_speed = (duplex) ? ETH_LINK_SPEED_10M :
+   ETH_LINK_SPEED_10M_HD;
+   } else if (!strcmp(value1, "100")) {
+   *link_speed = (duplex) ? ETH_LINK_SPEED_100M :
+   ETH_LINK_SPEED_100M_HD;
+   } else if (!strcmp(value1, "1000")) {
+   if (!duplex)
+   goto invalid_speed_param;
+   *link_speed = ETH_LINK_SPEED_1G;
+   } else if (!strcmp(value1, "1")) {
+   if (!duplex)
+   goto invalid_speed_param;
+   *link_speed = ETH_LINK_SPEED_10G;
+   } else if (!strcmp(value1, "4")) {
+   if (!duplex)
+   goto invalid_speed_param;
+   *link_speed = ETH_LINK_SPEED_40G;
+   } else if (!strcmp(value1, "auto")) {
+   if (!duplex)
+   goto invalid_speed_param;
+  

[dpdk-dev] [PATCH v9 2/4] ethdev: Fill speed capability bitmaps in the PMDs

2016-03-01 Thread Marc Sune
Added speed capabilities to all pmds supporting physical NICs:

* e1000
* ixgbe
* i40
* bnx2x
* cxgbe
* mlx4
* mlx5
* nfp
* fm10k

Signed-off-by: Marc Sune 
---
 drivers/net/bnx2x/bnx2x_ethdev.c |  1 +
 drivers/net/cxgbe/cxgbe_ethdev.c |  1 +
 drivers/net/e1000/em_ethdev.c|  6 ++
 drivers/net/e1000/igb_ethdev.c   |  6 ++
 drivers/net/fm10k/fm10k_ethdev.c |  4 
 drivers/net/i40e/i40e_ethdev.c   |  9 +
 drivers/net/ixgbe/ixgbe_ethdev.c | 10 ++
 drivers/net/mlx4/mlx4.c  |  4 
 drivers/net/mlx5/mlx5_ethdev.c   |  7 +++
 drivers/net/nfp/nfp_net.c|  2 ++
 10 files changed, 50 insertions(+)

diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c b/drivers/net/bnx2x/bnx2x_ethdev.c
index 69df02e..b547ac3 100644
--- a/drivers/net/bnx2x/bnx2x_ethdev.c
+++ b/drivers/net/bnx2x/bnx2x_ethdev.c
@@ -347,6 +347,7 @@ bnx2x_dev_infos_get(struct rte_eth_dev *dev, __rte_unused 
struct rte_eth_dev_inf
dev_info->min_rx_bufsize = BNX2X_MIN_RX_BUF_SIZE;
dev_info->max_rx_pktlen  = BNX2X_MAX_RX_PKT_LEN;
dev_info->max_mac_addrs  = BNX2X_MAX_MAC_ADDRS;
+   dev_info->speed_capa = ETH_SPEED_CAP_10G | ETH_SPEED_CAP_20G;
 }

 static void
diff --git a/drivers/net/cxgbe/cxgbe_ethdev.c b/drivers/net/cxgbe/cxgbe_ethdev.c
index 97ef152..203e119 100644
--- a/drivers/net/cxgbe/cxgbe_ethdev.c
+++ b/drivers/net/cxgbe/cxgbe_ethdev.c
@@ -171,6 +171,7 @@ static void cxgbe_dev_info_get(struct rte_eth_dev *eth_dev,

device_info->rx_desc_lim = cxgbe_desc_lim;
device_info->tx_desc_lim = cxgbe_desc_lim;
+   device_info->speed_capa = ETH_SPEED_CAP_10G | ETH_SPEED_CAP_40G;
 }

 static void cxgbe_dev_promiscuous_enable(struct rte_eth_dev *eth_dev)
diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index 4a843fe..e40dc37 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -1023,6 +1023,12 @@ eth_em_infos_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
.nb_min = E1000_MIN_RING_DESC,
.nb_align = EM_TXD_ALIGN,
};
+
+   dev_info->speed_capa = ETH_SPEED_CAP_10M_HD |
+   ETH_SPEED_CAP_10M_FD |
+   ETH_SPEED_CAP_100M_HD |
+   ETH_SPEED_CAP_100M_FD |
+   ETH_SPEED_CAP_1G;
 }

 /* return 0 means link status changed, -1 means not changed */
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index 4ed5e95..7eac8ea 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -1908,6 +1908,12 @@ eth_igb_infos_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)

dev_info->rx_desc_lim = rx_desc_lim;
dev_info->tx_desc_lim = tx_desc_lim;
+
+   dev_info->speed_capa = ETH_SPEED_CAP_10M_HD |
+   ETH_SPEED_CAP_10M_FD |
+   ETH_SPEED_CAP_100M_HD |
+   ETH_SPEED_CAP_100M_FD |
+   ETH_SPEED_CAP_1G;
 }

 static void
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index 421266b..2e6ec60 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -1333,6 +1333,10 @@ fm10k_dev_infos_get(struct rte_eth_dev *dev,
.nb_min = FM10K_MIN_TX_DESC,
.nb_align = FM10K_MULT_TX_DESC,
};
+
+   dev_info->speed_capa = ETH_SPEED_CAP_1G | ETH_SPEED_CAP_2_5G |
+   ETH_SPEED_CAP_10G | ETH_SPEED_CAP_25G |
+   ETH_SPEED_CAP_40G | ETH_SPEED_CAP_100G;
 }

 static int
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index ef24122..78a0cbd 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -2233,6 +2233,7 @@ static void
 i40e_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
 {
struct i40e_pf *pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
+   struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
struct i40e_vsi *vsi = pf->main_vsi;

dev_info->max_rx_queues = vsi->nb_qps;
@@ -2304,6 +2305,14 @@ i40e_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
dev_info->max_rx_queues += dev_info->vmdq_queue_num;
dev_info->max_tx_queues += dev_info->vmdq_queue_num;
}
+
+   if (i40e_is_40G_device(hw->device_id))
+   /* For XL710 */
+   dev_info->speed_capa = ETH_SPEED_CAP_1G | ETH_SPEED_CAP_10G;
+   else
+   /* For X710 */
+   dev_info->speed_capa = ETH_SPEED_CAP_10G | ETH_SPEED_CAP_40G;
+
 }

 static int
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/dr

[dpdk-dev] [PATCH v9 1/4] ethdev: Added ETH_SPEED_CAP bitmap for ports

2016-03-01 Thread Marc Sune
Added constants and bitmap to struct rte_eth_dev_info to be used by PMDs.

Signed-off-by: Marc Sune 
---
 lib/librte_ether/rte_ethdev.h | 24 
 1 file changed, 24 insertions(+)

diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 16da821..83ddbb7 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -824,6 +824,29 @@ struct rte_eth_conf {
 #define DEV_TX_OFFLOAD_OUTER_IPV4_CKSUM 0x0080 /**< Used for tunneling 
packet. */
 #define DEV_TX_OFFLOAD_QINQ_INSERT 0x0100

+/**
+ * Device supported speeds
+ */
+#define ETH_SPEED_CAP_NOT_PHY  (0)  /*< No phy media > */
+#define ETH_SPEED_CAP_10M_HD   (1 << 0)  /*< 10 Mbps half-duplex> */
+#define ETH_SPEED_CAP_10M_FD   (1 << 1)  /*< 10 Mbps full-duplex> */
+#define ETH_SPEED_CAP_100M_HD  (1 << 2)  /*< 100 Mbps half-duplex> */
+#define ETH_SPEED_CAP_100M_FD  (1 << 3)  /*< 100 Mbps full-duplex> */
+#define ETH_SPEED_CAP_1G   (1 << 4)  /*< 1 Gbps > */
+#define ETH_SPEED_CAP_2_5G (1 << 5)  /*< 2.5 Gbps > */
+#define ETH_SPEED_CAP_5G   (1 << 6)  /*< 5 Gbps > */
+#define ETH_SPEED_CAP_10G  (1 << 7)  /*< 10 Mbps > */
+#define ETH_SPEED_CAP_20G  (1 << 8)  /*< 20 Gbps > */
+#define ETH_SPEED_CAP_25G  (1 << 9)  /*< 25 Gbps > */
+#define ETH_SPEED_CAP_40G  (1 << 10)  /*< 40 Gbps > */
+#define ETH_SPEED_CAP_50G  (1 << 11)  /*< 50 Gbps > */
+#define ETH_SPEED_CAP_56G  (1 << 12)  /*< 56 Gbps > */
+#define ETH_SPEED_CAP_100G (1 << 13)  /*< 100 Gbps > */
+
+
+/**
+ * Ethernet device information
+ */
 struct rte_eth_dev_info {
struct rte_pci_device *pci_dev; /**< Device PCI information. */
const char *driver_name; /**< Device Driver name. */
@@ -852,6 +875,7 @@ struct rte_eth_dev_info {
uint16_t vmdq_pool_base;  /**< First ID of VMDQ pools. */
struct rte_eth_desc_lim rx_desc_lim;  /**< RX descriptors limits */
struct rte_eth_desc_lim tx_desc_lim;  /**< TX descriptors limits */
+   uint32_t speed_capa;  /**< Supported speeds bitmap (ETH_SPEED_CAP_). */
 };

 /**
-- 
2.1.4



[dpdk-dev] [PATCH v9 0/4] ethdev: add speed capabilities and refactor link API

2016-03-01 Thread 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 could 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.html

However, i) doing string comparisons is annoying, and can silently
break existing applications if PMDs change their names ii) it does not
provide all the supported capabilities of the ethdev iii) for some drivers it
is impossible determine correctly the (max) speed by the application
(e.g. in i40, distinguish between XL710 and X710).

In addition, the link APIs do not allow to define a set of advertised link
speeds for autonegociation.

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).

WARNING: this patch series, specifically 3/4, is NOT tested for most of the
PMDs, due to the lack of hardware. Only generic EM is tested (VM). Reviewing
and testing required by PMD maintainers.

* * * * *

v2: rebase, converted speed_capa into 32 bits bitmap, fixed alignment
(checkpatch).

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.

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.

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.

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.

v7: Rebased to current HEAD. Moved documentation to v2.3. Still needs testing
from PMD maintainers.

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.

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.

Marc Sune (4):
  ethdev: Added ETH_SPEED_CAP bitmap for ports
  ethdev: Fill speed capability bitmaps in the PMDs
  ethdev: redesign link speed config API
  doc: update with link changes

 app/test-pipeline/init.c  |   2 +-
 app/test-pmd/cmdline.c| 124 +++---
 app/test-pmd/config.c |   4 +-
 app/test/virtual_pmd.c|   4 +-
 doc/guides/nics/overview.rst  |   1 +
 doc/guides/rel_notes/release_16_04.rst|  27 +++
 drivers/net/af_packet/rte_eth_af_packet.c |   5 +-
 drivers/net/bnx2x/bnx2x_ethdev.c  |   7 +-
 drivers/net/bonding/rte_eth_bond_8023ad.c |  14 ++--
 drivers/net/cxgbe/base/t4_hw.c|   8 +-
 drivers/net/cxgbe/cxgbe_ethdev.c  |   1 +
 drivers/net/e1000/em_ethdev.c | 112 ++-
 drivers/net/e1000/igb_ethdev.c| 107 +++---
 drivers/net/fm10k/fm10k_ethdev.c  |   6 +-
 drivers/net/i40e/i40e_ethdev.c|  78 +++
 drivers/net/i40e/i40e_ethdev_vf.c |  11 +--
 drivers/net/ixgbe/ixgbe_ethdev.c  |  80 +--
 drivers/net/mlx4/mlx4.c   |   6 ++
 drivers/net/mlx5/mlx5_ethdev.c|   7 ++
 drivers/net/mpipe/mpipe_tilegx.c  |   6 +-
 drivers/net/nfp/nfp_net.c |   4 +-
 drivers/net/null/rte_eth_null.c   |   5 +-
 drivers/net/pcap/rte_eth_pcap.c   |   9 ++-
 drivers/net/ring/rte_eth_ring.c   |   5 +-
 drivers/net/virtio/virtio_ethdev.c|   2 +-
 drivers/net/virtio/virtio_ethdev.h|   2 -
 drivers/net/vmxnet3/vmxnet3_ethdev.c  |   5 +-
 drivers/net/xenvirt/rte_eth_xenvirt.c |   5 +-
 examples/ip_pipeline/config_parse.c   |   3 +-
 lib/librte_ether/rte_ethdev.c |  49 
 lib/librte_ether/rte_ethdev.h |  97 ++-
 lib/librte_ether/rte_ether_version.map|   6 ++
 32 files changed, 501 inserti

[dpdk-dev] [PATCH v8 4/4] doc: update with link changes

2016-02-14 Thread Marc Sune
Add new features, ABI changes and resolved issues notice for
the refactored link patch.

Signed-off-by: Marc Sune 
---
 doc/guides/rel_notes/release_2_3.rst | 102 +++
 1 file changed, 102 insertions(+)
 create mode 100644 doc/guides/rel_notes/release_2_3.rst

diff --git a/doc/guides/rel_notes/release_2_3.rst 
b/doc/guides/rel_notes/release_2_3.rst
new file mode 100644
index 000..b10c3bb
--- /dev/null
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -0,0 +1,102 @@
+DPDK Release 2.3
+
+
+New Features
+
+
+* **ethdev: define a set of advertised link speeds.**
+
+  Allowing to define a set of advertised speeds for auto-negociation,
+  explicitely disable link auto-negociation (single speed) and full
+  auto-negociation.
+
+* **ethdev: add speed_cap bitmap to recover eth device link speed capabilities
+  define a set of advertised link speeds.**
+
+  ``struct rte_eth_dev_info`` has now speed_cap bitmap, which allows the
+  application to recover the supported speeds for that ethernet device.
+
+
+Resolved Issues
+---
+
+* **ethdev: Fixed link_speed overflow in rte_eth_link for 100Gbps.**
+
+  100Gbps in Mbps (10) exceeds 16 bit max value of ``link_speed`` in
+  ``rte_eth_link``.
+
+
+EAL
+~~~
+
+
+Drivers
+~~~
+
+
+Libraries
+~
+
+
+Examples
+
+
+* New API call, rte_eth_speed_to_bm_flag(), in ethdev to map numerical speeds
+  to bitmap fields.
+
+
+Other
+~
+
+
+Known Issues
+
+
+
+API Changes
+---
+
+
+ABI Changes
+---
+
+* The ethdev rte_eth_link and rte_eth_conf structures were changed to
+  support the new link API, as well as ETH_LINK_HALF/FULL_DUPLEX.
+
+* The ethdev rte_eth_dev_info was changed to support device speed capabilities.
+
+
+Shared Library Versions
+---
+
+The libraries prepended with a plus sign were incremented in this version.
+
+.. code-block:: diff
+
+ libethdev.so.2
+ librte_acl.so.2
+ librte_cfgfile.so.2
+ librte_cmdline.so.1
+ librte_distributor.so.1
+ librte_eal.so.2
+ librte_hash.so.2
+ librte_ip_frag.so.1
+ librte_ivshmem.so.1
+ librte_jobstats.so.1
+ librte_kni.so.2
+ librte_kvargs.so.1
+ librte_lpm.so.2
+ librte_mbuf.so.2
+ librte_mempool.so.1
+ librte_meter.so.1
+ librte_pipeline.so.2
+ librte_pmd_bond.so.1
+ librte_pmd_ring.so.2
+ librte_port.so.2
+ librte_power.so.1
+ librte_reorder.so.1
+ librte_ring.so.1
+ librte_sched.so.1
+ librte_table.so.2
+ librte_timer.so.1
+ librte_vhost.so.2
-- 
2.1.4



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

2016-02-14 Thread Marc Sune
This patch redesigns the API to set the link speed/s configure
for an ethernet port. Specifically:

- it allows to define a set of advertised speeds for
  auto-negociation.
- it allows to disable link auto-negociation (single fixed speed).
- default: auto-negociate all supported speeds.

Other changes:

* Added utility MACROs ETH_SPEED_NUM_XXX with the numeric
  values of all supported link speeds, in Mbps.
* Converted link_speed to uint64_t to accomodate 100G speeds
  and beyond (bug).
* Added autoneg flag in struct rte_eth_link to indicate if
  link speed was a result of auto-negociation or was fixed
  by configuration.
* Added utility function to convert numeric speeds to bitmap
  fields.
* Added rte_eth_speed_to_bm_flag() to version map.

Signed-off-by: Marc Sune 
---
 app/test-pipeline/init.c  |   2 +-
 app/test-pmd/cmdline.c| 124 +++---
 app/test-pmd/config.c |   4 +-
 app/test/virtual_pmd.c|   4 +-
 drivers/net/af_packet/rte_eth_af_packet.c |   5 +-
 drivers/net/bnx2x/bnx2x_ethdev.c  |   8 +-
 drivers/net/bonding/rte_eth_bond_8023ad.c |  14 ++--
 drivers/net/cxgbe/base/t4_hw.c|   8 +-
 drivers/net/cxgbe/cxgbe_ethdev.c  |   2 +-
 drivers/net/e1000/em_ethdev.c | 116 ++--
 drivers/net/e1000/igb_ethdev.c| 111 +-
 drivers/net/fm10k/fm10k_ethdev.c  |   8 +-
 drivers/net/i40e/i40e_ethdev.c|  73 +-
 drivers/net/i40e/i40e_ethdev_vf.c |  11 +--
 drivers/net/ixgbe/ixgbe_ethdev.c  |  78 ---
 drivers/net/mlx4/mlx4.c   |   6 +-
 drivers/net/mpipe/mpipe_tilegx.c  |   6 +-
 drivers/net/nfp/nfp_net.c |   4 +-
 drivers/net/null/rte_eth_null.c   |   5 +-
 drivers/net/pcap/rte_eth_pcap.c   |   9 ++-
 drivers/net/ring/rte_eth_ring.c   |   5 +-
 drivers/net/virtio/virtio_ethdev.c|   2 +-
 drivers/net/virtio/virtio_ethdev.h|   2 -
 drivers/net/vmxnet3/vmxnet3_ethdev.c  |   5 +-
 drivers/net/xenvirt/rte_eth_xenvirt.c |   5 +-
 examples/ip_pipeline/config_parse.c   |   3 +-
 lib/librte_ether/rte_ethdev.c |  49 
 lib/librte_ether/rte_ethdev.h | 113 +--
 lib/librte_ether/rte_ether_version.map|   6 ++
 29 files changed, 443 insertions(+), 345 deletions(-)

diff --git a/app/test-pipeline/init.c b/app/test-pipeline/init.c
index db2196b..08fb041 100644
--- a/app/test-pipeline/init.c
+++ b/app/test-pipeline/init.c
@@ -200,7 +200,7 @@ app_ports_check_link(void)
port = (uint8_t) app.ports[i];
memset(, 0, sizeof(link));
rte_eth_link_get_nowait(port, );
-   RTE_LOG(INFO, USER1, "Port %u (%u Gbps) %s\n",
+   RTE_LOG(INFO, USER1, "Port %u (%" PRIu64 " Gbps) %s\n",
port,
link.link_speed / 1000,
link.link_status ? "UP" : "DOWN");
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 52e9f5f..57ad25f 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -956,14 +956,65 @@ struct cmd_config_speed_all {
cmdline_fixed_string_t value2;
 };

+static int
+parse_and_check_speed_duplex(char *value1, char *value2, uint32_t *link_speed)
+{
+
+   int duplex;
+
+   if (!strcmp(value2, "half")) {
+   duplex = 0;
+   } else if (!strcmp(value2, "full")) {
+   duplex = 1;
+   } else if (!strcmp(value2, "auto")) {
+   duplex = 1;
+   } else {
+   printf("Unknown parameter\n");
+   return -1;
+   }
+
+   if (!strcmp(value1, "10")) {
+   *link_speed = (duplex) ? ETH_LINK_SPEED_10M :
+   ETH_LINK_SPEED_10M_HD;
+   } else if (!strcmp(value1, "100")) {
+   *link_speed = (duplex) ? ETH_LINK_SPEED_100M :
+   ETH_LINK_SPEED_100M_HD;
+   } else if (!strcmp(value1, "1000")) {
+   if (!duplex)
+   goto invalid_speed_param;
+   *link_speed = ETH_LINK_SPEED_1G;
+   } else if (!strcmp(value1, "1")) {
+   if (!duplex)
+   goto invalid_speed_param;
+   *link_speed = ETH_LINK_SPEED_10G;
+   } else if (!strcmp(value1, "4")) {
+   if (!duplex)
+   goto invalid_speed_param;
+   *link_speed = ETH_LINK_SPEED_40G;
+   } else if (!strcmp(value1, "auto")) {
+   if (!duplex)
+   goto invalid_speed_param;
+   *link_s

[dpdk-dev] [PATCH v8 1/4] ethdev: Added ETH_SPEED_CAP bitmap for ports

2016-02-14 Thread Marc Sune
Added constants and bitmap to struct rte_eth_dev_info to be used by PMDs.

Signed-off-by: Marc Sune 
---
 lib/librte_ether/rte_ethdev.h | 24 
 1 file changed, 24 insertions(+)

diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 16da821..83ddbb7 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -824,6 +824,29 @@ struct rte_eth_conf {
 #define DEV_TX_OFFLOAD_OUTER_IPV4_CKSUM 0x0080 /**< Used for tunneling 
packet. */
 #define DEV_TX_OFFLOAD_QINQ_INSERT 0x0100

+/**
+ * Device supported speeds
+ */
+#define ETH_SPEED_CAP_NOT_PHY  (0)  /*< No phy media > */
+#define ETH_SPEED_CAP_10M_HD   (1 << 0)  /*< 10 Mbps half-duplex> */
+#define ETH_SPEED_CAP_10M_FD   (1 << 1)  /*< 10 Mbps full-duplex> */
+#define ETH_SPEED_CAP_100M_HD  (1 << 2)  /*< 100 Mbps half-duplex> */
+#define ETH_SPEED_CAP_100M_FD  (1 << 3)  /*< 100 Mbps full-duplex> */
+#define ETH_SPEED_CAP_1G   (1 << 4)  /*< 1 Gbps > */
+#define ETH_SPEED_CAP_2_5G (1 << 5)  /*< 2.5 Gbps > */
+#define ETH_SPEED_CAP_5G   (1 << 6)  /*< 5 Gbps > */
+#define ETH_SPEED_CAP_10G  (1 << 7)  /*< 10 Mbps > */
+#define ETH_SPEED_CAP_20G  (1 << 8)  /*< 20 Gbps > */
+#define ETH_SPEED_CAP_25G  (1 << 9)  /*< 25 Gbps > */
+#define ETH_SPEED_CAP_40G  (1 << 10)  /*< 40 Gbps > */
+#define ETH_SPEED_CAP_50G  (1 << 11)  /*< 50 Gbps > */
+#define ETH_SPEED_CAP_56G  (1 << 12)  /*< 56 Gbps > */
+#define ETH_SPEED_CAP_100G (1 << 13)  /*< 100 Gbps > */
+
+
+/**
+ * Ethernet device information
+ */
 struct rte_eth_dev_info {
struct rte_pci_device *pci_dev; /**< Device PCI information. */
const char *driver_name; /**< Device Driver name. */
@@ -852,6 +875,7 @@ struct rte_eth_dev_info {
uint16_t vmdq_pool_base;  /**< First ID of VMDQ pools. */
struct rte_eth_desc_lim rx_desc_lim;  /**< RX descriptors limits */
struct rte_eth_desc_lim tx_desc_lim;  /**< TX descriptors limits */
+   uint32_t speed_capa;  /**< Supported speeds bitmap (ETH_SPEED_CAP_). */
 };

 /**
-- 
2.1.4



[dpdk-dev] [PATCH v8 0/4] ethdev: add speed capabilities and refactor link API

2016-02-14 Thread 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 could 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.html

However, i) doing string comparisons is annoying, and can silently
break existing applications if PMDs change their names ii) it does not
provide all the supported capabilities of the ethdev iii) for some drivers it
is impossible determine correctly the (max) speed by the application
(e.g. in i40, distinguish between XL710 and X710).

In addition, the link APIs do not allow to define a set of advertised link
speeds for autonegociation.

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).

WARNING: this patch series, specifically 3/4, is NOT tested for most of the
PMDs, due to the lack of hardware. Only generic EM is tested (VM). Reviewing
and testing required by PMD maintainers.

* * * * *

v2: rebase, converted speed_capa into 32 bits bitmap, fixed alignment
(checkpatch).

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.

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.

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.

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.

v7: Rebased to current HEAD. Moved documentation to v2.3. Still needs testing
from PMD maintainers.

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.

Marc Sune (4):
  ethdev: Added ETH_SPEED_CAP bitmap for ports
  ethdev: Fill speed capability bitmaps in the PMDs
  ethdev: redesign link speed config API
  doc: update with link changes

 app/test-pipeline/init.c  |   2 +-
 app/test-pmd/cmdline.c| 124 +++---
 app/test-pmd/config.c |   4 +-
 app/test/virtual_pmd.c|   4 +-
 doc/guides/rel_notes/release_2_3.rst  | 102 
 drivers/net/af_packet/rte_eth_af_packet.c |   5 +-
 drivers/net/bnx2x/bnx2x_ethdev.c  |   7 +-
 drivers/net/bonding/rte_eth_bond_8023ad.c |  14 ++--
 drivers/net/cxgbe/base/t4_hw.c|   8 +-
 drivers/net/cxgbe/cxgbe_ethdev.c  |   1 +
 drivers/net/e1000/em_ethdev.c | 112 ++-
 drivers/net/e1000/igb_ethdev.c| 107 +++---
 drivers/net/fm10k/fm10k_ethdev.c  |   6 +-
 drivers/net/i40e/i40e_ethdev.c|  78 +++
 drivers/net/i40e/i40e_ethdev_vf.c |  11 +--
 drivers/net/ixgbe/ixgbe_ethdev.c  |  80 +--
 drivers/net/mlx4/mlx4.c   |   6 ++
 drivers/net/mlx5/mlx5_ethdev.c|   5 ++
 drivers/net/mpipe/mpipe_tilegx.c  |   6 +-
 drivers/net/nfp/nfp_net.c |   4 +-
 drivers/net/null/rte_eth_null.c   |   5 +-
 drivers/net/pcap/rte_eth_pcap.c   |   9 ++-
 drivers/net/ring/rte_eth_ring.c   |   5 +-
 drivers/net/virtio/virtio_ethdev.c|   2 +-
 drivers/net/virtio/virtio_ethdev.h|   2 -
 drivers/net/vmxnet3/vmxnet3_ethdev.c  |   5 +-
 drivers/net/xenvirt/rte_eth_xenvirt.c |   5 +-
 examples/ip_pipeline/config_parse.c   |   3 +-
 lib/librte_ether/rte_ethdev.c |  49 
 lib/librte_ether/rte_ethdev.h |  97 ++-
 lib/librte_ether/rte_ether_version.map|   6 ++
 31 files changed, 573 insertions(+), 301 deletions(-)
 create mode 100644 doc/guides/rel_notes/release_2_3.rst

-- 
2.1.4



[dpdk-dev] [PATCH v7 5/5] ethdev: add rte_eth_speed_to_bm_flag() to ver. map

2016-01-29 Thread Marc Sune
Added rte_eth_speed_to_bm_flag() to DPDK2.2 version map.

Signed-off-by: Marc Sune 
---
 lib/librte_ether/rte_ether_version.map | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/lib/librte_ether/rte_ether_version.map 
b/lib/librte_ether/rte_ether_version.map
index d8db24d..2c14ad7 100644
--- a/lib/librte_ether/rte_ether_version.map
+++ b/lib/librte_ether/rte_ether_version.map
@@ -117,3 +117,9 @@ DPDK_2.2 {

local: *;
 };
+
+DPDK_2.3 {
+   global:
+
+   rte_eth_speed_to_bm_flag;
+}DPDK_2.2;
-- 
2.1.4



[dpdk-dev] [PATCH v7 4/5] doc: update with link changes

2016-01-29 Thread Marc Sune
Add new features, ABI changes and resolved issues notice for
the refactored link patch.

Signed-off-by: Marc Sune 
---
 doc/guides/rel_notes/release_2_3.rst | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/doc/guides/rel_notes/release_2_3.rst 
b/doc/guides/rel_notes/release_2_3.rst
index 99de186..b10c3bb 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -4,10 +4,28 @@ DPDK Release 2.3
 New Features
 

+* **ethdev: define a set of advertised link speeds.**
+
+  Allowing to define a set of advertised speeds for auto-negociation,
+  explicitely disable link auto-negociation (single speed) and full
+  auto-negociation.
+
+* **ethdev: add speed_cap bitmap to recover eth device link speed capabilities
+  define a set of advertised link speeds.**
+
+  ``struct rte_eth_dev_info`` has now speed_cap bitmap, which allows the
+  application to recover the supported speeds for that ethernet device.
+

 Resolved Issues
 ---

+* **ethdev: Fixed link_speed overflow in rte_eth_link for 100Gbps.**
+
+  100Gbps in Mbps (10) exceeds 16 bit max value of ``link_speed`` in
+  ``rte_eth_link``.
+
+
 EAL
 ~~~

@@ -23,6 +41,9 @@ Libraries
 Examples
 

+* New API call, rte_eth_speed_to_bm_flag(), in ethdev to map numerical speeds
+  to bitmap fields.
+

 Other
 ~
@@ -39,6 +60,11 @@ API Changes
 ABI Changes
 ---

+* The ethdev rte_eth_link and rte_eth_conf structures were changed to
+  support the new link API, as well as ETH_LINK_HALF/FULL_DUPLEX.
+
+* The ethdev rte_eth_dev_info was changed to support device speed capabilities.
+

 Shared Library Versions
 ---
-- 
2.1.4



[dpdk-dev] [PATCH v7 3/5] ethdev: redesign link speed config API

2016-01-29 Thread Marc Sune
This patch redesigns the API to set the link speed/s configure
for an ethernet port. Specifically:

- it allows to define a set of advertised speeds for
  auto-negociation.
- it allows to disable link auto-negociation (single fixed speed).
- default: auto-negociate all supported speeds.

Other changes:

* Added utility MACROs ETH_SPEED_NUM_XXX with the numeric
  values of all supported link speeds, in Mbps.
* Converted link_speed to uint32_t to accomodate 100G speeds
  (bug).
* Added autoneg flag in struct rte_eth_link to indicate if
  link speed was a result of auto-negociation or was fixed
  by configuration.
* Added utility function to convert numeric speeds to bitmap
  fields.

Signed-off-by: Marc Sune 
---
 app/test-pmd/cmdline.c | 124 +++--
 app/test/virtual_pmd.c |   4 +-
 drivers/net/af_packet/rte_eth_af_packet.c  |   5 +-
 drivers/net/bonding/rte_eth_bond_8023ad.c  |  14 ++--
 drivers/net/cxgbe/base/t4_hw.c |   8 +-
 drivers/net/e1000/base/e1000_80003es2lan.c |   6 +-
 drivers/net/e1000/base/e1000_82541.c   |   8 +-
 drivers/net/e1000/base/e1000_82543.c   |   4 +-
 drivers/net/e1000/base/e1000_82575.c   |  11 +--
 drivers/net/e1000/base/e1000_api.c |   2 +-
 drivers/net/e1000/base/e1000_api.h |   2 +-
 drivers/net/e1000/base/e1000_defines.h |   4 +-
 drivers/net/e1000/base/e1000_hw.h  |   2 +-
 drivers/net/e1000/base/e1000_ich8lan.c |   7 +-
 drivers/net/e1000/base/e1000_mac.c |   9 ++-
 drivers/net/e1000/base/e1000_mac.h |   6 +-
 drivers/net/e1000/base/e1000_vf.c  |   4 +-
 drivers/net/e1000/base/e1000_vf.h  |   2 +-
 drivers/net/e1000/em_ethdev.c  | 113 +-
 drivers/net/e1000/igb_ethdev.c | 108 +
 drivers/net/fm10k/fm10k_ethdev.c   |   8 +-
 drivers/net/i40e/i40e_ethdev.c |  73 -
 drivers/net/i40e/i40e_ethdev_vf.c  |  11 +--
 drivers/net/ixgbe/ixgbe_ethdev.c   |  78 --
 drivers/net/mlx4/mlx4.c|   2 +
 drivers/net/mpipe/mpipe_tilegx.c   |   6 +-
 drivers/net/null/rte_eth_null.c|   5 +-
 drivers/net/pcap/rte_eth_pcap.c|   9 ++-
 drivers/net/ring/rte_eth_ring.c|   5 +-
 drivers/net/virtio/virtio_ethdev.c |   2 +-
 drivers/net/virtio/virtio_ethdev.h |   2 -
 drivers/net/vmxnet3/vmxnet3_ethdev.c   |   5 +-
 drivers/net/xenvirt/rte_eth_xenvirt.c  |   5 +-
 examples/ip_pipeline/config_parse.c|   3 +-
 lib/librte_ether/rte_ethdev.c  |  49 
 lib/librte_ether/rte_ethdev.h  | 113 --
 36 files changed, 454 insertions(+), 365 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 6d28c1b..00571bc 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -956,14 +956,65 @@ struct cmd_config_speed_all {
cmdline_fixed_string_t value2;
 };

+static int
+parse_and_check_speed_duplex(char *value1, char *value2, uint32_t *link_speed)
+{
+
+   int duplex;
+
+   if (!strcmp(value2, "half")) {
+   duplex = 0;
+   } else if (!strcmp(value2, "full")) {
+   duplex = 1;
+   } else if (!strcmp(value2, "auto")) {
+   duplex = 1;
+   } else {
+   printf("Unknown parameter\n");
+   return -1;
+   }
+
+   if (!strcmp(value1, "10")) {
+   *link_speed = (duplex) ? ETH_LINK_SPEED_10M :
+   ETH_LINK_SPEED_10M_HD;
+   } else if (!strcmp(value1, "100")) {
+   *link_speed = (duplex) ? ETH_LINK_SPEED_100M :
+   ETH_LINK_SPEED_100M_HD;
+   } else if (!strcmp(value1, "1000")) {
+   if (!duplex)
+   goto invalid_speed_param;
+   *link_speed = ETH_LINK_SPEED_1G;
+   } else if (!strcmp(value1, "1")) {
+   if (!duplex)
+   goto invalid_speed_param;
+   *link_speed = ETH_LINK_SPEED_10G;
+   } else if (!strcmp(value1, "4")) {
+   if (!duplex)
+   goto invalid_speed_param;
+   *link_speed = ETH_LINK_SPEED_40G;
+   } else if (!strcmp(value1, "auto")) {
+   if (!duplex)
+   goto invalid_speed_param;
+   *link_speed = ETH_LINK_SPEED_AUTONEG;
+   } else {
+   printf("Unknown parameter\n");
+   return -1;
+   }
+
+   return 0;
+
+invalid_speed_param:
+
+   printf("Invalid speed parameter\n");
+   return -1;
+}
+
 static void
 cmd_config_speed_all_parsed(void *parsed_result,
  

[dpdk-dev] [PATCH v7 2/5] ethdev: Fill speed capability bitmaps in the PMDs

2016-01-29 Thread Marc Sune
Added speed capabilities to all pmds supporting physical NICs:

* e1000
* ixgbe
* i40
* mlx4
* fm10k

Signed-off-by: Marc Sune 
---
 drivers/net/e1000/em_ethdev.c|  6 ++
 drivers/net/e1000/igb_ethdev.c   |  6 ++
 drivers/net/fm10k/fm10k_ethdev.c |  4 
 drivers/net/i40e/i40e_ethdev.c   |  9 +
 drivers/net/ixgbe/ixgbe_ethdev.c | 10 ++
 drivers/net/mlx4/mlx4.c  |  4 
 6 files changed, 39 insertions(+)

diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index 66e8993..fd48bbf 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -1023,6 +1023,12 @@ eth_em_infos_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
.nb_min = E1000_MIN_RING_DESC,
.nb_align = EM_TXD_ALIGN,
};
+
+   dev_info->speed_capa = ETH_SPEED_CAP_10M_HD |
+   ETH_SPEED_CAP_10M_FD |
+   ETH_SPEED_CAP_100M_HD |
+   ETH_SPEED_CAP_100M_FD |
+   ETH_SPEED_CAP_1G;
 }

 /* return 0 means link status changed, -1 means not changed */
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index d1bbcda..9c8dffa 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -1908,6 +1908,12 @@ eth_igb_infos_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)

dev_info->rx_desc_lim = rx_desc_lim;
dev_info->tx_desc_lim = tx_desc_lim;
+
+   dev_info->speed_capa = ETH_SPEED_CAP_10M_HD |
+   ETH_SPEED_CAP_10M_FD |
+   ETH_SPEED_CAP_100M_HD |
+   ETH_SPEED_CAP_100M_FD |
+   ETH_SPEED_CAP_1G;
 }

 static void
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index e4aed94..aeb2962 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -1333,6 +1333,10 @@ fm10k_dev_infos_get(struct rte_eth_dev *dev,
.nb_min = FM10K_MIN_TX_DESC,
.nb_align = FM10K_MULT_TX_DESC,
};
+
+   dev_info->speed_capa = ETH_SPEED_CAP_1G | ETH_SPEED_CAP_2_5G |
+   ETH_SPEED_CAP_10G | ETH_SPEED_CAP_25G |
+   ETH_SPEED_CAP_40G | ETH_SPEED_CAP_100G;
 }

 static int
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index bf6220d..d242973 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -2233,6 +2233,7 @@ static void
 i40e_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
 {
struct i40e_pf *pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
+   struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
struct i40e_vsi *vsi = pf->main_vsi;

dev_info->max_rx_queues = vsi->nb_qps;
@@ -2304,6 +2305,14 @@ i40e_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
dev_info->max_rx_queues += dev_info->vmdq_queue_num;
dev_info->max_tx_queues += dev_info->vmdq_queue_num;
}
+
+   if (i40e_is_40G_device(hw->device_id))
+   /* For XL710 */
+   dev_info->speed_capa = ETH_SPEED_CAP_1G | ETH_SPEED_CAP_10G;
+   else
+   /* For X710 */
+   dev_info->speed_capa = ETH_SPEED_CAP_10G | ETH_SPEED_CAP_40G;
+
 }

 static int
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 4c4c6df..4e3ab3d 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -2827,6 +2827,16 @@ ixgbe_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
dev_info->hash_key_size = IXGBE_HKEY_MAX_INDEX * sizeof(uint32_t);
dev_info->reta_size = ixgbe_reta_size_get(hw->mac.type);
dev_info->flow_type_rss_offloads = IXGBE_RSS_OFFLOAD_ALL;
+
+   dev_info->speed_capa = ETH_SPEED_CAP_1G | ETH_SPEED_CAP_10G;
+
+   if (hw->mac.type == ixgbe_mac_X540 ||
+   hw->mac.type == ixgbe_mac_X540_vf ||
+   hw->mac.type == ixgbe_mac_X550 ||
+   hw->mac.type == ixgbe_mac_X550_vf)
+
+   dev_info->speed_capa |= ETH_SPEED_CAP_100M_FD /*|
+   ETH_SPEED_CAP_100M_HD*/;
 }

 static void
diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index 207bfe2..1f3ed59 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -4265,6 +4265,10 @@ mlx4_dev_infos_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *info)
 0);
if (priv_get_ifname(priv, ) == 0)
info->if_index =

[dpdk-dev] [PATCH v7 1/5] ethdev: Added ETH_SPEED_CAP bitmap for ports

2016-01-29 Thread Marc Sune
Added constants and bitmap to struct rte_eth_dev_info to be used by PMDs.

Signed-off-by: Marc Sune 
---
 lib/librte_ether/rte_ethdev.h | 24 
 1 file changed, 24 insertions(+)

diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 8710dd7..dbc1599 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -824,6 +824,29 @@ struct rte_eth_conf {
 #define DEV_TX_OFFLOAD_OUTER_IPV4_CKSUM 0x0080 /**< Used for tunneling 
packet. */
 #define DEV_TX_OFFLOAD_QINQ_INSERT 0x0100

+/**
+ * Device supported speeds
+ */
+#define ETH_SPEED_CAP_NOT_PHY  (0)  /*< No phy media > */
+#define ETH_SPEED_CAP_10M_HD   (1 << 0)  /*< 10 Mbps half-duplex> */
+#define ETH_SPEED_CAP_10M_FD   (1 << 1)  /*< 10 Mbps full-duplex> */
+#define ETH_SPEED_CAP_100M_HD  (1 << 2)  /*< 100 Mbps half-duplex> */
+#define ETH_SPEED_CAP_100M_FD  (1 << 3)  /*< 100 Mbps full-duplex> */
+#define ETH_SPEED_CAP_1G   (1 << 4)  /*< 1 Gbps > */
+#define ETH_SPEED_CAP_2_5G (1 << 5)  /*< 2.5 Gbps > */
+#define ETH_SPEED_CAP_5G   (1 << 6)  /*< 5 Gbps > */
+#define ETH_SPEED_CAP_10G  (1 << 7)  /*< 10 Mbps > */
+#define ETH_SPEED_CAP_20G  (1 << 8)  /*< 20 Gbps > */
+#define ETH_SPEED_CAP_25G  (1 << 9)  /*< 25 Gbps > */
+#define ETH_SPEED_CAP_40G  (1 << 10)  /*< 40 Gbps > */
+#define ETH_SPEED_CAP_50G  (1 << 11)  /*< 50 Gbps > */
+#define ETH_SPEED_CAP_56G  (1 << 12)  /*< 56 Gbps > */
+#define ETH_SPEED_CAP_100G (1 << 13)  /*< 100 Gbps > */
+
+
+/**
+ * Ethernet device information
+ */
 struct rte_eth_dev_info {
struct rte_pci_device *pci_dev; /**< Device PCI information. */
const char *driver_name; /**< Device Driver name. */
@@ -852,6 +875,7 @@ struct rte_eth_dev_info {
uint16_t vmdq_pool_base;  /**< First ID of VMDQ pools. */
struct rte_eth_desc_lim rx_desc_lim;  /**< RX descriptors limits */
struct rte_eth_desc_lim tx_desc_lim;  /**< TX descriptors limits */
+   uint32_t speed_capa;  /**< Supported speeds bitmap (ETH_SPEED_CAP_). */
 };

 /**
-- 
2.1.4



[dpdk-dev] [PATCH v7 0/5] ethdev: add speed capabilities and refactor link API

2016-01-29 Thread 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 could 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.html

However, i) doing string comparisons is annoying, and can silently
break existing applications if PMDs change their names ii) it does not
provide all the supported capabilities of the ethdev iii) for some drivers it
is impossible determine correctly the (max) speed by the application
(e.g. in i40, distinguish between XL710 and X710).

In addition, the link APIs do not allow to define a set of advertised link
speeds for autonegociation.

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).

WARNING: this patch series, specifically 3/4, is NOT tested for most of the
PMDs, due to the lack of hardware. Only generic EM is tested (VM). Reviewing
and testing required by PMD maintainers.

* * * * *

v2: rebase, converted speed_capa into 32 bits bitmap, fixed alignment
(checkpatch).

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.

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.

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.

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.

v7: Rebased to current HEAD. Moved documentation to v2.3. Still needs testing
from PMD maintainers.

Marc Sune (5):
  ethdev: Added ETH_SPEED_CAP bitmap for ports
  ethdev: Fill speed capability bitmaps in the PMDs
  ethdev: redesign link speed config API
  doc: update with link changes
  ethdev: add rte_eth_speed_to_bm_flag() to ver. map

 app/test-pmd/cmdline.c | 124 +++--
 app/test/virtual_pmd.c |   4 +-
 doc/guides/rel_notes/release_2_2.rst   |  23 ++
 drivers/net/af_packet/rte_eth_af_packet.c  |   5 +-
 drivers/net/bonding/rte_eth_bond_8023ad.c  |  14 ++--
 drivers/net/cxgbe/base/t4_hw.c |   8 +-
 drivers/net/e1000/base/e1000_80003es2lan.c |   6 +-
 drivers/net/e1000/base/e1000_82541.c   |   8 +-
 drivers/net/e1000/base/e1000_82543.c   |   4 +-
 drivers/net/e1000/base/e1000_82575.c   |  11 +--
 drivers/net/e1000/base/e1000_api.c |   2 +-
 drivers/net/e1000/base/e1000_api.h |   2 +-
 drivers/net/e1000/base/e1000_defines.h |   4 +-
 drivers/net/e1000/base/e1000_hw.h  |   2 +-
 drivers/net/e1000/base/e1000_ich8lan.c |   4 +-
 drivers/net/e1000/base/e1000_mac.c |   9 ++-
 drivers/net/e1000/base/e1000_mac.h |   6 +-
 drivers/net/e1000/base/e1000_vf.c  |   4 +-
 drivers/net/e1000/base/e1000_vf.h  |   2 +-
 drivers/net/e1000/em_ethdev.c  | 109 -
 drivers/net/e1000/igb_ethdev.c | 104 +---
 drivers/net/fm10k/fm10k_ethdev.c   |   5 +-
 drivers/net/i40e/i40e_ethdev.c |  78 ++
 drivers/net/i40e/i40e_ethdev_vf.c  |  11 +--
 drivers/net/ixgbe/ixgbe_ethdev.c   |  74 -
 drivers/net/mlx4/mlx4.c|   6 ++
 drivers/net/mpipe/mpipe_tilegx.c   |   6 +-
 drivers/net/null/rte_eth_null.c|   5 +-
 drivers/net/pcap/rte_eth_pcap.c|   9 ++-
 drivers/net/ring/rte_eth_ring.c|   5 +-
 drivers/net/virtio/virtio_ethdev.c |   2 +-
 drivers/net/virtio/virtio_ethdev.h |   2 -
 drivers/net/vmxnet3/vmxnet3_ethdev.c   |   5 +-
 drivers/net/xenvirt/rte_eth_xenvirt.c  |   5 +-
 examples/ip_pipeline/config_parse.c|   3 +-
 lib/librte_ether/rte_ethdev.c  |  49 
 lib/librte_ether/rte_ethdev.h  |  97 +-
 lib/librte_ether/rte_ether_version.map |   6 ++
 38 files changed, 501 insertions(+), 322 deletions(-)

-- 
2.1.4



[dpdk-dev] [PATCH v6 0/5] ethdev: add speed capabilities and refactor link API

2015-12-16 Thread Marc Sune
2015-10-25 22:59 GMT+01: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 could 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.html
>
> However, i) doing string comparisons is annoying, and can silently
> break existing applications if PMDs change their names ii) it does not
> provide all the supported capabilities of the ethdev iii) for some drivers
> it
> is impossible determine correctly the (max) speed by the application
> (e.g. in i40, distinguish between XL710 and X710).
>
> In addition, the link APIs do not allow to define a set of advertised link
> speeds for autonegociation.
>
> 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).
>
> WARNING: this patch series, specifically 3/4, is NOT tested for most of the
> PMDs, due to the lack of hardware. Only generic EM is tested (VM).
> Minor bugs expected.
>

I will respin this patch to current HEAD targeting 2.3, but note that
testing of PMDs other than i40 and e1000 (82540Em) is necessary for this
patch to be merged.

I do not have all the HW to test it, so I would like to ask for some help
here. Some (more) peer reviews would also help.

Regards
marc


>
> * * * * *
>
> v2: rebase, converted speed_capa into 32 bits bitmap, fixed alignment
> (checkpatch).
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Marc Sune (5):
>   ethdev: Added ETH_SPEED_CAP bitmap for ports
>   ethdev: Fill speed capability bitmaps in the PMDs
>   ethdev: redesign link speed config API
>   doc: update with link changes
>   ethdev: add rte_eth_speed_to_bm_flag() to ver. map
>
>  app/test-pmd/cmdline.c | 124
> +++--
>  app/test/virtual_pmd.c |   4 +-
>  doc/guides/rel_notes/release_2_2.rst   |  23 ++
>  drivers/net/af_packet/rte_eth_af_packet.c  |   5 +-
>  drivers/net/bonding/rte_eth_bond_8023ad.c  |  14 ++--
>  drivers/net/cxgbe/base/t4_hw.c |   8 +-
>  drivers/net/e1000/base/e1000_80003es2lan.c |   6 +-
>  drivers/net/e1000/base/e1000_82541.c   |   8 +-
>  drivers/net/e1000/base/e1000_82543.c   |   4 +-
>  drivers/net/e1000/base/e1000_82575.c   |  11 +--
>  drivers/net/e1000/base/e1000_api.c |   2 +-
>  drivers/net/e1000/base/e1000_api.h |   2 +-
>  drivers/net/e1000/base/e1000_defines.h |   4 +-
>  drivers/net/e1000/base/e1000_hw.h  |   2 +-
>  drivers/net/e1000/base/e1000_ich8lan.c |   4 +-
>  drivers/net/e1000/base/e1000_mac.c |   9 ++-
>  drivers/net/e1000/base/e1000_mac.h |   6 +-
>  drivers/net/e1000/base/e1000_vf.c  |   4 +-
>  drivers/net/e1000/base/e1000_vf.h  |   2 +-
>  drivers/net/e1000/em_ethdev.c  | 109 -
>  drivers/net/e1000/igb_ethdev.c | 104 +---
>  drivers/net/fm10k/fm10k_ethdev.c   |   5 +-
>  drivers/net/i40e/i40e_ethdev.c |  78 ++
>  drivers/net/i40e/i40e_ethdev_vf.c  |  11 +--
>  drivers/net/ixgbe/ixgbe_ethdev.c   |  74 -
>  drivers/net/mlx4/mlx4.c|   6 ++
>  drivers/net/mpipe/mpipe_tilegx.c   |   6 +-
>  drivers/net/null/rte_eth_null.c|   5 +-
>  drivers/net/pcap/rte_eth_pcap.c|   9 ++-
>  drivers/net/ring/rte_eth_ring.c|

[dpdk-dev] [PATCH v6 1/5] ethdev: Added ETH_SPEED_CAP bitmap for ports

2015-11-19 Thread Marc Sune
Hi Thomas,

2015-11-01 23:11 GMT+01:00 Thomas Monjalon :

> 2015-10-25 22:59, Marc Sune:
> > +#define ETH_SPEED_CAP_NOT_PHY(0)  /*< No phy media > */
> > +#define ETH_SPEED_CAP_10M_HD (1 << 0)  /*< 10 Mbps half-duplex> */
> > +#define ETH_SPEED_CAP_10M_FD (1 << 1)  /*< 10 Mbps full-duplex> */
> > +#define ETH_SPEED_CAP_100M_HD(1 << 2)  /*< 100 Mbps
> half-duplex> */
> > +#define ETH_SPEED_CAP_100M_FD(1 << 3)  /*< 100 Mbps
> full-duplex> */
> > +#define ETH_SPEED_CAP_1G (1 << 4)  /*< 1 Gbps > */
> > +#define ETH_SPEED_CAP_2_5G   (1 << 5)  /*< 2.5 Gbps > */
> > +#define ETH_SPEED_CAP_5G (1 << 6)  /*< 5 Gbps > */
> > +#define ETH_SPEED_CAP_10G(1 << 7)  /*< 10 Mbps > */
> > +#define ETH_SPEED_CAP_20G(1 << 8)  /*< 20 Gbps > */
> > +#define ETH_SPEED_CAP_25G(1 << 9)  /*< 25 Gbps > */
> > +#define ETH_SPEED_CAP_40G(1 << 10)  /*< 40 Gbps > */
> > +#define ETH_SPEED_CAP_50G(1 << 11)  /*< 50 Gbps > */
> > +#define ETH_SPEED_CAP_56G(1 << 12)  /*< 56 Gbps > */
> > +#define ETH_SPEED_CAP_100G   (1 << 13)  /*< 100 Gbps > */
>
> In the patch 3, you rename this flags. It would be easier to understand if
> the right names were used in the first patch.
>
> > @@ -837,6 +860,7 @@ struct rte_eth_dev_info {
> >   uint16_t vmdq_queue_base; /**< First queue ID for VMDQ pools. */
> >   uint16_t vmdq_queue_num;  /**< Queue number for VMDQ pools. */
> >   uint16_t vmdq_pool_base;  /**< First ID of VMDQ pools. */
> > + uint32_t speed_capa;  /**< Supported speeds bitmap
> (ETH_SPEED_CAP_). */
>
> When renaming ETH_SPEED_CAP, this line is not changed later.
>

This is made in purpose.

In patch 3/5 the bitmap speeds are renamed to ETH_LINK_SPEED_XXX and
numeric values are moved ETH_SPEED_NUM_XXX, to make clear the difference. I
cannot, in this commit, rename them directly to ETH_LINK_SPEED_XXX since
they would collide with the current numeric speeds.

Thanks
Marc


[dpdk-dev] [PATCH v6 3/5] ethdev: redesign link speed config API

2015-11-18 Thread Marc Sune
Hi Thomas,

2015-11-01 23:16 GMT+01:00 Thomas Monjalon :

> 2015-10-25 22:59, Marc Sune:
> > This patch redesigns the API to set the link speed/s configure
> > for an ethernet port. Specifically:
> >
> > - it allows to define a set of advertised speeds for
> >   auto-negociation.
> > - it allows to disable link auto-negociation (single fixed speed).
> > - default: auto-negociate all supported speeds.
> >
> > Other changes:
> >
> > * Added utility MACROs ETH_SPEED_NUM_XXX with the numeric
> >   values of all supported link speeds, in Mbps.
> > * Converted link_speed to uint32_t to accomodate 100G speeds
> >   (bug).
> > * Added autoneg flag in struct rte_eth_link to indicate if
> >   link speed was a result of auto-negociation or was fixed
> >   by configuration.
> > * Added utility function to convert numeric speeds to bitmap
> >   fields.
>
> Having it split in several commits may help to understand the changes.
>

Apologies for the late response... crazy days.

At least first and last point in the enumeration do not make sense alone. I
can split the link_speed bug for 100G in another patch if you consider is
necessary for the series to be merged in.


> And it must be explained in the release notes in the "API changes".
>

Patch 4/5 in the series attempts to cover this:

http://dpdk.org/dev/patchwork/patch/7996/

Isn't it enough?

Marc


[dpdk-dev] [PATCH v6 3/5] ethdev: redesign link speed config API

2015-10-26 Thread Marc Sune
While testing this patch with some XL710, it seems even with current HEAD,
setting link speed into dev_conf to 10G does not work, it always takes
autoneg with all speeds.

Besides, this patch in particular should be tested for the rest of drivers
which I don't have HW for.

Regards
marc

2015-10-25 22:59 GMT+01:00 Marc Sune :

> This patch redesigns the API to set the link speed/s configure
> for an ethernet port. Specifically:
>
> - it allows to define a set of advertised speeds for
>   auto-negociation.
> - it allows to disable link auto-negociation (single fixed speed).
> - default: auto-negociate all supported speeds.
>
> Other changes:
>
> * Added utility MACROs ETH_SPEED_NUM_XXX with the numeric
>   values of all supported link speeds, in Mbps.
> * Converted link_speed to uint32_t to accomodate 100G speeds
>   (bug).
> * Added autoneg flag in struct rte_eth_link to indicate if
>   link speed was a result of auto-negociation or was fixed
>   by configuration.
> * Added utility function to convert numeric speeds to bitmap
>   fields.
>
> Signed-off-by: Marc Sune 
> ---
>  app/test-pmd/cmdline.c | 124
> +++--
>  app/test/virtual_pmd.c |   4 +-
>  drivers/net/af_packet/rte_eth_af_packet.c  |   5 +-
>  drivers/net/bonding/rte_eth_bond_8023ad.c  |  14 ++--
>  drivers/net/cxgbe/base/t4_hw.c |   8 +-
>  drivers/net/e1000/base/e1000_80003es2lan.c |   6 +-
>  drivers/net/e1000/base/e1000_82541.c   |   8 +-
>  drivers/net/e1000/base/e1000_82543.c   |   4 +-
>  drivers/net/e1000/base/e1000_82575.c   |  11 +--
>  drivers/net/e1000/base/e1000_api.c |   2 +-
>  drivers/net/e1000/base/e1000_api.h |   2 +-
>  drivers/net/e1000/base/e1000_defines.h |   4 +-
>  drivers/net/e1000/base/e1000_hw.h  |   2 +-
>  drivers/net/e1000/base/e1000_ich8lan.c |   4 +-
>  drivers/net/e1000/base/e1000_mac.c |   9 ++-
>  drivers/net/e1000/base/e1000_mac.h |   6 +-
>  drivers/net/e1000/base/e1000_vf.c  |   4 +-
>  drivers/net/e1000/base/e1000_vf.h  |   2 +-
>  drivers/net/e1000/em_ethdev.c  | 113
> +-
>  drivers/net/e1000/igb_ethdev.c | 108 +
>  drivers/net/fm10k/fm10k_ethdev.c   |   8 +-
>  drivers/net/i40e/i40e_ethdev.c |  73 -
>  drivers/net/i40e/i40e_ethdev_vf.c  |  11 +--
>  drivers/net/ixgbe/ixgbe_ethdev.c   |  72 -
>  drivers/net/mlx4/mlx4.c|   2 +
>  drivers/net/mpipe/mpipe_tilegx.c   |   6 +-
>  drivers/net/null/rte_eth_null.c|   5 +-
>  drivers/net/pcap/rte_eth_pcap.c|   9 ++-
>  drivers/net/ring/rte_eth_ring.c|   5 +-
>  drivers/net/virtio/virtio_ethdev.c |   2 +-
>  drivers/net/virtio/virtio_ethdev.h |   2 -
>  drivers/net/vmxnet3/vmxnet3_ethdev.c   |   5 +-
>  drivers/net/xenvirt/rte_eth_xenvirt.c  |   5 +-
>  examples/ip_pipeline/config_parse.c|   3 +-
>  lib/librte_ether/rte_ethdev.c  |  49 
>  lib/librte_ether/rte_ethdev.h  | 113
> --
>  36 files changed, 449 insertions(+), 361 deletions(-)
>
> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
> index 0f8f48f..c62f5be 100644
> --- a/app/test-pmd/cmdline.c
> +++ b/app/test-pmd/cmdline.c
> @@ -897,14 +897,65 @@ struct cmd_config_speed_all {
> cmdline_fixed_string_t value2;
>  };
>
> +static int
> +parse_and_check_speed_duplex(char *value1, char *value2, uint32_t
> *link_speed)
> +{
> +
> +   int duplex;
> +
> +   if (!strcmp(value2, "half")) {
> +   duplex = 0;
> +   } else if (!strcmp(value2, "full")) {
> +   duplex = 1;
> +   } else if (!strcmp(value2, "auto")) {
> +   duplex = 1;
> +   } else {
> +   printf("Unknown parameter\n");
> +   return -1;
> +   }
> +
> +   if (!strcmp(value1, "10")) {
> +   *link_speed = (duplex) ? ETH_LINK_SPEED_10M :
> +
>  ETH_LINK_SPEED_10M_HD;
> +   } else if (!strcmp(value1, "100")) {
> +   *link_speed = (duplex) ? ETH_LINK_SPEED_100M :
> +
>  ETH_LINK_SPEED_100M_HD;
> +   } else if (!strcmp(value1, "1000")) {
> +   if (!duplex)
> +   goto invalid_speed_param;
> +   *link_speed = ETH_LINK_SPEED_1G;
> +   } else if (!strcmp(value1, "1")) {
> +   if (!duplex)
> +   goto invalid_speed_param;
>

[dpdk-dev] [PATCH v6 5/5] ethdev: add rte_eth_speed_to_bm_flag() to ver. map

2015-10-26 Thread Marc Sune
Added rte_eth_speed_to_bm_flag() to DPDK2.2 version map.

Signed-off-by: Marc Sune 
---
 lib/librte_ether/rte_ether_version.map | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/lib/librte_ether/rte_ether_version.map 
b/lib/librte_ether/rte_ether_version.map
index 8345a6c..cbfe0c8 100644
--- a/lib/librte_ether/rte_ether_version.map
+++ b/lib/librte_ether/rte_ether_version.map
@@ -127,3 +127,9 @@ DPDK_2.1 {
rte_eth_timesync_read_tx_timestamp;

 } DPDK_2.0;
+
+DPDK_2.2 {
+   global:
+
+   rte_eth_speed_to_bm_flag;
+} DPDK_2.1;
-- 
2.1.4



[dpdk-dev] [PATCH v6 4/5] doc: update with link changes

2015-10-25 Thread Marc Sune
Add new features, ABI changes and resolved issues notice for
the refactored link patch.

Signed-off-by: Marc Sune 
---
 doc/guides/rel_notes/release_2_2.rst | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/doc/guides/rel_notes/release_2_2.rst 
b/doc/guides/rel_notes/release_2_2.rst
index 5687676..e0d1741 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -4,6 +4,17 @@ DPDK Release 2.2
 New Features
 

+* **ethdev: define a set of advertised link speeds.**
+
+  Allowing to define a set of advertised speeds for auto-negociation,
+  explicitely disable link auto-negociation (single speed) and full
+  auto-negociation.
+
+* **ethdev: add speed_cap bitmap to recover eth device link speed capabilities
+  define a set of advertised link speeds.**
+
+  ``struct rte_eth_dev_info`` has now speed_cap bitmap, which allows the
+  application to recover the supported speeds for that ethernet device.

 Resolved Issues
 ---
@@ -48,6 +59,11 @@ Libraries
   Fixed issue where an incorrect Cuckoo Hash key table size could be
   calculated limiting the size to 4GB.

+* **ethdev: Fixed link_speed overflow in rte_eth_link for 100Gbps.**
+
+  100Gbps in Mbps (10) exceeds 16 bit max value of ``link_speed`` in
+  ``rte_eth_link``.
+

 Examples
 
@@ -81,6 +97,8 @@ API Changes
 * The deprecated ring PMD functions are removed:
   rte_eth_ring_pair_create() and rte_eth_ring_pair_attach().

+* New API call, rte_eth_speed_to_bm_flag(), in ethdev to map numerical speeds
+  to bitmap fields.

 ABI Changes
 ---
@@ -91,6 +109,11 @@ ABI Changes
 * The ethdev flow director entries for SCTP were changed.
   It was already done in 2.1 for CONFIG_RTE_NEXT_ABI.

+* The ethdev rte_eth_link and rte_eth_conf structures were changed to
+  support the new link API, as well as ETH_LINK_HALF/FULL_DUPLEX.
+
+* The ethdev rte_eth_dev_info was changed to support device speed capabilities.
+
 * The mbuf structure was changed to support unified packet type.
   It was already done in 2.1 for CONFIG_RTE_NEXT_ABI.

-- 
2.1.4



[dpdk-dev] [PATCH v6 3/5] ethdev: redesign link speed config API

2015-10-25 Thread Marc Sune
This patch redesigns the API to set the link speed/s configure
for an ethernet port. Specifically:

- it allows to define a set of advertised speeds for
  auto-negociation.
- it allows to disable link auto-negociation (single fixed speed).
- default: auto-negociate all supported speeds.

Other changes:

* Added utility MACROs ETH_SPEED_NUM_XXX with the numeric
  values of all supported link speeds, in Mbps.
* Converted link_speed to uint32_t to accomodate 100G speeds
  (bug).
* Added autoneg flag in struct rte_eth_link to indicate if
  link speed was a result of auto-negociation or was fixed
  by configuration.
* Added utility function to convert numeric speeds to bitmap
  fields.

Signed-off-by: Marc Sune 
---
 app/test-pmd/cmdline.c | 124 +++--
 app/test/virtual_pmd.c |   4 +-
 drivers/net/af_packet/rte_eth_af_packet.c  |   5 +-
 drivers/net/bonding/rte_eth_bond_8023ad.c  |  14 ++--
 drivers/net/cxgbe/base/t4_hw.c |   8 +-
 drivers/net/e1000/base/e1000_80003es2lan.c |   6 +-
 drivers/net/e1000/base/e1000_82541.c   |   8 +-
 drivers/net/e1000/base/e1000_82543.c   |   4 +-
 drivers/net/e1000/base/e1000_82575.c   |  11 +--
 drivers/net/e1000/base/e1000_api.c |   2 +-
 drivers/net/e1000/base/e1000_api.h |   2 +-
 drivers/net/e1000/base/e1000_defines.h |   4 +-
 drivers/net/e1000/base/e1000_hw.h  |   2 +-
 drivers/net/e1000/base/e1000_ich8lan.c |   4 +-
 drivers/net/e1000/base/e1000_mac.c |   9 ++-
 drivers/net/e1000/base/e1000_mac.h |   6 +-
 drivers/net/e1000/base/e1000_vf.c  |   4 +-
 drivers/net/e1000/base/e1000_vf.h  |   2 +-
 drivers/net/e1000/em_ethdev.c  | 113 +-
 drivers/net/e1000/igb_ethdev.c | 108 +
 drivers/net/fm10k/fm10k_ethdev.c   |   8 +-
 drivers/net/i40e/i40e_ethdev.c |  73 -
 drivers/net/i40e/i40e_ethdev_vf.c  |  11 +--
 drivers/net/ixgbe/ixgbe_ethdev.c   |  72 -
 drivers/net/mlx4/mlx4.c|   2 +
 drivers/net/mpipe/mpipe_tilegx.c   |   6 +-
 drivers/net/null/rte_eth_null.c|   5 +-
 drivers/net/pcap/rte_eth_pcap.c|   9 ++-
 drivers/net/ring/rte_eth_ring.c|   5 +-
 drivers/net/virtio/virtio_ethdev.c |   2 +-
 drivers/net/virtio/virtio_ethdev.h |   2 -
 drivers/net/vmxnet3/vmxnet3_ethdev.c   |   5 +-
 drivers/net/xenvirt/rte_eth_xenvirt.c  |   5 +-
 examples/ip_pipeline/config_parse.c|   3 +-
 lib/librte_ether/rte_ethdev.c  |  49 
 lib/librte_ether/rte_ethdev.h  | 113 --
 36 files changed, 449 insertions(+), 361 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 0f8f48f..c62f5be 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -897,14 +897,65 @@ struct cmd_config_speed_all {
cmdline_fixed_string_t value2;
 };

+static int
+parse_and_check_speed_duplex(char *value1, char *value2, uint32_t *link_speed)
+{
+
+   int duplex;
+
+   if (!strcmp(value2, "half")) {
+   duplex = 0;
+   } else if (!strcmp(value2, "full")) {
+   duplex = 1;
+   } else if (!strcmp(value2, "auto")) {
+   duplex = 1;
+   } else {
+   printf("Unknown parameter\n");
+   return -1;
+   }
+
+   if (!strcmp(value1, "10")) {
+   *link_speed = (duplex) ? ETH_LINK_SPEED_10M :
+   ETH_LINK_SPEED_10M_HD;
+   } else if (!strcmp(value1, "100")) {
+   *link_speed = (duplex) ? ETH_LINK_SPEED_100M :
+   ETH_LINK_SPEED_100M_HD;
+   } else if (!strcmp(value1, "1000")) {
+   if (!duplex)
+   goto invalid_speed_param;
+   *link_speed = ETH_LINK_SPEED_1G;
+   } else if (!strcmp(value1, "1")) {
+   if (!duplex)
+   goto invalid_speed_param;
+   *link_speed = ETH_LINK_SPEED_10G;
+   } else if (!strcmp(value1, "4")) {
+   if (!duplex)
+   goto invalid_speed_param;
+   *link_speed = ETH_LINK_SPEED_40G;
+   } else if (!strcmp(value1, "auto")) {
+   if (!duplex)
+   goto invalid_speed_param;
+   *link_speed = ETH_LINK_SPEED_AUTONEG;
+   } else {
+   printf("Unknown parameter\n");
+   return -1;
+   }
+
+   return 0;
+
+invalid_speed_param:
+
+   printf("Invalid speed parameter\n");
+   return -1;
+}
+
 static void
 cmd_config_speed_all_parsed(void *parsed_result,
  

[dpdk-dev] [PATCH v6 2/5] ethdev: Fill speed capability bitmaps in the PMDs

2015-10-25 Thread Marc Sune
Added speed capabilities to all pmds supporting physical NICs:

* e1000
* ixgbe
* i40
* mlx4
* fm10k

Signed-off-by: Marc Sune 
---
 drivers/net/e1000/em_ethdev.c|  6 ++
 drivers/net/e1000/igb_ethdev.c   |  6 ++
 drivers/net/fm10k/fm10k_ethdev.c |  3 +++
 drivers/net/i40e/i40e_ethdev.c   |  9 +
 drivers/net/ixgbe/ixgbe_ethdev.c | 10 ++
 drivers/net/mlx4/mlx4.c  |  4 
 6 files changed, 38 insertions(+)

diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index 912f5dd..72f792c 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -933,6 +933,12 @@ eth_em_infos_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)

dev_info->max_rx_queues = 1;
dev_info->max_tx_queues = 1;
+
+   dev_info->speed_capa = ETH_SPEED_CAP_10M_HD |
+   ETH_SPEED_CAP_10M_FD |
+   ETH_SPEED_CAP_100M_HD |
+   ETH_SPEED_CAP_100M_FD |
+   ETH_SPEED_CAP_1G;
 }

 /* return 0 means link status changed, -1 means not changed */
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index 848ef6e..927f5d9 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -1570,6 +1570,12 @@ eth_igb_infos_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
},
.txq_flags = 0,
};
+
+   dev_info->speed_capa = ETH_SPEED_CAP_10M_HD |
+   ETH_SPEED_CAP_10M_FD |
+   ETH_SPEED_CAP_100M_HD |
+   ETH_SPEED_CAP_100M_FD |
+   ETH_SPEED_CAP_1G;
 }

 static void
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index a69c990..ca6357c 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -964,6 +964,9 @@ fm10k_dev_infos_get(struct rte_eth_dev *dev,
ETH_TXQ_FLAGS_NOOFFLOADS,
};

+   dev_info->speed_capa = ETH_SPEED_CAP_1G | ETH_SPEED_CAP_2_5G |
+   ETH_SPEED_CAP_10G | ETH_SPEED_CAP_25G |
+   ETH_SPEED_CAP_40G | ETH_SPEED_CAP_100G;
 }

 static int
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 2dd9fdc..8a5dfbf 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -1624,6 +1624,7 @@ static void
 i40e_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
 {
struct i40e_pf *pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
+   struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
struct i40e_vsi *vsi = pf->main_vsi;

dev_info->max_rx_queues = vsi->nb_qps;
@@ -1683,6 +1684,14 @@ i40e_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
dev_info->max_rx_queues += dev_info->vmdq_queue_num;
dev_info->max_tx_queues += dev_info->vmdq_queue_num;
}
+
+   if (i40e_is_40G_device(hw->device_id))
+   /* For XL710 */
+   dev_info->speed_capa = ETH_SPEED_CAP_1G | ETH_SPEED_CAP_10G;
+   else
+   /* For X710 */
+   dev_info->speed_capa = ETH_SPEED_CAP_10G | ETH_SPEED_CAP_40G;
+
 }

 static int
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index ec2918c..3be84aa 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -2399,6 +2399,16 @@ ixgbe_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
dev_info->hash_key_size = IXGBE_HKEY_MAX_INDEX * sizeof(uint32_t);
dev_info->reta_size = ETH_RSS_RETA_SIZE_128;
dev_info->flow_type_rss_offloads = IXGBE_RSS_OFFLOAD_ALL;
+
+   dev_info->speed_capa = ETH_SPEED_CAP_1G | ETH_SPEED_CAP_10G;
+
+   if (hw->mac.type == ixgbe_mac_X540 ||
+   hw->mac.type == ixgbe_mac_X540_vf ||
+   hw->mac.type == ixgbe_mac_X550 ||
+   hw->mac.type == ixgbe_mac_X550_vf)
+
+   dev_info->speed_capa |= ETH_SPEED_CAP_100M_FD /*|
+   ETH_SPEED_CAP_100M_HD*/;
 }

 static void
diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index 2f49ed5..b45e21a 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -3847,6 +3847,10 @@ mlx4_dev_infos_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *info)
  DEV_TX_OFFLOAD_UDP_CKSUM |
  DEV_TX_OFFLOAD_TCP_CKSUM) :
 0);
+
+   info->speed_capa = ETH_SPEED_CAP_10G |ETH_SPEED_CAP_40G |
+   ETH_SPEED_CAP_56G;
+
priv_unlock(priv);
 }

-- 
2.1.4



[dpdk-dev] [PATCH v6 1/5] ethdev: Added ETH_SPEED_CAP bitmap for ports

2015-10-25 Thread Marc Sune
Added constants and bitmap to struct rte_eth_dev_info to be used by PMDs.

Signed-off-by: Marc Sune 
---
 lib/librte_ether/rte_ethdev.h | 24 
 1 file changed, 24 insertions(+)

diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 8a8c82b..951a423 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -811,6 +811,29 @@ struct rte_eth_conf {
 #define DEV_TX_OFFLOAD_OUTER_IPV4_CKSUM 0x0080 /**< Used for tunneling 
packet. */
 #define DEV_TX_OFFLOAD_QINQ_INSERT 0x0100

+/**
+ * Device supported speeds
+ */
+#define ETH_SPEED_CAP_NOT_PHY  (0)  /*< No phy media > */
+#define ETH_SPEED_CAP_10M_HD   (1 << 0)  /*< 10 Mbps half-duplex> */
+#define ETH_SPEED_CAP_10M_FD   (1 << 1)  /*< 10 Mbps full-duplex> */
+#define ETH_SPEED_CAP_100M_HD  (1 << 2)  /*< 100 Mbps half-duplex> */
+#define ETH_SPEED_CAP_100M_FD  (1 << 3)  /*< 100 Mbps full-duplex> */
+#define ETH_SPEED_CAP_1G   (1 << 4)  /*< 1 Gbps > */
+#define ETH_SPEED_CAP_2_5G (1 << 5)  /*< 2.5 Gbps > */
+#define ETH_SPEED_CAP_5G   (1 << 6)  /*< 5 Gbps > */
+#define ETH_SPEED_CAP_10G  (1 << 7)  /*< 10 Mbps > */
+#define ETH_SPEED_CAP_20G  (1 << 8)  /*< 20 Gbps > */
+#define ETH_SPEED_CAP_25G  (1 << 9)  /*< 25 Gbps > */
+#define ETH_SPEED_CAP_40G  (1 << 10)  /*< 40 Gbps > */
+#define ETH_SPEED_CAP_50G  (1 << 11)  /*< 50 Gbps > */
+#define ETH_SPEED_CAP_56G  (1 << 12)  /*< 56 Gbps > */
+#define ETH_SPEED_CAP_100G (1 << 13)  /*< 100 Gbps > */
+
+
+/**
+ * Ethernet device information
+ */
 struct rte_eth_dev_info {
struct rte_pci_device *pci_dev; /**< Device PCI information. */
const char *driver_name; /**< Device Driver name. */
@@ -837,6 +860,7 @@ struct rte_eth_dev_info {
uint16_t vmdq_queue_base; /**< First queue ID for VMDQ pools. */
uint16_t vmdq_queue_num;  /**< Queue number for VMDQ pools. */
uint16_t vmdq_pool_base;  /**< First ID of VMDQ pools. */
+   uint32_t speed_capa;  /**< Supported speeds bitmap (ETH_SPEED_CAP_). */
 };

 /** Maximum name length for extended statistics counters */
-- 
2.1.4



[dpdk-dev] [PATCH v6 0/5] ethdev: add speed capabilities and refactor link API

2015-10-25 Thread 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 could 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.html

However, i) doing string comparisons is annoying, and can silently
break existing applications if PMDs change their names ii) it does not
provide all the supported capabilities of the ethdev iii) for some drivers it
is impossible determine correctly the (max) speed by the application
(e.g. in i40, distinguish between XL710 and X710).

In addition, the link APIs do not allow to define a set of advertised link
speeds for autonegociation.

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).

WARNING: this patch series, specifically 3/4, is NOT tested for most of the
PMDs, due to the lack of hardware. Only generic EM is tested (VM).
Minor bugs expected.

* * * * *

v2: rebase, converted speed_capa into 32 bits bitmap, fixed alignment
(checkpatch).

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.

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.

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.

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.

Marc Sune (5):
  ethdev: Added ETH_SPEED_CAP bitmap for ports
  ethdev: Fill speed capability bitmaps in the PMDs
  ethdev: redesign link speed config API
  doc: update with link changes
  ethdev: add rte_eth_speed_to_bm_flag() to ver. map

 app/test-pmd/cmdline.c | 124 +++--
 app/test/virtual_pmd.c |   4 +-
 doc/guides/rel_notes/release_2_2.rst   |  23 ++
 drivers/net/af_packet/rte_eth_af_packet.c  |   5 +-
 drivers/net/bonding/rte_eth_bond_8023ad.c  |  14 ++--
 drivers/net/cxgbe/base/t4_hw.c |   8 +-
 drivers/net/e1000/base/e1000_80003es2lan.c |   6 +-
 drivers/net/e1000/base/e1000_82541.c   |   8 +-
 drivers/net/e1000/base/e1000_82543.c   |   4 +-
 drivers/net/e1000/base/e1000_82575.c   |  11 +--
 drivers/net/e1000/base/e1000_api.c |   2 +-
 drivers/net/e1000/base/e1000_api.h |   2 +-
 drivers/net/e1000/base/e1000_defines.h |   4 +-
 drivers/net/e1000/base/e1000_hw.h  |   2 +-
 drivers/net/e1000/base/e1000_ich8lan.c |   4 +-
 drivers/net/e1000/base/e1000_mac.c |   9 ++-
 drivers/net/e1000/base/e1000_mac.h |   6 +-
 drivers/net/e1000/base/e1000_vf.c  |   4 +-
 drivers/net/e1000/base/e1000_vf.h  |   2 +-
 drivers/net/e1000/em_ethdev.c  | 109 -
 drivers/net/e1000/igb_ethdev.c | 104 +---
 drivers/net/fm10k/fm10k_ethdev.c   |   5 +-
 drivers/net/i40e/i40e_ethdev.c |  78 ++
 drivers/net/i40e/i40e_ethdev_vf.c  |  11 +--
 drivers/net/ixgbe/ixgbe_ethdev.c   |  74 -
 drivers/net/mlx4/mlx4.c|   6 ++
 drivers/net/mpipe/mpipe_tilegx.c   |   6 +-
 drivers/net/null/rte_eth_null.c|   5 +-
 drivers/net/pcap/rte_eth_pcap.c|   9 ++-
 drivers/net/ring/rte_eth_ring.c|   5 +-
 drivers/net/virtio/virtio_ethdev.c |   2 +-
 drivers/net/virtio/virtio_ethdev.h |   2 -
 drivers/net/vmxnet3/vmxnet3_ethdev.c   |   5 +-
 drivers/net/xenvirt/rte_eth_xenvirt.c  |   5 +-
 examples/ip_pipeline/config_parse.c|   3 +-
 lib/librte_ether/rte_ethdev.c  |  49 
 lib/librte_ether/rte_ethdev.h  |  97 +-
 lib/librte_ether/rte_ether_version.map |   6 ++
 38 files changed, 501 insertions(+), 322 deletions(-)

-- 
2.1.4



[dpdk-dev] C++ 98/03 rte_cpuflags.h compilation broken

2015-10-25 Thread Marc Sune
During the revision of an application I maintain that is currently using
DPDK v1.7.1 and about to port it to 2.1.0, I realised that 2.1.0rc4 and
above (at least) are broken when compiling applications without C++11
support:

In file included from
/home/marc/personal/xdpd/build/src/xdpd/drivers/gnu_linux_dpdk/../../../..//libs/dpdk/build/include/rte_cpuflags.h:46:0,
 from
/home/marc/personal/xdpd/build/src/xdpd/drivers/gnu_linux_dpdk/../../../..//libs/dpdk/build/include/rte_spinlock.h:43,
 from
../../../../../../../../../src/xdpd/drivers/gnu_linux_dpdk/src/hal-imp/openflow/openflow1x/../../../pipeline-imp/packet_inline.h:26,
 from
../../../../../../../../../src/xdpd/drivers/gnu_linux_dpdk/src/hal-imp/openflow/openflow1x/../../../pipeline-imp/packet.h:14,
 from
../../../../../../../../../src/xdpd/drivers/gnu_linux_dpdk/src/hal-imp/openflow/openflow1x/of1x_driver.cc:13:
/home/marc/personal/xdpd/build/src/xdpd/drivers/gnu_linux_dpdk/../../../..//libs/dpdk/build/include/generic/rte_cpuflags.h:53:6:
error: use of enum 'rte_cpu_flag_t' without previous declaration
 enum rte_cpu_flag_t __RTE_CPUFLAG_UNDERLYING_TYPE;
  ^
/home/marc/personal/xdpd/build/src/xdpd/drivers/gnu_linux_dpdk/../../../..//libs/dpdk/build/include/generic/rte_cpuflags.h:58:6:
error: use of enum 'cpu_register_t' without previous declaration
 enum cpu_register_t __RTE_REGISTER_UNDERLYING_TYPE;
  ^
/home/marc/personal/xdpd/build/src/xdpd/drivers/gnu_linux_dpdk/../../../..//libs/dpdk/build/include/generic/rte_cpuflags.h:107:31:
error: use of enum 'rte_cpu_flag_t' without previous declaration
 rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature);
   ^
In file included from
/home/marc/personal/xdpd/build/src/xdpd/drivers/gnu_linux_dpdk/../../../..//libs/dpdk/build/include/rte_spinlock.h:43:0,
 from
../../../../../../../../../src/xdpd/drivers/gnu_linux_dpdk/src/hal-imp/openflow/openflow1x/../../../pipeline-imp/packet_inline.h:26,
 from
../../../../../../../../../src/xdpd/drivers/gnu_linux_dpdk/src/hal-imp/openflow/openflow1x/../../../pipeline-imp/packet.h:14,
 from
../../../../../../../../../src/xdpd/drivers/gnu_linux_dpdk/src/hal-imp/openflow/openflow1x/of1x_driver.cc:13:
/home/marc/personal/xdpd/build/src/xdpd/drivers/gnu_linux_dpdk/../../../..//libs/dpdk/build/include/rte_cpuflags.h:
In function 'int rte_cpu_get_flag_enabled(rte_cpu_flag_t)':
/home/marc/personal/xdpd/build/src/xdpd/drivers/gnu_linux_dpdk/../../../..//libs/dpdk/build/include/rte_cpuflags.h:278:53:
error: conflicting declaration of C function 'int
rte_cpu_get_flag_enabled(rte_cpu_flag_t)'
 rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature)
 ^
In file included from
/home/marc/personal/xdpd/build/src/xdpd/drivers/gnu_linux_dpdk/../../../..//libs/dpdk/build/include/rte_cpuflags.h:46:0,
 from
/home/marc/personal/xdpd/build/src/xdpd/drivers/gnu_linux_dpdk/../../../..//libs/dpdk/build/include/rte_spinlock.h:43,
 from
../../../../../../../../../src/xdpd/drivers/gnu_linux_dpdk/src/hal-imp/openflow/openflow1x/../../../pipeline-imp/packet_inline.h:26,
 from
../../../../../../../../../src/xdpd/drivers/gnu_linux_dpdk/src/hal-imp/openflow/openflow1x/../../../pipeline-imp/packet.h:14,
 from
../../../../../../../../../src/xdpd/drivers/gnu_linux_dpdk/src/hal-imp/openflow/openflow1x/of1x_driver.cc:13:
/home/marc/personal/xdpd/build/src/xdpd/drivers/gnu_linux_dpdk/../../../..//libs/dpdk/build/include/generic/rte_cpuflags.h:107:1:
note: previous declaration 'int rte_cpu_get_flag_enabled(int)'
 rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature);
 ^
/home/marc/personal/xdpd/build/src/xdpd/drivers/gnu_linux_dpdk/../../../..//libs/dpdk/build/include/generic/rte_cpuflags.h:
At global scope:
/home/marc/personal/xdpd/build/src/xdpd/drivers/gnu_linux_dpdk/../../../..//libs/dpdk/build/include/generic/rte_cpuflags.h:107:1:
error: 'int rte_cpu_get_flag_enabled(int)' declared 'static' but never
defined [-Werror=unused-function]

There was a commit from J. Kim:

commit 621389bbbe0860d41538aeac893b6d74e714530c
Author: Joongi Kim 
Date:   Fri Jul 3 21:51:03 2015 +0900

eal: fix C++ app build

 * Forward declaration of enum in C++ requires explicit underlying
   type definitions.

 * This fixes the issue at:
   http://dpdk.org/ml/archives/dev/2015-April/017065.html

include/generic/rte_cpuflags.h:50:6:
error: use of enum ?rte_cpu_flag_t? without previous declaration
 enum rte_cpu_flag_t;

include/generic/rte_cpuflags.h:55:6:
error: use of enum ?cpu_register_t? without previous declaration
 enum cpu_register_t;

Signed-off-by: Joongi Kim 
[Thomas: fix extended to ppc and tile]


that partially addresses the compilation of rte_cpuflags.h in C++, but only
works for C++11 and above.

A solution could be 

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

2015-10-07 Thread Marc Sune
2015-10-06 15:48 GMT+02:00 N?lio Laranjeiro :

> Hi Marc,
>
> On Sun, Oct 04, 2015 at 11:12:46PM +0200, Marc Sune wrote:
> >[...]
> >  /**
> > + * Device supported speeds bitmap flags
> > + */
> > +#define ETH_LINK_SPEED_AUTONEG   (0 << 0)  /*<
> Autonegociate (all speeds)  */
> > +#define ETH_LINK_SPEED_NO_AUTONEG(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 */
> > +#define ETH_LINK_SPEED_100M  (1 << 4)  /*< 100 Mbps full-duplex
> */
> > +#define ETH_LINK_SPEED_1G(1 << 5)  /*< 1 Gbps */
> > +#define ETH_LINK_SPEED_2_5G  (1 << 6)  /*< 2.5 Gbps */
> > +#define ETH_LINK_SPEED_5G(1 << 7)  /*< 5 Gbps */
> > +#define ETH_LINK_SPEED_10G   (1 << 8)  /*< 10 Mbps */
> > +#define ETH_LINK_SPEED_20G   (1 << 9)  /*< 20 Gbps */
> > +#define ETH_LINK_SPEED_25G   (1 << 10)  /*< 25 Gbps */
> > +#define ETH_LINK_SPEED_40G   (1 << 11)  /*< 40 Gbps */
> > +#define ETH_LINK_SPEED_50G   (1 << 12)  /*< 50 Gbps */
> > +#define ETH_LINK_SPEED_56G   (1 << 13)  /*< 56 Gbps */
> > +#define ETH_LINK_SPEED_100G  (1 << 14)  /*< 100 Gbps */
> > +
> > +/**
> > + * Ethernet numeric link speeds in Mbps
> > + */
> > +#define ETH_SPEED_NUM_NONE   0  /*< Not defined */
> > +#define ETH_SPEED_NUM_10M10 /*< 10 Mbps */
> > +#define ETH_SPEED_NUM_100M   100/*< 100 Mbps */
> > +#define ETH_SPEED_NUM_1G 1000   /*< 1 Gbps */
> > +#define ETH_SPEED_NUM_2_5G   2500   /*< 2.5 Gbps */
> > +#define ETH_SPEED_NUM_5G 5000   /*< 5 Gbps */
> > +#define ETH_SPEED_NUM_10G1  /*< 10 Mbps */
> > +#define ETH_SPEED_NUM_20G2  /*< 20 Gbps */
> > +#define ETH_SPEED_NUM_25G25000  /*< 25 Gbps */
> > +#define ETH_SPEED_NUM_40G4  /*< 40 Gbps */
> > +#define ETH_SPEED_NUM_50G5  /*< 50 Gbps */
> > +#define ETH_SPEED_NUM_56G56000  /*< 56 Gbps */
> > +#define ETH_SPEED_NUM_100G   10 /*< 100 Gbps */
> > +
> > +/**
> >   * A structure used to retrieve link-level information of an Ethernet
> port.
> >   */
> >  struct rte_eth_link {
> > - uint16_t link_speed;  /**< ETH_LINK_SPEED_[10, 100, 1000,
> 1] */
> > - uint16_t link_duplex; /**< ETH_LINK_[HALF_DUPLEX, FULL_DUPLEX]
> */
> > - uint8_t  link_status : 1; /**< 1 -> link up, 0 -> link down */
> > -}__attribute__((aligned(8))); /**< aligned for atomic64 read/write
> */
> > -
> > -#define ETH_LINK_SPEED_AUTONEG  0   /**< Auto-negotiate link speed.
> */
> > -#define ETH_LINK_SPEED_10   10  /**< 10 megabits/second. */
> > -#define ETH_LINK_SPEED_100  100 /**< 100 megabits/second. */
> > -#define ETH_LINK_SPEED_1000 1000/**< 1 gigabits/second. */
> > -#define ETH_LINK_SPEED_11   /**< 10 gigabits/second. */
> > -#define ETH_LINK_SPEED_10G  1   /**< alias of 10
> gigabits/second. */
> > -#define ETH_LINK_SPEED_20G  2   /**< 20 gigabits/second. */
> > -#define ETH_LINK_SPEED_40G  4   /**< 40 gigabits/second. */
> > + uint32_t link_speed;   /**< Link speed (ETH_SPEED_NUM_) */
> > + uint16_t link_duplex;  /**< 1 -> full duplex, 0 -> half duplex
> */
> > + uint8_t link_autoneg : 1;  /**< 1 -> link speed has been autoneg */
> > + uint8_t link_status  : 1;  /**< 1 -> link up, 0 -> link down */
> > +} __attribute__((aligned(8)));  /**< aligned for atomic64
> read/write */
> >[...]
>
> Pretty good.  One question, why did you not merge link_duplex, autoneg,
> and status like:
>
> struct rte_eth_link {
> uint32_t link_speed;
> uint32_t link_duplex:1;
> uint32_t link_autoneg:1;
> uint32_t link_status:1;
> };
>
> is it really useful to keep a uint16_t for the duplex alone?
>

You are right, I've missed this one. Will be fixed in v6.


>
> Another point, the comment about link_duplex field should point to the
> defines you have changed i.e. ETH_LINK_HALF_DUPLEX, ETH_LINK_FULL_DUPLEX.
>

Right. Will do that as part of v6 + comments of Neil.

Marc


> Regards,
>
> --
> N?lio Laranjeiro
> 6WIND
>


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

2015-10-07 Thread Marc Sune
2015-10-05 12:59 GMT+02:00 Neil Horman :

> On Sun, Oct 04, 2015 at 11:12:46PM +0200, Marc Sune wrote:
> > This patch redesigns the API to set the link speed/s configure
> > for an ethernet port. Specifically:
> >
> > - it allows to define a set of advertised speeds for
> >   auto-negociation.
> > - it allows to disable link auto-negociation (single fixed speed).
> > - default: auto-negociate all supported speeds.
> >
> > Other changes:
> >
> > * Added utility MACROs ETH_SPEED_NUM_XXX with the numeric
> >   values of all supported link speeds, in Mbps.
> > * Converted link_speed to uint32_t to accomodate 100G speeds
> >   (bug).
> > * Added autoneg flag in struct rte_eth_link to indicate if
> >   link speed was a result of auto-negociation or was fixed
> >   by configuration.
> > * Added utility function to convert numeric speeds to bitmap
> >   fields.
> > * Adapted testpmd to the new link API.
> >
> > Signed-off-by: Marc Sune 
> >
> > diff --git a/lib/librte_ether/rte_ethdev.c
> b/lib/librte_ether/rte_ethdev.c
> > index f593f6e..29b2960 100644
> > --- a/lib/librte_ether/rte_ethdev.c
> > +++ b/lib/librte_ether/rte_ethdev.c
> > @@ -1072,6 +1072,55 @@ rte_eth_dev_check_mq_mode(uint8_t port_id,
> uint16_t nb_rx_q, uint16_t nb_tx_q,
> >  }
> >
> >  int
> > +rte_eth_speed_to_bm_flag(uint32_t speed, int duplex, uint32_t *flag)
> > +{
> > + switch (speed) {
> > + case ETH_SPEED_NUM_10M:
> > + *flag = (duplex) ? ETH_LINK_SPEED_10M :
> > +
>  ETH_LINK_SPEED_10M_HD;
> > + break;
> > + case ETH_SPEED_NUM_100M:
> > + *flag = (duplex) ? ETH_LINK_SPEED_100M :
> > +
>  ETH_LINK_SPEED_100M_HD;
> > + break;
> > + case ETH_SPEED_NUM_1G:
> > + *flag = ETH_LINK_SPEED_1G;
> > + break;
> > + case ETH_SPEED_NUM_2_5G:
> > + *flag = ETH_LINK_SPEED_2_5G;
> > + break;
> > + case ETH_SPEED_NUM_5G:
> > + *flag = ETH_LINK_SPEED_5G;
> > + break;
> > + case ETH_SPEED_NUM_10G:
> > + *flag = ETH_LINK_SPEED_10G;
> > + break;
> > + case ETH_SPEED_NUM_20G:
> > + *flag = ETH_LINK_SPEED_20G;
> > + break;
> > + case ETH_SPEED_NUM_25G:
> > + *flag = ETH_LINK_SPEED_25G;
> > + break;
> > + case ETH_SPEED_NUM_40G:
> > + *flag = ETH_LINK_SPEED_40G;
> > + break;
> > + case ETH_SPEED_NUM_50G:
> > + *flag = ETH_LINK_SPEED_50G;
> > + break;
> > + case ETH_SPEED_NUM_56G:
> > + *flag = ETH_LINK_SPEED_56G;
> > + break;
> > + case ETH_SPEED_NUM_100G:
> > + *flag = ETH_LINK_SPEED_100G;
> > + break;
> > + default:
> > + return -EINVAL;
> > + }
> > +
> > + return 0;
> > +}
> > +
>
> This nees to go in the appropriate version.map file for shared library
> building.
>
> > +int
> >  rte_eth_dev_configure(uint8_t port_id, uint16_t nb_rx_q, uint16_t
> nb_tx_q,
> > const struct rte_eth_conf *dev_conf)
> >  {
> > diff --git a/lib/librte_ether/rte_ethdev.h
> b/lib/librte_ether/rte_ethdev.h
> > index 951a423..bd333e4 100644
> > --- a/lib/librte_ether/rte_ethdev.h
> > +++ b/lib/librte_ether/rte_ethdev.h
> > @@ -238,26 +238,59 @@ struct rte_eth_stats {
> >  };
> >
> >  /**
> > + * Device supported speeds bitmap flags
> > + */
> > +#define ETH_LINK_SPEED_AUTONEG   (0 << 0)  /*<
> Autonegociate (all speeds)  */
> > +#define ETH_LINK_SPEED_NO_AUTONEG(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 */
> > +#define ETH_LINK_SPEED_100M  (1 << 4)  /*< 100 Mbps full-duplex
> */
> > +#define ETH_LINK_SPEED_1G(1 << 5)  /*< 1 Gbps */
> > +#define ETH_LINK_SPEED_2_5G  (1 << 6)  /*< 2.5 Gbps */
> > +#define ETH_LINK_SPEED_5G(1 << 7)  /*< 5 Gbps */
> > +#define ETH_LINK_SPEED_10G   (1 << 8)  /*< 10 Mbps */
> > +#define ETH_LINK_SPEED_20G

[dpdk-dev] [PATCH v5 0/4] ethdev: add speed capabilities and refactor link API

2015-10-05 Thread Marc Sune
2015-10-04 23:12 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 could 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.html
>
> However, i) doing string comparisons is annoying, and can silently
> break existing applications if PMDs change their names ii) it does not
> provide all the supported capabilities of the ethdev iii) for some drivers
> it
> is impossible determine correctly the (max) speed by the application
> (e.g. in i40, distinguish between XL710 and X710).
>
> In addition, the link APIs do not allow to define a set of advertised link
> speeds for autonegociation.
>
> 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).
>
> WARNING: this patch series, specifically 3/4, is NOT tested for most of the
> PMDs, due to the lack of hardware. Only generic EM is tested (VM).
> Minor bugs expected.
>

Please mind this.

I do not have access currently to my usual testbed (several 1000/igb +
XL710). It may take some time to be rearmed, so in the meantime I've
circulated it now to make sure I've correctly captured the conclusions of
the discussion and to ask for some help on those PMDs I can anyway not test
due to the lack of HW.

Regards
Marc


>
> * * * * *
>
> v2: rebase, converted speed_capa into 32 bits bitmap, fixed alignment
> (checkpatch).
>
> 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.
>
> 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.
>
> 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.
>
>
> Marc Sune (4):
>   ethdev: Added ETH_SPEED_CAP bitmap for ports
>   ethdev: Fill speed capability bitmaps in the PMDs
>   ethdev: redesign link speed config API
>   doc: update with link changes
>
>  app/test-pmd/cmdline.c | 124
> +++--
>  app/test/virtual_pmd.c |   4 +-
>  doc/guides/rel_notes/release_2_2.rst   |  22 -
>  drivers/net/af_packet/rte_eth_af_packet.c  |   5 +-
>  drivers/net/bonding/rte_eth_bond_8023ad.c  |  14 ++--
>  drivers/net/cxgbe/base/t4_hw.c |   8 +-
>  drivers/net/e1000/base/e1000_80003es2lan.c |   6 +-
>  drivers/net/e1000/base/e1000_82541.c   |   8 +-
>  drivers/net/e1000/base/e1000_82543.c   |   4 +-
>  drivers/net/e1000/base/e1000_82575.c   |  11 +--
>  drivers/net/e1000/base/e1000_api.c |   2 +-
>  drivers/net/e1000/base/e1000_api.h |   2 +-
>  drivers/net/e1000/base/e1000_defines.h |   4 +-
>  drivers/net/e1000/base/e1000_hw.h  |   2 +-
>  drivers/net/e1000/base/e1000_ich8lan.c |   4 +-
>  drivers/net/e1000/base/e1000_mac.c |   9 ++-
>  drivers/net/e1000/base/e1000_mac.h |   6 +-
>  drivers/net/e1000/base/e1000_vf.c  |   4 +-
>  drivers/net/e1000/base/e1000_vf.h  |   2 +-
>  drivers/net/e1000/em_ethdev.c  | 104 
>  drivers/net/e1000/igb_ethdev.c |  99 ---
>  drivers/net/fm10k/fm10k_ethdev.c   |   5 +-
>  drivers/net/i40e/i40e_ethdev.c |  75 +
>  drivers/net/i40e/i40e_ethdev_vf.c  |  11 +--
>  drivers/net/ixgbe/ixgbe_ethdev.c   |  74 -
>  drivers/net/mlx4/mlx4.c|   6 ++
>  drivers/net/mpipe/mpipe_tilegx.c   |   6 +-
>  drivers/net/null/rte_eth_null.c|   5 +-
>  drivers/net/pcap/rte_eth_pcap.c|   9 ++-
>  drivers/net/ring/rte_eth_ring.c|   5 +-
>  drivers/net/vmxnet3/vmxnet3_ethdev.c   |   5 +-
>  drivers/net/xenvirt/rte_eth_xenvirt.c  |   5 +-
>  examples/ip_pipeline/config_parse.c|   3 +-
>  lib/librte_ether/rte_ethdev.c  |  49 
>  lib/librte_ether/rte_ethdev.h  |  97 +-
>  35 files changed, 481 insertions(+), 318 deletions(-)
>
> --
> 2.1.4
>
>


[dpdk-dev] [PATCH v5 4/4] doc: update with link changes

2015-10-05 Thread Marc Sune
Add new features, ABI changes and resolved issues notice for
the refactored link patch.

Signed-off-by: Marc Sune 
---
 doc/guides/rel_notes/release_2_2.rst | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/doc/guides/rel_notes/release_2_2.rst 
b/doc/guides/rel_notes/release_2_2.rst
index 5687676..e8bd4d6 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -4,6 +4,17 @@ DPDK Release 2.2
 New Features
 

+* **ethdev: define a set of advertised link speeds.**
+
+  Allowing to define a set of advertised speeds for auto-negociation,
+  explicitely disable link auto-negociation (single speed) and full
+  auto-negociation.
+
+* **ethdev: add speed_cap bitmap to recover eth device link speed capabilities
+  define a set of advertised link speeds.**
+
+  ``struct rte_eth_dev_info`` has now speed_cap bitmap, which allows the
+  application to recover the supported speeds for that ethernet device.

 Resolved Issues
 ---
@@ -48,6 +59,11 @@ Libraries
   Fixed issue where an incorrect Cuckoo Hash key table size could be
   calculated limiting the size to 4GB.

+* **ethdev: Fixed link_speed overflow in rte_eth_link for 100Gbps.**
+
+  100Gbps in Mbps (10) exceeds 16 bit max value of ``link_speed`` in
+  ``rte_eth_link``.
+

 Examples
 
@@ -81,7 +97,6 @@ API Changes
 * The deprecated ring PMD functions are removed:
   rte_eth_ring_pair_create() and rte_eth_ring_pair_attach().

-
 ABI Changes
 ---

@@ -91,6 +106,11 @@ ABI Changes
 * The ethdev flow director entries for SCTP were changed.
   It was already done in 2.1 for CONFIG_RTE_NEXT_ABI.

+* The ethdev rte_eth_link and rte_eth_conf structures were changes to
+  support the new link API.
+
+* The ethdev rte_eth_dev_info was changed to support device speed capabilities.
+
 * The mbuf structure was changed to support unified packet type.
   It was already done in 2.1 for CONFIG_RTE_NEXT_ABI.

-- 
2.1.4



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

2015-10-05 Thread Marc Sune
This patch redesigns the API to set the link speed/s configure
for an ethernet port. Specifically:

- it allows to define a set of advertised speeds for
  auto-negociation.
- it allows to disable link auto-negociation (single fixed speed).
- default: auto-negociate all supported speeds.

Other changes:

* Added utility MACROs ETH_SPEED_NUM_XXX with the numeric
  values of all supported link speeds, in Mbps.
* Converted link_speed to uint32_t to accomodate 100G speeds
  (bug).
* Added autoneg flag in struct rte_eth_link to indicate if
  link speed was a result of auto-negociation or was fixed
  by configuration.
* Added utility function to convert numeric speeds to bitmap
  fields.
* Adapted testpmd to the new link API.

Signed-off-by: Marc Sune 
---
 app/test-pmd/cmdline.c | 124 +++--
 app/test/virtual_pmd.c |   4 +-
 drivers/net/af_packet/rte_eth_af_packet.c  |   5 +-
 drivers/net/bonding/rte_eth_bond_8023ad.c  |  14 ++--
 drivers/net/cxgbe/base/t4_hw.c |   8 +-
 drivers/net/e1000/base/e1000_80003es2lan.c |   6 +-
 drivers/net/e1000/base/e1000_82541.c   |   8 +-
 drivers/net/e1000/base/e1000_82543.c   |   4 +-
 drivers/net/e1000/base/e1000_82575.c   |  11 +--
 drivers/net/e1000/base/e1000_api.c |   2 +-
 drivers/net/e1000/base/e1000_api.h |   2 +-
 drivers/net/e1000/base/e1000_defines.h |   4 +-
 drivers/net/e1000/base/e1000_hw.h  |   2 +-
 drivers/net/e1000/base/e1000_ich8lan.c |   4 +-
 drivers/net/e1000/base/e1000_mac.c |   9 ++-
 drivers/net/e1000/base/e1000_mac.h |   6 +-
 drivers/net/e1000/base/e1000_vf.c  |   4 +-
 drivers/net/e1000/base/e1000_vf.h  |   2 +-
 drivers/net/e1000/em_ethdev.c  | 108 -
 drivers/net/e1000/igb_ethdev.c | 103 
 drivers/net/fm10k/fm10k_ethdev.c   |   8 +-
 drivers/net/i40e/i40e_ethdev.c |  70 
 drivers/net/i40e/i40e_ethdev_vf.c  |  11 +--
 drivers/net/ixgbe/ixgbe_ethdev.c   |  72 -
 drivers/net/mlx4/mlx4.c|   2 +
 drivers/net/mpipe/mpipe_tilegx.c   |   6 +-
 drivers/net/null/rte_eth_null.c|   5 +-
 drivers/net/pcap/rte_eth_pcap.c|   9 ++-
 drivers/net/ring/rte_eth_ring.c|   5 +-
 drivers/net/vmxnet3/vmxnet3_ethdev.c   |   5 +-
 drivers/net/xenvirt/rte_eth_xenvirt.c  |   5 +-
 examples/ip_pipeline/config_parse.c|   3 +-
 lib/librte_ether/rte_ethdev.c  |  49 
 lib/librte_ether/rte_ethdev.h  | 113 --
 34 files changed, 437 insertions(+), 356 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 0f8f48f..c62f5be 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -897,14 +897,65 @@ struct cmd_config_speed_all {
cmdline_fixed_string_t value2;
 };

+static int
+parse_and_check_speed_duplex(char *value1, char *value2, uint32_t *link_speed)
+{
+
+   int duplex;
+
+   if (!strcmp(value2, "half")) {
+   duplex = 0;
+   } else if (!strcmp(value2, "full")) {
+   duplex = 1;
+   } else if (!strcmp(value2, "auto")) {
+   duplex = 1;
+   } else {
+   printf("Unknown parameter\n");
+   return -1;
+   }
+
+   if (!strcmp(value1, "10")) {
+   *link_speed = (duplex) ? ETH_LINK_SPEED_10M :
+   ETH_LINK_SPEED_10M_HD;
+   } else if (!strcmp(value1, "100")) {
+   *link_speed = (duplex) ? ETH_LINK_SPEED_100M :
+   ETH_LINK_SPEED_100M_HD;
+   } else if (!strcmp(value1, "1000")) {
+   if (!duplex)
+   goto invalid_speed_param;
+   *link_speed = ETH_LINK_SPEED_1G;
+   } else if (!strcmp(value1, "1")) {
+   if (!duplex)
+   goto invalid_speed_param;
+   *link_speed = ETH_LINK_SPEED_10G;
+   } else if (!strcmp(value1, "4")) {
+   if (!duplex)
+   goto invalid_speed_param;
+   *link_speed = ETH_LINK_SPEED_40G;
+   } else if (!strcmp(value1, "auto")) {
+   if (!duplex)
+   goto invalid_speed_param;
+   *link_speed = ETH_LINK_SPEED_AUTONEG;
+   } else {
+   printf("Unknown parameter\n");
+   return -1;
+   }
+
+   return 0;
+
+invalid_speed_param:
+
+   printf("Invalid speed parameter\n");
+   return -1;
+}
+
 static void
 cmd_config_speed_all_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
 

[dpdk-dev] [PATCH v5 2/4] ethdev: Fill speed capability bitmaps in the PMDs

2015-10-05 Thread Marc Sune
Added speed capabilities to all pmds supporting physical NICs:

* e1000
* ixgbe
* i40
* mlx4
* fm10k

Signed-off-by: Marc Sune 
---
 drivers/net/e1000/em_ethdev.c|  6 ++
 drivers/net/e1000/igb_ethdev.c   |  6 ++
 drivers/net/fm10k/fm10k_ethdev.c |  3 +++
 drivers/net/i40e/i40e_ethdev.c   |  9 +
 drivers/net/ixgbe/ixgbe_ethdev.c | 10 ++
 drivers/net/mlx4/mlx4.c  |  4 
 6 files changed, 38 insertions(+)

diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index 912f5dd..72f792c 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -933,6 +933,12 @@ eth_em_infos_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)

dev_info->max_rx_queues = 1;
dev_info->max_tx_queues = 1;
+
+   dev_info->speed_capa = ETH_SPEED_CAP_10M_HD |
+   ETH_SPEED_CAP_10M_FD |
+   ETH_SPEED_CAP_100M_HD |
+   ETH_SPEED_CAP_100M_FD |
+   ETH_SPEED_CAP_1G;
 }

 /* return 0 means link status changed, -1 means not changed */
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index 848ef6e..927f5d9 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -1570,6 +1570,12 @@ eth_igb_infos_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
},
.txq_flags = 0,
};
+
+   dev_info->speed_capa = ETH_SPEED_CAP_10M_HD |
+   ETH_SPEED_CAP_10M_FD |
+   ETH_SPEED_CAP_100M_HD |
+   ETH_SPEED_CAP_100M_FD |
+   ETH_SPEED_CAP_1G;
 }

 static void
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index a69c990..ca6357c 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -964,6 +964,9 @@ fm10k_dev_infos_get(struct rte_eth_dev *dev,
ETH_TXQ_FLAGS_NOOFFLOADS,
};

+   dev_info->speed_capa = ETH_SPEED_CAP_1G | ETH_SPEED_CAP_2_5G |
+   ETH_SPEED_CAP_10G | ETH_SPEED_CAP_25G |
+   ETH_SPEED_CAP_40G | ETH_SPEED_CAP_100G;
 }

 static int
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 2dd9fdc..8a5dfbf 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -1624,6 +1624,7 @@ static void
 i40e_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
 {
struct i40e_pf *pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
+   struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
struct i40e_vsi *vsi = pf->main_vsi;

dev_info->max_rx_queues = vsi->nb_qps;
@@ -1683,6 +1684,14 @@ i40e_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
dev_info->max_rx_queues += dev_info->vmdq_queue_num;
dev_info->max_tx_queues += dev_info->vmdq_queue_num;
}
+
+   if (i40e_is_40G_device(hw->device_id))
+   /* For XL710 */
+   dev_info->speed_capa = ETH_SPEED_CAP_1G | ETH_SPEED_CAP_10G;
+   else
+   /* For X710 */
+   dev_info->speed_capa = ETH_SPEED_CAP_10G | ETH_SPEED_CAP_40G;
+
 }

 static int
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index ec2918c..053c77e 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -2399,6 +2399,16 @@ ixgbe_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
dev_info->hash_key_size = IXGBE_HKEY_MAX_INDEX * sizeof(uint32_t);
dev_info->reta_size = ETH_RSS_RETA_SIZE_128;
dev_info->flow_type_rss_offloads = IXGBE_RSS_OFFLOAD_ALL;
+
+   dev_info->speed_capa = ETH_SPEED_CAP_1G | ETH_SPEED_CAP_10G;
+
+   if (hw->mac.type == ixgbe_mac_X540 ||
+   hw->mac.type == ixgbe_mac_X540_vf ||
+   hw->mac.type == ixgbe_mac_X550 ||
+   hw->mac.type == ixgbe_mac_X550_vf)
+
+   dev_info->speed_capa |= ETH_SPEED_CAP_100M_FD
+   /*| ETH_SPEED_CAP_100M_HD*/;
 }

 static void
diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index 2f49ed5..88f95e5 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -3847,6 +3847,10 @@ mlx4_dev_infos_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *info)
  DEV_TX_OFFLOAD_UDP_CKSUM |
  DEV_TX_OFFLOAD_TCP_CKSUM) :
 0);
+
+   info->speed_capa = ETH_SPEED_CAP_10G | ETH_SPEED_CAP_40G |
+   ETH_SPEED_CAP_56G;
+
priv_unlock(priv);
 }

-- 
2.1.4



[dpdk-dev] [PATCH v5 0/4] ethdev: add speed capabilities and refactor link API

2015-10-05 Thread 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 could 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.html

However, i) doing string comparisons is annoying, and can silently
break existing applications if PMDs change their names ii) it does not
provide all the supported capabilities of the ethdev iii) for some drivers it
is impossible determine correctly the (max) speed by the application
(e.g. in i40, distinguish between XL710 and X710).

In addition, the link APIs do not allow to define a set of advertised link
speeds for autonegociation.

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).

WARNING: this patch series, specifically 3/4, is NOT tested for most of the
PMDs, due to the lack of hardware. Only generic EM is tested (VM).
Minor bugs expected.

* * * * *

v2: rebase, converted speed_capa into 32 bits bitmap, fixed alignment
(checkpatch).

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.

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.

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.


Marc Sune (4):
  ethdev: Added ETH_SPEED_CAP bitmap for ports
  ethdev: Fill speed capability bitmaps in the PMDs
  ethdev: redesign link speed config API
  doc: update with link changes

 app/test-pmd/cmdline.c | 124 +++--
 app/test/virtual_pmd.c |   4 +-
 doc/guides/rel_notes/release_2_2.rst   |  22 -
 drivers/net/af_packet/rte_eth_af_packet.c  |   5 +-
 drivers/net/bonding/rte_eth_bond_8023ad.c  |  14 ++--
 drivers/net/cxgbe/base/t4_hw.c |   8 +-
 drivers/net/e1000/base/e1000_80003es2lan.c |   6 +-
 drivers/net/e1000/base/e1000_82541.c   |   8 +-
 drivers/net/e1000/base/e1000_82543.c   |   4 +-
 drivers/net/e1000/base/e1000_82575.c   |  11 +--
 drivers/net/e1000/base/e1000_api.c |   2 +-
 drivers/net/e1000/base/e1000_api.h |   2 +-
 drivers/net/e1000/base/e1000_defines.h |   4 +-
 drivers/net/e1000/base/e1000_hw.h  |   2 +-
 drivers/net/e1000/base/e1000_ich8lan.c |   4 +-
 drivers/net/e1000/base/e1000_mac.c |   9 ++-
 drivers/net/e1000/base/e1000_mac.h |   6 +-
 drivers/net/e1000/base/e1000_vf.c  |   4 +-
 drivers/net/e1000/base/e1000_vf.h  |   2 +-
 drivers/net/e1000/em_ethdev.c  | 104 
 drivers/net/e1000/igb_ethdev.c |  99 ---
 drivers/net/fm10k/fm10k_ethdev.c   |   5 +-
 drivers/net/i40e/i40e_ethdev.c |  75 +
 drivers/net/i40e/i40e_ethdev_vf.c  |  11 +--
 drivers/net/ixgbe/ixgbe_ethdev.c   |  74 -
 drivers/net/mlx4/mlx4.c|   6 ++
 drivers/net/mpipe/mpipe_tilegx.c   |   6 +-
 drivers/net/null/rte_eth_null.c|   5 +-
 drivers/net/pcap/rte_eth_pcap.c|   9 ++-
 drivers/net/ring/rte_eth_ring.c|   5 +-
 drivers/net/vmxnet3/vmxnet3_ethdev.c   |   5 +-
 drivers/net/xenvirt/rte_eth_xenvirt.c  |   5 +-
 examples/ip_pipeline/config_parse.c|   3 +-
 lib/librte_ether/rte_ethdev.c  |  49 
 lib/librte_ether/rte_ethdev.h  |  97 +-
 35 files changed, 481 insertions(+), 318 deletions(-)

-- 
2.1.4



[dpdk-dev] [PATCH v4 0/2] ethdev: add port speed capability bitmap

2015-09-16 Thread Marc Sune
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 _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 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 multiple
> physical
> > > links). Regardless whether it is a Layer2 link aggregate (IEEE 802.1ad,
> > > Ethernet bonding, EtherChannel, DSL pair bonding, etc.) or a Layer3
> > > multipath link (e.g. simultaneously using Wi-Fi and mobile networks).
> So it
> > > doesn't make sense trying to impose physical link properties on a
> purely
> > > logical link. Likewise, it doesn't make sense to impose logical link
> > > properties on physical links. In other words: Don't consider bonding
> or any
> > > other logical link types when designing the PHY API.
> > > >
> > > > +1
> > >
> > > +1.
>
> I agree with the fact that physical link properties do not make sense for
> logical links, however in the case of the bonding PMD, the aggregated link
> speed can be actually useful for applications (assuming it is kept up to
> date, I think it's the case). The current API certainly allows this.
>
> > > > > I think there is consensus that 1/ (PHY capabilities) and 2/ (PHY
> > > advertisements) should use the same definitions, specifically a bitmap
> > > field. And when you disregard bonding, I don't see any reason to use
> > > different definitions for 3/ (PHY negotiation result). This makes it
> one
> > > unified API for all three purposes.
> > > >
> > > > Agree.
> > >
> > > I don't agree with this one, some PMDs don't use the advertise of
> > > autoneg result to get the speed or the duplex.  You make a
> > > generality from your case above all PMDs.
> > >
> >
> > can you please explain how a particular PMD is recovering the actual link
> > speed and the duplex has to do with the design of the (general) API?
>
> 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 with no clear advantage.


See below; these are trivial changes.


> All PMDs must be modified, the initial
> set of patches isn't complete in this regard.
>

Thanks for pointing out this. There are a couple missing.


>
> > > Mellanox get the speed, duplex and status information from IOCTLs
> > > which are not related to your bitmap.  So at least for this PMD, there
> > > is already a conversion from 3 fields to a bitmap, knowing that it will
> > > use the speed as an integer after.  What is the benefit of your
> solution?
> > >
> >
> > I said already I don't have a strong preference for 3/. But steering the
> > design of an API through a "minimum common denominator" principle is not
> a
> > good idea, specially since we are talking about a super simple mapping
> > issue for this specific PMD.
>
> I think Nelio was using mlx4 as an example, all PMDs have their own
> particular method to recover it and several must perform calculations to
> get
> the final value. Using integers for this task is certainly easier than
> going
> through bit-field conversions.
>

Drivers have their *own* way to extract the link speed from the HW, because
the way is stored is anyway HW specific. That a driver encodes their link
speed as a numeric value is just a coincidence, and the exception.

Specifically, and putting an example of e1000 (which you are right it is
buggy in v4, see below):

dpdk/drivers/net/e1000/base/e1000_mac.c

1651 s32 e1000_get_speed_and_duplex_copper_generic(struct e1000_hw *hw, u16
*speed,
1652   u16 *duplex)

1653 {

1654 u32 status;

1655

1656 DEBUGFUNC("e1000_get_speed_and_duplex_copper_generic");

1657

1658 status = E1000_READ_REG(hw, E1000_STAT

[dpdk-dev] [PATCH v4 0/2] ethdev: add port speed capability bitmap

2015-09-15 Thread Marc Sune
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 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 multiple physical
> links). Regardless whether it is a Layer2 link aggregate (IEEE 802.1ad,
> Ethernet bonding, EtherChannel, DSL pair bonding, etc.) or a Layer3
> multipath link (e.g. simultaneously using Wi-Fi and mobile networks). So it
> doesn't make sense trying to impose physical link properties on a purely
> logical link. Likewise, it doesn't make sense to impose logical link
> properties on physical links. In other words: Don't consider bonding or any
> other logical link types when designing the PHY API.
> >
> > +1
>
> +1.
>
> >
> >
> > > I think there is consensus that 1/ (PHY capabilities) and 2/ (PHY
> advertisements) should use the same definitions, specifically a bitmap
> field. And when you disregard bonding, I don't see any reason to use
> different definitions for 3/ (PHY negotiation result). This makes it one
> unified API for all three purposes.
> >
> > Agree.
>
> I don't agree with this one, some PMDs don't use the advertise of
> autoneg result to get the speed or the duplex.  You make a
> generality from your case above all PMDs.
>

can you please explain how a particular PMD is recovering the actual link
speed and the duplex has to do with the design of the (general) API?


>
> Mellanox get the speed, duplex and status information from IOCTLs
> which are not related to your bitmap.  So at least for this PMD, there
> is already a conversion from 3 fields to a bitmap, knowing that it will
> use the speed as an integer after.  What is the benefit of your solution?
>

I said already I don't have a strong preference for 3/. But steering the
design of an API through a "minimum common denominator" principle is not a
good idea, specially since we are talking about a super simple mapping
issue for this specific PMD.


>
> > > Nelio suggested adding a support function to convert the bitmap field
> to a speed value as an integer. I strongly support this, because you cannot
> expect the bitmap to be ordered by speed.
> >
> > Agree with Nelio This is useful.
>
> It was exactly the extreme opposite, a function which takes a
> rte_eth_link to a bitmap i.e. speed_to_bm (rte_eth_link link) because,
> the speed is mostly used as an integer and not some kind of bitmap.
>
> > > 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, auto
> negotiation/non-auto negotiation, or add two separate functions to get the
> duplex and auto-negotiation.
> >
> > Since, Full/Half duplex is for legacy 10/100Mbps only (afaik), I have my
> doubts on using a bit for all speeds. I would suggest to define (unroll)
> 100M (or 100M_FD) and 100M_HD, and the same 10Mbps/1gbps, as Thomas was
> suggesting some mails ago.
> >
> > This was done in v4 (implicitely 100M == 100M_FD). See below.
> >
> > MB> I didn't intend two bits to be allocated in the bitmap for all
> speeds to support full/half duplex, only for the relevant speeds. Since
> full duplex is dominant, I agree with the previous decision (originally
> suggested by Thomas, I think) to make full duplex implicit unless half
> duplex is explicitly specified. E.g. 10M_HD, 10M (alias 10M_FD), 100M_HD,
> 100M (alias 100M_FD), 1000M (or 1G), 2500M, 10G, 40G, 100G, etc.
> >
> >
> > > I haven't read the suggested code, but there should be some means in
> 2/ (advertisements) to disable auto negotiation, e.g. a single bit in the
> bitmap to indicate if the speed/duplex-indicating bits in the bitmap means
> forced speed/duplex (in which case only a single speed/duplex-bit should be
> set) or auto negotiation advertised speed/duplex (in which case multiple
> speed/duplex-bits can be set).
> >
> > Agree.
> >
> > v3/4 of this patch adds the bitmap in the advertised, as per discussed,
> to select a group of speeds This is not implemented by drivers yet (!).
> >
> > So, as of v4 of this patch, there could be: a) autoneg any supported
> speed (=> bitmap =

[dpdk-dev] [PATCH v4 0/2] ethdev: add port speed capability bitmap

2015-09-15 Thread Marc Sune
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 multiple physical
> links). Regardless whether it is a Layer2 link aggregate (IEEE 802.1ad,
> Ethernet bonding, EtherChannel, DSL pair bonding, etc.) or a Layer3
> multipath link (e.g. simultaneously using Wi-Fi and mobile networks). So it
> doesn't make sense trying to impose physical link properties on a purely
> logical link. Likewise, it doesn't make sense to impose logical link
> properties on physical links. In other words: Don't consider bonding or any
> other logical link types when designing the PHY API.
>

+1


>
> I think there is consensus that 1/ (PHY capabilities) and 2/ (PHY
> advertisements) should use the same definitions, specifically a bitmap
> field. And when you disregard bonding, I don't see any reason to use
> different definitions for 3/ (PHY negotiation result). This makes it one
> unified API for all three purposes.
>

Agree.


>
> Nelio suggested adding a support function to convert the bitmap field to a
> speed value as an integer. I strongly support this, because you cannot
> expect the bitmap to be ordered by speed.


Agree with Nelio This is useful.


> 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, auto
> negotiation/non-auto negotiation, or add two separate functions to get the
> duplex and auto-negotiation.
>

Since, Full/Half duplex is for legacy 10/100Mbps only (afaik), I have my
doubts on using a bit for all speeds. I would suggest to define (unroll)
100M (or 100M_FD) and 100M_HD, and the same 10Mbps/1gbps, as Thomas was
suggesting some mails ago.

This was done in v4 (implicitely 100M == 100M_FD). See below.


>
> I haven't read the suggested code, but there should be some means in 2/
> (advertisements) to disable auto negotiation, e.g. a single bit in the
> bitmap to indicate if the speed/duplex-indicating bits in the bitmap means
> forced speed/duplex (in which case only a single speed/duplex-bit should be
> set) or auto negotiation advertised speed/duplex (in which case multiple
> speed/duplex-bits can be set).


Agree.

v3/4 of this patch adds the bitmap in the advertised, as per discussed, to
select a group of speeds This is not implemented by drivers yet (!).

So, as of v4 of this patch, there could be: a) autoneg any supported speed
(=> bitmap == 0) b) autoneg over group of speeds (=> more than one bit set
in the bitmap) c) forced speed (one and only one set in the bitmap).

I think this is precisely what you meant + b) as a bonus


> And some means in 3/ (result) and maybe 2/ (advertisements) to select
> and/or indicate physical interface in dual-personality ports (e.g. ports
> where the PHY has both an SFP and a RJ45 connector, but only one of the two
> can be used at any time).
>
>
For rte_eth_link_get() I don't have such a strong opinion. You either

* encode the link speed and duplex as of now, separating duplex and numeric
speed. I would suggest to add the encoded speed+duplex bitmap flag for
consistency (although redundant).
* or you return a single value, the bitmap with a single flag set of the
unrolled speeds, and then have the helpers int rte_eth_speed_from_bm(int
val_bm) and 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 dpdk.org; Olga Shern; Adrien Mazarguil; 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 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.
> >
> > I am confused, specially since you were the one advocating for having
> > a unified set of constants for speeds (discussion in v2).
>
> Yes, my first thought was advocating an unification between capabilities
> and negotiated link properties.
> After I was convinced by Nelio's arguments: bitmap is good for
> capabilities (especially to describe every capabilities in one field) but
> integer is better for negotiated speed (especially for aggre

[dpdk-dev] [PATCH v4 0/2] ethdev: add port speed capability bitmap

2015-09-13 Thread Marc Sune
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 proposal looks good Nelio.
>

I am confused, specially since you were the one advocating for having a
unified set of constants for speeds (discussion in v2).

In any case, as I see it, if we want to address the comments of  M. Brorup:

http://comments.gmane.org/gmane.comp.networking.dpdk.devel/19664

we need bitmaps for rte_eth_conf link_speed to set the advertised speeds.

 857 struct rte_eth_conf {

 858 uint16_t link_speed;

 859 /**< ETH_LINK_SPEED_10[0|00|000], or 0 for autonegotation */

 860 uint16_t link_duplex;

Let me know if you really want to come back to v2 or not.

Marc


> Thanks
>


[dpdk-dev] [PATCH v4 0/2] ethdev: add port speed capability

2015-09-09 Thread Marc Sune
Answering

2015-09-09 11:29 GMT+02:00 N?lio Laranjeiro :

> bitmap
> Reply-To:
>
> Shern , Adrien
> Mazarguil 
> Bcc:
> Subject: Re: [dpdk-dev] [PATCH v4 0/2] ethdev: add port speed capability
> bitmap
> Reply-To:
> In-Reply-To: <20150909090855.GC17463 at autoinstall.dev.6wind.com>
>
> Marc,
>
> On Tue, Sep 08, 2015 at 10:24:36PM +0200, Marc Sune wrote:
> > 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.
> > > >
> > > > 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.html
> > > >
> > > > However, i) doing string comparisons is annoying, and can
> silently
> > > > break existing applications if PMDs change their names ii) it
> does not
> > > > provide all the supported capabilities of the ethdev iii) for
> some
> > drivers
> > > > it
> > > > is impossible determine correctly the (max) speed by the
> application
> > > > (e.g. in i40, distinguish between XL710 and X710).
> > > >
> > > > This small patch adds speed_capa bitmap in rte_eth_dev_info,
> which is
> > > > filled
> > > > by the PMDs according to the physical device capabilities.
> > > >
> > > > v2: rebase, converted speed_capa into 32 bits bitmap, fixed
> alignment
> > > > (checkpatch).
> > > >
> > > > 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 speeds, to
> allow a
> > > > bitmap
> > > > for defining the announced speeds, as suggested by M.
> Brorup. Fixed
> > > > spelling issues.
> > > >
> > > > 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.
> > > >
> > >
> > > Thomas,
> > >
> > > Since mostly you were commenting for v1 and v2; any opinion on
> this one?
> > >
> > > Regards
> > > marc
> >
> > Hi Marc,
> >
> > I have read your patches, and there are a few mistakes, for instance
> mlx4
> > (ConnectX-3 devices) does not support 100Gbps.
> >
> >
> > When I circulated v1 and v2 I was kindly asking maintainers and
> reviewers of
> > the drivers to fix any mistakes in SPEED capabilities, since I was
> taking the
> > speeds from the online websites Some were fixed, but
> apparently
> > some were still missing. I will remove 100Gbps. Please circulate any
> other
> > error you have spotted.
>
> From Mellanox website:
>  - ConnectX-3 EN: 10/40/56Gb/s
>  - ConnectX-3 Pro EN 10GBASE-T: 10G/s
>  - ConnectX-3 Pro: EN 10/40/56GbE
>  - ConnectX-3 Pro Programmable: 10/40Gb/s
>
> This PMD works with any of the ConnectX-3 adapters, so the announce speed
> should be 10/40/56Gb/s.
>

I will change this, thanks.


>
> > In addition, it seems your new bitmap does not support all kind of
> > speeds, take a look at the header of Ethtool, in the Linux kernel
> > (include/uapi/linux/ethtool.h) which already consumes 30bits without
> even
> > managing speeds above 56Gbps.
> >
> >
> > The bitmaps you are referring is SUPPORTED_ and ADVERTISED_. These
> bitmaps not
> > only contain the speeds but PHY properties (e.g. BASE for ETH).
> >
> > The intention of this patch was to expose speed capabilities, similar to
> the
> > bitmap SPEED_ in include/uapi/linux/ethtool.h, which as you see maps
> closely to
> > ETH_SPEED_ proposed in this patch.
> >
> > I think the encoding of other things, like the exact model of the
> interface and
> > its PHY details should go somewhere else. But I might be wrong here, so
> open to
> > hear opinions.
>
> I unders

[dpdk-dev] [PATCH v4 0/2] ethdev: add port speed capability bitmap

2015-09-08 Thread Marc Sune
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.
> > >
> > > 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.html
> > >
> > > However, i) doing string comparisons is annoying, and can silently
> > > break existing applications if PMDs change their names ii) it does not
> > > provide all the supported capabilities of the ethdev iii) for some
> drivers
> > > it
> > > is impossible determine correctly the (max) speed by the application
> > > (e.g. in i40, distinguish between XL710 and X710).
> > >
> > > This small patch adds speed_capa bitmap in rte_eth_dev_info, which is
> > > filled
> > > by the PMDs according to the physical device capabilities.
> > >
> > > v2: rebase, converted speed_capa into 32 bits bitmap, fixed alignment
> > > (checkpatch).
> > >
> > > 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 speeds, to allow a
> > > bitmap
> > > for defining the announced speeds, as suggested by M. Brorup. Fixed
> > > spelling issues.
> > >
> > > 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.
> > >
> >
> > Thomas,
> >
> > Since mostly you were commenting for v1 and v2; any opinion on this one?
> >
> > Regards
> > marc
>
> Hi Marc,
>
> I have read your patches, and there are a few mistakes, for instance mlx4
> (ConnectX-3 devices) does not support 100Gbps.
>

When I circulated v1 and v2 I was kindly asking maintainers and reviewers
of the drivers to fix any mistakes in SPEED capabilities, since I was
taking the speeds from the online websites Some were fixed, but
apparently some were still missing. I will remove 100Gbps. Please circulate
any other error you have spotted.



>
> In addition, it seems your new bitmap does not support all kind of
> speeds, take a look at the header of Ethtool, in the Linux kernel
> (include/uapi/linux/ethtool.h) which already consumes 30bits without even
> managing speeds above 56Gbps.
>

The bitmaps you are referring is SUPPORTED_ and ADVERTISED_. These bitmaps
not only contain the speeds but PHY properties (e.g. BASE for ETH).

The intention of this patch was to expose speed capabilities, similar to
the bitmap SPEED_ in include/uapi/linux/ethtool.h, which as you see maps
closely to ETH_SPEED_ proposed in this patch.

I think the encoding of other things, like the exact model of the interface
and its PHY details should go somewhere else. But I might be wrong here, so
open to hear opinions.


>
> It would be nice to keep the field to represent the real speed of the
> link, in case it is not represented by the bitmap, it could be also
> useful for aggregated links (bonding for instance).  The current API
> already works this way, it just needs to be extended from 16 to 32 bit
> to manage speed above 64Gbps.
>

This patch does not remove rte_eth_link_get() API. It just changes the
encoding of speed in struct rte_eth_link, to have an homogeneous set of
constants with the speed capabilities bitmap, as discussed previously in
the thread (see Thomas comments). IOW, it returns now a single SPEED_ value
in the struct rte_eth_link's link_speed field.

Marc


>
> >[...]
>
> N?lio
> --
> N?lio Laranjeiro
> 6WIND
>


[dpdk-dev] [PATCH v4 0/2] ethdev: add port speed capability bitmap

2015-09-07 Thread Marc Sune
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:
>
> http://dpdk.org/ml/archives/dev/2013-August/000412.html
>
> However, i) doing string comparisons is annoying, and can silently
> break existing applications if PMDs change their names ii) it does not
> provide all the supported capabilities of the ethdev iii) for some drivers
> it
> is impossible determine correctly the (max) speed by the application
> (e.g. in i40, distinguish between XL710 and X710).
>
> This small patch adds speed_capa bitmap in rte_eth_dev_info, which is
> filled
> by the PMDs according to the physical device capabilities.
>
> v2: rebase, converted speed_capa into 32 bits bitmap, fixed alignment
> (checkpatch).
>
> 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 speeds, to allow a
> bitmap
> for defining the announced speeds, as suggested by M. Brorup. Fixed
> spelling issues.
>
> 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.
>

Thomas,

Since mostly you were commenting for v1 and v2; any opinion on this one?

Regards
marc


>
> Marc Sune (2):
>   Added ETH_SPEED_ bitmap in rte_eth_dev_info
>   Filling speed capability bitmaps in the PMDs
>
>  app/test-pmd/cmdline.c| 32 +++
>  app/test/virtual_pmd.c|  2 +-
>  drivers/net/bonding/rte_eth_bond_8023ad.c | 14 +-
>  drivers/net/cxgbe/base/t4_hw.c|  8 +++---
>  drivers/net/e1000/em_ethdev.c | 20 +-
>  drivers/net/e1000/igb_ethdev.c| 20 +-
>  drivers/net/fm10k/fm10k_ethdev.c  |  3 +++
>  drivers/net/i40e/i40e_ethdev.c| 43
> +++
>  drivers/net/i40e/i40e_ethdev_vf.c |  2 +-
>  drivers/net/ixgbe/ixgbe_ethdev.c  | 32 +++
>  drivers/net/mlx4/mlx4.c   |  6 +
>  drivers/net/vmxnet3/vmxnet3_ethdev.c  |  2 +-
>  lib/librte_ether/rte_ethdev.h | 42
> +-
>  13 files changed, 142 insertions(+), 84 deletions(-)
>
> --
> 2.1.4
>
>


[dpdk-dev] rte_eal_init() alternative?

2015-09-02 Thread Marc Sune
Stephen, Don,

On Wed, Sep 2, 2015 at 9:00 PM, Stephen Hemminger <
stephen at networkplumber.org> wrote:

> On Wed, 2 Sep 2015 18:17:40 +
> Don Provan  wrote:
>
> > Thomas Monjalon:
> > >Yes but please, do not create an alternative init function.
> > >We just need to replace panic/exit with error codes and be sure that
> apps and examples handle them correctly.
> >
> > I understand your concerns, but the panics are really just the tip of
> the iceberg of the EAL library not realizing it's a library. It really
> makes no sense to think the library should define the application's command
> line, or that the PCI bus should be probed without considering whether this
> application is going to use PCI, and or to insist that EAL work be done on
> internal EAL threads.
> >
> > So I'd say it's way past time to consider revamping initialization to
> start the process of ending the DPDK library's tail wagging the
> application's dog. Naturally this would have to be done while retaining the
> existing init routine on top of a real library initialization, but that's
> just an unfortunate artifact of the library's history, not a rational
> design decision for moving forward.
>

That's one of the first things I was asking in the mailing list (argv):

http://dpdk.org/ml/archives/dev/2013-August/000374.html

I still think the same way.


> >
> > -don provan
> >
>
> You are welcome to submit patches with what you are proposing for review.
> Theoretical requirements discussions will probably only result in more
> mail,
> not new code. You know what you want, propose a solution.
>
> As far as the command line. That is easily managed by realizing the
> application
> doesn't have to pass the original command line into EAL. If you just view
> the
> command line as a way to pass unstructured options; the application or
> infrastructure
> can build up new values and pass it in.
>

Yes sure, and that's what all of us who are integrating DPDK in existing
applications is doing:

https://github.com/bisdn/xdpd/blob/stable/src/xdpd/drivers/gnu_linux_dpdk/src/hal-imp/driver.cc#L153-L157

But that's rather a workaround.

Instead, having an eal_init() API which only handles a fixed set of
arguments (non-argv) that can be used by existing applications, and build a
command line API on top of eal_init() that parses argv as of now (e.g.
eal_init_cl) seems to me cleaner. There are users that make use of the
parsing of argv (e.g. dpdk-pktgen) in DPDK, so I think it makes sense to
keep it.

So if you'd agree on this general proposal, I will try to allocate some
time for refactoring this.

Marc


>
> I agree that initialization itself should try and not fail except in the
> most extreme cases.  "ie I can't find /sys what is wrong" and should try
> and adapt more "you asked for 128 cpu's but I see only 2, log it and
> continue"
>
>


[dpdk-dev] [PATCH v4 1/2] Added ETH_SPEED_ bitmap in rte_eth_dev_info

2015-08-29 Thread Marc Sune
Currently there was no way to recover all the supported speeds of a certain
ether device.

This commit adds a speed capability bitmap to rte_eth_dev_info struct, to be
filled by PMDs. It also renames ETH_LINK_SPEED_XXX to ETH_SPEED, in order to
unify speed capabilities and link speeds. It also adds missing speeds to
ETH_SPEED.

The field speed in the struct rte_eth_conf is now a bitmap and therefore is
renamed to speeds. This allows to specify a list of speeds to be announced
during autonegociation, as suggested by M. Brorup. Drivers do not support (yet)
this capability.

Signed-off-by: Marc Sune 
---
 app/test-pmd/cmdline.c| 32 +++
 app/test/virtual_pmd.c|  2 +-
 drivers/net/bonding/rte_eth_bond_8023ad.c | 14 +--
 drivers/net/cxgbe/base/t4_hw.c|  8 +++---
 drivers/net/e1000/em_ethdev.c | 14 +--
 drivers/net/e1000/igb_ethdev.c| 14 +--
 drivers/net/i40e/i40e_ethdev.c| 34 -
 drivers/net/i40e/i40e_ethdev_vf.c |  2 +-
 drivers/net/ixgbe/ixgbe_ethdev.c  | 22 
 drivers/net/vmxnet3/vmxnet3_ethdev.c  |  2 +-
 examples/ip_pipeline/config_parse.c   |  2 +-
 lib/librte_ether/rte_ethdev.h | 42 ++-
 12 files changed, 103 insertions(+), 85 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 5799c9c..053acf6 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -903,7 +903,7 @@ cmd_config_speed_all_parsed(void *parsed_result,
__attribute__((unused)) void *data)
 {
struct cmd_config_speed_all *res = parsed_result;
-   uint16_t link_speed = ETH_LINK_SPEED_AUTONEG;
+   uint16_t link_speed = ETH_SPEED_AUTONEG;
uint16_t link_duplex = 0;
portid_t pid;

@@ -913,17 +913,17 @@ cmd_config_speed_all_parsed(void *parsed_result,
}

if (!strcmp(res->value1, "10"))
-   link_speed = ETH_LINK_SPEED_10;
+   link_speed = ETH_SPEED_10M;
else if (!strcmp(res->value1, "100"))
-   link_speed = ETH_LINK_SPEED_100;
+   link_speed = ETH_SPEED_100M;
else if (!strcmp(res->value1, "1000"))
-   link_speed = ETH_LINK_SPEED_1000;
+   link_speed = ETH_SPEED_1G;
else if (!strcmp(res->value1, "1"))
-   link_speed = ETH_LINK_SPEED_10G;
+   link_speed = ETH_SPEED_10G;
else if (!strcmp(res->value1, "4"))
-   link_speed = ETH_LINK_SPEED_40G;
+   link_speed = ETH_SPEED_40G;
else if (!strcmp(res->value1, "auto"))
-   link_speed = ETH_LINK_SPEED_AUTONEG;
+   link_speed = ETH_SPEED_AUTONEG;
else {
printf("Unknown parameter\n");
return;
@@ -941,7 +941,7 @@ cmd_config_speed_all_parsed(void *parsed_result,
}

FOREACH_PORT(pid, ports) {
-   ports[pid].dev_conf.link_speed = link_speed;
+   ports[pid].dev_conf.link_speeds = link_speed;
ports[pid].dev_conf.link_duplex = link_duplex;
}

@@ -1000,7 +1000,7 @@ cmd_config_speed_specific_parsed(void *parsed_result,
__attribute__((unused)) void *data)
 {
struct cmd_config_speed_specific *res = parsed_result;
-   uint16_t link_speed = ETH_LINK_SPEED_AUTONEG;
+   uint16_t link_speed = ETH_SPEED_AUTONEG;
uint16_t link_duplex = 0;

if (!all_ports_stopped()) {
@@ -1012,17 +1012,17 @@ cmd_config_speed_specific_parsed(void *parsed_result,
return;

if (!strcmp(res->value1, "10"))
-   link_speed = ETH_LINK_SPEED_10;
+   link_speed = ETH_SPEED_10M;
else if (!strcmp(res->value1, "100"))
-   link_speed = ETH_LINK_SPEED_100;
+   link_speed = ETH_SPEED_100M;
else if (!strcmp(res->value1, "1000"))
-   link_speed = ETH_LINK_SPEED_1000;
+   link_speed = ETH_SPEED_1G;
else if (!strcmp(res->value1, "1"))
-   link_speed = ETH_LINK_SPEED_1;
+   link_speed = ETH_SPEED_10G;
else if (!strcmp(res->value1, "4"))
-   link_speed = ETH_LINK_SPEED_40G;
+   link_speed = ETH_SPEED_40G;
else if (!strcmp(res->value1, "auto"))
-   link_speed = ETH_LINK_SPEED_AUTONEG;
+   link_speed = ETH_SPEED_AUTONEG;
else {
printf("Unknown parameter\n");
return;
@@ -1039,7 +1039,7 @@ cmd_config_speed_specific_parsed(void *parsed_result,
return;
}

-   ports[res->id].dev_conf.link_speed = link_speed;
+   ports[r

[dpdk-dev] [PATCH v4 0/2] ethdev: add port speed capability bitmap

2015-08-29 Thread 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:

http://dpdk.org/ml/archives/dev/2013-August/000412.html

However, i) doing string comparisons is annoying, and can silently
break existing applications if PMDs change their names ii) it does not
provide all the supported capabilities of the ethdev iii) for some drivers it
is impossible determine correctly the (max) speed by the application
(e.g. in i40, distinguish between XL710 and X710).

This small patch adds speed_capa bitmap in rte_eth_dev_info, which is filled
by the PMDs according to the physical device capabilities.

v2: rebase, converted speed_capa into 32 bits bitmap, fixed alignment
(checkpatch).

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 speeds, to allow a bitmap
for defining the announced speeds, as suggested by M. Brorup. Fixed
spelling issues.

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.

Marc Sune (2):
  Added ETH_SPEED_ bitmap in rte_eth_dev_info
  Filling speed capability bitmaps in the PMDs

 app/test-pmd/cmdline.c| 32 +++
 app/test/virtual_pmd.c|  2 +-
 drivers/net/bonding/rte_eth_bond_8023ad.c | 14 +-
 drivers/net/cxgbe/base/t4_hw.c|  8 +++---
 drivers/net/e1000/em_ethdev.c | 20 +-
 drivers/net/e1000/igb_ethdev.c| 20 +-
 drivers/net/fm10k/fm10k_ethdev.c  |  3 +++
 drivers/net/i40e/i40e_ethdev.c| 43 +++
 drivers/net/i40e/i40e_ethdev_vf.c |  2 +-
 drivers/net/ixgbe/ixgbe_ethdev.c  | 32 +++
 drivers/net/mlx4/mlx4.c   |  6 +
 drivers/net/vmxnet3/vmxnet3_ethdev.c  |  2 +-
 lib/librte_ether/rte_ethdev.h | 42 +-
 13 files changed, 142 insertions(+), 84 deletions(-)

-- 
2.1.4



[dpdk-dev] [PATCH v3 2/2] Filling speed capability bitmaps in the PMDs

2015-08-29 Thread Marc Sune
Added speed capabilities to all pmds supporting physical NICs:

* e1000
* ixgbe
* i40
* mlx4
* fm10k

Signed-off-by: Marc Sune 
---
 drivers/net/e1000/em_ethdev.c|  6 ++
 drivers/net/e1000/igb_ethdev.c   |  6 ++
 drivers/net/fm10k/fm10k_ethdev.c |  3 +++
 drivers/net/i40e/i40e_ethdev.c   |  9 +
 drivers/net/ixgbe/ixgbe_ethdev.c | 10 ++
 drivers/net/mlx4/mlx4.c  |  6 ++
 6 files changed, 40 insertions(+)

diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index 5ca1830..cd64843 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -888,6 +888,12 @@ eth_em_infos_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)

dev_info->max_rx_queues = 1;
dev_info->max_tx_queues = 1;
+
+   dev_info->speed_capa = ETH_SPEED_10M_HD |
+   ETH_SPEED_10M |
+   ETH_SPEED_100M_HD |
+   ETH_SPEED_100M |
+   ETH_SPEED_1G;
 }

 /* return 0 means link status changed, -1 means not changed */
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index 7c5e952..d511400 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -1404,6 +1404,12 @@ eth_igb_infos_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
},
.txq_flags = 0,
};
+
+   dev_info->speed_capa = ETH_SPEED_10M_HD |
+   ETH_SPEED_10M |
+   ETH_SPEED_100M_HD |
+   ETH_SPEED_100M |
+   ETH_SPEED_1G;
 }

 static void
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index 4afd5ab..40b1dd1 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -791,6 +791,9 @@ fm10k_dev_infos_get(struct rte_eth_dev *dev,
ETH_TXQ_FLAGS_NOOFFLOADS,
};

+   dev_info->speed_capa = ETH_SPEED_1G | ETH_SPEED_2_5G |
+   ETH_SPEED_10G | ETH_SPEED_25G |
+   ETH_SPEED_40G | ETH_SPEED_100G;
 }

 static int
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 056b081..87b1840 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -1519,6 +1519,7 @@ static void
 i40e_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
 {
struct i40e_pf *pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
+   struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
struct i40e_vsi *vsi = pf->main_vsi;

dev_info->max_rx_queues = vsi->nb_qps;
@@ -1574,6 +1575,14 @@ i40e_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
dev_info->max_rx_queues += dev_info->vmdq_queue_num;
dev_info->max_tx_queues += dev_info->vmdq_queue_num;
}
+
+   if (i40e_is_40G_device(hw->device_id))
+   /* For XL710 */
+   dev_info->speed_capa = ETH_SPEED_10G | ETH_SPEED_40G;
+   else
+   /* For X710 */
+   dev_info->speed_capa = ETH_SPEED_1G | ETH_SPEED_10G;
+
 }

 static int
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index b2fcffc..2e57a7c 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -2060,6 +2060,16 @@ ixgbe_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
};
dev_info->reta_size = ETH_RSS_RETA_SIZE_128;
dev_info->flow_type_rss_offloads = IXGBE_RSS_OFFLOAD_ALL;
+
+   dev_info->speed_capa = ETH_SPEED_1G | ETH_SPEED_10G;
+
+   if (hw->mac.type == ixgbe_mac_X540 ||
+   hw->mac.type == ixgbe_mac_X540_vf ||
+   hw->mac.type == ixgbe_mac_X550 ||
+   hw->mac.type == ixgbe_mac_X550_vf)
+
+   dev_info->speed_capa |= ETH_SPEED_100M |
+   ETH_SPEED_100M_HD;
 }

 static void
diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index fde23e1..f3dbe58 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -3487,6 +3487,12 @@ mlx4_dev_infos_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *info)
info->max_rx_queues = max;
info->max_tx_queues = max;
info->max_mac_addrs = elemof(priv->mac);
+
+   info->speed_capa = ETH_SPEED_10G | ETH_SPEED_20G |
+   ETH_SPEED_25G | ETH_SPEED_40G |
+   ETH_SPEED_50G | ETH_SPEED_56G |
+   ETH_SPEED_100G;
+
priv_unlock(priv);
 }

-- 
2.1.4



[dpdk-dev] [PATCH v3 1/2] Added ETH_SPEED_ bitmap in rte_eth_dev_info

2015-08-29 Thread Marc Sune
Currently there was no way to recover all the supported speeds of a certain
ether device.

This commit adds a speed capability bitmap to rte_eth_dev_info struct, to be
filled by PMDs. It also renames ETH_LINK_SPEED_XXX to ETH_SPEED, in order to
unify speed capabilities and link speeds. It also adds missing speeds to
ETH_SPEED.

The field speed in the struct rte_eth_link is now a bitmap and therefore is
renamed to speeds. This allows to specify a list of speeds to be announced
during autonegociation, as suggested by M. Brorup. Driver do not support yet
this capabilities.

Signed-off-by: Marc Sune 
---
 app/test-pmd/cmdline.c| 32 +++
 app/test/virtual_pmd.c|  2 +-
 drivers/net/bonding/rte_eth_bond_8023ad.c | 14 +--
 drivers/net/e1000/em_ethdev.c | 14 +--
 drivers/net/e1000/igb_ethdev.c| 14 +--
 drivers/net/i40e/i40e_ethdev.c| 28 ++---
 drivers/net/i40e/i40e_ethdev_vf.c |  2 +-
 drivers/net/ixgbe/ixgbe_ethdev.c  | 22 
 drivers/net/vmxnet3/vmxnet3_ethdev.c  |  2 +-
 lib/librte_ether/rte_ethdev.h | 42 ++-
 10 files changed, 95 insertions(+), 77 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 8142910..8e131c7 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -898,7 +898,7 @@ cmd_config_speed_all_parsed(void *parsed_result,
__attribute__((unused)) void *data)
 {
struct cmd_config_speed_all *res = parsed_result;
-   uint16_t link_speed = ETH_LINK_SPEED_AUTONEG;
+   uint16_t link_speed = ETH_SPEED_AUTONEG;
uint16_t link_duplex = 0;
portid_t pid;

@@ -908,17 +908,17 @@ cmd_config_speed_all_parsed(void *parsed_result,
}

if (!strcmp(res->value1, "10"))
-   link_speed = ETH_LINK_SPEED_10;
+   link_speed = ETH_SPEED_10M;
else if (!strcmp(res->value1, "100"))
-   link_speed = ETH_LINK_SPEED_100;
+   link_speed = ETH_SPEED_100M;
else if (!strcmp(res->value1, "1000"))
-   link_speed = ETH_LINK_SPEED_1000;
+   link_speed = ETH_SPEED_1G;
else if (!strcmp(res->value1, "1"))
-   link_speed = ETH_LINK_SPEED_10G;
+   link_speed = ETH_SPEED_10G;
else if (!strcmp(res->value1, "4"))
-   link_speed = ETH_LINK_SPEED_40G;
+   link_speed = ETH_SPEED_40G;
else if (!strcmp(res->value1, "auto"))
-   link_speed = ETH_LINK_SPEED_AUTONEG;
+   link_speed = ETH_SPEED_AUTONEG;
else {
printf("Unknown parameter\n");
return;
@@ -936,7 +936,7 @@ cmd_config_speed_all_parsed(void *parsed_result,
}

FOREACH_PORT(pid, ports) {
-   ports[pid].dev_conf.link_speed = link_speed;
+   ports[pid].dev_conf.link_speeds = link_speed;
ports[pid].dev_conf.link_duplex = link_duplex;
}

@@ -995,7 +995,7 @@ cmd_config_speed_specific_parsed(void *parsed_result,
__attribute__((unused)) void *data)
 {
struct cmd_config_speed_specific *res = parsed_result;
-   uint16_t link_speed = ETH_LINK_SPEED_AUTONEG;
+   uint16_t link_speed = ETH_SPEED_AUTONEG;
uint16_t link_duplex = 0;

if (!all_ports_stopped()) {
@@ -1007,17 +1007,17 @@ cmd_config_speed_specific_parsed(void *parsed_result,
return;

if (!strcmp(res->value1, "10"))
-   link_speed = ETH_LINK_SPEED_10;
+   link_speed = ETH_SPEED_10M;
else if (!strcmp(res->value1, "100"))
-   link_speed = ETH_LINK_SPEED_100;
+   link_speed = ETH_SPEED_100M;
else if (!strcmp(res->value1, "1000"))
-   link_speed = ETH_LINK_SPEED_1000;
+   link_speed = ETH_SPEED_1G;
else if (!strcmp(res->value1, "1"))
-   link_speed = ETH_LINK_SPEED_1;
+   link_speed = ETH_SPEED_10G;
else if (!strcmp(res->value1, "4"))
-   link_speed = ETH_LINK_SPEED_40G;
+   link_speed = ETH_SPEED_40G;
else if (!strcmp(res->value1, "auto"))
-   link_speed = ETH_LINK_SPEED_AUTONEG;
+   link_speed = ETH_SPEED_AUTONEG;
else {
printf("Unknown parameter\n");
return;
@@ -1034,7 +1034,7 @@ cmd_config_speed_specific_parsed(void *parsed_result,
return;
}

-   ports[res->id].dev_conf.link_speed = link_speed;
+   ports[res->id].dev_conf.link_speeds = link_speed;
ports[res->id].dev_conf.link_duplex = link_duplex;


[dpdk-dev] [PATCH v3 0/2] ethdev: add port speed capability bitmap

2015-08-29 Thread Marc Sune
From: Marc Sune <marcde...@gmail.de>

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.html

However, i) doing string comparisons is annoying, and can silently
break existing applications if PMDs change their names ii) it does not
provide all the supported capabilities of the ethdev iii) for some drivers it
is impossible determine correctly the (max) speed by the application
(e.g. in i40, distinguish between XL710 and X710).

This small patch adds speed_capa bitmap in rte_eth_dev_info, which is filled
by the PMDs according to the physical device capabilities.

v2: rebase, converted speed_capa into 32 bits bitmap, fixed alignment
(checkpatch).

v3: rebase to v2.1. unified ETH_LINK_SPEED and ETH_SPEED_CAP into ETH_SPEED.
Converted field speed in struct rte_eth_link to speed, to allow a bitmap
for defining the announced speeds, as suggested M. Brorup. Fixed spelling
issues.

Marc Sune (2):
  Added ETH_SPEED_ bitmap in rte_eth_dev_info
  Filling speed capability bitmaps in the PMDs

 app/test-pmd/cmdline.c| 32 +++
 app/test/virtual_pmd.c|  2 +-
 drivers/net/bonding/rte_eth_bond_8023ad.c | 14 +--
 drivers/net/e1000/em_ethdev.c | 20 +--
 drivers/net/e1000/igb_ethdev.c| 20 +--
 drivers/net/fm10k/fm10k_ethdev.c  |  3 +++
 drivers/net/i40e/i40e_ethdev.c| 37 ---
 drivers/net/i40e/i40e_ethdev_vf.c |  2 +-
 drivers/net/ixgbe/ixgbe_ethdev.c  | 32 +++
 drivers/net/mlx4/mlx4.c   |  6 +
 drivers/net/vmxnet3/vmxnet3_ethdev.c  |  2 +-
 lib/librte_ether/rte_ethdev.h | 42 ++-
 12 files changed, 135 insertions(+), 77 deletions(-)

-- 
2.1.4



[dpdk-dev] "ifconfig" commands/status using the dpdk:igb_uio driver

2015-08-05 Thread Marc Sune


On 04/08/15 23:09, Navneet Rao wrote:
> Hello Experts:
>   
>
> How can I configure my NIC setting(s) when loaded with the dpdk:igb_uio 
> driver?
> E.g I need to keep the MAC address and the IP address of the NIC the "same as 
> before" after switching to a dpdk:igb_uio driver for the NIC.

When you bind to igb_uio the NIC is "disconnected" from the kernel. 
Therefore ifconfig won't work. DPDK applications can configure the PHY 
and other parameters via DPDK APIs:

http://dpdk.org/doc/api/

and act as IP endpoints.

Marc

>
> Is there a equiv of "ifconfig" utility in dpdk?
> How do I address the NIC? I can only view the status using the 
> dpdk_nic_bind.py!!!
>
>   
>
>   
>
> Thanks
> -Navneet
>
>   
>
>   



[dpdk-dev] How to prevent KNI interface from getting deleted on application termination?

2015-07-09 Thread Marc Sune


On 09/07/15 08:36, Gopakumar Choorakkot Edakkunni wrote:
> Reading through the KNI module source, doesnt look like there is a way
> to do this. For my requirement, I will make some patch tomorrow to
> have a module option to just keep the KNI data structures around even
> if /dev/kni is closed, looks straightforward to do from the code
>
> Rgds,
> Gopa.
>
> On Wed, Jul 8, 2015 at 1:00 PM, Gopakumar Choorakkot Edakkunni
>  wrote:
>> Hi all,
>>
>> My application takes over one/multiple ethernet port(s) in a linux
>> system and creates KNI interfaces corresponding to them. So if there
>> was eth0 and eth1 in the non-dpdk mode, once I take over the ports
>> using dpdk, I create eth0 and eth1 KNI interfaces. As far as the linux
>> network managers are concerned, they dont really know about it (or
>> care I guess) - for example the dhcp client tries getting a dhcp
>> address over these KNI interfaces and succeeds.
>>
>> Now if my application crashes, I dont want the entire network
>> management subsystem on linux and the hotplugs and this and that to
>> get alarmed and routes to vanish from the route table etc.. etc.. The
>> application will crash and come back up real quick, nothing needs to
>> change in that meantime.

Maybe a stupid question; why not fixing your application so that it 
doesn't crash, instead of adding adhoc patches?

marc

>>
>> Any way to achieve that ? I just want to keep the KNI around even if
>> my app vanishes.
>>
>> Rgds,
>> Gopa.



[dpdk-dev] [PATCH v2] kni: ignore double calls to rte_kni_init()

2015-06-18 Thread Marc Sune
Prevent double initialization of the KNI subsytem.

v2: added warning trace

Signed-off-by: Marc Sune 
---
 lib/librte_kni/rte_kni.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/lib/librte_kni/rte_kni.c b/lib/librte_kni/rte_kni.c
index c5a0089..08155db 100644
--- a/lib/librte_kni/rte_kni.c
+++ b/lib/librte_kni/rte_kni.c
@@ -201,6 +201,12 @@ rte_kni_init(unsigned int max_kni_ifaces)
char obj_name[OBJNAMSIZ];
char mz_name[RTE_MEMZONE_NAMESIZE];

+   /* Immediately return if KNI is already initialized */
+   if (kni_memzone_pool.initialized) {
+   RTE_LOG(WARNING, KNI, "Double call to rte_kni_init()");
+   return;
+   }
+
if (max_kni_ifaces == 0) {
RTE_LOG(ERR, KNI, "Invalid number of max_kni_ifaces %d\n",
max_kni_ifaces);
-- 
2.1.4



[dpdk-dev] [PATCH v2 1/2] Added ETH_SPEED_CAP bitmap in rte_eth_dev_info

2015-06-18 Thread Marc Sune


On 18/06/15 16:43, Morten Br?rup wrote:
> Regarding the PHY speed ABI:
>
>   
>
> 1. The Ethernet PHY ABI for speed, duplex, etc. should be common throughout 
> the entire DPDK. It might be confusing if some structures/functions use a 
> bitmask to indicate PHY speed/duplex/personality/etc. and other 
> structures/functions use a combination of an unsigned integer, duplex flag, 
> personality enumeration etc. (By personality enumeration, I am referring to 
> PHYs with multiple electrical interfaces. E.g. a dual personality PHY might 
> have both an RJ45 copper interface and an SFP module interface, whereof only 
> one can be active at any time.)

Thomas was sending a similar comment and I agreed to do a unified speed 
bitmap for both capabilities and link negotiation/link info (v3, waiting 
for 2.2 merge window):

http://dpdk.org/ml/archives/dev/2015-June/019207.html

>
>   
>
> 2. The auto-negotiation standard allows the PHY to announce (to its link 
> partner) any subset of its capabilities to its link partner. E.g. a standard 
> 10/100/100 Ethernet PHY (which can handle both 10 and 100 Mbit/s in both half 
> and full duplex and 1 Gbit/s full duplex) can be configured to announce 10 
> Mbit/s half duplex and 100 Mbit/s full duplex capabilities to its link 
> partner. (Of course, more useful combinations are normally announced, but the 
> purpose of the example is to show that any combination is possible.)
>
>   
>
> The ABI for auto-negotiation should include options to select the list of 
> capabilities to announce to the link partner. The Linux PHY ABI only allows 
> forcing a selected speed and duplex (thereby disabling auto-negotiation) or 
> enabling auto-negotiation (thereby announcing all possible speeds and duplex 
> combinations the PHY is capable of). Don't make the same mistake in DPDK.

I see what you mean, and you are probably right. In any case this is for 
a separate patch, if we think it is a necessary feature to implement.

Nevertheless, this makes me rethink about the proposal from Thomas about 
unifying _100_HD/_100_FD to 100M, because you will need this 
granularity, eventually. @Thomas: opinions?

Thanks
Marc

p.s. Please configure your email client to reply using "In-Reply-To:" to 
allow clients and ML archives to use threading.

>   
>
> PS: While working for Vitesse Semiconductors (an Ethernet chip company) a 
> long time ago, I actually wrote the API for their line of Ethernet PHYs. So I 
> have hands on experience in this area.
>
>   
>
>   
>
> Med venlig hilsen / kind regards
>
>   
>
> Morten Br?rup
>
> CTO
>
>   
>
>   
>
>   
>
> SmartShare Systems A/S
>
> Tonsbakken 16-18
>
> DK-2740 Skovlunde
>
> Denmark
>
>   
>
> Office  +45 70 20 00 93
>
> Direct  +45 89 93 50 22
>
> Mobile  +45 25 40 82 12
>
>   
>
> mb at smartsharesystems.com 
>
> www.smartsharesystems.com 
>
>   
>



[dpdk-dev] [PATCH v2 1/2] Added ETH_SPEED_CAP bitmap in rte_eth_dev_info

2015-06-11 Thread Marc Sune


On 11/06/15 11:08, Thomas Monjalon wrote:
> 2015-06-08 10:50, Marc Sune:
>> On 29/05/15 20:23, Thomas Monjalon wrote:
>>> 2015-05-27 11:15, Marc Sune:
>>>> On 27/05/15 06:02, Thomas Monjalon wrote:
>>>>>> +#define ETH_SPEED_CAP_10M_HD(1 << 0)  /*< 10 Mbps half-duplex> */
>>>>>> +#define ETH_SPEED_CAP_10M_FD(1 << 1)  /*< 10 Mbps full-duplex> */
>>>>>> +#define ETH_SPEED_CAP_100M_HD   (1 << 2)  /*< 100 Mbps half-duplex> */
>>>>>> +#define ETH_SPEED_CAP_100M_FD   (1 << 3)  /*< 100 Mbps full-duplex> */
>>>>>> +#define ETH_SPEED_CAP_1G(1 << 4)  /*< 1 Gbps > */
>>>>>> +#define ETH_SPEED_CAP_2_5G  (1 << 5)  /*< 2.5 Gbps > */
>>>>>> +#define ETH_SPEED_CAP_5G(1 << 6)  /*< 5 Gbps > */
>>>>>> +#define ETH_SPEED_CAP_10G   (1 << 7)  /*< 10 Mbps > */
>>>>>> +#define ETH_SPEED_CAP_20G   (1 << 8)  /*< 20 Gbps > */
>>>>>> +#define ETH_SPEED_CAP_25G   (1 << 9)  /*< 25 Gbps > */
>>>>>> +#define ETH_SPEED_CAP_40G   (1 << 10)  /*< 40 Gbps > */
>>>>>> +#define ETH_SPEED_CAP_50G   (1 << 11)  /*< 50 Gbps > */
>>>>>> +#define ETH_SPEED_CAP_56G   (1 << 12)  /*< 56 Gbps > */
>>>>>> +#define ETH_SPEED_CAP_100G  (1 << 13)  /*< 100 Gbps > */
>>>>> We should note that rte_eth_link is using ETH_LINK_SPEED_* constants
>>>>> which are not some bitmaps so we have to create these new constants.
>>>> Yes, I can add that to the patch description (1/2).
>>>>
>>>>> Furthermore, rte_eth_link.link_speed is an uint16_t so it is limited
>>>>> to 40G. Should we use some constant bitmaps here also?
>>>> I also thought about converting link_speed into a bitmap to unify the
>>>> constants before starting the patch (there is redundancy), but I wanted
>>>> to be minimally invasive; changing link to a bitmap can break existing 
>>>> apps.
>>>>
>>>> I can also merge them if we think is a better idea.
>>> Maybe. Someone against this idea?
>> Me. I tried implementing this unified speed constantss, but the problem
>> is that for the capabilities full-duplex/half-duplex speeds are unrolled
>> (e.g. 100M_HD/100_FD). There is no generic 100M to set a specific speed,
> Or we can define ETH_SPEED_CAP_100M and ETH_SPEED_CAP_100M_FD.
> Is it possible to have a NIC doing 100M_FD but not 100M_HD?

Did not check in detail, but I guess this is mostly legacy NICs, not 
supported by DPDK anyway, and that is safe to assume 10M/100M meaning 
supports both HD/FD.

>
>> so if you want a fiex speed and duplex auto-negociation witht the
>> current set of constants, it would look weird; e.g.
>> link_speed=ETH_SPEED_100M_HD and then set
>> link_duplex=ETH_LINK_AUTONEG_DUPLEX):
>>
>>232 struct rte_eth_link {
>>233 uint16_t link_speed;  /**< ETH_LINK_SPEED_[10, 100,
>> 1000, 1] */
>>234 uint16_t link_duplex; /**< ETH_LINK_[HALF_DUPLEX,
>> FULL_DUPLEX] */
>>235 uint8_t  link_status : 1; /**< 1 -> link up, 0 -> link
>> down */
>>236 }__attribute__((aligned(8))); /**< aligned for atomic64
>> read/write */
>>
>> There is another minor point, which is when setting the speed in
>> rte_eth_conf:
>>
>>840 struct rte_eth_conf {
>>841 uint16_t link_speed;
>>842 /**< ETH_LINK_SPEED_10[0|00|000], or 0 for autonegotation */
>>
>> 0 is used for speed auto-negociation, but 0 is also used in the
>> capabilities bitmap to indicate no PHY_MEDIA (virtual interface). I
>> would have to define something like:
>>
>> 906 #define ETH_SPEED_NOT_PHY   (0)  /*< No phy media > */
>> 907 #define ETH_SPEED_AUTONEG   (0)  /*< Autonegociate speed > */
> Or something like SPEED_UNDEFINED

Ok. I will prepare the patch and circulate a v3.

After briefly chatting offline with Thomas, it seems I was not clearly 
stating in my original v1 that this patch is targeting DPDK v2.2, due to 
ABI(and API) issues.

It is, and so I will hold v3 until 2.2 window starts, to make it more clear.

thanks
Marc
>
>> And use (only) NOT_PHY for a capabilities and _AUTONEG for rte_eth_conf.
>>
>> The options I see:
>>
>> a) add to the the list of the current speeds generic 10M/100M/1G speeds
>> without HD/FD, and just use these speeds in rte_eth_conf.
>> b) leave them separated.
>>
>> I would vote for b), since the a) is not completely clean.
>> Opinions alternatives welcome.
>>
>> Marc



[dpdk-dev] [PATCH v2 1/2] Added ETH_SPEED_CAP bitmap in rte_eth_dev_info

2015-06-08 Thread Marc Sune


On 29/05/15 20:23, Thomas Monjalon wrote:
> 2015-05-27 11:15, Marc Sune:
>> On 27/05/15 06:02, Thomas Monjalon wrote:
>>> Why not starting with lower values? Some new drivers may be interested
>>> by lower speed.
>> Ok, but which values? 1Mbps FD/HD? Even lower than that?
>>
>> If you have some NIC(s) in mind with lower values, please point me to
>> that and I will collect the missing speeds.
> No sorry, I missed how low your first values were.
>
>>>> +#define ETH_SPEED_CAP_10M_HD  (1 << 0)  /*< 10 Mbps half-duplex> */
>>>> +#define ETH_SPEED_CAP_10M_FD  (1 << 1)  /*< 10 Mbps full-duplex> */
>>>> +#define ETH_SPEED_CAP_100M_HD (1 << 2)  /*< 100 Mbps half-duplex> */
>>>> +#define ETH_SPEED_CAP_100M_FD (1 << 3)  /*< 100 Mbps full-duplex> */
>>>> +#define ETH_SPEED_CAP_1G  (1 << 4)  /*< 1 Gbps > */
>>>> +#define ETH_SPEED_CAP_2_5G(1 << 5)  /*< 2.5 Gbps > */
>>>> +#define ETH_SPEED_CAP_5G  (1 << 6)  /*< 5 Gbps > */
>>>> +#define ETH_SPEED_CAP_10G (1 << 7)  /*< 10 Mbps > */
>>>> +#define ETH_SPEED_CAP_20G (1 << 8)  /*< 20 Gbps > */
>>>> +#define ETH_SPEED_CAP_25G (1 << 9)  /*< 25 Gbps > */
>>>> +#define ETH_SPEED_CAP_40G (1 << 10)  /*< 40 Gbps > */
>>>> +#define ETH_SPEED_CAP_50G (1 << 11)  /*< 50 Gbps > */
>>>> +#define ETH_SPEED_CAP_56G (1 << 12)  /*< 56 Gbps > */
>>>> +#define ETH_SPEED_CAP_100G(1 << 13)  /*< 100 Gbps > */
>>> We should note that rte_eth_link is using ETH_LINK_SPEED_* constants
>>> which are not some bitmaps so we have to create these new constants.
>> Yes, I can add that to the patch description (1/2).
>>
>>> Furthermore, rte_eth_link.link_speed is an uint16_t so it is limited
>>> to 40G. Should we use some constant bitmaps here also?
>> I also thought about converting link_speed into a bitmap to unify the
>> constants before starting the patch (there is redundancy), but I wanted
>> to be minimally invasive; changing link to a bitmap can break existing apps.
>>
>> I can also merge them if we think is a better idea.
> Maybe. Someone against this idea?

Me. I tried implementing this unified speed constantss, but the problem 
is that for the capabilities full-duplex/half-duplex speeds are unrolled 
(e.g. 100M_HD/100_FD). There is no generic 100M to set a specific speed, 
so if you want a fiex speed and duplex auto-negociation witht the 
current set of constants, it would look weird; e.g. 
link_speed=ETH_SPEED_100M_HD and then set 
link_duplex=ETH_LINK_AUTONEG_DUPLEX):

  232 struct rte_eth_link {
  233 uint16_t link_speed;  /**< ETH_LINK_SPEED_[10, 100, 
1000, 1] */
  234 uint16_t link_duplex; /**< ETH_LINK_[HALF_DUPLEX, 
FULL_DUPLEX] */
  235 uint8_t  link_status : 1; /**< 1 -> link up, 0 -> link 
down */
  236 }__attribute__((aligned(8))); /**< aligned for atomic64 
read/write */

There is another minor point, which is when setting the speed in 
rte_eth_conf:

  840 struct rte_eth_conf {
  841 uint16_t link_speed;
  842 /**< ETH_LINK_SPEED_10[0|00|000], or 0 for autonegotation */

0 is used for speed auto-negociation, but 0 is also used in the 
capabilities bitmap to indicate no PHY_MEDIA (virtual interface). I 
would have to define something like:

906 #define ETH_SPEED_NOT_PHY   (0)  /*< No phy media > */
907 #define ETH_SPEED_AUTONEG   (0)  /*< Autonegociate speed > */

And use (only) NOT_PHY for a capabilities and _AUTONEG for rte_eth_conf.

The options I see:

a) add to the the list of the current speeds generic 10M/100M/1G speeds 
without HD/FD, and just use these speeds in rte_eth_conf.
b) leave them separated.

I would vote for b), since the a) is not completely clean. 
Opinions alternatives welcome.

Marc

>
>>> What about removing _CAP suffix from your constants?
>> I added the suffix to make clearer the distinction with link speeds. I
>> can remove it if we merge both or if we consider it is not necessary.
>>
>>> [...]
>>>> +  uint32_t speed_capa;  /**< Supported speeds bitmap (ETH_SPEED_CAP_). */
>>> If the constants are ETH_SPEED_CAP, why not wording this variable speed_cap?
>> I followed the convention of the existing rx/tx offload capability bitmaps:
>>
>> marc at dev:~/git/bisdn/msune/xdpd/libs/dpdk/lib$ grep _capa\; * -R
>> librte_ether/rte_ethdev.h:uint32_t rx_offload_capa; /**< Device RX
>> offload capabilities. */
>> librte_ether/rte_ethdev.h:uint32_t tx_offload_capa; /**<

[dpdk-dev] KNI performance

2015-06-05 Thread Marc Sune


On 05/06/15 17:06, Jay Rolette wrote:
> The past few days I've been trying to chase down why operations over KNI
> are so bloody slow. To give you an idea how bad it is, we did a simple test
> over an NFS mount:
>
> # Mount over a non-KNI interface (eth0 on vanilla Ubuntu 14.04 LTS)
> $ time $(ls -last -R /mnt/sfs2008 > /dev/null)
> real11m58.224s
> user0m10.758s
> sys 0m25.050s
>
> # Reboot to make sure NFS cache is cleared and mount over a KNI interface
> $ time $(ls -last -R /mnt/sfs2008 > /dev/null)
> real87m36.295s
> user0m14.552s
> sys 0m25.949s
>
> Packet captures showed a pretty consistent ~4ms delay. Get a READDIRPLUS
> reply from NFS server and the TCP stack on the DPDK/KNI system took about
> 4ms to ACK the reply. It isn't just on ACK packets either. If there was no
> ACK required, there would be a 4ms delay before the next call was sent
> (ACCESS, LOOKUP, another READDIR, etc.).
>
> This is running on top of a real DPDK app, so there are various queues and
> ring-buffers in the path between KNI and the wire, so I started there. Long
> story short, worst case, those could only inject ~120us of latency into the
> path.
>
> Next stop was KNI itself. Ignoring a few minor optos I found, nothing in
> the code looked like it could account for 4ms of latency. That wasn't quite
> right though...
>
> Here's the code for the processing loop in kni_thread_single():
>
>  while (!kthread_should_stop()) {
>  down_read(_list_lock);
>  for (j = 0; j < KNI_RX_LOOP_NUM; j++) {
>  list_for_each_entry(dev, _list_head, list) {
> #ifdef RTE_KNI_VHOST
>  kni_chk_vhost_rx(dev);
> #else
>  kni_net_rx(dev);
> #endif
>  kni_net_poll_resp(dev);
>  }
>  }
>  up_read(_list_lock);
>  /* reschedule out for a while */
>  schedule_timeout_interruptible(usecs_to_jiffies( \
>  KNI_KTHREAD_RESCHEDULE_INTERVAL));
>
> Turns out the 4ms delay is due to the schedule_timeout() call. The code
> specifies a 5us sleep, but the call only guarantees a sleep of *at least*
> the time specified.
>
> The resolution of the sleep is controlled by the timer interrupt rate. If
> you are using a kernel from one of the usual Linux distros, HZ = 250 on
> x86. That works out nicely to a 4ms period. The KNI kernel thread was going
> to sleep and frequently not getting woken up for nearly 4ms.
>
> We rebuilt the kernel with HZ = 1000 and things improved considerably:
>
> # Mount over a KNI interface, HZ=1000
> $ time $(ls -last -R /mnt/sfs2008 > /dev/null)
>
> real21m8.478s
> user0m13.824s
> sys 0m18.113s
>
> Still not where I'd like to get it, but much, much better.
>
> Hopefully my pain is your gain and this helps other KNI users.

Jay,

If you set CONFIG_RTE_KNI_PREEMPT_DEFAULT to 'n' you should see a 
reduced latency and delay since there is no preemption (though 
sacrifices 1 CPU for the kni kmod):

http://patchwork.dpdk.org/dev/patchwork/patch/3304/

However, KNI is still pretty slow. Even considering that there will 
always be at least 1 copy involved, I still think is too slow. I didn't 
had time to look closer yet.

Marc



>
> Jay



[dpdk-dev] [PATCH] kni: ignore double calls to rte_kni_init()

2015-06-01 Thread Marc Sune
Prevent double initialization of the KNI subsytem.

Signed-off-by: Marc Sune 
---
 lib/librte_kni/rte_kni.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/lib/librte_kni/rte_kni.c b/lib/librte_kni/rte_kni.c
index c5a0089..df0449f 100644
--- a/lib/librte_kni/rte_kni.c
+++ b/lib/librte_kni/rte_kni.c
@@ -201,6 +201,10 @@ rte_kni_init(unsigned int max_kni_ifaces)
char obj_name[OBJNAMSIZ];
char mz_name[RTE_MEMZONE_NAMESIZE];

+   /* Immediately return if KNI is already initialized */
+   if (kni_memzone_pool.initialized)
+   return;
+
if (max_kni_ifaces == 0) {
RTE_LOG(ERR, KNI, "Invalid number of max_kni_ifaces %d\n",
max_kni_ifaces);
-- 
2.1.4



[dpdk-dev] Packet Cloning

2015-05-28 Thread Marc Sune


On 28/05/15 18:06, Matt Laswell wrote:
> Hey Kyle,
>
> That's one way you can handle it, though I suspect you'll end up with some
> complexity elsewhere in your code to deal with remembering whether you
> should look at the original data or the copied and modified data.  Another
> way is just to make a copy of the original mbuf, but have your copy API
> stop after it reaches some particular point.  Perhaps just the L2-L4
> headers, perhaps a few hundred bytes into payload, or perhaps something
> else entirely. This all gets very application dependent, of course.  How
> much is "enough" is going to depend heavily on what you're trying to
> accomplish.

mbufs can be chained in multiple segments. So you could first split into 
two segments leaving the big chunk in the original mbuf (chunk2) and 
copy chunk1 into the new mbuf (check prepend, adj and trim).

Marc

[1] http://dpdk.org/doc/api/rte__mbuf_8h.html

>



[dpdk-dev] [PATCH] kni: ignore double calls to rte_kni_init()

2015-05-28 Thread Marc Sune
Prevent double initialization of the KNI subsytem.

Signed-off-by: Marc Sune 
---
 lib/librte_kni/rte_kni.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/lib/librte_kni/rte_kni.c b/lib/librte_kni/rte_kni.c
index c5a0089..df0449f 100644
--- a/lib/librte_kni/rte_kni.c
+++ b/lib/librte_kni/rte_kni.c
@@ -201,6 +201,10 @@ rte_kni_init(unsigned int max_kni_ifaces)
char obj_name[OBJNAMSIZ];
char mz_name[RTE_MEMZONE_NAMESIZE];

+   /* Immediately return if KNI is already initialized */
+   if (kni_memzone_pool.initialized)
+   return;
+
if (max_kni_ifaces == 0) {
RTE_LOG(ERR, KNI, "Invalid number of max_kni_ifaces %d\n",
max_kni_ifaces);
-- 
2.1.4



[dpdk-dev] [PATCH 2/2] kni: add missing include dependencies

2015-05-28 Thread Marc Sune


On 25/05/15 14:23, Bruce Richardson wrote:
> The file rte_kni.h depends upon a number of other headers, some of which
> are missing from the #include lines. The following #includes are added:
>   * rte_memory.h - for the definition of phys_addr_t
>   * rte_mempool.h - for the definition of mempool struct and the mempool
> create function.
>
> Signed-off-by: Bruce Richardson 
> ---
>   lib/librte_kni/rte_kni.h | 2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/lib/librte_kni/rte_kni.h b/lib/librte_kni/rte_kni.h
> index 98edd72..44240fe 100644
> --- a/lib/librte_kni/rte_kni.h
> +++ b/lib/librte_kni/rte_kni.h
> @@ -47,6 +47,8 @@
>*/
>   
>   #include 
> +#include 
> +#include 
>   
>   #include 
>   

A fwd declaration of struct rte_mempool would be sufficient, but

Acked-by: Marc Sune 


[dpdk-dev] [PATCH 1/2] eal: add missing include to rte_pci.h

2015-05-28 Thread Marc Sune


On 25/05/15 14:23, Bruce Richardson wrote:
> rte_pci.h depends upon stdio.h for the definition of the FILE type. Add
> in #include  to the file to satisfy this dependency in cases
> where the including C file does not already include stdio.
>
> Signed-off-by: Bruce Richardson 
> ---
>   lib/librte_eal/common/include/rte_pci.h | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/lib/librte_eal/common/include/rte_pci.h 
> b/lib/librte_eal/common/include/rte_pci.h
> index 223d3cd..a346532 100644
> --- a/lib/librte_eal/common/include/rte_pci.h
> +++ b/lib/librte_eal/common/include/rte_pci.h
> @@ -74,6 +74,7 @@
>   extern "C" {
>   #endif
>   
> +#include 
>   #include 
>   #include 
>   #include 

Acked-by: Marc Sune 


[dpdk-dev] [PATCH 1/4] kni: add function to query the name of a kni object

2015-05-27 Thread Marc Sune


On 27/05/15 15:55, Bruce Richardson wrote:
> On Wed, May 27, 2015 at 03:52:34PM +0200, Marc Sune wrote:
>>
>> On 27/05/15 15:47, Bruce Richardson wrote:
>>> When a KNI object is created, a name is assigned to it which is stored
>>> internally. There is also an API function to look up a KNI object by
>>> name, but there is no API to query the current name of an existing
>>> KNI object. This patch adds just such an API.
>>>
>>> Signed-off-by: Bruce Richardson 
>>> ---
>>>   lib/librte_kni/rte_kni.c   |  6 ++
>>>   lib/librte_kni/rte_kni.h   | 10 ++
>>>   lib/librte_kni/rte_kni_version.map |  1 +
>>>   3 files changed, 17 insertions(+)
>>>
>>> diff --git a/lib/librte_kni/rte_kni.c b/lib/librte_kni/rte_kni.c
>>> index 4e70fa0..c5a0089 100644
>>> --- a/lib/librte_kni/rte_kni.c
>>> +++ b/lib/librte_kni/rte_kni.c
>>> @@ -674,6 +674,12 @@ rte_kni_get(const char *name)
>>> return NULL;
>>>   }
>>> +const char *
>>> +rte_kni_get_name(const struct rte_kni *kni)
>>> +{
>>> +   return kni->name;
>>> +}
>> Since a pointer to the kni context (struct rte_kni) is exposed to the user
>> (rte_kni_get() and rte_kni_alloc ()), and the field is directly in the
>> struct, is this API call really necessary? I would only see this necessary
>> if the API would only expose a handle, like a port_id for ethdev
>>
>> Marc
> The structure definition is in rte_kni.c, not in the header file, so 
> applications
> can't read the name directly. In other words, the create API just exposes a 
> handle.
> [The structure in the header is the conf structure, not the full kni struct]

Ops, you are right. I overlooked that. What about:

extern void rte_kni_get_config(const struct rte_kni *kni, struct 
rte_kni_conf* conf);

which fills in (copies) the fields of conf would allow to recover the 
original configuration, including the name? It is closer 
rte_eth_dev_info_get (unfortunately rte_kni_info_get is taken by the 
deprecated API), and would work if we add more params to rte_kni_conf.

Thanks
marc

> /Bruce
>
>>> +
>>>   /*
>>>* It is deprecated and just for backward compatibility.
>>>*/
>>> diff --git a/lib/librte_kni/rte_kni.h b/lib/librte_kni/rte_kni.h
>>> index 44240fe..0c74251 100644
>>> --- a/lib/librte_kni/rte_kni.h
>>> +++ b/lib/librte_kni/rte_kni.h
>>> @@ -248,6 +248,16 @@ extern uint8_t rte_kni_get_port_id(struct rte_kni 
>>> *kni) \
>>>   extern struct rte_kni *rte_kni_get(const char *name);
>>>   /**
>>> + * Get the name given to a KNI device
>>> + *
>>> + * @param kni
>>> + *   The KNI instance to query
>>> + * @return
>>> + *   The pointer to the KNI name
>>> + */
>>> +extern const char *rte_kni_get_name(const struct rte_kni *kni);
>>> +
>>> +/**
>>>* Get the KNI context of the specific port.
>>>*
>>>* Note: It is deprecated and just for backward compatibility.
>>> diff --git a/lib/librte_kni/rte_kni_version.map 
>>> b/lib/librte_kni/rte_kni_version.map
>>> index b0bbf4d..e5e4e1b 100644
>>> --- a/lib/librte_kni/rte_kni_version.map
>>> +++ b/lib/librte_kni/rte_kni_version.map
>>> @@ -6,6 +6,7 @@ DPDK_2.0 {
>>> rte_kni_create;
>>> rte_kni_get;
>>> rte_kni_get_port_id;
>>> +   rte_kni_get_name;
>>> rte_kni_handle_request;
>>> rte_kni_info_get;
>>> rte_kni_init;



[dpdk-dev] [PATCH 1/4] kni: add function to query the name of a kni object

2015-05-27 Thread Marc Sune


On 27/05/15 15:47, Bruce Richardson wrote:
> When a KNI object is created, a name is assigned to it which is stored
> internally. There is also an API function to look up a KNI object by
> name, but there is no API to query the current name of an existing
> KNI object. This patch adds just such an API.
>
> Signed-off-by: Bruce Richardson 
> ---
>   lib/librte_kni/rte_kni.c   |  6 ++
>   lib/librte_kni/rte_kni.h   | 10 ++
>   lib/librte_kni/rte_kni_version.map |  1 +
>   3 files changed, 17 insertions(+)
>
> diff --git a/lib/librte_kni/rte_kni.c b/lib/librte_kni/rte_kni.c
> index 4e70fa0..c5a0089 100644
> --- a/lib/librte_kni/rte_kni.c
> +++ b/lib/librte_kni/rte_kni.c
> @@ -674,6 +674,12 @@ rte_kni_get(const char *name)
>   return NULL;
>   }
>   
> +const char *
> +rte_kni_get_name(const struct rte_kni *kni)
> +{
> + return kni->name;
> +}

Since a pointer to the kni context (struct rte_kni) is exposed to the 
user (rte_kni_get() and rte_kni_alloc ()), and the field is directly in 
the struct, is this API call really necessary? I would only see this 
necessary if the API would only expose a handle, like a port_id for ethdev

Marc

> +
>   /*
>* It is deprecated and just for backward compatibility.
>*/
> diff --git a/lib/librte_kni/rte_kni.h b/lib/librte_kni/rte_kni.h
> index 44240fe..0c74251 100644
> --- a/lib/librte_kni/rte_kni.h
> +++ b/lib/librte_kni/rte_kni.h
> @@ -248,6 +248,16 @@ extern uint8_t rte_kni_get_port_id(struct rte_kni *kni) \
>   extern struct rte_kni *rte_kni_get(const char *name);
>   
>   /**
> + * Get the name given to a KNI device
> + *
> + * @param kni
> + *   The KNI instance to query
> + * @return
> + *   The pointer to the KNI name
> + */
> +extern const char *rte_kni_get_name(const struct rte_kni *kni);
> +
> +/**
>* Get the KNI context of the specific port.
>*
>* Note: It is deprecated and just for backward compatibility.
> diff --git a/lib/librte_kni/rte_kni_version.map 
> b/lib/librte_kni/rte_kni_version.map
> index b0bbf4d..e5e4e1b 100644
> --- a/lib/librte_kni/rte_kni_version.map
> +++ b/lib/librte_kni/rte_kni_version.map
> @@ -6,6 +6,7 @@ DPDK_2.0 {
>   rte_kni_create;
>   rte_kni_get;
>   rte_kni_get_port_id;
> + rte_kni_get_name;
>   rte_kni_handle_request;
>   rte_kni_info_get;
>   rte_kni_init;



[dpdk-dev] [PATCH v2 1/2] Added ETH_SPEED_CAP bitmap in rte_eth_dev_info

2015-05-27 Thread Marc Sune


On 27/05/15 06:02, Thomas Monjalon wrote:
> Hi Marc,
>
> 2015-05-26 21:50, Marc Sune:
>> Added constants and bitmap to struct rte_eth_dev_info to be used by PMDs.
>>
>> Signed-off-by: Marc Sune 
> [...]
>> +/**
>> + * Device supported speeds
>> + */
>> +#define ETH_SPEED_CAP_NOT_PHY   (0)  /*< No phy media > */
> Why not starting with lower values? Some new drivers may be interested
> by lower speed.

Ok, but which values? 1Mbps FD/HD? Even lower than that?

If you have some NIC(s) in mind with lower values, please point me to 
that and I will collect the missing speeds.

>
>> +#define ETH_SPEED_CAP_10M_HD(1 << 0)  /*< 10 Mbps half-duplex> */
>> +#define ETH_SPEED_CAP_10M_FD(1 << 1)  /*< 10 Mbps full-duplex> */
>> +#define ETH_SPEED_CAP_100M_HD   (1 << 2)  /*< 100 Mbps half-duplex> */
>> +#define ETH_SPEED_CAP_100M_FD   (1 << 3)  /*< 100 Mbps full-duplex> */
>> +#define ETH_SPEED_CAP_1G(1 << 4)  /*< 1 Gbps > */
>> +#define ETH_SPEED_CAP_2_5G  (1 << 5)  /*< 2.5 Gbps > */
>> +#define ETH_SPEED_CAP_5G(1 << 6)  /*< 5 Gbps > */
>> +#define ETH_SPEED_CAP_10G   (1 << 7)  /*< 10 Mbps > */
>> +#define ETH_SPEED_CAP_20G   (1 << 8)  /*< 20 Gbps > */
>> +#define ETH_SPEED_CAP_25G   (1 << 9)  /*< 25 Gbps > */
>> +#define ETH_SPEED_CAP_40G   (1 << 10)  /*< 40 Gbps > */
>> +#define ETH_SPEED_CAP_50G   (1 << 11)  /*< 50 Gbps > */
>> +#define ETH_SPEED_CAP_56G   (1 << 12)  /*< 56 Gbps > */
>> +#define ETH_SPEED_CAP_100G  (1 << 13)  /*< 100 Gbps > */
> We should note that rte_eth_link is using ETH_LINK_SPEED_* constants
> which are not some bitmaps so we have to create these new constants.

Yes, I can add that to the patch description (1/2).

> Furthermore, rte_eth_link.link_speed is an uint16_t so it is limited
> to 40G. Should we use some constant bitmaps here also?

I also thought about converting link_speed into a bitmap to unify the 
constants before starting the patch (there is redundancy), but I wanted 
to be minimally invasive; changing link to a bitmap can break existing apps.

I can also merge them if we think is a better idea.
> What about removing _CAP suffix from your constants?

I added the suffix to make clearer the distinction with link speeds. I 
can remove it if we merge both or if we consider it is not necessary.

>
> [...]
>> +uint32_t speed_capa;  /**< Supported speeds bitmap (ETH_SPEED_CAP_). */
> If the constants are ETH_SPEED_CAP, why not wording this variable speed_cap?

I followed the convention of the existing rx/tx offload capability bitmaps:

marc at dev:~/git/bisdn/msune/xdpd/libs/dpdk/lib$ grep _capa\; * -R
librte_ether/rte_ethdev.h:uint32_t rx_offload_capa; /**< Device RX 
offload capabilities. */
librte_ether/rte_ethdev.h:uint32_t tx_offload_capa; /**< Device TX 
offload capabilities. */

I am fine with speed_cap or speed_caps, but I think we should have some 
consistency on how we name bitmaps.

If we would want to make the bitmaps more explicit, we could define some 
helper typedefs in EAL:

typedef uint16_t bitmap16_t;
typedef uint32_t bitmap32_t;
typedef uint64_t bitmap64_t;

and replace the bitmaps of the structs, again specially the ones used by 
the users.

marc

>



[dpdk-dev] [PATCH v2 2/2] Filling speed capability bitmaps in the PMDs

2015-05-27 Thread Marc Sune


On 26/05/15 23:20, Igor Ryzhov wrote:
> Hello, Marc!
>
> You swapped values for X710 and XL710 - you use 1G and 10G for XL710, 10G and 
> 40G for X710.

Thanks, I will fix that in v3. This is why I was saying in the RFC patch 
that it needed to be carefully reviewed.

marc

>
> Best regards,
> Igor
>
>> 26 ??? 2015 ?., ? 22:50, Marc Sune  ???(?):
>>
>> Added speed capabilities to all pmds supporting physical NICs:
>>
>> * e1000
>> * ixgbe
>> * i40
>> * mlx4
>> * fm10k
>>
>> Signed-off-by: Marc Sune 
>> ---
>> drivers/net/e1000/em_ethdev.c|  6 ++
>> drivers/net/e1000/igb_ethdev.c   |  6 ++
>> drivers/net/fm10k/fm10k_ethdev.c |  3 +++
>> drivers/net/i40e/i40e_ethdev.c   |  9 +
>> drivers/net/ixgbe/ixgbe_ethdev.c | 10 ++
>> drivers/net/mlx4/mlx4.c  |  6 ++
>> 6 files changed, 40 insertions(+)
>>
>> diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
>> index d28030e..8e25cfa 100644
>> --- a/drivers/net/e1000/em_ethdev.c
>> +++ b/drivers/net/e1000/em_ethdev.c
>> @@ -883,6 +883,12 @@ eth_em_infos_get(struct rte_eth_dev *dev, struct 
>> rte_eth_dev_info *dev_info)
>>
>>  dev_info->max_rx_queues = 1;
>>  dev_info->max_tx_queues = 1;
>> +
>> +dev_info->speed_capa = ETH_SPEED_CAP_10M_HD |
>> +ETH_SPEED_CAP_10M_FD |
>> +ETH_SPEED_CAP_100M_HD |
>> +ETH_SPEED_CAP_100M_FD |
>> +ETH_SPEED_CAP_1G;
>> }
>>
>> /* return 0 means link status changed, -1 means not changed */
>> diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
>> index e4b370d..424ad6f 100644
>> --- a/drivers/net/e1000/igb_ethdev.c
>> +++ b/drivers/net/e1000/igb_ethdev.c
>> @@ -1398,6 +1398,12 @@ eth_igb_infos_get(struct rte_eth_dev *dev, struct 
>> rte_eth_dev_info *dev_info)
>>  },
>>  .txq_flags = 0,
>>  };
>> +
>> +dev_info->speed_capa = ETH_SPEED_CAP_10M_HD |
>> +ETH_SPEED_CAP_10M_FD |
>> +ETH_SPEED_CAP_100M_HD |
>> +ETH_SPEED_CAP_100M_FD |
>> +ETH_SPEED_CAP_1G;
>> }
>>
>> static void
>> diff --git a/drivers/net/fm10k/fm10k_ethdev.c 
>> b/drivers/net/fm10k/fm10k_ethdev.c
>> index 275c19c..e97b857 100644
>> --- a/drivers/net/fm10k/fm10k_ethdev.c
>> +++ b/drivers/net/fm10k/fm10k_ethdev.c
>> @@ -791,6 +791,9 @@ fm10k_dev_infos_get(struct rte_eth_dev *dev,
>>  ETH_TXQ_FLAGS_NOOFFLOADS,
>>  };
>>
>> +dev_info->speed_capa = ETH_SPEED_CAP_1G | ETH_SPEED_CAP_2_5G |
>> +ETH_SPEED_CAP_10G | ETH_SPEED_CAP_25G |
>> +ETH_SPEED_CAP_40G | ETH_SPEED_CAP_100G;
>> }
>>
>> static int
>> diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
>> index fb64027..5e9db6b 100644
>> --- a/drivers/net/i40e/i40e_ethdev.c
>> +++ b/drivers/net/i40e/i40e_ethdev.c
>> @@ -1519,6 +1519,7 @@ static void
>> i40e_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
>> {
>>  struct i40e_pf *pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
>> +struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
>>  struct i40e_vsi *vsi = pf->main_vsi;
>>
>>  dev_info->max_rx_queues = vsi->nb_qps;
>> @@ -1574,6 +1575,14 @@ i40e_dev_info_get(struct rte_eth_dev *dev, struct 
>> rte_eth_dev_info *dev_info)
>>  dev_info->max_rx_queues += dev_info->vmdq_queue_num;
>>  dev_info->max_tx_queues += dev_info->vmdq_queue_num;
>>  }
>> +
>> +if (i40e_is_40G_device(hw->device_id))
>> +/* For XL710 */
>> +dev_info->speed_capa = ETH_SPEED_CAP_1G | ETH_SPEED_CAP_10G;
>> +else
>> +/* For X710 */
>> +dev_info->speed_capa = ETH_SPEED_CAP_10G | ETH_SPEED_CAP_40G;
>> +
>> }
>>
>> static int
>> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c 
>> b/drivers/net/ixgbe/ixgbe_ethdev.c
>> index 0d9f9b2..78b13a8 100644
>> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
>> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
>> @@ -2054,6 +2054,16 @@ ixgbe_dev_info_get(str

[dpdk-dev] [PATCH v2 2/2] Filling speed capability bitmaps in the PMDs

2015-05-26 Thread Marc Sune
Added speed capabilities to all pmds supporting physical NICs:

* e1000
* ixgbe
* i40
* mlx4
* fm10k

Signed-off-by: Marc Sune 
---
 drivers/net/e1000/em_ethdev.c|  6 ++
 drivers/net/e1000/igb_ethdev.c   |  6 ++
 drivers/net/fm10k/fm10k_ethdev.c |  3 +++
 drivers/net/i40e/i40e_ethdev.c   |  9 +
 drivers/net/ixgbe/ixgbe_ethdev.c | 10 ++
 drivers/net/mlx4/mlx4.c  |  6 ++
 6 files changed, 40 insertions(+)

diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index d28030e..8e25cfa 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -883,6 +883,12 @@ eth_em_infos_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)

dev_info->max_rx_queues = 1;
dev_info->max_tx_queues = 1;
+
+   dev_info->speed_capa = ETH_SPEED_CAP_10M_HD |
+   ETH_SPEED_CAP_10M_FD |
+   ETH_SPEED_CAP_100M_HD |
+   ETH_SPEED_CAP_100M_FD |
+   ETH_SPEED_CAP_1G;
 }

 /* return 0 means link status changed, -1 means not changed */
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index e4b370d..424ad6f 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -1398,6 +1398,12 @@ eth_igb_infos_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
},
.txq_flags = 0,
};
+
+   dev_info->speed_capa = ETH_SPEED_CAP_10M_HD |
+   ETH_SPEED_CAP_10M_FD |
+   ETH_SPEED_CAP_100M_HD |
+   ETH_SPEED_CAP_100M_FD |
+   ETH_SPEED_CAP_1G;
 }

 static void
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index 275c19c..e97b857 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -791,6 +791,9 @@ fm10k_dev_infos_get(struct rte_eth_dev *dev,
ETH_TXQ_FLAGS_NOOFFLOADS,
};

+   dev_info->speed_capa = ETH_SPEED_CAP_1G | ETH_SPEED_CAP_2_5G |
+   ETH_SPEED_CAP_10G | ETH_SPEED_CAP_25G |
+   ETH_SPEED_CAP_40G | ETH_SPEED_CAP_100G;
 }

 static int
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index fb64027..5e9db6b 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -1519,6 +1519,7 @@ static void
 i40e_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
 {
struct i40e_pf *pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
+   struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
struct i40e_vsi *vsi = pf->main_vsi;

dev_info->max_rx_queues = vsi->nb_qps;
@@ -1574,6 +1575,14 @@ i40e_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
dev_info->max_rx_queues += dev_info->vmdq_queue_num;
dev_info->max_tx_queues += dev_info->vmdq_queue_num;
}
+
+   if (i40e_is_40G_device(hw->device_id))
+   /* For XL710 */
+   dev_info->speed_capa = ETH_SPEED_CAP_1G | ETH_SPEED_CAP_10G;
+   else
+   /* For X710 */
+   dev_info->speed_capa = ETH_SPEED_CAP_10G | ETH_SPEED_CAP_40G;
+
 }

 static int
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 0d9f9b2..78b13a8 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -2054,6 +2054,16 @@ ixgbe_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
};
dev_info->reta_size = ETH_RSS_RETA_SIZE_128;
dev_info->flow_type_rss_offloads = IXGBE_RSS_OFFLOAD_ALL;
+
+   dev_info->speed_capa = ETH_SPEED_CAP_1G | ETH_SPEED_CAP_10G;
+
+   if (hw->mac.type == ixgbe_mac_X540 ||
+   hw->mac.type == ixgbe_mac_X540_vf ||
+   hw->mac.type == ixgbe_mac_X550 ||
+   hw->mac.type == ixgbe_mac_X550_vf)
+
+   dev_info->speed_capa |= ETH_SPEED_CAP_100M_FD |
+   ETH_SPEED_CAP_100M_HD;
 }

 static void
diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index f915bc1..d4442fb 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -3482,6 +3482,12 @@ mlx4_dev_infos_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *info)
info->max_rx_queues = max;
info->max_tx_queues = max;
info->max_mac_addrs = elemof(priv->mac);
+
+   info->speed_capa = ETH_SPEED_CAP_10G | ETH_SPEED_CAP_20G |
+   ETH_SPEED_CAP_25G | ETH_SPEED_CAP_40G |
+   ET

[dpdk-dev] [PATCH v2 1/2] Added ETH_SPEED_CAP bitmap in rte_eth_dev_info

2015-05-26 Thread Marc Sune
Added constants and bitmap to struct rte_eth_dev_info to be used by PMDs.

Signed-off-by: Marc Sune 
---
 lib/librte_ether/rte_ethdev.h | 24 
 1 file changed, 24 insertions(+)

diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 16dbe00..f57676b 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -900,6 +900,29 @@ struct rte_eth_conf {
 #define DEV_TX_OFFLOAD_UDP_TSO 0x0040
 #define DEV_TX_OFFLOAD_OUTER_IPV4_CKSUM 0x0080 /**< Used for tunneling 
packet. */

+/**
+ * Device supported speeds
+ */
+#define ETH_SPEED_CAP_NOT_PHY  (0)  /*< No phy media > */
+#define ETH_SPEED_CAP_10M_HD   (1 << 0)  /*< 10 Mbps half-duplex> */
+#define ETH_SPEED_CAP_10M_FD   (1 << 1)  /*< 10 Mbps full-duplex> */
+#define ETH_SPEED_CAP_100M_HD  (1 << 2)  /*< 100 Mbps half-duplex> */
+#define ETH_SPEED_CAP_100M_FD  (1 << 3)  /*< 100 Mbps full-duplex> */
+#define ETH_SPEED_CAP_1G   (1 << 4)  /*< 1 Gbps > */
+#define ETH_SPEED_CAP_2_5G (1 << 5)  /*< 2.5 Gbps > */
+#define ETH_SPEED_CAP_5G   (1 << 6)  /*< 5 Gbps > */
+#define ETH_SPEED_CAP_10G  (1 << 7)  /*< 10 Mbps > */
+#define ETH_SPEED_CAP_20G  (1 << 8)  /*< 20 Gbps > */
+#define ETH_SPEED_CAP_25G  (1 << 9)  /*< 25 Gbps > */
+#define ETH_SPEED_CAP_40G  (1 << 10)  /*< 40 Gbps > */
+#define ETH_SPEED_CAP_50G  (1 << 11)  /*< 50 Gbps > */
+#define ETH_SPEED_CAP_56G  (1 << 12)  /*< 56 Gbps > */
+#define ETH_SPEED_CAP_100G (1 << 13)  /*< 100 Gbps > */
+
+
+/**
+ * Ethernet device information
+ */
 struct rte_eth_dev_info {
struct rte_pci_device *pci_dev; /**< Device PCI information. */
const char *driver_name; /**< Device Driver name. */
@@ -925,6 +948,7 @@ struct rte_eth_dev_info {
uint16_t vmdq_queue_base; /**< First queue ID for VMDQ pools. */
uint16_t vmdq_queue_num;  /**< Queue number for VMDQ pools. */
uint16_t vmdq_pool_base;  /**< First ID of VMDQ pools. */
+   uint32_t speed_capa;  /**< Supported speeds bitmap (ETH_SPEED_CAP_). */
 };

 /** Maximum name length for extended statistics counters */
-- 
2.1.4



[dpdk-dev] [PATCH v2 0/2] ethdev: add port speed capability bitmap

2015-05-26 Thread 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:

http://dpdk.org/ml/archives/dev/2013-August/000412.html

However, i) doing string comparisons is annoying, and can silently
break existing applications if PMDs change their names ii) it does not
provide all the supported capabilities of the ethdev iii) for some drivers it
is impossible determine correctly the (max) speed by the application
(e.g. in i40, distinguish between XL710 and X710).

This small patch adds speed_capa bitmap in rte_eth_dev_info, which is filled
by the PMDs according to the physical device capabilities.

v2: rebase, converted speed_capa into 32 bits bitmap, fixed alignment
(checkpatch).

Marc Sune (2):
  Added ETH_SPEED_CAP bitmap in rte_eth_dev_info
  Filling speed capability bitmaps in the PMDs

 drivers/net/e1000/em_ethdev.c|  6 ++
 drivers/net/e1000/igb_ethdev.c   |  6 ++
 drivers/net/fm10k/fm10k_ethdev.c |  3 +++
 drivers/net/i40e/i40e_ethdev.c   |  9 +
 drivers/net/ixgbe/ixgbe_ethdev.c | 10 ++
 drivers/net/mlx4/mlx4.c  |  6 ++
 lib/librte_ether/rte_ethdev.h| 24 
 7 files changed, 64 insertions(+)

-- 
2.1.4



[dpdk-dev] [RFC PATCH 1/2] Added ETH_SPEED_CAP bitmap in rte_eth_dev_info

2015-05-26 Thread Marc Sune


On 26/05/15 17:03, Stephen Hemminger wrote:
> On Tue, 12 May 2015 01:45:45 +0200
> Marc Sune  wrote:
>
>> +/**
>> + * Ethernet device information
>> + */
>>   struct rte_eth_dev_info {
>>  struct rte_pci_device *pci_dev; /**< Device PCI information. */
>>  const char *driver_name; /**< Device Driver name. */
>> @@ -924,6 +947,7 @@ struct rte_eth_dev_info {
>>  uint16_t vmdq_queue_base; /**< First queue ID for VMDQ pools. */
>>  uint16_t vmdq_queue_num;  /**< Queue number for VMDQ pools. */
>>  uint16_t vmdq_pool_base;  /**< First ID of VMDQ pools. */
>> +uint16_t speed_capa;  /**< Supported speeds bitmap. */
>>   };
>>   
> Since you are changing size of key structure, this is an ABI change.

Yes. This means target would be 2.2?

I will send the new version anyway to further discuss, and will rebase 
again once necessary.

Marc


[dpdk-dev] [RFC PATCH 0/2] ethdev: add port speed capability bitmap

2015-05-25 Thread Marc Sune
Any objections to this one? Otherwise I will rebase and propose a formal 
patch

marc

On 12/05/15 01:45, Marc Sune wrote:
> The current rte_eth_dev_info abstraction does not provide any mechanism to
> know 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.html
>
> However, i) doing string comparisons is annoying, and can silently
> break existing applications if PMDs change their names ii) it does not
> provide all the supported capabilities of the ethdev iii) for some drivers it
> is impossible determine correctly the (max) speed by the application
> (e.g. in i40, distinguish between XL710 and X710).
>
> This small patch adds speed_capa bitmap in rte_eth_dev_info, which is filled
> by the PMDs according to the physical device capabilities.
>
> WARNING: the patch is only tested with e1000s, and should be reviewed for
> accuracy.
>
>
> Marc Sune (2):
>Added ETH_SPEED_CAP bitmap in rte_eth_dev_info
>Filling speed capability bitmaps in the PMDs
>
>   lib/librte_ether/rte_ethdev.h   | 24 
>   lib/librte_pmd_e1000/em_ethdev.c|  6 ++
>   lib/librte_pmd_e1000/igb_ethdev.c   |  6 ++
>   lib/librte_pmd_fm10k/fm10k_ethdev.c |  3 +++
>   lib/librte_pmd_i40e/i40e_ethdev.c   |  9 +
>   lib/librte_pmd_ixgbe/ixgbe_ethdev.c | 10 ++
>   lib/librte_pmd_mlx4/mlx4.c  |  6 ++
>   7 files changed, 64 insertions(+)
>



[dpdk-dev] [RFC PATCHv2 0/2] pktdev as wrapper type

2015-05-20 Thread Marc Sune


On 20/05/15 12:28, Neil Horman wrote:
> On Wed, May 20, 2015 at 12:05:00PM +0200, Marc Sune wrote:
>>
>> On 20/05/15 10:31, Thomas Monjalon wrote:
>>> 2015-05-19 12:31, Bruce Richardson:
>>>> On Mon, May 11, 2015 at 05:29:39PM +0100, Bruce Richardson wrote:
>>>>> Hi all,
>>>>>
>>>>> after a small amount of offline discussion with Marc Sune, here is an
>>>>> alternative proposal for a higher-level interface - aka pktdev - to allow 
>>>>> a
>>>>> common Rx/Tx API across device types handling mbufs [for now, ethdev, ring
>>>>> and KNI]. The key code is in the first patch fo the set - the second is an
>>>>> example of a trivial usecase.
>>>>>
>>>>> What is different about this to previously:
>>>>> * wrapper class, so no changes to any existing ring, ethdev 
>>>>> implementations
>>>>> * use of function pointers for RX/TX with an API that maps to ethdev
>>>>>- this means there is little/no additional overhead for ethdev calls
>>>>>- inline special case for rings, to accelerate that. Since we are at a
>>>>>  higher level, we can special case process some things if 
>>>>> appropriate. This
>>>>>  means the impact to ring ops is one (predictable) branch per burst
>>>>> * elimination of the queue abstraction. For the ring and KNI, there is no
>>>>>concept of queues, so we just wrap the functions directly (no need 
>>>>> even for
>>>>>wrapper functions, the api's match so we can call directly). This also
>>>>>means:
>>>>>- adding in features per-queue, is far easier as we don't need to 
>>>>> worry about
>>>>>  having arrays of multiple queues. For example:
>>>>>- adding in buffering on TX (or RX) is easier since again we only have 
>>>>> a
>>>>>  single queue.
>>>>> * thread safety is made easier using a wrapper. For a MP ring, we can 
>>>>> create
>>>>>multiple pktdevs around it, and each thread will then be able to use 
>>>>> their
>>>>>own copy, with their own buffering etc.
>>>>>
>>>>> However, at this point, I'm just looking for general feedback on this as 
>>>>> an
>>>>> approach. I think it's quite flexible - even more so than the earlier 
>>>>> proposal
>>>>> we had. It's less proscriptive and doesn't make any demands on any other 
>>>>> libs.
>>>>>
>>>>> Comments/thoughts welcome.
>>>> Any comments on this RFC before I see about investing further time in it 
>>>> to clean
>>>> it up a bit and submit as a non-RFC patchset for merge in 2.1?
>>> I would say there are 2 possible approaches for KNI and ring handling:
>>> 1/ You Bruce, Marc and Keith are advocating for a layer on top of ethdev,
>>> ring, KNI and possibly other devices, which uses mbuf. The set of functions
>>> is simpler than ethdev but the data structure is mbuf which is related to
>>> ethdev layer.
>>> 2/ Konstantin and Neil talked about keeping mbuf for ethdev layer and 
>>> related
>>> libs only. Ring and KNI could have an ethdev API with a reduced set of
>>> implemented functions. Crypto devices could adopt a specific crypto API and
>>> an ethdev API at the same time.
>> I don't fully understand which APIs you meant by non-ethdev. This pktdev
>> wrapper proposal abstracts RX and TX functions only, and all of these are
>> using mbufs as the packet buffer abstraction right now anyway (ethdev).
>>
> He's referring to future device classes (like crypto devices), which 
> ostensibly
> would make use of the pktdev API.  My argument (and I think Thomas') is that 
> if
> a bit of hardware can be made to operate as a packet sending/receiving device,
> then its just as reasonable to use the existing ethdev api rather than some
> other restricted version of it (pktdev)
>
>> This approach does not preclude that different libraries expose other API
>> calls. In fact they will have to; setup the port/device ... It is just a
>> higher level API, so that you don't have to check the type of port in your
>> DPDK application I/O loop, minimizing user's code.
>>
> No argument there.  But if thats the case (and I agree that it is), an
> application will implicitly have to know what what type of device it is, 
> because
> it

[dpdk-dev] [RFC PATCHv2 0/2] pktdev as wrapper type

2015-05-20 Thread Marc Sune


On 20/05/15 10:31, Thomas Monjalon wrote:
> 2015-05-19 12:31, Bruce Richardson:
>> On Mon, May 11, 2015 at 05:29:39PM +0100, Bruce Richardson wrote:
>>> Hi all,
>>>
>>> after a small amount of offline discussion with Marc Sune, here is an
>>> alternative proposal for a higher-level interface - aka pktdev - to allow a
>>> common Rx/Tx API across device types handling mbufs [for now, ethdev, ring
>>> and KNI]. The key code is in the first patch fo the set - the second is an
>>> example of a trivial usecase.
>>>
>>> What is different about this to previously:
>>> * wrapper class, so no changes to any existing ring, ethdev implementations
>>> * use of function pointers for RX/TX with an API that maps to ethdev
>>>- this means there is little/no additional overhead for ethdev calls
>>>- inline special case for rings, to accelerate that. Since we are at a
>>>  higher level, we can special case process some things if appropriate. 
>>> This
>>>  means the impact to ring ops is one (predictable) branch per burst
>>> * elimination of the queue abstraction. For the ring and KNI, there is no
>>>concept of queues, so we just wrap the functions directly (no need even 
>>> for
>>>wrapper functions, the api's match so we can call directly). This also
>>>means:
>>>- adding in features per-queue, is far easier as we don't need to worry 
>>> about
>>>  having arrays of multiple queues. For example:
>>>- adding in buffering on TX (or RX) is easier since again we only have a
>>>  single queue.
>>> * thread safety is made easier using a wrapper. For a MP ring, we can create
>>>multiple pktdevs around it, and each thread will then be able to use 
>>> their
>>>own copy, with their own buffering etc.
>>>
>>> However, at this point, I'm just looking for general feedback on this as an
>>> approach. I think it's quite flexible - even more so than the earlier 
>>> proposal
>>> we had. It's less proscriptive and doesn't make any demands on any other 
>>> libs.
>>>
>>> Comments/thoughts welcome.
>> Any comments on this RFC before I see about investing further time in it to 
>> clean
>> it up a bit and submit as a non-RFC patchset for merge in 2.1?
> I would say there are 2 possible approaches for KNI and ring handling:
> 1/ You Bruce, Marc and Keith are advocating for a layer on top of ethdev,
> ring, KNI and possibly other devices, which uses mbuf. The set of functions
> is simpler than ethdev but the data structure is mbuf which is related to
> ethdev layer.
> 2/ Konstantin and Neil talked about keeping mbuf for ethdev layer and related
> libs only. Ring and KNI could have an ethdev API with a reduced set of
> implemented functions. Crypto devices could adopt a specific crypto API and
> an ethdev API at the same time.

I don't fully understand which APIs you meant by non-ethdev. This pktdev 
wrapper proposal abstracts RX and TX functions only, and all of these 
are using mbufs as the packet buffer abstraction right now anyway (ethdev).

This approach does not preclude that different libraries expose other 
API calls. In fact they will have to; setup the port/device ... It is 
just a higher level API, so that you don't have to check the type of 
port in your DPDK application I/O loop, minimizing user's code.

Or were you in 2) thinking about creating a different "packet buffer" 
abstraction, independent from the ethdev, and then map the different 
port specifics (e.g. mbuf) to this new abstraction?

>
> I feel it's cleaner, more generic and more maintainable to have drivers
> implementing one or several stable APIs instead of having some restricted
> wrappers to update.

This would be a separate library _on top_ of the existing APIs, and it 
has the advantage to simplify the DPDK user's application code when an 
application needs to deal with several types of port, as shown in the 
example that Bruce provided in PATCH #2.

I don't see why this could limit us or make it less maintainable. Of 
course this is an RFC patch; appropriate tests are missing (Bruce I can 
help you on that)

Marc

>
> Comments are welcome.



[dpdk-dev] TX performance regression caused by the mbuf cachline split

2015-05-12 Thread Marc Sune


On 12/05/15 02:28, Marc Sune wrote:
>
>
> On 12/05/15 01:18, Paul Emmerich wrote:
>> Found a really simple solution that almost restores the original 
>> performance: just add a prefetch on alloc. For some reason, I assumed 
>> that this was already done since the troublesome commit I 
>> investigated mentioned something about prefetching... I guess the 
>> commit referred to the hardware prefetcher in the CPU.
>>
>> Adding an explicit prefetch command in the mbuf alloc function gives 
>> a throughput of 12.7/10.35 Mpps in my benchmark with the 
>> simple/full-featured tx path.
>>
>> DPDK 1.7.1 was at 14.1/10.7 Mpps. I guess I can live with that, since 
>> I'm primarily interested in the full-featured path and the drop from 
>> 10.7 to ~10.4 was due to another change.
>
> Maybe a stupid question;
>
> Does the performance of v1.7.1 also improve if you backport this patch 
> to it?

Self answered... split was done in 1.8, so it is indeed stupid.

Marc
>
> Marc
>
>>
>> Patch: https://github.com/dpdk-org/dpdk/pull/2
>> I also sent an email to the mailing list.
>>
>> I also think that the rx-path could also benefit from prefetching 
>> somewhere.
>>
>>
>> Paul
>>
>



[dpdk-dev] TX performance regression caused by the mbuf cachline split

2015-05-12 Thread Marc Sune


On 12/05/15 01:18, Paul Emmerich wrote:
> Found a really simple solution that almost restores the original 
> performance: just add a prefetch on alloc. For some reason, I assumed 
> that this was already done since the troublesome commit I investigated 
> mentioned something about prefetching... I guess the commit referred 
> to the hardware prefetcher in the CPU.
>
> Adding an explicit prefetch command in the mbuf alloc function gives a 
> throughput of 12.7/10.35 Mpps in my benchmark with the 
> simple/full-featured tx path.
>
> DPDK 1.7.1 was at 14.1/10.7 Mpps. I guess I can live with that, since 
> I'm primarily interested in the full-featured path and the drop from 
> 10.7 to ~10.4 was due to another change.

Maybe a stupid question;

Does the performance of v1.7.1 also improve if you backport this patch 
to it?

Marc

>
> Patch: https://github.com/dpdk-org/dpdk/pull/2
> I also sent an email to the mailing list.
>
> I also think that the rx-path could also benefit from prefetching 
> somewhere.
>
>
> Paul
>



[dpdk-dev] [RFC PATCH 2/2] Filling speed capability bitmaps in the PMDs

2015-05-12 Thread Marc Sune
Added speed capabilities to all pmds supporting physical NICs:

* e1000
* ixgbe
* i40
* mlx4
* fm10k

This commit should be revised to ensure accuracy. It is mostly
untested (HW not available).

Signed-off-by: Marc Sune 
---
 lib/librte_pmd_e1000/em_ethdev.c|  6 ++
 lib/librte_pmd_e1000/igb_ethdev.c   |  6 ++
 lib/librte_pmd_fm10k/fm10k_ethdev.c |  3 +++
 lib/librte_pmd_i40e/i40e_ethdev.c   |  9 +
 lib/librte_pmd_ixgbe/ixgbe_ethdev.c | 10 ++
 lib/librte_pmd_mlx4/mlx4.c  |  6 ++
 6 files changed, 40 insertions(+)

diff --git a/lib/librte_pmd_e1000/em_ethdev.c b/lib/librte_pmd_e1000/em_ethdev.c
index da02988..593e182 100644
--- a/lib/librte_pmd_e1000/em_ethdev.c
+++ b/lib/librte_pmd_e1000/em_ethdev.c
@@ -883,6 +883,12 @@ eth_em_infos_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)

dev_info->max_rx_queues = 1;
dev_info->max_tx_queues = 1;
+
+   dev_info->speed_capa = ETH_SPEED_CAP_10M_HD |
+   ETH_SPEED_CAP_10M_FD |
+   ETH_SPEED_CAP_100M_HD |
+   ETH_SPEED_CAP_100M_FD |
+   ETH_SPEED_CAP_1G;
 }

 /* return 0 means link status changed, -1 means not changed */
diff --git a/lib/librte_pmd_e1000/igb_ethdev.c 
b/lib/librte_pmd_e1000/igb_ethdev.c
index 4415155..8b5514f 100644
--- a/lib/librte_pmd_e1000/igb_ethdev.c
+++ b/lib/librte_pmd_e1000/igb_ethdev.c
@@ -1398,6 +1398,12 @@ eth_igb_infos_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
},
.txq_flags = 0,
};
+
+   dev_info->speed_capa = ETH_SPEED_CAP_10M_HD |
+   ETH_SPEED_CAP_10M_FD |
+   ETH_SPEED_CAP_100M_HD |
+   ETH_SPEED_CAP_100M_FD |
+   ETH_SPEED_CAP_1G;
 }

 static void
diff --git a/lib/librte_pmd_fm10k/fm10k_ethdev.c 
b/lib/librte_pmd_fm10k/fm10k_ethdev.c
index 275c19c..e97b857 100644
--- a/lib/librte_pmd_fm10k/fm10k_ethdev.c
+++ b/lib/librte_pmd_fm10k/fm10k_ethdev.c
@@ -791,6 +791,9 @@ fm10k_dev_infos_get(struct rte_eth_dev *dev,
ETH_TXQ_FLAGS_NOOFFLOADS,
};

+   dev_info->speed_capa = ETH_SPEED_CAP_1G | ETH_SPEED_CAP_2_5G |
+   ETH_SPEED_CAP_10G | ETH_SPEED_CAP_25G |
+   ETH_SPEED_CAP_40G | ETH_SPEED_CAP_100G;
 }

 static int
diff --git a/lib/librte_pmd_i40e/i40e_ethdev.c 
b/lib/librte_pmd_i40e/i40e_ethdev.c
index 43762f2..70675d6 100644
--- a/lib/librte_pmd_i40e/i40e_ethdev.c
+++ b/lib/librte_pmd_i40e/i40e_ethdev.c
@@ -1518,6 +1518,7 @@ static void
 i40e_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
 {
struct i40e_pf *pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
+   struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
struct i40e_vsi *vsi = pf->main_vsi;

dev_info->max_rx_queues = vsi->nb_qps;
@@ -1573,6 +1574,14 @@ i40e_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
dev_info->max_rx_queues += dev_info->vmdq_queue_num;
dev_info->max_tx_queues += dev_info->vmdq_queue_num;
}
+
+   if (i40e_is_40G_device(hw->device_id))
+   /* For XL710 */
+   dev_info->speed_capa = ETH_SPEED_CAP_1G | ETH_SPEED_CAP_10G;
+   else
+   /* For X710 */
+   dev_info->speed_capa = ETH_SPEED_CAP_10G | ETH_SPEED_CAP_40G;
+
 }

 static int
diff --git a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c 
b/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
index 5f9a1cf..1b5de9a 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
+++ b/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
@@ -2054,6 +2054,16 @@ ixgbe_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
};
dev_info->reta_size = ETH_RSS_RETA_SIZE_128;
dev_info->flow_type_rss_offloads = IXGBE_RSS_OFFLOAD_ALL;
+
+   dev_info->speed_capa = ETH_SPEED_CAP_1G | ETH_SPEED_CAP_10G;
+
+   if (hw->mac.type == ixgbe_mac_X540 ||
+   hw->mac.type == ixgbe_mac_X540_vf ||
+   hw->mac.type == ixgbe_mac_X550 ||
+   hw->mac.type == ixgbe_mac_X550_vf)
+
+   dev_info->speed_capa |= ETH_SPEED_CAP_100M_FD |
+   ETH_SPEED_CAP_100M_HD;
 }

 static void
diff --git a/lib/librte_pmd_mlx4/mlx4.c b/lib/librte_pmd_mlx4/mlx4.c
index f915bc1..d4442fb 100644
--- a/lib/librte_pmd_mlx4/mlx4.c
+++ b/lib/librte_pmd_mlx4/mlx4.c
@@ -3482,6 +3482,12 @@ mlx4_dev_infos_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *info)
info->max_rx_queues = max;
info->max_tx_queues = max;
info->max_mac_add

[dpdk-dev] [RFC PATCH 1/2] Added ETH_SPEED_CAP bitmap in rte_eth_dev_info

2015-05-12 Thread Marc Sune
Added constants and bitmap to struct rte_eth_dev_info to be used by PMDs.

Signed-off-by: Marc Sune 
---
 lib/librte_ether/rte_ethdev.h | 24 
 1 file changed, 24 insertions(+)

diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 4648290..05f6e88 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -899,6 +899,29 @@ struct rte_eth_conf {
 #define DEV_TX_OFFLOAD_UDP_TSO 0x0040
 #define DEV_TX_OFFLOAD_OUTER_IPV4_CKSUM 0x0080 /**< Used for tunneling 
packet. */

+/**
+ * Device supported speeds
+ */
+#define ETH_SPEED_CAP_NOT_PHY  (0)  /*< No phy media > */
+#define ETH_SPEED_CAP_10M_HD   (1 << 0)  /*< 10 Mbps half-duplex> */
+#define ETH_SPEED_CAP_10M_FD   (1 << 1)  /*< 10 Mbps full-duplex> */
+#define ETH_SPEED_CAP_100M_HD  (1 << 2)  /*< 100 Mbps half-duplex> */
+#define ETH_SPEED_CAP_100M_FD  (1 << 3)  /*< 100 Mbps full-duplex> */
+#define ETH_SPEED_CAP_1G   (1 << 4)  /*< 1 Gbps > */
+#define ETH_SPEED_CAP_2_5G (1 << 5)  /*< 2.5 Gbps > */
+#define ETH_SPEED_CAP_5G   (1 << 6)  /*< 5 Gbps > */
+#define ETH_SPEED_CAP_10G  (1 << 7)  /*< 10 Mbps > */
+#define ETH_SPEED_CAP_20G  (1 << 8)  /*< 20 Gbps > */
+#define ETH_SPEED_CAP_25G  (1 << 9)  /*< 25 Gbps > */
+#define ETH_SPEED_CAP_40G  (1 << 10)  /*< 40 Gbps > */
+#define ETH_SPEED_CAP_50G  (1 << 11)  /*< 50 Gbps > */
+#define ETH_SPEED_CAP_56G  (1 << 12)  /*< 56 Gbps > */
+#define ETH_SPEED_CAP_100G (1 << 13)  /*< 100 Gbps > */
+
+
+/**
+ * Ethernet device information
+ */
 struct rte_eth_dev_info {
struct rte_pci_device *pci_dev; /**< Device PCI information. */
const char *driver_name; /**< Device Driver name. */
@@ -924,6 +947,7 @@ struct rte_eth_dev_info {
uint16_t vmdq_queue_base; /**< First queue ID for VMDQ pools. */
uint16_t vmdq_queue_num;  /**< Queue number for VMDQ pools. */
uint16_t vmdq_pool_base;  /**< First ID of VMDQ pools. */
+   uint16_t speed_capa;  /**< Supported speeds bitmap. */
 };

 /** Maximum name length for extended statistics counters */
-- 
2.1.4



[dpdk-dev] [RFC PATCH 0/2] ethdev: add port speed capability bitmap

2015-05-12 Thread Marc Sune
The current rte_eth_dev_info abstraction does not provide any mechanism to
know 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.html

However, i) doing string comparisons is annoying, and can silently
break existing applications if PMDs change their names ii) it does not
provide all the supported capabilities of the ethdev iii) for some drivers it
is impossible determine correctly the (max) speed by the application
(e.g. in i40, distinguish between XL710 and X710).

This small patch adds speed_capa bitmap in rte_eth_dev_info, which is filled
by the PMDs according to the physical device capabilities.

WARNING: the patch is only tested with e1000s, and should be reviewed for
accuracy.


Marc Sune (2):
  Added ETH_SPEED_CAP bitmap in rte_eth_dev_info
  Filling speed capability bitmaps in the PMDs

 lib/librte_ether/rte_ethdev.h   | 24 
 lib/librte_pmd_e1000/em_ethdev.c|  6 ++
 lib/librte_pmd_e1000/igb_ethdev.c   |  6 ++
 lib/librte_pmd_fm10k/fm10k_ethdev.c |  3 +++
 lib/librte_pmd_i40e/i40e_ethdev.c   |  9 +
 lib/librte_pmd_ixgbe/ixgbe_ethdev.c | 10 ++
 lib/librte_pmd_mlx4/mlx4.c  |  6 ++
 7 files changed, 64 insertions(+)

-- 
2.1.4



[dpdk-dev] [RFC PATCH 0/2] Move PMDs out of lib directory

2015-05-07 Thread Marc Sune


On 07/05/15 17:35, Bruce Richardson wrote:
> The "lib" directory is getting very crowded, with both general libs and
> poll mode drivers in it. This patch set proposes to move the PMDs out of the
> lib folder and to put them in a separate "pmds" folder. This should help
> with code browse-ability as the number of libs, and pmds increases.
>
> Comments or objections?
>
> Bruce Richardson (2):
>pmds: Use relative rather than absolute paths
>pmds: move pmds from lib to separate pmd dir
>
>   GNUmakefile|2 +-
>   lib/Makefile   |   14 -
>   lib/librte_eal/linuxapp/eal/Makefile   |8 +-
>   lib/librte_pmd_af_packet/Makefile  |   64 -
>   lib/librte_pmd_af_packet/rte_eth_af_packet.c   |  847 ---
>   lib/librte_pmd_af_packet/rte_eth_af_packet.h   |   53 -
>   .../rte_pmd_af_packet_version.map  |7 -
>   lib/librte_pmd_bond/Makefile   |   68 -
>   lib/librte_pmd_bond/rte_eth_bond.h |  366 --
>   lib/librte_pmd_bond/rte_eth_bond_8023ad.c  | 1216 -
>   lib/librte_pmd_bond/rte_eth_bond_8023ad.h  |  222 -
>   lib/librte_pmd_bond/rte_eth_bond_8023ad_private.h  |  308 --
>   lib/librte_pmd_bond/rte_eth_bond_alb.c |  287 -
>   lib/librte_pmd_bond/rte_eth_bond_alb.h |  142 -
>   lib/librte_pmd_bond/rte_eth_bond_api.c |  840 ---
>   lib/librte_pmd_bond/rte_eth_bond_args.c|  278 -
>   lib/librte_pmd_bond/rte_eth_bond_pmd.c | 2269 
>   lib/librte_pmd_bond/rte_eth_bond_private.h |  287 -
>   lib/librte_pmd_bond/rte_eth_bond_version.map   |   22 -
>   lib/librte_pmd_e1000/Makefile  |   99 -
>   lib/librte_pmd_e1000/e1000/README  |   39 -
>   lib/librte_pmd_e1000/e1000/e1000_80003es2lan.c | 1514 --
>   lib/librte_pmd_e1000/e1000/e1000_80003es2lan.h |  100 -
>   lib/librte_pmd_e1000/e1000/e1000_82540.c   |  717 ---
>   lib/librte_pmd_e1000/e1000/e1000_82541.c   | 1268 -
>   lib/librte_pmd_e1000/e1000/e1000_82541.h   |   91 -
>   lib/librte_pmd_e1000/e1000/e1000_82542.c   |  588 --
>   lib/librte_pmd_e1000/e1000/e1000_82543.c   | 1553 --
>   lib/librte_pmd_e1000/e1000/e1000_82543.h   |   56 -
>   lib/librte_pmd_e1000/e1000/e1000_82571.c   | 2026 ---
>   lib/librte_pmd_e1000/e1000/e1000_82571.h   |   65 -
>   lib/librte_pmd_e1000/e1000/e1000_82575.c   | 3639 -
>   lib/librte_pmd_e1000/e1000/e1000_82575.h   |  520 --
>   lib/librte_pmd_e1000/e1000/e1000_api.c | 1357 -
>   lib/librte_pmd_e1000/e1000/e1000_api.h |  167 -
>   lib/librte_pmd_e1000/e1000/e1000_defines.h | 1498 -
>   lib/librte_pmd_e1000/e1000/e1000_hw.h  | 1026 
>   lib/librte_pmd_e1000/e1000/e1000_i210.c| 1000 
>   lib/librte_pmd_e1000/e1000/e1000_i210.h|  110 -
>   lib/librte_pmd_e1000/e1000/e1000_ich8lan.c | 5260 --
>   lib/librte_pmd_e1000/e1000/e1000_ich8lan.h |  313 --
>   lib/librte_pmd_e1000/e1000/e1000_mac.c | 2247 
>   lib/librte_pmd_e1000/e1000/e1000_mac.h |   95 -
>   lib/librte_pmd_e1000/e1000/e1000_manage.c  |  573 --
>   lib/librte_pmd_e1000/e1000/e1000_manage.h  |   95 -
>   lib/librte_pmd_e1000/e1000/e1000_mbx.c |  777 ---
>   lib/librte_pmd_e1000/e1000/e1000_mbx.h |  105 -
>   lib/librte_pmd_e1000/e1000/e1000_nvm.c | 1377 -
>   lib/librte_pmd_e1000/e1000/e1000_nvm.h |   98 -
>   lib/librte_pmd_e1000/e1000/e1000_osdep.c   |   83 -
>   lib/librte_pmd_e1000/e1000/e1000_osdep.h   |  183 -
>   lib/librte_pmd_e1000/e1000/e1000_phy.c | 4273 ---
>   lib/librte_pmd_e1000/e1000/e1000_phy.h |  327 --
>   lib/librte_pmd_e1000/e1000/e1000_regs.h|  685 ---
>   lib/librte_pmd_e1000/e1000/e1000_vf.c  |  586 --
>   lib/librte_pmd_e1000/e1000/e1000_vf.h  |  295 -
>   lib/librte_pmd_e1000/e1000_ethdev.h|  340 --
>   lib/librte_pmd_e1000/e1000_logs.h  |   78 -
>   lib/librte_pmd_e1000/em_ethdev.c   | 1530 --
>   lib/librte_pmd_e1000/em_rxtx.c | 1865 ---
>   lib/librte_pmd_e1000/igb_ethdev.c  | 3656 -
>   lib/librte_pmd_e1000/igb_pf.c  |  511 --
>   lib/librte_pmd_e1000/igb_rxtx.c| 2397 
>   lib/librte_pmd_e1000/rte_pmd_e1000_version.map |4 -
>   lib/librte_pmd_enic/LICENSE|   27 -
>   lib/librte_pmd_enic/Makefile   |   71 -
>   lib/librte_pmd_enic/enic.h |  200 -
>   lib/librte_pmd_enic/enic_clsf.c|  

  1   2   >