[dpdk-dev] [PATCH RFC v2 08/12] lib/librte_vhost: vhost-user support

[Tetsuya Mukawa]

(2014/12/11 6:37), Huawei Xie wrote:
> vhost-user support
>
>
> Signed-off-by: Huawei Xie 
> ---
>  lib/librte_vhost/Makefile |   5 +-
>  lib/librte_vhost/vhost-net.h  |   4 +
>  lib/librte_vhost/vhost_cuse/virtio-net-cdev.c |   9 +
>  lib/librte_vhost/vhost_user/vhost-net-user.c  | 422 
> ++
>  lib/librte_vhost/vhost_user/vhost-net-user.h  | 108 +++
>  lib/librte_vhost/vhost_user/virtio-net-user.c | 199 
>  lib/librte_vhost/vhost_user/virtio-net-user.h |  48 +++
>  lib/librte_vhost/virtio-net.c |  16 +-
>  lib/librte_vhost/virtio-net.h |  43 +++
>  9 files changed, 842 insertions(+), 12 deletions(-)
>  create mode 100644 lib/librte_vhost/vhost_user/vhost-net-user.c
>  create mode 100644 lib/librte_vhost/vhost_user/vhost-net-user.h
>  create mode 100644 lib/librte_vhost/vhost_user/virtio-net-user.c
>  create mode 100644 lib/librte_vhost/vhost_user/virtio-net-user.h
>  create mode 100644 lib/librte_vhost/virtio-net.h
>
> diff --git a/lib/librte_vhost/Makefile b/lib/librte_vhost/Makefile
> index e0d0ef6..b2f14a0 100644
> --- a/lib/librte_vhost/Makefile
> +++ b/lib/librte_vhost/Makefile
> @@ -34,10 +34,11 @@ include $(RTE_SDK)/mk/rte.vars.mk
>  # library name
>  LIB = librte_vhost.a
>  
> -CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -I vhost_cuse -O3 
> -D_FILE_OFFSET_BITS=64 -lfuse
> +CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -I vhost_cuse -I vhost_user -O3 
> -D_FILE_OFFSET_BITS=64 -lfuse
>  LDFLAGS += -lfuse
>  # all source are stored in SRCS-y
> -SRCS-$(CONFIG_RTE_LIBRTE_VHOST) := vhost_cuse/vhost-net-cdev.c 
> vhost_cuse/virtio-net-cdev.c virtio-net.c vhost_rxtx.c
> +#SRCS-$(CONFIG_RTE_LIBRTE_VHOST) := vhost_cuse/vhost-net-cdev.c 
> vhost_cuse/virtio-net-cdev.c virtio-net.c vhost_rxtx.c
> +SRCS-$(CONFIG_RTE_LIBRTE_VHOST) := vhost_user/vhost-net-user.c 
> vhost_user/virtio-net-user.c vhost_user/fd_man.c virtio-net.c vhost_rxtx.c
>  
>  # install includes
>  SYMLINK-$(CONFIG_RTE_LIBRTE_VHOST)-include += rte_virtio_net.h
> diff --git a/lib/librte_vhost/vhost-net.h b/lib/librte_vhost/vhost-net.h
> index f7e96fd..f9ec40b 100644
> --- a/lib/librte_vhost/vhost-net.h
> +++ b/lib/librte_vhost/vhost-net.h
> @@ -41,8 +41,12 @@
>  
>  #include 
>  
> +#include "rte_virtio_net.h"
> +
>  #define VHOST_MEMORY_MAX_NREGIONS 8
>  
> +extern struct vhost_net_device_ops const *ops;
> +
>  /* Macros for printing using RTE_LOG */
>  #define RTE_LOGTYPE_VHOST_CONFIG RTE_LOGTYPE_USER1
>  #define RTE_LOGTYPE_VHOST_DATA   RTE_LOGTYPE_USER1
> diff --git a/lib/librte_vhost/vhost_cuse/virtio-net-cdev.c 
> b/lib/librte_vhost/vhost_cuse/virtio-net-cdev.c
> index edcbc10..8ac3360 100644
> --- a/lib/librte_vhost/vhost_cuse/virtio-net-cdev.c
> +++ b/lib/librte_vhost/vhost_cuse/virtio-net-cdev.c
> @@ -268,6 +268,7 @@ cuse_set_mem_table(struct vhost_device_ctx ctx,
>   struct vhost_memory_region *mem_regions = (void *)(uintptr_t)
>   ((uint64_t)(uintptr_t)mem_regions_addr + size);
>   uint64_t base_address = 0, mapped_address, mapped_size;
> + struct virtio_dev *dev;
>  
>   for (idx = 0; idx < nregions; idx++) {
>   regions[idx].guest_phys_address =
> @@ -335,6 +336,14 @@ cuse_set_mem_table(struct vhost_device_ctx ctx,
>   regions[idx].guest_phys_address;
>   }
>  
> + dev = get_device(ctx);
> + if (dev && dev->mem && dev->mmaped_address) {
> + munmap((void *)(uintptr_t)dev->mmaped_address,
> + (size_t)dev->mmaped_size);
> + free(dev->mem);
> + dev->mem = NULL;
> + }
> +
>   ops->set_mem_table(ctx, [0], valid_regions);
>   return 0;
>  }
> diff --git a/lib/librte_vhost/vhost_user/vhost-net-user.c 
> b/lib/librte_vhost/vhost_user/vhost-net-user.c
> new file mode 100644
> index 000..841d7e6
> --- /dev/null
> +++ b/lib/librte_vhost/vhost_user/vhost-net-user.c
> @@ -0,0 +1,422 @@
> +/*-
> + *   BSD LICENSE
> + *
> + *   Copyright(c) 2010-2014 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 

[dpdk-dev] [PATCH] i40e: workaround for XL710 performance

[Helin Zhang]

on XL710, performance number is far from the expectation on recent
firmware versions, if promiscuous mode is disabled, or promiscuous
mode is enabled and port MAC address is equal to the packet
destination MAC address. The fix for this issue may not be integrated
in the following firmware version. So the workaround in software
driver is needed. It needs to modify the initial values of 2 internal
only registers which is the same 2 of 3 registers of it did for X710.
Note that the workaround can be removed when it is fixed in firmware
in the future.

Signed-off-by: Helin Zhang 
---
 lib/librte_pmd_i40e/i40e_ethdev.c | 35 ++-
 1 file changed, 22 insertions(+), 13 deletions(-)

diff --git a/lib/librte_pmd_i40e/i40e_ethdev.c 
b/lib/librte_pmd_i40e/i40e_ethdev.c
index b47a3d2..3bb75d8 100644
--- a/lib/librte_pmd_i40e/i40e_ethdev.c
+++ b/lib/librte_pmd_i40e/i40e_ethdev.c
@@ -5327,21 +5327,30 @@ i40e_debug_read_register(struct i40e_hw *hw, uint32_t 
addr, uint64_t *val)

 /*
  * On X710, performance number is far from the expectation on recent firmware
- * versions. The fix for this issue may not be integrated in the following
+ * versions; on XL710, performance number is also far from the expectation on
+ * recent firmware versions, if promiscuous mode is disabled, or promiscuous
+ * mode is enabled and port MAC address is equal to the packet destination MAC
+ * address. The fix for this issue may not be integrated in the following
  * firmware version. So the workaround in software driver is needed. It needs
- * to modify the initial values of 3 internal only registers. Note that the
- * workaround can be removed when it is fixed in firmware in the future.
+ * to modify the initial values of 3 internal only registers for X710, and the
+ * same 2 internal registers for XL710. Note that the workaround can be removed
+ * when it is fixed in firmware in the future.
  */
-static void
-i40e_configure_registers(struct i40e_hw *hw)
-{
-#define I40E_GL_SWR_PRI_JOIN_MAP_0   0x26CE00
-#define I40E_GL_SWR_PRI_JOIN_MAP_2   0x26CE08
-#define I40E_GL_SWR_PM_UP_THR0x269FBC
+
+/* For both X710 and XL710 */
 #define I40E_GL_SWR_PRI_JOIN_MAP_0_VALUE 0x1200
+#define I40E_GL_SWR_PRI_JOIN_MAP_0   0x26CE00
+
 #define I40E_GL_SWR_PRI_JOIN_MAP_2_VALUE 0x011f0200
+#define I40E_GL_SWR_PRI_JOIN_MAP_2   0x26CE08
+
+/* For X710 only */
 #define I40E_GL_SWR_PM_UP_THR_VALUE  0x03030303
+#define I40E_GL_SWR_PM_UP_THR0x269FBC

+static void
+i40e_configure_registers(struct i40e_hw *hw)
+{
static const struct {
uint32_t addr;
uint64_t val;
@@ -5354,11 +5363,11 @@ i40e_configure_registers(struct i40e_hw *hw)
uint32_t i;
int ret;

-   /* Below fix is for X710 only */
-   if (i40e_is_40G_device(hw->device_id))
-   return;
-
for (i = 0; i < RTE_DIM(reg_table); i++) {
+   if ((i40e_is_40G_device(hw->device_id)) &&
+   (reg_table[i].addr == I40E_GL_SWR_PM_UP_THR))
+   continue;
+
ret = i40e_debug_read_register(hw, reg_table[i].addr, );
if (ret < 0) {
PMD_DRV_LOG(ERR, "Failed to read from 0x%"PRIx32,
-- 
1.9.3

[dpdk-dev] [PATCH v3 6/6] testpmd: Set Rx VMDq RSS mode

[Ouyang Changchun]

Set VMDq RSS mode if it has VF(VF number is more than 1) and has RSS 
information.

Signed-off-by: Changchun Ouyang 
---
 app/test-pmd/testpmd.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 8c69756..6230f8b 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -1708,6 +1708,16 @@ init_port_config(void)
port->dev_conf.rxmode.mq_mode = ETH_MQ_RX_NONE;
}

+   if (port->dev_info.max_vfs != 0) {
+   if (port->dev_conf.rx_adv_conf.rss_conf.rss_hf != 0)
+   port->dev_conf.rxmode.mq_mode =
+   ETH_MQ_RX_VMDQ_RSS;
+   else {
+   port->dev_conf.rxmode.mq_mode = ETH_MQ_RX_NONE;
+   port->dev_conf.txmode.mq_mode = ETH_MQ_TX_NONE;
+   }
+   }
+
port->rx_conf.rx_thresh = rx_thresh;
port->rx_conf.rx_free_thresh = rx_free_thresh;
port->rx_conf.rx_drop_en = rx_drop_en;
-- 
1.8.4.2

[dpdk-dev] [PATCH v3 5/6] ixgbe: Config VF RSS

[Ouyang Changchun]

It needs config RSS and IXGBE_MRQC and IXGBE_VFPSRTYPE to enable VF RSS.

The psrtype will determine how many queues the received packets will distribute 
to,
and the value of psrtype should depends on both facet: max VF rxq number which
has been negotiated with PF, and the number of rxq specified in config on guest.

Signed-off-by: Changchun Ouyang 
---
 lib/librte_pmd_ixgbe/ixgbe_pf.c   | 15 +++
 lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 92 ++-
 2 files changed, 97 insertions(+), 10 deletions(-)

diff --git a/lib/librte_pmd_ixgbe/ixgbe_pf.c b/lib/librte_pmd_ixgbe/ixgbe_pf.c
index cbb0145..9c9dad8 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_pf.c
+++ b/lib/librte_pmd_ixgbe/ixgbe_pf.c
@@ -187,6 +187,21 @@ int ixgbe_pf_host_configure(struct rte_eth_dev *eth_dev)
IXGBE_WRITE_REG(hw, IXGBE_MPSAR_LO(hw->mac.num_rar_entries), 0);
IXGBE_WRITE_REG(hw, IXGBE_MPSAR_HI(hw->mac.num_rar_entries), 0);

+   /*
+* VF RSS can support at most 4 queues for each VF, even if
+* 8 queues are available for each VF, it need refine to 4
+* queues here due to this limitation, otherwise no queue
+* will receive any packet even RSS is enabled.
+*/
+   if (eth_dev->data->dev_conf.rxmode.mq_mode == ETH_MQ_RX_VMDQ_RSS) {
+   if (RTE_ETH_DEV_SRIOV(eth_dev).nb_q_per_pool == 8) {
+   RTE_ETH_DEV_SRIOV(eth_dev).active = ETH_32_POOLS;
+   RTE_ETH_DEV_SRIOV(eth_dev).nb_q_per_pool = 4;
+   RTE_ETH_DEV_SRIOV(eth_dev).def_pool_q_idx =
+   dev_num_vf(eth_dev) * 4;
+   }
+   }
+
/* set VMDq map to default PF pool */
hw->mac.ops.set_vmdq(hw, 0, RTE_ETH_DEV_SRIOV(eth_dev).def_vmdq_idx);

diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c 
b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
index f69abda..a7c17a4 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
+++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
@@ -3327,6 +3327,39 @@ ixgbe_alloc_rx_queue_mbufs(struct igb_rx_queue *rxq)
 }

 static int
+ixgbe_config_vf_rss(struct rte_eth_dev *dev)
+{
+   struct ixgbe_hw *hw;
+   uint32_t mrqc;
+
+   ixgbe_rss_configure(dev);
+
+   hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+   /* MRQC: enable VF RSS */
+   mrqc = IXGBE_READ_REG(hw, IXGBE_MRQC);
+   mrqc &= ~IXGBE_MRQC_MRQE_MASK;
+   switch (RTE_ETH_DEV_SRIOV(dev).active) {
+   case ETH_64_POOLS:
+   mrqc |= IXGBE_MRQC_VMDQRSS64EN;
+   break;
+
+   case ETH_32_POOLS:
+   case ETH_16_POOLS:
+   mrqc |= IXGBE_MRQC_VMDQRSS32EN;
+   break;
+
+   default:
+   PMD_INIT_LOG(ERR, "Invalid pool number in IOV mode");
+   return -EINVAL;
+   }
+
+   IXGBE_WRITE_REG(hw, IXGBE_MRQC, mrqc);
+
+   return 0;
+}
+
+static int
 ixgbe_dev_mq_rx_configure(struct rte_eth_dev *dev)
 {
struct ixgbe_hw *hw =
@@ -3358,24 +3391,38 @@ ixgbe_dev_mq_rx_configure(struct rte_eth_dev *dev)
default: ixgbe_rss_disable(dev);
}
} else {
-   switch (RTE_ETH_DEV_SRIOV(dev).active) {
/*
 * SRIOV active scheme
 * FIXME if support DCB/RSS together with VMDq & SRIOV
 */
-   case ETH_64_POOLS:
-   IXGBE_WRITE_REG(hw, IXGBE_MRQC, IXGBE_MRQC_VMDQEN);
+   switch (dev->data->dev_conf.rxmode.mq_mode) {
+   case ETH_MQ_RX_RSS:
+   case ETH_MQ_RX_VMDQ_RSS:
+   ixgbe_config_vf_rss(dev);
break;

-   case ETH_32_POOLS:
-   IXGBE_WRITE_REG(hw, IXGBE_MRQC, IXGBE_MRQC_VMDQRT4TCEN);
-   break;
+   default:
+   switch (RTE_ETH_DEV_SRIOV(dev).active) {
+   case ETH_64_POOLS:
+   IXGBE_WRITE_REG(hw, IXGBE_MRQC,
+   IXGBE_MRQC_VMDQEN);
+   break;

-   case ETH_16_POOLS:
-   IXGBE_WRITE_REG(hw, IXGBE_MRQC, IXGBE_MRQC_VMDQRT8TCEN);
+   case ETH_32_POOLS:
+   IXGBE_WRITE_REG(hw, IXGBE_MRQC,
+   IXGBE_MRQC_VMDQRT4TCEN);
+   break;
+
+   case ETH_16_POOLS:
+   IXGBE_WRITE_REG(hw, IXGBE_MRQC,
+   IXGBE_MRQC_VMDQRT8TCEN);
+   break;
+   default:
+   PMD_INIT_LOG(ERR,
+   "invalid pool number in IOV mode");
+   break;
+   }
break;
-   default:
-   PMD_INIT_LOG(ERR, 

[dpdk-dev] [PATCH v3 3/6] ixgbe: Get VF queue number

[Ouyang Changchun]

Get the available Rx and Tx queue number when receiving IXGBE_VF_GET_QUEUES 
message from VF.

Signed-off-by: Changchun Ouyang 
---
 lib/librte_pmd_ixgbe/ixgbe_pf.c | 35 ++-
 1 file changed, 34 insertions(+), 1 deletion(-)

diff --git a/lib/librte_pmd_ixgbe/ixgbe_pf.c b/lib/librte_pmd_ixgbe/ixgbe_pf.c
index 495aff5..cbb0145 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_pf.c
+++ b/lib/librte_pmd_ixgbe/ixgbe_pf.c
@@ -53,6 +53,8 @@
 #include "ixgbe_ethdev.h"

 #define IXGBE_MAX_VFTA (128)
+#define IXGBE_VF_MSG_SIZE_DEFAULT 1
+#define IXGBE_VF_GET_QUEUE_MSG_SIZE 5

 static inline uint16_t
 dev_num_vf(struct rte_eth_dev *eth_dev)
@@ -491,9 +493,36 @@ ixgbe_negotiate_vf_api(struct rte_eth_dev *dev, uint32_t 
vf, uint32_t *msgbuf)
 }

 static int
+ixgbe_get_vf_queues(struct rte_eth_dev *dev, uint32_t vf, uint32_t *msgbuf)
+{
+   struct ixgbe_vf_info *vfinfo =
+   *IXGBE_DEV_PRIVATE_TO_P_VFDATA(dev->data->dev_private);
+   uint32_t default_q = vf * RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool;
+
+   /* Verify if the PF supports the mbox APIs version or not */
+   switch (vfinfo[vf].api_version) {
+   case ixgbe_mbox_api_20:
+   case ixgbe_mbox_api_11:
+   break;
+   default:
+   return -1;
+   }
+
+   /* Notify VF of Rx and Tx queue number */
+   msgbuf[IXGBE_VF_RX_QUEUES] = RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool;
+   msgbuf[IXGBE_VF_TX_QUEUES] = RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool;
+
+   /* Notify VF of default queue */
+   msgbuf[IXGBE_VF_DEF_QUEUE] = default_q;
+
+   return 0;
+}
+
+static int
 ixgbe_rcv_msg_from_vf(struct rte_eth_dev *dev, uint16_t vf)
 {
uint16_t mbx_size = IXGBE_VFMAILBOX_SIZE;
+   uint16_t msg_size = IXGBE_VF_MSG_SIZE_DEFAULT;
uint32_t msgbuf[IXGBE_VFMAILBOX_SIZE];
int32_t retval;
struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
@@ -537,6 +566,10 @@ ixgbe_rcv_msg_from_vf(struct rte_eth_dev *dev, uint16_t vf)
case IXGBE_VF_API_NEGOTIATE:
retval = ixgbe_negotiate_vf_api(dev, vf, msgbuf);
break;
+   case IXGBE_VF_GET_QUEUES:
+   retval = ixgbe_get_vf_queues(dev, vf, msgbuf);
+   msg_size = IXGBE_VF_GET_QUEUE_MSG_SIZE;
+   break;
default:
PMD_DRV_LOG(DEBUG, "Unhandled Msg %8.8x", (unsigned)msgbuf[0]);
retval = IXGBE_ERR_MBX;
@@ -551,7 +584,7 @@ ixgbe_rcv_msg_from_vf(struct rte_eth_dev *dev, uint16_t vf)

msgbuf[0] |= IXGBE_VT_MSGTYPE_CTS;

-   ixgbe_write_mbx(hw, msgbuf, 1, vf);
+   ixgbe_write_mbx(hw, msgbuf, msg_size, vf);

return retval;
 }
-- 
1.8.4.2

[dpdk-dev] [PATCH v3 1/6] ixgbe: Code cleanup

[Ouyang Changchun]

Put global register configuring out of loop for queue, where it should be there;
Also fix typo and indent.

Signed-off-by: Changchun Ouyang 
---
 lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 35 ++-
 1 file changed, 18 insertions(+), 17 deletions(-)

diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c 
b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
index 5c36bff..f69abda 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
+++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
@@ -3548,9 +3548,9 @@ ixgbe_dev_rx_init(struct rte_eth_dev *dev)
IXGBE_WRITE_REG(hw, 
IXGBE_PSRTYPE(rxq->reg_idx), psrtype);
}
srrctl = ((dev->data->dev_conf.rxmode.split_hdr_size <<
-  IXGBE_SRRCTL_BSIZEHDRSIZE_SHIFT) &
- IXGBE_SRRCTL_BSIZEHDR_MASK);
-   srrctl |= E1000_SRRCTL_DESCTYPE_HDR_SPLIT_ALWAYS;
+   IXGBE_SRRCTL_BSIZEHDRSIZE_SHIFT) &
+   IXGBE_SRRCTL_BSIZEHDR_MASK);
+   srrctl |= IXGBE_SRRCTL_DESCTYPE_HDR_SPLIT_ALWAYS;
} else
 #endif
srrctl = IXGBE_SRRCTL_DESCTYPE_ADV_ONEBUF;
@@ -3985,7 +3985,7 @@ ixgbevf_dev_rx_init(struct rte_eth_dev *dev)
struct igb_rx_queue *rxq;
struct rte_pktmbuf_pool_private *mbp_priv;
uint64_t bus_addr;
-   uint32_t srrctl;
+   uint32_t srrctl, psrtype = 0;
uint16_t buf_size;
uint16_t i;
int ret;
@@ -4039,20 +4039,10 @@ ixgbevf_dev_rx_init(struct rte_eth_dev *dev)
 * Configure Header Split
 */
if (dev->data->dev_conf.rxmode.header_split) {
-
-   /* Must setup the PSRTYPE register */
-   uint32_t psrtype;
-   psrtype = IXGBE_PSRTYPE_TCPHDR |
-   IXGBE_PSRTYPE_UDPHDR   |
-   IXGBE_PSRTYPE_IPV4HDR  |
-   IXGBE_PSRTYPE_IPV6HDR;
-
-   IXGBE_WRITE_REG(hw, IXGBE_VFPSRTYPE(i), psrtype);
-
srrctl = ((dev->data->dev_conf.rxmode.split_hdr_size <<
-  IXGBE_SRRCTL_BSIZEHDRSIZE_SHIFT) &
- IXGBE_SRRCTL_BSIZEHDR_MASK);
-   srrctl |= E1000_SRRCTL_DESCTYPE_HDR_SPLIT_ALWAYS;
+   IXGBE_SRRCTL_BSIZEHDRSIZE_SHIFT) &
+   IXGBE_SRRCTL_BSIZEHDR_MASK);
+   srrctl |= IXGBE_SRRCTL_DESCTYPE_HDR_SPLIT_ALWAYS;
} else
 #endif
srrctl = IXGBE_SRRCTL_DESCTYPE_ADV_ONEBUF;
@@ -4095,6 +4085,17 @@ ixgbevf_dev_rx_init(struct rte_eth_dev *dev)
}
}

+#ifdef RTE_HEADER_SPLIT_ENABLE
+   if (dev->data->dev_conf.rxmode.header_split)
+   /* Must setup the PSRTYPE register */
+   psrtype = IXGBE_PSRTYPE_TCPHDR |
+   IXGBE_PSRTYPE_UDPHDR   |
+   IXGBE_PSRTYPE_IPV4HDR  |
+   IXGBE_PSRTYPE_IPV6HDR;
+#endif
+
+   IXGBE_WRITE_REG(hw, IXGBE_VFPSRTYPE, psrtype);
+
if (dev->data->dev_conf.rxmode.enable_scatter) {
if (!dev->data->scattered_rx)
PMD_INIT_LOG(DEBUG, "forcing scatter mode");
-- 
1.8.4.2

[dpdk-dev] [PATCH v3 0/6] Enable VF RSS for Niantic

[Ouyang Changchun]

This patch enables VF RSS for Niantic, which allow each VF having at most 4 
queues.
The actual queue number per VF depends on the total number of pool, which is
determined by the total number of VF at PF initialization stage and the number 
of
queue specified in config:
1) If the number of VF is in the range from 1 to 32 and the number of rxq is 
4('--rxq 4' in testpmd),
then there is totally 32 pools(ETH_32_POOLS), and each VF have 4 queues;

2)If the number of VF is in the range from 33 to 64 and the number of rxq is 
2('--rxq 2' in testpmd),
then there is totally 64 pools(ETH_64_POOLS), and each VF have 2 queues;

On host, to enable VF RSS functionality, rx mq mode should be set as 
ETH_MQ_RX_VMDQ_RSS
or ETH_MQ_RX_RSS mode, and SRIOV mode should be activated(max_vfs >= 1).
It also needs config VF RSS information like hash function, RSS key, RSS key 
length.

The limitation for Niantic VF RSS is:
the hash and key are shared among PF and all VF, the RETA table with 128 
entries are
also shared among PF and all VF. So it is not good idea to query the hash and 
reta content per VF on
guest, instead, it makes sense to query them on host(PF).

v3 change:
  - More cleanup;

v2 change:
  - Update the description;
  - Use receiving queue number('--rxq ') specified in config to 
determine the number of pool and
the number of queue per VF;

v1 change:
  - Config VF RSS;

Changchun Ouyang (6):
  ixgbe: Code cleanup
  ixgbe: Negotiate VF API version
  ixgbe: Get VF queue number
  ether: Check VMDq RSS mode
  ixgbe: Config VF RSS
  testpmd: Set Rx VMDq RSS mode

 app/test-pmd/testpmd.c  |  10 +++
 lib/librte_ether/rte_ethdev.c   |  39 +--
 lib/librte_pmd_ixgbe/ixgbe_ethdev.h |   1 +
 lib/librte_pmd_ixgbe/ixgbe_pf.c |  75 -
 lib/librte_pmd_ixgbe/ixgbe_rxtx.c   | 127 
 5 files changed, 219 insertions(+), 33 deletions(-)

-- 
1.8.4.2

[dpdk-dev] [PATCH v3 5/6] ixgbe: Config VF RSS

[Vlad Zolotarov]

On 12/24/14 07:23, Ouyang Changchun wrote:
> It needs config RSS and IXGBE_MRQC and IXGBE_VFPSRTYPE to enable VF RSS.
>
> The psrtype will determine how many queues the received packets will 
> distribute to,
> and the value of psrtype should depends on both facet: max VF rxq number which
> has been negotiated with PF, and the number of rxq specified in config on 
> guest.
>
> Signed-off-by: Changchun Ouyang 
> ---
>   lib/librte_pmd_ixgbe/ixgbe_pf.c   | 15 +++
>   lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 92 
> ++-
>   2 files changed, 97 insertions(+), 10 deletions(-)
>
> diff --git a/lib/librte_pmd_ixgbe/ixgbe_pf.c b/lib/librte_pmd_ixgbe/ixgbe_pf.c
> index cbb0145..9c9dad8 100644
> --- a/lib/librte_pmd_ixgbe/ixgbe_pf.c
> +++ b/lib/librte_pmd_ixgbe/ixgbe_pf.c
> @@ -187,6 +187,21 @@ int ixgbe_pf_host_configure(struct rte_eth_dev *eth_dev)
>   IXGBE_WRITE_REG(hw, IXGBE_MPSAR_LO(hw->mac.num_rar_entries), 0);
>   IXGBE_WRITE_REG(hw, IXGBE_MPSAR_HI(hw->mac.num_rar_entries), 0);
>   
> + /*
> +  * VF RSS can support at most 4 queues for each VF, even if
> +  * 8 queues are available for each VF, it need refine to 4
> +  * queues here due to this limitation, otherwise no queue
> +  * will receive any packet even RSS is enabled.

According to Table 7-3 in the 82599 spec RSS is not available when port 
is configured to have 8 queues per pool. This means that if u see this 
configuration u may immediately disable RSS flow in your code.

> +  */
> + if (eth_dev->data->dev_conf.rxmode.mq_mode == ETH_MQ_RX_VMDQ_RSS) {
> + if (RTE_ETH_DEV_SRIOV(eth_dev).nb_q_per_pool == 8) {
> + RTE_ETH_DEV_SRIOV(eth_dev).active = ETH_32_POOLS;
> + RTE_ETH_DEV_SRIOV(eth_dev).nb_q_per_pool = 4;
> + RTE_ETH_DEV_SRIOV(eth_dev).def_pool_q_idx =
> + dev_num_vf(eth_dev) * 4;

According to 82599 spec u can't do that since RSS is not allowed when 
port is configured to have 8 function per-VF. Have u verified that this 
works? If yes, then spec should be updated.

> + }
> + }
> +
>   /* set VMDq map to default PF pool */
>   hw->mac.ops.set_vmdq(hw, 0, RTE_ETH_DEV_SRIOV(eth_dev).def_vmdq_idx);
>   
> diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c 
> b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> index f69abda..a7c17a4 100644
> --- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> +++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> @@ -3327,6 +3327,39 @@ ixgbe_alloc_rx_queue_mbufs(struct igb_rx_queue *rxq)
>   }
>   
>   static int
> +ixgbe_config_vf_rss(struct rte_eth_dev *dev)
> +{
> + struct ixgbe_hw *hw;
> + uint32_t mrqc;
> +
> + ixgbe_rss_configure(dev);
> +
> + hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> +
> + /* MRQC: enable VF RSS */
> + mrqc = IXGBE_READ_REG(hw, IXGBE_MRQC);
> + mrqc &= ~IXGBE_MRQC_MRQE_MASK;
> + switch (RTE_ETH_DEV_SRIOV(dev).active) {
> + case ETH_64_POOLS:
> + mrqc |= IXGBE_MRQC_VMDQRSS64EN;
> + break;
> +
> + case ETH_32_POOLS:
> + case ETH_16_POOLS:
> + mrqc |= IXGBE_MRQC_VMDQRSS32EN;

Again, this contradicts with the spec.

> + break;
> +
> + default:
> + PMD_INIT_LOG(ERR, "Invalid pool number in IOV mode");
> + return -EINVAL;
> + }
> +
> + IXGBE_WRITE_REG(hw, IXGBE_MRQC, mrqc);
> +
> + return 0;
> +}
> +
> +static int
>   ixgbe_dev_mq_rx_configure(struct rte_eth_dev *dev)
>   {
>   struct ixgbe_hw *hw =
> @@ -3358,24 +3391,38 @@ ixgbe_dev_mq_rx_configure(struct rte_eth_dev *dev)
>   default: ixgbe_rss_disable(dev);
>   }
>   } else {
> - switch (RTE_ETH_DEV_SRIOV(dev).active) {
>   /*
>* SRIOV active scheme
>* FIXME if support DCB/RSS together with VMDq & SRIOV
>*/
> - case ETH_64_POOLS:
> - IXGBE_WRITE_REG(hw, IXGBE_MRQC, IXGBE_MRQC_VMDQEN);
> + switch (dev->data->dev_conf.rxmode.mq_mode) {
> + case ETH_MQ_RX_RSS:
> + case ETH_MQ_RX_VMDQ_RSS:
> + ixgbe_config_vf_rss(dev);
>   break;
>   
> - case ETH_32_POOLS:
> - IXGBE_WRITE_REG(hw, IXGBE_MRQC, IXGBE_MRQC_VMDQRT4TCEN);
> - break;
> + default:
> + switch (RTE_ETH_DEV_SRIOV(dev).active) {

Sorry for nitpicking but have u considered taking this encapsulated 
"switch-case" block into a separate function? This could make the code 
look a lot nicer. ;)

> + case ETH_64_POOLS:
> + IXGBE_WRITE_REG(hw, IXGBE_MRQC,
> + IXGBE_MRQC_VMDQEN);
> + break;
>   
> - case ETH_16_POOLS:
> - IXGBE_WRITE_REG(hw, IXGBE_MRQC, 

[dpdk-dev] [PATCH v3 0/6] Enable VF RSS for Niantic

[Vlad Zolotarov]

On 12/24/14 07:22, Ouyang Changchun wrote:
> This patch enables VF RSS for Niantic, which allow each VF having at most 4 
> queues.
> The actual queue number per VF depends on the total number of pool, which is
> determined by the total number of VF at PF initialization stage and the 
> number of
> queue specified in config:
> 1) If the number of VF is in the range from 1 to 32 and the number of rxq is 
> 4('--rxq 4' in testpmd),
> then there is totally 32 pools(ETH_32_POOLS), and each VF have 4 queues;
>   
> 2)If the number of VF is in the range from 33 to 64 and the number of rxq is 
> 2('--rxq 2' in testpmd),
> then there is totally 64 pools(ETH_64_POOLS), and each VF have 2 queues;
>   
> On host, to enable VF RSS functionality, rx mq mode should be set as 
> ETH_MQ_RX_VMDQ_RSS
> or ETH_MQ_RX_RSS mode, and SRIOV mode should be activated(max_vfs >= 1).
> It also needs config VF RSS information like hash function, RSS key, RSS key 
> length.
>   
> The limitation for Niantic VF RSS is:
> the hash and key are shared among PF and all VF

Hmmm... This kinda contradicts the previous sentence where u say that VF 
on the host should configure hash and RSS key. If PF and VF share the 
same hash and key what's the use of configuring it in VF? Could u 
clarify, please?

> , the RETA table with 128 entries are
> also shared among PF and all VF. So it is not good idea to query the hash and 
> reta content per VF on
> guest, instead, it makes sense to query them on host(PF).

On the contrary - it's a very good idea! We use DPDK on Amazon's guests 
with enhanced networking and we have no access to the PF. We still need 
to know the RSS redirection rules for our VF pool. From the 82599 spec, 
chapter 4.6.10.1.1: "redirection table is common to all the pools and 
only indicates the queue inside the
pool to use once the pool is chosen". In that case we need to get the 
whole 128 entries of the RETA. Is there a reason why we can't have it?

>   
> v3 change:
>- More cleanup;
>
> v2 change:
>- Update the description;
>- Use receiving queue number('--rxq ') specified in config to 
> determine the number of pool and
>  the number of queue per VF;
>   
> v1 change:
>- Config VF RSS;
>
> Changchun Ouyang (6):
>ixgbe: Code cleanup
>ixgbe: Negotiate VF API version
>ixgbe: Get VF queue number
>ether: Check VMDq RSS mode
>ixgbe: Config VF RSS
>testpmd: Set Rx VMDq RSS mode
>
>   app/test-pmd/testpmd.c  |  10 +++
>   lib/librte_ether/rte_ethdev.c   |  39 +--
>   lib/librte_pmd_ixgbe/ixgbe_ethdev.h |   1 +
>   lib/librte_pmd_ixgbe/ixgbe_pf.c |  75 -
>   lib/librte_pmd_ixgbe/ixgbe_rxtx.c   | 127 
> 
>   5 files changed, 219 insertions(+), 33 deletions(-)
>

[dpdk-dev] [PATCH v2 6/6] testpmd: Set Rx VMDq RSS mode

[Ouyang Changchun]

Set VMDq RSS mode if it has VF(VF number is more than 1) and has RSS 
information.

Signed-off-by: Changchun Ouyang 
---
 app/test-pmd/testpmd.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 8c69756..6230f8b 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -1708,6 +1708,16 @@ init_port_config(void)
port->dev_conf.rxmode.mq_mode = ETH_MQ_RX_NONE;
}

+   if (port->dev_info.max_vfs != 0) {
+   if (port->dev_conf.rx_adv_conf.rss_conf.rss_hf != 0)
+   port->dev_conf.rxmode.mq_mode =
+   ETH_MQ_RX_VMDQ_RSS;
+   else {
+   port->dev_conf.rxmode.mq_mode = ETH_MQ_RX_NONE;
+   port->dev_conf.txmode.mq_mode = ETH_MQ_TX_NONE;
+   }
+   }
+
port->rx_conf.rx_thresh = rx_thresh;
port->rx_conf.rx_free_thresh = rx_free_thresh;
port->rx_conf.rx_drop_en = rx_drop_en;
-- 
1.8.4.2

[dpdk-dev] [PATCH v2 5/6] ixgbe: Config VF RSS

[Ouyang Changchun]

It needs config RSS and IXGBE_MRQC and IXGBE_VFPSRTYPE to enable VF RSS.

The psrtype will determine how many queues the received packets will distribute 
to,
and the value of psrtype should depends on both facets: max VF rxq number which
has been negotiated with PF, and the number of rxq specified in config on guest.

Signed-off-by: Changchun Ouyang 
---
 lib/librte_pmd_ixgbe/ixgbe_pf.c   | 15 +++
 lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 92 ++-
 2 files changed, 97 insertions(+), 10 deletions(-)

diff --git a/lib/librte_pmd_ixgbe/ixgbe_pf.c b/lib/librte_pmd_ixgbe/ixgbe_pf.c
index cbb0145..9c9dad8 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_pf.c
+++ b/lib/librte_pmd_ixgbe/ixgbe_pf.c
@@ -187,6 +187,21 @@ int ixgbe_pf_host_configure(struct rte_eth_dev *eth_dev)
IXGBE_WRITE_REG(hw, IXGBE_MPSAR_LO(hw->mac.num_rar_entries), 0);
IXGBE_WRITE_REG(hw, IXGBE_MPSAR_HI(hw->mac.num_rar_entries), 0);

+   /*
+* VF RSS can support at most 4 queues for each VF, even if
+* 8 queues are available for each VF, it need refine to 4
+* queues here due to this limitation, otherwise no queue
+* will receive any packet even RSS is enabled.
+*/
+   if (eth_dev->data->dev_conf.rxmode.mq_mode == ETH_MQ_RX_VMDQ_RSS) {
+   if (RTE_ETH_DEV_SRIOV(eth_dev).nb_q_per_pool == 8) {
+   RTE_ETH_DEV_SRIOV(eth_dev).active = ETH_32_POOLS;
+   RTE_ETH_DEV_SRIOV(eth_dev).nb_q_per_pool = 4;
+   RTE_ETH_DEV_SRIOV(eth_dev).def_pool_q_idx =
+   dev_num_vf(eth_dev) * 4;
+   }
+   }
+
/* set VMDq map to default PF pool */
hw->mac.ops.set_vmdq(hw, 0, RTE_ETH_DEV_SRIOV(eth_dev).def_vmdq_idx);

diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c 
b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
index f58f98e..5a3f528 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
+++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
@@ -3327,6 +3327,39 @@ ixgbe_alloc_rx_queue_mbufs(struct igb_rx_queue *rxq)
 }

 static int
+ixgbe_config_vf_rss(struct rte_eth_dev *dev)
+{
+   struct ixgbe_hw *hw;
+   uint32_t mrqc;
+
+   ixgbe_rss_configure(dev);
+
+   hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+   /* MRQC: enable VF RSS */
+   mrqc = IXGBE_READ_REG(hw, IXGBE_MRQC);
+   mrqc &= ~IXGBE_MRQC_MRQE_MASK;
+   switch (RTE_ETH_DEV_SRIOV(dev).active) {
+   case ETH_64_POOLS:
+   mrqc |= IXGBE_MRQC_VMDQRSS64EN;
+   break;
+
+   case ETH_32_POOLS:
+   case ETH_16_POOLS:
+   mrqc |= IXGBE_MRQC_VMDQRSS32EN;
+   break;
+
+   default:
+   PMD_INIT_LOG(ERR, "Invalid pool number in IOV mode");
+   return -EINVAL;
+   }
+
+   IXGBE_WRITE_REG(hw, IXGBE_MRQC, mrqc);
+
+   return 0;
+}
+
+static int
 ixgbe_dev_mq_rx_configure(struct rte_eth_dev *dev)
 {
struct ixgbe_hw *hw =
@@ -3358,24 +3391,38 @@ ixgbe_dev_mq_rx_configure(struct rte_eth_dev *dev)
default: ixgbe_rss_disable(dev);
}
} else {
-   switch (RTE_ETH_DEV_SRIOV(dev).active) {
/*
 * SRIOV active scheme
 * FIXME if support DCB/RSS together with VMDq & SRIOV
 */
-   case ETH_64_POOLS:
-   IXGBE_WRITE_REG(hw, IXGBE_MRQC, IXGBE_MRQC_VMDQEN);
+   switch (dev->data->dev_conf.rxmode.mq_mode) {
+   case ETH_MQ_RX_RSS:
+   case ETH_MQ_RX_VMDQ_RSS:
+   ixgbe_config_vf_rss(dev);
break;

-   case ETH_32_POOLS:
-   IXGBE_WRITE_REG(hw, IXGBE_MRQC, IXGBE_MRQC_VMDQRT4TCEN);
-   break;
+   default:
+   switch (RTE_ETH_DEV_SRIOV(dev).active) {
+   case ETH_64_POOLS:
+   IXGBE_WRITE_REG(hw, IXGBE_MRQC,
+   IXGBE_MRQC_VMDQEN);
+   break;

-   case ETH_16_POOLS:
-   IXGBE_WRITE_REG(hw, IXGBE_MRQC, IXGBE_MRQC_VMDQRT8TCEN);
+   case ETH_32_POOLS:
+   IXGBE_WRITE_REG(hw, IXGBE_MRQC,
+   IXGBE_MRQC_VMDQRT4TCEN);
+   break;
+
+   case ETH_16_POOLS:
+   IXGBE_WRITE_REG(hw, IXGBE_MRQC,
+   IXGBE_MRQC_VMDQRT8TCEN);
+   break;
+   default:
+   PMD_INIT_LOG(ERR,
+   "invalid pool number in IOV mode");
+   break;
+   }
break;
-   default:
-   PMD_INIT_LOG(ERR, 

[dpdk-dev] [PATCH v2 4/6] ether: Check VMDq RSS mode

[Ouyang Changchun]

Check multiple queues mode for VMDq RSS, handle it correctly instead of 
returning an error;
Also remove the limitation of per pool queue number has max value of 1, because
the per pool queue number could be 2 or 4 if it is VMDq RSS mode;

The number of rxq specified in config will determine the multiple queues mode 
for VMDq RSS.

Signed-off-by: Changchun Ouyang 
---
 lib/librte_ether/rte_ethdev.c | 39 ++-
 1 file changed, 34 insertions(+), 5 deletions(-)

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 95f2ceb..59ff325 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -510,8 +510,7 @@ rte_eth_dev_check_mq_mode(uint8_t port_id, uint16_t 
nb_rx_q, uint16_t nb_tx_q,

if (RTE_ETH_DEV_SRIOV(dev).active != 0) {
/* check multi-queue mode */
-   if ((dev_conf->rxmode.mq_mode == ETH_MQ_RX_RSS) ||
-   (dev_conf->rxmode.mq_mode == ETH_MQ_RX_DCB) ||
+   if ((dev_conf->rxmode.mq_mode == ETH_MQ_RX_DCB) ||
(dev_conf->rxmode.mq_mode == ETH_MQ_RX_DCB_RSS) ||
(dev_conf->txmode.mq_mode == ETH_MQ_TX_DCB)) {
/* SRIOV only works in VMDq enable mode */
@@ -525,7 +524,6 @@ rte_eth_dev_check_mq_mode(uint8_t port_id, uint16_t 
nb_rx_q, uint16_t nb_tx_q,
}

switch (dev_conf->rxmode.mq_mode) {
-   case ETH_MQ_RX_VMDQ_RSS:
case ETH_MQ_RX_VMDQ_DCB:
case ETH_MQ_RX_VMDQ_DCB_RSS:
/* DCB/RSS VMDQ in SRIOV mode, not implement yet */
@@ -534,6 +532,39 @@ rte_eth_dev_check_mq_mode(uint8_t port_id, uint16_t 
nb_rx_q, uint16_t nb_tx_q,
"unsupported VMDQ mq_mode rx %u\n",
port_id, dev_conf->rxmode.mq_mode);
return (-EINVAL);
+   case ETH_MQ_RX_RSS:
+   PMD_DEBUG_TRACE("ethdev port_id=%" PRIu8
+   " SRIOV active, "
+   "Rx mq mode is changed from:"
+   "mq_mode %u into VMDQ mq_mode %u\n",
+   port_id,
+   dev_conf->rxmode.mq_mode,
+   dev->data->dev_conf.rxmode.mq_mode);
+   case ETH_MQ_RX_VMDQ_RSS:
+   dev->data->dev_conf.rxmode.mq_mode = ETH_MQ_RX_VMDQ_RSS;
+   if (nb_rx_q < RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool) {
+   switch (nb_rx_q) {
+   case 1:
+   case 2:
+   RTE_ETH_DEV_SRIOV(dev).active =
+   ETH_64_POOLS;
+   break;
+   case 4:
+   RTE_ETH_DEV_SRIOV(dev).active =
+   ETH_32_POOLS;
+   break;
+   default:
+   PMD_DEBUG_TRACE("ethdev port_id=%d"
+   " SRIOV active, "
+   "queue number invalid\n",
+   port_id);
+   return -EINVAL;
+   }
+   RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool = nb_rx_q;
+   RTE_ETH_DEV_SRIOV(dev).def_pool_q_idx =
+   dev->pci_dev->max_vfs * nb_rx_q;
+   }
+   break;
default: /* ETH_MQ_RX_VMDQ_ONLY or ETH_MQ_RX_NONE */
/* if nothing mq mode configure, use default scheme */
dev->data->dev_conf.rxmode.mq_mode = 
ETH_MQ_RX_VMDQ_ONLY;
@@ -553,8 +584,6 @@ rte_eth_dev_check_mq_mode(uint8_t port_id, uint16_t 
nb_rx_q, uint16_t nb_tx_q,
default: /* ETH_MQ_TX_VMDQ_ONLY or ETH_MQ_TX_NONE */
/* if nothing mq mode configure, use default scheme */
dev->data->dev_conf.txmode.mq_mode = 
ETH_MQ_TX_VMDQ_ONLY;
-   if (RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool > 1)
-   RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool = 1;
break;
}

-- 
1.8.4.2

[dpdk-dev] [PATCH v2 3/6] ixgbe: Get VF queue number

[Ouyang Changchun]

Get the available Rx and Tx queue number when receiving IXGBE_VF_GET_QUEUES 
message from VF.

Signed-off-by: Changchun Ouyang 
---
 lib/librte_pmd_ixgbe/ixgbe_pf.c | 35 ++-
 1 file changed, 34 insertions(+), 1 deletion(-)

diff --git a/lib/librte_pmd_ixgbe/ixgbe_pf.c b/lib/librte_pmd_ixgbe/ixgbe_pf.c
index 495aff5..cbb0145 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_pf.c
+++ b/lib/librte_pmd_ixgbe/ixgbe_pf.c
@@ -53,6 +53,8 @@
 #include "ixgbe_ethdev.h"

 #define IXGBE_MAX_VFTA (128)
+#define IXGBE_VF_MSG_SIZE_DEFAULT 1
+#define IXGBE_VF_GET_QUEUE_MSG_SIZE 5

 static inline uint16_t
 dev_num_vf(struct rte_eth_dev *eth_dev)
@@ -491,9 +493,36 @@ ixgbe_negotiate_vf_api(struct rte_eth_dev *dev, uint32_t 
vf, uint32_t *msgbuf)
 }

 static int
+ixgbe_get_vf_queues(struct rte_eth_dev *dev, uint32_t vf, uint32_t *msgbuf)
+{
+   struct ixgbe_vf_info *vfinfo =
+   *IXGBE_DEV_PRIVATE_TO_P_VFDATA(dev->data->dev_private);
+   uint32_t default_q = vf * RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool;
+
+   /* Verify if the PF supports the mbox APIs version or not */
+   switch (vfinfo[vf].api_version) {
+   case ixgbe_mbox_api_20:
+   case ixgbe_mbox_api_11:
+   break;
+   default:
+   return -1;
+   }
+
+   /* Notify VF of Rx and Tx queue number */
+   msgbuf[IXGBE_VF_RX_QUEUES] = RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool;
+   msgbuf[IXGBE_VF_TX_QUEUES] = RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool;
+
+   /* Notify VF of default queue */
+   msgbuf[IXGBE_VF_DEF_QUEUE] = default_q;
+
+   return 0;
+}
+
+static int
 ixgbe_rcv_msg_from_vf(struct rte_eth_dev *dev, uint16_t vf)
 {
uint16_t mbx_size = IXGBE_VFMAILBOX_SIZE;
+   uint16_t msg_size = IXGBE_VF_MSG_SIZE_DEFAULT;
uint32_t msgbuf[IXGBE_VFMAILBOX_SIZE];
int32_t retval;
struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
@@ -537,6 +566,10 @@ ixgbe_rcv_msg_from_vf(struct rte_eth_dev *dev, uint16_t vf)
case IXGBE_VF_API_NEGOTIATE:
retval = ixgbe_negotiate_vf_api(dev, vf, msgbuf);
break;
+   case IXGBE_VF_GET_QUEUES:
+   retval = ixgbe_get_vf_queues(dev, vf, msgbuf);
+   msg_size = IXGBE_VF_GET_QUEUE_MSG_SIZE;
+   break;
default:
PMD_DRV_LOG(DEBUG, "Unhandled Msg %8.8x", (unsigned)msgbuf[0]);
retval = IXGBE_ERR_MBX;
@@ -551,7 +584,7 @@ ixgbe_rcv_msg_from_vf(struct rte_eth_dev *dev, uint16_t vf)

msgbuf[0] |= IXGBE_VT_MSGTYPE_CTS;

-   ixgbe_write_mbx(hw, msgbuf, 1, vf);
+   ixgbe_write_mbx(hw, msgbuf, msg_size, vf);

return retval;
 }
-- 
1.8.4.2

[dpdk-dev] [PATCH v2 2/6] ixgbe: Negotiate VF API version

[Ouyang Changchun]

Negotiate API version with VF when receiving the IXGBE_VF_API_NEGOTIATE message.

Signed-off-by: Changchun Ouyang 
---
 lib/librte_pmd_ixgbe/ixgbe_ethdev.h |  1 +
 lib/librte_pmd_ixgbe/ixgbe_pf.c | 25 +
 2 files changed, 26 insertions(+)

diff --git a/lib/librte_pmd_ixgbe/ixgbe_ethdev.h 
b/lib/librte_pmd_ixgbe/ixgbe_ethdev.h
index ca99170..730098d 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_ethdev.h
+++ b/lib/librte_pmd_ixgbe/ixgbe_ethdev.h
@@ -159,6 +159,7 @@ struct ixgbe_vf_info {
uint16_t tx_rate[IXGBE_MAX_QUEUE_NUM_PER_VF];
uint16_t vlan_count;
uint8_t spoofchk_enabled;
+   uint8_t api_version;
 };

 /*
diff --git a/lib/librte_pmd_ixgbe/ixgbe_pf.c b/lib/librte_pmd_ixgbe/ixgbe_pf.c
index 51da1fd..495aff5 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_pf.c
+++ b/lib/librte_pmd_ixgbe/ixgbe_pf.c
@@ -469,6 +469,28 @@ ixgbe_set_vf_lpe(struct rte_eth_dev *dev, __rte_unused 
uint32_t vf, uint32_t *ms
 }

 static int
+ixgbe_negotiate_vf_api(struct rte_eth_dev *dev, uint32_t vf, uint32_t *msgbuf)
+{
+   uint32_t api_version = msgbuf[1];
+   struct ixgbe_vf_info *vfinfo =
+   *IXGBE_DEV_PRIVATE_TO_P_VFDATA(dev->data->dev_private);
+
+   switch (api_version) {
+   case ixgbe_mbox_api_10:
+   case ixgbe_mbox_api_11:
+   vfinfo[vf].api_version = (uint8_t)api_version;
+   return 0;
+   default:
+   break;
+   }
+
+   RTE_LOG(ERR, PMD, "Negotiate invalid api version %u from VF %d\n",
+   api_version, vf);
+
+   return -1;
+}
+
+static int
 ixgbe_rcv_msg_from_vf(struct rte_eth_dev *dev, uint16_t vf)
 {
uint16_t mbx_size = IXGBE_VFMAILBOX_SIZE;
@@ -512,6 +534,9 @@ ixgbe_rcv_msg_from_vf(struct rte_eth_dev *dev, uint16_t vf)
case IXGBE_VF_SET_VLAN:
retval = ixgbe_vf_set_vlan(dev, vf, msgbuf);
break;
+   case IXGBE_VF_API_NEGOTIATE:
+   retval = ixgbe_negotiate_vf_api(dev, vf, msgbuf);
+   break;
default:
PMD_DRV_LOG(DEBUG, "Unhandled Msg %8.8x", (unsigned)msgbuf[0]);
retval = IXGBE_ERR_MBX;
-- 
1.8.4.2

[dpdk-dev] [PATCH v2 0/6] Enable VF RSS for Niantic

[Ouyang Changchun]

This patch enables VF RSS for Niantic, which allow each VF having at most 4 
queues.
The actual queue number per VF depends on the total number of pool, which is
determined by the total number of VF at PF initialization stage and the number 
of
queue specified in config:
1) If the number of VF is in the range from 1 to 32 and the number of rxq is 
4('--rxq 4' in testpmd),
then there is totally 32 pools(ETH_32_POOLS), and each VF have 4 queues;

2)If the number of VF is in the range from 33 to 64 and the number of rxq is 
2('--rxq 2' in testpmd),
then there is totally 64 pools(ETH_64_POOLS), and each VF have 2 queues;

On host, to enable VF RSS functionality, rx mq mode should be set as 
ETH_MQ_RX_VMDQ_RSS
or ETH_MQ_RX_RSS mode, and SRIOV mode should be activated(max_vfs >= 1).
It also needs config VF RSS information like hash function, RSS key, RSS key 
length.

The limitation for Niantic VF RSS is:
the hash and key are shared among PF and all VF, the RETA table with 128 
entries are
also shared among PF and all VF. So it is not good idea to query the hash and 
reta content per VF on
guest, instead, it makes sense to query them on host(PF).

v2 change:
  - Update the description;
  - Use receiving queue number('--rxq ') specified in config to 
determine the number of pool and
the number of queue per VF;

v1 change:
  - Config VF RSS;

Changchun Ouyang (6):
  ixgbe: Code cleanup
  ixgbe: Negotiate VF API version
  ixgbe: Get VF queue number
  ether: Check VMDq RSS mode
  ixgbe: Config VF RSS
  testpmd: Set Rx VMDq RSS mode

 app/test-pmd/testpmd.c  |  10 +++
 lib/librte_ether/rte_ethdev.c   |  39 ++--
 lib/librte_pmd_ixgbe/ixgbe_ethdev.h |   1 +
 lib/librte_pmd_ixgbe/ixgbe_pf.c |  75 +-
 lib/librte_pmd_ixgbe/ixgbe_rxtx.c   | 121 +---
 5 files changed, 216 insertions(+), 30 deletions(-)

-- 
1.8.4.2

[dpdk-dev] No probed ethernet devices /DPDP 1.7.1 in Fedora 21

[Neil Horman]

On Wed, Dec 24, 2014 at 02:26:21PM +0100, sothy shan wrote:
> Hello!
> 
> I am playing with DPDK 1.7.1 in Fedora.
> 
> When I do like this:
> 
> export RTE_SDK=$(pwd)export RTE_TARGET="x86_64-ivshmem-linuxapp-gcc"
> make install T="$RTE_TARGET"
> 
> It worked. Means Testpmd is running.
> 
> When I run as mentioned below:
> 
> make CONFIG_RTE_BUILD_SHARED_LIB=y  install T="$RTE_TARGET"
> 
> Build is sucess. But Testpmd gives error.
> 
> Error is :
> 
The dpdk ivshmem build assumes the presence of ivshmem devices as plumbed by
qemu virtual guests.  If you don't have a qemu guest running dpdk won't find any
shared memory devices, which is exactly what you are seeing.  That said, even if
you are running qemu guests, IIRC Fedora doesn't enable ivshmem because the code
has some security and behavioral issues still I think.  You'll need to rebuild
qemu to add support for it.

Neil

[dpdk-dev] [PATCH 0/6] Enable VF RSS for Niantic

[Vlad Zolotarov]

On 12/24/14 08:37, Ouyang, Changchun wrote:
>
> Hi,
>
> I have v3 patch for this to resolve your comments,
>
> We can discuss on v3 patch if there are further comments.
>

I'm looking at your v3 patchset right now... ;)

> Thanks
>
> Changchun
>
> *From:*Vladislav Zolotarov [mailto:vladz at cloudius-systems.com]
> *Sent:* Sunday, December 21, 2014 4:02 PM
> *To:* Ouyang, Changchun
> *Cc:* dev at dpdk.org
> *Subject:* RE: [PATCH 0/6] Enable VF RSS for Niantic
>
>
> On Dec 19, 2014 3:35 AM, "Ouyang, Changchun" 
> mailto:changchun.ouyang at intel.com>> wrote:
> >
> > My response as below.
> >
> >
> >
> > From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com 
> ]
> > Sent: Thursday, December 18, 2014 9:06 PM
> > To: dev at dpdk.org ; Ouyang, Changchun
> > Subject: Re: [PATCH 0/6] Enable VF RSS for Niantic
> >
> >
> >
> >
> >
> > On 12/18/14 12:11, Vlad Zolotarov wrote:
> >>
> >> From: Changchun Ouyang  >
> >>
> >>
> >>
> >> This patch enables VF RSS for Niantic, which allow each VF having 
> at most 4 queues.
> >>
> >> The actual queue number per VF depends on the number of VF:
> >>
> >> VF number from 1~32: 4 queues per VF;
> >>
> >> VF number from 33~max vf num: 2 queues per VF;
> >>
> >>
> >>
> >> On host, to enable VF RSS functionality, mq mode should be set as 
> ETH_MQ_RX_VMDQ_RSS
> >>
> >> or ETH_MQ_RX_RSS mode, and SRIOV mode should be activated.
> >>
> >> It also needs config VF RSS information like hash function, RSS 
> key, RSS key length.
> >
> >
> > This patch series is missing a few things:
> >
> > Taking into the consideration the number of Rx queues requested by a 
> user in the rte_eth_dev_configure().
> >
> > Changchun: yes, will have a v2 to consider it, as I say in my 
> previous response.
>
> I must have joined the mailing list after your v2 series. I'll take a 
> look in the web for it.
>
> >
> > dev->dev_ops->reta_query used by a rte_eth_dev_rss_reta_query() is 
> still not initialized for a VF. Thus there is no way to query the RSS 
> table
> >
> > Changchun: do you mean query rss table on guest?
>
> Of course.
>
> Niantic doesn?t have separate reta for a specific vf, the reta is 
> shared by pf and all vf.
>
> AFAIK the reta is statically divided between all available functions.
>
> So, first of all we need a way to know that is the size of a single VF 
> partition in order to know how many RSS queues may be configured.
>
> Then we need an ability to query/set the contents of the corresponding 
> reta partition like we can for PF.
>
> >
> > Do you think of returning all reta contents for each vf make sense?  
> Or any other insight here?
> >
> > rte_eth_dev_info_get() returns reta_size == 0 when called for a VF 
> function.
> >
> > Changchun:  same as above.
> >
> > Your insight here are welcome here.
> >
> > thanks
> >
> > Changchun
> >
> >
>

[dpdk-dev] [PATCH] i40e: workaround for XL710 performance

[Neil Horman]

On Wed, Dec 24, 2014 at 03:14:08PM +0800, Helin Zhang wrote:
> on XL710, performance number is far from the expectation on recent
> firmware versions, if promiscuous mode is disabled, or promiscuous
> mode is enabled and port MAC address is equal to the packet
> destination MAC address. The fix for this issue may not be integrated
> in the following firmware version. So the workaround in software
> driver is needed. It needs to modify the initial values of 2 internal
> only registers which is the same 2 of 3 registers of it did for X710.
> Note that the workaround can be removed when it is fixed in firmware
> in the future.
> 
> Signed-off-by: Helin Zhang 
> ---
>  lib/librte_pmd_i40e/i40e_ethdev.c | 35 ++-
>  1 file changed, 22 insertions(+), 13 deletions(-)
> 
> diff --git a/lib/librte_pmd_i40e/i40e_ethdev.c 
> b/lib/librte_pmd_i40e/i40e_ethdev.c
> index b47a3d2..3bb75d8 100644
> --- a/lib/librte_pmd_i40e/i40e_ethdev.c
> +++ b/lib/librte_pmd_i40e/i40e_ethdev.c
> @@ -5327,21 +5327,30 @@ i40e_debug_read_register(struct i40e_hw *hw, uint32_t 
> addr, uint64_t *val)
>  
>  /*
>   * On X710, performance number is far from the expectation on recent firmware
> - * versions. The fix for this issue may not be integrated in the following
> + * versions; on XL710, performance number is also far from the expectation on
> + * recent firmware versions, if promiscuous mode is disabled, or promiscuous
> + * mode is enabled and port MAC address is equal to the packet destination 
> MAC
> + * address. The fix for this issue may not be integrated in the following
>   * firmware version. So the workaround in software driver is needed. It needs
> - * to modify the initial values of 3 internal only registers. Note that the
> - * workaround can be removed when it is fixed in firmware in the future.
> + * to modify the initial values of 3 internal only registers for X710, and 
> the
> + * same 2 internal registers for XL710. Note that the workaround can be 
> removed
> + * when it is fixed in firmware in the future.

Wouldn't it be preferable to add a firmware version check to this code so that a
single driver can handle both cards with old and 'fixed' firmware?  That way
nothing needs to be removed and all i40e cards will have a consistent behavior
Neil

>   */
> -static void
> -i40e_configure_registers(struct i40e_hw *hw)
> -{
> -#define I40E_GL_SWR_PRI_JOIN_MAP_0   0x26CE00
> -#define I40E_GL_SWR_PRI_JOIN_MAP_2   0x26CE08
> -#define I40E_GL_SWR_PM_UP_THR0x269FBC
> +
> +/* For both X710 and XL710 */
>  #define I40E_GL_SWR_PRI_JOIN_MAP_0_VALUE 0x1200
> +#define I40E_GL_SWR_PRI_JOIN_MAP_0   0x26CE00
> +
>  #define I40E_GL_SWR_PRI_JOIN_MAP_2_VALUE 0x011f0200
> +#define I40E_GL_SWR_PRI_JOIN_MAP_2   0x26CE08
> +
> +/* For X710 only */
>  #define I40E_GL_SWR_PM_UP_THR_VALUE  0x03030303
> +#define I40E_GL_SWR_PM_UP_THR0x269FBC
>  
> +static void
> +i40e_configure_registers(struct i40e_hw *hw)
> +{
>   static const struct {
>   uint32_t addr;
>   uint64_t val;
> @@ -5354,11 +5363,11 @@ i40e_configure_registers(struct i40e_hw *hw)
>   uint32_t i;
>   int ret;
>  
> - /* Below fix is for X710 only */
> - if (i40e_is_40G_device(hw->device_id))
> - return;
> -
>   for (i = 0; i < RTE_DIM(reg_table); i++) {
> + if ((i40e_is_40G_device(hw->device_id)) &&
> + (reg_table[i].addr == I40E_GL_SWR_PM_UP_THR))
> + continue;
> +
>   ret = i40e_debug_read_register(hw, reg_table[i].addr, );
>   if (ret < 0) {
>   PMD_DRV_LOG(ERR, "Failed to read from 0x%"PRIx32,
> -- 
> 1.9.3
> 
> 

[dpdk-dev] [PATCH 0/6] Enable VF RSS for Niantic

[Ouyang, Changchun]

Hi,
I have v3 patch for this to resolve your comments,
We can discuss on v3 patch if there are further comments.
Thanks
Changchun

From: Vladislav Zolotarov [mailto:vl...@cloudius-systems.com]
Sent: Sunday, December 21, 2014 4:02 PM
To: Ouyang, Changchun
Cc: dev at dpdk.org
Subject: RE: [PATCH 0/6] Enable VF RSS for Niantic


On Dec 19, 2014 3:35 AM, "Ouyang, Changchun" mailto:changchun.ouyang at intel.com>> wrote:
>
> My response as below.
>
>
>
> From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com cloudius-systems.com>]
> Sent: Thursday, December 18, 2014 9:06 PM
> To: dev at dpdk.org; Ouyang, Changchun
> Subject: Re: [PATCH 0/6] Enable VF RSS for Niantic
>
>
>
>
>
> On 12/18/14 12:11, Vlad Zolotarov wrote:
>>
>> From: Changchun Ouyang > intel.com>
>>
>>
>>
>> This patch enables VF RSS for Niantic, which allow each VF having at most 4 
>> queues.
>>
>> The actual queue number per VF depends on the number of VF:
>>
>> VF number from 1~32: 4 queues per VF;
>>
>> VF number from 33~max vf num: 2 queues per VF;
>>
>>
>>
>> On host, to enable VF RSS functionality, mq mode should be set as 
>> ETH_MQ_RX_VMDQ_RSS
>>
>> or ETH_MQ_RX_RSS mode, and SRIOV mode should be activated.
>>
>> It also needs config VF RSS information like hash function, RSS key, RSS key 
>> length.
>
>
> This patch series is missing a few things:
>
> Taking into the consideration the number of Rx queues requested by a user in 
> the rte_eth_dev_configure().
>
> Changchun: yes, will have a v2 to consider it, as I say in my previous 
> response.

I must have joined the mailing list after your v2 series. I'll take a look in 
the web for it.

>
> dev->dev_ops->reta_query used by a rte_eth_dev_rss_reta_query() is still not 
> initialized for a VF. Thus there is no way to query the RSS table
>
> Changchun: do you mean query rss table on guest?

Of course.

Niantic doesn?t have separate reta for a specific vf, the reta is shared by pf 
and all vf.

AFAIK the reta is statically divided between all available functions.

So, first of all we need a way to know that is the size of a single VF 
partition in order to know how many RSS queues may be configured.

Then we need an ability to query/set the contents of the corresponding reta 
partition like we can for PF.

>
> Do you think of returning all reta contents for each vf make sense?  Or any 
> other insight here?
>
> rte_eth_dev_info_get() returns reta_size == 0 when called for a VF function.
>
> Changchun:  same as above.
>
> Your insight here are welcome here.
>
> thanks
>
> Changchun
>
>

[dpdk-dev] [PATCH RFC 0/3] DPDK ethdev callback support

[Qiu, Michael]

Hi Bruce,

I haven't seen the third patch of you patch set.

Just want to know if only me missed.

Thanks,
Michael

On 12/23/2014 12:48 AM, Bruce Richardson wrote:
> This RFC is for a small addition to the ethdev library, to add in support for
> callbacks at the RX and TX stages. This allows packet processing to be done on
> packets before they get returned to applications using rte_eth_rx_burst call.
>
> Use case: the first use case for this is to enable a consistent set of 
> packets mbufs to be received by applications irrespective of the NIC used
> to receive those. For example, for a port type that does not support RSS,
> a callback on RX can be configured to calculate a hash in software. 
> Similarly, this mechanism can be used to add other information to mbufs
> as they are received, such as timestamps or sequence numbers, without 
> cluttering
> up the main packet processing path with checks for whether packets have these
> fields filled in or not.
> A second use case is ease of intrumenting existing code. The example 
> application 
> shows how combining a timestamp insertion callback on RX can be paired with a 
> latency calculation callback on TX to easily instrument any application for
> packet latency.
> A third use case is to potentially extend existing NIC capabilities beyond
> what is currently supported. For example, where flow director capabilities
> can match up to a certain limit of flows - in the thousands, in the case of
> NICs using the ixgbe driver - a callback can extend this to potentially
> millions of flows by using a software hash table lookup inline for packets
> that missing the hardware lookup filters. It would all appear transparent 
> to the packet handling code in the main application.
>
> Future extensions: in future the ethdev library can be extended to provide
> a standard set of callbacks for use by drivers. 
>
> For now this patch set is RFC and still needs additional work for creating
> a remove function for callbacks and to add in additional testing code.
> Since this adds in new code into the critical data path, I have run some
> performance tests using testpmd with the ixgbe vector drivers (i.e. the
> fastest, fast-path we have :-) ). Performance drops due to this patch
> seems minimal to non-existant, rough tests on my system indicate a drop
> of perhaps 1%.
>
> All feedback welcome.
>
> Bruce Richardson (3):
>   ethdev: rename callbacks field to intr_cbs
>   ethdev: Add in data rxtx callback support
>   examples: example showing use of callbacks.
>
>  app/test/virtual_pmd.c |   2 +-
>  examples/rxtx_callbacks/Makefile   |  57 +
>  examples/rxtx_callbacks/basicfwd.c | 222 
> +
>  examples/rxtx_callbacks/basicfwd.h |  46 +++
>  lib/librte_ether/rte_ethdev.c  | 103 +--
>  lib/librte_ether/rte_ethdev.h  | 125 ++-
>  lib/librte_pmd_bond/rte_eth_bond_api.c |   2 +-
>  7 files changed, 543 insertions(+), 14 deletions(-)
>  create mode 100644 examples/rxtx_callbacks/Makefile
>  create mode 100644 examples/rxtx_callbacks/basicfwd.c
>  create mode 100644 examples/rxtx_callbacks/basicfwd.h
>

[dpdk-dev] [PATCH v2 1/6] ixgbe: Code cleanup

[Ouyang, Changchun]

Hi Helin,

> -Original Message-
> From: Zhang, Helin
> Sent: Wednesday, December 24, 2014 11:54 AM
> To: Ouyang, Changchun
> Cc: dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v2 1/6] ixgbe: Code cleanup
> 
> 
> 
> > -Original Message-
> > From: Ouyang, Changchun
> > Sent: Wednesday, December 24, 2014 11:50 AM
> > To: Zhang, Helin
> > Cc: dev at dpdk.org; Ouyang, Changchun
> > Subject: RE: [dpdk-dev] [PATCH v2 1/6] ixgbe: Code cleanup
> >
> > Hi Helin,
> >
> > > -Original Message-
> > > From: Zhang, Helin
> > > Sent: Wednesday, December 24, 2014 11:41 AM
> > > To: Ouyang, Changchun
> > > Cc: dev at dpdk.org
> > > Subject: RE: [dpdk-dev] [PATCH v2 1/6] ixgbe: Code cleanup
> > >
> > > Hi Changchun
> > >
> > > > -Original Message-
> > > > From: Ouyang, Changchun
> > > > Sent: Wednesday, December 24, 2014 11:22 AM
> > > > To: Zhang, Helin; dev at dpdk.org
> > > > Cc: Ouyang, Changchun
> > > > Subject: RE: [dpdk-dev] [PATCH v2 1/6] ixgbe: Code cleanup
> > > >
> > > > Hi Helin,
> > > >
> > > > > -Original Message-
> > > > > From: Zhang, Helin
> > > > > Sent: Wednesday, December 24, 2014 11:08 AM
> > > > > To: Ouyang, Changchun; dev at dpdk.org
> > > > > Subject: RE: [dpdk-dev] [PATCH v2 1/6] ixgbe: Code cleanup
> > > > >
> > > > > Is header split really supported in ixgbe? I guess not. If not,
> > > > > this code changes are not needed at all.
> > > > >
> > > >
> > > > I don't try to modify any logic here, as you know vf rss don't
> > > > have nothing to do with header split.
> > > But you modified code for header split. Have you validated it?
> > >
> > > > You mean " guess not ", can you 'make sure of it' rather than 'guess'
> > > > if you want to remove those codes?
> > > I did not see anywhere can enable ixgbe header split. It is your
> > > turn to make sure if your code changes are needed and correct. I
> > > don't want to remove any code, just want to know if your code have
> > > been validated for
> > header split.
> >
> > Yes, I make sure the code change is correct, and already validate the
> > code change on my platform, besides that, we also have validation team
> > to do further validation. any other concern then?
> I still don't know how to enable header split for ixgbe. Any answer from you?

As this patch aims at enabling vf rss, how about let's focus on it and don't 
fork to other features?
Thanks for your comments

Changchun

[dpdk-dev] [PATCH v2 1/6] ixgbe: Code cleanup

[Zhang, Helin]

> -Original Message-
> From: Ouyang, Changchun
> Sent: Wednesday, December 24, 2014 11:50 AM
> To: Zhang, Helin
> Cc: dev at dpdk.org; Ouyang, Changchun
> Subject: RE: [dpdk-dev] [PATCH v2 1/6] ixgbe: Code cleanup
> 
> Hi Helin,
> 
> > -Original Message-
> > From: Zhang, Helin
> > Sent: Wednesday, December 24, 2014 11:41 AM
> > To: Ouyang, Changchun
> > Cc: dev at dpdk.org
> > Subject: RE: [dpdk-dev] [PATCH v2 1/6] ixgbe: Code cleanup
> >
> > Hi Changchun
> >
> > > -Original Message-
> > > From: Ouyang, Changchun
> > > Sent: Wednesday, December 24, 2014 11:22 AM
> > > To: Zhang, Helin; dev at dpdk.org
> > > Cc: Ouyang, Changchun
> > > Subject: RE: [dpdk-dev] [PATCH v2 1/6] ixgbe: Code cleanup
> > >
> > > Hi Helin,
> > >
> > > > -Original Message-
> > > > From: Zhang, Helin
> > > > Sent: Wednesday, December 24, 2014 11:08 AM
> > > > To: Ouyang, Changchun; dev at dpdk.org
> > > > Subject: RE: [dpdk-dev] [PATCH v2 1/6] ixgbe: Code cleanup
> > > >
> > > > Is header split really supported in ixgbe? I guess not. If not,
> > > > this code changes are not needed at all.
> > > >
> > >
> > > I don't try to modify any logic here, as you know vf rss don't have
> > > nothing to do with header split.
> > But you modified code for header split. Have you validated it?
> >
> > > You mean " guess not ", can you 'make sure of it' rather than 'guess'
> > > if you want to remove those codes?
> > I did not see anywhere can enable ixgbe header split. It is your turn
> > to make sure if your code changes are needed and correct. I don't want
> > to remove any code, just want to know if your code have been validated for
> header split.
> 
> Yes, I make sure the code change is correct, and already validate the code
> change on my platform, besides that, we also have validation team to do
> further validation. any other concern then?
I still don't know how to enable header split for ixgbe. Any answer from you?

Regards,
Helin

> 
> Thanks
> Changchun

[dpdk-dev] [PATCH v2 1/6] ixgbe: Code cleanup

[Ouyang, Changchun]

Hi Helin,

> -Original Message-
> From: Zhang, Helin
> Sent: Wednesday, December 24, 2014 11:41 AM
> To: Ouyang, Changchun
> Cc: dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v2 1/6] ixgbe: Code cleanup
> 
> Hi Changchun
> 
> > -Original Message-
> > From: Ouyang, Changchun
> > Sent: Wednesday, December 24, 2014 11:22 AM
> > To: Zhang, Helin; dev at dpdk.org
> > Cc: Ouyang, Changchun
> > Subject: RE: [dpdk-dev] [PATCH v2 1/6] ixgbe: Code cleanup
> >
> > Hi Helin,
> >
> > > -Original Message-
> > > From: Zhang, Helin
> > > Sent: Wednesday, December 24, 2014 11:08 AM
> > > To: Ouyang, Changchun; dev at dpdk.org
> > > Subject: RE: [dpdk-dev] [PATCH v2 1/6] ixgbe: Code cleanup
> > >
> > > Is header split really supported in ixgbe? I guess not. If not, this
> > > code changes are not needed at all.
> > >
> >
> > I don't try to modify any logic here, as you know vf rss don't have
> > nothing to do with header split.
> But you modified code for header split. Have you validated it?
> 
> > You mean " guess not ", can you 'make sure of it' rather than 'guess'
> > if you want to remove those codes?
> I did not see anywhere can enable ixgbe header split. It is your turn to make
> sure if your code changes are needed and correct. I don't want to remove
> any code, just want to know if your code have been validated for header split.

Yes, I make sure the code change is correct, and already validate the code 
change on my platform, besides that, 
we also have validation team to do further validation. any other concern then?

Thanks
Changchun

[dpdk-dev] [PATCH v2 1/6] ixgbe: Code cleanup

[Zhang, Helin]

Hi Changchun

> -Original Message-
> From: Ouyang, Changchun
> Sent: Wednesday, December 24, 2014 11:22 AM
> To: Zhang, Helin; dev at dpdk.org
> Cc: Ouyang, Changchun
> Subject: RE: [dpdk-dev] [PATCH v2 1/6] ixgbe: Code cleanup
> 
> Hi Helin,
> 
> > -Original Message-
> > From: Zhang, Helin
> > Sent: Wednesday, December 24, 2014 11:08 AM
> > To: Ouyang, Changchun; dev at dpdk.org
> > Subject: RE: [dpdk-dev] [PATCH v2 1/6] ixgbe: Code cleanup
> >
> > Is header split really supported in ixgbe? I guess not. If not, this
> > code changes are not needed at all.
> >
> 
> I don't try to modify any logic here, as you know vf rss don't have nothing 
> to do
> with header split.
But you modified code for header split. Have you validated it?

> You mean " guess not ", can you 'make sure of it' rather than 'guess' if you 
> want
> to remove those codes?
I did not see anywhere can enable ixgbe header split. It is your turn to make 
sure if your
code changes are needed and correct. I don't want to remove any code, just want 
to know if your code have been validated for header split.

> 
> Thanks
> Changchun

[dpdk-dev] [PATCH v2 1/6] ixgbe: Code cleanup

[Ouyang, Changchun]

Hi Helin,

> -Original Message-
> From: Zhang, Helin
> Sent: Wednesday, December 24, 2014 11:08 AM
> To: Ouyang, Changchun; dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v2 1/6] ixgbe: Code cleanup
> 
> Is header split really supported in ixgbe? I guess not. If not, this code 
> changes
> are not needed at all.
> 

I don't try to modify any logic here, as you know vf rss don't have nothing to 
do with header split.
You mean " guess not ", can you 'make sure of it' rather than 'guess' if you 
want to remove those codes?

Thanks
Changchun

[dpdk-dev] [PATCH v2 1/6] ixgbe: Code cleanup

[Zhang, Helin]

Is header split really supported in ixgbe? I guess not. If not, this code 
changes are not needed at all.

Regards,
Helin

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ouyang Changchun
> Sent: Wednesday, December 24, 2014 10:57 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2 1/6] ixgbe: Code cleanup
> 
> Put global register configuring out of loop for queue; also fix typo and 
> indent.
> 
> Signed-off-by: Changchun Ouyang 
> ---
>  lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 29 +++--
>  1 file changed, 15 insertions(+), 14 deletions(-)
> 
> diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> index 5c36bff..f58f98e 100644
> --- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> +++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> @@ -3985,7 +3985,7 @@ ixgbevf_dev_rx_init(struct rte_eth_dev *dev)
>   struct igb_rx_queue *rxq;
>   struct rte_pktmbuf_pool_private *mbp_priv;
>   uint64_t bus_addr;
> - uint32_t srrctl;
> + uint32_t srrctl, psrtype = 0;
>   uint16_t buf_size;
>   uint16_t i;
>   int ret;
> @@ -4039,20 +4039,10 @@ ixgbevf_dev_rx_init(struct rte_eth_dev *dev)
>* Configure Header Split
>*/
>   if (dev->data->dev_conf.rxmode.header_split) {
> -
> - /* Must setup the PSRTYPE register */
> - uint32_t psrtype;
> - psrtype = IXGBE_PSRTYPE_TCPHDR |
> - IXGBE_PSRTYPE_UDPHDR   |
> - IXGBE_PSRTYPE_IPV4HDR  |
> - IXGBE_PSRTYPE_IPV6HDR;
> -
> - IXGBE_WRITE_REG(hw, IXGBE_VFPSRTYPE(i), psrtype);
> -
>   srrctl = ((dev->data->dev_conf.rxmode.split_hdr_size <<
> -IXGBE_SRRCTL_BSIZEHDRSIZE_SHIFT) &
> -   IXGBE_SRRCTL_BSIZEHDR_MASK);
> - srrctl |= E1000_SRRCTL_DESCTYPE_HDR_SPLIT_ALWAYS;
> + IXGBE_SRRCTL_BSIZEHDRSIZE_SHIFT) &
> + IXGBE_SRRCTL_BSIZEHDR_MASK);
> + srrctl |= IXGBE_SRRCTL_DESCTYPE_HDR_SPLIT_ALWAYS;
>   } else
>  #endif
>   srrctl = IXGBE_SRRCTL_DESCTYPE_ADV_ONEBUF; @@ -4095,6
> +4085,17 @@ ixgbevf_dev_rx_init(struct rte_eth_dev *dev)
>   }
>   }
> 
> +#ifdef RTE_HEADER_SPLIT_ENABLE
> + if (dev->data->dev_conf.rxmode.header_split) {
> + /* Must setup the PSRTYPE register */
> + psrtype = IXGBE_PSRTYPE_TCPHDR |
> + IXGBE_PSRTYPE_UDPHDR   |
> + IXGBE_PSRTYPE_IPV4HDR  |
> + IXGBE_PSRTYPE_IPV6HDR;
> +#endif
> +
> + IXGBE_WRITE_REG(hw, IXGBE_VFPSRTYPE, psrtype);
> +
>   if (dev->data->dev_conf.rxmode.enable_scatter) {
>   if (!dev->data->scattered_rx)
>   PMD_INIT_LOG(DEBUG, "forcing scatter mode");
> --
> 1.8.4.2

[dpdk-dev] [PATCH RFC 0/3] DPDK ethdev callback support

[Zhang, Helin]

For L2 RSS, I think i40e hardware supports it, which will be enabled soon later.

Regards,
Helin

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vithal S Mohare
> Sent: Tuesday, December 23, 2014 5:38 PM
> To: Richardson, Bruce
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH RFC 0/3] DPDK ethdev callback support
> 
> Agree.  As the mbuf is already received in the rx-q, may not yield great
> advantage.
> On side note, any plans to support RSS for L2 packets ?
> 
> -Original Message-
> From: Bruce Richardson [mailto:bruce.richardson at intel.com]
> Sent: Tuesday, December 23, 2014 3:00 PM
> To: Vithal S Mohare
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH RFC 0/3] DPDK ethdev callback support
> 
> On Tue, Dec 23, 2014 at 04:23:21AM +, Vithal S Mohare wrote:
> > Hi Bruce,
> >
> > 
> > For example, for a port type that does not support RSS, a callback on RX can
> be configured to calculate a hash in software.
> > 
> >
> > Wondering if this callback will also be useful to bridge the gap of no RSS
> support for L2 packets.  i.e. in the rx call-back handler, can applications
> calculate hash and feed it back so that spraying happens based on this?  Now,
> all pure L2 packets (e.g. arp pkts) comes to rx-q 0 of the 'port'.  Adding
> callback to [port][rx-q:0] would help?
> >
> > Thanks,
> > -Vithal
> 
> Yes, that could work. The downside is that it is no faster than having an app 
> do
> the calculation itself, it's just perhaps a little easier to work with in the 
> app.
> 
> /Bruce
> 
> >
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> > Sent: Monday, December 22, 2014 10:17 PM
> > To: dev at dpdk.org
> > Subject: [dpdk-dev] [PATCH RFC 0/3] DPDK ethdev callback support
> >
> > This RFC is for a small addition to the ethdev library, to add in support 
> > for
> callbacks at the RX and TX stages. This allows packet processing to be done on
> packets before they get returned to applications using rte_eth_rx_burst call.
> >
> > Use case: the first use case for this is to enable a consistent set of 
> > packets
> mbufs to be received by applications irrespective of the NIC used to receive
> those. For example, for a port type that does not support RSS, a callback on 
> RX
> can be configured to calculate a hash in software.
> > Similarly, this mechanism can be used to add other information to mbufs as
> they are received, such as timestamps or sequence numbers, without
> cluttering up the main packet processing path with checks for whether packets
> have these fields filled in or not.
> > A second use case is ease of intrumenting existing code. The example
> application shows how combining a timestamp insertion callback on RX can be
> paired with a latency calculation callback on TX to easily instrument any
> application for packet latency.
> > A third use case is to potentially extend existing NIC capabilities beyond 
> > what
> is currently supported. For example, where flow director capabilities can 
> match
> up to a certain limit of flows - in the thousands, in the case of NICs using 
> the
> ixgbe driver - a callback can extend this to potentially millions of flows by 
> using
> a software hash table lookup inline for packets that missing the hardware
> lookup filters. It would all appear transparent to the packet handling code in
> the main application.
> >
> > Future extensions: in future the ethdev library can be extended to provide a
> standard set of callbacks for use by drivers.
> >
> > For now this patch set is RFC and still needs additional work for creating a
> remove function for callbacks and to add in additional testing code.
> > Since this adds in new code into the critical data path, I have run some
> performance tests using testpmd with the ixgbe vector drivers (i.e. the 
> fastest,
> fast-path we have :-) ). Performance drops due to this patch seems minimal to
> non-existant, rough tests on my system indicate a drop of perhaps 1%.
> >
> > All feedback welcome.
> >
> > Bruce Richardson (3):
> >   ethdev: rename callbacks field to intr_cbs
> >   ethdev: Add in data rxtx callback support
> >   examples: example showing use of callbacks.
> >
> >  app/test/virtual_pmd.c |   2 +-
> >  examples/rxtx_callbacks/Makefile   |  57 +
> >  examples/rxtx_callbacks/basicfwd.c | 222
> +
> >  examples/rxtx_callbacks/basicfwd.h |  46 +++
> >  lib/librte_ether/rte_ethdev.c  | 103 +--
> >  lib/librte_ether/rte_ethdev.h  | 125 ++-
> >  lib/librte_pmd_bond/rte_eth_bond_api.c |   2 +-
> >  7 files changed, 543 insertions(+), 14 deletions(-)  create mode
> > 100644 examples/rxtx_callbacks/Makefile  create mode 100644
> > examples/rxtx_callbacks/basicfwd.c
> >  create mode 100644 examples/rxtx_callbacks/basicfwd.h
> >
> > --
> > 1.9.3
> >