[dpdk-dev] [PATCH 00/11] kill global pci device id list

[Zhang, Helin]

Hello David

Yes, long time ago, the same device IDs need to be filled in 3 or 4 places. 
Then it
would be better to have a centralized one, to avoid missing any.
And yes, it would be good to maintain device IDs per PMD.
As basically we don't expose any base driver header files, and sometimes those
device IDs need to be defined into different meanings, I'd prefer to have each
PMD has its own centralized device ID list header file, like you did for ixgbe.

Thanks a lot!

Regards,
Helin

> -Original Message-
> From: David Marchand [mailto:david.marchand at 6wind.com]
> Sent: Saturday, January 16, 2016 11:03 PM
> To: Zhang, Helin
> Cc: dev at dpdk.org; Thomas Monjalon
> Subject: Re: [dpdk-dev] [PATCH 00/11] kill global pci device id list
> 
> Hello Helin,
> 
> On Sun, Jan 10, 2016 at 4:53 PM, Zhang, Helin 
> wrote:
> > Thanks for your huge contribution!
> > May you help to describe more details of why you made these huge
> changes?
> 
> As far as I can see, the only reason why we have a centralised header
> maintained in eal with all pci device ids is the need to identify pci devices 
> that
> require a special treatment before starting a dpdk application (here, bind
> those pci devices to igb_uio / vfio).
> 
> This patchset splits this header into small pieces maintained by the drivers
> themselves, then tries to come up with a way to retrieve those pci device ids
> from the final dpdk application and from the drivers compiled as shared
> libraries.
> 
> With this, supported pci device ids are maintained by the drivers themselves
> rather than eal, pci devices ids requiring uio/vfio binding are still 
> available.
> 
> 
> Regards,
> --
> David Marchand

[dpdk-dev] L3 Forwarding performance of DPDK on virtio

[Tan, Jianfeng]

Hello!

On 1/21/2016 7:51 AM, Clarylin L wrote:
> I am running dpdk within a virtual guest as a L3 forwarder.
>
>
> The VM has two ports connecting to two linux bridges (in turn connecting
> two physical ports). DPDK is used to forward between these two ports (one
> port connected to traffic generator and the other connected to sink). I
> used iperf to test the throughput.
>
>
> If the VM/DPDK is running on passthrough, it can achieve around 10G
> end-to-end (from traffic generator to sink) throughput. However if the
> VM/DPDK is running on virtio (virtio-net-pmd), it achieves just 150M
> throughput, which is a huge degrade.
>
>
> On the virtio, I also measured the throughput between the traffic generator
> and its connected port on VM, as well as throughput between the sink and
> it's VM port. Both legs show around 7.5G throughput. So I guess forwarding
> within the VM (from one port to the other) would be a big killer of the
> performance.
>
>
> Any suggestion on how I can root cause the poor performance issue, or any
> idea on performance tuning techniques for virtio? thanks a lot!

The L3 forwarder, you mentioned, is the l3fwd example in DPDK? If so, I 
doubt it can work well with virtio, see another thread "Add API to get 
packet type info".

Thanks,
Jianfeng

[dpdk-dev] [PATCH 2/4] i40e: split function for input set change of hash and fdir

[Wu, Jingjing]

Hi, Andrey

Thanks for your comments. You are correct, I removed the I40E_INSET_FLEX_PAYLOAD
from valid fdir input set values, and this is one reason why I splited function 
for input set
change of hash and and it is because all flex payload configuration can be
set in struct rte_fdir_conf during device configure phase. And it is a more 
flexible configuration
including flexpayload's selection, input set selection by word and mask setting 
in bits.

If I enable it in the input set change API, it will be duplicate. And the input 
set change on
flexible payload only on word, just some ability compared with rte_fdir_conf.
If flexible selection isn't done in  struct rte_fdir_conf, the input set 
selection in input set change API doesn't make sense. If flexible selection is 
done in
struct rte_fdir_conf, why not selection input set in struct rte_fdir_conf at 
the same time?

And about you concern, "when application has to run on an old NIC and on a new 
one",
The rte_fdir_conf is for each eth_dev, so it will be fine.

Thanks
Jingjing  


> -Original Message-
> From: Chilikin, Andrey
> Sent: Thursday, January 21, 2016 4:05 AM
> To: Wu, Jingjing; dev at dpdk.org
> Cc: Zhang, Helin; Pei, Yulong; Ananyev, Konstantin
> Subject: RE: [PATCH 2/4] i40e: split function for input set change of hash and
> fdir
> 
> Hi Jingjing,
> 
> As I can see this patch not only splits fdir functionality from common
> fdir/hash code but also removes compatibility with DPDK 2.2 as it deletes
> I40E_INSET_FLEX_PAYLOAD from valid fdir input set values. Yes, flexible
> payload configuration can be set for fdir separately at the port 
> initialization,
> but this is more legacy from the previous generations of NICs which did not
> support dynamic input set configuration. I believe it would better to have
> I40E_INSET_FLEX_PAYLOAD valid for fdir input set same as in DPDK 2.2. So in
> legacy mode, when application has to run on an old NIC and on a new one,
> only legacy configuration would be used, but for applications targeting new
> HW single point of configuration would be used instead of mix of two.
> 
> Regards,
> Andrey
> 

[dpdk-dev] [PATCH 1/4] mem: add --single-file to create single mem-backed file

[Xie, Huawei]

On 1/11/2016 2:43 AM, Tan, Jianfeng wrote:
[snip]
> +#include 
> +#include 
> +#include 
> +#include 

Please remove unreferenced header files.

>  
>  #include 
>  #include 
> @@ -92,6 +96,9 @@
>  #include 
>  #include 
>  
> +#define _GNU_SOURCE
> +#include 
> +
>  #include "eal_private.h"

[snip]

> + char filepath[MAX_HUGEPAGE_PATH];
> +
> + syscall(SYS_getcpu, NULL, &socket_id, NULL);
> +

[snip]

>   mcfg->memseg[0].addr = addr;
> - mcfg->memseg[0].hugepage_sz = RTE_PGSIZE_4K;
> + mcfg->memseg[0].hugepage_sz = pagesize;
>   mcfg->memseg[0].len = internal_config.memory;
> - mcfg->memseg[0].socket_id = 0;
> + mcfg->memseg[0].socket_id = socket_id;

Anyway the socket_id here doesn't make sense. We could remove the
syscall which relies on _GNU_SOURCE.

[dpdk-dev] [PATCH 3/4] virtio/vdev: add ways to interact with vhost

[Xie, Huawei]

On 1/11/2016 2:43 AM, Tan, Jianfeng wrote:
> + if (hw->type == VHOST_KERNEL) {
> + struct vhost_vring_file file;
> +
> + file.fd = hw->backfd;
> + nvqs = data->nb_rx_queues + data->nb_tx_queues;
> + for (file.index = 0; file.index < nvqs; ++file.index) {
> + ret = vhost_kernel_ioctl(hw, VHOST_NET_SET_BACKEND, 
> &file);
> + if (ret < 0)
> + rte_panic("VHOST_NET_SET_BACKEND failed, %s\n",
> + strerror(errno));
> + }
> + }
> +
> + /* TODO: VHOST_SET_LOG_BASE */

We needn't support VHOST_SET_LOG_BASE.

[dpdk-dev] [PKTGEN] additional terminal IO question

[Arnon Warshavsky]

Black background gets me to the blind reset as well.
Pktgen is the only tab I keep with non black background..

On Thu, Jan 21, 2016 at 7:53 AM, Matthew Hall  wrote:

> If I try using pktgen theme mode (-T) or unmodified, without commenting
> out some of the stuff I mentioned I disabled for debugging in the previous
> thread, it seems like it sets the pktgen prompt to be invisible (black text
> on black??? or I'm not sure just want) on my TTY which has a black
> background.
>
> If you quit the app it does not reset the colors so my shell is also
> invisible, until I blindly run the reset command.
>
> Did anybody else try it on a black background? Did anybody else see these
> issues with it as well?
>
> Matthew.
>



-- 

*Arnon Warshavsky*
*Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | arnon at qwilt.com
*

[dpdk-dev] [PATCH] eal: add function to check if primary proc alive

[Qiu, Michael]

On 1/20/2016 9:26 PM, Harry van Haaren wrote:
> This patch adds a new function to the EAL API:
> int rte_eal_primary_proc_alive(const char *path);
>
> The function indicates if a primary process is alive right now.
> This functionality is implemented by testing for a write-
> lock on the config file, and the function tests for a lock.
>
> The use case for this functionality is that a secondary
> process can wait until a primary process starts by polling
> the function and waiting. When the primary is running, the
> secondary continues to poll to detect if the primary process
> has quit unexpectedly, the secondary process can detect this.
>
> The RTE_MAGIC number is written to the shared config by the
> primary process, this is the signal to the secondary process
> that the EAL is set up, and ready to be used. The function
> rte_eal_mcfg_complete() writes RTE_MAGIC. This has been
> delayed in the EAL init proceedure, as the PCI probing in
> the primary process can interfere with the secondary running.
>
> Signed-off-by: Harry van Haaren 
> ---

one question:

As we could start up many primaries, how does your secondary process
work with them?

Thanks,
Michael

[dpdk-dev] [PATCH] i40e: add VEB switching support for i40e

[Zhe Tao]

VEB switching feature for i40e is used to enable the switching between the
 VSIs connect to the virtual bridge. The old implementation is setting the
 virtual bridge mode as VEPA which is port aggregation. Enable the switching 
 ability by setting the loop back mode for the specific VSIs which connect to PF
 or VFs. 

Signed-off-by: Zhe Tao 
---
 drivers/net/i40e/i40e_ethdev.c | 48 +++---
 1 file changed, 40 insertions(+), 8 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index bf6220d..ba2ba9e 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -3822,6 +3822,39 @@ i40e_vsi_get_bw_config(struct i40e_vsi *vsi)
return I40E_SUCCESS;
 }

+/* i40e_enable_pf_lb
+ * @pf: pointer to the pf structure
+ *
+ * allow loopback on pf
+ */
+static inline void
+i40e_enable_pf_lb(struct i40e_pf *pf)
+{
+   struct i40e_hw *hw = I40E_PF_TO_HW(pf);
+   struct i40e_vsi_context ctxt;
+   int ret;
+
+   memset(&ctxt, 0, sizeof(ctxt));
+   ctxt.seid = pf->main_vsi_seid;
+   ctxt.pf_num = hw->pf_id;
+   ret = i40e_aq_get_vsi_params(hw, &ctxt, NULL);
+   if (ret) {
+   PMD_DRV_LOG(ERR, "cannot get pf vsi config, err %d, aq_err %d",
+   ret, hw->aq.asq_last_status);
+   return;
+   }
+   ctxt.flags = I40E_AQ_VSI_TYPE_PF;
+   ctxt.info.valid_sections =
+   rte_cpu_to_le_16(I40E_AQ_VSI_PROP_SWITCH_VALID);
+   ctxt.info.switch_id |=
+   rte_cpu_to_le_16(I40E_AQ_VSI_SW_ID_FLAG_ALLOW_LB);
+
+   ret = i40e_aq_update_vsi_params(hw, &ctxt, NULL);
+   if (ret)
+   PMD_DRV_LOG(ERR, "update vsi switch failed, aq_err=%d\n",
+   hw->aq.asq_last_status);
+}
+
 /* Setup a VSI */
 struct i40e_vsi *
 i40e_vsi_setup(struct i40e_pf *pf,
@@ -3857,6 +3890,8 @@ i40e_vsi_setup(struct i40e_pf *pf,
PMD_DRV_LOG(ERR, "VEB setup failed");
return NULL;
}
+   /* set ALLOWLOOPBACk on pf, when veb is created */
+   i40e_enable_pf_lb(pf);
}

vsi = rte_zmalloc("i40e_vsi", sizeof(struct i40e_vsi), 0);
@@ -4029,14 +4064,11 @@ i40e_vsi_setup(struct i40e_pf *pf,
ctxt.connection_type = 0x1;
ctxt.flags = I40E_AQ_VSI_TYPE_VF;

-   /**
-* Do not configure switch ID to enable VEB switch by
-* I40E_AQ_VSI_SW_ID_FLAG_ALLOW_LB. Because in Fortville,
-* if the source mac address of packet sent from VF is not
-* listed in the VEB's mac table, the VEB will switch the
-* packet back to the VF. Need to enable it when HW issue
-* is fixed.
-*/
+   /* Configure switch ID */
+   ctxt.info.valid_sections |=
+   rte_cpu_to_le_16(I40E_AQ_VSI_PROP_SWITCH_VALID);
+   ctxt.info.switch_id =
+   rte_cpu_to_le_16(I40E_AQ_VSI_SW_ID_FLAG_ALLOW_LB);

/* Configure port/vlan */
ctxt.info.valid_sections |=
-- 
2.1.4

[dpdk-dev] [PATCH 0/2] Add floating VEB support for i40e

[Zhe Tao]

This patch-set add the support for floating VEB in i40e.
All the VFs VSIs can decide whether to connect to the legacy VEB/VEPA or
 the floating VEB. When connect to the floating VEB a new floating VEB is
 created. Now all the VFs need to connect to floating VEB or legacy VEB,
 cannot connect to both of them. The PF and VMDQ,FD VSIs connect to
the old legacy VEB/VEPA.

Zhe Tao (2):
  support floating VEB config
  Add floating VEB support in i40e

 drivers/net/i40e/Makefile  |  2 +-
 drivers/net/i40e/i40e_ethdev.c | 92 ++
 drivers/net/i40e/i40e_ethdev.h |  3 +
 drivers/net/i40e/i40e_pf.c | 10 +++-
 lib/librte_eal/common/eal_common_options.c |  4 ++
 lib/librte_eal/common/eal_internal_cfg.h   |  1 +
 lib/librte_eal/common/eal_options.h|  2 +
 7 files changed, 86 insertions(+), 28 deletions(-)

-- 
2.1.4

[dpdk-dev] PATCH 1/2] i40e: support floating VEB config

[Zhe Tao]

Add the new floating related argument option in the EAL.
using this parameter, all the samples can decide whether to use legacy VEB/VEPA,
 or floating VEB.

Signed-off-by: Zhe Tao 
---
 lib/librte_eal/common/eal_common_options.c | 4 
 lib/librte_eal/common/eal_internal_cfg.h   | 1 +
 lib/librte_eal/common/eal_options.h| 2 ++
 3 files changed, 7 insertions(+)

diff --git a/lib/librte_eal/common/eal_common_options.c 
b/lib/librte_eal/common/eal_common_options.c
index 29942ea..29ed7bf 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -95,6 +95,7 @@ eal_long_options[] = {
{OPT_VFIO_INTR, 1, NULL, OPT_VFIO_INTR_NUM},
{OPT_VMWARE_TSC_MAP,0, NULL, OPT_VMWARE_TSC_MAP_NUM   },
{OPT_XEN_DOM0,  0, NULL, OPT_XEN_DOM0_NUM },
+   {OPT_FLOATING,  0, NULL, OPT_FLOATING_NUM },
{0, 0, NULL, 0}
 };

@@ -896,6 +897,9 @@ eal_parse_common_option(int opt, const char *optarg,
return -1;
}
break;
+   case OPT_FLOATING_NUM:
+   conf->floating = 1;
+   break;

/* don't know what to do, leave this to caller */
default:
diff --git a/lib/librte_eal/common/eal_internal_cfg.h 
b/lib/librte_eal/common/eal_internal_cfg.h
index 5f1367e..0dd303a 100644
--- a/lib/librte_eal/common/eal_internal_cfg.h
+++ b/lib/librte_eal/common/eal_internal_cfg.h
@@ -68,6 +68,7 @@ struct internal_config {
volatile unsigned xen_dom0_support; /**< support app running on Xen 
Dom0*/
volatile unsigned no_pci; /**< true to disable PCI */
volatile unsigned no_hpet;/**< true to disable HPET */
+   volatile unsigned floating;   /**< true to disable floating VEB */
volatile unsigned vmware_tsc_map; /**< true to use VMware TSC mapping

* instead of native TSC */
volatile unsigned no_shconf;  /**< true if there is no shared 
config */
diff --git a/lib/librte_eal/common/eal_options.h 
b/lib/librte_eal/common/eal_options.h
index a881c62..413c9e6 100644
--- a/lib/librte_eal/common/eal_options.h
+++ b/lib/librte_eal/common/eal_options.h
@@ -83,6 +83,8 @@ enum {
OPT_VMWARE_TSC_MAP_NUM,
 #define OPT_XEN_DOM0  "xen-dom0"
OPT_XEN_DOM0_NUM,
+#define OPT_FLOATING  "floating"
+   OPT_FLOATING_NUM,
OPT_LONG_MAX_NUM
 };

-- 
2.1.4

[dpdk-dev] [PATCH 2/2] i40e: Add floating VEB support in i40e

[Zhe Tao]

This patch add the support for floating VEB in i40e.
All the VFs VSIs can decide whether to connect to the legacy VEB/VEPA or
 the floating VEB. When connect to the floating VEB a new floating VEB is
 created. Now all the VFs need to connect to floating VEB or legacy VEB,
 cannot connect to both of them. The PF and VMDQ,FD VSIs connect to
the old legacy VEB/VEPA.

Signed-off-by: Zhe Tao 
---
 drivers/net/i40e/Makefile  |  2 +-
 drivers/net/i40e/i40e_ethdev.c | 92 ++
 drivers/net/i40e/i40e_ethdev.h |  3 ++
 drivers/net/i40e/i40e_pf.c | 10 -
 4 files changed, 79 insertions(+), 28 deletions(-)

diff --git a/drivers/net/i40e/Makefile b/drivers/net/i40e/Makefile
index 033ee4a..2e01d45 100644
--- a/drivers/net/i40e/Makefile
+++ b/drivers/net/i40e/Makefile
@@ -39,7 +39,7 @@ LIB = librte_pmd_i40e.a
 CFLAGS += -O3
 CFLAGS += $(WERROR_FLAGS) -DPF_DRIVER -DVF_DRIVER -DINTEGRATED_VF
 CFLAGS += -DX722_SUPPORT -DX722_A0_SUPPORT
-
+CFLAGS += -I$(RTE_SDK)/lib/librte_eal/common
 EXPORT_MAP := rte_pmd_i40e_version.map

 LIBABIVER := 1
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index bf6220d..b1605ca 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -3592,21 +3592,27 @@ i40e_veb_release(struct i40e_veb *veb)
struct i40e_vsi *vsi;
struct i40e_hw *hw;

-   if (veb == NULL || veb->associate_vsi == NULL)
+   if (veb == NULL)
return -EINVAL;

if (!TAILQ_EMPTY(&veb->head)) {
PMD_DRV_LOG(ERR, "VEB still has VSI attached, can't remove");
return -EACCES;
}
+   /* associate_vsi field is NULL for floating VEB */
+   if (veb->associate_vsi != NULL) {
+   vsi = veb->associate_vsi;
+   hw = I40E_VSI_TO_HW(vsi);

-   vsi = veb->associate_vsi;
-   hw = I40E_VSI_TO_HW(vsi);
+   vsi->uplink_seid = veb->uplink_seid;
+   vsi->veb = NULL;
+   } else {
+   veb->associate_pf->main_vsi->floating_veb = NULL;
+   hw = I40E_VSI_TO_HW(veb->associate_pf->main_vsi);
+   }

-   vsi->uplink_seid = veb->uplink_seid;
i40e_aq_delete_element(hw, veb->seid, NULL);
rte_free(veb);
-   vsi->veb = NULL;
return I40E_SUCCESS;
 }

@@ -3618,9 +3624,9 @@ i40e_veb_setup(struct i40e_pf *pf, struct i40e_vsi *vsi)
int ret;
struct i40e_hw *hw;

-   if (NULL == pf || vsi == NULL) {
+   if (NULL == pf) {
PMD_DRV_LOG(ERR, "veb setup failed, "
-   "associated VSI shouldn't null");
+   "associated PF shouldn't null");
return NULL;
}
hw = I40E_PF_TO_HW(pf);
@@ -3632,11 +3638,19 @@ i40e_veb_setup(struct i40e_pf *pf, struct i40e_vsi *vsi)
}

veb->associate_vsi = vsi;
+   veb->associate_pf = pf;
TAILQ_INIT(&veb->head);
-   veb->uplink_seid = vsi->uplink_seid;
+   veb->uplink_seid = vsi ? vsi->uplink_seid : 0;

-   ret = i40e_aq_add_veb(hw, veb->uplink_seid, vsi->seid,
-   I40E_DEFAULT_TCMAP, false, false, &veb->seid, NULL);
+   /* create floating veb if vsi is NULL */
+   if (vsi != NULL) {
+   ret = i40e_aq_add_veb(hw, veb->uplink_seid, vsi->seid,
+ I40E_DEFAULT_TCMAP, false, false,
+ &veb->seid, NULL);
+   } else {
+   ret = i40e_aq_add_veb(hw, 0, 0, I40E_DEFAULT_TCMAP,
+ false, false, &veb->seid, NULL);
+   }

if (ret != I40E_SUCCESS) {
PMD_DRV_LOG(ERR, "Add veb failed, aq_err: %d",
@@ -3688,20 +3702,21 @@ i40e_vsi_release(struct i40e_vsi *vsi)
i40e_veb_release(vsi->veb);
}

+   if (vsi->floating_veb) {
+   TAILQ_FOREACH(vsi_list, &vsi->floating_veb->head, list) {
+   if (i40e_vsi_release(vsi_list->vsi) != I40E_SUCCESS)
+   return -1;
+   TAILQ_REMOVE(&vsi->floating_veb->head, vsi_list, list);
+   }
+   i40e_veb_release(vsi->floating_veb);
+   }
+
/* Remove all macvlan filters of the VSI */
i40e_vsi_remove_all_macvlan_filter(vsi);
TAILQ_FOREACH(f, &vsi->mac_list, next)
rte_free(f);

if (vsi->type != I40E_VSI_MAIN) {
-   /* Remove vsi from parent's sibling list */
-   if (vsi->parent_vsi == NULL || vsi->parent_vsi->veb == NULL) {
-   PMD_DRV_LOG(ERR, "VSI's parent VSI is NULL");
-   return I40E_ERR_PARAM;
-   }
-   TAILQ_REMOVE(&vsi->parent_vsi->veb->head,
-   &vsi->sib_vsi_list, list);
-
/* Remove all switch element of the VSI */
ret = i40e_aq_delete_element(hw, vsi->seid, NULL);

[dpdk-dev] PATCH 1/2] i40e: support floating VEB config

[David Marchand]

Hello,

On Thu, Jan 21, 2016 at 8:24 AM, Zhe Tao  wrote:
> Add the new floating related argument option in the EAL.
> using this parameter, all the samples can decide whether to use legacy 
> VEB/VEPA,
>  or floating VEB.

Not familiar with this.
Can you confirm this stuff make sense for anything but i40e ?


Regards,
-- 
David Marchand

[dpdk-dev] [PATCH v2] cfgfile: support looking up sections by index

[Panu Matilainen]

On 01/19/2016 06:41 AM, Rich Lane wrote:
> This is useful when sections have duplicate names.
>
> Signed-off-by: Rich Lane 
> ---
> v1->v2:
> - Added new symbol to version script.
>
>   lib/librte_cfgfile/rte_cfgfile.c   | 16 
>   lib/librte_cfgfile/rte_cfgfile.h   | 23 +++
>   lib/librte_cfgfile/rte_cfgfile_version.map |  6 ++
>   3 files changed, 45 insertions(+)
>
> diff --git a/lib/librte_cfgfile/rte_cfgfile.c 
> b/lib/librte_cfgfile/rte_cfgfile.c
> index a677dad..0bb40a4 100644
> --- a/lib/librte_cfgfile/rte_cfgfile.c
> +++ b/lib/librte_cfgfile/rte_cfgfile.c
> @@ -333,6 +333,22 @@ rte_cfgfile_section_entries(struct rte_cfgfile *cfg, 
> const char *sectionname,
>   return i;
>   }
>
> +int
> +rte_cfgfile_section_entries_by_index(struct rte_cfgfile *cfg, int index,
> + struct rte_cfgfile_entry *entries, int max_entries)
> +{
> + int i;
> + const struct rte_cfgfile_section *sect;
> +
> + if (index >= cfg->num_sections)
> + return -1;
> +
> + sect = cfg->sections[index];

Since index is a signed int, I think you should check for < 0 as well in 
the above. Sorry for not noticing/mentioning that on the first round, I 
wasn't so much reviewing the code as just skimming through for general 
API/ABI issues.

Other than that, looks ok to me.

- Panu -

[dpdk-dev] PATCH 1/2] i40e: support floating VEB config

[Vincent JARDIN]

On 21/01/2016 08:29, David Marchand wrote:
> Hello,
>
> On Thu, Jan 21, 2016 at 8:24 AM, Zhe Tao  wrote:
>> Add the new floating related argument option in the EAL.
>> using this parameter, all the samples can decide whether to use legacy 
>> VEB/VEPA,
>>   or floating VEB.
>
> Not familiar with this.
> Can you confirm this stuff make sense for anything but i40e ?

+1 with David. On Linux kernel, only i40e includes this feature.

[dpdk-dev] [PATCH v3] Patch introducing API to read/write Intel Architecture Model Specific Registers (MSR)...

[Wojciech Andralojc]

Patch reworked.

Signed-off-by: Wojciech Andralojc 
---
 lib/librte_eal/common/include/arch/x86/rte_msr.h |  88 +
 lib/librte_eal/linuxapp/eal/Makefile |   1 +
 lib/librte_eal/linuxapp/eal/arch/x86/rte_msr.c   | 116 +++
 3 files changed, 205 insertions(+)
 create mode 100644 lib/librte_eal/common/include/arch/x86/rte_msr.h
 create mode 100644 lib/librte_eal/linuxapp/eal/arch/x86/rte_msr.c

diff --git a/lib/librte_eal/common/include/arch/x86/rte_msr.h 
b/lib/librte_eal/common/include/arch/x86/rte_msr.h
new file mode 100644
index 000..fc49107
--- /dev/null
+++ b/lib/librte_eal/common/include/arch/x86/rte_msr.h
@@ -0,0 +1,88 @@
+/*-
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2016 Intel Corporation. All rights reserved.
+ *   All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef _RTE_MSR_X86_64_H_
+#define _RTE_MSR_X86_64_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/**
+ * @file
+ *
+ * API to read/write Intel Architecture Model Specific Registers (MSR).
+ *
+ */
+
+/**
+ * Function to read CPU's MSR
+ *
+ * @param [in] cpuid
+ *  CPU logical core id
+ *
+ * @param [in] reg
+ *  MSR reg to read
+ *
+ * @param [out] value
+ *  Read value of MSR reg
+ *
+ * @return
+ *  Operations status
+*/
+extern int rte_msr_read(const unsigned cpuid, const uint32_t reg,
+   uint64_t *value);
+
+/**
+ * Function to write CPU's MSR
+ *
+ * @param [in] cpuid
+ *  CPU logical core id
+ *
+ * @param [in] reg
+ *  MSR reg to write
+ *
+ * @param [in] value
+ *  Value to be written to MSR reg
+ *
+ * @return
+ *  Operations status
+*/
+extern int rte_msr_write(const unsigned cpuid, const uint32_t reg,
+   const uint64_t value);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_MSR_X86_64_H_ */
diff --git a/lib/librte_eal/linuxapp/eal/Makefile 
b/lib/librte_eal/linuxapp/eal/Makefile
index 26eced5..4b6047f 100644
--- a/lib/librte_eal/linuxapp/eal/Makefile
+++ b/lib/librte_eal/linuxapp/eal/Makefile
@@ -68,6 +68,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) += eal_alarm.c
 ifeq ($(CONFIG_RTE_LIBRTE_IVSHMEM),y)
 SRCS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) += eal_ivshmem.c
 endif
+SRCS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) += ./arch/x86/rte_msr.c

 # from common dir
 SRCS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) += eal_common_lcore.c
diff --git a/lib/librte_eal/linuxapp/eal/arch/x86/rte_msr.c 
b/lib/librte_eal/linuxapp/eal/arch/x86/rte_msr.c
new file mode 100644
index 000..a702b6c
--- /dev/null
+++ b/lib/librte_eal/linuxapp/eal/arch/x86/rte_msr.c
@@ -0,0 +1,116 @@
+/*-
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2016 Intel Corporation. All rights reserved.
+ *   All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior writt

[dpdk-dev] [PKTGEN] fixing weird termio issues that complicate debugging

[Panu Matilainen]

On 01/20/2016 06:26 PM, Wiles, Keith wrote:
> On 1/20/16, 12:32 AM, "dev on behalf of Matthew Hall"  dpdk.org on behalf of mhall at mhcomputing.net> wrote:
>
>> Hello,
>>
>> Since the pktgen code is reindented I am finding time to read through it
>> and experiment and see if I can get it working.
>>
>> I have issues with the init process of pktgen. It is difficult to debug
>> it because the init code does a lot of very scary stuff to the terminal
>> control / TTY device at inconvenient times in an inconvenient order, and
>> in the process damages the debug output and damages the screen of your
>> GDB without doing weird things to run GDB on a different TTY.
>>
>> Of course I am willing to contribute patches and not just complain, but
>> first I need some help to follow what is going on.
>>
>> Here is the problematic call-flow with some explanation what went wrong
>> trying it on some community machines outside of its original environment:
>>
>> 1) it calls printf("\n%s %s\n", wr_copyright_msg(), wr_powered_by());
>> which dumps tons of weird boilerplate of licenses, copyrights, code
>> creator, etc.
>>
>> It is open source and everybody that matters already knows who coded it,
>> so is this stuff really that important? This gets in the way when you
>> are trying to work on it and I just have to comment it out.
>
> One problem is a number of people wanted to steal the code and use in
> a paid application, so the copyright is some what a requirement.

In that case, why is it under a BSD'ish license instead of something 
like GPL that's designed to prevent it in the first place? Might be too 
late to change it by now, just wondering.

> As you may know I do a lot of debugging on Pktgen and I feel they are
> a nuisance. I can try to see if we can clean up these messages, but
> do not hold your breath on getting them to be removed.

It would make a world of difference if it just printed the copyright etc 
in a couple of lines during startup, instead of taking over the entire 
screen for several seconds.

This is a whole lot like those anti-piracy ad campaigns on DVDs which 
you cant skip, so all the *legitimate* users are forced to suffer 
through them but all the bad guys just rip it out of their copies. DRM 
that ends up hurting the legitimate users the most is never a good idea.

- Panu -

[dpdk-dev] where to find ethernet CRC when stripping is off

[Ivan Boule]

Hi Francesco,

On 01/20/2016 06:15 PM, Montorsi, Francesco wrote:
> Hi Ivan,
>
>
>> -Original Message-
>> You would be right... if the PMDs did not transparently strip the CRC in
>> software when hardware CRC stripping is disabled at port configuration (as
>> described above).
>> See for instance how the function ixgbe_recv_pkts_lro() in file
>> drivers/net/ixgbe/ixgbe_rxtx.c deals with crc_len.
>
> Yeah, I see. However, I wonder what's the utility of the hw_strip_crc feature 
> if finally it is completely masked to the mbuf user.
> However, to my understanding, looking at that ixgbe code, I think that what I 
> wrote before:
>
> uint32_t crc = *(rte_pktmbuf_mtod_offset (mymbuf, uint32_t*, 
> mymbuf->pkt_len)) ;
>
> should work, since the pkt_len and data_len has the "crc_len" removed, but 
> the CRC itself should be there.

In most cases, yes. But not in the [rare] case where the CRC would have 
been the only data stored into the last segment of a scattered input 
packet. See how the function ixgbe_recv_pkts_lro() checks this 
particular case, and free the associated mbuf.

> I know it is kind of an hack, but at least for ixgbe that sounds like a 
> possible (temporary) solution for me
>
>
>> Considering your need, I think now that PMDs should keep the CRC that are
>> stored in received packets when hardware CRC stripping is disabled by the
>> application, so that the application can access it as needed.
>>
> Yes, that would be very useful.
>
>> Note that this would impose that the input packet processing of such DPDK
>> applications be aware of the CRC presence (+4 in the packet length , for
>> instance).
> Or perhaps, to maintain backward compatibility, just a flag inside the mbuf 
> could be set that informs the user that at the end of the mbuf packet, you 
> can find 4 bytes with the CRC.
>
>>
>> Let's see what others, if any, that might care think about such a change into
>> the CRC stripping semantics.
>
> Thanks!
> Francesco
>


-- 
Ivan Boule
6WIND Development Engineer

[dpdk-dev] [PATCH] eal: add function to check if primary proc alive

[Van Haaren, Harry]

> From: Qiu, Michael
> Sent: Thursday, January 21, 2016 6:14 AM
> To: Van Haaren, Harry ; david.marchand at 
> 6wind.com
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] eal: add function to check if primary proc 
> alive
> 
> As we could start up many primaries, how does your secondary process
> work with them?

When a primary process initializes, the location of the config file is 
important. The default is /var/run/.rte_config

To run multiple primary processes, the --file-prefix= option is used to 
specific a custom location for the config file. Eg: --file-prefix=testing
/var/run/.testing_config

The rte_eal_check_primary_alive(const char*) function takes a char* parameter - 
this is the location of the config file that the secondary process will wait 
for. Setting it to the correct value will make this secondary process wait for 
the corresponding primary process.

Regards, -Harry

[dpdk-dev] [PATCH v3] Patch introducing API to read/write Intel Architecture Model Specific Registers (MSR)...

[Thomas Monjalon]

Hi,

2016-01-21 08:18, Wojciech Andralojc:
> Patch reworked.
> 
> Signed-off-by: Wojciech Andralojc 

It cannot be applied without a proper commit log.

Please reword also the title to make it shorter and similar to
what you can find in the git history.
You can find some help in the doc:

http://dpdk.org/doc/guides/contributing/patches.html#commit-messages-subject-line

[dpdk-dev] [PATCH v5 02/11] linuxapp: eal: arm: Always return 0 for rte_eal_iopl_init()

[David Marchand]

Hello Santosh,

On Tue, Jan 19, 2016 at 12:46 PM, Santosh Shukla  wrote:
> iopl() syscall not supported in linux-arm/arm64 so always return 0 value.
>
> Signed-off-by: Santosh Shukla 
> Acked-by: Jan Viktorin 
> Suggested-by: Stephen Hemminger 

I suppose when we will have more arches, this can be rewritten so that
iopl() check is only applied to x86 and all other arches get a 0
return.

How about such commit title ?
"eal/linux: never check iopl for arm"


Regards,
-- 
David Marchand

[dpdk-dev] [PATCH v5 05/11] eal: pci: vfio: add rd/wr func for pci bar space

[David Marchand]

Santosh,

On Tue, Jan 19, 2016 at 12:46 PM, Santosh Shukla  wrote:
> Introducing below api for pci bar space rd/wr. Currently used for
> pci iobar rd/wr.
>
> Api's are:
> - rte_eal_pci_read_bar
> - rte_eal_pci_write_bar
>
> virtio when used for vfio-mode then virtio driver will use these api
> to do rd/wr operation on ioport pci bar.
>
> Signed-off-by: Santosh Shukla 
> ---
> v4--> v5:
> - added switch case in rd/wr pci_bar routine, as per Yuan comment
>
>  lib/librte_eal/common/include/rte_pci.h|   38 
> 
>  lib/librte_eal/linuxapp/eal/eal_pci.c  |   34 +
>  lib/librte_eal/linuxapp/eal/eal_pci_init.h |6 +
>  lib/librte_eal/linuxapp/eal/eal_pci_vfio.c |   28 
>  4 files changed, 106 insertions(+)

- What about BSD ?
Empty stub ?

- Those are new symbols, you must update rte_eal_version.map.


Regards,
-- 
David Marchand

[dpdk-dev] [PATCH 3/3] keepalive: add rte_keepalive_xstats() and example

[Remy Horton]

Morning,

On 20/01/2016 15:53, Harry van Haaren wrote:
> This patch adds a function that exposes keepalive statistics
> re-using the existing rte_eth_xstats struct. The function provides
> the client API the opportunity to read last-seen and status of
> each core.
>
> Signed-off-by: Harry van Haaren 
  ...
>   #include 
>   #include 
>   #include 
> +#include 
> +
> +#define RTE_KEEPALIVE_NSTATS 2

Tried building this and am getting the following error:

== Build lib/librte_eal/linuxapp/eal
   CC rte_keepalive.o
/local/rhorton/dpdk-test/lib/librte_eal/common/rte_keepalive.c:42:24: 
fatal error: rte_ethdev.h: No such file or directory
compilation terminated.

If I remember correctly, there are limitations on the libs using each 
others' header files..


..Remy

[dpdk-dev] [PATCH v5 02/11] linuxapp: eal: arm: Always return 0 for rte_eal_iopl_init()

[Santosh Shukla]

On Thu, Jan 21, 2016 at 3:11 PM, David Marchand 
wrote:

> Hello Santosh,
>
> On Tue, Jan 19, 2016 at 12:46 PM, Santosh Shukla 
> wrote:
> > iopl() syscall not supported in linux-arm/arm64 so always return 0 value.
> >
> > Signed-off-by: Santosh Shukla 
> > Acked-by: Jan Viktorin 
> > Suggested-by: Stephen Hemminger 
>
> I suppose when we will have more arches, this can be rewritten so that
> iopl() check is only applied to x86 and all other arches get a 0
> return.
>
>
Thats correct. And which is why I am holding my other patchset which
actually move rte_eal_xx_iopl() stuff into arch specifics. I don't wanted
to mix two topic in this series. Waiting for this series to get merged then
abstract things like, iopl() and move "sys/io.h" in arch specifics and get
rid of few ifdef X86 clutter across dpdk code.


> How about such commit title ?
> "eal/linux: never check iopl for arm"
>

even better, sending v6 change for this patch now, Thanks!

>
>
> Regards,
> --
> David Marchand
>

[dpdk-dev] [PATCH v5 05/11] eal: pci: vfio: add rd/wr func for pci bar space

[Santosh Shukla]

On Thu, Jan 21, 2016 at 3:12 PM, David Marchand
 wrote:
> Santosh,
>
> On Tue, Jan 19, 2016 at 12:46 PM, Santosh Shukla  
> wrote:
>> Introducing below api for pci bar space rd/wr. Currently used for
>> pci iobar rd/wr.
>>
>> Api's are:
>> - rte_eal_pci_read_bar
>> - rte_eal_pci_write_bar
>>
>> virtio when used for vfio-mode then virtio driver will use these api
>> to do rd/wr operation on ioport pci bar.
>>
>> Signed-off-by: Santosh Shukla 
>> ---
>> v4--> v5:
>> - added switch case in rd/wr pci_bar routine, as per Yuan comment
>>
>>  lib/librte_eal/common/include/rte_pci.h|   38 
>> 
>>  lib/librte_eal/linuxapp/eal/eal_pci.c  |   34 +
>>  lib/librte_eal/linuxapp/eal/eal_pci_init.h |6 +
>>  lib/librte_eal/linuxapp/eal/eal_pci_vfio.c |   28 
>>  4 files changed, 106 insertions(+)
>
> - What about BSD ?
> Empty stub ?
>
> - Those are new symbols, you must update rte_eal_version.map.
>
>

for both, agreed. Sending v6 for this patch now, Thanks!
> Regards,
> --
> David Marchand

[dpdk-dev] [PATCH v6 02/11] eal/linux: never check iopl for arm

[Santosh Shukla]

iopl() syscall not supported in linux-arm/arm64 so always return 0 value.

Signed-off-by: Santosh Shukla 
Acked-by: Jan Viktorin 
Suggested-by: Stephen Hemminger 
---

v5 --> v5:
- Renamed patch titled from "linuxapp: eal: arm: Always return 0 for
  rte_eal_iopl_init()" to current, Suggested by David.
  v5 patch was this[1]
 [1] http://dpdk.org/dev/patchwork/patch/9978/

 lib/librte_eal/linuxapp/eal/eal.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/librte_eal/linuxapp/eal/eal.c 
b/lib/librte_eal/linuxapp/eal/eal.c
index 635ec36..a2a3485 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -715,6 +715,8 @@ rte_eal_iopl_init(void)
if (iopl(3) != 0)
return -1;
return 0;
+#elif defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64)
+   return 0; /* iopl syscall not supported for ARM/ARM64 */
 #else
return -1;
 #endif
-- 
1.7.9.5

[dpdk-dev] [PATCH v6 05/11] eal: pci: vfio: add rd/wr func for pci bar space

[Santosh Shukla]

Introducing below api for pci bar space rd/wr. Currently used for
pci iobar rd/wr.

Api's are:
- rte_eal_pci_read_bar
- rte_eal_pci_write_bar

virtio when used for vfio-mode then virtio driver will use these api
to do rd/wr operation on ioport pci bar.

Signed-off-by: Santosh Shukla 
---
v5-->v6:
- included dummy implementation for rte_eal_pci_read/write_bar() api in bsdapp.
- Added api entry in rte_eal_version.map

 lib/librte_eal/bsdapp/eal/eal_pci.c |   19 
 lib/librte_eal/bsdapp/eal/rte_eal_version.map   |3 ++
 lib/librte_eal/common/include/rte_pci.h |   38 +++
 lib/librte_eal/linuxapp/eal/eal_pci.c   |   34 
 lib/librte_eal/linuxapp/eal/eal_pci_init.h  |6 
 lib/librte_eal/linuxapp/eal/eal_pci_vfio.c  |   28 +
 lib/librte_eal/linuxapp/eal/rte_eal_version.map |3 ++
 7 files changed, 131 insertions(+)

diff --git a/lib/librte_eal/bsdapp/eal/eal_pci.c 
b/lib/librte_eal/bsdapp/eal/eal_pci.c
index 95c32c1..2e535ea 100644
--- a/lib/librte_eal/bsdapp/eal/eal_pci.c
+++ b/lib/librte_eal/bsdapp/eal/eal_pci.c
@@ -479,6 +479,25 @@ int rte_eal_pci_write_config(const struct rte_pci_device 
*dev,
return -1;
 }

+int rte_eal_pci_read_bar(const struct rte_pci_device *device __rte_unused,
+void *buf __rte_unused, size_t len __rte_unused,
+off_t offset __rte_unused,
+int bar_idx __rte_unused)
+
+{
+   /* NA */
+   return 1;
+}
+
+int rte_eal_pci_write_bar(const struct rte_pci_device *device __rte_unused,
+ const void *buf __rte_unused, size_t len __rte_unused,
+ off_t offset __rte_unused,
+ int bar_idx __rte_unused)
+{
+   /* NA */
+   return 1;
+}
+
 /* Init the PCI EAL subsystem */
 int
 rte_eal_pci_init(void)
diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map 
b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
index 1b28170..7c7dcf0 100644
--- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
@@ -141,4 +141,7 @@ DPDK_2.3 {

rte_eal_pci_map_device;
rte_eal_pci_unmap_device;
+   rte_eal_pci_read_bar;
+   rte_eal_pci_write_bar;
+
 } DPDK_2.2;
diff --git a/lib/librte_eal/common/include/rte_pci.h 
b/lib/librte_eal/common/include/rte_pci.h
index 2224109..0c667ff 100644
--- a/lib/librte_eal/common/include/rte_pci.h
+++ b/lib/librte_eal/common/include/rte_pci.h
@@ -471,6 +471,44 @@ int rte_eal_pci_read_config(const struct rte_pci_device 
*device,
void *buf, size_t len, off_t offset);

 /**
+ * Read PCI bar space.
+ *
+ * @param device
+ *   A pointer to a rte_pci_device structure describing the device
+ *   to use
+ * @param buf
+ *   A data buffer where the bytes should be read into
+ * @param len
+ *   The length of the data buffer.
+ * @param offset
+ *   The offset into PCI bar space
+ * @param bar_idx
+ *   The pci bar index (valid range is 0..5)
+ */
+int rte_eal_pci_read_bar(const struct rte_pci_device *device,
+void *buf, size_t len, off_t offset, int bar_idx);
+
+/**
+ * Write PCI bar space.
+ *
+ * @param device
+ *   A pointer to a rte_pci_device structure describing the device
+ *   to use
+ * @param buf
+ *   A data buffer containing the bytes should be written
+ * @param len
+ *   The length of the data buffer.
+ * @param offset
+ *   The offset into PCI config space
+ * @param bar_idx
+ *   The pci bar index (valid range is 0..5)
+*/
+int rte_eal_pci_write_bar(const struct rte_pci_device *device,
+ const void *buf, size_t len, off_t offset,
+ int bar_idx);
+
+
+/**
  * Write PCI config space.
  *
  * @param device
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c 
b/lib/librte_eal/linuxapp/eal/eal_pci.c
index db947da..eb503f0 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
@@ -621,6 +621,40 @@ int rte_eal_pci_write_config(const struct rte_pci_device 
*device,
}
 }

+int rte_eal_pci_read_bar(const struct rte_pci_device *device,
+void *buf, size_t len, off_t offset,
+int bar_idx)
+
+{
+   const struct rte_intr_handle *intr_handle = &device->intr_handle;
+
+   switch (device->kdrv) {
+   case RTE_KDRV_VFIO:
+   return pci_vfio_read_bar(intr_handle, buf, len,
+offset, bar_idx);
+   default:
+   RTE_LOG(ERR, EAL, "write bar not supported by driver\n");
+   return -1;
+   }
+}
+
+int rte_eal_pci_write_bar(const struct rte_pci_device *device,
+ const void *buf, size_t len, off_t offset,
+ int bar_idx)
+{
+
+   const struct rte_intr_handle *intr_handle = &device->intr_handle;
+
+   switch (device->kdrv) {
+   

[dpdk-dev] [PATCH v6 02/11] eal/linux: never check iopl for arm

[David Marchand]

On Thu, Jan 21, 2016 at 11:26 AM, Santosh Shukla  wrote:
> iopl() syscall not supported in linux-arm/arm64 so always return 0 value.
>
> Signed-off-by: Santosh Shukla 
> Acked-by: Jan Viktorin 
> Suggested-by: Stephen Hemminger 

Acked-by: David Marchand 

-- 
David Marchand

[dpdk-dev] [PATCH v6 08/11] eal: pci: introduce RTE_KDRV_VFIO_NOIOMMUi driver mode

[David Marchand]

Santosh,

On Tue, Jan 19, 2016 at 7:57 PM, Santosh Shukla  wrote:
> Adding RTE_KDRV_VFIO_NOIOMMU mode in kernel driver. Also including
> rte_vfio_is_noiommu() helper function. This function will parse
> /sys/bus/pci/device// and make sure that
> - vfio noiommu mode set in kernel driver
> - pci device attached to vfio-noiommu driver only
>
> If both condition satisfies then set drv->kdrv = RTE_KDRV_VFIO_NOIOMMU
>
> Also did similar changes in virtio_rd/wr, Changes applicable for virtio spec
> 0.95 only.

This is a mode (specific to vfio), not a new kernel driver.

How come we need to distinguish between with/without iommu modes ?
Should not vfio behave the same way from an api point of view ?


Regards,
-- 
David Marchand

[dpdk-dev] [PATCH 00/16] fm10k: update shared code from ND team

[Wang Xiao W]

This shared code update patch set has passed the regression test.

Wang Xiao W (16):
  fm10k/base: cleanup namespace pollution and correct typecast
  fm10k/base: use bitshift for itr_scale
  fm10k/base: reset max_queues on init_hw_vf failure
  fm10k/base: document ITR scale workaround in VF TDLEN register
  fm10k/base: fix checkpatch warning
  fm10k/base: use BIT macro instead of open-coded bit-shifting of 1
  fm10k/base: do not use CamelCase
  fm10k/base: use memcpy for mac addr copy
  fm10k/base: allow removal of is_slot_appropriate function
  fm10k/base: consistently use VLAN ID when referencing vid variables
  fm10k/base: fix comment per upstream review changes
  fm10k/base: TLV structures must be 4byte aligned, not 1byte aligned
  fm10k/base: move constants to the right of binary operators
  fm10k/base: minor cleanups
  fm10k: use default mailbox message handler for pf
  fm10k/base: add macro definitions that are needed

 drivers/net/fm10k/base/fm10k_api.c   |   2 +
 drivers/net/fm10k/base/fm10k_api.h   |   2 +
 drivers/net/fm10k/base/fm10k_mbx.c   |  63 +++-
 drivers/net/fm10k/base/fm10k_mbx.h   |  11 +--
 drivers/net/fm10k/base/fm10k_osdep.h |  30 ++
 drivers/net/fm10k/base/fm10k_pf.c|  88 +
 drivers/net/fm10k/base/fm10k_pf.h|  18 ++--
 drivers/net/fm10k/base/fm10k_tlv.c   |  40 
 drivers/net/fm10k/base/fm10k_tlv.h   |   9 +-
 drivers/net/fm10k/base/fm10k_type.h  | 182 +++
 drivers/net/fm10k/base/fm10k_vf.c|  32 --
 drivers/net/fm10k/fm10k_ethdev.c |  41 +++-
 12 files changed, 220 insertions(+), 298 deletions(-)

-- 
1.9.3

[dpdk-dev] [PATCH 01/16] fm10k/base: cleanup namespace pollution and correct typecast

[Wang Xiao W]

Correct typecast in fm10k_update_xc_addr_pf.

Make functions that are only referenced locally static.

And fix the function header comment for fm10k_tlv_attr_nest_stop() while
we're at it.

Wrap fm10k_msg_data fm10k_iov_msg_data_pf[] in the new ifndef
NO_DEFAULT_SRIOV_MSG_HANDLERS so that drivers with custom SR-IOV
message handlers can strip it.

remove unused struct element in struct fm10k_mac_ops.

Signed-off-by: Wang Xiao W 
---
 drivers/net/fm10k/base/fm10k_pf.c   | 10 ++
 drivers/net/fm10k/base/fm10k_pf.h   |  4 ++--
 drivers/net/fm10k/base/fm10k_tlv.c  | 16 
 drivers/net/fm10k/base/fm10k_tlv.h  |  5 -
 drivers/net/fm10k/base/fm10k_type.h |  1 -
 drivers/net/fm10k/base/fm10k_vf.c   |  2 --
 6 files changed, 16 insertions(+), 22 deletions(-)

diff --git a/drivers/net/fm10k/base/fm10k_pf.c 
b/drivers/net/fm10k/base/fm10k_pf.c
index 6e6d71e..5b8c039 100644
--- a/drivers/net/fm10k/base/fm10k_pf.c
+++ b/drivers/net/fm10k/base/fm10k_pf.c
@@ -379,8 +379,8 @@ STATIC s32 fm10k_update_xc_addr_pf(struct fm10k_hw *hw, u16 
glort,
 ((u32)mac[3] << 16) |
 ((u32)mac[4] << 8) |
 ((u32)mac[5]));
-   mac_update.mac_upper = FM10K_CPU_TO_LE16(((u32)mac[0] << 8) |
-((u32)mac[1]));
+   mac_update.mac_upper = FM10K_CPU_TO_LE16(((u16)mac[0] << 8) |
+  ((u16)mac[1]));
mac_update.vlan = FM10K_CPU_TO_LE16(vid);
mac_update.glort = FM10K_CPU_TO_LE16(glort);
mac_update.action = add ? 0 : 1;
@@ -1457,6 +1457,7 @@ s32 fm10k_iov_msg_lport_state_pf(struct fm10k_hw *hw, u32 
**results,
return err;
 }

+#ifndef NO_DEFAULT_SRIOV_MSG_HANDLERS
 const struct fm10k_msg_data fm10k_iov_msg_data_pf[] = {
FM10K_TLV_MSG_TEST_HANDLER(fm10k_tlv_msg_test),
FM10K_VF_MSG_MSIX_HANDLER(fm10k_iov_msg_msix_pf),
@@ -1465,6 +1466,7 @@ const struct fm10k_msg_data fm10k_iov_msg_data_pf[] = {
FM10K_TLV_MSG_ERROR_HANDLER(fm10k_tlv_msg_error),
 };

+#endif
 /**
  *  fm10k_update_stats_hw_pf - Updates hardware related statistics of PF
  *  @hw: pointer to hardware structure
@@ -1754,8 +1756,8 @@ const struct fm10k_tlv_attr fm10k_update_pvid_msg_attr[] 
= {
  *
  *  This handler configures the default VLAN for the PF
  **/
-s32 fm10k_msg_update_pvid_pf(struct fm10k_hw *hw, u32 **results,
-struct fm10k_mbx_info *mbx)
+static s32 fm10k_msg_update_pvid_pf(struct fm10k_hw *hw, u32 **results,
+   struct fm10k_mbx_info *mbx)
 {
u16 glort, pvid;
u32 pvid_update;
diff --git a/drivers/net/fm10k/base/fm10k_pf.h 
b/drivers/net/fm10k/base/fm10k_pf.h
index 44bd193..92e2962 100644
--- a/drivers/net/fm10k/base/fm10k_pf.h
+++ b/drivers/net/fm10k/base/fm10k_pf.h
@@ -149,8 +149,6 @@ extern const struct fm10k_tlv_attr 
fm10k_lport_map_msg_attr[];
 #define FM10K_PF_MSG_LPORT_MAP_HANDLER(func) \
FM10K_MSG_HANDLER(FM10K_PF_MSG_ID_LPORT_MAP, \
  fm10k_lport_map_msg_attr, func)
-s32 fm10k_msg_update_pvid_pf(struct fm10k_hw *, u32 **,
-struct fm10k_mbx_info *);
 extern const struct fm10k_tlv_attr fm10k_update_pvid_msg_attr[];
 #define FM10K_PF_MSG_UPDATE_PVID_HANDLER(func) \
FM10K_MSG_HANDLER(FM10K_PF_MSG_ID_UPDATE_PVID, \
@@ -183,7 +181,9 @@ s32 fm10k_iov_msg_mac_vlan_pf(struct fm10k_hw *, u32 **,
  struct fm10k_mbx_info *);
 s32 fm10k_iov_msg_lport_state_pf(struct fm10k_hw *, u32 **,
 struct fm10k_mbx_info *);
+#ifndef NO_DEFAULT_SRIOV_MSG_HANDLERS
 extern const struct fm10k_msg_data fm10k_iov_msg_data_pf[];
+#endif

 s32 fm10k_init_ops_pf(struct fm10k_hw *hw);
 #endif /* _FM10K_PF_H */
diff --git a/drivers/net/fm10k/base/fm10k_tlv.c 
b/drivers/net/fm10k/base/fm10k_tlv.c
index 1d9d7d8..ade87d1 100644
--- a/drivers/net/fm10k/base/fm10k_tlv.c
+++ b/drivers/net/fm10k/base/fm10k_tlv.c
@@ -63,8 +63,8 @@ s32 fm10k_tlv_msg_init(u32 *msg, u16 msg_id)
  *  the attribute buffer.  It will return success if provided with a valid
  *  pointers.
  **/
-s32 fm10k_tlv_attr_put_null_string(u32 *msg, u16 attr_id,
-  const unsigned char *string)
+static s32 fm10k_tlv_attr_put_null_string(u32 *msg, u16 attr_id,
+ const unsigned char *string)
 {
u32 attr_data = 0, len = 0;
u32 *attr;
@@ -115,7 +115,7 @@ s32 fm10k_tlv_attr_put_null_string(u32 *msg, u16 attr_id,
  *  it in the array pointed by by string.  It will return success if provided
  *  with a valid pointers.
  **/
-s32 fm10k_tlv_attr_get_null_string(u32 *attr, unsigned char *string)
+static s32 fm10k_tlv_attr_get_null_string(u32 *attr, unsigned char *string)
 {
u32 len;

@@ -386,7 +386,7 @@ s32 fm10k_tlv_attr_get_le_struct(u32 *attr, void

[dpdk-dev] [PATCH 02/16] fm10k/base: use bitshift for itr_scale

[Wang Xiao W]

Upstream community wishes us to use bitshift instead of a divisor,
because this is faster, and prevents any need for a '0' check. In our
case, this even works out because default Gen3 will be 0.

Because of this, we are also able to remove the check for non-zero value
in the vf code path since that will already be the default Gen3 case.

Signed-off-by: Wang Xiao W 
---
 drivers/net/fm10k/base/fm10k_type.h | 6 +++---
 drivers/net/fm10k/base/fm10k_vf.c   | 4 
 2 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/net/fm10k/base/fm10k_type.h 
b/drivers/net/fm10k/base/fm10k_type.h
index 62fa73f..44187b1 100644
--- a/drivers/net/fm10k/base/fm10k_type.h
+++ b/drivers/net/fm10k/base/fm10k_type.h
@@ -352,9 +352,9 @@ struct fm10k_hw;
 #define FM10K_TDLEN(_n)((0x40 * (_n)) + 0x8002)
 #define FM10K_TDLEN_ITR_SCALE_SHIFT9
 #define FM10K_TDLEN_ITR_SCALE_MASK 0x0E00
-#define FM10K_TDLEN_ITR_SCALE_GEN1 4
-#define FM10K_TDLEN_ITR_SCALE_GEN2 2
-#define FM10K_TDLEN_ITR_SCALE_GEN3 1
+#define FM10K_TDLEN_ITR_SCALE_GEN1 2
+#define FM10K_TDLEN_ITR_SCALE_GEN2 1
+#define FM10K_TDLEN_ITR_SCALE_GEN3 0
 #define FM10K_TPH_TXCTRL(_n)   ((0x40 * (_n)) + 0x8003)
 #define FM10K_TPH_TXCTRL_DESC_TPHEN0x0020
 #define FM10K_TPH_TXCTRL_DESC_RROEN0x0200
diff --git a/drivers/net/fm10k/base/fm10k_vf.c 
b/drivers/net/fm10k/base/fm10k_vf.c
index 7822ab6..39bc927 100644
--- a/drivers/net/fm10k/base/fm10k_vf.c
+++ b/drivers/net/fm10k/base/fm10k_vf.c
@@ -159,10 +159,6 @@ STATIC s32 fm10k_init_hw_vf(struct fm10k_hw *hw)
 FM10K_TDLEN_ITR_SCALE_MASK) >>
FM10K_TDLEN_ITR_SCALE_SHIFT;

-   /* ensure a non-zero itr scale */
-   if (!hw->mac.itr_scale)
-   hw->mac.itr_scale = FM10K_TDLEN_ITR_SCALE_GEN3;
-
return FM10K_SUCCESS;
 }

-- 
1.9.3

[dpdk-dev] [PATCH 03/16] fm10k/base: reset max_queues on init_hw_vf failure

[Wang Xiao W]

VF drivers must detect how many queues are available. Previously, the
driver assumed that each VF has at minimum 1 queue. This assumption is
incorrect, since it is possible that the PF has not yet assigned the
queues to the VF by the time the VF checks. To resolve this, we added a
check first to ensure that the first queue is infact owned by the VF at
init_hw_vf time. However, the code flow did not reset hw->mac.max_queues
to 0. In some cases, such as during reinit flows, we call init_hw_vf
without clearing the previous value of hw->mac.max_queues. Due to this,
when init_hw_vf errors out, if its error code is not properly handled
the VF driver may still believe it has queues which no longer belong to
it. Fix this by clearing the hw->mac.max_queues on exit due to errors.

Signed-off-by: Wang Xiao W 
---
 drivers/net/fm10k/base/fm10k_vf.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/net/fm10k/base/fm10k_vf.c 
b/drivers/net/fm10k/base/fm10k_vf.c
index 39bc927..9b10ee4 100644
--- a/drivers/net/fm10k/base/fm10k_vf.c
+++ b/drivers/net/fm10k/base/fm10k_vf.c
@@ -128,8 +128,10 @@ STATIC s32 fm10k_init_hw_vf(struct fm10k_hw *hw)

/* verify we have at least 1 queue */
if (!~FM10K_READ_REG(hw, FM10K_TXQCTL(0)) ||
-   !~FM10K_READ_REG(hw, FM10K_RXQCTL(0)))
-   return FM10K_ERR_NO_RESOURCES;
+   !~FM10K_READ_REG(hw, FM10K_RXQCTL(0))) {
+   err = FM10K_ERR_NO_RESOURCES;
+   goto reset_max_queues;
+   }

/* determine how many queues we have */
for (i = 1; tqdloc0 && (i < FM10K_MAX_QUEUES_POOL); i++) {
@@ -147,7 +149,7 @@ STATIC s32 fm10k_init_hw_vf(struct fm10k_hw *hw)
/* shut down queues we own and reset DMA configuration */
err = fm10k_disable_queues_generic(hw, i);
if (err)
-   return err;
+   goto reset_max_queues;

/* record maximum queue count */
hw->mac.max_queues = i;
@@ -160,6 +162,11 @@ STATIC s32 fm10k_init_hw_vf(struct fm10k_hw *hw)
FM10K_TDLEN_ITR_SCALE_SHIFT;

return FM10K_SUCCESS;
+
+reset_max_queues:
+   hw->mac.max_queues = 0;
+
+   return err;
 }

 /**
-- 
1.9.3

[dpdk-dev] [PATCH 04/16] fm10k/base: document ITR scale workaround in VF TDLEN register

[Wang Xiao W]

Add comments which properly explain the undocumented use of bits in
TDLEN register prior to VF initializing it to the correct value. Note
that the mechanism is entirely software-defined and explain its purpose
to help reduce confusion in the future.

Signed-off-by: Wang Xiao W 
---
 drivers/net/fm10k/base/fm10k_pf.c   | 6 +-
 drivers/net/fm10k/base/fm10k_type.h | 9 +
 drivers/net/fm10k/base/fm10k_vf.c   | 9 +
 3 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/net/fm10k/base/fm10k_pf.c 
b/drivers/net/fm10k/base/fm10k_pf.c
index 5b8c039..6de679e 100644
--- a/drivers/net/fm10k/base/fm10k_pf.c
+++ b/drivers/net/fm10k/base/fm10k_pf.c
@@ -958,7 +958,8 @@ STATIC s32 fm10k_iov_assign_default_mac_vlan_pf(struct 
fm10k_hw *hw,
FM10K_WRITE_REG(hw, FM10K_TDBAH(vf_q_idx), tdbah);

/* Provide the VF the ITR scale, using software-defined fields in TDLEN
-* to pass the information during VF initialization
+* to pass the information during VF initialization. See definition of
+* FM10K_TDLEN_ITR_SCALE_SHIFT for more details.
 */
FM10K_WRITE_REG(hw, FM10K_TDLEN(vf_q_idx), hw->mac.itr_scale <<
   FM10K_TDLEN_ITR_SCALE_SHIFT);
@@ -1095,6 +1096,9 @@ STATIC s32 fm10k_iov_reset_resources_pf(struct fm10k_hw 
*hw,
for (i = queues_per_pool; i--;) {
FM10K_WRITE_REG(hw, FM10K_TDBAL(vf_q_idx + i), tdbal);
FM10K_WRITE_REG(hw, FM10K_TDBAH(vf_q_idx + i), tdbah);
+   /* See definition of FM10K_TDLEN_ITR_SCALE_SHIFT for an
+* explanation of how TDLEN is used.
+*/
FM10K_WRITE_REG(hw, FM10K_TDLEN(vf_q_idx + i),
hw->mac.itr_scale <<
FM10K_TDLEN_ITR_SCALE_SHIFT);
diff --git a/drivers/net/fm10k/base/fm10k_type.h 
b/drivers/net/fm10k/base/fm10k_type.h
index 44187b1..5db6345 100644
--- a/drivers/net/fm10k/base/fm10k_type.h
+++ b/drivers/net/fm10k/base/fm10k_type.h
@@ -350,6 +350,15 @@ struct fm10k_hw;
 #define FM10K_TDBAL(_n)((0x40 * (_n)) + 0x8000)
 #define FM10K_TDBAH(_n)((0x40 * (_n)) + 0x8001)
 #define FM10K_TDLEN(_n)((0x40 * (_n)) + 0x8002)
+/* When fist initialized, VFs need to know the Interrupt Throttle Rate (ITR)
+ * scale which is based on the PCIe speed but the speed information in the PCI
+ * configuration space may not be accurate. The PF already knows the ITR scale
+ * but there is no defined method to pass that information from the PF to the
+ * VF. This is accomplished during VF initialization by temporarily co-opting
+ * the yet-to-be-used TDLEN register to have the PF store the ITR shift for
+ * the VF to retrieve before the VF needs to use the TDLEN register for its
+ * intended purpose, i.e. before the Tx resources are allocated.
+ */
 #define FM10K_TDLEN_ITR_SCALE_SHIFT9
 #define FM10K_TDLEN_ITR_SCALE_MASK 0x0E00
 #define FM10K_TDLEN_ITR_SCALE_GEN1 2
diff --git a/drivers/net/fm10k/base/fm10k_vf.c 
b/drivers/net/fm10k/base/fm10k_vf.c
index 9b10ee4..43eb081 100644
--- a/drivers/net/fm10k/base/fm10k_vf.c
+++ b/drivers/net/fm10k/base/fm10k_vf.c
@@ -74,6 +74,11 @@ STATIC s32 fm10k_stop_hw_vf(struct fm10k_hw *hw)
FM10K_WRITE_REG(hw, FM10K_TDBAH(i), bah);
FM10K_WRITE_REG(hw, FM10K_RDBAL(i), bal);
FM10K_WRITE_REG(hw, FM10K_RDBAH(i), bah);
+   /* Restore ITR scale in software-defined mechanism in TDLEN
+* for next VF initialization. See definition of
+* FM10K_TDLEN_ITR_SCALE_SHIFT for more details on the use of
+* TDLEN here.
+*/
FM10K_WRITE_REG(hw, FM10K_TDLEN(i), tdlen);
}

@@ -157,6 +162,10 @@ STATIC s32 fm10k_init_hw_vf(struct fm10k_hw *hw)
/* fetch default VLAN and ITR scale */
hw->mac.default_vid = (FM10K_READ_REG(hw, FM10K_TXQCTL(0)) &
   FM10K_TXQCTL_VID_MASK) >> FM10K_TXQCTL_VID_SHIFT;
+   /* Read the ITR scale from TDLEN. See the definition of
+* FM10K_TDLEN_ITR_SCALE_SHIFT for more information about how TDLEN is
+* used here.
+*/
hw->mac.itr_scale = (FM10K_READ_REG(hw, FM10K_TDLEN(0)) &
 FM10K_TDLEN_ITR_SCALE_MASK) >>
FM10K_TDLEN_ITR_SCALE_SHIFT;
-- 
1.9.3

[dpdk-dev] [PATCH 05/16] fm10k/base: fix checkpatch warning

[Wang Xiao W]

Cleanup lines over 80 characters.
Cleanup useless else, checkpatch warns that else is not generally
useful after a break or return.

Signed-off-by: Wang Xiao W 
---
 drivers/net/fm10k/base/fm10k_mbx.c |  2 +-
 drivers/net/fm10k/base/fm10k_pf.c  | 19 ++-
 2 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/net/fm10k/base/fm10k_mbx.c 
b/drivers/net/fm10k/base/fm10k_mbx.c
index 3c9ab3a..7d03704 100644
--- a/drivers/net/fm10k/base/fm10k_mbx.c
+++ b/drivers/net/fm10k/base/fm10k_mbx.c
@@ -930,7 +930,7 @@ STATIC void fm10k_mbx_create_disconnect_hdr(struct 
fm10k_mbx_info *mbx)
 }

 /**
- *  fm10k_mbx_create_fake_disconnect_hdr - Generate a false disconnect mailbox 
header
+ *  fm10k_mbx_create_fake_disconnect_hdr - Generate a false disconnect mbox hdr
  *  @mbx: pointer to mailbox
  *
  *  This function creates a fake disconnect header for loading into remote
diff --git a/drivers/net/fm10k/base/fm10k_pf.c 
b/drivers/net/fm10k/base/fm10k_pf.c
index 6de679e..3ee88b6 100644
--- a/drivers/net/fm10k/base/fm10k_pf.c
+++ b/drivers/net/fm10k/base/fm10k_pf.c
@@ -1278,8 +1278,8 @@ s32 fm10k_iov_msg_mac_vlan_pf(struct fm10k_hw *hw, u32 
**results,
err = fm10k_iov_select_vid(vf_info, (u16)vid);
if (err < 0)
return err;
-   else
-   vid = err;
+
+   vid = err;

/* update VSI info for VF in regards to VLAN table */
err = hw->mac.ops.update_vlan(hw, vid, vf_info->vsi, set);
@@ -1304,8 +1304,8 @@ s32 fm10k_iov_msg_mac_vlan_pf(struct fm10k_hw *hw, u32 
**results,
err = fm10k_iov_select_vid(vf_info, vlan);
if (err < 0)
return err;
-   else
-   vlan = (u16)err;
+
+   vlan = (u16)err;

/* notify switch of request for new unicast address */
err = hw->mac.ops.update_uc_addr(hw, vf_info->glort,
@@ -1330,8 +1330,8 @@ s32 fm10k_iov_msg_mac_vlan_pf(struct fm10k_hw *hw, u32 
**results,
err = fm10k_iov_select_vid(vf_info, vlan);
if (err < 0)
return err;
-   else
-   vlan = (u16)err;
+
+   vlan = (u16)err;

/* notify switch of request for new multicast address */
err = hw->mac.ops.update_mc_addr(hw, vf_info->glort,
@@ -1500,9 +1500,10 @@ STATIC void fm10k_update_hw_stats_pf(struct fm10k_hw *hw,
xec = fm10k_read_hw_stats_32b(hw, FM10K_STATS_XEC, &stats->xec);
vlan_drop = fm10k_read_hw_stats_32b(hw, FM10K_STATS_VLAN_DROP,
&stats->vlan_drop);
-   loopback_drop = fm10k_read_hw_stats_32b(hw,
-   
FM10K_STATS_LOOPBACK_DROP,
-   &stats->loopback_drop);
+   loopback_drop =
+   fm10k_read_hw_stats_32b(hw,
+   FM10K_STATS_LOOPBACK_DROP,
+   &stats->loopback_drop);
nodesc_drop = fm10k_read_hw_stats_32b(hw,
  FM10K_STATS_NODESC_DROP,
  &stats->nodesc_drop);
-- 
1.9.3

[dpdk-dev] [PATCH 06/16] fm10k/base: use BIT macro instead of open-coded bit-shifting of 1

[Wang Xiao W]

The upstream Linux kernel community prefers using the BIT macro over
bit-shifting a 1.  Similar to how this is handled in the i40e shared code,
define a macro for OSes that do not already have it and wrap all that in
LINUX_MACROS so that it can be stripped from the Linux driver.

The upstream Linux kernel community prefers avoiding CamelCase in
variables, function names, etc.

Signed-off-by: Wang Xiao W 
---
 drivers/net/fm10k/base/fm10k_pf.c   | 12 ++--
 drivers/net/fm10k/base/fm10k_tlv.c  | 24 
 drivers/net/fm10k/base/fm10k_type.h | 18 --
 3 files changed, 30 insertions(+), 24 deletions(-)

diff --git a/drivers/net/fm10k/base/fm10k_pf.c 
b/drivers/net/fm10k/base/fm10k_pf.c
index 3ee88b6..7d48210 100644
--- a/drivers/net/fm10k/base/fm10k_pf.c
+++ b/drivers/net/fm10k/base/fm10k_pf.c
@@ -576,8 +576,8 @@ STATIC s32 fm10k_configure_dglort_map_pf(struct fm10k_hw 
*hw,
return FM10K_ERR_PARAM;

/* determine count of VSIs and queues */
-   queue_count = 1 << (dglort->rss_l + dglort->pc_l);
-   vsi_count = 1 << (dglort->vsi_l + dglort->queue_l);
+   queue_count = BIT(dglort->rss_l + dglort->pc_l);
+   vsi_count = BIT(dglort->vsi_l + dglort->queue_l);
glort = dglort->glort;
q_idx = dglort->queue_b;

@@ -593,8 +593,8 @@ STATIC s32 fm10k_configure_dglort_map_pf(struct fm10k_hw 
*hw,
}

/* determine count of PCs and queues */
-   queue_count = 1 << (dglort->queue_l + dglort->rss_l + dglort->vsi_l);
-   pc_count = 1 << dglort->pc_l;
+   queue_count = BIT(dglort->queue_l + dglort->rss_l + dglort->vsi_l);
+   pc_count = BIT(dglort->pc_l);

/* configure PC for Tx queues */
for (pc = 0; pc < pc_count; pc++) {
@@ -1001,7 +1001,7 @@ STATIC s32 fm10k_iov_reset_resources_pf(struct fm10k_hw 
*hw,
return FM10K_ERR_PARAM;

/* clear event notification of VF FLR */
-   FM10K_WRITE_REG(hw, FM10K_PFVFLREC(vf_idx / 32), 1 << (vf_idx % 32));
+   FM10K_WRITE_REG(hw, FM10K_PFVFLREC(vf_idx / 32), BIT(vf_idx % 32));

/* force timeout and then disconnect the mailbox */
vf_info->mbx.timeout = 0;
@@ -1417,7 +1417,7 @@ s32 fm10k_iov_msg_lport_state_pf(struct fm10k_hw *hw, u32 
**results,
mode = fm10k_iov_supported_xcast_mode_pf(vf_info, mode);

/* if mode is not currently enabled, enable it */
-   if (!(FM10K_VF_FLAG_ENABLED(vf_info) & (1 << mode)))
+   if (!(FM10K_VF_FLAG_ENABLED(vf_info) & BIT(mode)))
fm10k_update_xcast_mode_pf(hw, vf_info->glort, mode);

/* swap mode back to a bit flag */
diff --git a/drivers/net/fm10k/base/fm10k_tlv.c 
b/drivers/net/fm10k/base/fm10k_tlv.c
index ade87d1..e6150c1 100644
--- a/drivers/net/fm10k/base/fm10k_tlv.c
+++ b/drivers/net/fm10k/base/fm10k_tlv.c
@@ -249,7 +249,7 @@ s32 fm10k_tlv_attr_put_value(u32 *msg, u16 attr_id, s64 
value, u32 len)
attr = &msg[FM10K_TLV_DWORD_LEN(*msg)];

if (len < 4) {
-   attr[1] = (u32)value & ((0x1ul << (8 * len)) - 1);
+   attr[1] = (u32)value & (BIT(8 * len) - 1);
} else {
attr[1] = (u32)value;
if (len > 4)
@@ -699,29 +699,29 @@ STATIC void fm10k_tlv_msg_test_generate_data(u32 *msg, 
u32 attr_flags)
 {
DEBUGFUNC("fm10k_tlv_msg_test_generate_data");

-   if (attr_flags & (1 << FM10K_TEST_MSG_STRING))
+   if (attr_flags & BIT(FM10K_TEST_MSG_STRING))
fm10k_tlv_attr_put_null_string(msg, FM10K_TEST_MSG_STRING,
   test_str);
-   if (attr_flags & (1 << FM10K_TEST_MSG_MAC_ADDR))
+   if (attr_flags & BIT(FM10K_TEST_MSG_MAC_ADDR))
fm10k_tlv_attr_put_mac_vlan(msg, FM10K_TEST_MSG_MAC_ADDR,
test_mac, test_vlan);
-   if (attr_flags & (1 << FM10K_TEST_MSG_U8))
+   if (attr_flags & BIT(FM10K_TEST_MSG_U8))
fm10k_tlv_attr_put_u8(msg, FM10K_TEST_MSG_U8,  test_u8);
-   if (attr_flags & (1 << FM10K_TEST_MSG_U16))
+   if (attr_flags & BIT(FM10K_TEST_MSG_U16))
fm10k_tlv_attr_put_u16(msg, FM10K_TEST_MSG_U16, test_u16);
-   if (attr_flags & (1 << FM10K_TEST_MSG_U32))
+   if (attr_flags & BIT(FM10K_TEST_MSG_U32))
fm10k_tlv_attr_put_u32(msg, FM10K_TEST_MSG_U32, test_u32);
-   if (attr_flags & (1 << FM10K_TEST_MSG_U64))
+   if (attr_flags & BIT(FM10K_TEST_MSG_U64))
fm10k_tlv_attr_put_u64(msg, FM10K_TEST_MSG_U64, test_u64);
-   if (attr_flags & (1 << FM10K_TEST_MSG_S8))
+   if (attr_flags & BIT(FM10K_TEST_MSG_S8))
fm10k_tlv_attr_put_s8(msg, FM10K_TEST_MSG_S8,  test_s8);
-   if (attr_flags & (1 << FM10K_TEST_MSG_S16))
+   if (attr_flags & BIT(FM10K_TEST_MSG_S16))
fm10k_tlv_attr_put_s16(msg, FM10K_TEST_MSG_S16, test_s16);
-   if (attr_flags & (1 << FM

[dpdk-dev] [PATCH 07/16] fm10k/base: do not use CamelCase

[Wang Xiao W]

The upstream Linux kernel community prefers avoiding CamelCase in
variables, function names, etc.

Signed-off-by: Wang Xiao W 
---
 drivers/net/fm10k/base/fm10k_type.h | 14 +++---
 drivers/net/fm10k/fm10k_ethdev.c| 24 
 2 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/drivers/net/fm10k/base/fm10k_type.h 
b/drivers/net/fm10k/base/fm10k_type.h
index 387d25b..c9885a1 100644
--- a/drivers/net/fm10k/base/fm10k_type.h
+++ b/drivers/net/fm10k/base/fm10k_type.h
@@ -531,13 +531,13 @@ struct fm10k_hw;
 #endif

 enum fm10k_int_source {
-   fm10k_int_Mailbox   = 0,
-   fm10k_int_PCIeFault = 1,
-   fm10k_int_SwitchUpDown  = 2,
-   fm10k_int_SwitchEvent   = 3,
-   fm10k_int_SRAM  = 4,
-   fm10k_int_VFLR  = 5,
-   fm10k_int_MaxHoldTime   = 6,
+   fm10k_int_mailbox   = 0,
+   fm10k_int_pcie_fault= 1,
+   fm10k_int_switch_up_down= 2,
+   fm10k_int_switch_event  = 3,
+   fm10k_int_sram  = 4,
+   fm10k_int_vflr  = 5,
+   fm10k_int_max_hold_time = 6,
fm10k_int_sources_max_pf
 };

diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index e4aed94..e967628 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -2074,12 +2074,12 @@ fm10k_dev_enable_intr_pf(struct rte_eth_dev *dev)
/* Bind all local non-queue interrupt to vector 0 */
int_map |= 0;

-   FM10K_WRITE_REG(hw, FM10K_INT_MAP(fm10k_int_Mailbox), int_map);
-   FM10K_WRITE_REG(hw, FM10K_INT_MAP(fm10k_int_PCIeFault), int_map);
-   FM10K_WRITE_REG(hw, FM10K_INT_MAP(fm10k_int_SwitchUpDown), int_map);
-   FM10K_WRITE_REG(hw, FM10K_INT_MAP(fm10k_int_SwitchEvent), int_map);
-   FM10K_WRITE_REG(hw, FM10K_INT_MAP(fm10k_int_SRAM), int_map);
-   FM10K_WRITE_REG(hw, FM10K_INT_MAP(fm10k_int_VFLR), int_map);
+   FM10K_WRITE_REG(hw, FM10K_INT_MAP(fm10k_int_mailbox), int_map);
+   FM10K_WRITE_REG(hw, FM10K_INT_MAP(fm10k_int_pcie_fault), int_map);
+   FM10K_WRITE_REG(hw, FM10K_INT_MAP(fm10k_int_switch_up_down), int_map);
+   FM10K_WRITE_REG(hw, FM10K_INT_MAP(fm10k_int_switch_event), int_map);
+   FM10K_WRITE_REG(hw, FM10K_INT_MAP(fm10k_int_sram), int_map);
+   FM10K_WRITE_REG(hw, FM10K_INT_MAP(fm10k_int_vflr), int_map);

/* Enable misc causes */
FM10K_WRITE_REG(hw, FM10K_EIMR, FM10K_EIMR_ENABLE(PCA_FAULT) |
@@ -2105,12 +2105,12 @@ fm10k_dev_disable_intr_pf(struct rte_eth_dev *dev)

int_map |= 0;

-   FM10K_WRITE_REG(hw, FM10K_INT_MAP(fm10k_int_Mailbox), int_map);
-   FM10K_WRITE_REG(hw, FM10K_INT_MAP(fm10k_int_PCIeFault), int_map);
-   FM10K_WRITE_REG(hw, FM10K_INT_MAP(fm10k_int_SwitchUpDown), int_map);
-   FM10K_WRITE_REG(hw, FM10K_INT_MAP(fm10k_int_SwitchEvent), int_map);
-   FM10K_WRITE_REG(hw, FM10K_INT_MAP(fm10k_int_SRAM), int_map);
-   FM10K_WRITE_REG(hw, FM10K_INT_MAP(fm10k_int_VFLR), int_map);
+   FM10K_WRITE_REG(hw, FM10K_INT_MAP(fm10k_int_mailbox), int_map);
+   FM10K_WRITE_REG(hw, FM10K_INT_MAP(fm10k_int_pcie_fault), int_map);
+   FM10K_WRITE_REG(hw, FM10K_INT_MAP(fm10k_int_switch_up_down), int_map);
+   FM10K_WRITE_REG(hw, FM10K_INT_MAP(fm10k_int_switch_event), int_map);
+   FM10K_WRITE_REG(hw, FM10K_INT_MAP(fm10k_int_sram), int_map);
+   FM10K_WRITE_REG(hw, FM10K_INT_MAP(fm10k_int_vflr), int_map);

/* Disable misc causes */
FM10K_WRITE_REG(hw, FM10K_EIMR, FM10K_EIMR_DISABLE(PCA_FAULT) |
-- 
1.9.3

[dpdk-dev] [PATCH 08/16] fm10k/base: use memcpy for mac addr copy

[Wang Xiao W]

Use memcpy instead of copying MAC address byte-by-byte.

Signed-off-by: Wang Xiao W 
---
 drivers/net/fm10k/base/fm10k_pf.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/net/fm10k/base/fm10k_pf.c 
b/drivers/net/fm10k/base/fm10k_pf.c
index 7d48210..a1469aa 100644
--- a/drivers/net/fm10k/base/fm10k_pf.c
+++ b/drivers/net/fm10k/base/fm10k_pf.c
@@ -300,7 +300,6 @@ STATIC s32 fm10k_read_mac_addr_pf(struct fm10k_hw *hw)
 {
u8 perm_addr[ETH_ALEN];
u32 serial_num;
-   int i;

DEBUGFUNC("fm10k_read_mac_addr_pf");

@@ -324,10 +323,8 @@ STATIC s32 fm10k_read_mac_addr_pf(struct fm10k_hw *hw)
perm_addr[4] = (u8)(serial_num >> 8);
perm_addr[5] = (u8)(serial_num);

-   for (i = 0; i < ETH_ALEN; i++) {
-   hw->mac.perm_addr[i] = perm_addr[i];
-   hw->mac.addr[i] = perm_addr[i];
-   }
+   memcpy(hw->mac.perm_addr, perm_addr, ETH_ALEN);
+   memcpy(hw->mac.addr, perm_addr, ETH_ALEN);

return FM10K_SUCCESS;
 }
-- 
1.9.3

[dpdk-dev] [PATCH 09/16] fm10k/base: allow removal of is_slot_appropriate function

[Wang Xiao W]

The Linux Kernel provides the OS a call "pcie_get_minimum_link" which
can crawl the PCIe tree and determine the actual minimum link speed of a
device which is a more general check than provided by
is_slot_appropriate. Thus, the upstream driver does not use or want the
is_slot_appropriate function call. Add a NO_IS_SLOT_APPROPRIATE_CHECK
definition which can be defined during strip process to remove the code.
If left undefined (the default) then the code will all be active and no
driver changes should be necessary.

Signed-off-by: Wang Xiao W 
---
 drivers/net/fm10k/base/fm10k_api.c  | 2 ++
 drivers/net/fm10k/base/fm10k_api.h  | 2 ++
 drivers/net/fm10k/base/fm10k_pf.c   | 4 
 drivers/net/fm10k/base/fm10k_type.h | 2 ++
 drivers/net/fm10k/base/fm10k_vf.c   | 4 
 5 files changed, 14 insertions(+)

diff --git a/drivers/net/fm10k/base/fm10k_api.c 
b/drivers/net/fm10k/base/fm10k_api.c
index eb5bdaa..c49d20d 100644
--- a/drivers/net/fm10k/base/fm10k_api.c
+++ b/drivers/net/fm10k/base/fm10k_api.c
@@ -181,6 +181,7 @@ s32 fm10k_get_bus_info(struct fm10k_hw *hw)
   FM10K_NOT_IMPLEMENTED);
 }

+#ifndef NO_IS_SLOT_APPROPRIATE_CHECK
 /**
  *  fm10k_is_slot_appropriate - Indicate appropriate slot for this SKU
  *  @hw: pointer to hardware structure
@@ -195,6 +196,7 @@ bool fm10k_is_slot_appropriate(struct fm10k_hw *hw)
return true;
 }

+#endif
 /**
  *  fm10k_update_vlan - Clear VLAN ID to VLAN filter table
  *  @hw: pointer to hardware structure
diff --git a/drivers/net/fm10k/base/fm10k_api.h 
b/drivers/net/fm10k/base/fm10k_api.h
index 113aef5..2ab3149 100644
--- a/drivers/net/fm10k/base/fm10k_api.h
+++ b/drivers/net/fm10k/base/fm10k_api.h
@@ -44,7 +44,9 @@ s32 fm10k_stop_hw(struct fm10k_hw *hw);
 s32 fm10k_start_hw(struct fm10k_hw *hw);
 s32 fm10k_init_shared_code(struct fm10k_hw *hw);
 s32 fm10k_get_bus_info(struct fm10k_hw *hw);
+#ifndef NO_IS_SLOT_APPROPRIATE_CHECK
 bool fm10k_is_slot_appropriate(struct fm10k_hw *hw);
+#endif
 s32 fm10k_update_vlan(struct fm10k_hw *hw, u32 vid, u8 idx, bool set);
 s32 fm10k_read_mac_addr(struct fm10k_hw *hw);
 void fm10k_update_hw_stats(struct fm10k_hw *hw, struct fm10k_hw_stats *stats);
diff --git a/drivers/net/fm10k/base/fm10k_pf.c 
b/drivers/net/fm10k/base/fm10k_pf.c
index a1469aa..f5cbda4 100644
--- a/drivers/net/fm10k/base/fm10k_pf.c
+++ b/drivers/net/fm10k/base/fm10k_pf.c
@@ -216,6 +216,7 @@ STATIC s32 fm10k_init_hw_pf(struct fm10k_hw *hw)
return FM10K_SUCCESS;
 }

+#ifndef NO_IS_SLOT_APPROPRIATE_CHECK
 /**
  *  fm10k_is_slot_appropriate_pf - Indicate appropriate slot for this SKU
  *  @hw: pointer to hardware structure
@@ -231,6 +232,7 @@ STATIC bool fm10k_is_slot_appropriate_pf(struct fm10k_hw 
*hw)
   (hw->bus.width == hw->bus_caps.width);
 }

+#endif
 /**
  *  fm10k_update_vlan_pf - Update status of VLAN ID in VLAN filter table
  *  @hw: pointer to hardware structure
@@ -2064,7 +2066,9 @@ s32 fm10k_init_ops_pf(struct fm10k_hw *hw)
mac->ops.init_hw = &fm10k_init_hw_pf;
mac->ops.start_hw = &fm10k_start_hw_generic;
mac->ops.stop_hw = &fm10k_stop_hw_generic;
+#ifndef NO_IS_SLOT_APPROPRIATE_CHECK
mac->ops.is_slot_appropriate = &fm10k_is_slot_appropriate_pf;
+#endif
mac->ops.update_vlan = &fm10k_update_vlan_pf;
mac->ops.read_mac_addr = &fm10k_read_mac_addr_pf;
mac->ops.update_uc_addr = &fm10k_update_uc_addr_pf;
diff --git a/drivers/net/fm10k/base/fm10k_type.h 
b/drivers/net/fm10k/base/fm10k_type.h
index c9885a1..ba0a184 100644
--- a/drivers/net/fm10k/base/fm10k_type.h
+++ b/drivers/net/fm10k/base/fm10k_type.h
@@ -679,7 +679,9 @@ struct fm10k_mac_ops {
s32 (*stop_hw)(struct fm10k_hw *);
s32 (*get_bus_info)(struct fm10k_hw *);
s32 (*get_host_state)(struct fm10k_hw *, bool *);
+#ifndef NO_IS_SLOT_APPROPRIATE_CHECK
bool (*is_slot_appropriate)(struct fm10k_hw *);
+#endif
s32 (*update_vlan)(struct fm10k_hw *, u32, u8, bool);
s32 (*read_mac_addr)(struct fm10k_hw *);
s32 (*update_uc_addr)(struct fm10k_hw *, u16, const u8 *,
diff --git a/drivers/net/fm10k/base/fm10k_vf.c 
b/drivers/net/fm10k/base/fm10k_vf.c
index 43eb081..efbdbd1 100644
--- a/drivers/net/fm10k/base/fm10k_vf.c
+++ b/drivers/net/fm10k/base/fm10k_vf.c
@@ -178,6 +178,7 @@ reset_max_queues:
return err;
 }

+#ifndef NO_IS_SLOT_APPROPRIATE_CHECK
 /**
  *  fm10k_is_slot_appropriate_vf - Indicate appropriate slot for this SKU
  *  @hw: pointer to hardware structure
@@ -194,6 +195,7 @@ STATIC bool fm10k_is_slot_appropriate_vf(struct fm10k_hw 
*hw)
return TRUE;
 }

+#endif
 /* This structure defines the attibutes to be parsed below */
 const struct fm10k_tlv_attr fm10k_mac_vlan_msg_attr[] = {
FM10K_TLV_ATTR_U32(FM10K_MAC_VLAN_MSG_VLAN),
@@ -648,7 +650,9 @@ s32 fm10k_init_ops_vf(struct fm10k_hw *hw)
mac->ops.init_hw = &fm10k_init_hw_vf;
mac->ops.start_hw = &fm10k_start_hw_generic;
mac->ops.stop_hw = &fm10k_stop_hw

[dpdk-dev] [PATCH 10/16] fm10k/base: consistently use VLAN ID when referencing vid variables

[Wang Xiao W]

The vid variable name is shorthand for VLAN ID, so we should use this in
comments explaining what is happening.

Signed-off-by: Wang Xiao W 
---
 drivers/net/fm10k/base/fm10k_pf.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/fm10k/base/fm10k_pf.c 
b/drivers/net/fm10k/base/fm10k_pf.c
index f5cbda4..716d7f1 100644
--- a/drivers/net/fm10k/base/fm10k_pf.c
+++ b/drivers/net/fm10k/base/fm10k_pf.c
@@ -970,7 +970,7 @@ err_out:
txqctl |= (vf_idx << FM10K_TXQCTL_TC_SHIFT) |
  FM10K_TXQCTL_VF | vf_idx;

-   /* assign VID */
+   /* assign VLAN ID */
for (i = 0; i < queues_per_pool; i++)
FM10K_WRITE_REG(hw, FM10K_TXQCTL(vf_q_idx + i), txqctl);

@@ -1215,12 +1215,12 @@ s32 fm10k_iov_msg_msix_pf(struct fm10k_hw *hw, u32 
**results,
 }

 /**
- * fm10k_iov_select_vid - Select correct default vid
+ * fm10k_iov_select_vid - Select correct default VLAN ID
  * @hw: Pointer to hardware structure
- * @vid: vid to correct
+ * @vid: VLAN ID to correct
  *
- * Will report an error if vid is out of range. For vid = 0, it will return
- * either the pf_vid or sw_vid depending on which one is set.
+ * Will report an error if the VLAN ID is out of range. For VID = 0, it will
+ * return either the pf_vid or sw_vid depending on which one is set.
  */
 STATIC s32 fm10k_iov_select_vid(struct fm10k_vf_info *vf_info, u16 vid)
 {
@@ -1783,7 +1783,7 @@ static s32 fm10k_msg_update_pvid_pf(struct fm10k_hw *hw, 
u32 **results,
if (!fm10k_glort_valid_pf(hw, glort))
return FM10K_ERR_PARAM;

-   /* verify VID is valid */
+   /* verify VLAN ID is valid */
if (pvid >= FM10K_VLAN_TABLE_VID_MAX)
return FM10K_ERR_PARAM;

-- 
1.9.3

[dpdk-dev] [PATCH 11/16] fm10k/base: fix comment per upstream review changes

[Wang Xiao W]

The comment here was changed during review of upstream patch, and the
new wording is slightly more clear. Re-write the comment in SHARED code
based on this new wording.

Fix a number of mailbox comment issues with function header comments,
lower-case acronyms (i.e. FIFO, TLV), incorrect function names in DEBUGFUNC(),
duplicate comments and a stubbed-out header comment for fm10k_sm_mbx_init.

Signed-off-by: Wang Xiao W 
---
 drivers/net/fm10k/base/fm10k_mbx.c | 61 ++
 drivers/net/fm10k/base/fm10k_mbx.h |  4 +--
 drivers/net/fm10k/base/fm10k_pf.c  | 12 
 drivers/net/fm10k/base/fm10k_tlv.h |  4 +--
 4 files changed, 46 insertions(+), 35 deletions(-)

diff --git a/drivers/net/fm10k/base/fm10k_mbx.c 
b/drivers/net/fm10k/base/fm10k_mbx.c
index 7d03704..2e70434 100644
--- a/drivers/net/fm10k/base/fm10k_mbx.c
+++ b/drivers/net/fm10k/base/fm10k_mbx.c
@@ -70,7 +70,7 @@ STATIC u16 fm10k_fifo_unused(struct fm10k_mbx_fifo *fifo)
 }

 /**
- *  fm10k_fifo_empty - Test to verify if fifo is empty
+ *  fm10k_fifo_empty - Test to verify if FIFO is empty
  *  @fifo: pointer to FIFO
  *
  *  This function returns true if the FIFO is empty, else false
@@ -85,7 +85,7 @@ STATIC bool fm10k_fifo_empty(struct fm10k_mbx_fifo *fifo)
  *  @fifo: pointer to FIFO
  *  @offset: offset to add to head
  *
- *  This function returns the indices into the fifo based on head + offset
+ *  This function returns the indices into the FIFO based on head + offset
  **/
 STATIC u16 fm10k_fifo_head_offset(struct fm10k_mbx_fifo *fifo, u16 offset)
 {
@@ -97,7 +97,7 @@ STATIC u16 fm10k_fifo_head_offset(struct fm10k_mbx_fifo 
*fifo, u16 offset)
  *  @fifo: pointer to FIFO
  *  @offset: offset to add to tail
  *
- *  This function returns the indices into the fifo based on tail + offset
+ *  This function returns the indices into the FIFO based on tail + offset
  **/
 STATIC u16 fm10k_fifo_tail_offset(struct fm10k_mbx_fifo *fifo, u16 offset)
 {
@@ -173,7 +173,7 @@ STATIC u16 fm10k_mbx_index_len(struct fm10k_mbx_info *mbx, 
u16 head, u16 tail)
 /**
  *  fm10k_mbx_tail_add - Determine new tail value with added offset
  *  @mbx: pointer to mailbox
- *  @offset: length to add to head offset
+ *  @offset: length to add to tail offset
  *
  *  This function takes the local tail index and recomputes it for
  *  a given length added as an offset.
@@ -189,7 +189,7 @@ STATIC u16 fm10k_mbx_tail_add(struct fm10k_mbx_info *mbx, 
u16 offset)
 /**
  *  fm10k_mbx_tail_sub - Determine new tail value with subtracted offset
  *  @mbx: pointer to mailbox
- *  @offset: length to add to head offset
+ *  @offset: length to add to tail offset
  *
  *  This function takes the local tail index and recomputes it for
  *  a given length added as an offset.
@@ -253,7 +253,7 @@ STATIC u16 fm10k_mbx_pushed_tail_len(struct fm10k_mbx_info 
*mbx)
 }

 /**
- *  fm10k_fifo_write_copy - pulls data off of msg and places it in fifo
+ *  fm10k_fifo_write_copy - pulls data off of msg and places it in FIFO
  *  @fifo: pointer to FIFO
  *  @msg: message array to populate
  *  @tail_offset: additional offset to add to tail pointer
@@ -331,7 +331,7 @@ STATIC u16 fm10k_mbx_validate_msg_size(struct 
fm10k_mbx_info *mbx, u16 len)
u16 total_len = 0, msg_len;
u32 *msg;

-   DEBUGFUNC("fm10k_mbx_validate_msg");
+   DEBUGFUNC("fm10k_mbx_validate_msg_size");

/* length should include previous amounts pushed */
len += mbx->pushed;
@@ -353,6 +353,7 @@ STATIC u16 fm10k_mbx_validate_msg_size(struct 
fm10k_mbx_info *mbx, u16 len)

 /**
  *  fm10k_mbx_write_copy - pulls data off of Tx FIFO and places it in mbmem
+ *  @hw: pointer to hardware structure
  *  @mbx: pointer to mailbox
  *
  *  This function will take a section of the Tx FIFO and copy it into the
@@ -734,7 +735,7 @@ STATIC bool fm10k_mbx_tx_complete(struct fm10k_mbx_info 
*mbx)
  *  @hw: pointer to hardware structure
  *  @mbx: pointer to mailbox
  *
- *  This function dequeues messages and hands them off to the tlv parser.
+ *  This function dequeues messages and hands them off to the TLV parser.
  *  It will return the number of messages processed when called.
  **/
 STATIC u16 fm10k_mbx_dequeue_rx(struct fm10k_hw *hw,
@@ -951,7 +952,7 @@ STATIC void fm10k_mbx_create_fake_disconnect_hdr(struct 
fm10k_mbx_info *mbx)
 }

 /**
- *  fm10k_mbx_create_error_msg - Generate a error message
+ *  fm10k_mbx_create_error_msg - Generate an error message
  *  @mbx: pointer to mailbox
  *  @err: local error encountered
  *
@@ -984,7 +985,6 @@ STATIC void fm10k_mbx_create_error_msg(struct 
fm10k_mbx_info *mbx, s32 err)
 /**
  *  fm10k_mbx_validate_msg_hdr - Validate common fields in the message header
  *  @mbx: pointer to mailbox
- *  @msg: message array to read
  *
  *  This function will parse up the fields in the mailbox header and return
  *  an error if the header contains any of a number of invalid configurations
@@ -1050,11 +1050,12 @@ STATIC s32 fm10k_mbx_validate_msg_hdr(st

[dpdk-dev] [PATCH 12/16] fm10k/base: TLV structures must be 4byte aligned, not 1byte aligned

[Wang Xiao W]

Per comments from an upstream patch, and looking at how TLV LE_STRUCT
code works, we actually want these structures to be 4byte aligned, not
1byte aligned. In practice, 1byte alignment has worked so far because
all our structures end up being a multiple of 4. But if a future TLV
structure were added that had a u8 or similar sticking on the end things
would break. Fix this by using 4byte alignment which will prevent the
TLV LE_STRUCT code from breaking. Update the comment explaining that we
need 4byte alignment of our structures.

Signed-off-by: Wang Xiao W 
---
 drivers/net/fm10k/base/fm10k_pf.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/fm10k/base/fm10k_pf.h 
b/drivers/net/fm10k/base/fm10k_pf.h
index 92e2962..ee8527a 100644
--- a/drivers/net/fm10k/base/fm10k_pf.h
+++ b/drivers/net/fm10k/base/fm10k_pf.h
@@ -91,14 +91,14 @@ enum fm10k_pf_tlv_attr_id_v1 {
 #define FM10K_MSG_UPDATE_PVID_PVID_SHIFT   16
 #define FM10K_MSG_UPDATE_PVID_PVID_SIZE16

-/* The following data structures are overlayed specifically to TLV mailbox
- * messages, and must not have gaps between their values. They must line up
- * correctly to the TLV definition.
+/* The following data structures are overlayed directly onto TLV mailbox
+ * messages, and must not break 4 byte alignment. Ensure the structures line
+ * up correctly as per their TLV definition.
  */
 #ifdef C99
-#pragma pack(push, 1)
+#pragma pack(push, 4)
 #else
-#pragma pack(1)
+#pragma pack(4)
 #endif /* C99 */

 struct fm10k_mac_update {
-- 
1.9.3

[dpdk-dev] [PATCH 13/16] fm10k/base: move constants to the right of binary operators

[Wang Xiao W]

The upstream Linux kernel community prefers constants are to the right of
binary operators.

Signed-off-by: Wang Xiao W 
---
 drivers/net/fm10k/base/fm10k_pf.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/fm10k/base/fm10k_pf.c 
b/drivers/net/fm10k/base/fm10k_pf.c
index 456fe64..105babf 100644
--- a/drivers/net/fm10k/base/fm10k_pf.c
+++ b/drivers/net/fm10k/base/fm10k_pf.c
@@ -759,8 +759,8 @@ STATIC s32 fm10k_iov_assign_resources_pf(struct fm10k_hw 
*hw, u16 num_vfs,
FM10K_RXDCTL_WRITE_BACK_MIN_DELAY |
FM10K_RXDCTL_DROP_ON_EMPTY);
FM10K_WRITE_REG(hw, FM10K_RXQCTL(vf_q_idx),
-   FM10K_RXQCTL_VF |
-   (i << FM10K_RXQCTL_VF_SHIFT));
+   (i << FM10K_RXQCTL_VF_SHIFT) |
+   FM10K_RXQCTL_VF);

/* map queue pair to VF */
FM10K_WRITE_REG(hw, FM10K_TQMAP(qmap_idx), vf_q_idx);
@@ -1035,7 +1035,7 @@ STATIC s32 fm10k_iov_reset_resources_pf(struct fm10k_hw 
*hw,
txqctl = ((u32)vf_vid << FM10K_TXQCTL_VID_SHIFT) |
 (vf_idx << FM10K_TXQCTL_TC_SHIFT) |
 FM10K_TXQCTL_VF | vf_idx;
-   rxqctl = FM10K_RXQCTL_VF | (vf_idx << FM10K_RXQCTL_VF_SHIFT);
+   rxqctl = (vf_idx << FM10K_RXQCTL_VF_SHIFT) | FM10K_RXQCTL_VF;

/* stop further DMA and reset queue ownership back to VF */
for (i = vf_q_idx; i < (queues_per_pool + vf_q_idx); i++) {
-- 
1.9.3

[dpdk-dev] [PATCH 14/16] fm10k/base: minor cleanups

[Wang Xiao W]

Some cleanups to better reflect the code that was actually pushed out to
the upstream Linux community.

Signed-off-by: Wang Xiao W 
---
 drivers/net/fm10k/base/fm10k_mbx.h  |   7 --
 drivers/net/fm10k/base/fm10k_pf.h   |   4 --
 drivers/net/fm10k/base/fm10k_type.h | 132 
 3 files changed, 143 deletions(-)

diff --git a/drivers/net/fm10k/base/fm10k_mbx.h 
b/drivers/net/fm10k/base/fm10k_mbx.h
index e642c2f..edc57df 100644
--- a/drivers/net/fm10k/base/fm10k_mbx.h
+++ b/drivers/net/fm10k/base/fm10k_mbx.h
@@ -48,7 +48,6 @@ struct fm10k_mbx_info;
 /* XOR provides means of switching from Tx to Rx FIFO */
 #define FM10K_MBMEM_PF_XOR (FM10K_MBMEM_SM(0) ^ FM10K_MBMEM_PF(0))
 #define FM10K_MBX(_n)  ((_n) + 0x18800)
-#define FM10K_MBX_OWNER0x0001
 #define FM10K_MBX_REQ  0x0002
 #define FM10K_MBX_ACK  0x0004
 #define FM10K_MBX_REQ_INTERRUPT0x0008
@@ -213,7 +212,6 @@ enum fm10k_msg_type {
 /* version number for switch manager mailboxes */
 #define FM10K_SM_MBX_VERSION   1
 #define FM10K_SM_MBX_FIFO_LEN  (FM10K_MBMEM_PF_XOR - 1)
-#define FM10K_SM_MBX_FIFO_HDR_LEN  1

 /* offsets shared between all SM FIFO headers */
 #define FM10K_MSG_SM_TAIL_SHIFT0
@@ -233,18 +231,13 @@ enum fm10k_msg_type {
  */
 #define FM10K_MBX_ERR(_n) ((_n) - 512)
 #define FM10K_MBX_ERR_NO_MBX   FM10K_MBX_ERR(0x01)
-#define FM10K_MBX_ERR_NO_MSG   FM10K_MBX_ERR(0x02)
 #define FM10K_MBX_ERR_NO_SPACE FM10K_MBX_ERR(0x03)
-#define FM10K_MBX_ERR_LOCK FM10K_MBX_ERR(0x04)
 #define FM10K_MBX_ERR_TAIL FM10K_MBX_ERR(0x05)
 #define FM10K_MBX_ERR_HEAD FM10K_MBX_ERR(0x06)
-#define FM10K_MBX_ERR_DST  FM10K_MBX_ERR(0x07)
 #define FM10K_MBX_ERR_SRC  FM10K_MBX_ERR(0x08)
 #define FM10K_MBX_ERR_TYPE FM10K_MBX_ERR(0x09)
-#define FM10K_MBX_ERR_LEN  FM10K_MBX_ERR(0x0A)
 #define FM10K_MBX_ERR_SIZE FM10K_MBX_ERR(0x0B)
 #define FM10K_MBX_ERR_BUSY FM10K_MBX_ERR(0x0C)
-#define FM10K_MBX_ERR_VALUEFM10K_MBX_ERR(0x0D)
 #define FM10K_MBX_ERR_RSVD0FM10K_MBX_ERR(0x0E)
 #define FM10K_MBX_ERR_CRC  FM10K_MBX_ERR(0x0F)

diff --git a/drivers/net/fm10k/base/fm10k_pf.h 
b/drivers/net/fm10k/base/fm10k_pf.h
index ee8527a..c84b1bc 100644
--- a/drivers/net/fm10k/base/fm10k_pf.h
+++ b/drivers/net/fm10k/base/fm10k_pf.h
@@ -140,10 +140,6 @@ struct fm10k_swapi_1588_clock_owner {
 #pragma pack()
 #endif /* C99 */

-#define FM10K_PF_MSG_LPORT_CREATE_HANDLER(func) \
-   FM10K_MSG_HANDLER(FM10K_PF_MSG_ID_LPORT_CREATE, NULL, func)
-#define FM10K_PF_MSG_LPORT_DELETE_HANDLER(func) \
-   FM10K_MSG_HANDLER(FM10K_PF_MSG_ID_LPORT_DELETE, NULL, func)
 s32 fm10k_msg_lport_map_pf(struct fm10k_hw *, u32 **, struct fm10k_mbx_info *);
 extern const struct fm10k_tlv_attr fm10k_lport_map_msg_attr[];
 #define FM10K_PF_MSG_LPORT_MAP_HANDLER(func) \
diff --git a/drivers/net/fm10k/base/fm10k_type.h 
b/drivers/net/fm10k/base/fm10k_type.h
index ba0a184..3fc8f13 100644
--- a/drivers/net/fm10k/base/fm10k_type.h
+++ b/drivers/net/fm10k/base/fm10k_type.h
@@ -40,7 +40,6 @@ struct fm10k_hw;
 #include "fm10k_osdep.h"
 #include "fm10k_mbx.h"

-#define FM10K_INTEL_VENDOR_ID  0x8086
 #define FM10K_DEV_ID_PF0x15A4
 #define FM10K_DEV_ID_VF0x15A5
 #ifdef BOULDER_RAPIDS_HW
@@ -121,28 +120,16 @@ struct fm10k_hw;
 #define FM10K_CTRL_BAR4_ALLOWED0x0004

 #define FM10K_CTRL_EXT 0x0001
-#define FM10K_CTRL_EXT_NS_DIS  0x0001
-#define FM10K_CTRL_EXT_RO_DIS  0x0002
-#define FM10K_CTRL_EXT_SWITCH_LOOPBACK 0x0004
-#define FM10K_EXVET0x0002
-#define FM10K_EXVET_ETHERTYPE_MASK 0x00FF
-#define FM10K_EXVET_TAG_SIZE_SHIFT 16
-#define FM10K_EXVET_AFTER_VLAN 0x0004
 #define FM10K_GCR  0x0003
-#define FM10K_FACTPS   0x0004
 #define FM10K_GCR_EXT  0x0005

 /* Interrupt control registers */
 #define FM10K_EICR 0x0006
-#define FM10K_EICR_PCA_FAULT   0x0001
-#define FM10K_EICR_THI_FAULT   0x0004
-#define FM10K_EICR_FUM_FAULT   0x0020
 #define FM10K_EICR_FAULT_MASK  0x003F
 #define FM10K_EICR_MAILBOX 0x0040
 #define FM10K_EICR_SWITCHREADY 0x0080
 #define FM10K_EICR_SWITCHNOTREADY  0x0100
 #define FM10K_EICR_SWITCHINTERRUPT 0x0200
-#define FM10K_EICR_SRAMERROR   0x0400
 #define FM10K_EICR_VFLR0x0800
 #define FM10K_EICR_MAXHOLDTIME 0x1000
 #define FM10K_EIMR 0x0007
@@ -196,7 +183,6 @@ struct fm10k_hw

[dpdk-dev] [PATCH 16/16] fm10k/base: add macro definitions that are needed

[Wang Xiao W]

Some macros such as FM10K_RXINT_TIMER_SHIFT are removed in the share
code drop, but they are needed in dpdk/fm10k. This patch put all these
necessary macros into fm10k_osdep.h

Signed-off-by: Wang Xiao W 
---
 drivers/net/fm10k/base/fm10k_osdep.h | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/drivers/net/fm10k/base/fm10k_osdep.h 
b/drivers/net/fm10k/base/fm10k_osdep.h
index 6852ef0..869af1b 100644
--- a/drivers/net/fm10k/base/fm10k_osdep.h
+++ b/drivers/net/fm10k/base/fm10k_osdep.h
@@ -150,6 +150,36 @@ typedef intbool;
 #define fm10k_read_reg FM10K_READ_REG
 #endif

+#define FM10K_INTEL_VENDOR_ID   0x8086
+#define FM10K_DMA_CTRL_MINMSS_SHIFT9
+#define FM10K_EICR_PCA_FAULT   0x0001
+#define FM10K_EICR_THI_FAULT   0x0004
+#define FM10K_EICR_FUM_FAULT   0x0020
+#define FM10K_EICR_SRAMERROR   0x0400
+#define FM10K_SRAM_IP  0x13003
+#define FM10K_RXINT_TIMER_SHIFT8
+#define FM10K_TXINT_TIMER_SHIFT8
+#define FM10K_RXD_PKTTYPE_MASK 0x03F0
+#define FM10K_RXD_PKTTYPE_SHIFT4
+enum fm10k_rdesc_pkt_type {
+   /* L3 type */
+   FM10K_PKTTYPE_OTHER = 0x00,
+   FM10K_PKTTYPE_IPV4  = 0x01,
+   FM10K_PKTTYPE_IPV4_EX   = 0x02,
+   FM10K_PKTTYPE_IPV6  = 0x03,
+   FM10K_PKTTYPE_IPV6_EX   = 0x04,
+
+   /* L4 type */
+   FM10K_PKTTYPE_TCP   = 0x08,
+   FM10K_PKTTYPE_UDP   = 0x10,
+   FM10K_PKTTYPE_GRE   = 0x18,
+   FM10K_PKTTYPE_VXLAN = 0x20,
+   FM10K_PKTTYPE_NVGRE = 0x28,
+   FM10K_PKTTYPE_GENEVE= 0x30
+};
+#define FM10K_RXD_STATUS_IPCS  0x0008 /* Indicates IPv4 csum */
+#define FM10K_RXD_STATUS_HBO   0x0400 /* header buffer overrun */
+
 #define FM10K_TSO_MINMSS \
(FM10K_DMA_CTRL_MINMSS_64 >> FM10K_DMA_CTRL_MINMSS_SHIFT)
 #define FM10K_TSO_MIN_HEADERLEN54
-- 
1.9.3

[dpdk-dev] [PATCH 15/16] fm10k: use default mailbox message handler for pf

[Wang Xiao W]

The new share code makes fm10k_msg_update_pvid_pf function static, so we can
not refer to it now in fm10k_ethdev.c. The registered pf handler is almost the
same as the default pf handler, removing it has no impact on mailbox.

Signed-off-by: Wang Xiao W 
---
 drivers/net/fm10k/fm10k_ethdev.c | 17 ++---
 1 file changed, 2 insertions(+), 15 deletions(-)

diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index e967628..a118cf4 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -2367,29 +2367,16 @@ static const struct fm10k_msg_data fm10k_msgdata_vf[] = 
{
FM10K_TLV_MSG_ERROR_HANDLER(fm10k_tlv_msg_error),
 };

-/* Mailbox message handler in PF */
-static const struct fm10k_msg_data fm10k_msgdata_pf[] = {
-   FM10K_PF_MSG_ERR_HANDLER(XCAST_MODES, fm10k_msg_err_pf),
-   FM10K_PF_MSG_ERR_HANDLER(UPDATE_MAC_FWD_RULE, fm10k_msg_err_pf),
-   FM10K_PF_MSG_LPORT_MAP_HANDLER(fm10k_msg_lport_map_pf),
-   FM10K_PF_MSG_ERR_HANDLER(LPORT_CREATE, fm10k_msg_err_pf),
-   FM10K_PF_MSG_ERR_HANDLER(LPORT_DELETE, fm10k_msg_err_pf),
-   FM10K_PF_MSG_UPDATE_PVID_HANDLER(fm10k_msg_update_pvid_pf),
-   FM10K_TLV_MSG_ERROR_HANDLER(fm10k_tlv_msg_error),
-};
-
 static int
 fm10k_setup_mbx_service(struct fm10k_hw *hw)
 {
-   int err;
+   int err = 0;

/* Initialize mailbox lock */
fm10k_mbx_initlock(hw);

/* Replace default message handler with new ones */
-   if (hw->mac.type == fm10k_mac_pf)
-   err = hw->mbx.ops.register_handlers(&hw->mbx, fm10k_msgdata_pf);
-   else
+   if (hw->mac.type == fm10k_mac_vf)
err = hw->mbx.ops.register_handlers(&hw->mbx, fm10k_msgdata_vf);

if (err) {
-- 
1.9.3

[dpdk-dev] [PATCH v3] Patch introducing API to read/write Intel Architecture Model Specific Registers (MSR)...

[Panu Matilainen]

On 01/21/2016 10:18 AM, Wojciech Andralojc wrote:
> Patch reworked.
>
> Signed-off-by: Wojciech Andralojc 
> ---
>   lib/librte_eal/common/include/arch/x86/rte_msr.h |  88 +
>   lib/librte_eal/linuxapp/eal/Makefile |   1 +
>   lib/librte_eal/linuxapp/eal/arch/x86/rte_msr.c   | 116 
> +++
>   3 files changed, 205 insertions(+)
>   create mode 100644 lib/librte_eal/common/include/arch/x86/rte_msr.h
>   create mode 100644 lib/librte_eal/linuxapp/eal/arch/x86/rte_msr.c

This creates a new arch-specific public API, with rte_msr.h installed as 
a public header and implementation in the library (as opposed to 
inline), and so the new functions would have to be added to 
rte_eal_version.map.

However that is a bit of a problem since it only exists on IA 
architectures, so it'd mean dummy entries in the version map for all 
other architectures. All the other arch-specific APIs are inline code so 
this is the first of its kind.

Jerin Jacob suggested [1] adding these as internal (inline) functions
which to me looks like a more sensible approach, arch-specific APIs tend 
to be problematic.

[1] http://dpdk.org/ml/archives/dev/2016-January/031095.html

- Panu -

[dpdk-dev] [PATCH v3] Patch introducing API to read/write Intel Architecture Model Specific Registers (MSR)...

[Ananyev, Konstantin]

Hi Panu,

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Panu Matilainen
> Sent: Thursday, January 21, 2016 10:39 AM
> To: Andralojc, WojciechX
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3] Patch introducing API to read/write Intel 
> Architecture Model Specific Registers (MSR)...
> 
> On 01/21/2016 10:18 AM, Wojciech Andralojc wrote:
> > Patch reworked.
> >
> > Signed-off-by: Wojciech Andralojc 
> > ---
> >   lib/librte_eal/common/include/arch/x86/rte_msr.h |  88 +
> >   lib/librte_eal/linuxapp/eal/Makefile |   1 +
> >   lib/librte_eal/linuxapp/eal/arch/x86/rte_msr.c   | 116 
> > +++
> >   3 files changed, 205 insertions(+)
> >   create mode 100644 lib/librte_eal/common/include/arch/x86/rte_msr.h
> >   create mode 100644 lib/librte_eal/linuxapp/eal/arch/x86/rte_msr.c
> 
> This creates a new arch-specific public API, with rte_msr.h installed as
> a public header and implementation in the library (as opposed to
> inline), and so the new functions would have to be added to
> rte_eal_version.map.
> 
> However that is a bit of a problem since it only exists on IA
> architectures, so it'd mean dummy entries in the version map for all
> other architectures. All the other arch-specific APIs are inline code so
> this is the first of its kind.

My thought was:
1. implementation is linux specific (as I know not supposed to work under 
freebsd).
2. they are not supposed to be used at run-time cide-path, so no need to be 
inlined.
3. As I understand we plan to  have a library that will use these functions 
anyway.

About dummy entries in the .map file: if we'll create a 'weak' generic 
implementation,
that would just return an error - would it solve the issue? 

Konstantin

> 
> Jerin Jacob suggested [1] adding these as internal (inline) functions
> which to me looks like a more sensible approach, arch-specific APIs tend
> to be problematic.
> 
> [1] http://dpdk.org/ml/archives/dev/2016-January/031095.html
> 
>   - Panu -

[dpdk-dev] [PATCH v2 0/3] Keep-alive stats and doc fixes

[Harry van Haaren]

This patchset contains:
1. Fix variable naming consistency in sample guide
2. Set last_seen time on core when it gets registered
3. An xstats implementation for last-seen and current core status

v2:
-Refactor to remove rte_ethdev.h include

Harry van Haaren (3):
  doc: fix keepalive sample app guide
  eal: add keepalive core register timestamp
  keepalive: add rte_keepalive_xstats_get() and example

 doc/guides/rel_notes/release_2_3.rst|  6 +++
 doc/guides/sample_app_ug/keep_alive.rst | 30 +-
 examples/l2fwd-keepalive/main.c | 23 +--
 lib/librte_eal/bsdapp/eal/rte_eal_version.map   |  7 
 lib/librte_eal/common/include/rte_keepalive.h   | 28 -
 lib/librte_eal/common/rte_keepalive.c   | 52 -
 lib/librte_eal/linuxapp/eal/rte_eal_version.map |  7 
 7 files changed, 138 insertions(+), 15 deletions(-)

-- 
2.5.0

[dpdk-dev] [PATCH v2 1/3] doc: fix keepalive sample app guide

[Harry van Haaren]

This patch fixes some mismatches between the keepalive code
and the docs. Struct names, and descriptions are not in line
with the codebase.

Fixes: e64833f2273a ("examples/l2fwd-keepalive: add sample application")

Signed-off-by: Harry van Haaren 
---
 doc/guides/sample_app_ug/keep_alive.rst | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/doc/guides/sample_app_ug/keep_alive.rst 
b/doc/guides/sample_app_ug/keep_alive.rst
index 080811b..1478faf 100644
--- a/doc/guides/sample_app_ug/keep_alive.rst
+++ b/doc/guides/sample_app_ug/keep_alive.rst
@@ -1,6 +1,6 @@

 ..  BSD LICENSE
-Copyright(c) 2015 Intel Corporation. All rights reserved.
+Copyright(c) 2015-2016 Intel Corporation. All rights reserved.
 All rights reserved.

 Redistribution and use in source and binary forms, with or without
@@ -143,17 +143,17 @@ The Keep-Alive/'Liveliness' conceptual scheme:
 The following sections provide some explanation of the code aspects
 that are specific to the Keep Alive sample application.

-The heartbeat functionality is initialized with a struct
-rte_heartbeat and the callback function to invoke in the
+The keepalive functionality is initialized with a struct
+rte_keepalive and the callback function to invoke in the
 case of a timeout.

 .. code-block:: c

 rte_global_keepalive_info = rte_keepalive_create(&dead_core, NULL);
-if (rte_global_hbeat_info == NULL)
+if (rte_global_keepalive_info == NULL)
 rte_exit(EXIT_FAILURE, "keepalive_create() failed");

-The function that issues the pings hbeat_dispatch_pings()
+The function that issues the pings keepalive_dispatch_pings()
 is configured to run every check_period milliseconds.

 .. code-block:: c
@@ -162,7 +162,8 @@ is configured to run every check_period milliseconds.
 (check_period * rte_get_timer_hz()) / 1000,
 PERIODICAL,
 rte_lcore_id(),
-&hbeat_dispatch_pings, rte_global_keepalive_info
+&rte_keepalive_dispatch_pings,
+rte_global_keepalive_info
 ) != 0 )
 rte_exit(EXIT_FAILURE, "Keepalive setup failure.\n");

@@ -173,7 +174,7 @@ functionality and the example random failures.

 .. code-block:: c

-rte_keepalive_mark_alive(&rte_global_hbeat_info);
+rte_keepalive_mark_alive(&rte_global_keepalive_info);
 cur_tsc = rte_rdtsc();

 /* Die randomly within 7 secs for demo purposes.. */
@@ -185,7 +186,7 @@ The rte_keepalive_mark_alive function simply sets the core 
state to alive.
 .. code-block:: c

 static inline void
-rte_keepalive_mark_alive(struct rte_heartbeat *keepcfg)
+rte_keepalive_mark_alive(struct rte_keepalive *keepcfg)
 {
-keepcfg->state_flags[rte_lcore_id()] = 1;
+keepcfg->state_flags[rte_lcore_id()] = ALIVE;
 }
-- 
2.5.0

[dpdk-dev] [PATCH v2 2/3] eal: add keepalive core register timestamp

[Harry van Haaren]

This patch sets a timestamp on each lcore when it is registered
for keepalive. This causes the first values read by the monitor
to show time since the core was registered, instead of the delta
between 0 and the timestamp counter.

Signed-off-by: Harry van Haaren 
---
 lib/librte_eal/common/rte_keepalive.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lib/librte_eal/common/rte_keepalive.c 
b/lib/librte_eal/common/rte_keepalive.c
index 736fd0f..5358322 100644
--- a/lib/librte_eal/common/rte_keepalive.c
+++ b/lib/librte_eal/common/rte_keepalive.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 

 static void
 print_trace(const char *msg, struct rte_keepalive *keepcfg, int idx_core)
@@ -108,6 +109,8 @@ rte_keepalive_create(rte_keepalive_failure_callback_t 
callback,
 void
 rte_keepalive_register_core(struct rte_keepalive *keepcfg, const int id_core)
 {
-   if (id_core < RTE_KEEPALIVE_MAXCORES)
+   if (id_core < RTE_KEEPALIVE_MAXCORES) {
keepcfg->active_cores[id_core] = 1;
+   keepcfg->last_alive[id_core] = rte_rdtsc();
+   }
 }
-- 
2.5.0

[dpdk-dev] [PATCH v2 3/3] keepalive: add rte_keepalive_xstats_get() and example

[Harry van Haaren]

This patch adds a function that exposes keepalive statistics
using a rte_keepalive_xstats struct. The function provides
the client API the opportunity to read last-seen and status of
each core.

Signed-off-by: Harry van Haaren 
---
 doc/guides/rel_notes/release_2_3.rst|  6 
 doc/guides/sample_app_ug/keep_alive.rst | 11 ++
 examples/l2fwd-keepalive/main.c | 23 ++--
 lib/librte_eal/bsdapp/eal/rte_eal_version.map   |  7 
 lib/librte_eal/common/include/rte_keepalive.h   | 28 ++-
 lib/librte_eal/common/rte_keepalive.c   | 47 -
 lib/librte_eal/linuxapp/eal/rte_eal_version.map |  7 
 7 files changed, 124 insertions(+), 5 deletions(-)

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

+* **Keep Alive xstats**
+
+  A function ``rte_keepalive_xstats_get()`` has been added to the
+  keepalive header, allowing the retrieval of keepalive statistics
+  such as last-alive-time and the status of each core registered
+  for monitoring. The API reflects that of the existing xstats API.

 Resolved Issues
 ---
diff --git a/doc/guides/sample_app_ug/keep_alive.rst 
b/doc/guides/sample_app_ug/keep_alive.rst
index 1478faf..7c2d2a4 100644
--- a/doc/guides/sample_app_ug/keep_alive.rst
+++ b/doc/guides/sample_app_ug/keep_alive.rst
@@ -190,3 +190,14 @@ The rte_keepalive_mark_alive function simply sets the core 
state to alive.
 {
 keepcfg->state_flags[rte_lcore_id()] = ALIVE;
 }
+
+Keepalive exposes its statistics using an API very similar to the xstats API.
+This allows client code to call the function and retrieve the current status
+of keepalive, providing information like last-alive time and status per-core.
+
+.. code-block:: c
+
+nstats = rte_keepalive_xstats_get(rte_global_keepalive_info, xstats,
+  nstats);
+for (i = 0; i < nstats; i++)
+printf("%s : %lu\n", xstats[i].name, xstats[i].value);
diff --git a/examples/l2fwd-keepalive/main.c b/examples/l2fwd-keepalive/main.c
index f4d52f2..34c6d62 100644
--- a/examples/l2fwd-keepalive/main.c
+++ b/examples/l2fwd-keepalive/main.c
@@ -1,7 +1,7 @@
 /*-
  *   BSD LICENSE
  *
- *   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+ *   Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
  *   All rights reserved.
  *
  *   Redistribution and use in source and binary forms, with or without
@@ -66,6 +66,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -139,7 +140,7 @@ struct l2fwd_port_statistics 
port_statistics[RTE_MAX_ETHPORTS];
 /* A tsc-based timer responsible for triggering statistics printout */
 #define TIMER_MILLISECOND 1
 #define MAX_TIMER_PERIOD 86400 /* 1 day max */
-static int64_t timer_period = 10 * TIMER_MILLISECOND * 1000; /* 10 seconds */
+static int64_t timer_period = 1 * TIMER_MILLISECOND * 1000; /* 1 second */
 static int64_t check_period = 5; /* default check cycle is 5ms */

 /* Keepalive structure */
@@ -189,7 +190,23 @@ print_stats(__attribute__((unused)) struct rte_timer 
*ptr_timer,
   total_packets_tx,
   total_packets_rx,
   total_packets_dropped);
-   printf("\n\n");
+   printf("\nKeep Alive xstats ==\n");
+
+   /* Keepalive Xstats */
+   unsigned nstats = rte_keepalive_xstats_get(rte_global_keepalive_info,
+  0, 0);
+   struct rte_keepalive_xstats *xstats =
+   rte_zmalloc("RTE_KEEPALIVE_XSTATS",
+   sizeof(struct rte_keepalive_xstats) * nstats,
+   RTE_CACHE_LINE_SIZE);
+
+   nstats = rte_keepalive_xstats_get(rte_global_keepalive_info, xstats,
+ nstats);
+   unsigned i;
+   for (i = 0; i < nstats; i++)
+   printf("%s\t%lu\n", xstats[i].name, xstats[i].value);
+   printf("\n");
+   rte_free(xstats);
 }

 /* Send the burst of packets on an output interface */
diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map 
b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
index 9d7adf1..ff1cbc7 100644
--- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
@@ -135,3 +135,10 @@ DPDK_2.2 {
rte_xen_dom0_supported;

 } DPDK_2.1;
+
+DPDK_2.3 {
+   global:
+
+   rte_keepalive_xstats_get;
+
+} DPDK_2.2;
diff --git a/lib/librte_eal/common/include/rte_keepalive.h 
b/lib/librte_eal/common/include/rte_keepalive.h
index 02472c0..f98b92c 100644
--- a/lib/librte_eal/common/include/rte_keepa

[dpdk-dev] [RFC PATCH 0/5] virtio: Add a new layer to abstract pci access method

[Tetsuya Mukawa]

This patch series are not for upstreaming.

It describe how to use a new access method abstraction of "virtio-pci.c".
Because of this, some patches are not for upstreaming.

For example, below changes will be shared with Jianfeng's patches.
So these changes are just temporary.
 - "--shm" option to allocate EAL memory.
 - Some changes to access to EAL memory by virtual address.

Anyway, some changes are not for upstreaming, but virtual virtio-net PMD
should work with QEMU as described in commit log.

Tetsuya Mukawa (5):
  virtio: Change the parameter order of io_write8/16/32()
  virtio: move rte_eal_pci_unmap_device() to virtio_pci.c
  virtio: Add a new layer to abstract pci access method
  EAL: Add new EAL "--shm" option.
  virtio: Extend virtio-net PMD to support container environment

 config/common_linuxapp |1 +
 drivers/net/virtio/Makefile|4 +
 drivers/net/virtio/qtest.c | 1237 
 drivers/net/virtio/virtio_ethdev.c |  454 --
 drivers/net/virtio/virtio_ethdev.h |   12 +
 drivers/net/virtio/virtio_pci.c|  732 
 drivers/net/virtio/virtio_pci.h|   39 +-
 drivers/net/virtio/virtio_rxtx.c   |3 +-
 drivers/net/virtio/virtqueue.h |9 +-
 lib/librte_eal/common/eal_common_options.c |5 +
 lib/librte_eal/common/eal_internal_cfg.h   |1 +
 lib/librte_eal/common/eal_options.h|2 +
 lib/librte_eal/common/include/rte_memory.h |5 +
 lib/librte_eal/linuxapp/eal/eal_memory.c   |   76 ++
 14 files changed, 2337 insertions(+), 243 deletions(-)
 create mode 100644 drivers/net/virtio/qtest.c

-- 
2.1.4

[dpdk-dev] [RFC PATCH 1/5] virtio: Change the parameter order of io_write8/16/32()

[Tetsuya Mukawa]

The patch change the parameter order of below functions.
 - io_write8()
 - io_write16()
 - io_write32()
This changig are needed to add a new layer to abstract accessing
method.

Signed-off-by: Tetsuya Mukawa 
---
 drivers/net/virtio/virtio_pci.c | 66 -
 1 file changed, 33 insertions(+), 33 deletions(-)

diff --git a/drivers/net/virtio/virtio_pci.c b/drivers/net/virtio/virtio_pci.c
index 6b87429..0aeffb7 100644
--- a/drivers/net/virtio/virtio_pci.c
+++ b/drivers/net/virtio/virtio_pci.c
@@ -478,7 +478,7 @@ io_read##nr_bits(type *addr)\

 #define IO_WRITE_DEF(nr_bits, type)\
 static inline void \
-io_write##nr_bits(type val, type *addr)\
+io_write##nr_bits(type *addr, type val)\
 {  \
*(volatile type *)addr = val;   \
 }
@@ -493,10 +493,10 @@ IO_READ_DEF (32, uint32_t)
 IO_WRITE_DEF(32, uint32_t)

 static inline void
-io_write64_twopart(uint64_t val, uint32_t *lo, uint32_t *hi)
+io_write64_twopart(uint32_t *lo, uint32_t *hi, uint64_t val)
 {
-   io_write32(val & ((1ULL << 32) - 1), lo);
-   io_write32(val >> 32,hi);
+   io_write32(lo, val & ((1ULL << 32) - 1));
+   io_write32(hi, val >> 32);
 }

 static void
@@ -526,7 +526,7 @@ modern_write_dev_config(struct virtio_hw *hw, size_t offset,
const uint8_t *p = src;

for (i = 0;  i < length; i++)
-   io_write8(*p++, (uint8_t *)hw->dev_cfg + offset + i);
+   io_write8((uint8_t *)hw->dev_cfg + offset + i, *p++);
 }

 static uint64_t
@@ -534,10 +534,10 @@ modern_get_features(struct virtio_hw *hw)
 {
uint32_t features_lo, features_hi;

-   io_write32(0, &hw->common_cfg->device_feature_select);
+   io_write32(&hw->common_cfg->device_feature_select, 0);
features_lo = io_read32(&hw->common_cfg->device_feature);

-   io_write32(1, &hw->common_cfg->device_feature_select);
+   io_write32(&hw->common_cfg->device_feature_select, 1);
features_hi = io_read32(&hw->common_cfg->device_feature);

return ((uint64_t)features_hi << 32) | features_lo;
@@ -546,13 +546,13 @@ modern_get_features(struct virtio_hw *hw)
 static void
 modern_set_features(struct virtio_hw *hw, uint64_t features)
 {
-   io_write32(0, &hw->common_cfg->guest_feature_select);
-   io_write32(features & ((1ULL << 32) - 1),
-   &hw->common_cfg->guest_feature);
+   io_write32(&hw->common_cfg->guest_feature_select, 0);
+   io_write32(&hw->common_cfg->guest_feature,
+  features & ((1ULL << 32) - 1));

-   io_write32(1, &hw->common_cfg->guest_feature_select);
-   io_write32(features >> 32,
-   &hw->common_cfg->guest_feature);
+   io_write32(&hw->common_cfg->guest_feature_select, 1);
+   io_write32(&hw->common_cfg->guest_feature,
+  features >> 32);
 }

 static uint8_t
@@ -564,7 +564,7 @@ modern_get_status(struct virtio_hw *hw)
 static void
 modern_set_status(struct virtio_hw *hw, uint8_t status)
 {
-   io_write8(status, &hw->common_cfg->device_status);
+   io_write8(&hw->common_cfg->device_status, status);
 }

 static void
@@ -583,14 +583,14 @@ modern_get_isr(struct virtio_hw *hw)
 static uint16_t
 modern_set_config_irq(struct virtio_hw *hw, uint16_t vec)
 {
-   io_write16(vec, &hw->common_cfg->msix_config);
+   io_write16(&hw->common_cfg->msix_config, vec);
return io_read16(&hw->common_cfg->msix_config);
 }

 static uint16_t
 modern_get_queue_num(struct virtio_hw *hw, uint16_t queue_id)
 {
-   io_write16(queue_id, &hw->common_cfg->queue_select);
+   io_write16(&hw->common_cfg->queue_select, queue_id);
return io_read16(&hw->common_cfg->queue_size);
 }

@@ -606,20 +606,20 @@ modern_setup_queue(struct virtio_hw *hw, struct virtqueue 
*vq)
 ring[vq->vq_nentries]),
   VIRTIO_PCI_VRING_ALIGN);

-   io_write16(vq->vq_queue_index, &hw->common_cfg->queue_select);
+   io_write16(&hw->common_cfg->queue_select, vq->vq_queue_index);

-   io_write64_twopart(desc_addr, &hw->common_cfg->queue_desc_lo,
- &hw->common_cfg->queue_desc_hi);
-   io_write64_twopart(avail_addr, &hw->common_cfg->queue_avail_lo,
-  &hw->common_cfg->queue_avail_hi);
-   io_write64_twopart(used_addr, &hw->common_cfg->queue_used_lo,
- &hw->common_cfg->queue_used_hi);
+   io_write64_twopart(&hw->common_cfg->queue_desc_lo,
+  &hw->common_cfg->queue_desc_hi, desc_addr);
+   io_write64_twopart(&hw->common_cfg->queue_avail_lo,
+  &hw->common_cfg->queue_avail_hi, avail_addr);
+   io_write64_twopart(&hw->common_cfg->queue_used_lo,
+  &hw->com

[dpdk-dev] [RFC PATCH 2/5] virtio: move rte_eal_pci_unmap_device() to virtio_pci.c

[Tetsuya Mukawa]

To abstract pci access method, the patch moves below function
to "virtio_pci.c".
 - rte_eal_pci_unmap_device()

Signed-off-by: Tetsuya Mukawa 
---
 drivers/net/virtio/virtio_ethdev.c |  2 +-
 drivers/net/virtio/virtio_pci.c| 11 +++
 drivers/net/virtio/virtio_pci.h|  1 +
 3 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c
index deb0382..37833a8 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -1177,7 +1177,7 @@ eth_virtio_dev_uninit(struct rte_eth_dev *eth_dev)
rte_intr_callback_unregister(&pci_dev->intr_handle,
virtio_interrupt_handler,
eth_dev);
-   rte_eal_pci_unmap_device(pci_dev);
+   vtpci_uninit(pci_dev, hw);

PMD_INIT_LOG(DEBUG, "dev_uninit completed");

diff --git a/drivers/net/virtio/virtio_pci.c b/drivers/net/virtio/virtio_pci.c
index 0aeffb7..7d7ef06 100644
--- a/drivers/net/virtio/virtio_pci.c
+++ b/drivers/net/virtio/virtio_pci.c
@@ -878,3 +878,14 @@ vtpci_init(struct rte_pci_device *dev, struct virtio_hw 
*hw)

return 0;
 }
+
+void
+vtpci_uninit(struct rte_pci_device *dev, struct virtio_hw *hw)
+{
+   hw->dev  = NULL;
+   hw->vtpci_ops = NULL;
+   hw->use_msix = 0;
+   hw->io_base  = 0;
+   hw->modern   = 0;
+   rte_eal_pci_unmap_device(dev);
+}
diff --git a/drivers/net/virtio/virtio_pci.h b/drivers/net/virtio/virtio_pci.h
index 0544a07..17c7972 100644
--- a/drivers/net/virtio/virtio_pci.h
+++ b/drivers/net/virtio/virtio_pci.h
@@ -328,6 +328,7 @@ vtpci_with_feature(struct virtio_hw *hw, uint64_t bit)
  * Function declaration from virtio_pci.c
  */
 int vtpci_init(struct rte_pci_device *, struct virtio_hw *);
+void vtpci_uninit(struct rte_pci_device *dev, struct virtio_hw *);
 void vtpci_reset(struct virtio_hw *);

 void vtpci_reinit_complete(struct virtio_hw *);
-- 
2.1.4

[dpdk-dev] [RFC PATCH 3/5] virtio: Add a new layer to abstract pci access method

[Tetsuya Mukawa]

This patch addss function pointers to abstract pci access method.
This abstraction layer will be used when virtio-net PMD supports
container extension.

The below functions abstract how to access to pci configuration space.

struct virtio_pci_cfg_ops {
int   (*map)(...);
void  (*unmap)(...);
void *(*get_mapped_addr)(...);
int   (*read)(...);
};

The pci configuration space has information how to access to virtio
device registers. Basically, there are 2 ways to acccess to the
registers. One is using portio and the other is using mapped memory.
The below functions abstract this access method.

struct virtio_pci_dev_ops {
uint8_t  (*read8)(...);
uint16_t (*read16)(...);
uint32_t (*read32)(...);
void (*write8)(...);
void (*write16)(...);
void (*write32)(...);
};

Signed-off-by: Tetsuya Mukawa 
---
 drivers/net/virtio/virtio_ethdev.c |   4 +-
 drivers/net/virtio/virtio_pci.c| 519 ++---
 drivers/net/virtio/virtio_pci.h|  24 +-
 3 files changed, 386 insertions(+), 161 deletions(-)

diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c
index 37833a8..c477b05 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -1037,7 +1037,7 @@ eth_virtio_dev_init(struct rte_eth_dev *eth_dev)

pci_dev = eth_dev->pci_dev;

-   if (vtpci_init(pci_dev, hw) < 0)
+   if (vtpci_init(eth_dev, hw) < 0)
return -1;

/* Reset the device although not necessary at startup */
@@ -1177,7 +1177,7 @@ eth_virtio_dev_uninit(struct rte_eth_dev *eth_dev)
rte_intr_callback_unregister(&pci_dev->intr_handle,
virtio_interrupt_handler,
eth_dev);
-   vtpci_uninit(pci_dev, hw);
+   vtpci_uninit(eth_dev, hw);

PMD_INIT_LOG(DEBUG, "dev_uninit completed");

diff --git a/drivers/net/virtio/virtio_pci.c b/drivers/net/virtio/virtio_pci.c
index 7d7ef06..98eef85 100644
--- a/drivers/net/virtio/virtio_pci.c
+++ b/drivers/net/virtio/virtio_pci.c
@@ -49,24 +49,198 @@
 #define PCI_CAPABILITY_LIST0x34
 #define PCI_CAP_ID_VNDR0x09

+static uint8_t
+phys_legacy_read8(struct virtio_hw *hw, uint8_t *addr)
+{
+   return inb((unsigned short)(hw->io_base + (uint64_t)addr));
+}

-#define VIRTIO_PCI_REG_ADDR(hw, reg) \
-   (unsigned short)((hw)->io_base + (reg))
+static uint16_t
+phys_legacy_read16(struct virtio_hw *hw, uint16_t *addr)
+{
+   return inw((unsigned short)(hw->io_base + (uint64_t)addr));
+}

-#define VIRTIO_READ_REG_1(hw, reg) \
-   inb((VIRTIO_PCI_REG_ADDR((hw), (reg
-#define VIRTIO_WRITE_REG_1(hw, reg, value) \
-   outb_p((unsigned char)(value), (VIRTIO_PCI_REG_ADDR((hw), (reg
+static uint32_t
+phys_legacy_read32(struct virtio_hw *hw, uint32_t *addr)
+{
+   return inl((unsigned short)(hw->io_base + (uint64_t)addr));
+}

-#define VIRTIO_READ_REG_2(hw, reg) \
-   inw((VIRTIO_PCI_REG_ADDR((hw), (reg
-#define VIRTIO_WRITE_REG_2(hw, reg, value) \
-   outw_p((unsigned short)(value), (VIRTIO_PCI_REG_ADDR((hw), (reg
+static void
+phys_legacy_write8(struct virtio_hw *hw, uint8_t *addr, uint8_t val)
+{
+   return outb_p((unsigned char)val,
+   (unsigned short)(hw->io_base + (uint64_t)addr));
+}

-#define VIRTIO_READ_REG_4(hw, reg) \
-   inl((VIRTIO_PCI_REG_ADDR((hw), (reg
-#define VIRTIO_WRITE_REG_4(hw, reg, value) \
-   outl_p((unsigned int)(value), (VIRTIO_PCI_REG_ADDR((hw), (reg
+static void
+phys_legacy_write16(struct virtio_hw *hw, uint16_t *addr, uint16_t val)
+{
+   return outb_p((unsigned short)val,
+   (unsigned short)(hw->io_base + (uint64_t)addr));
+}
+
+static void
+phys_legacy_write32(struct virtio_hw *hw, uint32_t *addr, uint32_t val)
+{
+   return outb_p((unsigned int)val,
+   (unsigned short)(hw->io_base + (uint64_t)addr));
+}
+
+static const struct virtio_pci_dev_ops phys_legacy_dev_ops = {
+   .read8  = phys_legacy_read8,
+   .read16 = phys_legacy_read16,
+   .read32 = phys_legacy_read32,
+   .write8 = phys_legacy_write8,
+   .write16= phys_legacy_write16,
+   .write32= phys_legacy_write32,
+};
+
+static uint8_t
+phys_modern_read8(struct virtio_hw *hw __rte_unused, uint8_t *addr)
+{
+   return *(volatile uint8_t *)addr;
+}
+
+static uint16_t
+phys_modern_read16(struct virtio_hw *hw __rte_unused, uint16_t *addr)
+{
+   return *(volatile uint16_t *)addr;
+}
+
+static uint32_t
+phys_modern_read32(struct virtio_hw *hw __rte_unused, uint32_t *addr)
+{
+   return *(volatile uint32_t *)addr;
+}
+
+static void
+phys_modern_write8(struct virtio_hw *hw __rte_unused,
+   uint8_t *addr, uint8_t val)
+{
+   *(volatile uint8_t *)addr = val;
+}
+
+static 

[dpdk-dev] [RFC PATCH 4/5] EAL: Add new EAL "--shm" option.

[Tetsuya Mukawa]

This is a temporary patch to get EAL memory under 16T(1 << 44).

The patch adds new EAL "--shm" option. If the option is specified,
EAL will allocate one file from hugetlbfs. This memory is for sharing
memory between DPDK applicaiton and QEMU ivhsmem device.

Signed-off-by: Tetsuya Mukawa 
---
 lib/librte_eal/common/eal_common_options.c |  5 ++
 lib/librte_eal/common/eal_internal_cfg.h   |  1 +
 lib/librte_eal/common/eal_options.h|  2 +
 lib/librte_eal/common/include/rte_memory.h |  5 ++
 lib/librte_eal/linuxapp/eal/eal_memory.c   | 76 ++
 5 files changed, 89 insertions(+)

diff --git a/lib/librte_eal/common/eal_common_options.c 
b/lib/librte_eal/common/eal_common_options.c
index 29942ea..a752bf3 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -86,6 +86,7 @@ eal_long_options[] = {
{OPT_NO_HUGE,   0, NULL, OPT_NO_HUGE_NUM  },
{OPT_NO_PCI,0, NULL, OPT_NO_PCI_NUM   },
{OPT_NO_SHCONF, 0, NULL, OPT_NO_SHCONF_NUM},
+   {OPT_SHM,   0, NULL, OPT_SHM_NUM  },
{OPT_PCI_BLACKLIST, 1, NULL, OPT_PCI_BLACKLIST_NUM},
{OPT_PCI_WHITELIST, 1, NULL, OPT_PCI_WHITELIST_NUM},
{OPT_PROC_TYPE, 1, NULL, OPT_PROC_TYPE_NUM},
@@ -834,6 +835,10 @@ eal_parse_common_option(int opt, const char *optarg,
conf->no_hugetlbfs = 1;
break;

+   case OPT_SHM_NUM:
+   conf->shm = 1;
+   break;
+
case OPT_NO_PCI_NUM:
conf->no_pci = 1;
break;
diff --git a/lib/librte_eal/common/eal_internal_cfg.h 
b/lib/librte_eal/common/eal_internal_cfg.h
index 5f1367e..362ce12 100644
--- a/lib/librte_eal/common/eal_internal_cfg.h
+++ b/lib/librte_eal/common/eal_internal_cfg.h
@@ -66,6 +66,7 @@ struct internal_config {
volatile unsigned no_hugetlbfs;   /**< true to disable hugetlbfs */
unsigned hugepage_unlink; /**< true to unlink backing files */
volatile unsigned xen_dom0_support; /**< support app running on Xen 
Dom0*/
+   volatile unsigned shm;/**< true to create shared memory for 
ivshmem */
volatile unsigned no_pci; /**< true to disable PCI */
volatile unsigned no_hpet;/**< true to disable HPET */
volatile unsigned vmware_tsc_map; /**< true to use VMware TSC mapping
diff --git a/lib/librte_eal/common/eal_options.h 
b/lib/librte_eal/common/eal_options.h
index a881c62..c1e586a 100644
--- a/lib/librte_eal/common/eal_options.h
+++ b/lib/librte_eal/common/eal_options.h
@@ -55,6 +55,8 @@ enum {
OPT_HUGE_DIR_NUM,
 #define OPT_HUGE_UNLINK   "huge-unlink"
OPT_HUGE_UNLINK_NUM,
+#define OPT_SHM   "shm"
+   OPT_SHM_NUM,
 #define OPT_LCORES"lcores"
OPT_LCORES_NUM,
 #define OPT_LOG_LEVEL "log-level"
diff --git a/lib/librte_eal/common/include/rte_memory.h 
b/lib/librte_eal/common/include/rte_memory.h
index 9c9e40f..3ad155b 100644
--- a/lib/librte_eal/common/include/rte_memory.h
+++ b/lib/librte_eal/common/include/rte_memory.h
@@ -102,6 +102,7 @@ struct rte_memseg {
int32_t socket_id;  /**< NUMA socket ID. */
uint32_t nchannel;  /**< Number of channels. */
uint32_t nrank; /**< Number of ranks. */
+   int fd; /**< fd used for share this memory */
 #ifdef RTE_LIBRTE_XEN_DOM0
 /**< store segment MFNs */
uint64_t mfn[DOM0_NUM_MEMBLOCK];
@@ -130,6 +131,10 @@ int rte_mem_lock_page(const void *virt);
  */
 phys_addr_t rte_mem_virt2phy(const void *virt);

+
+int
+rte_memseg_info_get(int index, int *pfd, uint64_t *psize, void **paddr);
+
 /**
  * Get the layout of the available physical memory.
  *
diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c 
b/lib/librte_eal/linuxapp/eal/eal_memory.c
index 846fd31..7122f16 100644
--- a/lib/librte_eal/linuxapp/eal/eal_memory.c
+++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
@@ -150,6 +150,21 @@ rte_mem_lock_page(const void *virt)
return mlock((void*)aligned, page_size);
 }

+int
+rte_memseg_info_get(int index, int *pfd, uint64_t *psize, void **paddr)
+{
+   struct rte_mem_config *mcfg;
+   mcfg = rte_eal_get_configuration()->mem_config;
+
+   if (pfd != NULL)
+   *pfd = mcfg->memseg[index].fd;
+   if (psize != NULL)
+   *psize = (uint64_t)mcfg->memseg[index].len;
+   if (paddr != NULL)
+   *paddr = (void *)(uint64_t)mcfg->memseg[index].addr;
+   return 0;
+}
+
 /*
  * Get physical address of any mapped virtual address in the current process.
  */
@@ -1075,6 +1090,46 @@ calc_num_pages_per_socket(uint64_t * memory,
return total_num_pages;
 }

+static void *
+rte_eal_shm_create(int *pfd, const char *hugedir)
+{
+   int ret, fd;
+   char filepath[256];
+   void *vaddr;
+ 

[dpdk-dev] [RFC PATCH 5/5] virtio: Extend virtio-net PMD to support container environment

[Tetsuya Mukawa]

virtio: Extend virtio-net PMD to support container environment

The patch adds a new virtio-net PMD configuration that allows the PMD to
work on host as if the PMD is in VM.
Here is new configuration for virtio-net PMD.
 - CONFIG_RTE_LIBRTE_VIRTIO_HOST_MODE
To use this mode, EAL needs physically contiguous memory. To allocate
such memory, add "--shm" option to application command line.

To prepare virtio-net device on host, the users need to invoke QEMU
process in special qtest mode. This mode is mainly used for testing QEMU
devices from outer process. In this mode, no guest runs.
Here is QEMU command line.

 $ qemu-system-x86_64 \
 -machine pc-i440fx-1.4,accel=qtest \
 -display none -qtest-log /dev/null \
 -qtest unix:/tmp/socket,server \
 -netdev type=tap,script=/etc/qemu-ifup,id=net0,queues=1\
 -device virtio-net-pci,netdev=net0,mq=on \
 -chardev socket,id=chr1,path=/tmp/ivshmem,server \
 -device ivshmem,size=1G,chardev=chr1,vectors=1

 * QEMU process is needed per port.
 * Virtio-1.0 device is supported.
 * In most cases, just using above command is enough.
 * The vhost backends like vhost-net and vhost-user can be specified.
 * Only checked "pc-i440fx-1.4" machine, but may work with other
   machines. It depends on a machine has piix3 south bridge.
   If the machine doesn't have, virtio-net PMD cannot receive status
   changed interrupts.
 * Should not add "--enable-kvm" to QEMU command line.

After invoking QEMU, the PMD can connect to QEMU process using unix
domain sockets. Over these sockets, virtio-net, ivshmem and piix3
device in QEMU are probed by the PMD.
Here is example of command line.

 $ testpmd -c f -n 1 -m 1024 --shm \
  --vdev="eth_virtio_net0,qtest=/tmp/socket,ivshmem=/tmp/ivshmem"\
  -- --disable-hw-vlan --txqflags=0xf00 -i

Please specify same unix domain sockets and memory size in both QEMU
and DPDK command lines like above.
The share memory size should be power of 2, because ivshmem only
accepts such memry size.

Signed-off-by: Tetsuya Mukawa 
---
 config/common_linuxapp |1 +
 drivers/net/virtio/Makefile|4 +
 drivers/net/virtio/qtest.c | 1237 
 drivers/net/virtio/virtio_ethdev.c |  450 ++---
 drivers/net/virtio/virtio_ethdev.h |   12 +
 drivers/net/virtio/virtio_pci.c|  190 +-
 drivers/net/virtio/virtio_pci.h|   16 +
 drivers/net/virtio/virtio_rxtx.c   |3 +-
 drivers/net/virtio/virtqueue.h |9 +-
 9 files changed, 1845 insertions(+), 77 deletions(-)
 create mode 100644 drivers/net/virtio/qtest.c

diff --git a/config/common_linuxapp b/config/common_linuxapp
index 74bc515..04682f6 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -269,6 +269,7 @@ CONFIG_RTE_LIBRTE_PMD_SZEDATA2=n
 # Compile burst-oriented VIRTIO PMD driver
 #
 CONFIG_RTE_LIBRTE_VIRTIO_PMD=y
+CONFIG_RTE_LIBRTE_VIRTIO_HOST_MODE=y
 CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_INIT=n
 CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_RX=n
 CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_TX=n
diff --git a/drivers/net/virtio/Makefile b/drivers/net/virtio/Makefile
index 43835ba..697e629 100644
--- a/drivers/net/virtio/Makefile
+++ b/drivers/net/virtio/Makefile
@@ -52,6 +52,10 @@ SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_rxtx.c
 SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_ethdev.c
 SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_rxtx_simple.c

+ifeq ($(CONFIG_RTE_LIBRTE_VIRTIO_HOST_MODE),y)
+   SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += qtest.c
+endif
+
 # this lib depends upon:
 DEPDIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += lib/librte_eal lib/librte_ether
 DEPDIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += lib/librte_mempool lib/librte_mbuf
diff --git a/drivers/net/virtio/qtest.c b/drivers/net/virtio/qtest.c
new file mode 100644
index 000..717bee9
--- /dev/null
+++ b/drivers/net/virtio/qtest.c
@@ -0,0 +1,1237 @@
+/*-
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2015 IGEL Co., Ltd. All rights reserved.
+ *   All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of IGEL Co., Ltd. nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES

[dpdk-dev] [RFC PATCH 0/5] virtio: Add a new layer to abstract pci access method

[Tetsuya Mukawa]

On 2016/01/21 20:07, Tetsuya Mukawa wrote:
> This patch series are not for upstreaming.
>
> It describe how to use a new access method abstraction of "virtio-pci.c".
> Because of this, some patches are not for upstreaming.
>
> For example, below changes will be shared with Jianfeng's patches.
> So these changes are just temporary.
>  - "--shm" option to allocate EAL memory.
>  - Some changes to access to EAL memory by virtual address.
>
> Anyway, some changes are not for upstreaming, but virtual virtio-net PMD
> should work with QEMU as described in commit log.
>
> Tetsuya Mukawa (5):
>   virtio: Change the parameter order of io_write8/16/32()
>   virtio: move rte_eal_pci_unmap_device() to virtio_pci.c
>   virtio: Add a new layer to abstract pci access method
>   EAL: Add new EAL "--shm" option.
>   virtio: Extend virtio-net PMD to support container environment
>
>  config/common_linuxapp |1 +
>  drivers/net/virtio/Makefile|4 +
>  drivers/net/virtio/qtest.c | 1237 
> 
>  drivers/net/virtio/virtio_ethdev.c |  454 --
>  drivers/net/virtio/virtio_ethdev.h |   12 +
>  drivers/net/virtio/virtio_pci.c|  732 
>  drivers/net/virtio/virtio_pci.h|   39 +-
>  drivers/net/virtio/virtio_rxtx.c   |3 +-
>  drivers/net/virtio/virtqueue.h |9 +-
>  lib/librte_eal/common/eal_common_options.c |5 +
>  lib/librte_eal/common/eal_internal_cfg.h   |1 +
>  lib/librte_eal/common/eal_options.h|2 +
>  lib/librte_eal/common/include/rte_memory.h |5 +
>  lib/librte_eal/linuxapp/eal/eal_memory.c   |   76 ++
>  14 files changed, 2337 insertions(+), 243 deletions(-)
>  create mode 100644 drivers/net/virtio/qtest.c
>

Hi Yuanhan and Jianfeng,

Here is example how to use this new abstraction.
Please check first 3 patches to know how to implement the abstraction.

Also please see changes for "virtio_pci.c" involved in last patch.
This is the example.

Thanks,
Tetsuya

[dpdk-dev] [PATCH v6 08/11] eal: pci: introduce RTE_KDRV_VFIO_NOIOMMUi driver mode

[Santosh Shukla]

On Thu, Jan 21, 2016 at 4:02 PM, David Marchand 
wrote:

> Santosh,
>
> On Tue, Jan 19, 2016 at 7:57 PM, Santosh Shukla 
> wrote:
> > Adding RTE_KDRV_VFIO_NOIOMMU mode in kernel driver. Also including
> > rte_vfio_is_noiommu() helper function. This function will parse
> > /sys/bus/pci/device// and make sure that
> > - vfio noiommu mode set in kernel driver
> > - pci device attached to vfio-noiommu driver only
> >
> > If both condition satisfies then set drv->kdrv = RTE_KDRV_VFIO_NOIOMMU
> >
> > Also did similar changes in virtio_rd/wr, Changes applicable for virtio
> spec
> > 0.95 only.
>
> This is a mode (specific to vfio), not a new kernel driver.
>
>
Yes, Specific to VFIO and this is why noiommu appended after vfio i.e..
__VFIO and __VFIO_NOIOMMU.


> How come we need to distinguish between with/without iommu modes ?
>

By default vfio framework assumes iommu i.,e., iommu present. Unless user
explicitly set "enable_unsafe_noiommu_mode" param. so in my opinion, we
care to parse vfio driver for _noiommu_ mode only.


> Should not vfio behave the same way from an api point of view ?
>
>
Yes It should. vfio gives similar file_ops i.e.. read/write/mmap/seek etc..
I am little confused on your question, do you see any issue in vfio bar
rd/wr api implementation?


> Regards,
> --
> David Marchand
>

[dpdk-dev] [PATCH] no need to test for NULL when freeing

[David Marchand]

free() already handles NULL pointer.

Signed-off-by: David Marchand 
---
 app/test/test_devargs.c|  3 +-
 app/test/test_link_bonding.c   |  6 ++--
 app/test/test_pci.c|  3 +-
 app/test/test_ring.c   | 36 --
 drivers/net/xenvirt/rte_eth_xenvirt.c  |  6 ++--
 drivers/net/xenvirt/rte_mempool_gntalloc.c |  9 ++
 examples/ip_pipeline/cpu_core_map.c|  3 +-
 .../pipeline/pipeline_flow_classification_be.c |  6 ++--
 examples/vhost_xen/vhost_monitor.c |  3 +-
 examples/vhost_xen/xenstore_parse.c| 33 +++-
 lib/librte_eal/common/eal_common_devargs.c |  3 +-
 lib/librte_eal/linuxapp/eal/eal_memory.c   |  3 +-
 lib/librte_ether/rte_ethdev.c  |  6 ++--
 lib/librte_kvargs/rte_kvargs.c |  4 +--
 14 files changed, 41 insertions(+), 83 deletions(-)

diff --git a/app/test/test_devargs.c b/app/test/test_devargs.c
index 049f32d..e5a9aa0 100644
--- a/app/test/test_devargs.c
+++ b/app/test/test_devargs.c
@@ -48,8 +48,7 @@ static void free_devargs_list(void)
while (!TAILQ_EMPTY(&devargs_list)) {
devargs = TAILQ_FIRST(&devargs_list);
TAILQ_REMOVE(&devargs_list, devargs, next);
-   if (devargs->args)
-   free(devargs->args);
+   free(devargs->args);
free(devargs);
}
 }
diff --git a/app/test/test_link_bonding.c b/app/test/test_link_bonding.c
index 2d98958..7cbc289 100644
--- a/app/test/test_link_bonding.c
+++ b/app/test/test_link_bonding.c
@@ -4023,10 +4023,8 @@ test_close_bonded_device(void)
 static void
 testsuite_teardown(void)
 {
-   if (test_params->pkt_eth_hdr != NULL) {
-   free(test_params->pkt_eth_hdr);
-   test_params->pkt_eth_hdr = NULL;
-   }
+   free(test_params->pkt_eth_hdr);
+   test_params->pkt_eth_hdr = NULL;

/* Clean up and remove slaves from bonded device */
remove_slaves_and_stop_bonded_device();
diff --git a/app/test/test_pci.c b/app/test/test_pci.c
index 5530d99..0ed357e 100644
--- a/app/test/test_pci.c
+++ b/app/test/test_pci.c
@@ -139,8 +139,7 @@ static void free_devargs_list(void)
while (!TAILQ_EMPTY(&devargs_list)) {
devargs = TAILQ_FIRST(&devargs_list);
TAILQ_REMOVE(&devargs_list, devargs, next);
-   if (devargs->args)
-   free(devargs->args);
+   free(devargs->args);
free(devargs);
}
 }
diff --git a/app/test/test_ring.c b/app/test/test_ring.c
index e5614de..943c350 100644
--- a/app/test/test_ring.c
+++ b/app/test/test_ring.c
@@ -471,17 +471,13 @@ test_ring_basic(void)
if (ret != 0)
goto fail;

-   if (src)
-   free(src);
-   if (dst)
-   free(dst);
+   free(src);
+   free(dst);
return 0;

  fail:
-   if (src)
-   free(src);
-   if (dst)
-   free(dst);
+   free(src);
+   free(dst);
return -1;
 }

@@ -759,17 +755,13 @@ test_ring_burst_basic(void)
goto fail;

/* Free memory before test completed */
-   if (src)
-   free(src);
-   if (dst)
-   free(dst);
+   free(src);
+   free(dst);
return 0;

  fail:
-   if (src)
-   free(src);
-   if (dst)
-   free(dst);
+   free(src);
+   free(dst);
return -1;
 }

@@ -1168,17 +1160,13 @@ test_ring_stats(void)
memset(&r->stats[lcore_id], 0, sizeof(r->stats[lcore_id]));

/* Free memory before test completed */
-   if (src)
-   free(src);
-   if (dst)
-   free(dst);
+   free(src);
+   free(dst);
return 0;

 fail:
-   if (src)
-   free(src);
-   if (dst)
-   free(dst);
+   free(src);
+   free(dst);
return -1;
 #endif
 }
diff --git a/drivers/net/xenvirt/rte_eth_xenvirt.c 
b/drivers/net/xenvirt/rte_eth_xenvirt.c
index 3353bcb..3f31806 100644
--- a/drivers/net/xenvirt/rte_eth_xenvirt.c
+++ b/drivers/net/xenvirt/rte_eth_xenvirt.c
@@ -431,10 +431,8 @@ gntalloc_vring_create(int queue_type, uint32_t size, int 
vtidx)
va = NULL;
}
 out:
-   if (pa_arr)
-   free(pa_arr);
-   if (gref_arr)
-   free(gref_arr);
+   free(pa_arr);
+   free(gref_arr);

return va;
 }
diff --git a/drivers/net/xenvirt/rte_mempool_gntalloc.c 
b/drivers/net/xenvirt/rte_mempool_gntalloc.c
index 0585f08..7bfbfda 100644
--- a/drivers/net/xenvirt/rte_mempool_gntalloc.c
+++ b/drivers/net/xenvirt/rte_mempool_gntalloc.c
@@ -229,15 +229,12 @@ mmap_failed:
munmap(gnt_arr[i].va, pg_sz);
}
 out:
-   if (gnt_arr)
-   free(

[dpdk-dev] [PATCH v6 08/11] eal: pci: introduce RTE_KDRV_VFIO_NOIOMMUi driver mode

[Thomas Monjalon]

2016-01-21 16:43, Santosh Shukla:
> David Marchand  wrote:
> > This is a mode (specific to vfio), not a new kernel driver.
> >
> Yes, Specific to VFIO and this is why noiommu appended after vfio i.e..
> __VFIO and __VFIO_NOIOMMU.

Woaaa! Your logic is really disappointing :)
Specific to VFIO => append _NOIOMMU
If it's for VFIO, it should be called VFIO (that's my logic).

> > How come we need to distinguish between with/without iommu modes ?
> 
> By default vfio framework assumes iommu i.,e., iommu present. Unless user
> explicitly set "enable_unsafe_noiommu_mode" param. so in my opinion, we
> care to parse vfio driver for _noiommu_ mode only.

Why do we care to parse noiommu only?
Even if virtio cannot work in an IOMMU case, there is no reason to add
a VFIO_NOIOMMU type here.

> > Should not vfio behave the same way from an api point of view ?
> >
> Yes It should. vfio gives similar file_ops i.e.. read/write/mmap/seek etc..
> I am little confused on your question, do you see any issue in vfio bar
> rd/wr api implementation?

I think you should just consider the VFIO API and let the noiommu option
as a kernel configuration detail.

[dpdk-dev] [PATCH] no need to test for NULL when freeing

[Thomas Monjalon]

2016-01-21 12:23, David Marchand:
> free() already handles NULL pointer.
> 
> Signed-off-by: David Marchand 
> ---
>  app/test/test_devargs.c|  3 +-
>  app/test/test_link_bonding.c   |  6 ++--
>  app/test/test_pci.c|  3 +-
>  app/test/test_ring.c   | 36 
> --
>  drivers/net/xenvirt/rte_eth_xenvirt.c  |  6 ++--
>  drivers/net/xenvirt/rte_mempool_gntalloc.c |  9 ++
>  examples/ip_pipeline/cpu_core_map.c|  3 +-
>  .../pipeline/pipeline_flow_classification_be.c |  6 ++--
>  examples/vhost_xen/vhost_monitor.c |  3 +-
>  examples/vhost_xen/xenstore_parse.c| 33 +++-
>  lib/librte_eal/common/eal_common_devargs.c |  3 +-
>  lib/librte_eal/linuxapp/eal/eal_memory.c   |  3 +-
>  lib/librte_ether/rte_ethdev.c  |  6 ++--
>  lib/librte_kvargs/rte_kvargs.c |  4 +--
>  14 files changed, 41 insertions(+), 83 deletions(-)

Have you used a coccinelle script?

[dpdk-dev] [PATCH] no need to test for NULL when freeing

[David Marchand]

On Thu, Jan 21, 2016 at 12:30 PM, Thomas Monjalon
 wrote:
> 2016-01-21 12:23, David Marchand:
>> free() already handles NULL pointer.
>>
>> Signed-off-by: David Marchand 
>> ---
>>  app/test/test_devargs.c|  3 +-
>>  app/test/test_link_bonding.c   |  6 ++--
>>  app/test/test_pci.c|  3 +-
>>  app/test/test_ring.c   | 36 
>> --
>>  drivers/net/xenvirt/rte_eth_xenvirt.c  |  6 ++--
>>  drivers/net/xenvirt/rte_mempool_gntalloc.c |  9 ++
>>  examples/ip_pipeline/cpu_core_map.c|  3 +-
>>  .../pipeline/pipeline_flow_classification_be.c |  6 ++--
>>  examples/vhost_xen/vhost_monitor.c |  3 +-
>>  examples/vhost_xen/xenstore_parse.c| 33 +++-
>>  lib/librte_eal/common/eal_common_devargs.c |  3 +-
>>  lib/librte_eal/linuxapp/eal/eal_memory.c   |  3 +-
>>  lib/librte_ether/rte_ethdev.c  |  6 ++--
>>  lib/librte_kvargs/rte_kvargs.c |  4 +--
>>  14 files changed, 41 insertions(+), 83 deletions(-)
>
> Have you used a coccinelle script?

Nop, some shell script of mine with manual checks.


-- 
David Marchand

[dpdk-dev] [PATCH v5 8/9] virtio: add 1.0 support

[Thomas Monjalon]

2016-01-19 16:12, Yuanhan Liu:
> +#define IO_READ_DEF(nr_bits, type) \
> +static inline type \
> +io_read##nr_bits(type *addr)   \
> +{  \
> +   return *(volatile type *)addr;  \
> +}
> +
> +#define IO_WRITE_DEF(nr_bits, type)\
> +static inline void \
> +io_write##nr_bits(type val, type *addr)\
> +{  \
> +   *(volatile type *)addr = val;   \
> +}
> +
> +IO_READ_DEF (8, uint8_t)
> +IO_WRITE_DEF(8, uint8_t)
> +
> +IO_READ_DEF (16, uint16_t)
> +IO_WRITE_DEF(16, uint16_t)
> +
> +IO_READ_DEF (32, uint32_t)
> +IO_WRITE_DEF(32, uint32_t)

Yes you can do this.
But not sure you should.

> +static inline void
> +io_write64_twopart(uint64_t val, uint32_t *lo, uint32_t *hi)
> +{
> +   io_write32(val & ((1ULL << 32) - 1), lo);
> +   io_write32(val >> 32,hi);
> +}

When debugging this code, how GDB behave?
How to find the definition of io_write32() with grep or simple editors?

[dpdk-dev] [PATCH v5 8/9] virtio: add 1.0 support

[Thomas Monjalon]

2016-01-19 16:12, Yuanhan Liu:
>  int
>  vtpci_init(struct rte_pci_device *dev, struct virtio_hw *hw)
>  {
> -   hw->vtpci_ops = &legacy_ops;
> +   hw->dev = dev;
> +
> +   /*
> +* Try if we can succeed reading virtio pci caps, which exists
> +* only on modern pci device. If failed, we fallback to legacy
> +* virtio handling.
> +*/
> +   if (virtio_read_caps(dev, hw) == 0) {
> +   PMD_INIT_LOG(INFO, "modern virtio pci detected.");
> +   hw->vtpci_ops = &modern_ops;
> +   hw->modern= 1;
> +   dev->driver->drv_flags |= RTE_PCI_DRV_INTR_LSC;
> +   return 0;
> +   }

RTE_PCI_DRV_INTR_LSC is already set by virtio_resource_init_by_uio().
Do you mean interrupt was not supported with legacy virtio?

[dpdk-dev] [PATCH 0/2] minor cleanup in ethdev hotplug

[David Marchand]

It was first a preparation step for future patchsets, but I am not sure what
will become of them, so sending this anyway since it does not hurt to clean
this now.


-- 
David Marchand

David Marchand (2):
  ethdev: remove useless checks
  ethdev: move code to common place in hotplug

 lib/librte_ether/rte_ethdev.c | 84 +--
 1 file changed, 40 insertions(+), 44 deletions(-)

-- 
1.9.1

[dpdk-dev] [PATCH 1/2] ethdev: remove useless null checks

[David Marchand]

We are in static functions and those passed arguments can't be NULL.

Signed-off-by: David Marchand 
---
 lib/librte_ether/rte_ethdev.c | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index af990e2..951fb1c 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -220,9 +220,6 @@ rte_eth_dev_create_unique_device_name(char *name, size_t 
size,
 {
int ret;

-   if ((name == NULL) || (pci_dev == NULL))
-   return -EINVAL;
-
ret = snprintf(name, size, "%d:%d.%d",
pci_dev->addr.bus, pci_dev->addr.devid,
pci_dev->addr.function);
@@ -505,9 +502,6 @@ rte_eth_dev_is_detachable(uint8_t port_id)
 static int
 rte_eth_dev_attach_pdev(struct rte_pci_addr *addr, uint8_t *port_id)
 {
-   if ((addr == NULL) || (port_id == NULL))
-   goto err;
-
/* re-construct pci_device_list */
if (rte_eal_pci_scan())
goto err;
@@ -531,9 +525,6 @@ rte_eth_dev_detach_pdev(uint8_t port_id, struct 
rte_pci_addr *addr)
struct rte_pci_addr freed_addr;
struct rte_pci_addr vp;

-   if (addr == NULL)
-   goto err;
-
/* check whether the driver supports detach feature, or not */
if (rte_eth_dev_is_detachable(port_id))
goto err;
@@ -566,9 +557,6 @@ rte_eth_dev_attach_vdev(const char *vdevargs, uint8_t 
*port_id)
char *name = NULL, *args = NULL;
int ret = -1;

-   if ((vdevargs == NULL) || (port_id == NULL))
-   goto end;
-
/* parse vdevargs, then retrieve device name and args */
if (rte_eal_parse_devargs_str(vdevargs, &name, &args))
goto end;
@@ -600,9 +588,6 @@ rte_eth_dev_detach_vdev(uint8_t port_id, char *vdevname)
 {
char name[RTE_ETH_NAME_MAX_LEN];

-   if (vdevname == NULL)
-   goto err;
-
/* check whether the driver supports detach feature, or not */
if (rte_eth_dev_is_detachable(port_id))
goto err;
-- 
1.9.1

[dpdk-dev] [PATCH 2/2] ethdev: move code to common place in hotplug

[David Marchand]

Move these error logs and checks on detach capabilities in a common place.

Signed-off-by: David Marchand 
---
 lib/librte_ether/rte_ethdev.c | 69 +--
 1 file changed, 40 insertions(+), 29 deletions(-)

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 951fb1c..9083783 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -514,7 +514,6 @@ rte_eth_dev_attach_pdev(struct rte_pci_addr *addr, uint8_t 
*port_id)

return 0;
 err:
-   RTE_LOG(ERR, EAL, "Driver, cannot attach the device\n");
return -1;
 }

@@ -525,10 +524,6 @@ rte_eth_dev_detach_pdev(uint8_t port_id, struct 
rte_pci_addr *addr)
struct rte_pci_addr freed_addr;
struct rte_pci_addr vp;

-   /* check whether the driver supports detach feature, or not */
-   if (rte_eth_dev_is_detachable(port_id))
-   goto err;
-
/* get pci address by port id */
if (rte_eth_dev_get_addr_by_port(port_id, &freed_addr))
goto err;
@@ -546,7 +541,6 @@ rte_eth_dev_detach_pdev(uint8_t port_id, struct 
rte_pci_addr *addr)
*addr = freed_addr;
return 0;
 err:
-   RTE_LOG(ERR, EAL, "Driver, cannot detach the device\n");
return -1;
 }

@@ -577,8 +571,6 @@ end:
free(name);
free(args);

-   if (ret < 0)
-   RTE_LOG(ERR, EAL, "Driver, cannot attach the device\n");
return ret;
 }

@@ -588,10 +580,6 @@ rte_eth_dev_detach_vdev(uint8_t port_id, char *vdevname)
 {
char name[RTE_ETH_NAME_MAX_LEN];

-   /* check whether the driver supports detach feature, or not */
-   if (rte_eth_dev_is_detachable(port_id))
-   goto err;
-
/* get device name by port id */
if (rte_eth_dev_get_name_by_port(port_id, name))
goto err;
@@ -603,7 +591,6 @@ rte_eth_dev_detach_vdev(uint8_t port_id, char *vdevname)
strncpy(vdevname, name, sizeof(name));
return 0;
 err:
-   RTE_LOG(ERR, EAL, "Driver, cannot detach the device\n");
return -1;
 }

@@ -612,14 +599,25 @@ int
 rte_eth_dev_attach(const char *devargs, uint8_t *port_id)
 {
struct rte_pci_addr addr;
+   int ret = -1;

if ((devargs == NULL) || (port_id == NULL))
-   return -EINVAL;
+   goto err;

-   if (eal_parse_pci_DomBDF(devargs, &addr) == 0)
-   return rte_eth_dev_attach_pdev(&addr, port_id);
-   else
-   return rte_eth_dev_attach_vdev(devargs, port_id);
+   if (eal_parse_pci_DomBDF(devargs, &addr) == 0) {
+   ret = rte_eth_dev_attach_pdev(&addr, port_id);
+   if (ret < 0)
+   goto err;
+   } else {
+   ret = rte_eth_dev_attach_vdev(devargs, port_id);
+   if (ret < 0)
+   goto err;
+   }
+
+   return 0;
+err:
+   RTE_LOG(ERR, EAL, "Driver, cannot attach the device\n");
+   return ret;
 }

 /* detach the device, then store the name of the device */
@@ -627,26 +625,39 @@ int
 rte_eth_dev_detach(uint8_t port_id, char *name)
 {
struct rte_pci_addr addr;
-   int ret;
+   int ret = -1;

if (name == NULL)
-   return -EINVAL;
+   goto err;
+
+   /* check whether the driver supports detach feature, or not */
+   if (rte_eth_dev_is_detachable(port_id))
+   goto err;

if (rte_eth_dev_get_device_type(port_id) == RTE_ETH_DEV_PCI) {
ret = rte_eth_dev_get_addr_by_port(port_id, &addr);
if (ret < 0)
-   return ret;
+   goto err;

ret = rte_eth_dev_detach_pdev(port_id, &addr);
-   if (ret == 0)
-   snprintf(name, RTE_ETH_NAME_MAX_LEN,
-   "%04x:%02x:%02x.%d",
-   addr.domain, addr.bus,
-   addr.devid, addr.function);
+   if (ret < 0)
+   goto err;

-   return ret;
-   } else
-   return rte_eth_dev_detach_vdev(port_id, name);
+   snprintf(name, RTE_ETH_NAME_MAX_LEN,
+   "%04x:%02x:%02x.%d",
+   addr.domain, addr.bus,
+   addr.devid, addr.function);
+   } else {
+   ret = rte_eth_dev_detach_vdev(port_id, name);
+   if (ret < 0)
+   goto err;
+   }
+
+   return 0;
+
+err:
+   RTE_LOG(ERR, EAL, "Driver, cannot detach the device\n");
+   return ret;
 }

 static int
-- 
1.9.1

[dpdk-dev] [PATCH v6 08/11] eal: pci: introduce RTE_KDRV_VFIO_NOIOMMUi driver mode

[Santosh Shukla]

On Thu, Jan 21, 2016 at 4:58 PM, Thomas Monjalon
 wrote:
> 2016-01-21 16:43, Santosh Shukla:
>> David Marchand  wrote:
>> > This is a mode (specific to vfio), not a new kernel driver.
>> >
>> Yes, Specific to VFIO and this is why noiommu appended after vfio i.e..
>> __VFIO and __VFIO_NOIOMMU.
>
> Woaaa! Your logic is really disappointing :)
> Specific to VFIO => append _NOIOMMU
> If it's for VFIO, it should be called VFIO (that's my logic).
>
I am confused by reading your comment. vfio works for default iommu
and now with noiommu. drv->kdrv need to know driver mode for vfio
case. So that user can simply read drv->kdrv value in their driver and
accordingly use vfio rd/wr api for example {pread/pwrite}. This is how
rte_eal_pci_vfio_read/write_bar() api implemented.

And Yes it is called VFIO but with with specifics appended in it.

>> > How come we need to distinguish between with/without iommu modes ?
>>
>> By default vfio framework assumes iommu i.,e., iommu present. Unless user
>> explicitly set "enable_unsafe_noiommu_mode" param. so in my opinion, we
>> care to parse vfio driver for _noiommu_ mode only.
>
> Why do we care to parse noiommu only?

Because pmd drivers example virtio can work with vfio only in
_noiommu_ mode. In particular, virtio spec 0.95 / legacy virtio. So at
the initialization (example .. virtio-net) of such pmd driver, pmd
driver should know that vfio-with-noiommu mode enabled or not? for
that pmd driver simply checks drv->kdrv value. Currently virtio-net
pmd driver does resource parsing then resource init for interfaces
like UIO/ioport, I intend to do same but only parsing, as resource
init for vfio case already taken care by pci_xx_vfio_map() api in
virtio-net pmd driver (refer Yaun recently virtio 1.0 recently
submitted rte_eal_pci_map patch)

Also Yuan in one of earlier thread inclined to remove all the resource
parsing api from virtio-net pmd driver. Pl. refer this thread [1]

[1] http://dpdk.org/dev/patchwork/patch/9862/

> Even if virtio cannot work in an IOMMU case, there is no reason to add
> a VFIO_NOIOMMU type here.
>
>> > Should not vfio behave the same way from an api point of view ?
>> >
>> Yes It should. vfio gives similar file_ops i.e.. read/write/mmap/seek etc..
>> I am little confused on your question, do you see any issue in vfio bar
>> rd/wr api implementation?
>
> I think you should just consider the VFIO API and let the noiommu option
> as a kernel configuration detail.

vfio apis _are_ considered at low level rd/wr implementation, Has
nothing to do with iommu/noiommu mode. See pci_vfio_read/write_bar()
implementation, they are using pread64/pwrite64() vfio rd/wr api.

[dpdk-dev] [PATCH v2 0/3] Keep-alive stats and doc fixes

[Remy Horton]

On 21/01/2016 11:05, Harry van Haaren wrote:
> This patchset contains:
> 1. Fix variable naming consistency in sample guide
> 2. Set last_seen time on core when it gets registered
> 3. An xstats implementation for last-seen and current core status
>
> v2:
> -Refactor to remove rte_ethdev.h include

Acked-by: Remy Horton 

[dpdk-dev] virtio ring layout changes for optimal single-stream performance

[Michael S. Tsirkin]

Hi all!
I have been experimenting with alternative virtio ring layouts,
in order to speed up single stream performance.

I have just posted a benchmark I wrote for the purpose, and a (partial)
alternative layout implementation.  This achieves 20-40% reduction in
virtio overhead in the (default) polling mode.

http://article.gmane.org/gmane.linux.kernel.virtualization/26889

The layout is trying to be as simple as possible, to reduce
the number of cache lines bouncing between CPUs.

For benchmarking, the idea is to emulate virtio in user-space,
artificially adding overhead for e.g. signalling to match what happens
in case of a VM.

I'd be very curious to get feedback on this, in particular, some people
discussed using vectored operations to format virtio ring - would it
conflict with this work?

You are all welcome to post enhancements or more layout alternatives as
patches.

TODO:
- documentation+discussion of interaction with CPU caching
- thorough benchmarking of different configurations/hosts
- experiment with event index replacements
- better emulate vmexit/vmentry cost overhead
- virtio spec proposal

Thanks!
-- 
MST

[dpdk-dev] [PATCH 2/5] vhost: refactor virtio_dev_rx

[Jérôme Jutteau]

Hi Yuanhan,

2015-12-14 2:47 GMT+01:00 Yuanhan Liu :
> Right, I should move it in the beginning of this function.

Any news about this refactoring ?

-- 
J?r?me Jutteau,
Tel : 0826.206.307 (poste 304)
IMPORTANT: The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, you
are hereby notified that any dissemination, distribution or copying of
this communication is strictly prohibited. If you have received this
communication in error, please notify us immediately by replying to
the message and deleting it from your computer.

[dpdk-dev] [PATCH v6 08/11] eal: pci: introduce RTE_KDRV_VFIO_NOIOMMUi driver mode

[Thomas Monjalon]

2016-01-21 17:34, Santosh Shukla:
> On Thu, Jan 21, 2016 at 4:58 PM, Thomas Monjalon
>  wrote:
> > 2016-01-21 16:43, Santosh Shukla:
> >> David Marchand  wrote:
> >> > This is a mode (specific to vfio), not a new kernel driver.
> >> >
> >> Yes, Specific to VFIO and this is why noiommu appended after vfio i.e..
> >> __VFIO and __VFIO_NOIOMMU.
> >
> > Woaaa! Your logic is really disappointing :)
> > Specific to VFIO => append _NOIOMMU
> > If it's for VFIO, it should be called VFIO (that's my logic).
> >
> I am confused by reading your comment. vfio works for default iommu
> and now with noiommu. drv->kdrv need to know driver mode for vfio
> case. So that user can simply read drv->kdrv value in their driver and
> accordingly use vfio rd/wr api for example {pread/pwrite}. This is how
> rte_eal_pci_vfio_read/write_bar() api implemented.

Sorry I don't understand. Why EAL read/write functions should be different
depending of the VFIO mode?

> And Yes it is called VFIO but with with specifics appended in it.
> 
> >> > How come we need to distinguish between with/without iommu modes ?
> >>
> >> By default vfio framework assumes iommu i.,e., iommu present. Unless user
> >> explicitly set "enable_unsafe_noiommu_mode" param. so in my opinion, we
> >> care to parse vfio driver for _noiommu_ mode only.
> >
> > Why do we care to parse noiommu only?
> 
> Because pmd drivers example virtio can work with vfio only in
> _noiommu_ mode. In particular, virtio spec 0.95 / legacy virtio.

Please could you explain the limitation (except IOMMU availability)?

> So at
> the initialization (example .. virtio-net) of such pmd driver, pmd
> driver should know that vfio-with-noiommu mode enabled or not? for
> that pmd driver simply checks drv->kdrv value.

If a check is needed, I would prefer using your function
pci_vfio_is_noiommu() and remove driver modes from struct rte_kernel_driver.

> Currently virtio-net
> pmd driver does resource parsing then resource init for interfaces
> like UIO/ioport, I intend to do same but only parsing, as resource
> init for vfio case already taken care by pci_xx_vfio_map() api in
> virtio-net pmd driver (refer Yaun recently virtio 1.0 recently
> submitted rte_eal_pci_map patch)
> 
> Also Yuan in one of earlier thread inclined to remove all the resource
> parsing api from virtio-net pmd driver. Pl. refer this thread [1]
> 
> [1] http://dpdk.org/dev/patchwork/patch/9862/

Yes he said
"we should try to avoid getting UIO/VFIO stuff inside virtio pmd driver".
I agree we must try to have those abstractions in EAL.
The only exception seems to be the switch ioport/PCI bar to read/write
in virtio.

> > Even if virtio cannot work in an IOMMU case, there is no reason to add
> > a VFIO_NOIOMMU type here.
> >
> >> > Should not vfio behave the same way from an api point of view ?
> >> >
> >> Yes It should. vfio gives similar file_ops i.e.. read/write/mmap/seek etc..
> >> I am little confused on your question, do you see any issue in vfio bar
> >> rd/wr api implementation?
> >
> > I think you should just consider the VFIO API and let the noiommu option
> > as a kernel configuration detail.
> 
> vfio apis _are_ considered at low level rd/wr implementation, Has
> nothing to do with iommu/noiommu mode. See pci_vfio_read/write_bar()
> implementation, they are using pread64/pwrite64() vfio rd/wr api.

So you agree that the VFIO API abstract the iommu availability details?

[dpdk-dev] [PKTGEN] additional terminal IO question

[Wiles, Keith]

On 1/20/16, 11:53 PM, "dev on behalf of Matthew Hall"  wrote:

>If I try using pktgen theme mode (-T) or unmodified, without commenting 
>out some of the stuff I mentioned I disabled for debugging in the 
>previous thread, it seems like it sets the pktgen prompt to be invisible 
>(black text on black??? or I'm not sure just want) on my TTY which has a 
>black background.

I am not sure what you changed for debugging, but on my Ubuntu 15.10 using MATE 
Terminal 1.10.1 with a black background and white text the cursor remains as 
white after I quit Pktgen. If you have a crash for some reason the cmdline code 
leaves the TTY in a raw mode no echo, which is just like no cursor. I have to 
also do ?stty sane? to get echo/cursor back on. Is this what is happing to you?

I created a white-black.theme I was using and did not try to make it pretty as 
I use a black on light yellow background. Here is the theme.
theme default white none off
theme top.spinner cyan none bold
theme top.ports green none bold
theme top.page white none off
theme top.copyright yellow none off
theme top.poweredby blue none bold
theme sep.dash blue none off
theme sep.text white none off
theme stats.port.label blue none bold
theme stats.port.flags blue none bold
theme stats.port.status green none bold
theme stats.dyn.label yellow none off
theme stats.dyn.values yellow none off
theme stats.stat.label magenta none off
theme stats.stat.values white none off
theme stats.total.label red none bold
theme stats.colon blue none bold
theme pktgen.prompt green none off
cls

Please give more details next time to help me understand the problem like OS 
type, terminal type used, versions, ?


Thanks
++Keith
>
>If you quit the app it does not reset the colors so my shell is also 
>invisible, until I blindly run the reset command.
>
>Did anybody else try it on a black background? Did anybody else see 
>these issues with it as well?
>
>Matthew.
>


Regards,
Keith

[dpdk-dev] [PATCH 0/2] Reduce DPDK initialization time

[Thomas Monjalon]

2015-11-22 14:13, Zhihong Wang:
> This patch aims to reduce DPDK initialization time, which is important in 
> cases such as micro service.
> 
> Changes are:
> 
> 1. Reduce timer initialization time
> 
> 2. Remove unnecessary hugepage zero-filling operations
> 
> With this patch:
> 
> 1. Timer initialization time can be reduced by 4/10 second
> 
> 2. Memory initialization time can be reduced nearly by half
> 
> The 2nd topic has been brought up before in this thread:
> http://dpdk.org/dev/patchwork/patch/4219/

Applied, thanks

[dpdk-dev] [PKTGEN] dumb question: how to start packet TX and set the payload

[Wiles, Keith]

On 1/21/16, 12:15 AM, "dev on behalf of Matthew Hall"  wrote:

>Hello,
>
>I was trying to just use the default PKT file, test/set_seq.pkt, like so:
>
>sudo "./app/app/${RTE_TARGET}/pktgen" \
>-l 2,3 \
>--master-lcore 2 \

BTW, the lowest core will be the master by default in the -c or -l option, so 
setting master-lcore is not required.
>-n 2 \
>-m 1024 \
>-w 0a:00.1 \
>--no-shconf \
>--file-prefix pktgen \
>-- \
>-P \
>-m 2.0 \
>-f test/set_seq.pkt
>
>After pktgen loaded, the port 0 is marked as UP. So I typed "start all" 
>and also tried "str". Sadly, so far, it seems like I could not get this 
>to actually begin sending any packets. At least, no counters are 
>incrementing in the pktgen UI. So I wasn't sure how to make sure it is 
>really sending or not.

The problem is you used the same core (2) for the -m option. Core 2 is being 
used for the keyboard, timer and screen output. This means you must have the -m 
option starting with core 3 as in -m 3.0 and your problem should go away. The 
first or master core is consume by Pktgen to handle the previous stuff and you 
must start with the next cores for Rx/Tx of packets. I really need to put tests 
in the code, which I will try to add soon.

Sorry,
++Keith

>
>The documentation talked about many different commands available, but it 
>didn't specifically say how to start transmitting the packets based on 
>the content of your *.pkt script file.
>
>I'm just trying to figure out what I messed up so that I can write 
>(another) doc patch besides the one I just sent a moment ago.
>
>I was also curious about putting some specific payloads into the packets 
>in pktgen. There are many ways of configuring the packet size, but it 
>doesn't talk about how and where to set the packet content. This is 
>important for my app as its performance will go up and down depending on 
>if the L4-L7 data has "interesting" content inside or not.
>
>Sincerely,
>Matthew.
>


Regards,
Keith

[dpdk-dev] [PKTGEN] fixing weird termio issues that complicate debugging

[Wiles, Keith]

On 1/21/16, 2:46 AM, "Panu Matilainen"  wrote:

>On 01/20/2016 06:26 PM, Wiles, Keith wrote:
>> On 1/20/16, 12:32 AM, "dev on behalf of Matthew Hall" > dpdk.org on behalf of mhall at mhcomputing.net> wrote:
>>
>>> Hello,
>>>
>>> Since the pktgen code is reindented I am finding time to read through it
>>> and experiment and see if I can get it working.
>>>
>>> I have issues with the init process of pktgen. It is difficult to debug
>>> it because the init code does a lot of very scary stuff to the terminal
>>> control / TTY device at inconvenient times in an inconvenient order, and
>>> in the process damages the debug output and damages the screen of your
>>> GDB without doing weird things to run GDB on a different TTY.
>>>
>>> Of course I am willing to contribute patches and not just complain, but
>>> first I need some help to follow what is going on.
>>>
>>> Here is the problematic call-flow with some explanation what went wrong
>>> trying it on some community machines outside of its original environment:
>>>
>>> 1) it calls printf("\n%s %s\n", wr_copyright_msg(), wr_powered_by());
>>> which dumps tons of weird boilerplate of licenses, copyrights, code
>>> creator, etc.
>>>
>>> It is open source and everybody that matters already knows who coded it,
>>> so is this stuff really that important? This gets in the way when you
>>> are trying to work on it and I just have to comment it out.
>>
>> One problem is a number of people wanted to steal the code and use in
>> a paid application, so the copyright is some what a requirement.
>
>In that case, why is it under a BSD'ish license instead of something 
>like GPL that's designed to prevent it in the first place? Might be too 
>late to change it by now, just wondering.

DPDK is BSD, so you can not use a GPL application with DPDK (I think) anyway I 
can try to speed you the screens, but does it really matter as these are only 
at startup and I normally leave pktgen running for long periods of time. The 
extra time at the start does not seem to be a big issue, right?

>
>> As you may know I do a lot of debugging on Pktgen and I feel they are
>> a nuisance. I can try to see if we can clean up these messages, but
>> do not hold your breath on getting them to be removed.
>
>It would make a world of difference if it just printed the copyright etc 
>in a couple of lines during startup, instead of taking over the entire 
>screen for several seconds.
>
>This is a whole lot like those anti-piracy ad campaigns on DVDs which 
>you cant skip, so all the *legitimate* users are forced to suffer 
>through them but all the bad guys just rip it out of their copies. DRM 
>that ends up hurting the legitimate users the most is never a good idea.
>
>   - Panu -
>
>
>


Regards,
Keith

[dpdk-dev] [PKTGEN] additional terminal IO question

[Arnon Warshavsky]

Keith,
On my end I'm ending with black on black with Konsole 2.3.3 on Centos 6.5
starting as green on black.

On Thu, Jan 21, 2016 at 4:55 PM, Wiles, Keith  wrote:

> On 1/20/16, 11:53 PM, "dev on behalf of Matthew Hall" <
> dev-bounces at dpdk.org on behalf of mhall at mhcomputing.net> wrote:
>
> >If I try using pktgen theme mode (-T) or unmodified, without commenting
> >out some of the stuff I mentioned I disabled for debugging in the
> >previous thread, it seems like it sets the pktgen prompt to be invisible
> >(black text on black??? or I'm not sure just want) on my TTY which has a
> >black background.
>
> I am not sure what you changed for debugging, but on my Ubuntu 15.10 using
> MATE Terminal 1.10.1 with a black background and white text the cursor
> remains as white after I quit Pktgen. If you have a crash for some reason
> the cmdline code leaves the TTY in a raw mode no echo, which is just like
> no cursor. I have to also do ?stty sane? to get echo/cursor back on. Is
> this what is happing to you?
>
> I created a white-black.theme I was using and did not try to make it
> pretty as I use a black on light yellow background. Here is the theme.
> theme default white none off
> theme top.spinner cyan none bold
> theme top.ports green none bold
> theme top.page white none off
> theme top.copyright yellow none off
> theme top.poweredby blue none bold
> theme sep.dash blue none off
> theme sep.text white none off
> theme stats.port.label blue none bold
> theme stats.port.flags blue none bold
> theme stats.port.status green none bold
> theme stats.dyn.label yellow none off
> theme stats.dyn.values yellow none off
> theme stats.stat.label magenta none off
> theme stats.stat.values white none off
> theme stats.total.label red none bold
> theme stats.colon blue none bold
> theme pktgen.prompt green none off
> cls
>
> Please give more details next time to help me understand the problem like
> OS type, terminal type used, versions, ?
>
>
> Thanks
> ++Keith
> >
> >If you quit the app it does not reset the colors so my shell is also
> >invisible, until I blindly run the reset command.
> >
> >Did anybody else try it on a black background? Did anybody else see
> >these issues with it as well?
> >
> >Matthew.
> >
>
>
> Regards,
> Keith
>
>
>
>
>


-- 

*Arnon Warshavsky*
*Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | arnon at qwilt.com
*

[dpdk-dev] [PKTGEN] dumb question: how to start packet TX and set the payload

[Wiles, Keith]

On 1/21/16, 12:15 AM, "dev on behalf of Matthew Hall"  wrote:

>Hello,
>
>I was trying to just use the default PKT file, test/set_seq.pkt, like so:
>
>sudo "./app/app/${RTE_TARGET}/pktgen" \
>-l 2,3 \
>--master-lcore 2 \
>-n 2 \
>-m 1024 \
>-w 0a:00.1 \
>--no-shconf \
>--file-prefix pktgen \
>-- \
>-P \
>-m 2.0 \
>-f test/set_seq.pkt
>
>After pktgen loaded, the port 0 is marked as UP. So I typed "start all" 
>and also tried "str". Sadly, so far, it seems like I could not get this 
>to actually begin sending any packets. At least, no counters are 
>incrementing in the pktgen UI. So I wasn't sure how to make sure it is 
>really sending or not.
>
>The documentation talked about many different commands available, but it 
>didn't specifically say how to start transmitting the packets based on 
>the content of your *.pkt script file.
>
>I'm just trying to figure out what I messed up so that I can write 
>(another) doc patch besides the one I just sent a moment ago.
>
>I was also curious about putting some specific payloads into the packets 
>in pktgen. There are many ways of configuring the packet size, but it 
>doesn't talk about how and where to set the packet content. This is 
>important for my app as its performance will go up and down depending on 
>if the L4-L7 data has "interesting" content inside or not.

Forgot to answer this one. Pktgen does not allow the user to define the content 
of the packet per say only the fill pattern and what ever you configure the 
packet type to be. If you would like to submit a patch for adding user specific 
content it has always been a goal of my to add that feature.

>
>Sincerely,
>Matthew.
>


Regards,
Keith

[dpdk-dev] [PKTGEN] additional terminal IO question

[Wiles, Keith]

From: Arnon Warshavsky mailto:ar...@qwilt.com>>
Date: Thursday, January 21, 2016 at 9:04 AM
To: "Keith Wiles (Intel)" mailto:keith.wiles at 
intel.com>>
Cc: Matthew Hall mailto:mhall at mhcomputing.net>>, 
"dev at dpdk.org" mailto:dev at 
dpdk.org>>
Subject: Re: [dpdk-dev] [PKTGEN] additional terminal IO question

Keith,
On my end I'm ending with black on black with Konsole 2.3.3 on Centos 6.5 
starting as green on black.

I changed my console to green on black and got the same results. When I quit 
Pktgen the cursor color and text return to green. I can not set the cursor 
color different from the text color on this terminal. This maybe a problem with 
kconsole. Using xterm the cursor and text are restored as well.

I would need to install a Centos 6.5 with Konsole. I can run konsole, but the 
setting will not allow me to adjust the colors most likely it needs more then 
just konsole installed with this MATE window system. Even in this default state 
of black on white the cursor returns as black with black text, which could be 
the problem???


On Thu, Jan 21, 2016 at 4:55 PM, Wiles, Keith mailto:keith.wiles at intel.com>> wrote:
On 1/20/16, 11:53 PM, "dev on behalf of Matthew Hall" mailto:dev-bounces at dpdk.org> on behalf of mhall at 
mhcomputing.net> wrote:

>If I try using pktgen theme mode (-T) or unmodified, without commenting
>out some of the stuff I mentioned I disabled for debugging in the
>previous thread, it seems like it sets the pktgen prompt to be invisible
>(black text on black??? or I'm not sure just want) on my TTY which has a
>black background.

I am not sure what you changed for debugging, but on my Ubuntu 15.10 using MATE 
Terminal 1.10.1 with a black background and white text the cursor remains as 
white after I quit Pktgen. If you have a crash for some reason the cmdline code 
leaves the TTY in a raw mode no echo, which is just like no cursor. I have to 
also do ?stty sane? to get echo/cursor back on. Is this what is happing to you?

I created a white-black.theme I was using and did not try to make it pretty as 
I use a black on light yellow background. Here is the theme.
theme default white none off
theme top.spinner cyan none bold
theme top.ports green none bold
theme top.page white none off
theme top.copyright yellow none off
theme top.poweredby blue none bold
theme sep.dash blue none off
theme sep.text white none off
theme stats.port.label blue none bold
theme stats.port.flags blue none bold
theme stats.port.status green none bold
theme stats.dyn.label yellow none off
theme stats.dyn.values yellow none off
theme stats.stat.label magenta none off
theme stats.stat.values white none off
theme stats.total.label red none bold
theme stats.colon blue none bold
theme pktgen.prompt green none off
cls

Please give more details next time to help me understand the problem like OS 
type, terminal type used, versions, ?


Thanks
++Keith
>
>If you quit the app it does not reset the colors so my shell is also
>invisible, until I blindly run the reset command.
>
>Did anybody else try it on a black background? Did anybody else see
>these issues with it as well?
>
>Matthew.
>


Regards,
Keith







--

Arnon Warshavsky
Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | arnon at 
qwilt.com

[dpdk-dev] [PKTGEN] additional terminal IO question

[Arnon Warshavsky]

Keith,
For the record, on my end (can only speak for myself)  this is not a real
problem.
I work around it by using a different theme and live with it happily ever
after.
I just provided the input since I encountered it.

/Arnon

On Thu, Jan 21, 2016 at 5:27 PM, Wiles, Keith  wrote:

>
> From: Arnon Warshavsky mailto:arnon at qwilt.com>>
> Date: Thursday, January 21, 2016 at 9:04 AM
> To: "Keith Wiles (Intel)"  keith.wiles at intel.com>>
> Cc: Matthew Hall mailto:mhall at mhcomputing.net>>, 
> "
> dev at dpdk.org" mailto:dev at 
> dpdk.org>>
> Subject: Re: [dpdk-dev] [PKTGEN] additional terminal IO question
>
> Keith,
> On my end I'm ending with black on black with Konsole 2.3.3 on Centos 6.5
> starting as green on black.
>
> I changed my console to green on black and got the same results. When I
> quit Pktgen the cursor color and text return to green. I can not set the
> cursor color different from the text color on this terminal. This maybe a
> problem with kconsole. Using xterm the cursor and text are restored as well.
>
> I would need to install a Centos 6.5 with Konsole. I can run konsole, but
> the setting will not allow me to adjust the colors most likely it needs
> more then just konsole installed with this MATE window system. Even in this
> default state of black on white the cursor returns as black with black
> text, which could be the problem???
>
>
> On Thu, Jan 21, 2016 at 4:55 PM, Wiles, Keith  > wrote:
> On 1/20/16, 11:53 PM, "dev on behalf of Matthew Hall" <
> dev-bounces at dpdk.org on behalf of
> mhall at mhcomputing.net> wrote:
>
> >If I try using pktgen theme mode (-T) or unmodified, without commenting
> >out some of the stuff I mentioned I disabled for debugging in the
> >previous thread, it seems like it sets the pktgen prompt to be invisible
> >(black text on black??? or I'm not sure just want) on my TTY which has a
> >black background.
>
> I am not sure what you changed for debugging, but on my Ubuntu 15.10 using
> MATE Terminal 1.10.1 with a black background and white text the cursor
> remains as white after I quit Pktgen. If you have a crash for some reason
> the cmdline code leaves the TTY in a raw mode no echo, which is just like
> no cursor. I have to also do ?stty sane? to get echo/cursor back on. Is
> this what is happing to you?
>
> I created a white-black.theme I was using and did not try to make it
> pretty as I use a black on light yellow background. Here is the theme.
> theme default white none off
> theme top.spinner cyan none bold
> theme top.ports green none bold
> theme top.page white none off
> theme top.copyright yellow none off
> theme top.poweredby blue none bold
> theme sep.dash blue none off
> theme sep.text white none off
> theme stats.port.label blue none bold
> theme stats.port.flags blue none bold
> theme stats.port.status green none bold
> theme stats.dyn.label yellow none off
> theme stats.dyn.values yellow none off
> theme stats.stat.label magenta none off
> theme stats.stat.values white none off
> theme stats.total.label red none bold
> theme stats.colon blue none bold
> theme pktgen.prompt green none off
> cls
>
> Please give more details next time to help me understand the problem like
> OS type, terminal type used, versions, ?
>
>
> Thanks
> ++Keith
> >
> >If you quit the app it does not reset the colors so my shell is also
> >invisible, until I blindly run the reset command.
> >
> >Did anybody else try it on a black background? Did anybody else see
> >these issues with it as well?
> >
> >Matthew.
> >
>
>
> Regards,
> Keith
>
>
>
>
>
>
>
> --
>
> Arnon Warshavsky
> Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | arnon at qwilt.com
> 
>



-- 

*Arnon Warshavsky*
*Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | arnon at qwilt.com
*

[dpdk-dev] [dpdk-dev, 2/2] ethdev: move code to common place in hotplug

[Jan Viktorin]

On Thu, 21 Jan 2016 12:57:11 +0100
David Marchand  wrote:

> Move these error logs and checks on detach capabilities in a common place.
> 
> Signed-off-by: David Marchand 
> 
> ---
> lib/librte_ether/rte_ethdev.c | 69 +--
>  1 file changed, 40 insertions(+), 29 deletions(-)
> 
> diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
> index 951fb1c..9083783 100644
> --- a/lib/librte_ether/rte_ethdev.c
> +++ b/lib/librte_ether/rte_ethdev.c
> @@ -514,7 +514,6 @@ rte_eth_dev_attach_pdev(struct rte_pci_addr *addr, 
> uint8_t *port_id)
>  
>   return 0;
> [snip]
>  
> @@ -612,14 +599,25 @@ int
>  rte_eth_dev_attach(const char *devargs, uint8_t *port_id)
>  {
>   struct rte_pci_addr addr;
> + int ret = -1;
>  
>   if ((devargs == NULL) || (port_id == NULL))
> - return -EINVAL;
> + goto err;

This change modifies the return value from -EINVAL to -1. I don't know
whether is this an issue but it looks suspicious.

>  
> - if (eal_parse_pci_DomBDF(devargs, &addr) == 0)
> - return rte_eth_dev_attach_pdev(&addr, port_id);
> - else
> - return rte_eth_dev_attach_vdev(devargs, port_id);
> + if (eal_parse_pci_DomBDF(devargs, &addr) == 0) {
> + ret = rte_eth_dev_attach_pdev(&addr, port_id);
> + if (ret < 0)
> + goto err;
> + } else {
> + ret = rte_eth_dev_attach_vdev(devargs, port_id);
> + if (ret < 0)
> + goto err;
> + }
> +
> + return 0;
> +err:
> + RTE_LOG(ERR, EAL, "Driver, cannot attach the device\n");
> + return ret;
>  }
>  
>  /* detach the device, then store the name of the device */
> @@ -627,26 +625,39 @@ int
>  rte_eth_dev_detach(uint8_t port_id, char *name)
>  {
>   struct rte_pci_addr addr;
> - int ret;
> + int ret = -1;
>  
>   if (name == NULL)
> - return -EINVAL;
> + goto err;

Same here...

> +
> + /* check whether the driver supports detach feature, or not */
> + if (rte_eth_dev_is_detachable(port_id))
> + goto err;
>  
> [snip]




-- 
   Jan Viktorin  E-mail: Viktorin at RehiveTech.com
   System Architect  Web:www.RehiveTech.com
   RehiveTech
   Brno, Czech Republic

[dpdk-dev] [PKTGEN] [PATCH 2/2] usage_pktgen.rst: multiple instances: clarify EAL options needed

[Wiles, Keith]

On 1/20/16, 11:50 PM, "dev on behalf of Matthew Hall"  wrote:

>Signed-off-by: Matthew Hall 
>---
> docs/source/usage_pktgen.rst | 15 +++
> 1 file changed, 15 insertions(+)
>
>diff --git a/docs/source/usage_pktgen.rst b/docs/source/usage_pktgen.rst
>index efe8aa4..223d033 100644
>--- a/docs/source/usage_pktgen.rst
>+++ b/docs/source/usage_pktgen.rst
>@@ -157,4 +157,19 @@ The -m option then assigns lcores to the ports.
> The information from above is taken from two new files pktgen-master.sh
> and pktgen-slave.sh, have a look at them and adjust as you need.
> 
>+The following DPDK / EAL options must be configured correctly as well:
>+
>+* ``-l lcore_id_list``: non-conflicting list of lcores for each app

If you are going to add -l option then you need to add the -c option too.
>+
>+* ``--master-lcore lcore_id``: non-conflicting master lcore for each app

This option is not required for pktgen or DPDK, which I think we can leave out.
>+
>+* ``-m hugepage_mb / --socket-mem hugepage_mb_list``: non-conflicting amount
>+of hugepage memory for each app, or for each app on each CPU socket
>+
>+* ``--no-shconf``: prevents DPDK from claiming a lockfile that breaks
>+concurrent use of multiple apps

This one is not required, correct? As long as you set the primary processes 
file-prefix to different prefixes for each one.
>+
>+* ``--file-prefix``: assigns a unique name to the hugepage mmap() files for
>+each app
>+
> Pktgen can also be configured using the :ref:`commands`.
>-- 
>2.5.0
>
>


Regards,
Keith

[dpdk-dev] [PKTGEN] [PATCH 1/2] usage_pktgen.rst: multiple instances: clean up section intro

[Wiles, Keith]

On 1/20/16, 11:50 PM, "dev on behalf of Matthew Hall"  wrote:

>Signed-off-by: Matthew Hall 
>---
> docs/source/usage_pktgen.rst | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
>diff --git a/docs/source/usage_pktgen.rst b/docs/source/usage_pktgen.rst
>index 20bd314..efe8aa4 100644
>--- a/docs/source/usage_pktgen.rst
>+++ b/docs/source/usage_pktgen.rst
>@@ -103,15 +103,15 @@ Multiple Instances of Pktgen or other application
> =
> 
> One possible solution I use and if you have enough ports available to use.
>-Lets say you need two ports for your application, but you have 4 ports in
>-your system. I physically loop back the cables to have port 0 connect to
>-port 2 and port 1 connected to port 3. Now I can give two ports to my
>-application and two ports to Pktgen.
>-
>-Setup if pktgen and your application you have to startup each one a bit
>-differently to make sure they share the resources like memory and the
>-ports. I will use two Pktgen running on the same machine, which just means
>-you have to setup your application as one of the applications.
>+Let's say you need two ports for your application, but you have 4 ports in
>+your system. I physically loop back the cables to have port 0 connect to port
>+2 and port 1 connected to port 3. Now I can give two ports to my application
>+and two ports to Pktgen.

It appears (if I compared the text correctly) the above only move a few 
trailing words to the next line, why?
>+
>+If you are running pktgen and your application together, you have to start up
>+each one a bit differently to make sure they share the resources like memory
>+and the ports. I will use two Pktgens running on the same machine, which just
>+means you have imagine your application as one of the applications.

Maybe this is clearer.

If you are running pktgen and your application together, you have to start up
each one a bit differently to make sure they share the resources like memory,
huge page files and ports. I will use two Pktgens running on the same machine,
which just means you have imagine your application as one of the Pktgen 
instances.


> 
> In my machine I have 8 10G ports and 72 lcores between 2 sockets. Plus I
> have 1024 hugepages per socket for a total of 2048.
>-- 
>2.5.0
>
>


Regards,
Keith

[dpdk-dev] [PATCH v6 08/11] eal: pci: introduce RTE_KDRV_VFIO_NOIOMMUi driver mode

[Santosh Shukla]

On Thu, Jan 21, 2016 at 8:16 PM, Thomas Monjalon
 wrote:
> 2016-01-21 17:34, Santosh Shukla:
>> On Thu, Jan 21, 2016 at 4:58 PM, Thomas Monjalon
>>  wrote:
>> > 2016-01-21 16:43, Santosh Shukla:
>> >> David Marchand  wrote:
>> >> > This is a mode (specific to vfio), not a new kernel driver.
>> >> >
>> >> Yes, Specific to VFIO and this is why noiommu appended after vfio i.e..
>> >> __VFIO and __VFIO_NOIOMMU.
>> >
>> > Woaaa! Your logic is really disappointing :)
>> > Specific to VFIO => append _NOIOMMU
>> > If it's for VFIO, it should be called VFIO (that's my logic).
>> >
>> I am confused by reading your comment. vfio works for default iommu
>> and now with noiommu. drv->kdrv need to know driver mode for vfio
>> case. So that user can simply read drv->kdrv value in their driver and
>> accordingly use vfio rd/wr api for example {pread/pwrite}. This is how
>> rte_eal_pci_vfio_read/write_bar() api implemented.
>
> Sorry I don't understand. Why EAL read/write functions should be different
> depending of the VFIO mode?
>

no, EAL rd/wr functions are not different for vfio or vfio modes {same
for iommu or noiommu}. Pl. see pci_eal_read/write_bar() api. Those
apis currently used for VFIO, Irrespective of vfio mode. If required,
we can add UIO bar_rd/wr api too. pci_eal_rd/wr_bar() are abstract
apis. Underneath implementation can be vfio or uio type.

>> And Yes it is called VFIO but with with specifics appended in it.
>>
>> >> > How come we need to distinguish between with/without iommu modes ?
>> >>
>> >> By default vfio framework assumes iommu i.,e., iommu present. Unless user
>> >> explicitly set "enable_unsafe_noiommu_mode" param. so in my opinion, we
>> >> care to parse vfio driver for _noiommu_ mode only.
>> >
>> > Why do we care to parse noiommu only?
>>
>> Because pmd drivers example virtio can work with vfio only in
>> _noiommu_ mode. In particular, virtio spec 0.95 / legacy virtio.
>
> Please could you explain the limitation (except IOMMU availability)?
>

Ok.

I believe - we both agree that noiommu mode is a need for pmd drivers
like virtio, right? if so then other reason is implementation driven
i.e..

Pl. look at virtio_pci.c in this patch.. VIRTIO_RD/WR/_1/2/4()
implementation. They are in-use and applicable to  virtio spec 0.95,
so far support uio/ioport-way rd/wr. Now to support vfio-way rd/wr -
need to check drv->kdrv value, that value should be of vfio_noiommu
types __not__  generic _vfio types.

>> So at
>> the initialization (example .. virtio-net) of such pmd driver, pmd
>> driver should know that vfio-with-noiommu mode enabled or not? for
>> that pmd driver simply checks drv->kdrv value.
>
> If a check is needed, I would prefer using your function
> pci_vfio_is_noiommu() and remove driver modes from struct rte_kernel_driver.
>

I don't think calling pci_vfio_no_iommu() inside
virtio_reg_rd/wr_1/2/3() would be a good idea.

>> Currently virtio-net
>> pmd driver does resource parsing then resource init for interfaces
>> like UIO/ioport, I intend to do same but only parsing, as resource
>> init for vfio case already taken care by pci_xx_vfio_map() api in
>> virtio-net pmd driver (refer Yaun recently virtio 1.0 recently
>> submitted rte_eal_pci_map patch)
>>
>> Also Yuan in one of earlier thread inclined to remove all the resource
>> parsing api from virtio-net pmd driver. Pl. refer this thread [1]
>>
>> [1] http://dpdk.org/dev/patchwork/patch/9862/
>
> Yes he said
> "we should try to avoid getting UIO/VFIO stuff inside virtio pmd driver".
> I agree we must try to have those abstractions in EAL.

Right,

IMO vfio now has that abstraction in place and pmd driver only to
check driver type, which virtio-net pmd doing for vfio case. `

> The only exception seems to be the switch ioport/PCI bar to read/write
> in virtio.
>

Right, and only applicable for x86 arch, wont work for non-x86 archs.

>> > Even if virtio cannot work in an IOMMU case, there is no reason to add
>> > a VFIO_NOIOMMU type here.
>> >
>> >> > Should not vfio behave the same way from an api point of view ?
>> >> >
>> >> Yes It should. vfio gives similar file_ops i.e.. read/write/mmap/seek 
>> >> etc..
>> >> I am little confused on your question, do you see any issue in vfio bar
>> >> rd/wr api implementation?
>> >
>> > I think you should just consider the VFIO API and let the noiommu option
>> > as a kernel configuration detail.
>>
>> vfio apis _are_ considered at low level rd/wr implementation, Has
>> nothing to do with iommu/noiommu mode. See pci_vfio_read/write_bar()
>> implementation, they are using pread64/pwrite64() vfio rd/wr api.
>
> So you agree that the VFIO API abstract the iommu availability details?
>

didn't understood your question,
>

[dpdk-dev] [dpdk-dev, 2/2] ethdev: move code to common place in hotplug

[David Marchand]

On Thu, Jan 21, 2016 at 4:38 PM, Jan Viktorin  
wrote:
> On Thu, 21 Jan 2016 12:57:11 +0100
> David Marchand  wrote:
>
[snip]
>> @@ -612,14 +599,25 @@ int
>>  rte_eth_dev_attach(const char *devargs, uint8_t *port_id)
>>  {
>>   struct rte_pci_addr addr;
>> + int ret = -1;
>>
>>   if ((devargs == NULL) || (port_id == NULL))
>> - return -EINVAL;
>> + goto err;
>
> This change modifies the return value from -EINVAL to -1. I don't know
> whether is this an issue but it looks suspicious.

Should not be an issue, as the api does not give details on expected
negative return values.
Just noticed, this also introduces a new log message that was not
displayed before.

To be safe, I suppose I should restore this.

Thomas, opinion ?


Thanks.
-- 
David Marchand

[dpdk-dev] [dpdk-dev, 2/2] ethdev: move code to common place in hotplug

[Thomas Monjalon]

2016-01-21 19:06, David Marchand:
> On Thu, Jan 21, 2016 at 4:38 PM, Jan Viktorin  
> wrote:
> > On Thu, 21 Jan 2016 12:57:11 +0100
> > David Marchand  wrote:
> >
> [snip]
> >> @@ -612,14 +599,25 @@ int
> >>  rte_eth_dev_attach(const char *devargs, uint8_t *port_id)
> >>  {
> >>   struct rte_pci_addr addr;
> >> + int ret = -1;
> >>
> >>   if ((devargs == NULL) || (port_id == NULL))
> >> - return -EINVAL;
> >> + goto err;
> >
> > This change modifies the return value from -EINVAL to -1. I don't know
> > whether is this an issue but it looks suspicious.
> 
> Should not be an issue, as the api does not give details on expected
> negative return values.
> Just noticed, this also introduces a new log message that was not
> displayed before.
> 
> To be safe, I suppose I should restore this.
> 
> Thomas, opinion ?

I'm OK with the log message added for this error case.
I would just keep the -EINVAL return value.

Other nit: you are allowed to fix the (moved) log message.

[dpdk-dev] [PKTGEN] fixing weird termio issues that complicate debugging

[Stephen Hemminger]

On Thu, 21 Jan 2016 15:03:37 +
"Wiles, Keith"  wrote:

> On 1/21/16, 2:46 AM, "Panu Matilainen"  wrote:
> 
> >On 01/20/2016 06:26 PM, Wiles, Keith wrote:
> >> On 1/20/16, 12:32 AM, "dev on behalf of Matthew Hall"  >> dpdk.org on behalf of mhall at mhcomputing.net> wrote:
> >>
> >>> Hello,
> >>>
> >>> Since the pktgen code is reindented I am finding time to read through it
> >>> and experiment and see if I can get it working.
> >>>
> >>> I have issues with the init process of pktgen. It is difficult to debug
> >>> it because the init code does a lot of very scary stuff to the terminal
> >>> control / TTY device at inconvenient times in an inconvenient order, and
> >>> in the process damages the debug output and damages the screen of your
> >>> GDB without doing weird things to run GDB on a different TTY.
> >>>
> >>> Of course I am willing to contribute patches and not just complain, but
> >>> first I need some help to follow what is going on.
> >>>
> >>> Here is the problematic call-flow with some explanation what went wrong
> >>> trying it on some community machines outside of its original environment:
> >>>
> >>> 1) it calls printf("\n%s %s\n", wr_copyright_msg(), wr_powered_by());
> >>> which dumps tons of weird boilerplate of licenses, copyrights, code
> >>> creator, etc.
> >>>
> >>> It is open source and everybody that matters already knows who coded it,
> >>> so is this stuff really that important? This gets in the way when you
> >>> are trying to work on it and I just have to comment it out.
> >>
> >> One problem is a number of people wanted to steal the code and use in
> >> a paid application, so the copyright is some what a requirement.
> >
> >In that case, why is it under a BSD'ish license instead of something 
> >like GPL that's designed to prevent it in the first place? Might be too 
> >late to change it by now, just wondering.
> 
> DPDK is BSD, so you can not use a GPL application with DPDK (I think) anyway 
> I can try to speed you the screens, but does it really matter as these are 
> only at startup and I normally leave pktgen running for long periods of time. 
> The extra time at the start does not seem to be a big issue, right?
> 
> >
> >> As you may know I do a lot of debugging on Pktgen and I feel they are
> >> a nuisance. I can try to see if we can clean up these messages, but
> >> do not hold your breath on getting them to be removed.
> >
> >It would make a world of difference if it just printed the copyright etc 
> >in a couple of lines during startup, instead of taking over the entire 
> >screen for several seconds.
> >
> >This is a whole lot like those anti-piracy ad campaigns on DVDs which 
> >you cant skip, so all the *legitimate* users are forced to suffer 
> >through them but all the bad guys just rip it out of their copies. DRM 
> >that ends up hurting the legitimate users the most is never a good idea.
> >
> > - Panu -
> >
> >
> >
> 
> 
> Regards,
> Keith

I would rip out the whole tty control and theming nonsense and then
just print one line copyright on startup.

[dpdk-dev] [dpdk-dev,1/2] ethdev: remove useless null checks

[Jan Viktorin]

On Thu, 21 Jan 2016 12:57:10 +0100
David Marchand  wrote:

> We are in static functions and those passed arguments can't be NULL.
> 
> Signed-off-by: David Marchand 
> 
> ---
> lib/librte_ether/rte_ethdev.c | 15 ---
>  1 file changed, 15 deletions(-)
> 
> diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
> index af990e2..951fb1c 100644
> --- a/lib/librte_ether/rte_ethdev.c
> +++ b/lib/librte_ether/rte_ethdev.c
> @@ -220,9 +220,6 @@ rte_eth_dev_create_unique_device_name(char *name, size_t 
> size,
>  {
>   int ret;
>  
> - if ((name == NULL) || (pci_dev == NULL))
> - return -EINVAL;

Do you use a kind of assert in DPDK? The patch looks OK, however, I
would prefer something like

assert_not_null(name);
assert_not_null(pci_dev);

Usually, if some outer code is broken by mistake, the assert catches
such an issue. At the same time, it documents the code by telling
"this must never be NULL here". I agree, that returning -EINVAL for
this kind of check is incorrect.

Same for other changes...

> [snip]

[dpdk-dev] [PKTGEN] dumb question: how to start packet TX and set the payload

[Matthew Hall]

On Thu, Jan 21, 2016 at 03:05:38PM +, Wiles, Keith wrote:
> Forgot to answer this one. Pktgen does not allow the user to define the 
> content of the packet per say only the fill pattern and what ever you 
> configure the packet type to be. If you would like to submit a patch for 
> adding user specific content it has always been a goal of my to add that 
> feature.

I am happy to work to make the patch, it would help if you could provide some 
hints where in the code I should look... when I went searching for seqCnt I 
found a packet-constructor function run in a loop when applying a 
packet-sequence operation. Is the packet-constructor the right place or should 
I look somewhere else?

Matthew.

[dpdk-dev] [PKTGEN] dumb question: how to start packet TX and set the payload

[Matthew Hall]

On Thu, Jan 21, 2016 at 03:01:33PM +, Wiles, Keith wrote:
> The problem is you used the same core (2) for the -m option. Core 2 is being 
> used for the keyboard, timer and screen output. This means you must have the 
> -m option starting with core 3 as in -m 3.0 and your problem should go away. 
> The first or master core is consume by Pktgen to handle the previous stuff 
> and you must start with the next cores for Rx/Tx of packets. I really need 
> to put tests in the code, which I will try to add soon.

I'll see if I can figure out some patches for that.

Matthew.

[dpdk-dev] virtio ring layout changes for optimal single-stream performance

[Michael S. Tsirkin]

On Thu, Jan 21, 2016 at 04:38:36PM +0100, Cornelia Huck wrote:
> On Thu, 21 Jan 2016 15:39:26 +0200
> "Michael S. Tsirkin"  wrote:
> 
> > Hi all!
> > I have been experimenting with alternative virtio ring layouts,
> > in order to speed up single stream performance.
> > 
> > I have just posted a benchmark I wrote for the purpose, and a (partial)
> > alternative layout implementation.  This achieves 20-40% reduction in
> > virtio overhead in the (default) polling mode.
> > 
> > http://article.gmane.org/gmane.linux.kernel.virtualization/26889
> > 
> > The layout is trying to be as simple as possible, to reduce
> > the number of cache lines bouncing between CPUs.
> 
> Some kind of diagram or textual description would really help to review
> this.
> 
> > 
> > For benchmarking, the idea is to emulate virtio in user-space,
> > artificially adding overhead for e.g. signalling to match what happens
> > in case of a VM.
> 
> Hm... is this overhead comparable enough between different platform so
> that you can get a halfway realistic scenario?

On x86 is seems pretty stable.
It's a question of setting VMEXIT_CYCLES and VMENTRY_CYCLES correctly.

> What about things like
> endianness conversions?

I didn't bother with them yet.

> > 
> > I'd be very curious to get feedback on this, in particular, some people
> > discussed using vectored operations to format virtio ring - would it
> > conflict with this work?
> > 
> > You are all welcome to post enhancements or more layout alternatives as
> > patches.
> 
> Let me see if I can find time to experiment a bit.

[dpdk-dev] virtio ring layout changes for optimal single-stream performance

[Cornelia Huck]

On Thu, 21 Jan 2016 15:39:26 +0200
"Michael S. Tsirkin"  wrote:

> Hi all!
> I have been experimenting with alternative virtio ring layouts,
> in order to speed up single stream performance.
> 
> I have just posted a benchmark I wrote for the purpose, and a (partial)
> alternative layout implementation.  This achieves 20-40% reduction in
> virtio overhead in the (default) polling mode.
> 
> http://article.gmane.org/gmane.linux.kernel.virtualization/26889
> 
> The layout is trying to be as simple as possible, to reduce
> the number of cache lines bouncing between CPUs.

Some kind of diagram or textual description would really help to review
this.

> 
> For benchmarking, the idea is to emulate virtio in user-space,
> artificially adding overhead for e.g. signalling to match what happens
> in case of a VM.

Hm... is this overhead comparable enough between different platform so
that you can get a halfway realistic scenario? What about things like
endianness conversions?

> 
> I'd be very curious to get feedback on this, in particular, some people
> discussed using vectored operations to format virtio ring - would it
> conflict with this work?
> 
> You are all welcome to post enhancements or more layout alternatives as
> patches.

Let me see if I can find time to experiment a bit.

[dpdk-dev] [PKTGEN] dumb question: how to start packet TX and set the payload

[Wiles, Keith]

On 1/21/16, 1:00 PM, "Matthew Hall"  wrote:

>On Thu, Jan 21, 2016 at 03:05:38PM +, Wiles, Keith wrote:
>> Forgot to answer this one. Pktgen does not allow the user to define the 
>> content of the packet per say only the fill pattern and what ever you 
>> configure the packet type to be. If you would like to submit a patch for 
>> adding user specific content it has always been a goal of my to add that 
>> feature.
>
>I am happy to work to make the patch, it would help if you could provide some 
>hints where in the code I should look... when I went searching for seqCnt I 
>found a packet-constructor function run in a loop when applying a 
>packet-sequence operation. Is the packet-constructor the right place or should 
>I look somewhere else?

The packet-constructor builds the different types single, range, sequence and 
PCAP packets, before the packets are sent.

What type of data do you want to add to the packets? Now it builds IPv4/UDP/TCP 
packets, do you need to replace UDP or TCP or just add more protocol layers?
>
>Matthew.
>


Regards,
Keith

[dpdk-dev] [PKTGEN] fixing weird termio issues that complicate debugging

[Matthew Hall]

On Thu, Jan 21, 2016 at 11:00:14AM -0800, Stephen Hemminger wrote:
> I would rip out the whole tty control and theming nonsense and then
> just print one line copyright on startup.

Personally, I might have put this sentiment more diplomatically, but a 
refactor effort such as this would make life easier for me coming from the 
community trying to work with this tool.

When I get a bit deeper into it, I'll see if I can help.

Matthew.

[dpdk-dev] [PATCH 2/4] i40e: split function for input set change of hash and fdir

[Chilikin, Andrey]

Hi Jingjing,

> -Original Message-
> From: Wu, Jingjing
> Sent: Thursday, January 21, 2016 1:29 AM
> To: Chilikin, Andrey; dev at dpdk.org
> Cc: Zhang, Helin; Pei, Yulong; Ananyev, Konstantin
> Subject: RE: [PATCH 2/4] i40e: split function for input set change of hash and
> fdir
> 
> Hi, Andrey
> 
> Thanks for your comments. You are correct, I removed the
> I40E_INSET_FLEX_PAYLOAD from valid fdir input set values, and this is one
> reason why I splited function for input set change of hash and and it is 
> because
> all flex payload configuration can be set in struct rte_fdir_conf during 
> device
> configure phase. And it is a more flexible configuration including 
> flexpayload's
> selection, input set selection by word and mask setting in bits.

Should it be then two patches? First patch to split fdir and hash input set 
configuration and then second one to remove existing functionality? At the 
moment it is not obvious that this patch not just splits fdir input set 
configuration but removes some features in a way that fdir it is not compatible 
with DPDK 2.2 anymore.

> 
> If I enable it in the input set change API, it will be duplicate. And the 
> input set
> change on flexible payload only on word, just some ability compared with
> rte_fdir_conf.
> If flexible selection isn't done in  struct rte_fdir_conf, the input set 
> selection in
> input set change API doesn't make sense. If flexible selection is done in 
> struct
> rte_fdir_conf, why not selection input set in struct rte_fdir_conf at the same
> time?

I do not have a problem with selecting it at the same time - it always was this 
way with the legacy systems. But now new NIC supports new way of configuring 
input set with flexible payload as a part of this input set. So why not to have 
new way of configuration available as well and change input set using one API 
call instead of splitting single configuration in to two parts?

> And about you concern, "when application has to run on an old NIC and on a
> new one", The rte_fdir_conf is for each eth_dev, so it will be fine.
> 
> Thanks
> Jingjing

Regards,
Andrey

> 
> 
> > -Original Message-
> > From: Chilikin, Andrey
> > Sent: Thursday, January 21, 2016 4:05 AM
> > To: Wu, Jingjing; dev at dpdk.org
> > Cc: Zhang, Helin; Pei, Yulong; Ananyev, Konstantin
> > Subject: RE: [PATCH 2/4] i40e: split function for input set change of
> > hash and fdir
> >
> > Hi Jingjing,
> >
> > As I can see this patch not only splits fdir functionality from common
> > fdir/hash code but also removes compatibility with DPDK 2.2 as it
> > deletes I40E_INSET_FLEX_PAYLOAD from valid fdir input set values. Yes,
> > flexible payload configuration can be set for fdir separately at the
> > port initialization, but this is more legacy from the previous
> > generations of NICs which did not support dynamic input set
> > configuration. I believe it would better to have
> > I40E_INSET_FLEX_PAYLOAD valid for fdir input set same as in DPDK 2.2.
> > So in legacy mode, when application has to run on an old NIC and on a
> > new one, only legacy configuration would be used, but for applications
> targeting new HW single point of configuration would be used instead of mix of
> two.
> >
> > Regards,
> > Andrey
> >

[dpdk-dev] [PKTGEN] dumb question: how to start packet TX and set the payload

[Matthew Hall]

On Thu, Jan 21, 2016 at 07:44:21PM +, Wiles, Keith wrote:
> What type of data do you want to add to the packets? Now it builds 
> IPv4/UDP/TCP packets, do you need to replace UDP or TCP or just add more 
> protocol layers?

I perform content inspection of various types:

IPv4 - supported
IPv6 - supported
TCP - supported
UDP - supported
DNS - need custom binary payload
sFlow - need custom binary payload
Netflow - need custom sequence (supported) and custom binary payload
UDP Syslog - need custom ASCII payload (binary would of course work)

TCP Syslog - need custom ASCII payload (probably impossible w/ this tool as a 
three-way handshake is needed for me to begin receiving in the app, which is 
among other things a high performance Syslog digester, but UDP is enough for 
now)

Because it's a security app I have to model things like "99% boring, 1% 
interesting" as packets which raise alerts cost more resources than packets 
which do not.

Matthew.

[dpdk-dev] [PATCH] igb: set default thresholds correctly based on mac type

[Stephen Hemminger]

This brings the DPDK igb driver inline with the behavior used by
the current Linux driver. The IGB hardware has several different
MAC types and the threshold values that work vary based on the hardware.

Since DPDK 1.8 it has been up to devices to provide the correct default
configuration parameter. But the igb driver gives values that are broken
on some devices, and always causes a warning message at startup.

Please test this on real hardware, I don't have the luxury of a
hardware lab full of variations of this chip.

Signed-off-by: Stephen Hemminger 
---
 drivers/net/e1000/igb_ethdev.c | 11 ++-
 drivers/net/e1000/igb_rxtx.c   |  8 
 2 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index d1bbcda..31b2c1f 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -61,13 +61,14 @@
  * Default values for port configuration
  */
 #define IGB_DEFAULT_RX_FREE_THRESH  32
-#define IGB_DEFAULT_RX_PTHRESH  8
+
+#define IGB_DEFAULT_RX_PTHRESH  ((hw->mac.type == e1000_i354) ? 12 : 8)
 #define IGB_DEFAULT_RX_HTHRESH  8
-#define IGB_DEFAULT_RX_WTHRESH  0
+#define IGB_DEFAULT_RX_WTHRESH  ((hw->mac.type == e1000_82576) ? 1 : 4)

-#define IGB_DEFAULT_TX_PTHRESH  32
-#define IGB_DEFAULT_TX_HTHRESH  0
-#define IGB_DEFAULT_TX_WTHRESH  0
+#define IGB_DEFAULT_TX_PTHRESH  ((hw->mac.type == e1000_i354) ? 20: 8)
+#define IGB_DEFAULT_TX_HTHRESH  1
+#define IGB_DEFAULT_TX_WTHRESH  ((hw->mac.type == e1000_82576) ? 1 : 16)

 #define IGB_HKEY_MAX_INDEX 10

diff --git a/drivers/net/e1000/igb_rxtx.c b/drivers/net/e1000/igb_rxtx.c
index 996e7da..499b6b4 100644
--- a/drivers/net/e1000/igb_rxtx.c
+++ b/drivers/net/e1000/igb_rxtx.c
@@ -1315,13 +1315,13 @@ eth_igb_tx_queue_setup(struct rte_eth_dev *dev,
 * driver.
 */
if (tx_conf->tx_free_thresh != 0)
-   PMD_INIT_LOG(WARNING, "The tx_free_thresh parameter is not "
+   PMD_INIT_LOG(INFO, "The tx_free_thresh parameter is not "
 "used for the 1G driver.");
if (tx_conf->tx_rs_thresh != 0)
-   PMD_INIT_LOG(WARNING, "The tx_rs_thresh parameter is not "
+   PMD_INIT_LOG(INFO, "The tx_rs_thresh parameter is not "
 "used for the 1G driver.");
-   if (tx_conf->tx_thresh.wthresh == 0)
-   PMD_INIT_LOG(WARNING, "To improve 1G driver performance, "
+   if (tx_conf->tx_thresh.wthresh == 0 && hw->mac.type != e1000_82576)
+   PMD_INIT_LOG(INFO, "To improve 1G driver performance, "
 "consider setting the TX WTHRESH value to 4, 8, "
 "or 16.");

-- 
2.1.4

[dpdk-dev] DPDK mbuf pool in SR-IOV env and one RX/TX queue

[Saurabh Mishra]

Hi,


Is it possible for two or more processes to share the same mbuf_pool in
SR-IOV with single rx/tx queue?



 char *eal_argv[] = {"fakeelf",

"-c2",

"-n4",

"--proc-type=primary",};


int ret = rte_eal_init(4, eal_argv);

And for secondary, we are passing --proc-type=secondary and adjust -c
option according to the core number (1 << core_num).

rte_pktmbuf_pool_create(mbuf_pool_name,
NB_MBUFS,

MBUF_CACHE_SIZE, 0,
RTE_MBUF_DEFAULT_BUF_SIZE,

rte_socket_id());



We have seen that it does not work. However, with PCI pass through of whole
NIC, we can easily share same mbuf_pool with many processes.


What are the limitations with SR-IOV and DPDK? If we create one primary and
don't create any  secondary proc-type, then that seems to work with SR-IOV.
However, the moment we add a secondary process, rte_mempool_lookup()
returns NULL.


Note that we see only 1 queue for rx and tx and multi-queue gets disabled
the moment we enable VFs.


[683877.050219] ixgbe :06:00.0: *Multi*queue Disabled: Rx Queue count =
1, Tx Queue count = 1

[683879.799872] ixgbe :06:00.1: *Multi*queue Disabled: Rx Queue count =
1, Tx Queue count = 1

The device is question is as follows:



06:00.0 *Ether*net controller: Intel Corporation 82599ES 10-Gigabit
SFI/SFP+ Network Connection (rev 01)

06:00.1 *Ether*net controller: Intel Corporation 82599ES 10-Gigabit
SFI/SFP+ Network Connection (rev 01)

06:10.0 *Ether*net controller: Intel Corporation 82599 *Ether*net
Controller Virtual Function (rev 01)

06:10.1 *Ether*net controller: Intel Corporation 82599 *Ether*net
Controller Virtual Function (rev 01)

06:10.2 *Ether*net controller: Intel Corporation 82599 *Ether*net
Controller Virtual Function (rev 01)

06:10.3 *Ether*net controller: Intel Corporation 82599 *Ether*net
Controller Virtual Function (rev 01)



Thanks,

/Saurabh