[dpdk-dev] New mailing list for users

[Thomas Monjalon]

Hello,

Following this discussion:
http://dpdk.org/ml/archives/dev/2015-October/025032.html
the mailing-list users at dpdk.org has been created.

Like dev at dpdk.org, you must be registered to post without moderation.
It is a basic spam counter-measure.

As usual, please try to be friendly and give accurate answers to questions.
The traffic on this list should be low if the documentation is good enough.
If you feel some improvements are required to better help users and reduce
the traffic of this list, do not hesitate to send a patch for the doc ;)

If you have some patches to send or discuss, please use dev at dpdk.org.

Welcome DPDK users!

[dpdk-dev] I have a problem in setting up DPDK 2.1.0 in Fedora OS release 20 (Heisenbug). I cannot r

[최익성]

 Dear De Lara Guarch, Pablo.

I checked what you mentioned.

* Fedora Linux kernel version is as follows.

 $ uname -r (print kernel name)
 3.17.7-200.fc20.x86_64

 $ uname -a
 Linux sdnlab-k01 3.17.7-200.fc20.x86_64 #1 SMP Wed Dec 17 03:35:33 UTC 
2014 x86_64 x86_64 x86_64 GNU/Linux

 $ cat /proc/version
 Linux version 3.17.7-200.fc20.x86_64 (mockbuild at 
bkernel01.phx2.fedoraproject.org) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-7) 
(GCC) ) #1 SMP Wed Dec 17 03:35:33 UTC 2014

 $ rpm -q kernel
 kernel-3.11.10-301.fc20.x86_64
 kernel-3.17.7-200.fc20.x86_64
 kernel-3.15.6-200.fc20.x86_64

 $ cat /etc/redhat-release
 Fedora release 20 (Heisenbug)


* Vt-d seems to be enabled. I heard that the result values of 3 or 5 mean the 
virtualization activated.

 $ sudo rdmsr 0x3A
 5

And I have strange error during the yum update.


$ sudo yum update

--> Finished Dependency Resolution
--> Running transaction check
---> Package aspell-en.x86_64 50:7.1-6.fc20 will be installed
---> Package kernel-devel.x86_64 0:3.11.10-301.fc20 will be erased
---> Package kernel-modules-extra.x86_64 0:3.11.10-301.fc20 will be erased
---> Package kernel-modules-extra.x86_64 0:3.19.8-100.fc20 will be installed
--> Processing Dependency: kernel-uname-r = 3.19.8-100.fc20.x86_64 for 
package: kernel-modules-extra-3.19.8-100.fc20.x86_64
--> Finished Dependency Resolution
Error: Package: kernel-modules-extra-3.19.8-100.fc20.x86_64 (updates)
   Requires: kernel-uname-r = 3.19.8-100.fc20.x86_64
   Installed: kernel-3.11.10-301.fc20.x86_64 (@anaconda)
   kernel-uname-r = 3.11.10-301.fc20.x86_64
   Installed: kernel-3.15.6-200.fc20.x86_64 (installed)
   kernel-uname-r = 3.15.6-200.fc20.x86_64
   Installed: kernel-3.17.7-200.fc20.x86_64 (@updates)
   kernel-uname-r = 3.17.7-200.fc20.x86_64
   Available: kernel-debug-3.11.10-301.fc20.x86_64 (fedora)
   kernel-uname-r = 3.11.10-301.fc20.x86_64+debug
   Available: kernel-debug-3.19.8-100.fc20.x86_64 (updates)
   kernel-uname-r = 3.19.8-100.fc20.x86_64+debug
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest


* There are virtual bridge and virtual nic in the Fedora server.

$ ifconfig  or $ ifconfig -a

virbr0: flags=4099  mtu 1500
inet ?.?.?.?  netmask 255.255.255.0  broadcast ?.?.?.?
ether 52:54:00:f2:70:98  txqueuelen 0  (Ethernet)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 0  bytes 0 (0.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

virbr0-nic: flags=4098  mtu 1500
ether 52:54:00:f2:70:98  txqueuelen 500  (Ethernet)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 0  bytes 0 (0.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


Thank you very much.

Sincerely Yours,

Ick-Sung Choi.



-Original Message-
From: "De Lara Guarch, Pablo" 
To: "???"; "dev at dpdk.org"; 
Cc: 
Sent: 2015-10-14 (?) 22:19:02
Subject: RE: [dpdk-dev] I have a problem in setting up DPDK 2.1.0 in Fedora OS 
release 20 (Heisenbug). I cannot r

Hi Ick-Sung,



> * Fedora OS version : Fedora release 20 (Heisenbug)

> 

> * gcc version : gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7).

> 

> * Intel(R) Xeon(R) CPU E5-2680  10 cores, 64G bytes system memory.

> * 2 2-port NIC cards, Intel? 82599ES 10 Gigabit Ethernet 2 port Controller.

> SFI/SFP+. optical link. Hence there are 4 10 GbE ports.

> 

> * I attached DPDK setup script in my environment.



What is your kernel version? And also, can you check if you have VT-d enabled?



Thanks,

Pablo

> 

> 

> Thank you very much.

> 

> Sincerely Yours,

> 

> Ick-Sung Choi.

[dpdk-dev] [PATCH 02/34] e1000/base: add new devices

[Lu, Wenzhuo]

Hi Hemminger,

> -Original Message-
> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> Sent: Thursday, October 15, 2015 12:01 AM
> To: Lu, Wenzhuo
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 02/34] e1000/base: add new devices
> 
> On Wed, 14 Oct 2015 14:34:07 +0800
> Wenzhuo Lu  wrote:
> 
> > Add some new i218 devices.
> >
> > Signed-off-by: Wenzhuo Lu 
> > ---
> >  drivers/net/e1000/base/e1000_api.c |  4 
> >  drivers/net/e1000/base/e1000_defines.h |  2 ++
> >  drivers/net/e1000/base/e1000_hw.h  |  4 
> >  drivers/net/e1000/base/e1000_ich8lan.c | 18 ++
> >  4 files changed, 24 insertions(+), 4 deletions(-)
> 
> I assume a later patch will add these devices to the DPDK PCI device list. 
> There
> are still some issues where base driver supports more devices than the DPDK 
> list.
Thanks for the comments. I planned to create another patch for the code outside 
the base. But seems better to include it in this set. I'll send a V2.

[dpdk-dev] [PATCH] eal/bsd: reinitialize optind and optreset to 1

[Tiwei Bie]

Hi Don!

I'm truly sorry for my misunderstanding. :-(
Thank you so much for your detailed comments!

I will update my patch!

Thanks again!

Best wishes,
Tiwei Bie

On Wed, Oct 14, 2015 at 05:54:14PM +, Don Provan wrote:
> > > On Wed, Oct 14, 2015 at 10:28:44AM +0800, Tiwei Bie wrote:
> > > > It is designed to have DPDK's parameters specified in the front of the
> > > > cmd line and terminated by '--'.
> 
> In other words, it is designed assuming the DPDK library can dictate
> the application's command line. This is an incorrect assumption
> that should be eliminated.
> 
> I don't think I'm the only one that has figured out that layering a
> service on top of DPDK requires creating a fake argc/argv array.
> The original plan of having rte_eal_init() parse the actual application
> command line organized as dictated by DPDK is not reasonable.
> 
> > > > And 1 or 0 are not some
> > > > arbitrary values. They are used to put the index back to the beginning
> > > > of the new argv[] array.
> 
> They're arbitrary values from the point of view of the calling
> application. If the caller is using getopt() for its own purposes,
> it has every reason to expect optind to have the same value
> after the call to rte_eal_init() that it had before, not some
> other value that the DPDK library happened to think was
> useful.
> 
> > > > We shouldn't mix up DPDK's parameters and application's parameters.
> > > > And we should group them using '--'.
> 
> Exactly! Yet we do confuse the two by using getopt() without considering
> that the application's parameters might not be in the argc/argv list that's
> passed to rte_eal_init().
> 
> > I'm considering updating optind to make it point to the option after
> > '--' before eal_parse_args() returns, and eal_parse_args() will return
> > 0 to avoid breaking the current applications which use the return value
> > of rte_eal_init() to update argc/argv.
> >
> > Any comments? Thanks! :-)
> 
> Don't do it. Last time I looked, optind wasn't even mentioned in the
> documentation. Even if I thought it was reasonable to change it,
> I would still argue against using it as an undocumented return
> value, particularly when the documented return value works fine.
> 
> -don provan
> dprovan at bivio.net

[dpdk-dev] [PATCH v2 01/35] e1000/base: update readme and copyright

[Wenzhuo Lu]

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/base/README  | 4 ++--
 drivers/net/e1000/base/e1000_80003es2lan.c | 2 +-
 drivers/net/e1000/base/e1000_80003es2lan.h | 2 +-
 drivers/net/e1000/base/e1000_82540.c   | 2 +-
 drivers/net/e1000/base/e1000_82541.c   | 2 +-
 drivers/net/e1000/base/e1000_82541.h   | 2 +-
 drivers/net/e1000/base/e1000_82542.c   | 2 +-
 drivers/net/e1000/base/e1000_82543.c   | 2 +-
 drivers/net/e1000/base/e1000_82543.h   | 2 +-
 drivers/net/e1000/base/e1000_82571.c   | 2 +-
 drivers/net/e1000/base/e1000_82571.h   | 2 +-
 drivers/net/e1000/base/e1000_82575.c   | 2 +-
 drivers/net/e1000/base/e1000_82575.h   | 2 +-
 drivers/net/e1000/base/e1000_api.c | 2 +-
 drivers/net/e1000/base/e1000_api.h | 2 +-
 drivers/net/e1000/base/e1000_defines.h | 2 +-
 drivers/net/e1000/base/e1000_hw.h  | 2 +-
 drivers/net/e1000/base/e1000_i210.c| 2 +-
 drivers/net/e1000/base/e1000_i210.h| 2 +-
 drivers/net/e1000/base/e1000_ich8lan.c | 2 +-
 drivers/net/e1000/base/e1000_ich8lan.h | 2 +-
 drivers/net/e1000/base/e1000_mac.c | 2 +-
 drivers/net/e1000/base/e1000_mac.h | 2 +-
 drivers/net/e1000/base/e1000_manage.c  | 2 +-
 drivers/net/e1000/base/e1000_manage.h  | 2 +-
 drivers/net/e1000/base/e1000_mbx.c | 2 +-
 drivers/net/e1000/base/e1000_mbx.h | 2 +-
 drivers/net/e1000/base/e1000_nvm.c | 2 +-
 drivers/net/e1000/base/e1000_nvm.h | 2 +-
 drivers/net/e1000/base/e1000_phy.c | 2 +-
 drivers/net/e1000/base/e1000_phy.h | 2 +-
 drivers/net/e1000/base/e1000_regs.h| 2 +-
 drivers/net/e1000/base/e1000_vf.c  | 2 +-
 drivers/net/e1000/base/e1000_vf.h  | 2 +-
 34 files changed, 35 insertions(+), 35 deletions(-)

diff --git a/drivers/net/e1000/base/README b/drivers/net/e1000/base/README
index 59275b6..8d48135 100644
--- a/drivers/net/e1000/base/README
+++ b/drivers/net/e1000/base/README
@@ -1,7 +1,7 @@
 ..
  BSD LICENSE

- Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
  All rights reserved.

  Redistribution and use in source and binary forms, with or without
@@ -31,7 +31,7 @@
  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

 This directory contains source code of FreeBSD em & igb drivers of version
-cid-shared-code.2014.04.21 released by LAD. The sub-directory of lad/
+cid-shared-code.2015.10.09 released by ND. The sub-directory of base/
 contains the original source package.

 Updating the driver
diff --git a/drivers/net/e1000/base/e1000_80003es2lan.c 
b/drivers/net/e1000/base/e1000_80003es2lan.c
index 72692d9..b79496b 100644
--- a/drivers/net/e1000/base/e1000_80003es2lan.c
+++ b/drivers/net/e1000/base/e1000_80003es2lan.c
@@ -1,6 +1,6 @@
 
/***

-Copyright (c) 2001-2014, Intel Corporation
+Copyright (c) 2001-2015, Intel Corporation
 All rights reserved.

 Redistribution and use in source and binary forms, with or without
diff --git a/drivers/net/e1000/base/e1000_80003es2lan.h 
b/drivers/net/e1000/base/e1000_80003es2lan.h
index f5fe967..93ec19b 100644
--- a/drivers/net/e1000/base/e1000_80003es2lan.h
+++ b/drivers/net/e1000/base/e1000_80003es2lan.h
@@ -1,6 +1,6 @@
 
/***

-Copyright (c) 2001-2014, Intel Corporation
+Copyright (c) 2001-2015, Intel Corporation
 All rights reserved.

 Redistribution and use in source and binary forms, with or without
diff --git a/drivers/net/e1000/base/e1000_82540.c 
b/drivers/net/e1000/base/e1000_82540.c
index fc1fa94..7de7b7b 100644
--- a/drivers/net/e1000/base/e1000_82540.c
+++ b/drivers/net/e1000/base/e1000_82540.c
@@ -1,6 +1,6 @@
 
/***

-Copyright (c) 2001-2014, Intel Corporation
+Copyright (c) 2001-2015, Intel Corporation
 All rights reserved.

 Redistribution and use in source and binary forms, with or without
diff --git a/drivers/net/e1000/base/e1000_82541.c 
b/drivers/net/e1000/base/e1000_82541.c
index 952aea2..9cdb91c 100644
--- a/drivers/net/e1000/base/e1000_82541.c
+++ b/drivers/net/e1000/base/e1000_82541.c
@@ -1,6 +1,6 @@
 
/***

-Copyright (c) 2001-2014, Intel Corporation
+Copyright (c) 2001-2015, Intel Corporation
 All rights reserved.

 Redistribution and use in source and binary forms, with or without
diff --git a/drivers/net/e1000/base/e1000_82541.h 
b/drivers/net/e1000/base/e1000_82541.h
index 0f50f55..e0bee7c 100644
--- a/drivers/net/e1000/base/e1000_82541.h
+++ b/drivers/net/e1000/base/e1000_82541.h
@@ -1,6 +1,6 @@
 
/***

-Copyright (c) 2001-2014, Intel Corporation
+Copyright (

[dpdk-dev] [PATCH v2 02/35] e1000/base: add new devices

[Wenzhuo Lu]

Add some new i218 devices.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/base/e1000_api.c |  4 
 drivers/net/e1000/base/e1000_defines.h |  2 ++
 drivers/net/e1000/base/e1000_hw.h  |  4 
 drivers/net/e1000/base/e1000_ich8lan.c | 18 ++
 4 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/drivers/net/e1000/base/e1000_api.c 
b/drivers/net/e1000/base/e1000_api.c
index bfddb79..5ec0ad1 100644
--- a/drivers/net/e1000/base/e1000_api.c
+++ b/drivers/net/e1000/base/e1000_api.c
@@ -292,6 +292,10 @@ s32 e1000_set_mac_type(struct e1000_hw *hw)
case E1000_DEV_ID_PCH_LPT_I217_V:
case E1000_DEV_ID_PCH_LPTLP_I218_LM:
case E1000_DEV_ID_PCH_LPTLP_I218_V:
+   case E1000_DEV_ID_PCH_I218_LM2:
+   case E1000_DEV_ID_PCH_I218_V2:
+   case E1000_DEV_ID_PCH_I218_LM3:
+   case E1000_DEV_ID_PCH_I218_V3:
mac->type = e1000_pch_lpt;
break;
case E1000_DEV_ID_82575EB_COPPER:
diff --git a/drivers/net/e1000/base/e1000_defines.h 
b/drivers/net/e1000/base/e1000_defines.h
index 605e26e..71bd2e0 100644
--- a/drivers/net/e1000/base/e1000_defines.h
+++ b/drivers/net/e1000/base/e1000_defines.h
@@ -197,6 +197,7 @@ POSSIBILITY OF SUCH DAMAGE.
 #define E1000_RCTL_LBM_TCVR0x00C0 /* tcvr loopback mode */
 #define E1000_RCTL_DTYP_PS 0x0400 /* Packet Split descriptor */
 #define E1000_RCTL_RDMTS_HALF  0x /* Rx desc min thresh size */
+#define E1000_RCTL_RDMTS_HEX   0x0001
 #define E1000_RCTL_MO_SHIFT12 /* multicast offset shift */
 #define E1000_RCTL_MO_30x3000 /* multicast offset 15:4 */
 #define E1000_RCTL_BAM 0x8000 /* broadcast enable */
@@ -1467,6 +1468,7 @@ POSSIBILITY OF SUCH DAMAGE.
 #define E1000_RXPBS_SIZE_I210_MASK 0x003F /* Rx packet buffer size */
 #define E1000_TXPB0S_SIZE_I210_MASK0x003F /* Tx packet buffer 0 size */

+
 /* Proxy Filter Control */
 #define E1000_PROXYFC_D0   0x0001 /* Enable offload in D0 */
 #define E1000_PROXYFC_EX   0x0004 /* Directed exact proxy */
diff --git a/drivers/net/e1000/base/e1000_hw.h 
b/drivers/net/e1000/base/e1000_hw.h
index b0e7a61..154b9e5 100644
--- a/drivers/net/e1000/base/e1000_hw.h
+++ b/drivers/net/e1000/base/e1000_hw.h
@@ -132,6 +132,10 @@ struct e1000_hw;
 #define E1000_DEV_ID_PCH_LPT_I217_V0x153B
 #define E1000_DEV_ID_PCH_LPTLP_I218_LM 0x155A
 #define E1000_DEV_ID_PCH_LPTLP_I218_V  0x1559
+#define E1000_DEV_ID_PCH_I218_LM2  0x15A0
+#define E1000_DEV_ID_PCH_I218_V2   0x15A1
+#define E1000_DEV_ID_PCH_I218_LM3  0x15A2 /* Wildcat Point PCH */
+#define E1000_DEV_ID_PCH_I218_V3   0x15A3 /* Wildcat Point PCH */
 #define E1000_DEV_ID_82576 0x10C9
 #define E1000_DEV_ID_82576_FIBER   0x10E6
 #define E1000_DEV_ID_82576_SERDES  0x10E7
diff --git a/drivers/net/e1000/base/e1000_ich8lan.c 
b/drivers/net/e1000/base/e1000_ich8lan.c
index f98d54e..6d998df 100644
--- a/drivers/net/e1000/base/e1000_ich8lan.c
+++ b/drivers/net/e1000/base/e1000_ich8lan.c
@@ -62,6 +62,10 @@ POSSIBILITY OF SUCH DAMAGE.
  * Ethernet Connection I217-V
  * Ethernet Connection I218-V
  * Ethernet Connection I218-LM
+ * Ethernet Connection (2) I218-LM
+ * Ethernet Connection (2) I218-V
+ * Ethernet Connection (3) I218-LM
+ * Ethernet Connection (3) I218-V
  */

 #include "e1000_api.h"
@@ -1052,19 +1056,19 @@ s32 e1000_enable_ulp_lpt_lp(struct e1000_hw *hw, bool 
to_sx)
if ((hw->mac.type < e1000_pch_lpt) ||
(hw->device_id == E1000_DEV_ID_PCH_LPT_I217_LM) ||
(hw->device_id == E1000_DEV_ID_PCH_LPT_I217_V) ||
+   (hw->device_id == E1000_DEV_ID_PCH_I218_LM2) ||
+   (hw->device_id == E1000_DEV_ID_PCH_I218_V2) ||
(hw->dev_spec.ich8lan.ulp_state == e1000_ulp_state_on))
return 0;

if (!to_sx) {
int i = 0;
-
/* Poll up to 5 seconds for Cable Disconnected indication */
while (!(E1000_READ_REG(hw, E1000_FEXT) &
 E1000_FEXT_PHY_CABLE_DISCONNECTED)) {
/* Bail if link is re-acquired */
if (E1000_READ_REG(hw, E1000_STATUS) & E1000_STATUS_LU)
return -E1000_ERR_PHY;
-
if (i++ == 100)
break;

@@ -1197,6 +1201,8 @@ s32 e1000_disable_ulp_lpt_lp(struct e1000_hw *hw, bool 
force)
if ((hw->mac.type < e1000_pch_lpt) ||
(hw->device_id == E1000_DEV_ID_PCH_LPT_I217_LM) ||
(hw->device_id == E1000_DEV_ID_PCH_LPT_I217_V) ||
+   (hw->device_id == E1000_DEV_ID_PCH_I218_LM2) ||
+   (hw->device_id == E1000_DEV_ID_PCH_I218_V2) ||
(hw->dev_spec.ich8lan.ulp_state == e1000_ulp_state_off))
return 0;

@@ -1452,7 +1458,9 @@ STATIC s32 e1000_check_for_copper_link_ich8lan

[dpdk-dev] [PATCH v2 03/35] e1000/base: fix issue with link flap on 82579

[Wenzhuo Lu]

Several customers have reported a link flap issue on 82579. The symptoms
are random and intermittent link losses when 82579 is connected to specific
switches. Issue has been root caused as interoperability problem between
the NIC and at least some Broadcom PHYs in the Energy Efficient Ethernet
wake mechanism.
To fix the issue, we are disabling the Phase Locked Loop shutdown in 100M
Low Power Idle. This solution will cause an increase of power in 100M EEE
link. It may cost additional 28mW in this specific mode.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/base/e1000_ich8lan.c | 11 +++
 drivers/net/e1000/base/e1000_ich8lan.h |  2 ++
 2 files changed, 13 insertions(+)

diff --git a/drivers/net/e1000/base/e1000_ich8lan.c 
b/drivers/net/e1000/base/e1000_ich8lan.c
index 6d998df..f23d810 100644
--- a/drivers/net/e1000/base/e1000_ich8lan.c
+++ b/drivers/net/e1000/base/e1000_ich8lan.c
@@ -935,6 +935,17 @@ s32 e1000_set_eee_pchlan(struct e1000_hw *hw)
}
}

+   if (hw->phy.type == e1000_phy_82579) {
+   ret_val = e1000_read_emi_reg_locked(hw, I82579_LPI_PLL_SHUT,
+   &data);
+   if (ret_val)
+   goto release;
+
+   data &= ~I82579_LPI_100_PLL_SHUT;
+   ret_val = e1000_write_emi_reg_locked(hw, I82579_LPI_PLL_SHUT,
+data);
+   }
+
/* R/Clr IEEE MMD 3.1 bits 11:10 - Tx/Rx LPI Received */
ret_val = e1000_read_emi_reg_locked(hw, pcs_status, &data);
if (ret_val)
diff --git a/drivers/net/e1000/base/e1000_ich8lan.h 
b/drivers/net/e1000/base/e1000_ich8lan.h
index e9b73df..c690d9e 100644
--- a/drivers/net/e1000/base/e1000_ich8lan.h
+++ b/drivers/net/e1000/base/e1000_ich8lan.h
@@ -262,12 +262,14 @@ POSSIBILITY OF SUCH DAMAGE.
 #define I82577_MSE_THRESHOLD   0x0887 /* 82577 Mean Square Error Threshold */
 #define I82579_MSE_LINK_DOWN   0x2411 /* MSE count before dropping link */
 #define I82579_RX_CONFIG   0x3412 /* Receive configuration */
+#define I82579_LPI_PLL_SHUT0x4412 /* LPI PLL Shut Enable */
 #define I82579_EEE_PCS_STATUS  0x182E  /* IEEE MMD Register 3.1 >> 8 */
 #define I82579_EEE_CAPABILITY  0x0410 /* IEEE MMD Register 3.20 */
 #define I82579_EEE_ADVERTISEMENT   0x040E /* IEEE MMD Register 7.60 */
 #define I82579_EEE_LP_ABILITY  0x040F /* IEEE MMD Register 7.61 */
 #define I82579_EEE_100_SUPPORTED   (1 << 1) /* 100BaseTx EEE */
 #define I82579_EEE_1000_SUPPORTED  (1 << 2) /* 1000BaseTx EEE */
+#define I82579_LPI_100_PLL_SHUT(1 << 2) /* 100M LPI PLL Shut Enabled */
 #define I217_EEE_PCS_STATUS0x9401   /* IEEE MMD Register 3.1 */
 #define I217_EEE_CAPABILITY0x8000   /* IEEE MMD Register 3.20 */
 #define I217_EEE_ADVERTISEMENT 0x8001   /* IEEE MMD Register 7.60 */
-- 
1.9.3

[dpdk-dev] [PATCH v2 04/35] e1000/base: fix issue with jumbo frame CRC failures in client

[Wenzhuo Lu]

This is a patch to change the value of register 776.20[11:2] for jumbo
mode from 0x1A to 0x1F. This is to enlarge the gap between read and
write pointers in the TX Fifo.
And replace the magic number with a macro by the way.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/base/e1000_defines.h | 1 +
 drivers/net/e1000/base/e1000_ich8lan.c | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/e1000/base/e1000_defines.h 
b/drivers/net/e1000/base/e1000_defines.h
index 71bd2e0..79a88bb 100644
--- a/drivers/net/e1000/base/e1000_defines.h
+++ b/drivers/net/e1000/base/e1000_defines.h
@@ -468,6 +468,7 @@ POSSIBILITY OF SUCH DAMAGE.

 #define ETHERNET_FCS_SIZE  4
 #define MAX_JUMBO_FRAME_SIZE   0x3F00
+#define E1000_TX_PTR_GAP   0x1F

 /* Extended Configuration Control and Size */
 #define E1000_EXTCNF_CTRL_MDIO_SW_OWNERSHIP0x0020
diff --git a/drivers/net/e1000/base/e1000_ich8lan.c 
b/drivers/net/e1000/base/e1000_ich8lan.c
index f23d810..cc6e033 100644
--- a/drivers/net/e1000/base/e1000_ich8lan.c
+++ b/drivers/net/e1000/base/e1000_ich8lan.c
@@ -2601,7 +2601,7 @@ s32 e1000_lv_jumbo_workaround_ich8lan(struct e1000_hw 
*hw, bool enable)
return ret_val;
hw->phy.ops.read_reg(hw, PHY_REG(776, 20), &data);
data &= ~(0x3FF << 2);
-   data |= (0x1A << 2);
+   data |= (E1000_TX_PTR_GAP << 2);
ret_val = hw->phy.ops.write_reg(hw, PHY_REG(776, 20), data);
if (ret_val)
return ret_val;
-- 
1.9.3

[dpdk-dev] [PATCH v2 05/35] e1000/base: redundant PHY power down for i210

[Wenzhuo Lu]

The wrong bit is being used in PHYREG16 for PHY power down. In addition,
the use of PHYREG 16 is unnecessary if bit 11 of PHYREG 0 is used.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/base/e1000_phy.c | 15 ---
 drivers/net/e1000/base/e1000_phy.h |  1 -
 2 files changed, 16 deletions(-)

diff --git a/drivers/net/e1000/base/e1000_phy.c 
b/drivers/net/e1000/base/e1000_phy.c
index 7620ecf..6bbb379 100644
--- a/drivers/net/e1000/base/e1000_phy.c
+++ b/drivers/net/e1000/base/e1000_phy.c
@@ -3498,16 +3498,10 @@ STATIC s32 e1000_access_phy_wakeup_reg_bm(struct 
e1000_hw *hw, u32 offset,
 void e1000_power_up_phy_copper(struct e1000_hw *hw)
 {
u16 mii_reg = 0;
-   u16 power_reg = 0;

/* The PHY will retain its settings across a power down/up cycle */
hw->phy.ops.read_reg(hw, PHY_CONTROL, &mii_reg);
mii_reg &= ~MII_CR_POWER_DOWN;
-   if (hw->phy.type == e1000_phy_i210) {
-   hw->phy.ops.read_reg(hw, GS40G_COPPER_SPEC, &power_reg);
-   power_reg &= ~GS40G_CS_POWER_DOWN;
-   hw->phy.ops.write_reg(hw, GS40G_COPPER_SPEC, power_reg);
-   }
hw->phy.ops.write_reg(hw, PHY_CONTROL, mii_reg);
 }

@@ -3522,17 +3516,10 @@ void e1000_power_up_phy_copper(struct e1000_hw *hw)
 void e1000_power_down_phy_copper(struct e1000_hw *hw)
 {
u16 mii_reg = 0;
-   u16 power_reg = 0;

/* The PHY will retain its settings across a power down/up cycle */
hw->phy.ops.read_reg(hw, PHY_CONTROL, &mii_reg);
mii_reg |= MII_CR_POWER_DOWN;
-   /* i210 Phy requires an additional bit for power up/down */
-   if (hw->phy.type == e1000_phy_i210) {
-   hw->phy.ops.read_reg(hw, GS40G_COPPER_SPEC, &power_reg);
-   power_reg |= GS40G_CS_POWER_DOWN;
-   hw->phy.ops.write_reg(hw, GS40G_COPPER_SPEC, power_reg);
-   }
hw->phy.ops.write_reg(hw, PHY_CONTROL, mii_reg);
msec_delay(1);
 }
@@ -3563,7 +3550,6 @@ STATIC s32 __e1000_read_phy_reg_hv(struct e1000_hw *hw, 
u32 offset, u16 *data,
if (ret_val)
return ret_val;
}
-
/* Page 800 works differently than the rest so it has its own func */
if (page == BM_WUC_PAGE) {
ret_val = e1000_access_phy_wakeup_reg_bm(hw, offset, data,
@@ -3673,7 +3659,6 @@ STATIC s32 __e1000_write_phy_reg_hv(struct e1000_hw *hw, 
u32 offset, u16 data,
if (ret_val)
return ret_val;
}
-
/* Page 800 works differently than the rest so it has its own func */
if (page == BM_WUC_PAGE) {
ret_val = e1000_access_phy_wakeup_reg_bm(hw, offset, &data,
diff --git a/drivers/net/e1000/base/e1000_phy.h 
b/drivers/net/e1000/base/e1000_phy.h
index b30b36e..2b78af0 100644
--- a/drivers/net/e1000/base/e1000_phy.h
+++ b/drivers/net/e1000/base/e1000_phy.h
@@ -143,7 +143,6 @@ bool e1000_is_mphy_ready(struct e1000_hw *hw);
 #define GS40G_MAC_LB   0x4140
 #define GS40G_MAC_SPEED_1G 0X0006
 #define GS40G_COPPER_SPEC  0x0010
-#define GS40G_CS_POWER_DOWN0x0002

 /* BM/HV Specific Registers */
 #define BM_PORT_CTRL_PAGE  769
-- 
1.9.3

[dpdk-dev] [PATCH v2 06/35] e1000/base: add return value to the functions of setting receive address register

[Wenzhuo Lu]

Previously, the rar_set functions were of type void, and when they failed
to program an address register they would, at most,  put a message into
the log and end.  The fact that they failed to program an address into a
address register, if checked for, should be captured and passed back to
the caller so that the drivers can deal with the situation (or not) as
they deem best.
Drivers can ignore or use the return value.  No change to base drivers
is mandated by this change unless a driver wants to handle the failure
to program an address register (e.g. evaluate the return value).

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/base/e1000_82542.c   |  6 --
 drivers/net/e1000/base/e1000_api.c |  6 --
 drivers/net/e1000/base/e1000_api.h |  2 +-
 drivers/net/e1000/base/e1000_hw.h  |  2 +-
 drivers/net/e1000/base/e1000_ich8lan.c | 18 ++
 drivers/net/e1000/base/e1000_mac.c | 12 +++-
 drivers/net/e1000/base/e1000_mac.h |  2 +-
 drivers/net/e1000/base/e1000_vf.c  |  6 --
 drivers/net/e1000/base/e1000_vf.h  |  2 +-
 9 files changed, 33 insertions(+), 23 deletions(-)

diff --git a/drivers/net/e1000/base/e1000_82542.c 
b/drivers/net/e1000/base/e1000_82542.c
index a538cba..4f1183a 100644
--- a/drivers/net/e1000/base/e1000_82542.c
+++ b/drivers/net/e1000/base/e1000_82542.c
@@ -46,7 +46,7 @@ STATIC s32  e1000_init_hw_82542(struct e1000_hw *hw);
 STATIC s32  e1000_setup_link_82542(struct e1000_hw *hw);
 STATIC s32  e1000_led_on_82542(struct e1000_hw *hw);
 STATIC s32  e1000_led_off_82542(struct e1000_hw *hw);
-STATIC void e1000_rar_set_82542(struct e1000_hw *hw, u8 *addr, u32 index);
+STATIC int  e1000_rar_set_82542(struct e1000_hw *hw, u8 *addr, u32 index);
 STATIC void e1000_clear_hw_cntrs_82542(struct e1000_hw *hw);
 STATIC s32  e1000_read_mac_addr_82542(struct e1000_hw *hw);

@@ -410,7 +410,7 @@ STATIC s32 e1000_led_off_82542(struct e1000_hw *hw)
  *  Sets the receive address array register at index to the address passed
  *  in by addr.
  **/
-STATIC void e1000_rar_set_82542(struct e1000_hw *hw, u8 *addr, u32 index)
+STATIC int e1000_rar_set_82542(struct e1000_hw *hw, u8 *addr, u32 index)
 {
u32 rar_low, rar_high;

@@ -431,6 +431,8 @@ STATIC void e1000_rar_set_82542(struct e1000_hw *hw, u8 
*addr, u32 index)

E1000_WRITE_REG_ARRAY(hw, E1000_RA, (index << 1), rar_low);
E1000_WRITE_REG_ARRAY(hw, E1000_RA, ((index << 1) + 1), rar_high);
+
+   return E1000_SUCCESS;
 }

 /**
diff --git a/drivers/net/e1000/base/e1000_api.c 
b/drivers/net/e1000/base/e1000_api.c
index 5ec0ad1..bbfcae8 100644
--- a/drivers/net/e1000/base/e1000_api.c
+++ b/drivers/net/e1000/base/e1000_api.c
@@ -831,10 +831,12 @@ void e1000_config_collision_dist(struct e1000_hw *hw)
  *
  *  Sets a Receive Address Register (RAR) to the specified address.
  **/
-void e1000_rar_set(struct e1000_hw *hw, u8 *addr, u32 index)
+int e1000_rar_set(struct e1000_hw *hw, u8 *addr, u32 index)
 {
if (hw->mac.ops.rar_set)
-   hw->mac.ops.rar_set(hw, addr, index);
+   return hw->mac.ops.rar_set(hw, addr, index);
+
+   return E1000_SUCCESS;
 }

 /**
diff --git a/drivers/net/e1000/base/e1000_api.h 
b/drivers/net/e1000/base/e1000_api.h
index 53a641c..563d0ca 100644
--- a/drivers/net/e1000/base/e1000_api.h
+++ b/drivers/net/e1000/base/e1000_api.h
@@ -68,7 +68,7 @@ s32 e1000_setup_link(struct e1000_hw *hw);
 s32 e1000_get_speed_and_duplex(struct e1000_hw *hw, u16 *speed, u16 *duplex);
 s32 e1000_disable_pcie_master(struct e1000_hw *hw);
 void e1000_config_collision_dist(struct e1000_hw *hw);
-void e1000_rar_set(struct e1000_hw *hw, u8 *addr, u32 index);
+int e1000_rar_set(struct e1000_hw *hw, u8 *addr, u32 index);
 u32 e1000_hash_mc_addr(struct e1000_hw *hw, u8 *mc_addr);
 void e1000_update_mc_addr_list(struct e1000_hw *hw, u8 *mc_addr_list,
   u32 mc_addr_count);
diff --git a/drivers/net/e1000/base/e1000_hw.h 
b/drivers/net/e1000/base/e1000_hw.h
index 154b9e5..f06be0c 100644
--- a/drivers/net/e1000/base/e1000_hw.h
+++ b/drivers/net/e1000/base/e1000_hw.h
@@ -699,7 +699,7 @@ struct e1000_mac_operations {
s32  (*setup_led)(struct e1000_hw *);
void (*write_vfta)(struct e1000_hw *, u32, u32);
void (*config_collision_dist)(struct e1000_hw *);
-   void (*rar_set)(struct e1000_hw *, u8*, u32);
+   int  (*rar_set)(struct e1000_hw *, u8*, u32);
s32  (*read_mac_addr)(struct e1000_hw *);
s32  (*validate_mdi_setting)(struct e1000_hw *);
s32  (*acquire_swfw_sync)(struct e1000_hw *, u16);
diff --git a/drivers/net/e1000/base/e1000_ich8lan.c 
b/drivers/net/e1000/base/e1000_ich8lan.c
index cc6e033..228d4c5 100644
--- a/drivers/net/e1000/base/e1000_ich8lan.c
+++ b/drivers/net/e1000/base/e1000_ich8lan.c
@@ -77,8 +77,8 @@ STATIC s32  e1000_acquire_nvm_ich8lan(struct e1000_hw *hw);
 STATIC void e1000_release_nvm_ich8lan(struct e1000_hw *hw);
 STATIC bool e1000_check_mng_mode_ich8lan(struct e

[dpdk-dev] [PATCH v2 07/35] e1000/base: add defaults for i210 TX/RX PBSIZE

[Wenzhuo Lu]

These are the defaults for the packet buffer size registers that need to
be explicitly set back if someone changes them and comes back to a normal
driver.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/base/e1000_defines.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/e1000/base/e1000_defines.h 
b/drivers/net/e1000/base/e1000_defines.h
index 79a88bb..8e40771 100644
--- a/drivers/net/e1000/base/e1000_defines.h
+++ b/drivers/net/e1000/base/e1000_defines.h
@@ -1468,6 +1468,8 @@ POSSIBILITY OF SUCH DAMAGE.
 #define E1000_RXPBS_CFG_TS_EN  0x8000 /* Timestamp in Rx buffer */
 #define E1000_RXPBS_SIZE_I210_MASK 0x003F /* Rx packet buffer size */
 #define E1000_TXPB0S_SIZE_I210_MASK0x003F /* Tx packet buffer 0 size */
+#define I210_RXPBSIZE_DEFAULT  0x00A2 /* RXPBSIZE default */
+#define I210_TXPBSIZE_DEFAULT  0x0414 /* TXPBSIZE default */


 /* Proxy Filter Control */
-- 
1.9.3

[dpdk-dev] [PATCH v2 08/35] e1000/base: remove E1000_WRITE_FLUSH for DH89XXCC_SGMII after commencing HW reset

[Wenzhuo Lu]

For DH89XXCC_SGMII, write flush leaves registers of this device trashed
(0x). Added check for this device.
Also, after both for Port SW Reset and Device Reset case, platform should
wait at least 3ms before reading any registers. Since waiting is
conditionally executed only for Device Reset - removed the condition.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/base/e1000_82575.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/net/e1000/base/e1000_82575.c 
b/drivers/net/e1000/base/e1000_82575.c
index 3dc8066..ab547ca 100644
--- a/drivers/net/e1000/base/e1000_82575.c
+++ b/drivers/net/e1000/base/e1000_82575.c
@@ -2490,11 +2490,17 @@ STATIC s32 e1000_reset_hw_82580(struct e1000_hw *hw)
ctrl |= E1000_CTRL_RST;

E1000_WRITE_REG(hw, E1000_CTRL, ctrl);
-   E1000_WRITE_FLUSH(hw);

-   /* Add delay to insure DEV_RST has time to complete */
-   if (global_device_reset)
-   msec_delay(5);
+   switch (hw->device_id) {
+   case E1000_DEV_ID_DH89XXCC_SGMII:
+   break;
+   default:
+   E1000_WRITE_FLUSH(hw);
+   break;
+   }
+
+   /* Add delay to insure DEV_RST or RST has time to complete */
+   msec_delay(5);

ret_val = e1000_get_auto_rd_done_generic(hw);
if (ret_val) {
-- 
1.9.3

[dpdk-dev] [PATCH v2 10/35] e1000/base: change invariant return to not use variables

[Wenzhuo Lu]

Although this change should be optimized out by the compiler, just
return a constant directly rather than declare a variable.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/base/e1000_82575.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/net/e1000/base/e1000_82575.c 
b/drivers/net/e1000/base/e1000_82575.c
index ab547ca..3bdcf69 100644
--- a/drivers/net/e1000/base/e1000_82575.c
+++ b/drivers/net/e1000/base/e1000_82575.c
@@ -891,7 +891,6 @@ out:
 STATIC s32 e1000_set_d0_lplu_state_82580(struct e1000_hw *hw, bool active)
 {
struct e1000_phy_info *phy = &hw->phy;
-   s32 ret_val = E1000_SUCCESS;
u32 data;

DEBUGFUNC("e1000_set_d0_lplu_state_82580");
@@ -919,7 +918,7 @@ STATIC s32 e1000_set_d0_lplu_state_82580(struct e1000_hw 
*hw, bool active)
}

E1000_WRITE_REG(hw, E1000_82580_PHY_POWER_MGMT, data);
-   return ret_val;
+   return E1000_SUCCESS;
 }

 /**
@@ -939,7 +938,6 @@ STATIC s32 e1000_set_d0_lplu_state_82580(struct e1000_hw 
*hw, bool active)
 s32 e1000_set_d3_lplu_state_82580(struct e1000_hw *hw, bool active)
 {
struct e1000_phy_info *phy = &hw->phy;
-   s32 ret_val = E1000_SUCCESS;
u32 data;

DEBUGFUNC("e1000_set_d3_lplu_state_82580");
@@ -967,7 +965,7 @@ s32 e1000_set_d3_lplu_state_82580(struct e1000_hw *hw, bool 
active)
}

E1000_WRITE_REG(hw, E1000_82580_PHY_POWER_MGMT, data);
-   return ret_val;
+   return E1000_SUCCESS;
 }

 /**
@@ -981,7 +979,7 @@ s32 e1000_set_d3_lplu_state_82580(struct e1000_hw *hw, bool 
active)
  **/
 STATIC s32 e1000_acquire_nvm_82575(struct e1000_hw *hw)
 {
-   s32 ret_val;
+   s32 ret_val = E1000_SUCCESS;

DEBUGFUNC("e1000_acquire_nvm_82575");

@@ -1003,6 +1001,7 @@ STATIC s32 e1000_acquire_nvm_82575(struct e1000_hw *hw)
DEBUGOUT("Nvm bit banging access error detected and 
cleared.\n");
}
}
+
if (hw->mac.type == e1000_82580) {
u32 eecd = E1000_READ_REG(hw, E1000_EECD);
if (eecd & E1000_EECD_BLOCKED) {
@@ -1013,7 +1012,6 @@ STATIC s32 e1000_acquire_nvm_82575(struct e1000_hw *hw)
}
}

-
ret_val = e1000_acquire_nvm_generic(hw);
if (ret_val)
e1000_release_swfw_sync_82575(hw, E1000_SWFW_EEP_SM);
@@ -1127,7 +1125,6 @@ STATIC void e1000_release_swfw_sync_82575(struct e1000_hw 
*hw, u16 mask)
 STATIC s32 e1000_get_cfg_done_82575(struct e1000_hw *hw)
 {
s32 timeout = PHY_CFG_TIMEOUT;
-   s32 ret_val = E1000_SUCCESS;
u32 mask = E1000_NVM_CFG_DONE_PORT_0;

DEBUGFUNC("e1000_get_cfg_done_82575");
@@ -1152,7 +1149,7 @@ STATIC s32 e1000_get_cfg_done_82575(struct e1000_hw *hw)
(hw->phy.type == e1000_phy_igp_3))
e1000_phy_init_script_igp3(hw);

-   return ret_val;
+   return E1000_SUCCESS;
 }

 /**
-- 
1.9.3

[dpdk-dev] [PATCH v2 00/35] update e1000 base code

[Wenzhuo Lu]

Short summary:
*update readme and copyright
*add new devices
*fix issue with link flap on 82579
*fix issue with jumbo frame CRC failures in client
*redundant PHY power down for i210
*add return value to the functions of setting receive address register
*add defaults for i210 TX/RX PBSIZE
*remove E1000_WRITE_FLUSH for DH89XXCC_SGMII after commencing HW reset
*add evaluation of e1000_nvm_read return value
*change invariant return to not use variables
*add return value handler when check manage mode
*add return value handler for ESB2 controller init and reset
*add support for inverted format ETrackId
*add EEARBC_I210 for i210
*apply paranoia to macro arguments
*add flags to set eee advertisement modes
*prevent ulp flow if cable connected
*fix TIPG value for non 10 half duplex mode
*add return value for resume workaround
*fix link detect flow
*cleanup NAHUM6LP_HW tags
*add bit for disable packetbuffer read
*K1 flow fixes
*remove FIXME comment
*set correct value of beacon duration
*disable extension header parsing for IPv6
*fix for i354 88E1112 PHY using AutoMedia Detect
*increase timeout of polling bit RSPCIPHY in check_reset_block
*implement 88E1543 PHY initialization
*use the correct i210 register for EEMNGCTL
*move the print to the right position
*synchronization of MAC-PHY interface only on non- ME systems
*fix to enable both ulp and EEE in Sx state

V2:
Add the new devices to the DPDK PCI device list.

Wenzhuo Lu (35):
  e1000/base: update readme and copyright
  e1000/base: add new devices
  e1000/base: fix issue with link flap on 82579
  e1000/base: fix issue with jumbo frame CRC failures in client
  e1000/base: redundant PHY power down for i210
  e1000/base: add return value to the functions of setting receive
address register
  e1000/base: add defaults for i210 TX/RX PBSIZE
  e1000/base: remove E1000_WRITE_FLUSH for DH89XXCC_SGMII after
commencing HW reset
  e1000/base: add evaluation of e1000_nvm_read return value
  e1000/base: change invariant return to not use variables
  e1000/base: add return value handler when check manage mode
  e1000/base: add return value handler for ESB2 controller init and
reset
  e1000/base: add support for inverted format ETrackId
  e1000/base: add EEARBC_I210 for i210
  e1000/base: apply paranoia to macro arguments
  e1000/base: add flags to set eee advertisement modes
  e1000/base: prevent ulp flow if cable connected
  e1000/base: fix TIPG value for non 10 half duplex mode
  e1000/base: add return value for resume workaround
  e1000/base: fix link detect flow
  e1000/base: cleanup NAHUM6LP_HW tags
  e1000/base: add bit for disable packetbuffer read
  e1000/base: K1 flow fixes
  e1000/base: remove FIXME comment
  e1000/base: set correct value of beacon duration
  e1000/base: disable extension header parsing for IPv6
  e1000/base: fix for i354 88E1112 PHY using AutoMedia Detect
  e1000/base: increase timeout of polling bit RSPCIPHY in
check_reset_block
  e1000/base: implement 88E1543 PHY initialization
  e1000/base: use the correct i210 register for EEMNGCTL
  e1000/base: move the print to the right position
  e1000/base: synchronization of MAC-PHY interface only on non- ME
systems
  e1000/base: fix to enable both ulp and EEE in Sx state
  e1000/base: some minor change
  e1000: add new devices

 drivers/net/e1000/base/README   |   4 +-
 drivers/net/e1000/base/e1000_80003es2lan.c  |  33 ++--
 drivers/net/e1000/base/e1000_80003es2lan.h  |   2 +-
 drivers/net/e1000/base/e1000_82540.c|   2 +-
 drivers/net/e1000/base/e1000_82541.c|   2 +-
 drivers/net/e1000/base/e1000_82541.h|   2 +-
 drivers/net/e1000/base/e1000_82542.c|   8 +-
 drivers/net/e1000/base/e1000_82543.c|   2 +-
 drivers/net/e1000/base/e1000_82543.h|   2 +-
 drivers/net/e1000/base/e1000_82571.c|   8 +-
 drivers/net/e1000/base/e1000_82571.h|   2 +-
 drivers/net/e1000/base/e1000_82575.c| 205 +++
 drivers/net/e1000/base/e1000_82575.h|   7 +-
 drivers/net/e1000/base/e1000_api.c  |  12 +-
 drivers/net/e1000/base/e1000_api.h  |  20 +-
 drivers/net/e1000/base/e1000_defines.h  |   8 +-
 drivers/net/e1000/base/e1000_hw.h   |  16 +-
 drivers/net/e1000/base/e1000_i210.c |  49 -
 drivers/net/e1000/base/e1000_i210.h |   2 +-
 drivers/net/e1000/base/e1000_ich8lan.c  | 252 +---
 drivers/net/e1000/base/e1000_ich8lan.h  |  43 ++--
 drivers/net/e1000/base/e1000_mac.c  |  14 +-
 drivers/net/e1000/base/e1000_mac.h  |   4 +-
 drivers/net/e1000/base/e1000_manage.c   |   7 +-
 drivers/net/e1000/base/e1000_manage.h   |   2 +-
 drivers/net/e1000/base/e1000_mbx.c  |   2 +-
 drivers/net/e1000/base/e1000_mbx.h  |   2 +-
 drivers/net/e1000/base/e1000_nvm.c  |  11 +-
 drivers/net/e1000/ba

[dpdk-dev] [PATCH v2 12/35] e1000/base: add return value handler for ESB2 controller init and reset

[Wenzhuo Lu]

Adding code where missing to handle case where calls to
e1000_read_kmrn_reg_80003es2lan and e1000_write_kmrn_reg_80003es2lan return
an error value.
Also, when accessing the E1000_KMRNCTRLSTA_INBAND_PARAM offset to disable
far-end loopback on 80003es2lan devices, make the handling of a read or
write failure consistent between hw_init and hw_reset.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/base/e1000_80003es2lan.c | 31 --
 1 file changed, 21 insertions(+), 10 deletions(-)

diff --git a/drivers/net/e1000/base/e1000_80003es2lan.c 
b/drivers/net/e1000/base/e1000_80003es2lan.c
index b79496b..5ac925e 100644
--- a/drivers/net/e1000/base/e1000_80003es2lan.c
+++ b/drivers/net/e1000/base/e1000_80003es2lan.c
@@ -852,11 +852,15 @@ STATIC s32 e1000_reset_hw_80003es2lan(struct e1000_hw *hw)
/* Disable IBIST slave mode (far-end loopback) */
ret_val = e1000_read_kmrn_reg_80003es2lan(hw,
E1000_KMRNCTRLSTA_INBAND_PARAM, &kum_reg_data);
-   if (ret_val)
-   return ret_val;
-   kum_reg_data |= E1000_KMRNCTRLSTA_IBIST_DISABLE;
-   e1000_write_kmrn_reg_80003es2lan(hw, E1000_KMRNCTRLSTA_INBAND_PARAM,
-   kum_reg_data);
+   if (!ret_val) {
+   kum_reg_data |= E1000_KMRNCTRLSTA_IBIST_DISABLE;
+   ret_val = e1000_write_kmrn_reg_80003es2lan(hw,
+E1000_KMRNCTRLSTA_INBAND_PARAM,
+kum_reg_data);
+   if (ret_val)
+   DEBUGOUT("Error disabling far-end loopback\n");
+   } else
+   DEBUGOUT("Error disabling far-end loopback\n");

ret_val = e1000_get_auto_rd_done_generic(hw);
if (ret_val)
@@ -912,11 +916,18 @@ STATIC s32 e1000_init_hw_80003es2lan(struct e1000_hw *hw)
return ret_val;

/* Disable IBIST slave mode (far-end loopback) */
-   e1000_read_kmrn_reg_80003es2lan(hw, E1000_KMRNCTRLSTA_INBAND_PARAM,
-   &kum_reg_data);
-   kum_reg_data |= E1000_KMRNCTRLSTA_IBIST_DISABLE;
-   e1000_write_kmrn_reg_80003es2lan(hw, E1000_KMRNCTRLSTA_INBAND_PARAM,
-kum_reg_data);
+   ret_val =
+   e1000_read_kmrn_reg_80003es2lan(hw, E1000_KMRNCTRLSTA_INBAND_PARAM,
+   &kum_reg_data);
+   if (!ret_val) {
+   kum_reg_data |= E1000_KMRNCTRLSTA_IBIST_DISABLE;
+   ret_val = e1000_write_kmrn_reg_80003es2lan(hw,
+E1000_KMRNCTRLSTA_INBAND_PARAM,
+kum_reg_data);
+   if (ret_val)
+   DEBUGOUT("Error disabling far-end loopback\n");
+   } else
+   DEBUGOUT("Error disabling far-end loopback\n");

/* Set the transmit descriptor write-back policy */
reg_data = E1000_READ_REG(hw, E1000_TXDCTL(0));
-- 
1.9.3

[dpdk-dev] [PATCH v2 09/35] e1000/base: add evaluation of e1000_nvm_read return value

[Wenzhuo Lu]

Adding code to a case where e1000_nvn_read is called, but there is no
consideration for when the read fails (returns an error code).
Also, this patch adds an error message to a base NVM reading function that
is missing it for consistency.
This patch is not covering all cases of these conditions, it only covers
the code used by the e1000e driver.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/base/e1000_manage.c | 5 -
 drivers/net/e1000/base/e1000_nvm.c| 3 +++
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/net/e1000/base/e1000_manage.c 
b/drivers/net/e1000/base/e1000_manage.c
index ac4c08a..8564a7f 100644
--- a/drivers/net/e1000/base/e1000_manage.c
+++ b/drivers/net/e1000/base/e1000_manage.c
@@ -363,9 +363,12 @@ bool e1000_enable_mng_pass_thru(struct e1000_hw *hw)
} else if ((hw->mac.type == e1000_82574) ||
   (hw->mac.type == e1000_82583)) {
u16 data;
+   s32 ret_val;

factps = E1000_READ_REG(hw, E1000_FACTPS);
-   e1000_read_nvm(hw, NVM_INIT_CONTROL2_REG, 1, &data);
+   ret_val = e1000_read_nvm(hw, NVM_INIT_CONTROL2_REG, 1, &data);
+   if (ret_val)
+   return false;

if (!(factps & E1000_FACTPS_MNGCG) &&
((data & E1000_NVM_INIT_CTRL2_MNGM) ==
diff --git a/drivers/net/e1000/base/e1000_nvm.c 
b/drivers/net/e1000/base/e1000_nvm.c
index 966a34c..01be9e4 100644
--- a/drivers/net/e1000/base/e1000_nvm.c
+++ b/drivers/net/e1000/base/e1000_nvm.c
@@ -585,6 +585,9 @@ s32 e1000_read_nvm_eerd(struct e1000_hw *hw, u16 offset, 
u16 words, u16 *data)
   E1000_NVM_RW_REG_DATA);
}

+   if (ret_val)
+   DEBUGOUT1("NVM read error: %d\n", ret_val);
+
return ret_val;
 }

-- 
1.9.3

[dpdk-dev] [PATCH v2 11/35] e1000/base: add return value handler when check manage mode

[Wenzhuo Lu]

Adding code, where missing, to handle the case when hw->nvm.ops.read returns
an error value.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/base/e1000_82571.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/e1000/base/e1000_82571.c 
b/drivers/net/e1000/base/e1000_82571.c
index 5e0e43c..7c279db 100644
--- a/drivers/net/e1000/base/e1000_82571.c
+++ b/drivers/net/e1000/base/e1000_82571.c
@@ -1452,10 +1452,14 @@ STATIC void e1000_clear_vfta_82571(struct e1000_hw *hw)
 STATIC bool e1000_check_mng_mode_82574(struct e1000_hw *hw)
 {
u16 data;
+   s32 ret_val;

DEBUGFUNC("e1000_check_mng_mode_82574");

-   hw->nvm.ops.read(hw, NVM_INIT_CONTROL2_REG, 1, &data);
+   ret_val = hw->nvm.ops.read(hw, NVM_INIT_CONTROL2_REG, 1, &data);
+   if (ret_val)
+   return false;
+
return (data & E1000_NVM_INIT_CTRL2_MNGM) != 0;
 }

-- 
1.9.3

[dpdk-dev] [PATCH v2 13/35] e1000/base: add support for inverted format ETrackId

[Wenzhuo Lu]

There are some images which contain ETrackID in inverted format. This patch
allows reading this format.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/base/e1000_nvm.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/e1000/base/e1000_nvm.c 
b/drivers/net/e1000/base/e1000_nvm.c
index 01be9e4..762acd1 100644
--- a/drivers/net/e1000/base/e1000_nvm.c
+++ b/drivers/net/e1000/base/e1000_nvm.c
@@ -1373,8 +1373,12 @@ etrack_id:
hw->nvm.ops.read(hw, (NVM_ETRACK_WORD + 1), 1, &eeprom_verh);
fw_vers->etrack_id = (eeprom_verh << NVM_ETRACK_SHIFT)
| eeprom_verl;
+   } else if ((etrack_test & NVM_ETRACK_VALID) == 0) {
+   hw->nvm.ops.read(hw, NVM_ETRACK_WORD, 1, &eeprom_verh);
+   hw->nvm.ops.read(hw, (NVM_ETRACK_WORD + 1), 1, &eeprom_verl);
+   fw_vers->etrack_id = (eeprom_verh << NVM_ETRACK_SHIFT) |
+eeprom_verl;
}
-   return;
 }


-- 
1.9.3

[dpdk-dev] [PATCH v2 14/35] e1000/base: add EEARBC_I210 for i210

[Wenzhuo Lu]

EEARBC has changed on i210. It means EEARBC has a different address on
i210 than on other NICs. So, add a new entity named EEARBC_I210 to the
register list and make sure the right one is being used on i210.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/base/e1000_i210.c | 17 ++---
 drivers/net/e1000/base/e1000_regs.h |  1 +
 2 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/net/e1000/base/e1000_i210.c 
b/drivers/net/e1000/base/e1000_i210.c
index 842e9d4..fedf88e 100644
--- a/drivers/net/e1000/base/e1000_i210.c
+++ b/drivers/net/e1000/base/e1000_i210.c
@@ -925,7 +925,7 @@ s32 e1000_write_xmdio_reg(struct e1000_hw *hw, u16 addr, u8 
dev_addr, u16 data)
 STATIC s32 e1000_pll_workaround_i210(struct e1000_hw *hw)
 {
s32 ret_val;
-   u32 wuc, mdicnfg, ctrl_ext, reg_val;
+   u32 wuc, mdicnfg, ctrl, ctrl_ext, reg_val;
u16 nvm_word, phy_word, pci_word, tmp_nvm;
int i;

@@ -942,9 +942,9 @@ STATIC s32 e1000_pll_workaround_i210(struct e1000_hw *hw)
nvm_word = E1000_INVM_DEFAULT_AL;
tmp_nvm = nvm_word | E1000_INVM_PLL_WO_VAL;
for (i = 0; i < E1000_MAX_PLL_TRIES; i++) {
-   /* check current state */
-   hw->phy.ops.read_reg(hw, (E1000_PHY_PLL_FREQ_PAGE |
-E1000_PHY_PLL_FREQ_REG), &phy_word);
+   /* check current state directly from internal PHY */
+   e1000_read_phy_reg_gs40g(hw, (E1000_PHY_PLL_FREQ_PAGE |
+E1000_PHY_PLL_FREQ_REG), &phy_word);
if ((phy_word & E1000_PHY_PLL_UNCONF)
!= E1000_PHY_PLL_UNCONF) {
ret_val = E1000_SUCCESS;
@@ -952,14 +952,17 @@ STATIC s32 e1000_pll_workaround_i210(struct e1000_hw *hw)
} else {
ret_val = -E1000_ERR_PHY;
}
-   hw->phy.ops.reset(hw);
+   /* directly reset the internal PHY */
+   ctrl = E1000_READ_REG(hw, E1000_CTRL);
+   E1000_WRITE_REG(hw, E1000_CTRL, ctrl|E1000_CTRL_PHY_RST);
+
ctrl_ext = E1000_READ_REG(hw, E1000_CTRL_EXT);
ctrl_ext |= (E1000_CTRL_EXT_PHYPDEN | E1000_CTRL_EXT_SDLPE);
E1000_WRITE_REG(hw, E1000_CTRL_EXT, ctrl_ext);

E1000_WRITE_REG(hw, E1000_WUC, 0);
reg_val = (E1000_INVM_AUTOLOAD << 4) | (tmp_nvm << 16);
-   E1000_WRITE_REG(hw, E1000_EEARBC, reg_val);
+   E1000_WRITE_REG(hw, E1000_EEARBC_I210, reg_val);

e1000_read_pci_cfg(hw, E1000_PCI_PMCSR, &pci_word);
pci_word |= E1000_PCI_PMCSR_D3;
@@ -968,7 +971,7 @@ STATIC s32 e1000_pll_workaround_i210(struct e1000_hw *hw)
pci_word &= ~E1000_PCI_PMCSR_D3;
e1000_write_pci_cfg(hw, E1000_PCI_PMCSR, &pci_word);
reg_val = (E1000_INVM_AUTOLOAD << 4) | (nvm_word << 16);
-   E1000_WRITE_REG(hw, E1000_EEARBC, reg_val);
+   E1000_WRITE_REG(hw, E1000_EEARBC_I210, reg_val);

/* restore WUC register */
E1000_WRITE_REG(hw, E1000_WUC, wuc);
diff --git a/drivers/net/e1000/base/e1000_regs.h 
b/drivers/net/e1000/base/e1000_regs.h
index 8999b5b..b9fcdea 100644
--- a/drivers/net/e1000/base/e1000_regs.h
+++ b/drivers/net/e1000/base/e1000_regs.h
@@ -110,6 +110,7 @@ POSSIBILITY OF SUCH DAMAGE.
 #define E1000_PBECCSTS 0x0100C  /* Packet Buffer ECC Status - RW */
 #define E1000_EEMNGCTL 0x01010  /* MNG EEprom Control */
 #define E1000_EEARBC   0x01024  /* EEPROM Auto Read Bus Control */
+#define E1000_EEARBC_I210  0x12024 /* EEPROM Auto Read Bus Control */
 #define E1000_FLASHT   0x01028  /* FLASH Timer Register */
 #define E1000_EEWR 0x0102C  /* EEPROM Write Register - RW */
 #define E1000_FLSWCTL  0x01030  /* FLASH control register */
-- 
1.9.3

[dpdk-dev] [PATCH v2 15/35] e1000/base: apply paranoia to macro arguments

[Wenzhuo Lu]

Macro arguments need to be in parens since we can pass in expressions.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/base/e1000_api.h  | 16 
 drivers/net/e1000/base/e1000_hw.h   |  2 +-
 drivers/net/e1000/base/e1000_regs.h |  4 ++--
 3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/net/e1000/base/e1000_api.h 
b/drivers/net/e1000/base/e1000_api.h
index 563d0ca..0bc471d 100644
--- a/drivers/net/e1000/base/e1000_api.h
+++ b/drivers/net/e1000/base/e1000_api.h
@@ -124,14 +124,14 @@ u32  e1000_translate_register_82542(u32 reg);
  * TBI_ACCEPT macro definition:
  *
  * This macro requires:
- *  adapter = a pointer to struct e1000_hw
+ *  a = a pointer to struct e1000_hw
  *  status = the 8 bit status field of the Rx descriptor with EOP set
- *  error = the 8 bit error field of the Rx descriptor with EOP set
+ *  errors = the 8 bit error field of the Rx descriptor with EOP set
  *  length = the sum of all the length fields of the Rx descriptors that
  *   make up the current frame
  *  last_byte = the last byte of the frame DMAed by the hardware
- *  max_frame_length = the maximum frame length we want to accept.
- *  min_frame_length = the minimum frame length we want to accept.
+ *  min_frame_size = the minimum frame length we want to accept.
+ *  max_frame_size = the maximum frame length we want to accept.
  *
  * This macro is a conditional that should be used in the interrupt
  * handler's Rx processing routine when RxErrors have been detected.
@@ -157,10 +157,10 @@ u32  e1000_translate_register_82542(u32 reg);
 (((errors) & E1000_RXD_ERR_FRAME_ERR_MASK) == E1000_RXD_ERR_CE) && \
 ((last_byte) == CARRIER_EXTENSION) && \
 (((status) & E1000_RXD_STAT_VP) ? \
- (((length) > (min_frame_size - VLAN_TAG_SIZE)) && \
- ((length) <= (max_frame_size + 1))) : \
- (((length) > min_frame_size) && \
- ((length) <= (max_frame_size + VLAN_TAG_SIZE + 1)
+ (((length) > ((min_frame_size) - VLAN_TAG_SIZE)) && \
+ ((length) <= ((max_frame_size) + 1))) : \
+ (((length) > (min_frame_size)) && \
+ ((length) <= ((max_frame_size) + VLAN_TAG_SIZE + 1)

 #define E1000_MAX(a, b) ((a) > (b) ? (a) : (b))
 #define E1000_DIVIDE_ROUND_UP(a, b)(((a) + (b) - 1) / (b)) /* ceil(a/b) */
diff --git a/drivers/net/e1000/base/e1000_hw.h 
b/drivers/net/e1000/base/e1000_hw.h
index f06be0c..fd48104 100644
--- a/drivers/net/e1000/base/e1000_hw.h
+++ b/drivers/net/e1000/base/e1000_hw.h
@@ -785,7 +785,7 @@ struct e1000_mac_info {
u16 uta_reg_count;

/* Maximum size of the MTA register table in all supported adapters */
-   #define MAX_MTA_REG 128
+#define MAX_MTA_REG 128
u32 mta_shadow[MAX_MTA_REG];
u16 rar_entry_count;

diff --git a/drivers/net/e1000/base/e1000_regs.h 
b/drivers/net/e1000/base/e1000_regs.h
index b9fcdea..2891da3 100644
--- a/drivers/net/e1000/base/e1000_regs.h
+++ b/drivers/net/e1000/base/e1000_regs.h
@@ -203,7 +203,7 @@ POSSIBILITY OF SUCH DAMAGE.
 /* Queues fetch arbitration priority control register */
 #define E1000_I210_TQAVARBCTRL 0x3574
 /* Queues priority masks where _n and _p can be 0-3. */
-#define E1000_TQAVARBCTRL_QUEUE_PRI(_n, _p)((_p) << (2 * _n))
+#define E1000_TQAVARBCTRL_QUEUE_PRI(_n, _p)((_p) << (2 * (_n)))
 /* QAV Tx mode control registers where _n can be 0 or 1. */
 #define E1000_I210_TQAVCC(_n)  (0x3004 + 0x40 * (_n))

@@ -216,7 +216,7 @@ POSSIBILITY OF SUCH DAMAGE.
 #define E1000_PQGPTC(_n)   (0x010014 + (0x100 * (_n)))

 /* Queues packet buffer size masks where _n can be 0-3 and _s 0-63 [kB] */
-#define E1000_I210_TXPBS_SIZE(_n, _s)  ((_s) << (6 * _n))
+#define E1000_I210_TXPBS_SIZE(_n, _s)  ((_s) << (6 * (_n)))

 #define E1000_MMDAC13 /* MMD Access Control */
 #define E1000_MMDAAD   14 /* MMD Access Address/Data */
-- 
1.9.3

[dpdk-dev] [PATCH v2 16/35] e1000/base: add flags to set eee advertisement modes

[Wenzhuo Lu]

!!! REQUIRES DRIVER CHANGES !!!

Change e1000_set_eee_i350 and e1000_set_eee_i354 to have flags allowing
changes in the advertised EEE speeds.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/base/e1000_82575.c | 34 +++---
 drivers/net/e1000/base/e1000_82575.h |  4 ++--
 2 files changed, 29 insertions(+), 9 deletions(-)

diff --git a/drivers/net/e1000/base/e1000_82575.c 
b/drivers/net/e1000/base/e1000_82575.c
index 3bdcf69..81e6011 100644
--- a/drivers/net/e1000/base/e1000_82575.c
+++ b/drivers/net/e1000/base/e1000_82575.c
@@ -2893,13 +2893,14 @@ out:
 /**
  *  e1000_set_eee_i350 - Enable/disable EEE support
  *  @hw: pointer to the HW structure
+ *  @adv1g: boolean flag enabling 1G EEE advertisement
+ *  @adv100m: boolean flag enabling 100M EEE advertisement
  *
  *  Enable/disable EEE based on setting in dev_spec structure.
  *
  **/
-s32 e1000_set_eee_i350(struct e1000_hw *hw)
+s32 e1000_set_eee_i350(struct e1000_hw *hw, bool adv1G, bool adv100M)
 {
-   s32 ret_val = E1000_SUCCESS;
u32 ipcnfg, eeer;

DEBUGFUNC("e1000_set_eee_i350");
@@ -2914,7 +2915,16 @@ s32 e1000_set_eee_i350(struct e1000_hw *hw)
if (!(hw->dev_spec._82575.eee_disable)) {
u32 eee_su = E1000_READ_REG(hw, E1000_EEE_SU);

-   ipcnfg |= (E1000_IPCNFG_EEE_1G_AN | E1000_IPCNFG_EEE_100M_AN);
+   if (adv100M)
+   ipcnfg |= E1000_IPCNFG_EEE_100M_AN;
+   else
+   ipcnfg &= ~E1000_IPCNFG_EEE_100M_AN;
+
+   if (adv1G)
+   ipcnfg |= E1000_IPCNFG_EEE_1G_AN;
+   else
+   ipcnfg &= ~E1000_IPCNFG_EEE_1G_AN;
+
eeer |= (E1000_EEER_TX_LPI_EN | E1000_EEER_RX_LPI_EN |
 E1000_EEER_LPI_FC);

@@ -2932,17 +2942,19 @@ s32 e1000_set_eee_i350(struct e1000_hw *hw)
E1000_READ_REG(hw, E1000_EEER);
 out:

-   return ret_val;
+   return E1000_SUCCESS;
 }

 /**
  *  e1000_set_eee_i354 - Enable/disable EEE support
  *  @hw: pointer to the HW structure
+ *  @adv1g: boolean flag enabling 1G EEE advertisement
+ *  @adv100m: boolean flag enabling 100M EEE advertisement
  *
  *  Enable/disable EEE legacy mode based on setting in dev_spec structure.
  *
  **/
-s32 e1000_set_eee_i354(struct e1000_hw *hw)
+s32 e1000_set_eee_i354(struct e1000_hw *hw, bool adv1G, bool adv100M)
 {
struct e1000_phy_info *phy = &hw->phy;
s32 ret_val = E1000_SUCCESS;
@@ -2984,8 +2996,16 @@ s32 e1000_set_eee_i354(struct e1000_hw *hw)
if (ret_val)
goto out;

-   phy_data |= E1000_EEE_ADV_100_SUPPORTED |
-   E1000_EEE_ADV_1000_SUPPORTED;
+   if (adv100M)
+   phy_data |= E1000_EEE_ADV_100_SUPPORTED;
+   else
+   phy_data &= ~E1000_EEE_ADV_100_SUPPORTED;
+
+   if (adv1G)
+   phy_data |= E1000_EEE_ADV_1000_SUPPORTED;
+   else
+   phy_data &= ~E1000_EEE_ADV_1000_SUPPORTED;
+
ret_val = e1000_write_xmdio_reg(hw, E1000_EEE_ADV_ADDR_I354,
E1000_EEE_ADV_DEV_I354,
phy_data);
diff --git a/drivers/net/e1000/base/e1000_82575.h 
b/drivers/net/e1000/base/e1000_82575.h
index 0c8a464..7a46ceb 100644
--- a/drivers/net/e1000/base/e1000_82575.h
+++ b/drivers/net/e1000/base/e1000_82575.h
@@ -494,8 +494,8 @@ void e1000_rlpml_set_vf(struct e1000_hw *, u16);
 s32 e1000_promisc_set_vf(struct e1000_hw *, enum e1000_promisc_type type);
 u16 e1000_rxpbs_adjust_82580(u32 data);
 s32 e1000_read_emi_reg(struct e1000_hw *hw, u16 addr, u16 *data);
-s32 e1000_set_eee_i350(struct e1000_hw *);
-s32 e1000_set_eee_i354(struct e1000_hw *);
+s32 e1000_set_eee_i350(struct e1000_hw *hw, bool adv1G, bool adv100M);
+s32 e1000_set_eee_i354(struct e1000_hw *hw, bool adv1G, bool adv100M);
 s32 e1000_get_eee_status_i354(struct e1000_hw *, bool *);
 s32 e1000_initialize_M88E1512_phy(struct e1000_hw *hw);

-- 
1.9.3

[dpdk-dev] [PATCH v2 17/35] e1000/base: prevent ulp flow if cable connected

[Wenzhuo Lu]

Enabling ulp on link down when cable is connect caused an infinite
loop of linkup/down indications in the NDIS driver.
After discussed, correct flow is to enable ULP only when cable is
disconnected.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/base/e1000_ich8lan.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/e1000/base/e1000_ich8lan.c 
b/drivers/net/e1000/base/e1000_ich8lan.c
index 228d4c5..5077a3f 100644
--- a/drivers/net/e1000/base/e1000_ich8lan.c
+++ b/drivers/net/e1000/base/e1000_ich8lan.c
@@ -1089,6 +1089,9 @@ s32 e1000_enable_ulp_lpt_lp(struct e1000_hw *hw, bool 
to_sx)
  (E1000_READ_REG(hw, E1000_FEXT) &
   E1000_FEXT_PHY_CABLE_DISCONNECTED) ? "" : "not",
  i * 50);
+   if (!(E1000_READ_REG(hw, E1000_FEXT) &
+   E1000_FEXT_PHY_CABLE_DISCONNECTED))
+   return 0;
}

if (E1000_READ_REG(hw, E1000_FWSM) & E1000_ICH_FWSM_FW_VALID) {
-- 
1.9.3

[dpdk-dev] [PATCH v2 18/35] e1000/base: fix TIPG value for non 10 half duplex mode

[Wenzhuo Lu]

TIPG value is increased when setting speed to 10 half to prevent
packet loss. However, it was never decreased again when speed
changes. This caused performance issues in the NDIS driver.
Fix this to restore TIPG to default value on non 10 half.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/base/e1000_ich8lan.c | 49 +++---
 1 file changed, 28 insertions(+), 21 deletions(-)

diff --git a/drivers/net/e1000/base/e1000_ich8lan.c 
b/drivers/net/e1000/base/e1000_ich8lan.c
index 5077a3f..4ffaeef 100644
--- a/drivers/net/e1000/base/e1000_ich8lan.c
+++ b/drivers/net/e1000/base/e1000_ich8lan.c
@@ -1392,7 +1392,8 @@ out:
 STATIC s32 e1000_check_for_copper_link_ich8lan(struct e1000_hw *hw)
 {
struct e1000_mac_info *mac = &hw->mac;
-   s32 ret_val;
+   s32 ret_val, tipg_reg = 0;
+   u16 emi_addr, emi_val = 0;
bool link = false;
u16 phy_reg;

@@ -1442,32 +1443,38 @@ STATIC s32 e1000_check_for_copper_link_ich8lan(struct 
e1000_hw *hw)
 */
if (((hw->mac.type == e1000_pch2lan) ||
 (hw->mac.type == e1000_pch_lpt)) && link) {
-   u32 reg;
-   reg = E1000_READ_REG(hw, E1000_STATUS);
-   if (!(reg & (E1000_STATUS_FD | E1000_STATUS_SPEED_MASK))) {
-   u16 emi_addr;
+   u16 speed, duplex;

-   reg = E1000_READ_REG(hw, E1000_TIPG);
-   reg &= ~E1000_TIPG_IPGT_MASK;
-   reg |= 0xFF;
-   E1000_WRITE_REG(hw, E1000_TIPG, reg);
+   e1000_get_speed_and_duplex_copper_generic(hw, &speed, &duplex);
+   tipg_reg = E1000_READ_REG(hw, E1000_TIPG);
+   tipg_reg &= ~E1000_TIPG_IPGT_MASK;

+   if (duplex == HALF_DUPLEX && speed == SPEED_10) {
+   tipg_reg |= 0xFF;
/* Reduce Rx latency in analog PHY */
-   ret_val = hw->phy.ops.acquire(hw);
-   if (ret_val)
-   return ret_val;
+   emi_val = 0;
+   } else {
+   /* Roll back the default values */
+   tipg_reg |= 0x08;
+   emi_val = 1;
+   }

-   if (hw->mac.type == e1000_pch2lan)
-   emi_addr = I82579_RX_CONFIG;
-   else
-   emi_addr = I217_RX_CONFIG;
-   ret_val = e1000_write_emi_reg_locked(hw, emi_addr, 0);
+   E1000_WRITE_REG(hw, E1000_TIPG, tipg_reg);

-   hw->phy.ops.release(hw);
+   ret_val = hw->phy.ops.acquire(hw);
+   if (ret_val)
+   return ret_val;

-   if (ret_val)
-   return ret_val;
-   }
+   if (hw->mac.type == e1000_pch2lan)
+   emi_addr = I82579_RX_CONFIG;
+   else
+   emi_addr = I217_RX_CONFIG;
+   ret_val = e1000_write_emi_reg_locked(hw, emi_addr, emi_val);
+
+   hw->phy.ops.release(hw);
+
+   if (ret_val)
+   return ret_val;
}

/* Work-around I218 hang issue */
-- 
1.9.3

[dpdk-dev] [PATCH v2 19/35] e1000/base: add return value for resume workaround

[Wenzhuo Lu]

Add u32 return value to function e1000_resume_workarounds_pchlan,
so that calling function can detect PHY access failure during resuming
flow.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/base/e1000_ich8lan.c | 11 ++-
 drivers/net/e1000/base/e1000_ich8lan.h |  2 +-
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/net/e1000/base/e1000_ich8lan.c 
b/drivers/net/e1000/base/e1000_ich8lan.c
index 4ffaeef..5635dd5 100644
--- a/drivers/net/e1000/base/e1000_ich8lan.c
+++ b/drivers/net/e1000/base/e1000_ich8lan.c
@@ -4943,19 +4943,18 @@ out:
  *  the PHY.
  *  On i217, setup Intel Rapid Start Technology.
  **/
-void e1000_resume_workarounds_pchlan(struct e1000_hw *hw)
+u32 e1000_resume_workarounds_pchlan(struct e1000_hw *hw)
 {
s32 ret_val;

DEBUGFUNC("e1000_resume_workarounds_pchlan");
-
if (hw->mac.type < e1000_pch2lan)
-   return;
+   return E1000_SUCCESS;

ret_val = e1000_init_phy_workarounds_pchlan(hw);
if (ret_val) {
DEBUGOUT1("Failed to init PHY flow ret_val=%d\n", ret_val);
-   return;
+   return ret_val;
}

/* For i217 Intel Rapid Start Technology support when the system
@@ -4969,7 +4968,7 @@ void e1000_resume_workarounds_pchlan(struct e1000_hw *hw)
ret_val = hw->phy.ops.acquire(hw);
if (ret_val) {
DEBUGOUT("Failed to setup iRST\n");
-   return;
+   return ret_val;
}

/* Clear Auto Enable LPI after link up */
@@ -5003,7 +5002,9 @@ release:
if (ret_val)
DEBUGOUT1("Error %d in resume workarounds\n", ret_val);
hw->phy.ops.release(hw);
+   return ret_val;
}
+   return E1000_SUCCESS;
 }

 /**
diff --git a/drivers/net/e1000/base/e1000_ich8lan.h 
b/drivers/net/e1000/base/e1000_ich8lan.h
index c690d9e..130627c 100644
--- a/drivers/net/e1000/base/e1000_ich8lan.h
+++ b/drivers/net/e1000/base/e1000_ich8lan.h
@@ -300,7 +300,7 @@ void e1000_set_kmrn_lock_loss_workaround_ich8lan(struct 
e1000_hw *hw,
 void e1000_igp3_phy_powerdown_workaround_ich8lan(struct e1000_hw *hw);
 void e1000_gig_downshift_workaround_ich8lan(struct e1000_hw *hw);
 void e1000_suspend_workarounds_ich8lan(struct e1000_hw *hw);
-void e1000_resume_workarounds_pchlan(struct e1000_hw *hw);
+u32 e1000_resume_workarounds_pchlan(struct e1000_hw *hw);
 s32 e1000_configure_k1_ich8lan(struct e1000_hw *hw, bool k1_enable);
 void e1000_copy_rx_addrs_to_phy_ich8lan(struct e1000_hw *hw);
 s32 e1000_lv_jumbo_workaround_ich8lan(struct e1000_hw *hw, bool enable);
-- 
1.9.3

[dpdk-dev] [PATCH v2 20/35] e1000/base: fix link detect flow

[Wenzhuo Lu]

In case that auto-negotiate is not enabled, call
e1000_setup_copper_link_generic instead of e1000_phy_setup_autoneg.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/base/e1000_ich8lan.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/net/e1000/base/e1000_ich8lan.c 
b/drivers/net/e1000/base/e1000_ich8lan.c
index 5635dd5..d10c5d8 100644
--- a/drivers/net/e1000/base/e1000_ich8lan.c
+++ b/drivers/net/e1000/base/e1000_ich8lan.c
@@ -1254,10 +1254,15 @@ s32 e1000_disable_ulp_lpt_lp(struct e1000_hw *hw, bool 
force)
/* Restore link speed advertisements and restart
 * Auto-negotiation
 */
-   ret_val = e1000_phy_setup_autoneg(hw);
-   if (ret_val)
-   goto out;
-
+   if (hw->mac.autoneg) {
+   ret_val = e1000_phy_setup_autoneg(hw);
+   if (ret_val)
+   goto out;
+   } else {
+   ret_val = e1000_setup_copper_link_generic(hw);
+   if (ret_val)
+   goto out;
+   }
ret_val = e1000_oem_bits_config_ich8lan(hw, true);
}

-- 
1.9.3

[dpdk-dev] [PATCH v2 21/35] e1000/base: cleanup NAHUM6LP_HW tags

[Wenzhuo Lu]

Remove all NAHUM6LP_HW tags.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/base/e1000_hw.h  |  6 +++---
 drivers/net/e1000/base/e1000_ich8lan.c |  9 +
 drivers/net/e1000/base/e1000_ich8lan.h | 29 ++---
 drivers/net/e1000/base/e1000_osdep.h   |  1 -
 drivers/net/e1000/base/e1000_regs.h|  4 ++--
 5 files changed, 24 insertions(+), 25 deletions(-)

diff --git a/drivers/net/e1000/base/e1000_hw.h 
b/drivers/net/e1000/base/e1000_hw.h
index fd48104..e4e4f76 100644
--- a/drivers/net/e1000/base/e1000_hw.h
+++ b/drivers/net/e1000/base/e1000_hw.h
@@ -935,7 +935,7 @@ struct e1000_shadow_ram {

 #define E1000_SHADOW_RAM_WORDS 2048

-#if defined(NAHUM6LP_HW) && defined(ULP_SUPPORT)
+#ifdef ULP_SUPPORT
 /* I218 PHY Ultra Low Power (ULP) states */
 enum e1000_ulp_state {
e1000_ulp_state_unknown,
@@ -943,7 +943,7 @@ enum e1000_ulp_state {
e1000_ulp_state_on,
 };

-#endif /* NAHUM6LP_HW && ULP_SUPPORT */
+#endif /* ULP_SUPPORT */
 struct e1000_dev_spec_ich8lan {
bool kmrn_lock_loss_workaround_enabled;
struct e1000_shadow_ram shadow_ram[E1000_SHADOW_RAM_WORDS];
@@ -952,7 +952,7 @@ struct e1000_dev_spec_ich8lan {
bool nvm_k1_enabled;
bool eee_disable;
u16 eee_lp_ability;
-#if defined(NAHUM6LP_HW) && defined(ULP_SUPPORT)
+#ifdef ULP_SUPPORT
enum e1000_ulp_state ulp_state;
 #endif /* NAHUM6LP_HW && ULP_SUPPORT */
u16 lat_enc;
diff --git a/drivers/net/e1000/base/e1000_ich8lan.c 
b/drivers/net/e1000/base/e1000_ich8lan.c
index d10c5d8..782da2a 100644
--- a/drivers/net/e1000/base/e1000_ich8lan.c
+++ b/drivers/net/e1000/base/e1000_ich8lan.c
@@ -311,13 +311,13 @@ STATIC s32 e1000_init_phy_workarounds_pchlan(struct 
e1000_hw *hw)
 */
e1000_gate_hw_phy_config_ich8lan(hw, true);

-#if defined(NAHUM6LP_HW) && defined(ULP_SUPPORT)
+#ifdef ULP_SUPPORT
/* It is not possible to be certain of the current state of ULP
 * so forcibly disable it.
 */
hw->dev_spec.ich8lan.ulp_state = e1000_ulp_state_unknown;

-#endif /* NAHUM6LP_HW && ULP_SUPPORT */
+#endif /* ULP_SUPPORT */
ret_val = hw->phy.ops.acquire(hw);
if (ret_val) {
DEBUGOUT("Failed to initialize PHY flow\n");
@@ -758,6 +758,7 @@ STATIC s32 e1000_init_mac_params_ich8lan(struct e1000_hw 
*hw)
/* multicast address update for pch2 */
mac->ops.update_mc_addr_list =
e1000_update_mc_addr_list_pch2lan;
+   /* fall-through */
 #endif
case e1000_pchlan:
 #if defined(QV_RELEASE) || !defined(NO_PCH_LPT_B0_SUPPORT)
@@ -1047,7 +1048,7 @@ update_fextnvm6:
return ret_val;
 }

-#if defined(NAHUM6LP_HW) && defined(ULP_SUPPORT)
+#ifdef ULP_SUPPORT
 /**
  *  e1000_enable_ulp_lpt_lp - configure Ultra Low Power mode for LynxPoint-LP
  *  @hw: pointer to the HW structure
@@ -1385,7 +1386,7 @@ out:
return ret_val;
 }

-#endif /* NAHUM6LP_HW && ULP_SUPPORT */
+#endif /* ULP_SUPPORT */
 /**
  *  e1000_check_for_copper_link_ich8lan - Check for link (Copper)
  *  @hw: pointer to the HW structure
diff --git a/drivers/net/e1000/base/e1000_ich8lan.h 
b/drivers/net/e1000/base/e1000_ich8lan.h
index 130627c..f5d8ab1 100644
--- a/drivers/net/e1000/base/e1000_ich8lan.h
+++ b/drivers/net/e1000/base/e1000_ich8lan.h
@@ -69,22 +69,22 @@ POSSIBILITY OF SUCH DAMAGE.

 #define E1000_FWSM_WLOCK_MAC_MASK  0x0380
 #define E1000_FWSM_WLOCK_MAC_SHIFT 7
-#if !defined(EXTERNAL_RELEASE) || (defined(NAHUM6LP_HW) && 
defined(ULP_SUPPORT))
+#if !defined(EXTERNAL_RELEASE) || defined(ULP_SUPPORT)
 #define E1000_FWSM_ULP_CFG_DONE0x0400  /* Low power cfg 
done */
-#endif /* !EXTERNAL_RELEASE || (NAHUM6LP_HW && ULP_SUPPORT) */
+#endif /* !EXTERNAL_RELEASE || ULP_SUPPORT */

 /* Shared Receive Address Registers */
 #define E1000_SHRAL_PCH_LPT(_i)(0x05408 + ((_i) * 8))
 #define E1000_SHRAH_PCH_LPT(_i)(0x0540C + ((_i) * 8))

-#if !defined(EXTERNAL_RELEASE) || (defined(NAHUM6LP_HW) && 
defined(ULP_SUPPORT))
+#if !defined(EXTERNAL_RELEASE) || defined(ULP_SUPPORT)
 #define E1000_H2ME 0x05B50/* Host to ME */
-#endif /* !EXTERNAL_RELEASE || (NAHUM6LP_HW && ULP_SUPPORT) */
-#if !defined(EXTERNAL_RELEASE) || (defined(NAHUM6LP_HW) && 
defined(ULP_SUPPORT))
+#endif /* !EXTERNAL_RELEASE || ULP_SUPPORT */
+#if !defined(EXTERNAL_RELEASE) || defined(ULP_SUPPORT)
 #define E1000_H2ME_ULP 0x0800 /* ULP Indication Bit */
 #define E1000_H2ME_ENFORCE_SETTINGS0x1000 /* Enforce Settings */

-#endif /* !EXTERNAL_RELEASE || (NAHUM6LP_HW && ULP_SUPPORT) */
+#endif /* !EXTERNAL_RELEASE || ULP_SUPPORT */
 #define ID_LED_DEFAULT_ICH8LAN ((ID_LED_DEF1_DEF2 << 12) | \
 (ID_LED_OFF1_OFF2 <<  8) | \
 (ID_LED_OFF1_ON2  <<  4) | \
@@ -97,11 +97,11 @@ POSSIBILITY OF SUCH DAMAGE.

 #define E1000_ICH8_LAN_INIT_TIMEOUT1500

-#if !de

[dpdk-dev] [PATCH v2 22/35] e1000/base: add bit for disable packetbuffer read

[Wenzhuo Lu]

Added bit FEXTNVM7[18], that controls disabling MAC packet buffer read.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/base/e1000_ich8lan.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/e1000/base/e1000_ich8lan.h 
b/drivers/net/e1000/base/e1000_ich8lan.h
index f5d8ab1..f7f66a4 100644
--- a/drivers/net/e1000/base/e1000_ich8lan.h
+++ b/drivers/net/e1000/base/e1000_ich8lan.h
@@ -115,6 +115,8 @@ POSSIBILITY OF SUCH DAMAGE.
 #define E1000_FEXTNVM6_REQ_PLL_CLK 0x0100
 #define E1000_FEXTNVM6_ENABLE_K1_ENTRY_CONDITION   0x0200

+/* bit for disabling packet buffer read */
+#define E1000_FEXTNVM7_DISABLE_PB_READ 0x0004
 #if !defined(EXTERNAL_RELEASE) || defined(ULP_SUPPORT)
 #define E1000_FEXTNVM7_DISABLE_SMB_PERST   0x0020
 #endif /* !EXTERNAL_RELEASE || ULP_SUPPORT */
-- 
1.9.3

[dpdk-dev] [PATCH v2 24/35] e1000/base: remove FIXME comment

[Wenzhuo Lu]

The "FIXME" comment is revomed from e1000_acquire_swfw_sync_80003es2lan
but forgotten being removed from e1000_acquire_swfw_sync_82575 while
the similar changes were made to both.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/base/e1000_82575.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/e1000/base/e1000_82575.c 
b/drivers/net/e1000/base/e1000_82575.c
index 81e6011..511636a 100644
--- a/drivers/net/e1000/base/e1000_82575.c
+++ b/drivers/net/e1000/base/e1000_82575.c
@@ -1050,7 +1050,7 @@ STATIC s32 e1000_acquire_swfw_sync_82575(struct e1000_hw 
*hw, u16 mask)
u32 swmask = mask;
u32 fwmask = mask << 16;
s32 ret_val = E1000_SUCCESS;
-   s32 i = 0, timeout = 200; /* FIXME: find real value to use here */
+   s32 i = 0, timeout = 200;

DEBUGFUNC("e1000_acquire_swfw_sync_82575");

-- 
1.9.3

[dpdk-dev] [PATCH v2 26/35] e1000/base: disable extension header parsing for IPv6

[Wenzhuo Lu]

All 1G Server products need to have IPv6 extension headers turned off.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/base/e1000_82575.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/net/e1000/base/e1000_82575.c 
b/drivers/net/e1000/base/e1000_82575.c
index 511636a..e170353 100644
--- a/drivers/net/e1000/base/e1000_82575.c
+++ b/drivers/net/e1000/base/e1000_82575.c
@@ -2125,7 +2125,7 @@ STATIC void e1000_clear_hw_cntrs_82575(struct e1000_hw 
*hw)
  *  e1000_rx_fifo_flush_82575 - Clean rx fifo after Rx enable
  *  @hw: pointer to the HW structure
  *
- *  After rx enable if managability is enabled then there is likely some
+ *  After Rx enable, if manageability is enabled then there is likely some
  *  bad data at the start of the fifo and possibly in the DMA fifo.  This
  *  function clears the fifos and flushes any packets that came in as rx was
  *  being enabled.
@@ -2135,7 +2135,13 @@ void e1000_rx_fifo_flush_82575(struct e1000_hw *hw)
u32 rctl, rlpml, rxdctl[4], rfctl, temp_rctl, rx_enabled;
int i, ms_wait;

-   DEBUGFUNC("e1000_rx_fifo_workaround_82575");
+   DEBUGFUNC("e1000_rx_fifo_flush_82575");
+
+   /* disable IPv6 options as per hardware errata */
+   rfctl = E1000_READ_REG(hw, E1000_RFCTL);
+   rfctl |= E1000_RFCTL_IPV6_EX_DIS;
+   E1000_WRITE_REG(hw, E1000_RFCTL, rfctl);
+
if (hw->mac.type != e1000_82575 ||
!(E1000_READ_REG(hw, E1000_MANC) & E1000_MANC_RCV_TCO_EN))
return;
@@ -2163,7 +2169,6 @@ void e1000_rx_fifo_flush_82575(struct e1000_hw *hw)
 * incoming packets are rejected.  Set enable and wait 2ms so that
 * any packet that was coming in as RCTL.EN was set is flushed
 */
-   rfctl = E1000_READ_REG(hw, E1000_RFCTL);
E1000_WRITE_REG(hw, E1000_RFCTL, rfctl & ~E1000_RFCTL_LEF);

rlpml = E1000_READ_REG(hw, E1000_RLPML);
-- 
1.9.3

[dpdk-dev] [PATCH v2 27/35] e1000/base: fix for i354 88E1112 PHY using AutoMedia Detect

[Wenzhuo Lu]

e1000_check_for_link_media_swap() is supposed to check PHY page 0 for
copper and PHY page 1 for "other" (fiber) link. We switched back from
page 1 to page 0 too soon, before e1000_check_for_link_82575() is
executed and we were never finding link on fiber (other).

Note: The precedence of link type is controlled by the PHY settings.

If the link is copper, as the M88E1112 page address is set to 1, it should be
set back to 0 before checking this link.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/base/e1000_82575.c | 23 +++
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/net/e1000/base/e1000_82575.c 
b/drivers/net/e1000/base/e1000_82575.c
index e170353..4374eab 100644
--- a/drivers/net/e1000/base/e1000_82575.c
+++ b/drivers/net/e1000/base/e1000_82575.c
@@ -1234,7 +1234,7 @@ STATIC s32 e1000_check_for_link_media_swap(struct 
e1000_hw *hw)

DEBUGFUNC("e1000_check_for_link_media_swap");

-   /* Check the copper medium. */
+   /* Check for copper. */
ret_val = phy->ops.write_reg(hw, E1000_M88E1112_PAGE_ADDR, 0);
if (ret_val)
return ret_val;
@@ -1246,7 +1246,7 @@ STATIC s32 e1000_check_for_link_media_swap(struct 
e1000_hw *hw)
if (data & E1000_M88E1112_STATUS_LINK)
port = E1000_MEDIA_PORT_COPPER;

-   /* Check the other medium. */
+   /* Check for other. */
ret_val = phy->ops.write_reg(hw, E1000_M88E1112_PAGE_ADDR, 1);
if (ret_val)
return ret_val;
@@ -1255,11 +1255,6 @@ STATIC s32 e1000_check_for_link_media_swap(struct 
e1000_hw *hw)
if (ret_val)
return ret_val;

-   /* reset page to 0 */
-   ret_val = phy->ops.write_reg(hw, E1000_M88E1112_PAGE_ADDR, 0);
-   if (ret_val)
-   return ret_val;
-
if (data & E1000_M88E1112_STATUS_LINK)
port = E1000_MEDIA_PORT_OTHER;

@@ -1267,8 +1262,20 @@ STATIC s32 e1000_check_for_link_media_swap(struct 
e1000_hw *hw)
if (port && (hw->dev_spec._82575.media_port != port)) {
hw->dev_spec._82575.media_port = port;
hw->dev_spec._82575.media_changed = true;
+   }
+
+   if (port == E1000_MEDIA_PORT_COPPER) {
+   /* reset page to 0 */
+   ret_val = phy->ops.write_reg(hw, E1000_M88E1112_PAGE_ADDR, 0);
+   if (ret_val)
+   return ret_val;
+   e1000_check_for_link_82575(hw);
} else {
-   ret_val = e1000_check_for_link_82575(hw);
+   e1000_check_for_link_82575(hw);
+   /* reset page to 0 */
+   ret_val = phy->ops.write_reg(hw, E1000_M88E1112_PAGE_ADDR, 0);
+   if (ret_val)
+   return ret_val;
}

return E1000_SUCCESS;
-- 
1.9.3

[dpdk-dev] [PATCH v2 28/35] e1000/base: increase timeout of polling bit RSPCIPHY in check_reset_block

[Wenzhuo Lu]

Previously, in check_reset_block RSPCIPHY was polled for 100 ms before 
determining
that the ME veto is set. This needed to be increased to 300 ms.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/base/e1000_ich8lan.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/e1000/base/e1000_ich8lan.c 
b/drivers/net/e1000/base/e1000_ich8lan.c
index 7b7c631..70eba71 100644
--- a/drivers/net/e1000/base/e1000_ich8lan.c
+++ b/drivers/net/e1000/base/e1000_ich8lan.c
@@ -1991,7 +1991,7 @@ STATIC s32 e1000_check_reset_block_ich8lan(struct 
e1000_hw *hw)
continue;
}
blocked = false;
-   } while (blocked && (i++ < 10));
+   } while (blocked && (i++ < 30));
return blocked ? E1000_BLK_PHY_RESET : E1000_SUCCESS;
 }

-- 
1.9.3

[dpdk-dev] [PATCH v2 23/35] e1000/base: K1 flow fixes

[Wenzhuo Lu]

This patch is for the following updates to the K1 configurations:
Tx idle period for entering K1 should be 128 ns.
Minimum Tx idle period in K1 should be 256 ns.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/base/e1000_ich8lan.c | 47 +-
 drivers/net/e1000/base/e1000_ich8lan.h |  5 +++-
 drivers/net/e1000/base/e1000_phy.h |  7 +
 drivers/net/e1000/base/e1000_regs.h|  1 +
 4 files changed, 58 insertions(+), 2 deletions(-)

diff --git a/drivers/net/e1000/base/e1000_ich8lan.c 
b/drivers/net/e1000/base/e1000_ich8lan.c
index 782da2a..56e20b4 100644
--- a/drivers/net/e1000/base/e1000_ich8lan.c
+++ b/drivers/net/e1000/base/e1000_ich8lan.c
@@ -1492,10 +1492,14 @@ STATIC s32 e1000_check_for_copper_link_ich8lan(struct 
e1000_hw *hw)
if (ret_val)
return ret_val;
}
-
/* Clear link partner's EEE ability */
hw->dev_spec.ich8lan.eee_lp_ability = 0;

+   /* Configure K0s minimum time */
+   if (hw->mac.type == e1000_pch_lpt) {
+   e1000_configure_k0s_lpt(hw, K1_ENTRY_LATENCY, K1_MIN_TIME);
+   }
+
if (!link)
return E1000_SUCCESS; /* No link detected */

@@ -5298,3 +5302,44 @@ release:
}
 }

+/**
+ *  e1000_configure_k0s_lpt - Configure K0s power state
+ *  @hw: pointer to the HW structure
+ *  @entry_latency: Tx idle period for entering K0s - valid values are 0 to 3.
+ * 0 corresponds to 128ns, each value over 0 doubles the duration.
+ *  @min_time: Minimum Tx idle period allowed  - valid values are 0 to 4.
+ * 0 corresponds to 128ns, each value over 0 doubles the duration.
+ *
+ *  Configure the K1 power state based on the provided parameter.
+ *  Assumes semaphore already acquired.
+ *
+ *  Success returns 0, Failure returns:
+ * -E1000_ERR_PHY (-2) in case of access error
+ * -E1000_ERR_PARAM (-4) in case of parameters error
+ **/
+s32 e1000_configure_k0s_lpt(struct e1000_hw *hw, u8 entry_latency, u8 min_time)
+{
+   s32 ret_val;
+   u16 kmrn_reg = 0;
+
+   DEBUGFUNC("e1000_configure_k0s_lpt");
+
+   if (entry_latency > 3 || min_time > 4)
+   return -E1000_ERR_PARAM;
+
+   ret_val = e1000_read_kmrn_reg_locked(hw, E1000_KMRNCTRLSTA_K0S_CTRL,
+&kmrn_reg);
+   if (ret_val)
+   return ret_val;
+
+   /* for now don't touch the latency */
+   kmrn_reg &= ~(E1000_KMRNCTRLSTA_K0S_CTRL_MIN_TIME_MASK);
+   kmrn_reg |= ((min_time << E1000_KMRNCTRLSTA_K0S_CTRL_MIN_TIME_SHIFT));
+
+   ret_val = e1000_write_kmrn_reg_locked(hw, E1000_KMRNCTRLSTA_K0S_CTRL,
+ kmrn_reg);
+   if (ret_val)
+   return ret_val;
+
+   return E1000_SUCCESS;
+}
diff --git a/drivers/net/e1000/base/e1000_ich8lan.h 
b/drivers/net/e1000/base/e1000_ich8lan.h
index f7f66a4..c54e4e7 100644
--- a/drivers/net/e1000/base/e1000_ich8lan.h
+++ b/drivers/net/e1000/base/e1000_ich8lan.h
@@ -114,7 +114,7 @@ POSSIBILITY OF SUCH DAMAGE.

 #define E1000_FEXTNVM6_REQ_PLL_CLK 0x0100
 #define E1000_FEXTNVM6_ENABLE_K1_ENTRY_CONDITION   0x0200
-
+#define E1000_FEXTNVM6_K1_OFF_ENABLE   0x8000
 /* bit for disabling packet buffer read */
 #define E1000_FEXTNVM7_DISABLE_PB_READ 0x0004
 #if !defined(EXTERNAL_RELEASE) || defined(ULP_SUPPORT)
@@ -181,6 +181,8 @@ POSSIBILITY OF SUCH DAMAGE.

 #define E1000_NVM_K1_CONFIG0x1B /* NVM K1 Config Word */
 #define E1000_NVM_K1_ENABLE0x1  /* NVM Enable K1 bit */
+#define K1_ENTRY_LATENCY   0
+#define K1_MIN_TIME1

 /* SMBus Control Phy Register */
 #define CV_SMB_CTRLPHY_REG(769, 23)
@@ -303,6 +305,7 @@ void e1000_gig_downshift_workaround_ich8lan(struct e1000_hw 
*hw);
 void e1000_suspend_workarounds_ich8lan(struct e1000_hw *hw);
 u32 e1000_resume_workarounds_pchlan(struct e1000_hw *hw);
 s32 e1000_configure_k1_ich8lan(struct e1000_hw *hw, bool k1_enable);
+s32 e1000_configure_k0s_lpt(struct e1000_hw *hw, u8 entry_latency, u8 
min_time);
 void e1000_copy_rx_addrs_to_phy_ich8lan(struct e1000_hw *hw);
 s32 e1000_lv_jumbo_workaround_ich8lan(struct e1000_hw *hw, bool enable);
 s32 e1000_read_emi_reg_locked(struct e1000_hw *hw, u16 addr, u16 *data);
diff --git a/drivers/net/e1000/base/e1000_phy.h 
b/drivers/net/e1000/base/e1000_phy.h
index 2b78af0..3e45a9e 100644
--- a/drivers/net/e1000/base/e1000_phy.h
+++ b/drivers/net/e1000/base/e1000_phy.h
@@ -274,6 +274,13 @@ bool e1000_is_mphy_ready(struct e1000_hw *hw);
 #define E1000_KMRNCTRLSTA_K1_CONFIG0x7
 #define E1000_KMRNCTRLSTA_K1_ENABLE0x0002 /* enable K1 */
 #define E1000_KMRNCTRLSTA_HD_CTRL  0x10   /* Kumeran HD Control */
+#define E1000_KMRNCTRLSTA_K0S_CTRL 0x1E/* Kumeran K0s Control */
+#define E1000_KMRNCTRLSTA_K0S_CTRL_ENTRY_LTNCY_SHIFT   0
+#define E1000_KMRNCTRLSTA_K0S_CTRL_MIN_TIME_SHIFT  4
+#define E1000_KMRNCTRLSTA_K0S_CTRL_ENTRY_LTNCY_MASK\
+   (3 << E100

[dpdk-dev] [PATCH v2 25/35] e1000/base: set correct value of beacon duration

[Wenzhuo Lu]

Fix for I217 Packet Loss issue - The Management Engine sets the FEXTNVM4
Beacon Duration incorrectly.  This fix ensures that the correct value will
always be set. Correct value for this field is 8 usec.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/base/e1000_ich8lan.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/net/e1000/base/e1000_ich8lan.c 
b/drivers/net/e1000/base/e1000_ich8lan.c
index 56e20b4..7b7c631 100644
--- a/drivers/net/e1000/base/e1000_ich8lan.c
+++ b/drivers/net/e1000/base/e1000_ich8lan.c
@@ -1483,6 +1483,20 @@ STATIC s32 e1000_check_for_copper_link_ich8lan(struct 
e1000_hw *hw)
return ret_val;
}

+   /* I217 Packet Loss issue:
+* ensure that FEXTNVM4 Beacon Duration is set correctly
+* on power up.
+* Set the Beacon Duration for I217 to 8 usec
+*/
+   if (hw->mac.type == e1000_pch_lpt) {
+   u32 mac_reg;
+
+   mac_reg = E1000_READ_REG(hw, E1000_FEXTNVM4);
+   mac_reg &= ~E1000_FEXTNVM4_BEACON_DURATION_MASK;
+   mac_reg |= E1000_FEXTNVM4_BEACON_DURATION_8USEC;
+   E1000_WRITE_REG(hw, E1000_FEXTNVM4, mac_reg);
+   }
+
/* Work-around I218 hang issue */
if ((hw->device_id == E1000_DEV_ID_PCH_LPTLP_I218_LM) ||
(hw->device_id == E1000_DEV_ID_PCH_LPTLP_I218_V) ||
-- 
1.9.3

[dpdk-dev] [PATCH v2 29/35] e1000/base: implement 88E1543 PHY initialization

[Wenzhuo Lu]

The initializtion process for 88E1543 PHY.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/base/e1000_82575.c   | 106 -
 drivers/net/e1000/base/e1000_82575.h   |   1 +
 drivers/net/e1000/base/e1000_defines.h |   1 +
 3 files changed, 107 insertions(+), 1 deletion(-)

diff --git a/drivers/net/e1000/base/e1000_82575.c 
b/drivers/net/e1000/base/e1000_82575.c
index 4374eab..723885d 100644
--- a/drivers/net/e1000/base/e1000_82575.c
+++ b/drivers/net/e1000/base/e1000_82575.c
@@ -277,6 +277,11 @@ STATIC s32 e1000_init_phy_params_82575(struct e1000_hw *hw)
if (ret_val)
goto out;
}
+   if (phy->id == M88E1543_E_PHY_ID) {
+   ret_val = e1000_initialize_M88E1543_phy(hw);
+   if (ret_val)
+   goto out;
+   }
break;
case IGP03E1000_E_PHY_ID:
case IGP04E1000_E_PHY_ID:
@@ -2817,7 +2822,7 @@ s32 e1000_read_emi_reg(struct e1000_hw *hw, u16 addr, u16 
*data)
  *  e1000_initialize_M88E1512_phy - Initialize M88E1512 PHY
  *  @hw: pointer to the HW structure
  *
- *  Initialize Marverl 1512 to work correctly with Avoton.
+ *  Initialize Marvell 1512 to work correctly with Avoton.
  **/
 s32 e1000_initialize_M88E1512_phy(struct e1000_hw *hw)
 {
@@ -2903,6 +2908,105 @@ out:
 }

 /**
+ *  e1000_initialize_M88E1543_phy - Initialize M88E1543 PHY
+ *  @hw: pointer to the HW structure
+ *
+ *  Initialize Marvell 1543 to work correctly with Avoton.
+ **/
+s32 e1000_initialize_M88E1543_phy(struct e1000_hw *hw)
+{
+   struct e1000_phy_info *phy = &hw->phy;
+   s32 ret_val = E1000_SUCCESS;
+
+   DEBUGFUNC("e1000_initialize_M88E1543_phy");
+
+   /* Check if this is correct PHY. */
+   if (phy->id != M88E1543_E_PHY_ID)
+   goto out;
+
+   /* Switch to PHY page 0xFF. */
+   ret_val = phy->ops.write_reg(hw, E1000_M88E1543_PAGE_ADDR, 0x00FF);
+   if (ret_val)
+   goto out;
+
+   ret_val = phy->ops.write_reg(hw, E1000_M88E1512_CFG_REG_2, 0x214B);
+   if (ret_val)
+   goto out;
+
+   ret_val = phy->ops.write_reg(hw, E1000_M88E1512_CFG_REG_1, 0x2144);
+   if (ret_val)
+   goto out;
+
+   ret_val = phy->ops.write_reg(hw, E1000_M88E1512_CFG_REG_2, 0x0C28);
+   if (ret_val)
+   goto out;
+
+   ret_val = phy->ops.write_reg(hw, E1000_M88E1512_CFG_REG_1, 0x2146);
+   if (ret_val)
+   goto out;
+
+   ret_val = phy->ops.write_reg(hw, E1000_M88E1512_CFG_REG_2, 0xB233);
+   if (ret_val)
+   goto out;
+
+   ret_val = phy->ops.write_reg(hw, E1000_M88E1512_CFG_REG_1, 0x214D);
+   if (ret_val)
+   goto out;
+
+   ret_val = phy->ops.write_reg(hw, E1000_M88E1512_CFG_REG_2, 0xDC0C);
+   if (ret_val)
+   goto out;
+
+   ret_val = phy->ops.write_reg(hw, E1000_M88E1512_CFG_REG_1, 0x2159);
+   if (ret_val)
+   goto out;
+
+   /* Switch to PHY page 0xFB. */
+   ret_val = phy->ops.write_reg(hw, E1000_M88E1543_PAGE_ADDR, 0x00FB);
+   if (ret_val)
+   goto out;
+
+   ret_val = phy->ops.write_reg(hw, E1000_M88E1512_CFG_REG_3, 0xC00D);
+   if (ret_val)
+   goto out;
+
+   /* Switch to PHY page 0x12. */
+   ret_val = phy->ops.write_reg(hw, E1000_M88E1543_PAGE_ADDR, 0x12);
+   if (ret_val)
+   goto out;
+
+   /* Change mode to SGMII-to-Copper */
+   ret_val = phy->ops.write_reg(hw, E1000_M88E1512_MODE, 0x8001);
+   if (ret_val)
+   goto out;
+
+   /* Switch to PHY page 1. */
+   ret_val = phy->ops.write_reg(hw, E1000_M88E1543_PAGE_ADDR, 0x1);
+   if (ret_val)
+   goto out;
+
+   /* Change mode to 1000BASE-X/SGMII and autoneg enable; reset */
+   ret_val = phy->ops.write_reg(hw, E1000_M88E1543_FIBER_CTRL, 0x9140);
+   if (ret_val)
+   goto out;
+
+   /* Return the PHY to page 0. */
+   ret_val = phy->ops.write_reg(hw, E1000_M88E1543_PAGE_ADDR, 0);
+   if (ret_val)
+   goto out;
+
+   ret_val = phy->ops.commit(hw);
+   if (ret_val) {
+   DEBUGOUT("Error committing the PHY changes\n");
+   return ret_val;
+   }
+
+   msec_delay(1000);
+out:
+   return ret_val;
+}
+
+/**
  *  e1000_set_eee_i350 - Enable/disable EEE support
  *  @hw: pointer to the HW structure
  *  @adv1g: boolean flag enabling 1G EEE advertisement
diff --git a/drivers/net/e1000/base/e1000_82575.h 
b/drivers/net/e1000/base/e1000_82575.h
index 7a46ceb..c498684 100644
--- a/drivers/net/e1000/base/e1000_82575.h
+++ b/drivers/net/e1000/base/e1000_82575.h
@@ -498,6 +498,7 @@ s32 e1000_set_eee_i350(struct e1000_hw *hw, bool adv1G, 
bool adv100M);
 s32 e1000_set_eee_i354(struct e1000_hw *hw, bool adv1G, bool adv100M);
 s32 e1000_get_eee_status_i354(struct e1000_hw *, bool *);

[dpdk-dev] [PATCH v2 30/35] e1000/base: use the correct i210 register for EEMNGCTL

[Wenzhuo Lu]

The i210 has two EEPROM access registers that are located in
non-standard offsets: EEARBC and EEMNGCTL. EEARBC was fixed previously
and EEMNGCTL should also be corrected.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/base/e1000_i210.c | 30 ++
 drivers/net/e1000/base/e1000_regs.h |  1 +
 2 files changed, 31 insertions(+)

diff --git a/drivers/net/e1000/base/e1000_i210.c 
b/drivers/net/e1000/base/e1000_i210.c
index fedf88e..277331c 100644
--- a/drivers/net/e1000/base/e1000_i210.c
+++ b/drivers/net/e1000/base/e1000_i210.c
@@ -982,6 +982,35 @@ STATIC s32 e1000_pll_workaround_i210(struct e1000_hw *hw)
 }

 /**
+ *  e1000_get_cfg_done_i210 - Read config done bit
+ *  @hw: pointer to the HW structure
+ *
+ *  Read the management control register for the config done bit for
+ *  completion status.  NOTE: silicon which is EEPROM-less will fail trying
+ *  to read the config done bit, so an error is *ONLY* logged and returns
+ *  E1000_SUCCESS.  If we were to return with error, EEPROM-less silicon
+ *  would not be able to be reset or change link.
+ **/
+STATIC s32 e1000_get_cfg_done_i210(struct e1000_hw *hw)
+{
+   s32 timeout = PHY_CFG_TIMEOUT;
+   u32 mask = E1000_NVM_CFG_DONE_PORT_0;
+
+   DEBUGFUNC("e1000_get_cfg_done_i210");
+
+   while (timeout) {
+   if (E1000_READ_REG(hw, E1000_EEMNGCTL_I210) & mask)
+   break;
+   msec_delay(1);
+   timeout--;
+   }
+   if (!timeout)
+   DEBUGOUT("MNG configuration cycle has not completed.\n");
+
+   return E1000_SUCCESS;
+}
+
+/**
  *  e1000_init_hw_i210 - Init hw for I210/I211
  *  @hw: pointer to the HW structure
  *
@@ -998,6 +1027,7 @@ s32 e1000_init_hw_i210(struct e1000_hw *hw)
if (ret_val != E1000_SUCCESS)
return ret_val;
}
+   hw->phy.ops.get_cfg_done = e1000_get_cfg_done_i210;
ret_val = e1000_init_hw_82575(hw);
return ret_val;
 }
diff --git a/drivers/net/e1000/base/e1000_regs.h 
b/drivers/net/e1000/base/e1000_regs.h
index e23e1e8..84531a9 100644
--- a/drivers/net/e1000/base/e1000_regs.h
+++ b/drivers/net/e1000/base/e1000_regs.h
@@ -110,6 +110,7 @@ POSSIBILITY OF SUCH DAMAGE.
 #define E1000_PBS  0x01008  /* Packet Buffer Size */
 #define E1000_PBECCSTS 0x0100C  /* Packet Buffer ECC Status - RW */
 #define E1000_EEMNGCTL 0x01010  /* MNG EEprom Control */
+#define E1000_EEMNGCTL_I2100x01010  /* i210 MNG EEprom Mode Control */
 #define E1000_EEARBC   0x01024  /* EEPROM Auto Read Bus Control */
 #define E1000_EEARBC_I210  0x12024 /* EEPROM Auto Read Bus Control */
 #define E1000_FLASHT   0x01028  /* FLASH Timer Register */
-- 
1.9.3

[dpdk-dev] [PATCH v2 31/35] e1000/base: move the print to the right position

[Wenzhuo Lu]

This info need not to be always printed. Move it into the if.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/base/e1000_phy.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/e1000/base/e1000_phy.c 
b/drivers/net/e1000/base/e1000_phy.c
index 6bbb379..d43b7ce 100644
--- a/drivers/net/e1000/base/e1000_phy.c
+++ b/drivers/net/e1000/base/e1000_phy.c
@@ -1833,9 +1833,9 @@ s32 e1000_phy_force_speed_duplex_m88(struct e1000_hw *hw)
 phy_data);
if (ret_val)
return ret_val;
-   }

-   DEBUGOUT1("M88E1000 PSCR: %X\n", phy_data);
+   DEBUGOUT1("M88E1000 PSCR: %X\n", phy_data);
+   }

ret_val = phy->ops.read_reg(hw, PHY_CONTROL, &phy_data);
if (ret_val)
-- 
1.9.3

[dpdk-dev] [PATCH v2 32/35] e1000/base: synchronization of MAC-PHY interface only on non- ME systems

[Wenzhuo Lu]

On power up, the MAC - PHY interface needs to be set to PCIe, even if
cable is disconnected.  In ME systems, the ME handles this on exit from
Sx(Sticky mode) state. In non-ME, the driver handles it. Added a check
for non-ME system to the driver code that handles that.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/base/e1000_ich8lan.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/net/e1000/base/e1000_ich8lan.c 
b/drivers/net/e1000/base/e1000_ich8lan.c
index 70eba71..6dc053f 100644
--- a/drivers/net/e1000/base/e1000_ich8lan.c
+++ b/drivers/net/e1000/base/e1000_ich8lan.c
@@ -234,15 +234,19 @@ STATIC bool e1000_phy_is_accessible_pchlan(struct 
e1000_hw *hw)
return false;
 out:
if (hw->mac.type == e1000_pch_lpt) {
-   /* Unforce SMBus mode in PHY */
-   hw->phy.ops.read_reg_locked(hw, CV_SMB_CTRL, &phy_reg);
-   phy_reg &= ~CV_SMB_CTRL_FORCE_SMBUS;
-   hw->phy.ops.write_reg_locked(hw, CV_SMB_CTRL, phy_reg);
+   /* Only unforce SMBus if ME is not active */
+   if (!(E1000_READ_REG(hw, E1000_FWSM) &
+   E1000_ICH_FWSM_FW_VALID)) {
+   /* Unforce SMBus mode in PHY */
+   hw->phy.ops.read_reg_locked(hw, CV_SMB_CTRL, &phy_reg);
+   phy_reg &= ~CV_SMB_CTRL_FORCE_SMBUS;
+   hw->phy.ops.write_reg_locked(hw, CV_SMB_CTRL, phy_reg);

-   /* Unforce SMBus mode in MAC */
-   mac_reg = E1000_READ_REG(hw, E1000_CTRL_EXT);
-   mac_reg &= ~E1000_CTRL_EXT_FORCE_SMBUS;
-   E1000_WRITE_REG(hw, E1000_CTRL_EXT, mac_reg);
+   /* Unforce SMBus mode in MAC */
+   mac_reg = E1000_READ_REG(hw, E1000_CTRL_EXT);
+   mac_reg &= ~E1000_CTRL_EXT_FORCE_SMBUS;
+   E1000_WRITE_REG(hw, E1000_CTRL_EXT, mac_reg);
+   }
}

return true;
-- 
1.9.3

[dpdk-dev] [PATCH v2 33/35] e1000/base: fix to enable both ulp and EEE in Sx state

[Wenzhuo Lu]

This patch implements a modified flow that allows both ULP and EEE
in Sx(Sticky mode).

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/base/e1000_ich8lan.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/e1000/base/e1000_ich8lan.c 
b/drivers/net/e1000/base/e1000_ich8lan.c
index 6dc053f..f62ad0b 100644
--- a/drivers/net/e1000/base/e1000_ich8lan.c
+++ b/drivers/net/e1000/base/e1000_ich8lan.c
@@ -1154,10 +1154,15 @@ skip_smbus:
if (to_sx) {
if (E1000_READ_REG(hw, E1000_WUFC) & E1000_WUFC_LNKC)
phy_reg |= I218_ULP_CONFIG1_WOL_HOST;
+   else
+   phy_reg &= ~I218_ULP_CONFIG1_WOL_HOST;

phy_reg |= I218_ULP_CONFIG1_STICKY_ULP;
+   phy_reg &= ~I218_ULP_CONFIG1_INBAND_EXIT;
} else {
phy_reg |= I218_ULP_CONFIG1_INBAND_EXIT;
+   phy_reg &= ~I218_ULP_CONFIG1_STICKY_ULP;
+   phy_reg &= ~I218_ULP_CONFIG1_WOL_HOST;
}
e1000_write_phy_reg_hv_locked(hw, I218_ULP_CONFIG1, phy_reg);

@@ -1178,6 +1183,7 @@ skip_smbus:
mac_reg &= ~E1000_TCTL_EN;
E1000_WRITE_REG(hw, E1000_TCTL, mac_reg);
}
+
 release:
hw->phy.ops.release(hw);
 out:
-- 
1.9.3

[dpdk-dev] [PATCH v2 34/35] e1000/base: some minor change

[Wenzhuo Lu]

Some minor code change. No functionality impact.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/base/e1000_ich8lan.c | 27 ---
 drivers/net/e1000/base/e1000_ich8lan.h |  1 +
 2 files changed, 13 insertions(+), 15 deletions(-)

diff --git a/drivers/net/e1000/base/e1000_ich8lan.c 
b/drivers/net/e1000/base/e1000_ich8lan.c
index f62ad0b..89d07e9 100644
--- a/drivers/net/e1000/base/e1000_ich8lan.c
+++ b/drivers/net/e1000/base/e1000_ich8lan.c
@@ -1442,7 +1442,6 @@ STATIC s32 e1000_check_for_copper_link_ich8lan(struct 
e1000_hw *hw)
ret_val = e1000_disable_ulp_lpt_lp(hw, false);
else
ret_val = e1000_enable_ulp_lpt_lp(hw, false);
-
if (ret_val)
return ret_val;
}
@@ -2979,7 +2978,6 @@ STATIC s32 e1000_set_lplu_state_pchlan(struct e1000_hw 
*hw, bool active)
u16 oem_reg;

DEBUGFUNC("e1000_set_lplu_state_pchlan");
-
ret_val = hw->phy.ops.read_reg(hw, HV_OEM_BITS, &oem_reg);
if (ret_val)
return ret_val;
@@ -3199,6 +3197,7 @@ STATIC s32 e1000_valid_nvm_bank_detect_ich8lan(struct 
e1000_hw *hw, u32 *bank)
struct e1000_nvm_info *nvm = &hw->nvm;
u32 bank1_offset = nvm->flash_bank_size * sizeof(u16);
u32 act_offset = E1000_ICH_NVM_SIG_WORD * 2 + 1;
+   u32 nvm_dword = 0;
u8 sig_byte = 0;
s32 ret_val;

@@ -3506,12 +3505,10 @@ STATIC s32 e1000_read_flash_data_ich8lan(struct 
e1000_hw *hw, u32 offset,
hsflctl.hsf_ctrl.fldbcount = size - 1;
hsflctl.hsf_ctrl.flcycle = ICH_CYCLE_READ;
E1000_WRITE_FLASH_REG16(hw, ICH_FLASH_HSFCTL, hsflctl.regval);
-
E1000_WRITE_FLASH_REG(hw, ICH_FLASH_FADDR, flash_linear_addr);

-   ret_val =
-   e1000_flash_cycle_ich8lan(hw,
- ICH_FLASH_READ_COMMAND_TIMEOUT);
+   ret_val = e1000_flash_cycle_ich8lan(hw,
+   ICH_FLASH_READ_COMMAND_TIMEOUT);

/* Check if FCERR is set to 1, if set to 1, clear it
 * and try the whole sequence a few more times, else
@@ -3546,6 +3543,7 @@ STATIC s32 e1000_read_flash_data_ich8lan(struct e1000_hw 
*hw, u32 offset,
return ret_val;
 }

+
 /**
  *  e1000_write_nvm_ich8lan - Write word(s) to the NVM
  *  @hw: pointer to the HW structure
@@ -3599,7 +3597,7 @@ STATIC s32 e1000_update_nvm_checksum_ich8lan(struct 
e1000_hw *hw)
struct e1000_dev_spec_ich8lan *dev_spec = &hw->dev_spec.ich8lan;
u32 i, act_offset, new_bank_offset, old_bank_offset, bank;
s32 ret_val;
-   u16 data;
+   u16 data = 0;

DEBUGFUNC("e1000_update_nvm_checksum_ich8lan");

@@ -3635,12 +3633,7 @@ STATIC s32 e1000_update_nvm_checksum_ich8lan(struct 
e1000_hw *hw)
if (ret_val)
goto release;
}
-
for (i = 0; i < E1000_SHADOW_RAM_WORDS; i++) {
-   /* Determine whether to write the value stored
-* in the other NVM bank or a modified value stored
-* in the shadow RAM
-*/
if (dev_spec->shadow_ram[i].modified) {
data = dev_spec->shadow_ram[i].value;
} else {
@@ -3650,7 +3643,6 @@ STATIC s32 e1000_update_nvm_checksum_ich8lan(struct 
e1000_hw *hw)
if (ret_val)
break;
}
-
/* If the word is 0x13, then make sure the signature bits
 * (15:14) are 11b until the commit has completed.
 * This will allow us to write 10b which indicates the
@@ -3665,6 +3657,7 @@ STATIC s32 e1000_update_nvm_checksum_ich8lan(struct 
e1000_hw *hw)
act_offset = (i + new_bank_offset) << 1;

usec_delay(100);
+
/* Write the bytes to the new bank. */
ret_val = e1000_retry_write_flash_byte_ich8lan(hw,
   act_offset,
@@ -3699,8 +3692,7 @@ STATIC s32 e1000_update_nvm_checksum_ich8lan(struct 
e1000_hw *hw)
goto release;

data &= 0xBFFF;
-   ret_val = e1000_retry_write_flash_byte_ich8lan(hw,
-  act_offset * 2 + 1,
+   ret_val = e1000_retry_write_flash_byte_ich8lan(hw, act_offset * 2 + 1,
   (u8)(data >> 8));
if (ret_val)
goto release;
@@ -3711,7 +3703,9 @@ STATIC s32 e1000_update_nvm_checksum_ich8lan(struct 
e1000_hw *hw)
 * to 1's. We can write 1's to 0's without an erase
 */
act_offset = (old_bank_offset + E1000_ICH_NVM_SIG_WORD) * 2 + 1;
+
ret_val = e1000_retry_write_flash_byte_ich8lan(hw, act_offset, 0);
+
if (ret_val)
goto release;

@@ -3865

[dpdk-dev] [PATCH v2 35/35] e1000: add new devices

[Wenzhuo Lu]

Add the new e1000 devices to the DPDK PCI device list.

Signed-off-by: Wenzhuo Lu 
---
 lib/librte_eal/common/include/rte_pci_dev_ids.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h 
b/lib/librte_eal/common/include/rte_pci_dev_ids.h
index 265e66c..19892e1 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -272,6 +272,11 @@
 #define E1000_DEV_ID_PCH_LPT_I217_V   0x153B
 #define E1000_DEV_ID_PCH_LPTLP_I218_LM   0x155A
 #define E1000_DEV_ID_PCH_LPTLP_I218_V0x1559
+#define E1000_DEV_ID_PCH_I218_LM2 0x15A0
+#define E1000_DEV_ID_PCH_I218_V2  0x15A1
+#define E1000_DEV_ID_PCH_I218_LM3 0x15A2
+#define E1000_DEV_ID_PCH_I218_V3  0x15A3
+

 /*
  * Tested (supported) on VM emulated HW.
-- 
1.9.3

[dpdk-dev] [Q] l2fwd in examples directory

[Moon-Sang Lee]

There is codes as below in examples/l2fwd/main.c and I think
rte_eth_dev_socket_id(portid)
always returns -1(SOCKET_ID_ANY) since there is no association code between
port and
lcore in the example codes. (i.e. I need to find a matching lcore from
lcore_queue_conf[] with portid
and call rte_lcore_to_socket_id(lcore_id).)

/* init one RX queue */
fflush(stdout);
ret = rte_eth_rx_queue_setup(portid, 0, nb_rxd,
 rte_eth_dev_socket_id(portid),
 NULL,
 l2fwd_pktmbuf_pool);
if (ret < 0)
rte_exit(EXIT_FAILURE, "rte_eth_rx_queue_setup:err=%d,
port=%u\n",
  ret, (unsigned) portid);

It works fine even though memory is allocated in different NUMA node. But I
wonder there is
a DPDK API that associates inlcore to port internally,
thus rte_eth_devices[portid].pci_dev->numa_node contains proper node.


-- 
Moon-Sang Lee, SW Engineer
Email: sang0627 at gmail.com
Wisdom begins in wonder. *Socrates*

[dpdk-dev] [Q] l2fwd in examples directory

[Moon-Sang Lee]

There is codes as below in examples/l2fwd/main.c and I think
rte_eth_dev_socket_id(portid)
always returns -1(SOCKET_ID_ANY) since there is no association code between
port and
lcore in the example codes. (i.e. I need to find a matching lcore from
lcore_queue_conf[] with portid
and call rte_lcore_to_socket_id(lcore_id).)

/* init one RX queue */
fflush(stdout);
ret = rte_eth_rx_queue_setup(portid, 0, nb_rxd,
 rte_eth_dev_socket_id(portid),
 NULL,
 l2fwd_pktmbuf_pool);
if (ret < 0)
rte_exit(EXIT_FAILURE, "rte_eth_rx_queue_setup:err=%d,
port=%u\n",
  ret, (unsigned) portid);

It works fine even though memory is allocated in different NUMA node. But I
wonder there is
a DPDK API that associates inlcore to port internally thus
rte_eth_devices[portid].pci_dev->numa_node
contains proper node.


-- 
Moon-Sang Lee, SW Engineer
Email: sang0627 at gmail.com
Wisdom begins in wonder. *Socrates*

[dpdk-dev] [PATCH] fm10k: add Intel Boulder Rapid NIC support

[Chen, Jing D]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Michael Qiu
> Sent: Friday, September 25, 2015 10:31 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] fm10k: add Intel Boulder Rapid NIC support
> 
> Boulder Rapid is Intel new NIC within fm10k family.
> This patch make DPDK driver support this new NIC.
> 
> Signed-off-by: Michael Qiu 


Acked-by : Jing Chen 

[dpdk-dev] [PATCH 1/3] fm10k: add multi-queue checking

[Qiu, Michael]

On 2015/9/30 15:29, Shaopeng He wrote:
> Add multi-queue checking in device configure process.
> Currently, VMDQ and RSS are supported.
>
> Signed-off-by: Shaopeng He 
> ---
>  drivers/net/fm10k/fm10k_ethdev.c | 44 
> 
>  1 file changed, 44 insertions(+)
>
> diff --git a/drivers/net/fm10k/fm10k_ethdev.c 
> b/drivers/net/fm10k/fm10k_ethdev.c
> index a69c990..082937d 100644
> --- a/drivers/net/fm10k/fm10k_ethdev.c
> +++ b/drivers/net/fm10k/fm10k_ethdev.c
> @@ -283,12 +283,56 @@ tx_queue_disable(struct fm10k_hw *hw, uint16_t qnum)
>  }
>  
>  static int
> +fm10k_check_mq_mode(struct rte_eth_dev *dev)
> +{
> + enum rte_eth_rx_mq_mode rx_mq_mode = dev->data->dev_conf.rxmode.mq_mode;
> + struct fm10k_hw *hw = FM10K_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> + struct rte_eth_vmdq_rx_conf *vmdq_conf;
> + uint16_t nb_rx_q = dev->data->nb_rx_queues;
> +
> + vmdq_conf = &dev->data->dev_conf.rx_adv_conf.vmdq_rx_conf;
> +
> + if (rx_mq_mode & ETH_MQ_RX_DCB_FLAG) {
> + PMD_INIT_LOG(ERR, "DCB mode is not supported.");
> + return -EINVAL;
> + }
> +
> + if (!(rx_mq_mode & ETH_MQ_RX_VMDQ_FLAG))
> + return 0;
> +
> + if (hw->mac.type == fm10k_mac_vf) {
> + PMD_INIT_LOG(ERR, "VMDQ mode is not supported in VF.");
> + return -EINVAL;
> + }

I think vf check should be the first one, then we do not need check dcb
and VMDq flag.

Thanks,
Michael
> +
> + /* Check VMDQ queue pool number */
> + if (vmdq_conf->nb_queue_pools >
> + sizeof(vmdq_conf->pool_map[0].pools) * CHAR_BIT ||
> + vmdq_conf->nb_queue_pools > nb_rx_q) {
> + PMD_INIT_LOG(ERR, "Too many of queue pools: %d",
> + vmdq_conf->nb_queue_pools);
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static int
>  fm10k_dev_configure(struct rte_eth_dev *dev)
>  {
> + int ret;
> +
>   PMD_INIT_FUNC_TRACE();
>  
>   if (dev->data->dev_conf.rxmode.hw_strip_crc == 0)
>   PMD_INIT_LOG(WARNING, "fm10k always strip CRC");
> + /* multipe queue mode checking */
> + ret  = fm10k_check_mq_mode(dev);
> + if (ret != 0) {
> + PMD_DRV_LOG(ERR, "fm10k_check_mq_mode fails with %d.",
> + ret);
> + return ret;
> + }
>  
>   return 0;
>  }

[dpdk-dev] [PATCH v4] mbuf/ip_frag: move mbuf chaining to common code

[Simon Kagstrom]

Chaining/segmenting mbufs can be useful in many places, so make it
global.

Signed-off-by: Simon Kagstrom 
Signed-off-by: Johan Faltstrom 
---
ChangeLog:
v4:
  * Line up doxygen comments better (Olivier Matz)
  * Correct patch name (Thomas Monajlon)

v3:
  * Describe performance implications of linear search
  * Correct check-for-out-of-bounds (Konstantin Ananyev)

v2:
  * Check for nb_segs byte overflow (Olivier MATZ)
  * Don't reset nb_segs in tail (Olivier MATZ)

 lib/librte_ip_frag/ip_frag_common.h  | 23 ---
 lib/librte_ip_frag/rte_ipv4_reassembly.c |  7 --
 lib/librte_ip_frag/rte_ipv6_reassembly.c |  7 --
 lib/librte_mbuf/rte_mbuf.h   | 38 
 4 files changed, 48 insertions(+), 27 deletions(-)

diff --git a/lib/librte_ip_frag/ip_frag_common.h 
b/lib/librte_ip_frag/ip_frag_common.h
index 6b2acee..cde6ed4 100644
--- a/lib/librte_ip_frag/ip_frag_common.h
+++ b/lib/librte_ip_frag/ip_frag_common.h
@@ -166,27 +166,4 @@ ip_frag_reset(struct ip_frag_pkt *fp, uint64_t tms)
fp->frags[IP_FIRST_FRAG_IDX] = zero_frag;
 }

-/* chain two mbufs */
-static inline void
-ip_frag_chain(struct rte_mbuf *mn, struct rte_mbuf *mp)
-{
-   struct rte_mbuf *ms;
-
-   /* adjust start of the last fragment data. */
-   rte_pktmbuf_adj(mp, (uint16_t)(mp->l2_len + mp->l3_len));
-
-   /* chain two fragments. */
-   ms = rte_pktmbuf_lastseg(mn);
-   ms->next = mp;
-
-   /* accumulate number of segments and total length. */
-   mn->nb_segs = (uint8_t)(mn->nb_segs + mp->nb_segs);
-   mn->pkt_len += mp->pkt_len;
-
-   /* reset pkt_len and nb_segs for chained fragment. */
-   mp->pkt_len = mp->data_len;
-   mp->nb_segs = 1;
-}
-
-
 #endif /* _IP_FRAG_COMMON_H_ */
diff --git a/lib/librte_ip_frag/rte_ipv4_reassembly.c 
b/lib/librte_ip_frag/rte_ipv4_reassembly.c
index 5d24843..26d07f9 100644
--- a/lib/librte_ip_frag/rte_ipv4_reassembly.c
+++ b/lib/librte_ip_frag/rte_ipv4_reassembly.c
@@ -63,7 +63,9 @@ ipv4_frag_reassemble(const struct ip_frag_pkt *fp)
/* previous fragment found. */
if(fp->frags[i].ofs + fp->frags[i].len == ofs) {

-   ip_frag_chain(fp->frags[i].mb, m);
+   /* adjust start of the last fragment data. */
+   rte_pktmbuf_adj(m, (uint16_t)(m->l2_len + 
m->l3_len));
+   rte_pktmbuf_chain(fp->frags[i].mb, m);

/* update our last fragment and offset. */
m = fp->frags[i].mb;
@@ -78,7 +80,8 @@ ipv4_frag_reassemble(const struct ip_frag_pkt *fp)
}

/* chain with the first fragment. */
-   ip_frag_chain(fp->frags[IP_FIRST_FRAG_IDX].mb, m);
+   rte_pktmbuf_adj(m, (uint16_t)(m->l2_len + m->l3_len));
+   rte_pktmbuf_chain(fp->frags[IP_FIRST_FRAG_IDX].mb, m);
m = fp->frags[IP_FIRST_FRAG_IDX].mb;

/* update mbuf fields for reassembled packet. */
diff --git a/lib/librte_ip_frag/rte_ipv6_reassembly.c 
b/lib/librte_ip_frag/rte_ipv6_reassembly.c
index 1f1c172..5969b4a 100644
--- a/lib/librte_ip_frag/rte_ipv6_reassembly.c
+++ b/lib/librte_ip_frag/rte_ipv6_reassembly.c
@@ -86,7 +86,9 @@ ipv6_frag_reassemble(const struct ip_frag_pkt *fp)
/* previous fragment found. */
if (fp->frags[i].ofs + fp->frags[i].len == ofs) {

-   ip_frag_chain(fp->frags[i].mb, m);
+   /* adjust start of the last fragment data. */
+   rte_pktmbuf_adj(m, (uint16_t)(m->l2_len + 
m->l3_len));
+   rte_pktmbuf_chain(fp->frags[i].mb, m);

/* update our last fragment and offset. */
m = fp->frags[i].mb;
@@ -101,7 +103,8 @@ ipv6_frag_reassemble(const struct ip_frag_pkt *fp)
}

/* chain with the first fragment. */
-   ip_frag_chain(fp->frags[IP_FIRST_FRAG_IDX].mb, m);
+   rte_pktmbuf_adj(m, (uint16_t)(m->l2_len + m->l3_len));
+   rte_pktmbuf_chain(fp->frags[IP_FIRST_FRAG_IDX].mb, m);
m = fp->frags[IP_FIRST_FRAG_IDX].mb;

/* update mbuf fields for reassembled packet. */
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index d7c9030..4a93189 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -1775,6 +1775,44 @@ static inline int rte_pktmbuf_is_contiguous(const struct 
rte_mbuf *m)
 }

 /**
+ * Chain an mbuf to another, thereby creating a segmented packet.
+ *
+ * Note: The implementation will do a linear walk over the segments to find
+ * the tail entry. For cases when there are many segments, it's better to
+ * chain the entries manually.
+ *
+ * @param head
+ *   The head of the mbuf chain (the first packet)
+ * @param tail
+ *   The mbuf to put last in the chain
+ *
+ * @return
+ *   - 0, o

[dpdk-dev] [PATCH v5 4/9] null: virtual dynamic rss configuration

[Tetsuya Mukawa]

On 2015/09/30 23:05, Tomasz Kulasek wrote:
> This implementation allows to set and read RSS configuration for null
> device, and is used to validate right values propagation over the slaves,
> in test units for dynamic RSS configuration for bonding.
>
> v5 changes:
>  - replaced memcpy with rte_memcpy
>
> Signed-off-by: Tomasz Kulasek 
> ---
>  drivers/net/null/rte_eth_null.c |  116 
> +++
>  1 file changed, 116 insertions(+)
>
> diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c
> index bf81b1b..b01f647 100644
> --- a/drivers/net/null/rte_eth_null.c
> +++ b/drivers/net/null/rte_eth_null.c
> @@ -37,6 +37,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>


Hi Tomasz,

We don't have "rte_eth_null.h" at this point.
(The header file will be added next patch)
Probably, we also need "rte_pmd_null_version.map" to compile correctly.
(To make sure, please compile DPDK with "CONFIG_RTE_BUILD_SHARED_LIB=y"
option.)

Also, it seems 'rte_eth_null.h' should be included like below.
#include "rte_eth_null.h"
Without it, we cannot compile.

Thanks,
Tetsuya

[dpdk-dev] [PATCH] examples/vmdq: Fix the core dump issue when mem_pool is more than 34

[Sun, Xutao]

> -Original Message-
> From: De Lara Guarch, Pablo
> Sent: Tuesday, October 13, 2015 3:59 PM
> To: Sun, Xutao; dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH] examples/vmdq: Fix the core dump issue
> when mem_pool is more than 34
> 
> Hi Xutao,
> 
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Xutao Sun
> > Sent: Tuesday, October 13, 2015 8:29 AM
> > To: dev at dpdk.org
> > Subject: [dpdk-dev] [PATCH] examples/vmdq: Fix the core dump issue
> > when mem_pool is more than 34
> >
> > Macro MAX_QUEUES was defined to 128, only allow 16 mem_pools in
> > theory.
> > When running vmdq_app with more than 34 mem_pools, it will cause the
> > core_dump issue.
> > Change MAX_QUEUES to 1024 will solve this issue.
> >
> > Signed-off-by: Xutao Sun 
> > ---
> >  examples/vmdq/main.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/examples/vmdq/main.c b/examples/vmdq/main.c index
> > a142d49..b463cfb 100644
> > --- a/examples/vmdq/main.c
> > +++ b/examples/vmdq/main.c
> > @@ -69,7 +69,7 @@
> >  #include 
> >  #include 
> >
> > -#define MAX_QUEUES 128
> > +#define MAX_QUEUES 1024
> >  /*
> >   * For 10 GbE, 128 queues require roughly
> >   * 128*512 (RX/TX_queue_nb * RX/TX_ring_descriptors_nb) per port.
> > --
> > 1.9.3
> 
> Just for clarification, when you say mem_pools, do you mean vmdq pools?
> Also, if you are going to increase MAX_QUEUES, shouldn't you increase the
> NUM_MBUFS_PER_PORT?
> Looking at the comment below, looks like there is a calculation of number of
> mbufs based on number of queues.
> Plus, I assume 128 is the maximum number of queues per port, and as far as I
> know, only Fortville supports 256 as maximum.
> 
> Thanks,
> Pablo


Hi Pablo,

I mean vmdq pools when I say mem_pools.
And as you say, NUM_MBUFS_PER_PORT should be increased actually. 
I may use macro to replace the old expression. 
#define NUM_MBUFS_PER_PORT (MAX_QUEUES * 
max(RTE_TEST_RX_DESC_DEFAULT,RTE_TEST_TX_DESC_DEFAULT))
And this patch is to fix the issue about running VMDQ on  Fortville, so the 
maximum number of queues is larger than 128.
Thank you very much for your advice!

Thanks,
Xutao

[dpdk-dev] I have a problem in setting up DPDK 2.1.0 in Fedora OS release 20 (Heisenbug). I cannot r

[De Lara Guarch, Pablo]

Hi,

From: ??? [mailto:pnk...@naver.com]
Sent: Thursday, October 15, 2015 2:02 AM
To: De Lara Guarch, Pablo; dev at dpdk.org
Subject: RE: [dpdk-dev] I have a problem in setting up DPDK 2.1.0 in Fedora OS 
release 20 (Heisenbug). I cannot r


Dear De Lara Guarch, Pablo.



I checked what you mentioned.



* Fedora Linux kernel version is as follows.



 $ uname -r (print kernel name)

 3.17.7-200.fc20.x86_64



 $ uname -a

 Linux sdnlab-k01 3.17.7-200.fc20.x86_64 #1 SMP Wed Dec 17 03:35:33 UTC 
2014 x86_64 x86_64 x86_64 GNU/Linux



 $ cat /proc/version

 Linux version 3.17.7-200.fc20.x86_64 (mockbuild at 
bkernel01.phx2.fedoraproject.org) (gcc version 4.8.3 20140911 (Red Hat 
4.8.3-7) (GCC) ) #1 SMP Wed Dec 17 03:35:33 UTC 2014



 $ rpm -q kernel

 kernel-3.11.10-301.fc20.x86_64

 kernel-3.17.7-200.fc20.x86_64

 kernel-3.15.6-200.fc20.x86_64



 $ cat /etc/redhat-release

 Fedora release 20 (Heisenbug)





* Vt-d seems to be enabled. I heard that the result values of 3 or 5 mean the 
virtualization activated.



 $ sudo rdmsr 0x3A

 5



If VT-d is enabled, and you are running on the host, you need to use 
?intel_iommu=on iommu=pt? in the kernel parameters.

Anyway, there is a known issue with kernels between 3.15 and 3.17, with VT-d: 
take a look at the bug 6.25 here:

http://dpdk.readthedocs.org/en/v2.1.0/rel_notes/known_issues.html



I suggest you  to disable VT-d and see if you problem goes away, and if so,



update your kernel and include the line above if you need VT-d enabled for any 
reason.



And I have strange error during the yum update.





$ sudo yum update



--> Finished Dependency Resolution

--> Running transaction check

---> Package aspell-en.x86_64 50:7.1-6.fc20 will be installed

---> Package kernel-devel.x86_64 0:3.11.10-301.fc20 will be erased

---> Package kernel-modules-extra.x86_64 0:3.11.10-301.fc20 will be erased

---> Package kernel-modules-extra.x86_64 0:3.19.8-100.fc20 will be installed

--> Processing Dependency: kernel-uname-r = 3.19.8-100.fc20.x86_64 for package: 
kernel-modules-extra-3.19.8-100.fc20.x86_64

--> Finished Dependency Resolution

Error: Package: kernel-modules-extra-3.19.8-100.fc20.x86_64 (updates)

   Requires: kernel-uname-r = 3.19.8-100.fc20.x86_64

   Installed: kernel-3.11.10-301.fc20.x86_64 (@anaconda)

   kernel-uname-r = 3.11.10-301.fc20.x86_64

   Installed: kernel-3.15.6-200.fc20.x86_64 (installed)

   kernel-uname-r = 3.15.6-200.fc20.x86_64

   Installed: kernel-3.17.7-200.fc20.x86_64 (@updates)

   kernel-uname-r = 3.17.7-200.fc20.x86_64

   Available: kernel-debug-3.11.10-301.fc20.x86_64 (fedora)

   kernel-uname-r = 3.11.10-301.fc20.x86_64+debug

   Available: kernel-debug-3.19.8-100.fc20.x86_64 (updates)

   kernel-uname-r = 3.19.8-100.fc20.x86_64+debug

 You could try using --skip-broken to work around the problem

 You could try running: rpm -Va --nofiles --nodigest





* There are virtual bridge and virtual nic in the Fedora server.



$ ifconfig  or $ ifconfig -a



virbr0: flags=4099  mtu 1500

inet ?.?.?.?  netmask 255.255.255.0  broadcast ?.?.?.?

ether 52:54:00:f2:70:98  txqueuelen 0  (Ethernet)

RX packets 0  bytes 0 (0.0 B)

RX errors 0  dropped 0  overruns 0  frame 0

TX packets 0  bytes 0 (0.0 B)

TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0



virbr0-nic: flags=4098  mtu 1500

ether 52:54:00:f2:70:98  txqueuelen 500  (Ethernet)

RX packets 0  bytes 0 (0.0 B)

RX errors 0  dropped 0  overruns 0  frame 0

TX packets 0  bytes 0 (0.0 B)

TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0





Thank you very much.



Sincerely Yours,



Ick-Sung Choi.







-Original Message-
From: "De Lara Guarch, Pablo"mailto:pablo.de.lara.gua...@intel.com>>
To: "???"mailto:pnk003 at naver.com>>; "dev at 
dpdk.org"mailto:dev at dpdk.org>>;
Cc:
Sent: 2015-10-14 (?) 22:19:02
Subject: RE: [dpdk-dev] I have a problem in setting up DPDK 2.1.0 in Fedora OS 
release 20 (Heisenbug). I cannot r

Hi Ick-Sung,

> * Fedora OS version : Fedora release 20 (Heisenbug)
>
> * gcc version : gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7).
>
> * Intel(R) Xeon(R) CPU E5-2680 10 cores, 64G bytes system memory.
> * 2 2-port NIC cards, Intel? 82599ES 10 Gigabit Ethernet 2 port Controller.
> SFI/SFP+. optical link. Hence there are 4 10 GbE ports.
>
> * I attached DPDK setup script in my environment.

What is your kernel version? And also, can you check if you have VT-d enabled?

Thanks,
Pablo
>
>
> Thank you very much.
>
> Sincerely Yours,
>
> Ick-Sung Choi.
[http://mail.naver.com/readReceipt/notify/?img=b9nqKAIOWNgqpoFvaxmsa6MwMrtrpAvwFrE9pxbdMquZMobqpovmpz3gMX%2B0MoUd74lR74lcWNFlbX30WLloWrdQaXICM4wT743074wCb4u5pXkC

[dpdk-dev] I have a problem in setting up DPDK 2.1.0 in Fedora OS release 20 (Heisenbug). I cannot r

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of ???
> Sent: Thursday, October 15, 2015 2:02 AM
> To: De Lara Guarch, Pablo; dev at dpdk.org
> Subject: Re: [dpdk-dev] I have a problem in setting up DPDK 2.1.0 in
> Fedora OS release 20 (Heisenbug). I cannot r
>
> I checked what you mentioned.
> 
> * Fedora Linux kernel version is as follows.
> 
>  $ uname -r (print kernel name)
>  3.17.7-200.fc20.x86_64

Hi,

This may be a known issue. See:


http://dpdk.org/doc/guides/rel_notes/known_issues.html#devices-bound-to-igb-uio-with-vt-d-enabled-do-not-work-on-linux-kernel-3-15-3-17


"Devices bound to igb_uio with VT-d enabled do not work on Linux kernel 
3.15-3.17

Description:
When VT-d is enabled (iommu=pt intel_iommu=on), devices are 1:1 mapped. In 
the Linux kernel unbinding devices from drivers removes that mapping which 
result in IOMMU errors. Introduced in Linux kernel 3.15 commit, solved in Linux 
kernel 3.18 commit."

John

[dpdk-dev] [PATCH v5 5/9] null: export eth_dev_null_create

[Tetsuya Mukawa]

On 2015/10/14 21:42, Jastrzebski, MichalX K wrote:
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Tetsuya Mukawa
>> Sent: Wednesday, October 14, 2015 3:35 AM
>> To: Kulasek, TomaszX; dev at dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH v5 5/9] null: export eth_dev_null_create
>>
>> On 2015/09/30 23:05, Tomasz Kulasek wrote:
>>> Signed-off-by: Tomasz Kulasek 
>>> ---
>>>  drivers/net/null/Makefile |2 +-
>>>  drivers/net/null/rte_eth_null.c   |2 +-
>>>  drivers/net/null/rte_eth_null.h   |   40
>> +
>>>  drivers/net/null/rte_pmd_null_version.map |7 +
>>>  4 files changed, 49 insertions(+), 2 deletions(-)
>>>  create mode 100644 drivers/net/null/rte_eth_null.h
>> Acked-by: Tetsuya Mukawa 
> Hi Tetsuya,
> Thank You for a review and acking patches. 
> There are 5 remaining patches in a patch-set: 
>
> [dpdk-dev] [PATCH v5 1/9] bonding: rss dynamic configuration
> [dpdk-dev] [PATCH v5 6/9] test: dynamic rss configuration
> [dpdk-dev] [PATCH v5 7/9] bonding: per queue stats
> [dpdk-dev] [PATCH v5 8/9] doc: fixed spellings and typos
> [dpdk-dev] [PATCH v5 9/9] doc: dynamic rss configuration for bonding
>
> Could You also review them and ack if You agree with that implementation, 
> please?

Hi MichalX,

I've checked above patches. But I am sorry that I am not a correct
person to ack your patches.
To review it correctly, at least knowledge about RSS and bonding PMD are
needed, but honestly I am not familiar with RSS.
Is it possible to find a correct person who can ack it?

BTW, I've checked the patch from the following point of view. It may
help other reviewers.
(I've checked after fixing null PMD issues I've found today, please
check an email I've sent to Tomasz)
 - No fatal errors are reported by checkpatch.pl.
- Some style warnings are reported, but I guess we can ignore it.
 - No compile error with gcc-4.6/4.7/4.8/4.9/5, clang and icc.
 - No missing symbol.
 - No compile error for docs.
 - No compile error for examples.

Thanks,
Tetsuya

[dpdk-dev] [PATCH v2 01/35] e1000/base: update readme and copyright

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wenzhuo Lu
> Sent: Thursday, October 15, 2015 3:03 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2 01/35] e1000/base: update readme and
> copyright

Hi Wenzhuo,

If you do an update to this patchset again could you add something to the 
release note. Or just submit it in another patch if this gets merged as it is.

It doesn't need to include every change to e1000/base, just a summary of the 
important ones. See for example the entry for "Updated the ixgbe base driver" 
in the previous release notes:

http://dpdk.org/doc/guides/rel_notes/release_2_1.html

John.
-- 

[dpdk-dev] Calling rte_eth_rx_burst() multiple times

[Younghwan Go]

Hi,

I'm pretty new to playing with DPDK. I was trying to see if I can always 
receive MAX_BURST packets by calling rte_eth_rx_burst() multiple times 
on same  pair (code shown below). I'm using DPDK-2.1.0 on 2 
dual-port Intel 82599ES 10Gbps NICs with Ubuntu 14.04.3 (kernel 
3.13.0-63-generic).

Since packet processing is slower (~10 Gbps) than pure RX speed (~40 
Gbps), I assumed rte_eth_rx_burst() would always receive some number of 
packets, eventually filling up MAX_BURST. But for multi-core case (4 
CPUs, 4 ports), rte_eth_rx_burst() starts to always return 0 after some 
time, causing all cores to be blocked forever. Analyzing the DPDK code 
(drivers/net/ixgbe/ixgbe_rxtx.c), I'm seeing that inside 
ixgbe_rx_scan_hw_ring() function, "rxdp->wb.upper.status.error" always 
returns 0 (where is this value set by the way?).

I didn't see this problem for single-core case, in which it returned 
MAX_BURST packets at every rte_eth_rx_burst() call. Also, if I break out 
of while loop when I receive 0, I keep receiving packets in next  pairs. Does anyone know why this block might happen? Or am I not 
allowed to call rte_eth_rx_burst() multiple times on same  
pair if I get 0? Any help will be great! Thank you!


int cnt = MAX_BURST; // MAX_BURST = 32
int off = 0;
do {
 ret = rte_eth_rx_burst(port_id, queue_id, &m_table[off], cnt);
 if (ret == 0) {
 // don't break out but continue
 } else if (ret > 0) {
 off += ret;
 cnt -= ret;
 }
} while (cnt > 0);


Best,
Younghwan

[dpdk-dev] [PATCH v2 01/35] e1000/base: update readme and copyright

[Lu, Wenzhuo]

Hi John,

> -Original Message-
> From: Mcnamara, John
> Sent: Thursday, October 15, 2015 4:30 PM
> To: Lu, Wenzhuo; dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v2 01/35] e1000/base: update readme and
> copyright
> 
> 
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wenzhuo Lu
> > Sent: Thursday, October 15, 2015 3:03 AM
> > To: dev at dpdk.org
> > Subject: [dpdk-dev] [PATCH v2 01/35] e1000/base: update readme and
> > copyright
> 
> Hi Wenzhuo,
> 
> If you do an update to this patchset again could you add something to the
> release note. Or just submit it in another patch if this gets merged as it is.
> 
> It doesn't need to include every change to e1000/base, just a summary of the
> important ones. See for example the entry for "Updated the ixgbe base driver" 
> in
> the previous release notes:
> 
> http://dpdk.org/doc/guides/rel_notes/release_2_1.html
Thanks for the comments. I'll update the release notes.
> 
> John.
> --
> 

[dpdk-dev] [PATCH v5 4/9] null: virtual dynamic rss configuration

[Kulasek, TomaszX]

> -Original Message-
> From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp]
> Sent: Thursday, October 15, 2015 09:46
> To: Kulasek, TomaszX; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v5 4/9] null: virtual dynamic rss
> configuration
> 
> On 2015/09/30 23:05, Tomasz Kulasek wrote:
> > This implementation allows to set and read RSS configuration for null
> > device, and is used to validate right values propagation over the
> > slaves, in test units for dynamic RSS configuration for bonding.
> >
> > v5 changes:
> >  - replaced memcpy with rte_memcpy
> >
> > Signed-off-by: Tomasz Kulasek 
> > ---
> >  drivers/net/null/rte_eth_null.c |  116
> > +++
> >  1 file changed, 116 insertions(+)
> >
> > diff --git a/drivers/net/null/rte_eth_null.c
> > b/drivers/net/null/rte_eth_null.c index bf81b1b..b01f647 100644
> > --- a/drivers/net/null/rte_eth_null.c
> > +++ b/drivers/net/null/rte_eth_null.c
> > @@ -37,6 +37,8 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> >
> >
> 
> 
> Hi Tomasz,
> 
> We don't have "rte_eth_null.h" at this point.
> (The header file will be added next patch) Probably, we also need
> "rte_pmd_null_version.map" to compile correctly.
> (To make sure, please compile DPDK with "CONFIG_RTE_BUILD_SHARED_LIB=y"
> option.)
> 
> Also, it seems 'rte_eth_null.h' should be included like below.
> #include "rte_eth_null.h"
> Without it, we cannot compile.
> 
> Thanks,
> Tetsuya

Hi Tetsuya,

This file and modifications are already included in "[dpdk-dev,v5,5/9] null: 
export eth_dev_null_create" in the patch set, also the required symlink is 
created like below:

---
diff --git a/drivers/net/null/Makefile b/drivers/net/null/Makefile
index 96ba01c..2202389 100644
--- a/drivers/net/null/Makefile
+++ b/drivers/net/null/Makefile
@@ -51,7 +51,7 @@  SRCS-$(CONFIG_RTE_LIBRTE_PMD_NULL) += rte_eth_null.c
 #
 # Export include files
 #
-SYMLINK-y-include +=
+SYMLINK-y-include += rte_eth_null.h

 # this lib depends upon:
 DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_NULL) += lib/librte_mbuf
---

Tomasz.

[dpdk-dev] [PATCH v5 4/9] null: virtual dynamic rss configuration

[Tetsuya Mukawa]

On 2015/10/15 17:42, Kulasek, TomaszX wrote:
>> -Original Message-
>> From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp]
>> Sent: Thursday, October 15, 2015 09:46
>> To: Kulasek, TomaszX; dev at dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH v5 4/9] null: virtual dynamic rss
>> configuration
>>
>> On 2015/09/30 23:05, Tomasz Kulasek wrote:
>>> This implementation allows to set and read RSS configuration for null
>>> device, and is used to validate right values propagation over the
>>> slaves, in test units for dynamic RSS configuration for bonding.
>>>
>>> v5 changes:
>>>  - replaced memcpy with rte_memcpy
>>>
>>> Signed-off-by: Tomasz Kulasek 
>>> ---
>>>  drivers/net/null/rte_eth_null.c |  116
>>> +++
>>>  1 file changed, 116 insertions(+)
>>>
>>> diff --git a/drivers/net/null/rte_eth_null.c
>>> b/drivers/net/null/rte_eth_null.c index bf81b1b..b01f647 100644
>>> --- a/drivers/net/null/rte_eth_null.c
>>> +++ b/drivers/net/null/rte_eth_null.c
>>> @@ -37,6 +37,8 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>> +#include 
>>>
>>>
>>
>> Hi Tomasz,
>>
>> We don't have "rte_eth_null.h" at this point.
>> (The header file will be added next patch) Probably, we also need
>> "rte_pmd_null_version.map" to compile correctly.
>> (To make sure, please compile DPDK with "CONFIG_RTE_BUILD_SHARED_LIB=y"
>> option.)
>>
>> Also, it seems 'rte_eth_null.h' should be included like below.
>> #include "rte_eth_null.h"
>> Without it, we cannot compile.
>>
>> Thanks,
>> Tetsuya
> Hi Tetsuya,
>
> This file and modifications are already included in "[dpdk-dev,v5,5/9] null: 
> export eth_dev_null_create" in the patch set, also the required symlink is 
> created like below:

Hi Tomasz,

But "rte_eth_null.h" is used in " [PATCH v5 4/9] null: virtual dynamic
rss configuration".
It means we cannot compile DPDK before applying "[dpdk-dev,v5,5/9]".
When we need to use git-bisect, this will be problem.
So could you please keep DPDK being able to compile at any point?

Thanks,
Tetsuya,

[dpdk-dev] Calling rte_eth_rx_burst() multiple times

[Zoltan Kiss]

On 15/10/15 09:32, Younghwan Go wrote:
> Hi,
>
> I'm pretty new to playing with DPDK. I was trying to see if I can always
> receive MAX_BURST packets by calling rte_eth_rx_burst() multiple times
> on same  pair (code shown below). I'm using DPDK-2.1.0 on 2
> dual-port Intel 82599ES 10Gbps NICs with Ubuntu 14.04.3 (kernel
> 3.13.0-63-generic).
>
> Since packet processing is slower (~10 Gbps) than pure RX speed (~40
> Gbps), I assumed rte_eth_rx_burst() would always receive some number of
> packets, eventually filling up MAX_BURST. But for multi-core case (4
> CPUs, 4 ports), rte_eth_rx_burst() starts to always return 0 after some
> time, causing all cores to be blocked forever. Analyzing the DPDK code
> (drivers/net/ixgbe/ixgbe_rxtx.c), I'm seeing that inside
> ixgbe_rx_scan_hw_ring() function, "rxdp->wb.upper.status.error" always
> returns 0 (where is this value set by the way?).

I think it is set by the hardware.

>
> I didn't see this problem for single-core case, in which it returned
> MAX_BURST packets at every rte_eth_rx_burst() call. Also, if I break out
> of while loop when I receive 0, I keep receiving packets in next  queue> pairs. Does anyone know why this block might happen? Or am I not
> allowed to call rte_eth_rx_burst() multiple times on same 
> pair if I get 0? Any help will be great! Thank you!

Although not mentioned in the documentation itself, as far as I know 
rte_eth_rx_burst() is not thread-safe. If you look in to receive 
functions, there are no locking anywhere. You should call it on separate 
queues from different threads, and configure e.g RSS to distribute the 
traffic by the hardware.

>
> 
> int cnt = MAX_BURST; // MAX_BURST = 32
> int off = 0;
> do {
>  ret = rte_eth_rx_burst(port_id, queue_id, &m_table[off], cnt);
>  if (ret == 0) {
>  // don't break out but continue
>  } else if (ret > 0) {
>  off += ret;
>  cnt -= ret;
>  }
> } while (cnt > 0);
> 
>
> Best,
> Younghwan

[dpdk-dev] [PATCH] ixgbe: prefetch packet headers in vector PMD receive function

[Zoltan Kiss]

On 15/10/15 00:23, Ananyev, Konstantin wrote:
>
>
>> -Original Message-
>> From: Zoltan Kiss [mailto:zoltan.kiss at linaro.org]
>> Sent: Wednesday, October 14, 2015 5:11 PM
>> To: Ananyev, Konstantin; Richardson, Bruce; dev at dpdk.org
>> Subject: Re: [PATCH] ixgbe: prefetch packet headers in vector PMD receive 
>> function
>>
>>
>>
>> On 28/09/15 00:19, Ananyev, Konstantin wrote:
>>>
>>>
 -Original Message-
 From: Zoltan Kiss [mailto:zoltan.kiss at linaro.org]
 Sent: Friday, September 25, 2015 7:29 PM
 To: Richardson, Bruce; dev at dpdk.org
 Cc: Ananyev, Konstantin
 Subject: Re: [PATCH] ixgbe: prefetch packet headers in vector PMD receive 
 function

 On 07/09/15 07:41, Richardson, Bruce wrote:
>
>> -Original Message-
>> From: Zoltan Kiss [mailto:zoltan.kiss at linaro.org]
>> Sent: Monday, September 7, 2015 3:15 PM
>> To: Richardson, Bruce; dev at dpdk.org
>> Cc: Ananyev, Konstantin
>> Subject: Re: [PATCH] ixgbe: prefetch packet headers in vector PMD receive
>> function
>>
>>
>>
>> On 07/09/15 13:57, Richardson, Bruce wrote:
>>>
 -Original Message-
 From: Zoltan Kiss [mailto:zoltan.kiss at linaro.org]
 Sent: Monday, September 7, 2015 1:26 PM
 To: dev at dpdk.org
 Cc: Ananyev, Konstantin; Richardson, Bruce
 Subject: Re: [PATCH] ixgbe: prefetch packet headers in vector PMD
 receive function

 Hi,

 I just realized I've missed the "[PATCH]" tag from the subject. Did
 anyone had time to review this?

>>> Hi Zoltan,
>>>
>>> the big thing that concerns me with this is the addition of new
>>> instructions for each packet in the fast path. Ideally, this
>>> prefetching would be better handled in the application itself, as for
>>> some apps, e.g. those using pipelining, the core doing the RX from the
>>> NIC may not touch the packet data at all, and the prefetches will
>> instead cause a performance slowdown.
>>> Is it possible to get the same performance increase - or something
>>> close to it - by making changes in OVS?
>> OVS already does a prefetch when it's processing the previous packet, but
>> apparently it's not early enough. At least for my test scenario, where 
>> I'm
>> forwarding UDP packets with the least possible overhead. I guess in tests
>> where OVS does more complex processing it should be fine.
>> I'll try to move the prefetch earlier in OVS codebase, but I'm not sure 
>> if
>> it'll help.
> I would suggest trying to prefetch more than one packet ahead. 
> Prefetching 4 or
> 8 ahead might work better, depending on the processing being done.

 I've moved the prefetch earlier, and it seems to work:

 https://patchwork.ozlabs.org/patch/519017/

 However it raises the question: should we remove header prefetch from
 all the other drivers, and the CONFIG_RTE_PMD_PACKET_PREFETCH option?
>>>
>>> My vote would be for that.
>>> Konstantin
>>
>> After some further thinking I would rather support the
>> rte_packet_prefetch() macro (prefetch the header in the driver, and
>> configure it through CONFIG_RTE_PMD_PACKET_PREFETCH)
>>
>> - the prefetch can happen earlier, so if an application needs the header
>> right away, this is the fastest
>> - if the application doesn't need header prefetch, it can turn it off
>> compile time. Same as if we wouldn't have this option.
>> - if the application has mixed needs (sometimes it needs the header
>> right away, sometimes it doesn't), it can turn it off and do what it
>> needs. Same as if we wouldn't have this option.
>>
>> A harder decision would be whether it should be turned on or off by
>> default. Currently it's on, and half of the receive functions don't use it.
>
> Yep,  it is sort of a mess right now.
> Another question if we'd like to keep it and standardise it:
> at what moment to prefetch: as soon as we realize that HW is done with that 
> buffer,
> or as late inside rx_burst() as possible?
> I suppose there is no clear answer for that.
I think if the application needs the driver start the prefetching, it 
does it because it's already too late when rte_eth_rx_burst() returns. 
So I think it's best to do it as soon as we learn that the HW is done.

> That's why my thought was to just get rid of it.
> Though if it would be implemented in some standardized way and disabled by 
> default -
> that's probably ok too.
> BTW, couldn't that be implemented just via rte_ethdev rx callbacks mechanism?
> Then we can have the code one place and don't need compile option at all -
> could be ebabled/disabled dynamically on a per nic basis.
> Or would it be too high overhead for that?

I think if we go that way, it's better to pass an option to 
rte_eth_rx_burst() and tell if you want the header prefetched by the 
driver. That would be the mos

[dpdk-dev] [PATCH v5 5/9] null: export eth_dev_null_create

[Jastrzebski, MichalX K]

> -Original Message-
> From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp]
> Sent: Thursday, October 15, 2015 10:17 AM
> To: Jastrzebski, MichalX K
> Cc: Glynn, Michael J; Kulasek, TomaszX; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v5 5/9] null: export eth_dev_null_create
> 
> On 2015/10/14 21:42, Jastrzebski, MichalX K wrote:
> >> -Original Message-
> >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Tetsuya Mukawa
> >> Sent: Wednesday, October 14, 2015 3:35 AM
> >> To: Kulasek, TomaszX; dev at dpdk.org
> >> Subject: Re: [dpdk-dev] [PATCH v5 5/9] null: export eth_dev_null_create
> >>
> >> On 2015/09/30 23:05, Tomasz Kulasek wrote:
> >>> Signed-off-by: Tomasz Kulasek 
> >>> ---
> >>>  drivers/net/null/Makefile |2 +-
> >>>  drivers/net/null/rte_eth_null.c   |2 +-
> >>>  drivers/net/null/rte_eth_null.h   |   40
> >> +
> >>>  drivers/net/null/rte_pmd_null_version.map |7 +
> >>>  4 files changed, 49 insertions(+), 2 deletions(-)
> >>>  create mode 100644 drivers/net/null/rte_eth_null.h
> >> Acked-by: Tetsuya Mukawa 
> > Hi Tetsuya,
> > Thank You for a review and acking patches.
> > There are 5 remaining patches in a patch-set:
> >
> > [dpdk-dev] [PATCH v5 1/9] bonding: rss dynamic configuration
> > [dpdk-dev] [PATCH v5 6/9] test: dynamic rss configuration
> > [dpdk-dev] [PATCH v5 7/9] bonding: per queue stats
> > [dpdk-dev] [PATCH v5 8/9] doc: fixed spellings and typos
> > [dpdk-dev] [PATCH v5 9/9] doc: dynamic rss configuration for bonding
> >
> > Could You also review them and ack if You agree with that implementation,
> please?
> 
> Hi MichalX,
> 
> I've checked above patches. But I am sorry that I am not a correct
> person to ack your patches.
> To review it correctly, at least knowledge about RSS and bonding PMD are
> needed, but honestly I am not familiar with RSS.
> Is it possible to find a correct person who can ack it?
> 
> BTW, I've checked the patch from the following point of view. It may
> help other reviewers.
> (I've checked after fixing null PMD issues I've found today, please
> check an email I've sent to Tomasz)
>  - No fatal errors are reported by checkpatch.pl.
> - Some style warnings are reported, but I guess we can ignore it.
>  - No compile error with gcc-4.6/4.7/4.8/4.9/5, clang and icc.
>  - No missing symbol.
>  - No compile error for docs.
>  - No compile error for examples.
> 
> Thanks,
> Tetsuya

Hi Tetsuya,
Thank You very much for verifications and Your comments. 
I will ask maintainers in term of reviewing remaining patches.

Regarding an issue with rte_eth_null.h I think that reordering of patches
4 and 5 may be sufficient. 

Best regards
Michal

[dpdk-dev] Calling rte_eth_rx_burst() multiple times

[Younghwan Go]

Hi Zoltan,

Thanks for the email.

2015-10-15 ?? 7:23? Zoltan Kiss ?(?) ? ?:
>
>
> On 15/10/15 09:32, Younghwan Go wrote:
>> Hi,
>>
>> I'm pretty new to playing with DPDK. I was trying to see if I can always
>> receive MAX_BURST packets by calling rte_eth_rx_burst() multiple times
>> on same  pair (code shown below). I'm using DPDK-2.1.0 on 2
>> dual-port Intel 82599ES 10Gbps NICs with Ubuntu 14.04.3 (kernel
>> 3.13.0-63-generic).
>>
>> Since packet processing is slower (~10 Gbps) than pure RX speed (~40
>> Gbps), I assumed rte_eth_rx_burst() would always receive some number of
>> packets, eventually filling up MAX_BURST. But for multi-core case (4
>> CPUs, 4 ports), rte_eth_rx_burst() starts to always return 0 after some
>> time, causing all cores to be blocked forever. Analyzing the DPDK code
>> (drivers/net/ixgbe/ixgbe_rxtx.c), I'm seeing that inside
>> ixgbe_rx_scan_hw_ring() function, "rxdp->wb.upper.status.error" always
>> returns 0 (where is this value set by the way?).
>
> I think it is set by the hardware.
>
>>
>> I didn't see this problem for single-core case, in which it returned
>> MAX_BURST packets at every rte_eth_rx_burst() call. Also, if I break out
>> of while loop when I receive 0, I keep receiving packets in next > queue> pairs. Does anyone know why this block might happen? Or am I not
>> allowed to call rte_eth_rx_burst() multiple times on same 
>> pair if I get 0? Any help will be great! Thank you!
>
> Although not mentioned in the documentation itself, as far as I know 
> rte_eth_rx_burst() is not thread-safe. If you look in to receive 
> functions, there are no locking anywhere. You should call it on 
> separate queues from different threads, and configure e.g RSS to 
> distribute the traffic by the hardware.

I'm calling rte_eth_rx_burst() on separate queue ids for each thread. 
I'm actually using lcore_id (= 0, 1, 2, 3 for 4 threads pinned to each 
separate CPU core) as queue_id. I also made sure that this problem is 
not caused by threads conflicting by locking before calling 
rte_eth_rx_burst().

For RSS, I configured with ETH_RSS_IP for load balancing traffic to each 
port and queue. But even if RSS wasn't set, shouldn't at least one core 
be receiving packets? What I'm seeing is all threads getting stuck at 
rte_eth_rx_burst() with return value of 0s indefinitely.

>>
>> 
>> int cnt = MAX_BURST; // MAX_BURST = 32
>> int off = 0;
>> do {
>>  ret = rte_eth_rx_burst(port_id, queue_id, &m_table[off], cnt);
>>  if (ret == 0) {
>>  // don't break out but continue
>>  } else if (ret > 0) {
>>  off += ret;
>>  cnt -= ret;
>>  }
>> } while (cnt > 0);
>> 
>>
>> Best,
>> Younghwan

Thanks,
Younghwan

[dpdk-dev] [PATCH 1/3] fm10k: add multi-queue checking

[He, Shaopeng]

Hi, Michael

> -Original Message-
> From: Qiu, Michael
> Sent: Thursday, October 15, 2015 2:28 PM
> To: He, Shaopeng; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 1/3] fm10k: add multi-queue checking
> 
> On 2015/9/30 15:29, Shaopeng He wrote:
> > Add multi-queue checking in device configure process.
> > Currently, VMDQ and RSS are supported.
> >
> > Signed-off-by: Shaopeng He 
> > ---
> >  drivers/net/fm10k/fm10k_ethdev.c | 44
> > 
> >  1 file changed, 44 insertions(+)
> >
> > diff --git a/drivers/net/fm10k/fm10k_ethdev.c
> > b/drivers/net/fm10k/fm10k_ethdev.c
> > index a69c990..082937d 100644
> > --- a/drivers/net/fm10k/fm10k_ethdev.c
> > +++ b/drivers/net/fm10k/fm10k_ethdev.c
> > @@ -283,12 +283,56 @@ tx_queue_disable(struct fm10k_hw *hw,
> uint16_t
> > qnum)  }
> >
> >  static int
> > +fm10k_check_mq_mode(struct rte_eth_dev *dev) {
> > +   enum rte_eth_rx_mq_mode rx_mq_mode = dev->data-
> >dev_conf.rxmode.mq_mode;
> > +   struct fm10k_hw *hw = FM10K_DEV_PRIVATE_TO_HW(dev->data-
> >dev_private);
> > +   struct rte_eth_vmdq_rx_conf *vmdq_conf;
> > +   uint16_t nb_rx_q = dev->data->nb_rx_queues;
> > +
> > +   vmdq_conf = &dev->data->dev_conf.rx_adv_conf.vmdq_rx_conf;
> > +
> > +   if (rx_mq_mode & ETH_MQ_RX_DCB_FLAG) {
> > +   PMD_INIT_LOG(ERR, "DCB mode is not supported.");
> > +   return -EINVAL;
> > +   }
> > +
> > +   if (!(rx_mq_mode & ETH_MQ_RX_VMDQ_FLAG))
> > +   return 0;
> > +
> > +   if (hw->mac.type == fm10k_mac_vf) {
> > +   PMD_INIT_LOG(ERR, "VMDQ mode is not supported in VF.");
> > +   return -EINVAL;
> > +   }
> 
> I think vf check should be the first one, then we do not need check dcb and
> VMDq flag.
> 
> Thanks,
> Michael

Thanks for the comments. There is a case of RSS support on VF, if vf check be 
the first one, it will return fail, which is not correct.

Thanks,
--Shaopeng
> > +
> > +   /* Check VMDQ queue pool number */
> > +   if (vmdq_conf->nb_queue_pools >
> > +   sizeof(vmdq_conf->pool_map[0].pools) * CHAR_BIT
> ||
> > +   vmdq_conf->nb_queue_pools > nb_rx_q) {
> > +   PMD_INIT_LOG(ERR, "Too many of queue pools: %d",
> > +   vmdq_conf->nb_queue_pools);
> > +   return -EINVAL;
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> > +static int
> >  fm10k_dev_configure(struct rte_eth_dev *dev)  {
> > +   int ret;
> > +
> > PMD_INIT_FUNC_TRACE();
> >
> > if (dev->data->dev_conf.rxmode.hw_strip_crc == 0)
> > PMD_INIT_LOG(WARNING, "fm10k always strip CRC");
> > +   /* multipe queue mode checking */
> > +   ret  = fm10k_check_mq_mode(dev);
> > +   if (ret != 0) {
> > +   PMD_DRV_LOG(ERR, "fm10k_check_mq_mode fails
> with %d.",
> > +   ret);
> > +   return ret;
> > +   }
> >
> > return 0;
> >  }

[dpdk-dev] [PATCH] vhost-user: enable virtio 1.0

[Marcel Apfelbaum]

Make vhost-user virtio 1.0 compatible by adding it to the
supported features and keeping the header length
the same as for mergeable RX buffers.

Signed-off-by: Marcel Apfelbaum 
---

To be applied on top of:
   [dpdk-dev] [PATCH v6 00/13] vhost-user multiple queues enabling

Thanks,
Marcel

 lib/librte_vhost/virtio-net.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/lib/librte_vhost/virtio-net.c b/lib/librte_vhost/virtio-net.c
index a51327d..ee4650e 100644
--- a/lib/librte_vhost/virtio-net.c
+++ b/lib/librte_vhost/virtio-net.c
@@ -75,6 +75,7 @@ static struct virtio_net_config_ll *ll_root;
(1ULL << VIRTIO_NET_F_CTRL_VQ) | \
(1ULL << VIRTIO_NET_F_CTRL_RX) | \
(1ULL << VIRTIO_NET_F_MQ)  | \
+   (1ULL << VIRTIO_F_VERSION_1)   | \
(1ULL << VHOST_F_LOG_ALL)  | \
(1ULL << VHOST_USER_F_PROTOCOL_FEATURES))
 static uint64_t VHOST_FEATURES = VHOST_SUPPORTED_FEATURES;
@@ -477,17 +478,17 @@ set_features(struct vhost_device_ctx ctx, uint64_t *pu)
return -1;

dev->features = *pu;
-   if (dev->features & (1 << VIRTIO_NET_F_MRG_RXBUF)) {
-   LOG_DEBUG(VHOST_CONFIG,
-   "(%"PRIu64") Mergeable RX buffers enabled\n",
-   dev->device_fh);
+   if (dev->features &
+   ((1 << VIRTIO_NET_F_MRG_RXBUF) | (1ULL << VIRTIO_F_VERSION_1))) {
vhost_hlen = sizeof(struct virtio_net_hdr_mrg_rxbuf);
} else {
-   LOG_DEBUG(VHOST_CONFIG,
-   "(%"PRIu64") Mergeable RX buffers disabled\n",
-   dev->device_fh);
vhost_hlen = sizeof(struct virtio_net_hdr);
}
+   LOG_DEBUG(VHOST_CONFIG,
+  "(%"PRIu64") Mergeable RX buffers %s, virtio 1 %s\n",
+ dev->device_fh,
+  (dev->features & (1 << VIRTIO_NET_F_MRG_RXBUF)) ? "on" : "off",
+  (dev->features & (1ULL << VIRTIO_F_VERSION_1)) ? "on" : "off");

for (i = 0; i < dev->virt_qp_nb; i++) {
uint16_t base_idx = i * VIRTIO_QNUM;
-- 
2.1.0

[dpdk-dev] [PATCH] eal: don't reset getopt lib

[Tiwei Bie]

Someone may need to call rte_eal_init() with a fake argc/argv array
in the middle of using getopt() to parse its own unrelated argc/argv
parameters. So getopt lib shouldn't be reset by rte_eal_init().

Now eal will always save optind, optarg and optopt (and optreset on
FreeBSD) at the beginning, initialize optind (and optreset on FreeBSD)
to 1 before calling getopt_long(), then restore all values after.

Suggested-by: Don Provan 
Suggested-by: Bruce Richardson 
Signed-off-by: Tiwei Bie 
---
 lib/librte_eal/bsdapp/eal/eal.c   | 59 +++--
 lib/librte_eal/linuxapp/eal/eal.c | 69 ++-
 2 files changed, 102 insertions(+), 26 deletions(-)

diff --git a/lib/librte_eal/bsdapp/eal/eal.c b/lib/librte_eal/bsdapp/eal/eal.c
index 1b6f705..bd09377 100644
--- a/lib/librte_eal/bsdapp/eal/eal.c
+++ b/lib/librte_eal/bsdapp/eal/eal.c
@@ -312,8 +312,20 @@ eal_log_level_parse(int argc, char **argv)
int opt;
char **argvopt;
int option_index;
+   int old_optind;
+   int old_optopt;
+   int old_optreset;
+   char *old_optarg;
+
+   /* save getopt lib */
+   old_optind = optind;
+   old_optopt = optopt;
+   old_optreset = optreset;
+   old_optarg = optarg;

argvopt = argv;
+   optind = 1;
+   optreset = 1;

eal_reset_internal_config(&internal_config);

@@ -334,7 +346,11 @@ eal_log_level_parse(int argc, char **argv)
break;
}

-   optind = 0; /* reset getopt lib */
+   /* restore getopt lib */
+   optind = old_optind;
+   optopt = old_optopt;
+   optreset = old_optreset;
+   optarg = old_optarg;
 }

 /* Parse the argument given in the command line of the application */
@@ -345,25 +361,37 @@ eal_parse_args(int argc, char **argv)
char **argvopt;
int option_index;
char *prgname = argv[0];
+   int old_optind;
+   int old_optopt;
+   int old_optreset;
+   char *old_optarg;
+
+   /* save getopt lib */
+   old_optind = optind;
+   old_optopt = optopt;
+   old_optreset = optreset;
+   old_optarg = optarg;

argvopt = argv;
+   optind = 1;
+   optreset = 1;

while ((opt = getopt_long(argc, argvopt, eal_short_options,
  eal_long_options, &option_index)) != EOF) {

-   int ret;
-
/* getopt is not happy, stop right now */
if (opt == '?') {
eal_usage(prgname);
-   return -1;
+   ret = -1;
+   goto out;
}

ret = eal_parse_common_option(opt, optarg, &internal_config);
/* common parser is not happy */
if (ret < 0) {
eal_usage(prgname);
-   return -1;
+   ret = -1;
+   goto out;
}
/* common parser handled this option */
if (ret == 0)
@@ -387,23 +415,34 @@ eal_parse_args(int argc, char **argv)
"on FreeBSD\n", opt);
}
eal_usage(prgname);
-   return -1;
+   ret = -1;
+   goto out;
}
}

-   if (eal_adjust_config(&internal_config) != 0)
-   return -1;
+   if (eal_adjust_config(&internal_config) != 0) {
+   ret = -1;
+   goto out;
+   }

/* sanity checks */
if (eal_check_common_options(&internal_config) != 0) {
eal_usage(prgname);
-   return -1;
+   ret = -1;
+   goto out;
}

if (optind >= 0)
argv[optind-1] = prgname;
ret = optind-1;
-   optind = 0; /* reset getopt lib */
+
+out:
+   /* restore getopt lib */
+   optind = old_optind;
+   optopt = old_optopt;
+   optreset = old_optreset;
+   optarg = old_optarg;
+
return ret;
 }

diff --git a/lib/librte_eal/linuxapp/eal/eal.c 
b/lib/librte_eal/linuxapp/eal/eal.c
index 33e1067..4796030 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -505,8 +505,17 @@ eal_log_level_parse(int argc, char **argv)
int opt;
char **argvopt;
int option_index;
+   int old_optind;
+   int old_optopt;
+   char *old_optarg;
+
+   /* save getopt lib */
+   old_optind = optind;
+   old_optopt = optopt;
+   old_optarg = optarg;

argvopt = argv;
+   optind = 1;

eal_reset_internal_config(&internal_config);

@@ -527,7 +536,10 @@ eal_log_level_parse(int argc, char **argv)
break;
}

-   optind = 0; /* reset getopt lib */
+   /* restore getopt lib */
+   optind = old_optind;
+   optopt = old_optopt;
+   

[dpdk-dev] [PATCH 0/2] Provide reasonable default to -n

[Panu Matilainen]

The number of memory channels is a truly obscure thing as a mandatory
command line argument when its really just an optimization.
Provide a reasonable default in mempool as suggested by Bruce Richardson
and make the -n argument optional in EAL to make DPDK that little bit
easier to use for a first-timer.

Panu Matilainen (2):
  mempool: use a better default for number of memory channels
  eal: make the -n argument optional

 lib/librte_eal/common/eal_common_options.c | 8 +---
 lib/librte_mempool/rte_mempool.c   | 2 +-
 2 files changed, 2 insertions(+), 8 deletions(-)

-- 
2.4.3

[dpdk-dev] [PATCH 1/2] mempool: use a better default for number of memory channels

[Panu Matilainen]

Optimize for quad-channel by default, this should work well for
all the cases, better than the previous value of one anyway.

Suggested-by: Bruce Richardson 
Signed-off-by: Panu Matilainen 
---
 lib/librte_mempool/rte_mempool.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index 8e185c5..e57cbbd 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -113,7 +113,7 @@ static unsigned optimize_object_size(unsigned obj_size)
/* get number of channels */
nchan = rte_memory_get_nchannel();
if (nchan == 0)
-   nchan = 1;
+   nchan = 4;

nrank = rte_memory_get_nrank();
if (nrank == 0)
-- 
2.4.3

[dpdk-dev] [PATCH 2/2] eal: make the -n argument optional

[Panu Matilainen]

Obtaining the correct value of memory channels, especially from a
running system, can be anything from difficult to plain impossible.
Since the value is merely an optimization and does not affect functionality
otherwise, its pointless to force such a guess on users initially, such
things belong to performance tuning phase.

Signed-off-by: Panu Matilainen 
---
 lib/librte_eal/common/eal_common_options.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/lib/librte_eal/common/eal_common_options.c 
b/lib/librte_eal/common/eal_common_options.c
index 1f459ac..a4cdbaa 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -834,12 +834,6 @@ eal_check_common_options(struct internal_config 
*internal_cfg)
RTE_LOG(ERR, EAL, "Invalid process type specified\n");
return -1;
}
-   if (internal_cfg->process_type == RTE_PROC_PRIMARY &&
-   internal_cfg->force_nchannel == 0) {
-   RTE_LOG(ERR, EAL, "Number of memory channels (-n) not "
-   "specified\n");
-   return -1;
-   }
if (index(internal_cfg->hugefile_prefix, '%') != NULL) {
RTE_LOG(ERR, EAL, "Invalid char, '%%', in --"OPT_FILE_PREFIX" "
"option\n");
@@ -869,7 +863,7 @@ eal_check_common_options(struct internal_config 
*internal_cfg)
 void
 eal_common_usage(void)
 {
-   printf("-c COREMASK|-l CORELIST -n CHANNELS [options]\n\n"
+   printf("-c COREMASK|-l CORELIST [options]\n\n"
   "EAL common options:\n"
   "  -c COREMASK Hexadecimal bitmask of cores to run on\n"
   "  -l CORELIST List of cores to run on\n"
-- 
2.4.3

[dpdk-dev] Calling rte_eth_rx_burst() multiple times

[Zoltan Kiss]

On 15/10/15 11:43, Younghwan Go wrote:
> Hi Zoltan,
>
> Thanks for the email.
>
> 2015-10-15 ?? 7:23? Zoltan Kiss ?(?) ? ?:
>>
>>
>> On 15/10/15 09:32, Younghwan Go wrote:
>>> Hi,
>>>
>>> I'm pretty new to playing with DPDK. I was trying to see if I can always
>>> receive MAX_BURST packets by calling rte_eth_rx_burst() multiple times
>>> on same  pair (code shown below). I'm using DPDK-2.1.0 on 2
>>> dual-port Intel 82599ES 10Gbps NICs with Ubuntu 14.04.3 (kernel
>>> 3.13.0-63-generic).
>>>
>>> Since packet processing is slower (~10 Gbps) than pure RX speed (~40
>>> Gbps), I assumed rte_eth_rx_burst() would always receive some number of
>>> packets, eventually filling up MAX_BURST. But for multi-core case (4
>>> CPUs, 4 ports), rte_eth_rx_burst() starts to always return 0 after some
>>> time, causing all cores to be blocked forever. Analyzing the DPDK code
>>> (drivers/net/ixgbe/ixgbe_rxtx.c), I'm seeing that inside
>>> ixgbe_rx_scan_hw_ring() function, "rxdp->wb.upper.status.error" always
>>> returns 0 (where is this value set by the way?).
>>
>> I think it is set by the hardware.
>>
>>>
>>> I didn't see this problem for single-core case, in which it returned
>>> MAX_BURST packets at every rte_eth_rx_burst() call. Also, if I break out
>>> of while loop when I receive 0, I keep receiving packets in next >> queue> pairs. Does anyone know why this block might happen? Or am I not
>>> allowed to call rte_eth_rx_burst() multiple times on same 
>>> pair if I get 0? Any help will be great! Thank you!
>>
>> Although not mentioned in the documentation itself, as far as I know
>> rte_eth_rx_burst() is not thread-safe. If you look in to receive
>> functions, there are no locking anywhere. You should call it on
>> separate queues from different threads, and configure e.g RSS to
>> distribute the traffic by the hardware.
>
> I'm calling rte_eth_rx_burst() on separate queue ids for each thread.
> I'm actually using lcore_id (= 0, 1, 2, 3 for 4 threads pinned to each
> separate CPU core) as queue_id. I also made sure that this problem is
> not caused by threads conflicting by locking before calling
> rte_eth_rx_burst().
>
> For RSS, I configured with ETH_RSS_IP for load balancing traffic to each
> port and queue. But even if RSS wasn't set, shouldn't at least one core
> be receiving packets? What I'm seeing is all threads getting stuck at
> rte_eth_rx_burst() with return value of 0s indefinitely.
>
>>>
>>> 
>>> int cnt = MAX_BURST; // MAX_BURST = 32
>>> int off = 0;
>>> do {
>>>  ret = rte_eth_rx_burst(port_id, queue_id, &m_table[off], cnt);

Another thing which might cause your problem is that I don't see where 
do you release the buffers after received into m_table. You need to call 
rte_pktmbuf_free() on them at some point, otherwise your pool can get 
depleted, and the receive function can't refill the descriptor rings.


>>>  if (ret == 0) {
>>>  // don't break out but continue
>>>  } else if (ret > 0) {
>>>  off += ret;
>>>  cnt -= ret;
>>>  }
>>> } while (cnt > 0);
>>> 
>>>
>>> Best,
>>> Younghwan
>
> Thanks,
> Younghwan

[dpdk-dev] [PATCH 0/2] Provide reasonable default to -n

[David Marchand]

Hello,

On Thu, Oct 15, 2015 at 1:49 PM, Panu Matilainen 
wrote:

> The number of memory channels is a truly obscure thing as a mandatory
> command line argument when its really just an optimization.
> Provide a reasonable default in mempool as suggested by Bruce Richardson
> and make the -n argument optional in EAL to make DPDK that little bit
> easier to use for a first-timer.
>
> Panu Matilainen (2):
>   mempool: use a better default for number of memory channels
>   eal: make the -n argument optional
>
>  lib/librte_eal/common/eal_common_options.c | 8 +---
>  lib/librte_mempool/rte_mempool.c   | 2 +-
>  2 files changed, 2 insertions(+), 8 deletions(-)
>

Looks good to me.
Thanks Panu.

Acked-by: David Marchand 


-- 
David Marchand

[dpdk-dev] [PATCH 0/2] Provide reasonable default to -n

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Panu Matilainen
> Sent: Thursday, October 15, 2015 12:49 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 0/2] Provide reasonable default to -n
> 
> The number of memory channels is a truly obscure thing as a mandatory
> command line argument when its really just an optimization.
> Provide a reasonable default in mempool as suggested by Bruce Richardson
> and make the -n argument optional in EAL to make DPDK that little bit
> easier to use for a first-timer.

Hi,

In the Linux and FreeBSD user guides there is the following statement that will
need to change as well, either as part of this patchset, or separately:

"The -c and the -n options are mandatory; the others are optional."

http://www.dpdk.org/doc/guides/linux_gsg/build_sample_apps.html#running-a-sample-application
http://www.dpdk.org/doc/guides/freebsd_gsg/build_sample_apps.html#running-a-sample-application

John.
-- 

[dpdk-dev] [PATCH] eal:Map rte cfg and uio at the end of hugepage mem

[Nissim Nisimov]

Problem:
In DPDK Primary/Secondary module we assume mapping same regions of virtual 
memory addresses for Primary process and Secondary.
An issue may occur when the Primary and secondary processes are not symmetric 
in such way that the code is not the same (for example, Primary process is a 
traffic distributer and secondary is a worker). The result may be that specific 
virtual address region in the first process won't be available in the second 
process.

Changes done at eal init:
map all related rte configuration and uio sections close to the end of huge 
pages memory (that mean rte_eal_memory_init() should be called before 
rte_config_init() in primary process)
According to our observations there will be more probability to success when 
allocating rte_config and uio memzones after huge pages sections (actually uio 
is already allocated after the huge pages area)

Signed-off-by: Nissim Nisimov 
---
 lib/librte_eal/linuxapp/eal/eal.c | 28 ++--
 lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 10 +++---
 2 files changed, 29 insertions(+), 9 deletions(-)

diff --git a/lib/librte_eal/linuxapp/eal/eal.c 
b/lib/librte_eal/linuxapp/eal/eal.c
index 33e1067..3cb354b 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -87,6 +87,7 @@

 #define SOCKET_MEM_STRLEN (RTE_MAX_NUMA_NODES * 10)

+void *pci_find_max_end_va(void);
 /* Allow the application to print its usage message too if set */
 static rte_usage_hook_trte_application_usage_hook = NULL;

@@ -189,12 +190,15 @@ rte_eal_config_create(void)
return;

/* map the config before hugepage address so that we don't waste a page 
*/
-   if (internal_config.base_virtaddr != 0)
+   if (internal_config.base_virtaddr != 0){
rte_mem_cfg_addr = (void *)
RTE_ALIGN_FLOOR(internal_config.base_virtaddr -
sizeof(struct rte_mem_config), sysconf(_SC_PAGE_SIZE));
-   else
-   rte_mem_cfg_addr = NULL;
+}
+   else{
+   rte_mem_cfg_addr = pci_find_max_end_va();
+RTE_LOG(INFO, EAL, "rte_mem_cfg_addr =  0x%llx 
PType=%s\n",(unsigned long long)rte_mem_cfg_addr,rte_config.process_type == 
RTE_PROC_PRIMARY ? "PRIMARY" : "SECONDARY");
+}

if (mem_cfg_fd < 0){
mem_cfg_fd = open(pathname, O_RDWR | O_CREAT, 0660);
@@ -227,7 +231,7 @@ rte_eal_config_create(void)
/* store address of the config in the config itself so that secondary
 * processes could later map the config into this exact location */
rte_config.mem_config->mem_cfg_addr = (uintptr_t) rte_mem_cfg_addr;
-
+
 }

 /* attach to an existing shared memory config */
@@ -784,6 +788,13 @@ rte_eal_init(int argc, char **argv)

rte_srand(rte_rdtsc());

+/* Primary process should allocate hugepages before configuration */
+   if(internal_config.process_type == RTE_PROC_PRIMARY){
+   RTE_LOG(INFO, EAL, "Calling rte_eal_memory_init as 
=%s\n",(rte_config.process_type == RTE_PROC_PRIMARY) ? "PRIMARY" : "SECONDARY");
+   if (rte_eal_memory_init() < 0)
+   rte_panic("Cannot init memory\n");
+   }
+
rte_config_init();

if (rte_eal_pci_init() < 0)
@@ -793,8 +804,13 @@ rte_eal_init(int argc, char **argv)
if (rte_eal_ivshmem_init() < 0)
rte_panic("Cannot init IVSHMEM\n");
 #endif
-
-   if (rte_eal_memory_init() < 0)
+/* secondary process will call memory init only after calling to 
rte_config_init() */
+   if(internal_config.process_type == RTE_PROC_SECONDARY){
+   RTE_LOG(INFO, EAL, "Calling rte_eal_memory_init as 
=%s\n",rte_config.process_type == RTE_PROC_PRIMARY ? "PRIMARY" : "SECONDARY");
+   if (rte_eal_memory_init() < 0)
+   rte_panic("Cannot init memory\n");
+   }
+if (rte_eal_memory_init() < 0)
rte_panic("Cannot init memory\n");

/* the directories are locked during eal_hugepage_info_init */
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c 
b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
index ac50e13..6812c37 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
@@ -338,9 +338,13 @@ pci_uio_map_resource_by_index(struct rte_pci_device *dev, 
int res_idx,
}

/* try mapping somewhere close to the end of hugepages */
-   if (pci_map_addr == NULL)
-   pci_map_addr = pci_find_max_end_va();
-
+   if (pci_map_addr == NULL){
+   if (internal_config.base_virtaddr != 0){
+   pci_map_addr = pci_find_max_end_va();
+} else{
+   pci_map_addr = 
(void*)RTE_PTR_ALIGN(((char*)rte_eal_get_configuration()->mem_config->mem_cfg_addr
 + sizeof(struct rte_mem_config)),sysconf(_SC_PAGE_SIZE));
+}
+}
 

[dpdk-dev] [PATCH v4 0/7] Add instalation rules for dpdk files.

[Panu Matilainen]

On 10/10/2015 08:45 PM, Arevalo, Mario Alfredo C wrote:
> Hi,
>
> Good day, I was wondering if someone has any comment about it :)

Hi, sorry been busy with some other agendas :)

See below...

>
> v4:
>
> Modify the makefile target to specify the files
> that will be installed using a rule:
>
> * make install-bin (install app files)(dafault path BIN_DIR=/usr/bin).
>
> * make install-headers (install headers)(dafault path 
> INCLUDE_DIR=/usr/include/dpdk).
>
> * make install-lib (install libraries)(dafault path if the architecture is 64 
> bits
>  is LIB_DIR=/usr/lib64 else LIB_DIR=/usr/lib).

I still maintain the LIB_DIR heuristic around x86_64 arch is broken and 
that we'll be better off without it. Even auto*tools and cmake dont try 
to guess this. If you insist on heuristics, you'll need help from other 
tools, eg on systems where systemd-path is available, you can get a 
reasonable well-educated guess from it with "systemd-path 
system-library-arch".

>
> * make install-doc (install documentation)(dafault path 
> DOC_DIR=/usr/share/doc/dpdk).
>
> * make install-mod (install modules)(dafault path if RTE_EXEC_ENV=linuxapp 
> then
>  KERNEL_DIR=/lib/modules/$(uname -r)/extra/drivers/dpdk else 
> KERNEL_DIR=/boot/modules).

Just noticed, this creates the /lib/modules structure even if there are 
no kernel modules to install. Not the end of the world of course.

> * make install-sdk (install headers, makefiles, scripts,examples, tools and
>  config files) (default path DATA_DIR=/usr/share/dpdk).
>
> * make install-fhs (install  libraries, modules, app files,
>  nic bind files and documentation).

I still think that install-fhs should include headers as well, that is 
what all normal OSS software does on "make install" anyway. Or just 
install it all (ie whole -sdk). The documentation installed with 
install-fhs includes things like the programmers guide, which is of 
little use without the sdk bits.

- Pan u-

[dpdk-dev] [PATCH] eal:Map rte cfg and uio at the end of hugepage mem

[Burakov, Anatoly]

Hi

> Problem:
> In DPDK Primary/Secondary module we assume mapping same regions of
> virtual memory addresses for Primary process and Secondary.
> An issue may occur when the Primary and secondary processes are not
> symmetric in such way that the code is not the same (for example, Primary
> process is a traffic distributer and secondary is a worker). The result may be
> that specific virtual address region in the first process won't be available 
> in
> the second process.
> 
> Changes done at eal init:
> map all related rte configuration and uio sections close to the end of huge
> pages memory (that mean rte_eal_memory_init() should be called before
> rte_config_init() in primary process)
> According to our observations there will be more probability to success when
> allocating rte_config and uio memzones after huge pages sections (actually
> uio is already allocated after the huge pages area)

Not sure I understand the purpose of the patch. Doesn't --base-virtaddr flag 
solve your issues?

Thanks,
Anatoly

[dpdk-dev] [PATCH 0/2] Provide reasonable default to -n

[Panu Matilainen]

On 10/15/2015 03:10 PM, Mcnamara, John wrote:
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Panu Matilainen
>> Sent: Thursday, October 15, 2015 12:49 PM
>> To: dev at dpdk.org
>> Subject: [dpdk-dev] [PATCH 0/2] Provide reasonable default to -n
>>
>> The number of memory channels is a truly obscure thing as a mandatory
>> command line argument when its really just an optimization.
>> Provide a reasonable default in mempool as suggested by Bruce Richardson
>> and make the -n argument optional in EAL to make DPDK that little bit
>> easier to use for a first-timer.
>
> Hi,
>
> In the Linux and FreeBSD user guides there is the following statement that 
> will
> need to change as well, either as part of this patchset, or separately:
>
>  "The -c and the -n options are mandatory; the others are optional."
>
> http://www.dpdk.org/doc/guides/linux_gsg/build_sample_apps.html#running-a-sample-application
> http://www.dpdk.org/doc/guides/freebsd_gsg/build_sample_apps.html#running-a-sample-application

Sure. I was planning on going through the docs and updating them 
(separately) if the change is otherwise accepted, I suspect there are 
more than those two places needing changes.

- Panu -

[dpdk-dev] [PATCH] eal:Map rte cfg and uio at the end of hugepage mem

[Nissim Nisimov]

Hi Anatoly,


Actually the use of --base-virtaddr will be valuable only when user know in 
advance the virtual addresses he wishes for huge pages in his application.

We found out that in some of the cases we don't know it in advance and propose 
a more generic solution which will solve the below issue without user 
interfering.

If user --base-virtaddr is not null (i.e user know the addresses he wants for 
the hugepages) our changes will be disabled and the code will act exactly as 
today without the patch.

Pls let me know if u have any more doubts.

Thx
Nissim

-Original Message-
From: Burakov, Anatoly [mailto:anatoly.bura...@intel.com] 
Sent: Thursday, October 15, 2015 3:33 PM
To: Nissim Nisimov; dev at dpdk.org
Subject: RE: [dpdk-dev] [PATCH] eal:Map rte cfg and uio at the end of hugepage 
mem

Hi

> Problem:
> In DPDK Primary/Secondary module we assume mapping same regions of 
> virtual memory addresses for Primary process and Secondary.
> An issue may occur when the Primary and secondary processes are not 
> symmetric in such way that the code is not the same (for example, 
> Primary process is a traffic distributer and secondary is a worker). 
> The result may be that specific virtual address region in the first 
> process won't be available in the second process.
> 
> Changes done at eal init:
> map all related rte configuration and uio sections close to the end of 
> huge pages memory (that mean rte_eal_memory_init() should be called 
> before
> rte_config_init() in primary process)
> According to our observations there will be more probability to 
> success when allocating rte_config and uio memzones after huge pages 
> sections (actually uio is already allocated after the huge pages area)

Not sure I understand the purpose of the patch. Doesn't --base-virtaddr flag 
solve your issues?

Thanks,
Anatoly

[dpdk-dev] Mellanox PMD failure w/DPDK-2.1.0 and MLNX_OFED-3.1-1.0.3

[Olga Shern]

Hi Bill,

Sorry it took me a while to reply ?.
We did more tests and didn?t reproduce the issue.
I also checked the code and seems that there are only 2  conditions when RD 
creation fails,

1.   The arguments we are passing to the RD creation function are wrong ? 
this is not reasonable, because this is PMD code and here the behavior is not 
deterministic , works in most cases and doesn?t work on your setup ?

2.   calloc function is failing ? also not reasonable

There is a verb  application that uses accelerated verbs and res domains, 
raw_ethernet_bw
Example:
raw_ethernet_bw -d mlx4_0  -i 1  --client -E 00:00:00:00:01:02 --use_res_domain 
--verb_type=accl

Another suggestion, can you please compile PMD with debug enabled, it may give 
more details ?

Best Regards,
Olga

From: Bill O'Hara [mailto:billtoh...@gmail.com]
Sent: Saturday, October 10, 2015 12:18 AM
To: Olga Shern 
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] Mellanox PMD failure w/DPDK-2.1.0 and 
MLNX_OFED-3.1-1.0.3

Hi Olga

Thanks for the pointer towards the use of "accelerated verbs".

Yes, SRIOV is enabled, dpdk on the hypervisor on the probed VFs. That said, it 
also fails on the underlying PF as far as I see (e.g. below the log shows (VF: 
false) for device mlx4_0 and the code fails in RD creation on this as well as 
on one of the VFs). I don't see any messages generated in dmesg that seem to 
indicate errors at any point, but extract included below.

But here's perhaps the crux! Switching off sriov and running with the new 
combination of dpdk and ofed against just a single PF also fails in exactly the 
same way (RD creation failure).

The old code continues to work. I will audit our code to make sure we're not 
missing something when using dpdk-2.1. In the meantime, do you have a minimal 
test that involves RD creation?

thanks
bill



// DPDK output for application run using dpdk-2.1 and ofed 3.1
EAL: Detected lcore 0 as core 0 on socket 0
EAL: Detected lcore 1 as core 1 on socket 0
EAL: Detected lcore 2 as core 2 on socket 0
EAL: Detected lcore 3 as core 3 on socket 0
EAL: Detected lcore 4 as core 4 on socket 0
EAL: Detected lcore 5 as core 5 on socket 0
EAL: Detected lcore 6 as core 0 on socket 0
EAL: Detected lcore 7 as core 1 on socket 0
EAL: Detected lcore 8 as core 2 on socket 0
EAL: Detected lcore 9 as core 3 on socket 0
EAL: Detected lcore 10 as core 4 on socket 0
EAL: Detected lcore 11 as core 5 on socket 0
EAL: Support maximum 128 logical core(s) by configuration.
EAL: Detected 12 lcore(s)
EAL: VFIO modules not all loaded, skip VFIO support...
EAL: Setting up physically contiguous memory...
EAL: Ask a virtual area of 0xe40 bytes
EAL: Virtual area found at 0x7fffe600 (size = 0xe40)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7fffe5c0 (size = 0x20)
EAL: Ask a virtual area of 0x7180 bytes
EAL: Virtual area found at 0x7fff7420 (size = 0x7180)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7fff73e0 (size = 0x20)
EAL: Requesting 512 pages of size 2MB from socket 0
EAL: TSC frequency is ~2394453 KHz
EAL: Master lcore 0 is ready (tid=f7fe7940;cpuset=[0])
EAL: lcore 1 is ready (tid=e53fe700;cpuset=[1])
EAL: lcore 2 is ready (tid=e4bfd700;cpuset=[2])
EAL: lcore 3 is ready (tid=e43fc700;cpuset=[3])
EAL: PCI device :01:00.0 on NUMA socket 0
EAL:   probe driver: 15b3:1003 librte_pmd_mlx4
PMD: librte_pmd_mlx4: PCI information matches, using device "mlx4_0" (VF: false)
PMD: librte_pmd_mlx4: 1 port(s) detected
PMD: librte_pmd_mlx4: port 1 MAC address is f4:52:14:8f:16:80
EAL: PCI device :01:00.1 on NUMA socket 0
EAL:   probe driver: 15b3:1004 librte_pmd_mlx4
PMD: librte_pmd_mlx4: PCI information matches, using device "mlx4_1" (VF: true)
PMD: librte_pmd_mlx4: 1 port(s) detected
PMD: librte_pmd_mlx4: port 1 MAC address is b2:00:7c:2b:3f:47
EAL: PCI device :01:00.2 on NUMA socket 0
EAL:   probe driver: 15b3:1004 librte_pmd_mlx4
PMD: librte_pmd_mlx4: PCI information matches, using device "mlx4_2" (VF: true)
PMD: librte_pmd_mlx4: 1 port(s) detected
PMD: librte_pmd_mlx4: port 1 MAC address is 3a:3d:c7:e0:ed:5a
EAL: PCI device :01:00.3 on NUMA socket 0
EAL:   probe driver: 15b3:1004 librte_pmd_mlx4
PMD: librte_pmd_mlx4: PCI information matches, using device "mlx4_3" (VF: true)
PMD: librte_pmd_mlx4: 1 port(s) detected
PMD: librte_pmd_mlx4: port 1 MAC address is ee:6a:a6:79:24:4c
EAL: PCI device :01:00.4 on NUMA socket 0
EAL:   probe driver: 15b3:1004 librte_pmd_mlx4
PMD: librte_pmd_mlx4: PCI information matches, using device "mlx4_4" (VF: true)
PMD: librte_pmd_mlx4: 1 port(s) detected
PMD: librte_pmd_mlx4: port 1 MAC address is 8a:7a:30:00:46:33
EAL: PCI device :01:00.5 on NUMA socket 0
EAL:   probe driver: 15b3:1004 librte_pmd_mlx4
PMD: librte_pmd_mlx4: cannot access device, is mlx4_ib loaded?
EAL: PCI device :01:00.6 on NUMA socket 0
EAL:   probe driver: 15b3:1004 librte_pmd_mlx4
PMD: librte_pmd_mlx4: cannot access device

[dpdk-dev] Segmentation fault when bonding ports on Mellanox ConnectX-3

[Olga Shern]

Hi Jeff,

Glad to hear that this is working for you ?
What bonding mode do you use?

There is a limitation, as you saw, we cannot  add additional MAC to the VF from 
DPDK.
You can set MAC of the VF on VM  by the same way you did on the pf.

Let me know if you have any additional questions

Best Regards,
Olga


From: Jesper Wramberg [mailto:jesper.wramb...@gmail.com]
Sent: Monday, October 12, 2015 7:03 PM
To: Olga Shern 
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] Segmentation fault when bonding ports on Mellanox 
ConnectX-3

Hi again,

The patches worked great and the DPDK bonding API functions with the ConnectX-3 
now.. yay :-)

I have run into some new trouble however and since its related I figured I 
would ask here if anyone could help. I am using SR-IOV to create a dual-port 
VF. When trying to bond the ports on this VF it seems that DPDK cannot set the 
mac address on the slaves. As a result, I am unable to receive data on the 
bonded port. As a workaround, I can set the mac address on the two VF ports 
manually in Linux using "ip link set  vf 0 mac ..." after which I 
can start DPDK and receive data on the bonded port as wanted.

Is there a way to allow DPDK to change the mac address so I avoid the 
workaround ? I have done some searching but couldn't find anything.

Regards,
Jesper Wramberg



2015-10-09 0:29 GMT+02:00 Olga Shern mailto:olgas at 
mellanox.com>>:
For the sake of clarity, I assume you mean the patches about:
"eal: new interrupt handler type"
"mlx4: handle interrupts"
[Olga ] Yes, you are right

Best Regards,
Olga

2015-10-08 17:36 GMT+02:00 Olga Shern mailto:olgas at 
mellanox.com>>:


Hi Jesper,

Bonding pmd is not supported with dpdk 2.1 on Mellanox nic
We just sent patches to support async link events. Without these patches it 
will  not work.

Best Regards
Olga
Sent from Samsung Mobile.

 Original message 
From: Jesper Wramberg
Date:08/10/2015 4:25 PM (GMT+00:00)
To: dev at dpdk.org
Subject: [dpdk-dev] Segmentation fault when bonding ports on Mellanox ConnectX-3

Hi all,

I was wondering if anyone has any experience with the ConnectX-3 card from
Mellanox ? I have a server with such a card I can't seem to get link
bonding to work.

I've installed the necessary kernel modules, etc. and the card works as
expected when testing it using e.g. the layer 2 forwarding example. If i
try to run the bond example, however, I get a segmentation fault when the
"rte_eth_bond_slave_add" function is called. Originally I wanted to bond
the ports using the EAL cmd line option but the card only has one pci
address :(

Does anyone have any idea what could be causing this behavior ?
I am running fw version 2.30.x which I have considered upgrading. Besides
this I have been wondering if I have to do anything in Linux since the PMD
uses the Linux drivers for control. I haven't been able to find any
information on it though.

Regards,
Jesper Wramberg

[dpdk-dev] [PATCH 0/2] Provide reasonable default to -n

[Mcnamara, John]

> -Original Message-
> From: Panu Matilainen [mailto:pmatilai at redhat.com]
> Sent: Thursday, October 15, 2015 1:37 PM
> To: Mcnamara, John; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 0/2] Provide reasonable default to -n
> 
> Sure. I was planning on going through the docs and updating them
> (separately) if the change is otherwise accepted, I suspect there are more
> than those two places needing changes.

Hi,

Good stuff.

I counted ~ 100 places in the docs where -n is used. I don't know if they all
have to be removed. The 2 examples I gave were the only ones that I found,
in a quick scan, that explicitly say -n is required. The rest are in the
"mostly harmless" category but if you wanted to remove the majority of the
references then that is probably okay.

John.
-- 

[dpdk-dev] [PATCH] vhost-user: enable virtio 1.0

[Michael S. Tsirkin]

On Thu, Oct 15, 2015 at 02:08:39PM +0300, Marcel Apfelbaum wrote:
> Make vhost-user virtio 1.0 compatible by adding it to the
> supported features and keeping the header length
> the same as for mergeable RX buffers.
> 
> Signed-off-by: Marcel Apfelbaum 

Looks good to me

Acked-by: Michael S. Tsirkin 

Just one question: dpdk is only supported on little-endian
platforms at the moment, right?
virtio 1 spec requires little endian.

> ---
> 
> To be applied on top of:
>[dpdk-dev] [PATCH v6 00/13] vhost-user multiple queues enabling
> 
> Thanks,
> Marcel
> 
>  lib/librte_vhost/virtio-net.c | 15 ---
>  1 file changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/lib/librte_vhost/virtio-net.c b/lib/librte_vhost/virtio-net.c
> index a51327d..ee4650e 100644
> --- a/lib/librte_vhost/virtio-net.c
> +++ b/lib/librte_vhost/virtio-net.c
> @@ -75,6 +75,7 @@ static struct virtio_net_config_ll *ll_root;
>   (1ULL << VIRTIO_NET_F_CTRL_VQ) | \
>   (1ULL << VIRTIO_NET_F_CTRL_RX) | \
>   (1ULL << VIRTIO_NET_F_MQ)  | \
> + (1ULL << VIRTIO_F_VERSION_1)   | \
>   (1ULL << VHOST_F_LOG_ALL)  | \
>   (1ULL << VHOST_USER_F_PROTOCOL_FEATURES))
>  static uint64_t VHOST_FEATURES = VHOST_SUPPORTED_FEATURES;
> @@ -477,17 +478,17 @@ set_features(struct vhost_device_ctx ctx, uint64_t *pu)
>   return -1;
>  
>   dev->features = *pu;
> - if (dev->features & (1 << VIRTIO_NET_F_MRG_RXBUF)) {
> - LOG_DEBUG(VHOST_CONFIG,
> - "(%"PRIu64") Mergeable RX buffers enabled\n",
> - dev->device_fh);
> + if (dev->features &
> + ((1 << VIRTIO_NET_F_MRG_RXBUF) | (1ULL << VIRTIO_F_VERSION_1))) {
>   vhost_hlen = sizeof(struct virtio_net_hdr_mrg_rxbuf);
>   } else {
> - LOG_DEBUG(VHOST_CONFIG,
> - "(%"PRIu64") Mergeable RX buffers disabled\n",
> - dev->device_fh);
>   vhost_hlen = sizeof(struct virtio_net_hdr);
>   }
> + LOG_DEBUG(VHOST_CONFIG,
> +  "(%"PRIu64") Mergeable RX buffers %s, virtio 1 %s\n",
> +   dev->device_fh,
> +  (dev->features & (1 << VIRTIO_NET_F_MRG_RXBUF)) ? "on" : "off",
> +  (dev->features & (1ULL << VIRTIO_F_VERSION_1)) ? "on" : "off");
>  
>   for (i = 0; i < dev->virt_qp_nb; i++) {
>   uint16_t base_idx = i * VIRTIO_QNUM;
> -- 
> 2.1.0

[dpdk-dev] Question about unsupported transceivers

[Alex Forster]

On 10/13/15, 4:34 PM, "Alexander Duyck"  wrote:

>If you are using Intel's out-of-tree ixgbe driver I believe the module
>parameters are comma separated with one index per port.  So if you have
>two ports you should be passing "allow_unsupported_sfp=1,1", and for 4
>you would need four '1's.

This seemed very promising. I compiled and installed the out of tree ixgbe
driver and set the option in /etc/modprobe.d/ixgbe.conf. dmesg shows all
eight "allow_unsupported_sfp enabled" messages but the last four ports
still error out with the unsupported SFP message when running the tests.

Before I start arbitrarily trying to patch out parts of the SFP
verification code in ixgbe, are there any other tips I should know?

Alex Forster

[dpdk-dev] Question about unsupported transceivers

[Alexander Duyck]

On 10/15/2015 07:46 AM, Alex Forster wrote:
> On 10/13/15, 4:34 PM, "Alexander Duyck"  wrote:
>
>> If you are using Intel's out-of-tree ixgbe driver I believe the module
>> parameters are comma separated with one index per port.  So if you have
>> two ports you should be passing "allow_unsupported_sfp=1,1", and for 4
>> you would need four '1's.
>
> This seemed very promising. I compiled and installed the out of tree ixgbe
> driver and set the option in /etc/modprobe.d/ixgbe.conf. dmesg shows all
> eight "allow_unsupported_sfp enabled" messages but the last four ports
> still error out with the unsupported SFP message when running the tests.
>
> Before I start arbitrarily trying to patch out parts of the SFP
> verification code in ixgbe, are there any other tips I should know?

Can you send me the command you used to load the module, and the exact 
number of ixgbe ports you have in the system?  With that I could then 
verify that the command was entered correctly as it is possible there 
could still be an issue in the way the command was entered.

One other possibility is that when the driver loads each load counts as 
an instance in the module parameter array.  So if for example you unbind 
the driver on one port and then later rebind it you will have consumed 
one of the values in the array.  Do it enough times and you exceed the 
bounds of the array as you entered it and it will simply use the default 
value of 0.

Also the output of "ethtool -i " would be useful to verify that 
you have the out-of-tree driver loaded and not the in kernel.

- Alex

[dpdk-dev] Question about unsupported transceivers

[Alex Forster]

On 10/15/15, 11:30 AM, "Alexander Duyck"  wrote:


>On 10/15/2015 07:46 AM, Alex Forster wrote:
>> On 10/13/15, 4:34 PM, "Alexander Duyck" 
>>wrote:
>>
>>> If you are using Intel's out-of-tree ixgbe driver I believe the module
>>> parameters are comma separated with one index per port.  So if you have
>>> two ports you should be passing "allow_unsupported_sfp=1,1", and for 4
>>> you would need four '1's.
>>
>> This seemed very promising. I compiled and installed the out of tree
>>ixgbe
>> driver and set the option in /etc/modprobe.d/ixgbe.conf. dmesg shows all
>> eight "allow_unsupported_sfp enabled" messages but the last four ports
>> still error out with the unsupported SFP message when running the tests.
>>
>> Before I start arbitrarily trying to patch out parts of the SFP
>> verification code in ixgbe, are there any other tips I should know?
>
>Can you send me the command you used to load the module, and the exact
>number of ixgbe ports you have in the system?  With that I could then
>verify that the command was entered correctly as it is possible there
>could still be an issue in the way the command was entered.
>
>One other possibility is that when the driver loads each load counts as
>an instance in the module parameter array.  So if for example you unbind
>the driver on one port and then later rebind it you will have consumed
>one of the values in the array.  Do it enough times and you exceed the
>bounds of the array as you entered it and it will simply use the default
>value of 0.
>
>Also the output of "ethtool -i " would be useful to verify that
>you have the out-of-tree driver loaded and not the in kernel.
>
>- Alex
>



Alex Forster

[dpdk-dev] Question about unsupported transceivers

[Alex Forster]

On 10/15/15, 11:30 AM, "Alexander Duyck"  wrote:

>On 10/15/2015 07:46 AM, Alex Forster wrote:
>> On 10/13/15, 4:34 PM, "Alexander Duyck" 
>>wrote:
>>
>>> If you are using Intel's out-of-tree ixgbe driver I believe the module
>>> parameters are comma separated with one index per port.  So if you have
>>> two ports you should be passing "allow_unsupported_sfp=1,1", and for 4
>>> you would need four '1's.
>>
>> This seemed very promising. I compiled and installed the out of tree
>>ixgbe
>> driver and set the option in /etc/modprobe.d/ixgbe.conf. dmesg shows all
>> eight "allow_unsupported_sfp enabled" messages but the last four ports
>> still error out with the unsupported SFP message when running the tests.
>>
>> Before I start arbitrarily trying to patch out parts of the SFP
>> verification code in ixgbe, are there any other tips I should know?
>
>Can you send me the command you used to load the module, and the exact
>number of ixgbe ports you have in the system?  With that I could then
>verify that the command was entered correctly as it is possible there
>could still be an issue in the way the command was entered.
>
>One other possibility is that when the driver loads each load counts as
>an instance in the module parameter array.  So if for example you unbind
>the driver on one port and then later rebind it you will have consumed
>one of the values in the array.  Do it enough times and you exceed the
>bounds of the array as you entered it and it will simply use the default
>value of 0.
>
>Also the output of "ethtool -i " would be useful to verify that
>you have the out-of-tree driver loaded and not the in kernel.
>
>- Alex
>

Er, let me try that again.

https://gist.github.com/AlexForster/f5372c5b60153d278089


Alex Forster

[dpdk-dev] [PATCH] ixgbe: prefetch packet headers in vector PMD receive function

[Ananyev, Konstantin]

> -Original Message-
> From: Zoltan Kiss [mailto:zoltan.kiss at linaro.org]
> Sent: Thursday, October 15, 2015 11:33 AM
> To: Ananyev, Konstantin; Richardson, Bruce; dev at dpdk.org
> Subject: Re: [PATCH] ixgbe: prefetch packet headers in vector PMD receive 
> function
> 
> 
> 
> On 15/10/15 00:23, Ananyev, Konstantin wrote:
> >
> >
> >> -Original Message-
> >> From: Zoltan Kiss [mailto:zoltan.kiss at linaro.org]
> >> Sent: Wednesday, October 14, 2015 5:11 PM
> >> To: Ananyev, Konstantin; Richardson, Bruce; dev at dpdk.org
> >> Subject: Re: [PATCH] ixgbe: prefetch packet headers in vector PMD receive 
> >> function
> >>
> >>
> >>
> >> On 28/09/15 00:19, Ananyev, Konstantin wrote:
> >>>
> >>>
>  -Original Message-
>  From: Zoltan Kiss [mailto:zoltan.kiss at linaro.org]
>  Sent: Friday, September 25, 2015 7:29 PM
>  To: Richardson, Bruce; dev at dpdk.org
>  Cc: Ananyev, Konstantin
>  Subject: Re: [PATCH] ixgbe: prefetch packet headers in vector PMD 
>  receive function
> 
>  On 07/09/15 07:41, Richardson, Bruce wrote:
> >
> >> -Original Message-
> >> From: Zoltan Kiss [mailto:zoltan.kiss at linaro.org]
> >> Sent: Monday, September 7, 2015 3:15 PM
> >> To: Richardson, Bruce; dev at dpdk.org
> >> Cc: Ananyev, Konstantin
> >> Subject: Re: [PATCH] ixgbe: prefetch packet headers in vector PMD 
> >> receive
> >> function
> >>
> >>
> >>
> >> On 07/09/15 13:57, Richardson, Bruce wrote:
> >>>
>  -Original Message-
>  From: Zoltan Kiss [mailto:zoltan.kiss at linaro.org]
>  Sent: Monday, September 7, 2015 1:26 PM
>  To: dev at dpdk.org
>  Cc: Ananyev, Konstantin; Richardson, Bruce
>  Subject: Re: [PATCH] ixgbe: prefetch packet headers in vector PMD
>  receive function
> 
>  Hi,
> 
>  I just realized I've missed the "[PATCH]" tag from the subject. Did
>  anyone had time to review this?
> 
> >>> Hi Zoltan,
> >>>
> >>> the big thing that concerns me with this is the addition of new
> >>> instructions for each packet in the fast path. Ideally, this
> >>> prefetching would be better handled in the application itself, as for
> >>> some apps, e.g. those using pipelining, the core doing the RX from the
> >>> NIC may not touch the packet data at all, and the prefetches will
> >> instead cause a performance slowdown.
> >>> Is it possible to get the same performance increase - or something
> >>> close to it - by making changes in OVS?
> >> OVS already does a prefetch when it's processing the previous packet, 
> >> but
> >> apparently it's not early enough. At least for my test scenario, where 
> >> I'm
> >> forwarding UDP packets with the least possible overhead. I guess in 
> >> tests
> >> where OVS does more complex processing it should be fine.
> >> I'll try to move the prefetch earlier in OVS codebase, but I'm not 
> >> sure if
> >> it'll help.
> > I would suggest trying to prefetch more than one packet ahead. 
> > Prefetching 4 or
> > 8 ahead might work better, depending on the processing being done.
> 
>  I've moved the prefetch earlier, and it seems to work:
> 
>  https://patchwork.ozlabs.org/patch/519017/
> 
>  However it raises the question: should we remove header prefetch from
>  all the other drivers, and the CONFIG_RTE_PMD_PACKET_PREFETCH option?
> >>>
> >>> My vote would be for that.
> >>> Konstantin
> >>
> >> After some further thinking I would rather support the
> >> rte_packet_prefetch() macro (prefetch the header in the driver, and
> >> configure it through CONFIG_RTE_PMD_PACKET_PREFETCH)
> >>
> >> - the prefetch can happen earlier, so if an application needs the header
> >> right away, this is the fastest
> >> - if the application doesn't need header prefetch, it can turn it off
> >> compile time. Same as if we wouldn't have this option.
> >> - if the application has mixed needs (sometimes it needs the header
> >> right away, sometimes it doesn't), it can turn it off and do what it
> >> needs. Same as if we wouldn't have this option.
> >>
> >> A harder decision would be whether it should be turned on or off by
> >> default. Currently it's on, and half of the receive functions don't use it.
> >
> > Yep,  it is sort of a mess right now.
> > Another question if we'd like to keep it and standardise it:
> > at what moment to prefetch: as soon as we realize that HW is done with that 
> > buffer,
> > or as late inside rx_burst() as possible?
> > I suppose there is no clear answer for that.
> I think if the application needs the driver start the prefetching, it
> does it because it's already too late when rte_eth_rx_burst() returns.
> So I think it's best to do it as soon as we learn that the HW is done.

Probably, but it might be situations when it would be more plau

[dpdk-dev] Question about unsupported transceivers

[Alexander Duyck]

On 10/15/2015 08:43 AM, Alex Forster wrote:
> On 10/15/15, 11:30 AM, "Alexander Duyck"  wrote:
>
>> On 10/15/2015 07:46 AM, Alex Forster wrote:
>>> On 10/13/15, 4:34 PM, "Alexander Duyck" 
>>> wrote:
>>>
 If you are using Intel's out-of-tree ixgbe driver I believe the module
 parameters are comma separated with one index per port.  So if you have
 two ports you should be passing "allow_unsupported_sfp=1,1", and for 4
 you would need four '1's.
>>>
>>> This seemed very promising. I compiled and installed the out of tree
>>> ixgbe
>>> driver and set the option in /etc/modprobe.d/ixgbe.conf. dmesg shows all
>>> eight "allow_unsupported_sfp enabled" messages but the last four ports
>>> still error out with the unsupported SFP message when running the tests.
>>>
>>> Before I start arbitrarily trying to patch out parts of the SFP
>>> verification code in ixgbe, are there any other tips I should know?
>>
>> Can you send me the command you used to load the module, and the exact
>> number of ixgbe ports you have in the system?  With that I could then
>> verify that the command was entered correctly as it is possible there
>> could still be an issue in the way the command was entered.
>>
>> One other possibility is that when the driver loads each load counts as
>> an instance in the module parameter array.  So if for example you unbind
>> the driver on one port and then later rebind it you will have consumed
>> one of the values in the array.  Do it enough times and you exceed the
>> bounds of the array as you entered it and it will simply use the default
>> value of 0.
>>
>> Also the output of "ethtool -i " would be useful to verify that
>> you have the out-of-tree driver loaded and not the in kernel.
>>
>> - Alex
>>
>
> Er, let me try that again.
>
> https://gist.github.com/AlexForster/f5372c5b60153d278089
>
>
> Alex Forster
>
>

It looks like you are probably seeing interfaces be unbound and then 
rebound.  As such you are likely pushing things outside of the array 
boundary.  One solution might just be to at more ",1"s if you are only 
going to be doing this kind of thing at boot up.  The upper limit for 
the array is 32 entries so as long as you only are setting this up once 
you could probably get away with that.

An alternative would be to modify the definition of the parameter in 
ixgbe_param.c.  If you look through the file you should fine several 
likes like below:
struct ixgbe_option opt = {
.type = enable_option,
.name = "allow_unsupported_sfp",
.err  = "defaulting to Disabled",
.def  = OPTION_DISABLED
};

If you modify the .def value to "OPTION_ENABLED", and then rebuild and 
reinstall your driver you should be able have it install without any issues.

- Alex

[dpdk-dev] [PATCH] eal: don't reset getopt lib

[Don Provan]

Looks perfect. Thanks!
-don

-Original Message-
From: Tiwei Bie [mailto:b...@mail.ustc.edu.cn] 
Sent: Thursday, October 15, 2015 4:46 AM
To: Don Provan ; bruce.richardson at intel.com; dev at 
dpdk.org
Subject: [PATCH] eal: don't reset getopt lib

Someone may need to call rte_eal_init() with a fake argc/argv array in the 
middle of using getopt() to parse its own unrelated argc/argv parameters. So 
getopt lib shouldn't be reset by rte_eal_init().

Now eal will always save optind, optarg and optopt (and optreset on
FreeBSD) at the beginning, initialize optind (and optreset on FreeBSD) to 1 
before calling getopt_long(), then restore all values after.

Suggested-by: Don Provan 
Suggested-by: Bruce Richardson 
Signed-off-by: Tiwei Bie 
---
 lib/librte_eal/bsdapp/eal/eal.c   | 59 +++--
 lib/librte_eal/linuxapp/eal/eal.c | 69 ++-
 2 files changed, 102 insertions(+), 26 deletions(-)

diff --git a/lib/librte_eal/bsdapp/eal/eal.c b/lib/librte_eal/bsdapp/eal/eal.c 
index 1b6f705..bd09377 100644
--- a/lib/librte_eal/bsdapp/eal/eal.c
+++ b/lib/librte_eal/bsdapp/eal/eal.c
@@ -312,8 +312,20 @@ eal_log_level_parse(int argc, char **argv)
int opt;
char **argvopt;
int option_index;
+   int old_optind;
+   int old_optopt;
+   int old_optreset;
+   char *old_optarg;
+
+   /* save getopt lib */
+   old_optind = optind;
+   old_optopt = optopt;
+   old_optreset = optreset;
+   old_optarg = optarg;

argvopt = argv;
+   optind = 1;
+   optreset = 1;

eal_reset_internal_config(&internal_config);

@@ -334,7 +346,11 @@ eal_log_level_parse(int argc, char **argv)
break;
}

-   optind = 0; /* reset getopt lib */
+   /* restore getopt lib */
+   optind = old_optind;
+   optopt = old_optopt;
+   optreset = old_optreset;
+   optarg = old_optarg;
 }

 /* Parse the argument given in the command line of the application */ @@ 
-345,25 +361,37 @@ eal_parse_args(int argc, char **argv)
char **argvopt;
int option_index;
char *prgname = argv[0];
+   int old_optind;
+   int old_optopt;
+   int old_optreset;
+   char *old_optarg;
+
+   /* save getopt lib */
+   old_optind = optind;
+   old_optopt = optopt;
+   old_optreset = optreset;
+   old_optarg = optarg;

argvopt = argv;
+   optind = 1;
+   optreset = 1;

while ((opt = getopt_long(argc, argvopt, eal_short_options,
  eal_long_options, &option_index)) != EOF) {

-   int ret;
-
/* getopt is not happy, stop right now */
if (opt == '?') {
eal_usage(prgname);
-   return -1;
+   ret = -1;
+   goto out;
}

ret = eal_parse_common_option(opt, optarg, &internal_config);
/* common parser is not happy */
if (ret < 0) {
eal_usage(prgname);
-   return -1;
+   ret = -1;
+   goto out;
}
/* common parser handled this option */
if (ret == 0)
@@ -387,23 +415,34 @@ eal_parse_args(int argc, char **argv)
"on FreeBSD\n", opt);
}
eal_usage(prgname);
-   return -1;
+   ret = -1;
+   goto out;
}
}

-   if (eal_adjust_config(&internal_config) != 0)
-   return -1;
+   if (eal_adjust_config(&internal_config) != 0) {
+   ret = -1;
+   goto out;
+   }

/* sanity checks */
if (eal_check_common_options(&internal_config) != 0) {
eal_usage(prgname);
-   return -1;
+   ret = -1;
+   goto out;
}

if (optind >= 0)
argv[optind-1] = prgname;
ret = optind-1;
-   optind = 0; /* reset getopt lib */
+
+out:
+   /* restore getopt lib */
+   optind = old_optind;
+   optopt = old_optopt;
+   optreset = old_optreset;
+   optarg = old_optarg;
+
return ret;
 }

diff --git a/lib/librte_eal/linuxapp/eal/eal.c 
b/lib/librte_eal/linuxapp/eal/eal.c
index 33e1067..4796030 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -505,8 +505,17 @@ eal_log_level_parse(int argc, char **argv)
int opt;
char **argvopt;
int option_index;
+   int old_optind;
+   int old_optopt;
+   char *old_optarg;
+
+   /* save getopt lib */
+   old_optind = optind;
+   old_optopt = optopt;
+   old_optarg = optarg;

argvopt = argv;
+   optind = 1;

eal_reset_internal_config(&in

[dpdk-dev] Why rte_eal_ivshmem_obj_initd() does not add memory pools to rte_mempool_tailq list?

[Mauricio Vásquez]

Dear DPDK community,

Some time ago I was trying to map a memory pool into a guest using IVSHMEM
as described here:

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

After some time I decided to review the code of eal_ivshmem.c, I noticed
that in the function rte_eal_ivshmem_obj_init the rings are added to the
rte_ring_tailq list, but for memory pools there is not a similar procedure.
My question is why it does not exist such procedure? Is there any reason or
is it just missing?

If it is just missing I could propose a implementation for it,

Thank you very much for your attention,

Mauricio V?squez

[dpdk-dev] [PATCH] add a dpdk contributors guide

[John McNamara]

Add a document to explain the DPDK patch submission and review process.

This is based on the existing information on the http://dpdk.org/dev
webpage, on the Linux kernel patch submission guidelines, and on the
existing day to day workflow on the mailing list.

This is a draft so feel free to chime in with additions and corrections.


John McNamara (1):
  doc: add contributors guide

 doc/guides/contributing/index.rst   |   1 +
 doc/guides/contributing/patches.rst | 309 
 2 files changed, 310 insertions(+)
 create mode 100644 doc/guides/contributing/patches.rst

--
1.8.1.4

[dpdk-dev] [PATCH] doc: add contributors guide

[John McNamara]

Add a document to explain the DPDK patch submission and review process.

Signed-off-by: John McNamara 
---
 doc/guides/contributing/index.rst   |   1 +
 doc/guides/contributing/patches.rst | 309 
 2 files changed, 310 insertions(+)
 create mode 100644 doc/guides/contributing/patches.rst

diff --git a/doc/guides/contributing/index.rst 
b/doc/guides/contributing/index.rst
index 561427b..f49ca88 100644
--- a/doc/guides/contributing/index.rst
+++ b/doc/guides/contributing/index.rst
@@ -9,3 +9,4 @@ Contributor's Guidelines
 design
 versioning
 documentation
+patches
diff --git a/doc/guides/contributing/patches.rst 
b/doc/guides/contributing/patches.rst
new file mode 100644
index 000..e5d28d5
--- /dev/null
+++ b/doc/guides/contributing/patches.rst
@@ -0,0 +1,309 @@
+.. submitting_patches:
+
+Contributing Code to DPDK
+=
+
+This document outlines the guidelines for submitting code to DPDK.
+
+The DPDK development process is modeled (loosely) on the Linux Kernel 
development model so it is worth reading the
+Linux kernel guide on submitting patches:
+`How to Get Your Change Into the Linux Kernel 
`_.
+The rationale for many of the DPDK guidelines is explained in greater detail 
in the kernel guidelines.
+
+
+The DPDK Development Process
+-
+
+The DPDK development process has the following features:
+
+* The code is hosted in a public git repository.
+* There is a mailing list where developers submit patches.
+* There are maintainers for hierarchical components.
+* Patches are reviewed publicly on the mailing list.
+* Successfully reviewed patches are merged to the master branch of the 
repository.
+
+The mailing list for DPDK development is `dev at dpkg.org 
`_.
+Contributors will need to `register for the mailing list 
`_ in order to submit patches.
+It is also worth registering for the DPDK `Patchwork 
`_
+
+There are also DPDK mailing lists for:
+
+* users: `general usage questions `_.
+* announce: `release announcements `_ 
(also forwarded to the dev list).
+* dts: `test suite reviews and discussions `_.
+* test-reports: `test reports `_ 
(from continuous integration testing).
+
+The development process requires some familiarity with the ``git`` version 
control system.
+Refer to the `Pro Git Book `_ for further 
information.
+
+
+Getting the Source Code
+---
+
+The source code can be cloned using either of the following::
+
+git clone git://dpdk.org/dpdk
+
+git clone http://dpdk.org/git/dpdk
+
+You can also `browse the source code `_ 
online.
+
+
+Make your Changes
+-
+
+Make your planned changes in the cloned ``dpdk`` repo. Here are some 
guidelines and requirements:
+
+* Follow the :ref:`coding_style` guidelines.
+
+* If you add new files or directories you should add your name to the 
``MAINTAINERS`` file.
+
+* If your changes add new external functions then they should be added to the 
local ``version.map`` file.
+  See the :doc:`Guidelines for ABI policy and versioning 
`.
+
+* Most changes will require an addition to the release notes in 
``doc/guides/rel_notes/``.
+  See the :ref:`Release Notes section of the Documentation Guidelines 
` for details.
+
+* Don?t break compilation between commits with forward dependencies.
+  Each commit should compile on its own to allow for ``git bisect`` and 
continuous integration testing.
+
+* Add tests to the the ``app/test`` unit test framework where possible.
+
+* Add documentation, if required, in the form of Doxygen comments or a User 
Guide in RST format.
+  See the :ref:`Documentation Guidelines `.
+
+Once the changes have been made you should commit them to your local repo.
+The commits should be separated into logical patches in a patchset.
+In general commits should be separated based on their directory such as 
``lib``, ``drivers``, ``scripts`` although
+some of these, such as ``drivers`` may require finer grained separation.
+The easiest way of determining this is to do a ``git log`` on changed or 
similar files.
+
+Example of a logical patchset separation::
+
+   [patch 1/6]ethdev: add support for ieee1588 timestamping
+   [patch 2/6]e1000: add support for ieee1588 timestamping
+   [patch 3/6]ixgbe: add support for ieee1588 timestamping
+   [patch 4/6]i40e: add support for ieee1588 timestamping
+   [patch 5/6]app/testpmd: refactor ieee1588 forwarding
+   [patch 6/6]doc: document ieee1588 forwarding mode
+
+
+The component separation will also be used in the subject line of the commit 
message,

[dpdk-dev] Question about unsupported transceivers

[Alex Forster]

On 10/15/15, 12:17 PM, "Alexander Duyck"  wrote:


>On 10/15/2015 08:43 AM, Alex Forster wrote:
>> On 10/15/15, 11:30 AM, "Alexander Duyck" 
>>wrote:
>>
>>> On 10/15/2015 07:46 AM, Alex Forster wrote:
 On 10/13/15, 4:34 PM, "Alexander Duyck" 
 wrote:

> If you are using Intel's out-of-tree ixgbe driver I believe the
>module
> parameters are comma separated with one index per port.  So if you
>have
> two ports you should be passing "allow_unsupported_sfp=1,1", and for
>4
> you would need four '1's.

 This seemed very promising. I compiled and installed the out of tree
 ixgbe
 driver and set the option in /etc/modprobe.d/ixgbe.conf. dmesg shows
all
 eight "allow_unsupported_sfp enabled" messages but the last four ports
 still error out with the unsupported SFP message when running the
tests.

 Before I start arbitrarily trying to patch out parts of the SFP
 verification code in ixgbe, are there any other tips I should know?
>>>
>>> Can you send me the command you used to load the module, and the exact
>>> number of ixgbe ports you have in the system?  With that I could then
>>> verify that the command was entered correctly as it is possible there
>>> could still be an issue in the way the command was entered.
>>>
>>> One other possibility is that when the driver loads each load counts as
>>> an instance in the module parameter array.  So if for example you
>>>unbind
>>> the driver on one port and then later rebind it you will have consumed
>>> one of the values in the array.  Do it enough times and you exceed the
>>> bounds of the array as you entered it and it will simply use the
>>>default
>>> value of 0.
>>>
>>> Also the output of "ethtool -i " would be useful to verify that
>>> you have the out-of-tree driver loaded and not the in kernel.
>>>
>>> - Alex
>>>
>>
>> Er, let me try that again.
>>
>> https://gist.github.com/AlexForster/f5372c5b60153d278089
>>
>>
>> Alex Forster
>>
>>
>
>It looks like you are probably seeing interfaces be unbound and then
>rebound.  As such you are likely pushing things outside of the array
>boundary.  One solution might just be to at more ",1"s if you are only
>going to be doing this kind of thing at boot up.  The upper limit for
>the array is 32 entries so as long as you only are setting this up once
>you could probably get away with that.
>
>An alternative would be to modify the definition of the parameter in
>ixgbe_param.c.  If you look through the file you should fine several
>likes like below:
>   struct ixgbe_option opt = {
>   .type = enable_option,
>   .name = "allow_unsupported_sfp",
>   .err  = "defaulting to Disabled",
>   .def  = OPTION_DISABLED
>   };
>
>If you modify the .def value to "OPTION_ENABLED", and then rebuild and
>reinstall your driver you should be able have it install without any
>issues.
>
>- Alex
>

Yeah, I've had roughly the same thought process since you mentioned the
args array. My first idea was "maybe the driver can't fit all of my 1's"
but I saw it was defined at 32. Then I decided to just patch the whole
enable_unsupported_sfp option out
https://gist.github.com/AlexForster/112fd822704caf804849 but I'm still
failing.

I've been digging a bit, and I'm failing here in ixgbe_main.c...

/* reset_hw fills in the perm_addr as well */
hw->phy.reset_if_overtemp = true;
err = hw->mac.ops.reset_hw(hw);
hw->phy.reset_if_overtemp = false;
if (err == IXGBE_ERR_SFP_NOT_PRESENT) {
err = IXGBE_SUCCESS;
} else if (err == IXGBE_ERR_SFP_NOT_SUPPORTED) {
e_dev_err("failed to load because an unsupported SFP+ or QSFP "
  "module type was detected.\n");
e_dev_err("Reload the driver after installing a supported "
  "module.\n");
goto err_sw_init;
} else if (err) {
e_dev_err("HW Init failed: %d\n", err);
goto err_sw_init;
}


I've attempted a hand-stacktrace and came up with the following...

ixgbe_82599.c at 1016
 * ixgbe_reset_hw_82599() is defined
 * calls phy->ops.init() which potentially returns
IXGBE_ERR_SFP_NOT_SUPPORTED

ixgbe_82599.c at 102
 * ixgbe_init_phy_ops_82599() is defined
 * IXGBE_ERR_SFP_NOT_SUPPORTED is returned after calling
phy->ops.identify()

ixgbe_82599.c at 2085
 * ixgbe_identify_phy_82599() is defined
 * calls ixgbe_identify_module_generic()

ixgbe_phy.c at 1281
 * ixgbe_identify_module_generic() is defined
 * calls ixgbe_identify_qsfp_module_generic()

ixgbe_phy.c at 1663
 * ixgbe_identify_qsfp_module_generic() is defined
 * We fail somewhere before the ending call to ixgbe_get_device_caps()
which does take allow_unsupported_sfp into account

 * Possibility: hw->phy.ops.read_i2c_eeprom(hw, IXGBE_SFF_IDENTIFIER,
&identifier) != IXGBE_SFF_IDENTIFIER_QSFP_PLUS
 * Possibility: active_cable != true

And then I'm over my head. Should I assume from here that the most likely
explanation is a 

[dpdk-dev] Question about unsupported transceivers

[Alexander Duyck]

On 10/15/2015 10:13 AM, Alex Forster wrote:
> On 10/15/15, 12:17 PM, "Alexander Duyck"  wrote:
>
>
>> On 10/15/2015 08:43 AM, Alex Forster wrote:
>>> On 10/15/15, 11:30 AM, "Alexander Duyck" 
>>> wrote:
>>>
 On 10/15/2015 07:46 AM, Alex Forster wrote:
> On 10/13/15, 4:34 PM, "Alexander Duyck" 
> wrote:
>
>> If you are using Intel's out-of-tree ixgbe driver I believe the
>> module
>> parameters are comma separated with one index per port.  So if you
>> have
>> two ports you should be passing "allow_unsupported_sfp=1,1", and for
>> 4
>> you would need four '1's.
> This seemed very promising. I compiled and installed the out of tree
> ixgbe
> driver and set the option in /etc/modprobe.d/ixgbe.conf. dmesg shows
> all
> eight "allow_unsupported_sfp enabled" messages but the last four ports
> still error out with the unsupported SFP message when running the
> tests.
>
> Before I start arbitrarily trying to patch out parts of the SFP
> verification code in ixgbe, are there any other tips I should know?
 Can you send me the command you used to load the module, and the exact
 number of ixgbe ports you have in the system?  With that I could then
 verify that the command was entered correctly as it is possible there
 could still be an issue in the way the command was entered.

 One other possibility is that when the driver loads each load counts as
 an instance in the module parameter array.  So if for example you
 unbind
 the driver on one port and then later rebind it you will have consumed
 one of the values in the array.  Do it enough times and you exceed the
 bounds of the array as you entered it and it will simply use the
 default
 value of 0.

 Also the output of "ethtool -i " would be useful to verify that
 you have the out-of-tree driver loaded and not the in kernel.

 - Alex

>>> Er, let me try that again.
>>>
>>> https://gist.github.com/AlexForster/f5372c5b60153d278089
>>>
>>>
>>> Alex Forster
>>>
>>>
>> It looks like you are probably seeing interfaces be unbound and then
>> rebound.  As such you are likely pushing things outside of the array
>> boundary.  One solution might just be to at more ",1"s if you are only
>> going to be doing this kind of thing at boot up.  The upper limit for
>> the array is 32 entries so as long as you only are setting this up once
>> you could probably get away with that.
>>
>> An alternative would be to modify the definition of the parameter in
>> ixgbe_param.c.  If you look through the file you should fine several
>> likes like below:
>>  struct ixgbe_option opt = {
>>  .type = enable_option,
>>  .name = "allow_unsupported_sfp",
>>  .err  = "defaulting to Disabled",
>>  .def  = OPTION_DISABLED
>>  };
>>
>> If you modify the .def value to "OPTION_ENABLED", and then rebuild and
>> reinstall your driver you should be able have it install without any
>> issues.
>>
>> - Alex
>>
> Yeah, I've had roughly the same thought process since you mentioned the
> args array. My first idea was "maybe the driver can't fit all of my 1's"
> but I saw it was defined at 32. Then I decided to just patch the whole
> enable_unsupported_sfp option out
> https://gist.github.com/AlexForster/112fd822704caf804849 but I'm still
> failing.

Your changes are a bit over-kill and actually take things in the wrong 
direction.  By commenting out the whole allow_unsupported_sfp block you 
are disabling it by default.  Remember the module parameter allows it, 
by removing it there is no way to enable the feature.

Like I mentioned in my previous email just take a look at replacing the 
"OPTION_DISABLED" value with "OPTION_ENABLED" in the .def part of the 
structure.  After that you won't need to pass the module parameter as it 
will always be enabled by default.

- Alex

[dpdk-dev] Question about unsupported transceivers

[Alex Forster]

On 10/15/15, 2:00 PM, "Alexander Duyck"  wrote:

>
>Your changes are a bit over-kill and actually take things in the wrong
>direction.  By commenting out the whole allow_unsupported_sfp block you
>are disabling it by default.  Remember the module parameter allows it,
>by removing it there is no way to enable the feature.
>
>Like I mentioned in my previous email just take a look at replacing the
>"OPTION_DISABLED" value with "OPTION_ENABLED" in the .def part of the
>structure.  After that you won't need to pass the module parameter as it
>will always be enabled by default.
>
>- Alex

It's hard to see in the patch, but I basically replaced that whole option
check block with:

{
/*
* allow_unsupported_sfp - Enable/Disable support for unsupported
* and untested SFP+ modules.
*/
adapter->hw.allow_unsupported_sfp = true;


}

Alex Forster

[dpdk-dev] Question about unsupported transceivers

[Alexander Duyck]

On 10/15/2015 10:13 AM, Alex Forster wrote:
> On 10/15/15, 12:17 PM, "Alexander Duyck"  wrote:
>
>
>> On 10/15/2015 08:43 AM, Alex Forster wrote:
>>> On 10/15/15, 11:30 AM, "Alexander Duyck" 
>>> wrote:
>>>
 On 10/15/2015 07:46 AM, Alex Forster wrote:
> On 10/13/15, 4:34 PM, "Alexander Duyck" 
> wrote:
>
>> If you are using Intel's out-of-tree ixgbe driver I believe the
>> module
>> parameters are comma separated with one index per port.  So if you
>> have
>> two ports you should be passing "allow_unsupported_sfp=1,1", and for
>> 4
>> you would need four '1's.
> This seemed very promising. I compiled and installed the out of tree
> ixgbe
> driver and set the option in /etc/modprobe.d/ixgbe.conf. dmesg shows
> all
> eight "allow_unsupported_sfp enabled" messages but the last four ports
> still error out with the unsupported SFP message when running the
> tests.
>
> Before I start arbitrarily trying to patch out parts of the SFP
> verification code in ixgbe, are there any other tips I should know?
 Can you send me the command you used to load the module, and the exact
 number of ixgbe ports you have in the system?  With that I could then
 verify that the command was entered correctly as it is possible there
 could still be an issue in the way the command was entered.

 One other possibility is that when the driver loads each load counts as
 an instance in the module parameter array.  So if for example you
 unbind
 the driver on one port and then later rebind it you will have consumed
 one of the values in the array.  Do it enough times and you exceed the
 bounds of the array as you entered it and it will simply use the
 default
 value of 0.

 Also the output of "ethtool -i " would be useful to verify that
 you have the out-of-tree driver loaded and not the in kernel.

 - Alex

>>> Er, let me try that again.
>>>
>>> https://gist.github.com/AlexForster/f5372c5b60153d278089
>>>
>>>
>>> Alex Forster
>>>
>>>
>> It looks like you are probably seeing interfaces be unbound and then
>> rebound.  As such you are likely pushing things outside of the array
>> boundary.  One solution might just be to at more ",1"s if you are only
>> going to be doing this kind of thing at boot up.  The upper limit for
>> the array is 32 entries so as long as you only are setting this up once
>> you could probably get away with that.
>>
>> An alternative would be to modify the definition of the parameter in
>> ixgbe_param.c.  If you look through the file you should fine several
>> likes like below:
>>  struct ixgbe_option opt = {
>>  .type = enable_option,
>>  .name = "allow_unsupported_sfp",
>>  .err  = "defaulting to Disabled",
>>  .def  = OPTION_DISABLED
>>  };
>>
>> If you modify the .def value to "OPTION_ENABLED", and then rebuild and
>> reinstall your driver you should be able have it install without any
>> issues.
>>
>> - Alex
>>
> Yeah, I've had roughly the same thought process since you mentioned the
> args array. My first idea was "maybe the driver can't fit all of my 1's"
> but I saw it was defined at 32. Then I decided to just patch the whole
> enable_unsupported_sfp option out
> https://gist.github.com/AlexForster/112fd822704caf804849 but I'm still
> failing.
>
> I've been digging a bit, and I'm failing here in ixgbe_main.c...
>
> /* reset_hw fills in the perm_addr as well */
> hw->phy.reset_if_overtemp = true;
> err = hw->mac.ops.reset_hw(hw);
> hw->phy.reset_if_overtemp = false;
> if (err == IXGBE_ERR_SFP_NOT_PRESENT) {
>   err = IXGBE_SUCCESS;
> } else if (err == IXGBE_ERR_SFP_NOT_SUPPORTED) {
>   e_dev_err("failed to load because an unsupported SFP+ or QSFP "
> "module type was detected.\n");
>   e_dev_err("Reload the driver after installing a supported "
> "module.\n");
>   goto err_sw_init;
> } else if (err) {
>   e_dev_err("HW Init failed: %d\n", err);
>   goto err_sw_init;
> }
>
>
> I've attempted a hand-stacktrace and came up with the following...
>
> ixgbe_82599.c at 1016
>   * ixgbe_reset_hw_82599() is defined
>   * calls phy->ops.init() which potentially returns
> IXGBE_ERR_SFP_NOT_SUPPORTED
>
> ixgbe_82599.c at 102
>   * ixgbe_init_phy_ops_82599() is defined
>   * IXGBE_ERR_SFP_NOT_SUPPORTED is returned after calling
> phy->ops.identify()
>
> ixgbe_82599.c at 2085
>   * ixgbe_identify_phy_82599() is defined
>   * calls ixgbe_identify_module_generic()
>
> ixgbe_phy.c at 1281
>   * ixgbe_identify_module_generic() is defined
>   * calls ixgbe_identify_qsfp_module_generic()
>
> ixgbe_phy.c at 1663
>   * ixgbe_identify_qsfp_module_generic() is defined
>   * We fail somewhere before the ending call to ixgbe_get_device_caps()
> which does take allow_unsupported_sfp into account
>
>   * Possibility: hw->phy.ops.rea

[dpdk-dev] [PATCH] doc: add contributors guide

[Thomas Monjalon]

Hi John,

2015-10-15 17:51, John McNamara:
> Add a document to explain the DPDK patch submission and review process.

Thanks

> +There are also DPDK mailing lists for:
> +
> +* users: `general usage questions `_.
> +* announce: `release announcements `_ 
> (also forwarded to the dev list).
> +* dts: `test suite reviews and discussions 
> `_.

I think these lists are not relevant for patch submission.

> +* test-reports: `test reports `_ 
> (from continuous integration testing).
[...]
> +Getting the Source Code
> +---
> +
> +The source code can be cloned using either of the following::
> +
> +git clone git://dpdk.org/dpdk
> +
> +git clone http://dpdk.org/git/dpdk
> +
> +You can also `browse the source code 
> `_ online.

The online browse doesn't help for patch contribution.

[...]
> +* If you add new files or directories you should add your name to the 
> ``MAINTAINERS`` file.

yes

> +* If your changes add new external functions then they should be added to 
> the local ``version.map`` file.
> +  See the :doc:`Guidelines for ABI policy and versioning 
> `.
> +
> +* Most changes will require an addition to the release notes in 
> ``doc/guides/rel_notes/``.
> +  See the :ref:`Release Notes section of the Documentation Guidelines 
> ` for details.

s/Most/Important/ ?

> +* Don?t break compilation between commits with forward dependencies.
> +  Each commit should compile on its own to allow for ``git bisect`` and 
> continuous integration testing.

no, please, don't break compilation :)

> +* Add tests to the the ``app/test`` unit test framework where possible.
> +
> +* Add documentation, if required, in the form of Doxygen comments or a User 
> Guide in RST format.

s/required/relevant/ ?

> +The commits should be separated into logical patches in a patchset.

Yes

> +In general commits should be separated based on their directory such as 
> ``lib``, ``drivers``, ``scripts`` although
> +some of these, such as ``drivers`` may require finer grained separation.

No. The directory is not so important.
It must be easy to review first.
If changes are not so big and do not require specific explanations,
it's better to keep things together in the same patch.
A good way of thinking about patch split is to consider backports:
will it be easy to backport this change with its dependencies?
will it be easy to backport this feature/fix without useless bloat?

> +The easiest way of determining this is to do a ``git log`` on changed or 
> similar files.

Yes

> +Example of a logical patchset separation::
> +
> +   [patch 1/6]ethdev: add support for ieee1588 timestamping
> +   [patch 2/6]e1000: add support for ieee1588 timestamping
> +   [patch 3/6]ixgbe: add support for ieee1588 timestamping
> +   [patch 4/6]i40e: add support for ieee1588 timestamping
> +   [patch 5/6]app/testpmd: refactor ieee1588 forwarding
> +   [patch 6/6]doc: document ieee1588 forwarding mode

The doc must be committed with the API change (ethdev).
Splitting driver implementations is useful only if they are really big or
require some specific explanations in the commit message.

> +* The summary line should be lowercase.

The acronyms can be uppercase.

> +  For example::
> +
> + ixgbe: fix bug in xyz

After "fix", the word "bug" is useless.
It's better to briefly explain the impact of the bug, e.g. "fix RSS on 32-bit".
So people interested in RSS or 32-bit will look at this fix.

> + ixgbe: add refcount to foo struct

Generally, using the name of a struct, a variable or a file in the title
reveals that you don't know how to explain your change simply.
The implementation details may be explained in the long message.
The title must help to catch the area and the impact of the change.

> +If you are submitting a RFC draft of a feature you can use ``[RFC]`` instead 
> of ``[PATCH]``.

A RFC may be incomplete.
It helps to have feedbacks before doing more.

> +* You must provide a body to the commit message after the subject/summary 
> line.
> +  Do not leave it blank.

When it is totally obvious, the Signed-off is enough.

> +* When fixing a regression, it is a good idea to reference the id of the 
> commit which introduced the bug.
> +  You can generate the required text as follows::
> +
> + git log -1 COMMIT_ID --abbrev=12 --format='Fixes: %h ("%s")'

git alias: fixline = log -1 --abbrev=12 --format='Fixes: %h (\"%s\")'

> + Fixes: a4024448efa6 ("i40e: add ieee1588 timestamping")

Yes it will help the backports.

> +* When fixing an error or warning it is useful to add the error message or 
> output.

The steps to reproduce the bugs are also required.

> +* ``Reported-by:`` The reporter of the issue.
> +* ``Tested-by:`` The tester of the change.
> +* ``Reviewed-by:`` The reviewer of the change.
> +* ``Su

[dpdk-dev] DPDK patch backlog

[Stephen Hemminger]

There are currently 428 patches in New state in DPDK patchwork.

Thomas, could you start reducing that backlog?
The simplest solution would be to merge some of the big patch series
from Intel for the base drivers, then reviewers can focus on the other
patches.

[dpdk-dev] [PATCH 1/4] ixgbe: 512 entries RSS table on x550

[Ananyev, Konstantin]

Hi Wenzhuo,

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wenzhuo Lu
> Sent: Monday, September 28, 2015 8:52 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 1/4] ixgbe: 512 entries RSS table on x550
> 
> Comparing with the older NICs, x550's RSS redirection table is enlarged to 512
> entries. As the original code is for the NICs which have a 128 entries RSS 
> table,
> it means only part of the RSS table is set on x550. So, RSS cannot work as
> expected on x550, it doesn't redirect the packets evenly.
> This patch configs the entries beyond 128 on x550 to let RSS work well, and 
> also
> update the query and update functions to support 512 entries.
> 
> Signed-off-by: Wenzhuo Lu 
> ---
>  drivers/net/ixgbe/ixgbe_ethdev.c | 106 
> ++-
>  drivers/net/ixgbe/ixgbe_rxtx.c   |  18 +--
>  2 files changed, 109 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c 
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index ec2918c..a1ef26f 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -2397,7 +2397,17 @@ ixgbe_dev_info_get(struct rte_eth_dev *dev, struct 
> rte_eth_dev_info *dev_info)
>   ETH_TXQ_FLAGS_NOOFFLOADS,
>   };
>   dev_info->hash_key_size = IXGBE_HKEY_MAX_INDEX * sizeof(uint32_t);
> - dev_info->reta_size = ETH_RSS_RETA_SIZE_128;
> +
> + switch (hw->mac.type) {
> + case ixgbe_mac_X550:
> + case ixgbe_mac_X550EM_x:
> + dev_info->reta_size = ETH_RSS_RETA_SIZE_512;
> + break;
> + default:
> + dev_info->reta_size = ETH_RSS_RETA_SIZE_128;
> + break;
> + }
> +

Instead of adding switch(hw->mac_type) in dozen of places, why
not to create a new function: get_reta_size(hw) and use it whenever it is 
needed?

>   dev_info->flow_type_rss_offloads = IXGBE_RSS_OFFLOAD_ALL;
>  }
> 
> @@ -3205,14 +3215,29 @@ ixgbe_dev_rss_reta_update(struct rte_eth_dev *dev,
>   struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> 
>   PMD_INIT_FUNC_TRACE();
> - if (reta_size != ETH_RSS_RETA_SIZE_128) {
> - PMD_DRV_LOG(ERR, "The size of hash lookup table configured "
> - "(%d) doesn't match the number hardware can supported "
> - "(%d)\n", reta_size, ETH_RSS_RETA_SIZE_128);
> - return -EINVAL;
> + switch (hw->mac.type) {
> + case ixgbe_mac_X550:
> + case ixgbe_mac_X550EM_x:
> + if (reta_size != ETH_RSS_RETA_SIZE_512) {
> + PMD_DRV_LOG(ERR, "The size of hash lookup table "
> + "configured (%d) doesn't match the "
> + "number hardware can supported (%d)\n",
> + reta_size, ETH_RSS_RETA_SIZE_512);
> + return -EINVAL;
> + }
> + break;
> + default:
> + if (reta_size != ETH_RSS_RETA_SIZE_128) {
> + PMD_DRV_LOG(ERR, "The size of hash lookup table "
> + "configured (%d) doesn't match the "
> + "number hardware can supported (%d)\n",
> + reta_size, ETH_RSS_RETA_SIZE_128);
> + return -EINVAL;
> + }
> + break;
>   }
> 
> - for (i = 0; i < reta_size; i += IXGBE_4_BIT_WIDTH) {
> + for (i = 0; i < ETH_RSS_RETA_SIZE_128; i += IXGBE_4_BIT_WIDTH) {
>   idx = i / RTE_RETA_GROUP_SIZE;
>   shift = i % RTE_RETA_GROUP_SIZE;
>   mask = (uint8_t)((reta_conf[idx].mask >> shift) &
> @@ -3234,6 +3259,30 @@ ixgbe_dev_rss_reta_update(struct rte_eth_dev *dev,
>   IXGBE_WRITE_REG(hw, IXGBE_RETA(i >> 2), reta);
>   }
> 
> + for (i = ETH_RSS_RETA_SIZE_128; i < reta_size; i += IXGBE_4_BIT_WIDTH) {
> + idx = i / RTE_RETA_GROUP_SIZE;
> + shift = i % RTE_RETA_GROUP_SIZE;
> + mask = (uint8_t)((reta_conf[idx].mask >> shift) &
> + IXGBE_4_BIT_MASK);
> + if (!mask)
> + continue;
> + if (mask == IXGBE_4_BIT_MASK)
> + r = 0;
> + else
> + r = IXGBE_READ_REG(hw,
> + IXGBE_ERETA((i - ETH_RSS_RETA_SIZE_128) >> 2));
> + for (j = 0, reta = 0; j < IXGBE_4_BIT_WIDTH; j++) {
> + if (mask & (0x1 << j))
> + reta |= reta_conf[idx].reta[shift + j] <<
> + (CHAR_BIT * j);
> + else
> + reta |= r & (IXGBE_8_BIT_MASK <<
> + (CHAR_BIT * j));
> + }
> + IXGBE_WRITE_REG(hw,
> +   

[dpdk-dev] [PATCH 2/4] ixgbe: VF RSS config on x550

[Ananyev, Konstantin]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wenzhuo Lu
> Sent: Monday, September 28, 2015 8:52 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 2/4] ixgbe: VF RSS config on x550
> 
> On x550, there're separate registers provided for VF RSS while on the other
> 10G NICs, for example, 82599, VF and PF share the same registers.
> This patch lets x550 use the VF specific registers when doing RSS 
> configuration
> on VF. The behavior of other 10G NICs doesn't change.
> 
> Signed-off-by: Wenzhuo Lu 
> ---
>  drivers/net/ixgbe/ixgbe_rxtx.c | 111 
> +++--
>  1 file changed, 108 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
> index a746ae7..4a2d24a 100644
> --- a/drivers/net/ixgbe/ixgbe_rxtx.c
> +++ b/drivers/net/ixgbe/ixgbe_rxtx.c
> @@ -2838,6 +2838,107 @@ ixgbe_rss_configure(struct rte_eth_dev *dev)
>   ixgbe_hw_rss_hash_set(hw, &rss_conf);
>  }
> 
> +static void
> +ixgbevf_rss_disable_x550(struct rte_eth_dev *dev)
> +{
> + struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> + uint32_t vfmrqc;
> +
> + vfmrqc = IXGBE_READ_REG(hw, IXGBE_VFMRQC);
> + vfmrqc &= ~IXGBE_MRQC_RSSEN;
> + IXGBE_WRITE_REG(hw, IXGBE_VFMRQC, vfmrqc);
> +}
> +
> +static void
> +ixgbevf_hw_rss_hash_set_x550(struct ixgbe_hw *hw,
> + struct rte_eth_rss_conf *rss_conf)
> +{
> + uint8_t  *hash_key;
> + uint32_t vfmrqc;
> + uint32_t rss_key;
> + uint64_t rss_hf;
> + uint16_t i;
> +
> + hash_key = rss_conf->rss_key;
> + if (hash_key != NULL) {
> + /* Fill in RSS hash key */
> + for (i = 0; i < 10; i++) {
> + rss_key  = hash_key[(i * 4)];
> + rss_key |= hash_key[(i * 4) + 1] << 8;
> + rss_key |= hash_key[(i * 4) + 2] << 16;
> + rss_key |= hash_key[(i * 4) + 3] << 24;
> + IXGBE_WRITE_REG_ARRAY(hw, IXGBE_VFRSSRK(0), i, rss_key);
> + }
> + }
> +
> + /* Set configured hashing protocols in VFMRQC register */
> + rss_hf = rss_conf->rss_hf;
> + vfmrqc = IXGBE_MRQC_RSSEN; /* Enable RSS */
> + if (rss_hf & ETH_RSS_IPV4)
> + vfmrqc |= IXGBE_MRQC_RSS_FIELD_IPV4;
> + if (rss_hf & ETH_RSS_NONFRAG_IPV4_TCP)
> + vfmrqc |= IXGBE_MRQC_RSS_FIELD_IPV4_TCP;
> + if (rss_hf & ETH_RSS_IPV6)
> + vfmrqc |= IXGBE_MRQC_RSS_FIELD_IPV6;
> + if (rss_hf & ETH_RSS_IPV6_EX)
> + vfmrqc |= IXGBE_MRQC_RSS_FIELD_IPV6_EX;
> + if (rss_hf & ETH_RSS_NONFRAG_IPV6_TCP)
> + vfmrqc |= IXGBE_MRQC_RSS_FIELD_IPV6_TCP;
> + if (rss_hf & ETH_RSS_IPV6_TCP_EX)
> + vfmrqc |= IXGBE_MRQC_RSS_FIELD_IPV6_EX_TCP;
> + if (rss_hf & ETH_RSS_NONFRAG_IPV4_UDP)
> + vfmrqc |= IXGBE_MRQC_RSS_FIELD_IPV4_UDP;
> + if (rss_hf & ETH_RSS_NONFRAG_IPV6_UDP)
> + vfmrqc |= IXGBE_MRQC_RSS_FIELD_IPV6_UDP;
> + if (rss_hf & ETH_RSS_IPV6_UDP_EX)
> + vfmrqc |= IXGBE_MRQC_RSS_FIELD_IPV6_EX_UDP;
> + IXGBE_WRITE_REG(hw, IXGBE_VFMRQC, vfmrqc);
> +}

This function is identical to ixgbe_hw_rss_hash_set(), except the 2 HW register 
sets it updates:
IXGBE_VFMRQC vs IXGBE_MRQC and IXGBE_VFRSSRK(0) vs IXGBE_RSSRK(0).
Plus they botha re static functions, so why not addresses of these 2 HW 
registers as extra parameters
to the ixgbe_hw_rss_hash_set() and use it in all places.
That way you'll avoid quite big code duplication.

> +
> +static void
> +ixgbevf_rss_configure_x550(struct rte_eth_dev *dev)
> +{
> + struct rte_eth_rss_conf rss_conf;
> + struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> + uint32_t reta = 0;
> + uint16_t i;
> + uint16_t j;
> +
> + PMD_INIT_FUNC_TRACE();
> +
> + if (dev->data->dev_conf.rxmode.mq_mode != ETH_MQ_RX_RSS) {
> + ixgbevf_rss_disable_x550(dev);
> + PMD_DRV_LOG(DEBUG, "RSS not configured\n");
> + return;
> + }
> + /*
> +  * Fill in redirection table
> +  * The byte-swap is needed because NIC registers are in
> +  * little-endian order.
> +  */
> + for (i = 0, j = 0; i < ETH_RSS_RETA_SIZE_64; i++, j++) {
> + if (j == dev->data->nb_rx_queues)
> + j = 0;
> + reta = (reta << 8) | j;
> + if ((i & 3) == 3)
> + IXGBE_WRITE_REG(hw, IXGBE_VFRETA(i >> 2),
> + rte_bswap32(reta));
> + }
> +
> + /*
> +  * Configure the RSS key and the RSS protocols used to compute
> +  * the RSS hash of input packets.
> +  */
> + rss_conf = dev->data->dev_conf.rx_adv_conf.rss_conf;
> + if ((rss_conf.rss_hf & IXGBE_RSS_OFFLOAD_ALL) == 0) {
> + ixgbevf_rss_disable_x550(dev);
> + return;
> + }
> + if (rss_conf.rss_key == NULL)
>

[dpdk-dev] FW: [PATCH 3/4] ixgbe: VF RSS hash query and update

[Ananyev, Konstantin]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wenzhuo Lu
> Sent: Monday, September 28, 2015 8:53 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 3/4] ixgbe: VF RSS hash query and update
> 
> This patch implements the VF RSS hash query and update function on 10G
> NICs. But the update function is only provided for x550. Because the
> other NICs don't have the separate registers for VF, we don't want to
> let a VF NIC change the shared RSS hash registers. It may cause PF and
> other VF NICs' behavior change without being noticed.
> 
> Signed-off-by: Wenzhuo Lu 
> ---
>  drivers/net/ixgbe/ixgbe_ethdev.c |  2 +
>  drivers/net/ixgbe/ixgbe_ethdev.h |  6 +++
>  drivers/net/ixgbe/ixgbe_rxtx.c   | 95 
> 
>  3 files changed, 103 insertions(+)
> 
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c 
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index a1ef26f..5e50ee6 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -497,6 +497,8 @@ static const struct eth_dev_ops ixgbevf_eth_dev_ops = {
>   .mac_addr_set = ixgbevf_set_default_mac_addr,
>   .get_reg_length   = ixgbevf_get_reg_length,
>   .get_reg  = ixgbevf_get_regs,
> + .rss_hash_update  = ixgbevf_dev_rss_hash_update,
> + .rss_hash_conf_get= ixgbevf_dev_rss_hash_conf_get,
>  };
> 
>  /* store statistics names and its offset in stats structure */
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.h 
> b/drivers/net/ixgbe/ixgbe_ethdev.h
> index c3d4f4f..30952b6 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.h
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.h
> @@ -377,6 +377,12 @@ int ixgbe_dev_rss_hash_update(struct rte_eth_dev *dev,
>  int ixgbe_dev_rss_hash_conf_get(struct rte_eth_dev *dev,
>   struct rte_eth_rss_conf *rss_conf);
> 
> +int ixgbevf_dev_rss_hash_update(struct rte_eth_dev *dev,
> + struct rte_eth_rss_conf *rss_conf);
> +
> +int ixgbevf_dev_rss_hash_conf_get(struct rte_eth_dev *dev,
> +   struct rte_eth_rss_conf *rss_conf);
> +
>  /*
>   * Flow director function prototypes
>   */
> diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
> index 4a2d24a..5b64ece 100644
> --- a/drivers/net/ixgbe/ixgbe_rxtx.c
> +++ b/drivers/net/ixgbe/ixgbe_rxtx.c
> @@ -2895,6 +2895,101 @@ ixgbevf_hw_rss_hash_set_x550(struct ixgbe_hw *hw,
>   IXGBE_WRITE_REG(hw, IXGBE_VFMRQC, vfmrqc);
>  }
> 
> +int
> +ixgbevf_dev_rss_hash_update(struct rte_eth_dev *dev,
> + struct rte_eth_rss_conf *rss_conf)
> +{
> + struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> + uint32_t vfmrqc;
> + uint64_t rss_hf;
> +
> + if (hw->mac.type != ixgbe_mac_X550_vf &&
> + hw->mac.type != ixgbe_mac_X550EM_x_vf) {
> + PMD_DRV_LOG(ERR, "RSS hash update is not supported on this "
> + "VF NIC.");
> + return -ENOTSUP;
> + }
> +
> + /*
> +  * There's hardware limitation:
> +  * "RSS enabling cannot be done dynamically while it must be
> +  *  preceded by a software reset"
> +  * Before changing anything, first check that the update RSS operation
> +  * does not attempt to disable RSS, if RSS was enabled at
> +  * initialization time, or does not attempt to enable RSS, if RSS was
> +  * disabled at initialization time.
> +  */
> + rss_hf = rss_conf->rss_hf & IXGBE_RSS_OFFLOAD_ALL;
> + vfmrqc = IXGBE_READ_REG(hw, IXGBE_VFMRQC);
> + if (!(vfmrqc & IXGBE_MRQC_RSSEN)) { /* RSS disabled */
> + if (rss_hf != 0) /* Enable RSS */
> + return -(EINVAL);
> + return 0; /* Nothing to do */
> + }
> + /* RSS enabled */
> + if (rss_hf == 0) /* Disable RSS */
> + return -(EINVAL);
> + ixgbevf_hw_rss_hash_set_x550(hw, rss_conf);
> + return 0;
> +}

Same comment as before: this function is just copy & paste 
ixgbe_dev_rss_hash_update(),
the only difference is the HW register: VFMRQC vs MRQC.
Pls unify - create a common static function that would be called by both 
ixgbe_dev_rss_hash_update()
and ixgbevf_dev_rss_hash_update(), or something. 

> +
> +int
> +ixgbevf_dev_rss_hash_conf_get(struct rte_eth_dev *dev,
> +   struct rte_eth_rss_conf *rss_conf)
> +{
> + struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> + uint8_t *hash_key;
> + uint32_t vfmrqc;
> + uint32_t rss_key;
> + uint64_t rss_hf;
> + uint16_t i;
> +
> + if (hw->mac.type != ixgbe_mac_X550_vf &&
> + hw->mac.type != ixgbe_mac_X550EM_x_vf) {
> + return ixgbe_dev_rss_hash_conf_get(dev, rss_conf);
> + }
> +
> + hash_key = rss_conf->rss_key;
> + if (hash_key != NULL) {
> + /* Return RSS hash key */
> + for (i = 0; i < 10; i++) {

[dpdk-dev] [PATCH 4/4] ixgbe: VF RSS reta query and update

[Ananyev, Konstantin]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wenzhuo Lu
> Sent: Monday, September 28, 2015 8:53 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 4/4] ixgbe: VF RSS reta query and update
> 
> This patch implements the VF RSS redirection table query and update function
> on 10G NICs. But the update function is only provided for x550. Because the
> other NICs don't have the separate registers for VF, we don't want to let a
> VF NIC change the shared RSS reta registers. It may cause PF and other VF 
> NICs'
> behavior change without being noticed.
> 
> Signed-off-by: Wenzhuo Lu 
> ---
>  drivers/net/ixgbe/ixgbe_ethdev.c | 103 
> +++
>  1 file changed, 103 insertions(+)
> 
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c 
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index 5e50ee6..44baadf 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -326,6 +326,13 @@ static int ixgbe_timesync_read_rx_timestamp(struct 
> rte_eth_dev *dev,
>  static int ixgbe_timesync_read_tx_timestamp(struct rte_eth_dev *dev,
>   struct timespec *timestamp);
> 
> +static int ixgbevf_dev_rss_reta_update(struct rte_eth_dev *dev,
> + struct rte_eth_rss_reta_entry64 *reta_conf,
> + uint16_t reta_size);
> +static int ixgbevf_dev_rss_reta_query(struct rte_eth_dev *dev,
> + struct rte_eth_rss_reta_entry64 *reta_conf,
> + uint16_t reta_size);
> +
>  /*
>   * Define VF Stats MACRO for Non "cleared on read" register
>   */
> @@ -497,6 +504,8 @@ static const struct eth_dev_ops ixgbevf_eth_dev_ops = {
>   .mac_addr_set = ixgbevf_set_default_mac_addr,
>   .get_reg_length   = ixgbevf_get_reg_length,
>   .get_reg  = ixgbevf_get_regs,
> + .reta_update  = ixgbevf_dev_rss_reta_update,
> + .reta_query   = ixgbevf_dev_rss_reta_query,
>   .rss_hash_update  = ixgbevf_dev_rss_hash_update,
>   .rss_hash_conf_get= ixgbevf_dev_rss_hash_conf_get,
>  };
> @@ -5557,6 +5566,100 @@ ixgbe_set_eeprom(struct rte_eth_dev *dev,
>   return eeprom->ops.write_buffer(hw,  first, length, data);
>  }
> 
> +static int
> +ixgbevf_dev_rss_reta_update(struct rte_eth_dev *dev,
> + struct rte_eth_rss_reta_entry64 *reta_conf,
> + uint16_t reta_size)
> +{
> + struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> + uint32_t reta, r;
> + uint16_t i, j;
> + uint16_t idx, shift;
> + uint8_t mask;
> +
> + if (hw->mac.type != ixgbe_mac_X550_vf &&
> + hw->mac.type != ixgbe_mac_X550EM_x_vf) {
> + PMD_DRV_LOG(ERR, "RSS reta update is not supported on this "
> + "VF NIC.");
> + return -ENOTSUP;
> + }
> +
> + if (reta_size != ETH_RSS_RETA_SIZE_64) {
> + PMD_DRV_LOG(ERR, "The size of hash lookup table configured "
> + "(%d) doesn't match the number of hardware can "
> + "support (%d)\n", reta_size, ETH_RSS_RETA_SIZE_64);
> + return -EINVAL;
> + }
> +
> + for (i = 0; i < reta_size; i += IXGBE_4_BIT_WIDTH) {
> + idx = i / RTE_RETA_GROUP_SIZE;
> + shift = i % RTE_RETA_GROUP_SIZE;
> + mask = (uint8_t)((reta_conf[idx].mask >> shift) &
> + IXGBE_4_BIT_WIDTH);
> + if (!mask)
> + continue;
> + if (mask == IXGBE_4_BIT_WIDTH)
> + r = 0;
> + else
> + r = IXGBE_READ_REG(hw, IXGBE_VFRETA(i >> 2));
> +
> + for (j = 0, reta = 0; j < IXGBE_4_BIT_WIDTH; j++) {
> + if (mask & (0x1 << j))
> + reta |= reta_conf[idx].reta[shift + j] <<
> + (CHAR_BIT * j);
> + else
> + reta |= r &
> + (IXGBE_8_BIT_MASK << (CHAR_BIT * j));
> + }
> + IXGBE_WRITE_REG(hw, IXGBE_VFRETA(i >> 2), reta);
> + }
> +
> + return 0;
> +}
> +
> +static int
> +ixgbevf_dev_rss_reta_query(struct rte_eth_dev *dev,
> + struct rte_eth_rss_reta_entry64 *reta_conf,
> + uint16_t reta_size)
> +{
> + struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> + uint32_t reta;
> + uint16_t i, j;
> + uint16_t idx, shift;
> + uint8_t mask;
> +
> + if (hw->mac.type != ixgbe_mac_X550_vf &&
> + hw->mac.type != ixgbe_mac_X550EM_x_vf) {
> + return ixgbe_dev_rss_reta_query(dev, reta_conf, reta_size);
> + }
> +
> + if (reta_size != ETH_RSS_RETA_SIZE_64) {
> + PMD_DRV_LOG(ERR, "The size of hash lookup table configured "
> +