[dpdk-dev] flow director - perfect match filter
Hi, Poborsky Please try sending an IP packet (not UDP, TCP or SCTP). Or you can try to set filter.l4type = RTE_FDIR_L4TYPE_TCP when adding a filter. I guess it is because the NIC already classify you packet as TCP one. > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Newman Poborsky > Sent: Thursday, October 30, 2014 11:18 PM > To: dev at dpdk.org > Subject: [dpdk-dev] flow director - perfect match filter > > Hi, > > I'm not sure this is the right place to post a question like this, but I've > been > stuck with the same problem for days now. > > I'm trying to use flow director perfect match filters and so far I haven't > been > able to get it working. I have tried writing my own simple app (based on given > examples) and I tried adding filter using something as simple as: > > //setting the mask to watch for src IP > memset(&fdir_masks, 0x00, sizeof(struct rte_fdir_masks)); > fdir_masks.src_ipv4_mask = 0x; ret = > rte_eth_dev_fdir_set_masks(portid, &fdir_masks); //adding filter > memset(&filter, 0, sizeof(struct rte_fdir_filter)); filter.ip_src.ipv4_addr = > htonl(ipv4_src); filter.l4type = RTE_FDIR_L4TYPE_NONE; filter.iptype = > RTE_FDIR_IPTYPE_IPV4; ret = > rte_eth_dev_fdir_add_perfect_filter(portid,&filter,3,queue,0); > ... > > > After running this code and using using tcpreplay to push traffic to > interface, I > get all the misses in the stats and no matches. As far as I understand, to > match only on src IP, all rte_fdir_filter elements should be set to 0, and > only > src_ip should be masked (with 1's). > > After this I tried running testpmd application but also no luck. The commands > I used are: > set_masks_filter 0 only_ip_flow 0 src_mask 0x 0x dst_mask > 0x 0x flexbytes 0 vlan_id 0 vlan_prio 0 add_perfect_filter 0 ip > src 10.10.10.10 0 dst 0.0.0.0 0 flexbytes 0 vlan 0 queue 1 soft 3 > > Filter is added but after sending packets to this interface, I only see > misses in > stats. > > What I am doing wrong? I've read the docs and looked at API reference but > didn't find anything that could help me. > > Configuring flow director filter using ethtool and sending same packets > results in matches, so packets I'm sending should be matched. > > Thank you for any help! > > Newman P.
[dpdk-dev] Relationship between H/W ring and S/W ring
Thanks Bruce. I also agree with that the size of the S/W ring depends on the configuration parameters because the size of the S/W ring is /sizeof(struct igb_rx_entry) * len/ in the ixgbe_dev_rx_queue_setup function. H/W ring is also allocated in the same function by using the ring_dma_zone_reserve function, and its size is RX_RING_SZ. I don't think the RX_RING_SZ is configurable but it is fixed value. Is there any other code configuring the size of H/W ring? 2014-10-30 ?? 6:55? Bruce Richardson ?(?) ? ?: > On Thu, Oct 30, 2014 at 04:32:16PM +0900, Gyumin wrote: >> Hi >> >> I`m reading the ixgbe code especially about H/W ring and S/W ring. Is the >> relationship between H/W ring and S/W ring one-to-one mapping? >> As far as I know, H/W ring size is determined in the code(hard coded) while >> S/W ring size is determined in port configuration time. >> In the ixgbe_rx_alloc_bufs function, H/W ring header address and packet >> address indicate the DMA address of S/W ring's mbuf. I understand it means >> that the relationship between the H/W ring and S/W ring is one-to-one >> mapping. For example, if the size of H/W ring is greater than the size of >> S/W ring then some portion of H/W ring is unused. Is it correct? >> >> Thanks > Hi, > > Yes, there is a 1:1 mapping between the hardware and software ring entries, > and both are sized depending on the configuration parameters passed to the > ring setup APIs. As you state, the HW ring contains the DMA addresses of the > packet buffers, while the sw_ring contains the pointers to the original > mbufs. The two rings are always kept in sync in the code. > > /Bruce >
[dpdk-dev] [PATCH v3 7/8] ethdev: support of multiple sizes of redirection table
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Tuesday, October 28, 2014 6:05 PM > To: Zhang, Helin > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v3 7/8] ethdev: support of multiple sizes of > redirection table > > 2014-10-28 00:37, Zhang, Helin: > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > 2014-10-22 19:53, Helin Zhang: > > > > +#define RTE_BIT_WIDTH_64 (CHAR_BIT * sizeof(uint64_t)) > > > > > > How can it be different of 64? > > > Using 64 would be simpler to understand than RTE_BIT_WIDTH_64. > > > > > > > + uint8_t reta[RTE_BIT_WIDTH_64]; /**< 64 redirection table > > > > entries. */ > > We always try to use macro in code to replace numeric, this can get the > > numeric > more understandable. > > How bit width 64 is more understandable than 64? > Especially when you count a number of entries, not a bit width. > RETA_ENTRIES_MAX would be more understandable. Renaming the macro is needed. I plan to rename it to RTE_RETA_GROUP_SIZE, as it is a group of 64 reta entries, but not the maximum number of valid entries. > > -- > Thomas Regards, Helin
[dpdk-dev] [PATCH] igb_uio: fix build for longterm kernel 2.6.32.63
This patch will make RHEL6 build failed.
The root cause is that RHEL-based kernel is slightly different with
upstream kernel.
It has some functions (pci_num_vf, kstrtoul, etc) which don't exist in
upstream
longterm kernel.
For better compatibility, IMHO it is distinguishing RHEL-based kernel
and upstream one.
Using macro like:
```
#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 34) && \
!(defined(RHEL_RELEASE_CODE) && RHEL_RELEASE_CODE >=
RHEL_RELEASE_VERSION(6, 3))
static int pci_num_vf(struct pci_dev *dev)
{
```
But this is RHEL-specified fix. For other distros, if they have some
problem, we should
hack it in the same way.
Thanks and regards,
Jincheng Miao
On 10/30/2014 04:18 PM, Jincheng Miao wrote:
> There is a logical error in igb_uio/compat.h when define pci_num_vf().
> Only CONFIG_PCI_IOV enabled, this function could be defined.
>
> This patch fix the following error for linux-2.6.32.63:
> CC [M]
> /root/dpdk-source/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.o
> /root/dpdk-source/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.c: In
> function ?show_max_vfs?:
> /root/dpdk-source/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.c:75:
> error: implicit declaration of function ?pci_num_vf?
>
> Signed-off-by: Jincheng Miao
> ---
> lib/librte_eal/linuxapp/igb_uio/compat.h |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/lib/librte_eal/linuxapp/igb_uio/compat.h
> b/lib/librte_eal/linuxapp/igb_uio/compat.h
> index 676fa1b..0af0cae 100644
> --- a/lib/librte_eal/linuxapp/igb_uio/compat.h
> +++ b/lib/librte_eal/linuxapp/igb_uio/compat.h
> @@ -21,7 +21,7 @@
> #endif
>
> #if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 34) && \
> - !defined(CONFIG_PCI_IOV)
> + defined(CONFIG_PCI_IOV)
>
> static int pci_num_vf(struct pci_dev *dev)
> {
[dpdk-dev] [PATCH] i40e:fix MAC filter issues in i40e_ethdev.c
This patch fixes two issues: one is to fix the log issue, the other is to set filter type when updating the default MAC filter. Signed-off-by: Jijiang Liu --- lib/librte_pmd_i40e/i40e_ethdev.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/lib/librte_pmd_i40e/i40e_ethdev.c b/lib/librte_pmd_i40e/i40e_ethdev.c index d768a08..b35cdd2 100644 --- a/lib/librte_pmd_i40e/i40e_ethdev.c +++ b/lib/librte_pmd_i40e/i40e_ethdev.c @@ -1723,7 +1723,7 @@ i40e_mac_filter_handle(struct rte_eth_dev *dev, enum rte_filter_op filter_op, i40e_pf_enable_irq0(hw); break; default: - PMD_DRV_LOG(ERR, "unknown operation %u\n", filter_op); + PMD_DRV_LOG(ERR, "unknown operation %u", filter_op); ret = I40E_ERR_PARAM; break; } @@ -2628,6 +2628,7 @@ i40e_update_default_filter_setting(struct i40e_vsi *vsi) mac = &f->mac_info.mac_addr; (void)rte_memcpy(&mac->addr_bytes, hw->mac.perm_addr, ETH_ADDR_LEN); + f->mac_info.filter_type = RTE_MACVLAN_PERFECT_MATCH; TAILQ_INSERT_TAIL(&vsi->mac_list, f, next); vsi->mac_num++; -- 1.7.7.6
[dpdk-dev] [PATCH] librte_ether:change rte_eth_mac_filter structure
As the filter type in i40e is defined enum type, so this patch changes the
filter_type filed in the rte_eth_mac_filter for fixing the compilation error
under ICC compiler.
Signed-off-by: Jijiang Liu
---
lib/librte_ether/rte_eth_ctrl.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index 14a739b..91a6b64 100644
--- a/lib/librte_ether/rte_eth_ctrl.h
+++ b/lib/librte_ether/rte_eth_ctrl.h
@@ -91,7 +91,7 @@ enum rte_mac_filter_type {
struct rte_eth_mac_filter {
uint8_t is_vf; /**< 1 for VF, 0 for port dev */
uint16_t dst_id; /**
[dpdk-dev] [PATCH v2] i40e:fix MAC filter issues in i40e_ethdev.c
This patch fixes two issues: one is to fix the log issues, the other is to set
filter type when updating the default MAC filter.
v2 changes:
Fix the remaining PMD log issues.
Signed-off-by: Jijiang Liu
---
lib/librte_pmd_i40e/i40e_ethdev.c | 17 +
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/lib/librte_pmd_i40e/i40e_ethdev.c
b/lib/librte_pmd_i40e/i40e_ethdev.c
index d768a08..a860af7 100644
--- a/lib/librte_pmd_i40e/i40e_ethdev.c
+++ b/lib/librte_pmd_i40e/i40e_ethdev.c
@@ -1633,33 +1633,33 @@ i40e_vf_mac_filter_set(struct i40e_pf *pf,
int ret;
if (pf == NULL) {
- PMD_DRV_LOG(ERR, "Invalid PF argument\n");
+ PMD_DRV_LOG(ERR, "Invalid PF argument.");
return -EINVAL;
}
hw = I40E_PF_TO_HW(pf);
if (filter == NULL) {
- PMD_DRV_LOG(ERR, "Invalid mac filter argument\n");
+ PMD_DRV_LOG(ERR, "Invalid mac filter argument.");
return -EINVAL;
}
new_mac = &filter->mac_addr;
if (is_zero_ether_addr(new_mac)) {
- PMD_DRV_LOG(ERR, "Invalid ethernet address\n");
+ PMD_DRV_LOG(ERR, "Invalid ethernet address.");
return -EINVAL;
}
vf_id = filter->dst_id;
if (vf_id > pf->vf_num - 1 || !pf->vfs) {
- PMD_DRV_LOG(ERR, "Invalid argument\n");
+ PMD_DRV_LOG(ERR, "Invalid argument.");
return -EINVAL;
}
vf = &pf->vfs[vf_id];
if (add && is_same_ether_addr(new_mac, &(pf->dev_addr))) {
- PMD_DRV_LOG(INFO, "Ignore adding permanent MAC address\n");
+ PMD_DRV_LOG(INFO, "Ignore adding permanent MAC address.");
return -EINVAL;
}
@@ -1673,7 +1673,7 @@ i40e_vf_mac_filter_set(struct i40e_pf *pf,
mac_filter.filter_type = filter->filter_type;
ret = i40e_vsi_add_mac(vf->vsi, &mac_filter);
if (ret != I40E_SUCCESS) {
- PMD_DRV_LOG(ERR, "Failed to add MAC filter\n");
+ PMD_DRV_LOG(ERR, "Failed to add MAC filter.");
return -1;
}
ether_addr_copy(new_mac, &pf->dev_addr);
@@ -1682,7 +1682,7 @@ i40e_vf_mac_filter_set(struct i40e_pf *pf,
ETHER_ADDR_LEN);
ret = i40e_vsi_delete_mac(vf->vsi, &filter->mac_addr);
if (ret != I40E_SUCCESS) {
- PMD_DRV_LOG(ERR, "Failed to delete MAC filter\n");
+ PMD_DRV_LOG(ERR, "Failed to delete MAC filter.");
return -1;
}
@@ -1723,7 +1723,7 @@ i40e_mac_filter_handle(struct rte_eth_dev *dev, enum
rte_filter_op filter_op,
i40e_pf_enable_irq0(hw);
break;
default:
- PMD_DRV_LOG(ERR, "unknown operation %u\n", filter_op);
+ PMD_DRV_LOG(ERR, "unknown operation %u", filter_op);
ret = I40E_ERR_PARAM;
break;
}
@@ -2628,6 +2628,7 @@ i40e_update_default_filter_setting(struct i40e_vsi *vsi)
mac = &f->mac_info.mac_addr;
(void)rte_memcpy(&mac->addr_bytes, hw->mac.perm_addr,
ETH_ADDR_LEN);
+ f->mac_info.filter_type = RTE_MACVLAN_PERFECT_MATCH;
TAILQ_INSERT_TAIL(&vsi->mac_list, f, next);
vsi->mac_num++;
--
1.7.7.6
[dpdk-dev] [PATCH v3 0/5] Support virtio multicast feature
- V1 change: This patch series support multicast feature in virtio and vhost. The vhost backend enables the promiscuous mode and config ETH_VMDQ_ACCEPT_BROADCAST and ETH_VMDQ_ACCEPT_MULTICAST in VMDQ offload register to receive the multicast and broadcast packets. The virtio frontend provides the functionality of enabling and disabling the multicast and promiscuous mode. -V2 change: Rework the patch basing on new vhost library and new vhost application. -V3 change: Rework the patch for comments, split commits. Changchun Ouyang (5): Add vmdq rx mode field into rx config struct. Config VM offload register in igb PMD to enable it receive broadcast and multicast packets. Config PFVML2FLT register in ixgbe PMD to enable it receive broadcast and multicast packets. Add new API in virtio for supporting promiscuous and allmulticast enable and disable. This is to enable user space vhost receiving and forwarding broadcast and multicast packets: Use new option in command line to enable promisc mode; Enable 2 bits in VMDQ RX mode: ETH_VMDQ_ACCEPT_BROADCAST and ETH_VMDQ_ACCEPT_MULTICAST. examples/vhost/main.c | 24 -- lib/librte_ether/rte_ethdev.h | 1 + lib/librte_pmd_e1000/igb_rxtx.c | 20 lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 16 +++ lib/librte_pmd_virtio/virtio_ethdev.c | 90 ++- lib/librte_vhost/virtio-net.c | 4 +- 6 files changed, 150 insertions(+), 5 deletions(-) -- 1.8.4.2
[dpdk-dev] [PATCH v3 1/5] ethdev: add vmdq rx mode
Add vmdq rx mode field into rx config struct.
Signed-off-by: Changchun Ouyang
---
lib/librte_ether/rte_ethdev.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 8bf274d..c1413d2 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -577,6 +577,7 @@ struct rte_eth_vmdq_rx_conf {
uint8_t default_pool; /**< The default pool, if applicable */
uint8_t enable_loop_back; /**< Enable VT loop back */
uint8_t nb_pool_maps; /**< We can have up to 64 filters/mappings */
+ uint32_t rx_mode; /**< RX mode for vmdq */
struct {
uint16_t vlan_id; /**< The vlan id of the received frame */
uint64_t pools; /**< Bitmask of pools for packet rx */
--
1.8.4.2
[dpdk-dev] [PATCH v3 2/5] igb: Config VM offload register
Config VM offload register in igb PMD to enable it
receive broadcast and multicast packets.
Signed-off-by: Changchun Ouyang
---
lib/librte_pmd_e1000/igb_rxtx.c | 20
1 file changed, 20 insertions(+)
diff --git a/lib/librte_pmd_e1000/igb_rxtx.c b/lib/librte_pmd_e1000/igb_rxtx.c
index f09c525..0dca7b7 100644
--- a/lib/librte_pmd_e1000/igb_rxtx.c
+++ b/lib/librte_pmd_e1000/igb_rxtx.c
@@ -1779,6 +1779,26 @@ igb_vmdq_rx_hw_configure(struct rte_eth_dev *dev)
vt_ctl |= E1000_VT_CTL_IGNORE_MAC;
E1000_WRITE_REG(hw, E1000_VT_CTL, vt_ctl);
+ for (i = 0; i < E1000_VMOLR_SIZE; i++) {
+ vmolr = E1000_READ_REG(hw, E1000_VMOLR(i));
+ vmolr &= ~(E1000_VMOLR_AUPE | E1000_VMOLR_ROMPE |
+ E1000_VMOLR_ROPE | E1000_VMOLR_BAM |
+ E1000_VMOLR_MPME);
+
+ if (cfg->rx_mode & ETH_VMDQ_ACCEPT_UNTAG)
+ vmolr |= E1000_VMOLR_AUPE;
+ if (cfg->rx_mode & ETH_VMDQ_ACCEPT_HASH_MC)
+ vmolr |= E1000_VMOLR_ROMPE;
+ if (cfg->rx_mode & ETH_VMDQ_ACCEPT_HASH_UC)
+ vmolr |= E1000_VMOLR_ROPE;
+ if (cfg->rx_mode & ETH_VMDQ_ACCEPT_BROADCAST)
+ vmolr |= E1000_VMOLR_BAM;
+ if (cfg->rx_mode & ETH_VMDQ_ACCEPT_MULTICAST)
+ vmolr |= E1000_VMOLR_MPME;
+
+ E1000_WRITE_REG(hw, E1000_VMOLR(i), vmolr);
+ }
+
/*
* VMOLR: set STRVLAN as 1 if IGMAC in VTCTL is set as 1
* Both 82576 and 82580 support it
--
1.8.4.2
[dpdk-dev] [PATCH v3 3/5] ixgbe: Config PFVML2FLT register
Config PFVML2FLT register in ixgbe PMD to enable it
receive broadcast and multicast packets.
Signed-off-by: Changchun Ouyang
---
lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 16
1 file changed, 16 insertions(+)
diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
index 3a5a8ff..96276a7 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
+++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
@@ -3123,6 +3123,7 @@ ixgbe_vmdq_rx_hw_configure(struct rte_eth_dev *dev)
struct ixgbe_hw *hw;
enum rte_eth_nb_pools num_pools;
uint32_t mrqc, vt_ctl, vlanctrl;
+ uint32_t vmolr = 0;
int i;
PMD_INIT_FUNC_TRACE();
@@ -3145,6 +3146,21 @@ ixgbe_vmdq_rx_hw_configure(struct rte_eth_dev *dev)
IXGBE_WRITE_REG(hw, IXGBE_VT_CTL, vt_ctl);
+ for (i = 0; i < (int)num_pools; i++) {
+ if (cfg->rx_mode & ETH_VMDQ_ACCEPT_UNTAG)
+ vmolr |= IXGBE_VMOLR_AUPE;
+ if (cfg->rx_mode & ETH_VMDQ_ACCEPT_HASH_MC)
+ vmolr |= IXGBE_VMOLR_ROMPE;
+ if (cfg->rx_mode & ETH_VMDQ_ACCEPT_HASH_UC)
+ vmolr |= IXGBE_VMOLR_ROPE;
+ if (cfg->rx_mode & ETH_VMDQ_ACCEPT_BROADCAST)
+ vmolr |= IXGBE_VMOLR_BAM;
+ if (cfg->rx_mode & ETH_VMDQ_ACCEPT_MULTICAST)
+ vmolr |= IXGBE_VMOLR_MPE;
+
+ IXGBE_WRITE_REG(hw, IXGBE_VMOLR(i), vmolr);
+ }
+
/* VLNCTRL: enable vlan filtering and allow all vlan tags through */
vlanctrl = IXGBE_READ_REG(hw, IXGBE_VLNCTRL);
vlanctrl |= IXGBE_VLNCTRL_VFE ; /* enable vlan filters */
--
1.8.4.2
[dpdk-dev] [PATCH v3 4/5] virtio: New API for promisc and allmulticast
Add new API in virtio for supporting promiscuous and allmulticast enable and
disable.
Signed-off-by: Changchun Ouyang
---
lib/librte_pmd_virtio/virtio_ethdev.c | 90 ++-
1 file changed, 89 insertions(+), 1 deletion(-)
diff --git a/lib/librte_pmd_virtio/virtio_ethdev.c
b/lib/librte_pmd_virtio/virtio_ethdev.c
index 19930c0..c009f2a 100644
--- a/lib/librte_pmd_virtio/virtio_ethdev.c
+++ b/lib/librte_pmd_virtio/virtio_ethdev.c
@@ -66,6 +66,10 @@ static int eth_virtio_dev_init(struct eth_driver *eth_drv,
static int virtio_dev_configure(struct rte_eth_dev *dev);
static int virtio_dev_start(struct rte_eth_dev *dev);
static void virtio_dev_stop(struct rte_eth_dev *dev);
+static void virtio_dev_promiscuous_enable(struct rte_eth_dev *dev);
+static void virtio_dev_promiscuous_disable(struct rte_eth_dev *dev);
+static void virtio_dev_allmulticast_enable(struct rte_eth_dev *dev);
+static void virtio_dev_allmulticast_disable(struct rte_eth_dev *dev);
static void virtio_dev_info_get(struct rte_eth_dev *dev,
struct rte_eth_dev_info *dev_info);
static int virtio_dev_link_update(struct rte_eth_dev *dev,
@@ -403,6 +407,86 @@ virtio_dev_close(struct rte_eth_dev *dev)
virtio_dev_stop(dev);
}
+static void
+virtio_dev_promiscuous_enable(struct rte_eth_dev *dev)
+{
+ struct virtio_hw *hw
+ = VIRTIO_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+ struct virtio_pmd_ctrl ctrl;
+ int dlen[1];
+ int ret;
+
+ ctrl.hdr.class = VIRTIO_NET_CTRL_RX;
+ ctrl.hdr.cmd = VIRTIO_NET_CTRL_RX_PROMISC;
+ ctrl.data[0] = 1;
+ dlen[0] = 1;
+
+ ret = virtio_send_command(hw->cvq, &ctrl, dlen, 1);
+
+ if (ret)
+ PMD_INIT_LOG(ERR, "Failed to enable promisc");
+}
+
+static void
+virtio_dev_promiscuous_disable(struct rte_eth_dev *dev)
+{
+ struct virtio_hw *hw
+ = VIRTIO_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+ struct virtio_pmd_ctrl ctrl;
+ int dlen[1];
+ int ret;
+
+ ctrl.hdr.class = VIRTIO_NET_CTRL_RX;
+ ctrl.hdr.cmd = VIRTIO_NET_CTRL_RX_PROMISC;
+ ctrl.data[0] = 0;
+ dlen[0] = 1;
+
+ ret = virtio_send_command(hw->cvq, &ctrl, dlen, 1);
+
+ if (ret)
+ PMD_INIT_LOG(ERR, "Failed to disable promisc");
+}
+
+static void
+virtio_dev_allmulticast_enable(struct rte_eth_dev *dev)
+{
+ struct virtio_hw *hw
+ = VIRTIO_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+ struct virtio_pmd_ctrl ctrl;
+ int dlen[1];
+ int ret;
+
+ ctrl.hdr.class = VIRTIO_NET_CTRL_RX;
+ ctrl.hdr.cmd = VIRTIO_NET_CTRL_RX_ALLMULTI;
+ ctrl.data[0] = 1;
+ dlen[0] = 1;
+
+ ret = virtio_send_command(hw->cvq, &ctrl, dlen, 1);
+
+ if (ret)
+ PMD_INIT_LOG(ERR, "Failed to enable allmulticast");
+}
+
+static void
+virtio_dev_allmulticast_disable(struct rte_eth_dev *dev)
+{
+ struct virtio_hw *hw
+ = VIRTIO_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+ struct virtio_pmd_ctrl ctrl;
+ int dlen[1];
+ int ret;
+
+ ctrl.hdr.class = VIRTIO_NET_CTRL_RX;
+ ctrl.hdr.cmd = VIRTIO_NET_CTRL_RX_ALLMULTI;
+ ctrl.data[0] = 0;
+ dlen[0] = 1;
+
+ ret = virtio_send_command(hw->cvq, &ctrl, dlen, 1);
+
+ if (ret)
+ PMD_INIT_LOG(ERR, "Failed to disable allmulticast");
+}
+
/*
* dev_ops for virtio, bare necessities for basic operation
*/
@@ -411,6 +495,10 @@ static struct eth_dev_ops virtio_eth_dev_ops = {
.dev_start = virtio_dev_start,
.dev_stop= virtio_dev_stop,
.dev_close = virtio_dev_close,
+ .promiscuous_enable = virtio_dev_promiscuous_enable,
+ .promiscuous_disable = virtio_dev_promiscuous_disable,
+ .allmulticast_enable = virtio_dev_allmulticast_enable,
+ .allmulticast_disable= virtio_dev_allmulticast_disable,
.dev_infos_get = virtio_dev_info_get,
.stats_get = virtio_dev_stats_get,
@@ -561,7 +649,7 @@ virtio_negotiate_features(struct virtio_hw *hw)
{
uint32_t host_features, mask;
- mask = VIRTIO_NET_F_CTRL_RX | VIRTIO_NET_F_CTRL_VLAN;
+ mask = VIRTIO_NET_F_CTRL_VLAN;
mask |= VIRTIO_NET_F_CSUM | VIRTIO_NET_F_GUEST_CSUM;
/* TSO and LRO are only available when their corresponding
--
1.8.4.2
[dpdk-dev] [PATCH v3 5/5] vhost: enable promisc mode and multicast
This is to enable user space vhost receiving and forwarding broadcast
and multicast packets: Use new option in command line to enable promisc mode;
Enable 2 bits in VMDQ RX mode: ETH_VMDQ_ACCEPT_BROADCAST and
ETH_VMDQ_ACCEPT_MULTICAST.
Signed-off-by: Changchun Ouyang
---
examples/vhost/main.c | 24 +---
lib/librte_vhost/virtio-net.c | 4 +++-
2 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/examples/vhost/main.c b/examples/vhost/main.c
index 57ef464..07104a0 100644
--- a/examples/vhost/main.c
+++ b/examples/vhost/main.c
@@ -161,6 +161,9 @@
/* mask of enabled ports */
static uint32_t enabled_port_mask = 0;
+/* Promiscuous mode */
+static uint32_t promiscuous;
+
/*Number of switching cores enabled*/
static uint32_t num_switching_cores = 0;
@@ -364,13 +367,15 @@ static inline int
get_eth_conf(struct rte_eth_conf *eth_conf, uint32_t num_devices)
{
struct rte_eth_vmdq_rx_conf conf;
+ struct rte_eth_vmdq_rx_conf *def_conf =
+ &vmdq_conf_default.rx_adv_conf.vmdq_rx_conf;
unsigned i;
memset(&conf, 0, sizeof(conf));
conf.nb_queue_pools = (enum rte_eth_nb_pools)num_devices;
conf.nb_pool_maps = num_devices;
- conf.enable_loop_back =
- vmdq_conf_default.rx_adv_conf.vmdq_rx_conf.enable_loop_back;
+ conf.enable_loop_back = def_conf->enable_loop_back;
+ conf.rx_mode = def_conf->rx_mode;
for (i = 0; i < conf.nb_pool_maps; i++) {
conf.pool_map[i].vlan_id = vlan_tags[ i ];
@@ -468,6 +473,9 @@ port_init(uint8_t port)
return retval;
}
+ if (promiscuous)
+ rte_eth_promiscuous_enable(port);
+
rte_eth_macaddr_get(port, &vmdq_ports_eth_addr[port]);
RTE_LOG(INFO, VHOST_PORT, "Max virtio devices supported: %u\n",
num_devices);
RTE_LOG(INFO, VHOST_PORT, "Port %u MAC: %02"PRIx8" %02"PRIx8" %02"PRIx8
@@ -598,7 +606,8 @@ us_vhost_parse_args(int argc, char **argv)
};
/* Parse command line */
- while ((opt = getopt_long(argc, argv, "p:",long_option, &option_index))
!= EOF) {
+ while ((opt = getopt_long(argc, argv, "p:P",
+ long_option, &option_index)) != EOF) {
switch (opt) {
/* Portmask */
case 'p':
@@ -610,6 +619,15 @@ us_vhost_parse_args(int argc, char **argv)
}
break;
+ case 'P':
+ promiscuous = 1;
+ vmdq_conf_default.rx_adv_conf.vmdq_rx_conf.rx_mode =
+ ETH_VMDQ_ACCEPT_BROADCAST |
+ ETH_VMDQ_ACCEPT_MULTICAST;
+ rte_vhost_feature_enable(1ULL << VIRTIO_NET_F_CTRL_RX);
+
+ break;
+
case 0:
/* Enable/disable vm2vm comms. */
if (!strncmp(long_option[option_index].name, "vm2vm",
diff --git a/lib/librte_vhost/virtio-net.c b/lib/librte_vhost/virtio-net.c
index 8015dd8..2698a99 100644
--- a/lib/librte_vhost/virtio-net.c
+++ b/lib/librte_vhost/virtio-net.c
@@ -68,7 +68,9 @@ static struct virtio_net_device_ops const *notify_ops;
static struct virtio_net_config_ll *ll_root;
/* Features supported by this application. RX merge buffers are enabled by
default. */
-#define VHOST_SUPPORTED_FEATURES (1ULL << VIRTIO_NET_F_MRG_RXBUF)
+#define VHOST_SUPPORTED_FEATURES ((1ULL << VIRTIO_NET_F_MRG_RXBUF) | \
+ (1ULL << VIRTIO_NET_F_CTRL_RX))
+
static uint64_t VHOST_FEATURES = VHOST_SUPPORTED_FEATURES;
/* Line size for reading maps file. */
--
1.8.4.2
[dpdk-dev] [PATCH v2 1/3] ethdev: define ctrl_pkt filter type and its structure
Hi, Thomas
Thanks for your comments
Jingjing
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Friday, October 31, 2014 6:47 AM
> To: Wu, Jingjing
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 1/3] ethdev: define ctrl_pkt filter type
> and its structure
>
> 2014-10-22 16:19, Jingjing Wu:
> > +/**
> > + * Define all structures for Control Packet Filter type corresponding with
> specific operations.
> > + */
>
> Please explain what is a control packet.
A control element in Fortville can be used to receive control packets and
control other switching elements. Control packet filter can filter control
packet (such as LLDP) to different queues in receive and identify the switch
element that should process the packets in transmit.
At the same time, we also can use this filter to route non-control packets to
queue or other engine by filtering mac and ether_type. The name "control packet
filter" comes from Fortville.
>
> > +
> > +#define RTE_CONTROL_PACKET_FLAGS_IGNORE_MAC0x0001
> > +#define RTE_CONTROL_PACKET_FLAGS_DROP 0x0002
> > +#define RTE_CONTROL_PACKET_FLAGS_TO_QUEUE 0x0004
> > +#define RTE_CONTROL_PACKET_FLAGS_TX0x0008
> > +#define RTE_CONTROL_PACKET_FLAGS_RX0x
>
> Flag RX is 0?
Yes, RX is default value. Maybe it need to be removed.
>
> > +/**
> > + * A structure used to define the control packet filter entry
> > + * to support RTE_ETH_FILTER_CTRL_PKT with RTE_ETH_FILTER_ADD
> > + * and RTE_ETH_FILTER_DELETE operations.
> > + */
> > +struct rte_ctrl_pkt_filter {
> > + struct ether_addr mac_addr; /**< mac address to match. */
> > + uint16_t ether_type; /**< ether type to match */
> > + uint16_t flags; /**< options for filter's behavior*/
> > + uint16_t dest_id; /**< destination vsi id or pool id*/
>
> vsi id and pool id cannot be understood in a generic context.
> Please explain what you mean and why queue is not enough.
If queue is not specified, dest_id defines which element (vsi) will get the
packet.
If queue is specified, the queue need belong to the destination element.
>
> > + uint16_t queue; /**< queue assign to if TO QUEUE flag is
> > set
> */
>
> TO QUEUE is not defined. Is it really needed?
>
TO QUEUE is just the flag RTE_CONTROL_PACKET_FLAGS_TO_QUEUE above.
> Thanks
> --
> Thomas
[dpdk-dev] [PATCH v2 0/2] compatibility fallback and replacement of kernel function invoking
The related kernel function is: - pci_num_vf, it is introduced from upstream linux-2.6.34. For RHEL6's kernel, it is defined from RHEL6.0. - kstrtoul, this function is united kernel API to replace strict_strtoul in the furture. It is introduced from linux-2.6.39. For RHEL6, it is defined from RHEL6.4. This patchset do some compatiblity work for these two functions, and replace strict_strtoul which is depleted from linux-3.18. v2: Merge these two patch in one patchset. Compatible with old kernel for kstrtoul. Compatible with RHEL6 for pci_num_vf. Jincheng Miao (2): igb_uio: compatible with upstream longterm kernel and RHEL6 eal: replace strict_strtoul with kstrtoul lib/librte_eal/linuxapp/igb_uio/compat.h| 12 +++- lib/librte_eal/linuxapp/igb_uio/igb_uio.c |4 ++-- lib/librte_eal/linuxapp/kni/kni_vhost.c |2 +- lib/librte_eal/linuxapp/xen_dom0/dom0_mm_misc.c |2 +- 4 files changed, 15 insertions(+), 5 deletions(-)
[dpdk-dev] [PATCH v2 1/2] igb_uio: compatible with upstream longterm kernel and RHEL6
Function pci_num_vf() is introduced from upstream linux-2.6.34. So
this patch make compatible with longterm kernel linux-2.6.32.63.
For RHEL6's kernel, although it is based on linux-2.6.32, it has
pci_num_vf() implementation. As the same with commit 11ba0426,
pci_num_vf() is defined from RHEL6. So we should check the macro
RHEL_RELEASE_CODE to consider this situation.
Signed-off-by: Jincheng Miao
---
lib/librte_eal/linuxapp/igb_uio/compat.h |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/lib/librte_eal/linuxapp/igb_uio/compat.h
b/lib/librte_eal/linuxapp/igb_uio/compat.h
index 676fa1b..0639386 100644
--- a/lib/librte_eal/linuxapp/igb_uio/compat.h
+++ b/lib/librte_eal/linuxapp/igb_uio/compat.h
@@ -21,7 +21,9 @@
#endif
#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 34) && \
- !defined(CONFIG_PCI_IOV)
+ (!(defined(RHEL_RELEASE_CODE) && \
+ RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(6, 0) && \
+ defined(CONFIG_PCI_IOV)))
static int pci_num_vf(struct pci_dev *dev)
{
--
1.7.1
[dpdk-dev] [PATCH v2 2/2] eal: replace strict_strtoul with kstrtoul
>From upstream kernel commit 3db2e9cd, strict_strto* serial functions are removed. So that we should directly used kstrtoul instead. For compatible with old kernel and RHEL6, add some logic to igb_uio/compat.h, same as what we do for pci_num_vf(). Signed-off-by: Jincheng Miao --- lib/librte_eal/linuxapp/igb_uio/compat.h|8 lib/librte_eal/linuxapp/igb_uio/igb_uio.c |4 ++-- lib/librte_eal/linuxapp/kni/kni_vhost.c |2 +- lib/librte_eal/linuxapp/xen_dom0/dom0_mm_misc.c |2 +- 4 files changed, 12 insertions(+), 4 deletions(-) diff --git a/lib/librte_eal/linuxapp/igb_uio/compat.h b/lib/librte_eal/linuxapp/igb_uio/compat.h index 0639386..403c529 100644 --- a/lib/librte_eal/linuxapp/igb_uio/compat.h +++ b/lib/librte_eal/linuxapp/igb_uio/compat.h @@ -45,6 +45,14 @@ static int pci_num_vf(struct pci_dev *dev) #endif /* < 2.6.34 */ +#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 39) && \ +(!(defined(RHEL_RELEASE_CODE) && \ + RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(6, 4))) + +#define kstrtoul strict_strtoul + +#endif /* < 2.6.39 */ + #if LINUX_VERSION_CODE < KERNEL_VERSION(3, 3, 0) && \ (!(defined(RHEL_RELEASE_CODE) && \ RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(6, 3))) diff --git a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c index d1ca26e..47ff2f3 100644 --- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c +++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c @@ -83,7 +83,7 @@ store_max_vfs(struct device *dev, struct device_attribute *attr, unsigned long max_vfs; struct pci_dev *pdev = container_of(dev, struct pci_dev, dev); - if (0 != strict_strtoul(buf, 0, &max_vfs)) + if (0 != kstrtoul(buf, 0, &max_vfs)) return -EINVAL; if (0 == max_vfs) @@ -174,7 +174,7 @@ store_max_read_request_size(struct device *dev, unsigned long size = 0; int ret; - if (strict_strtoul(buf, 0, &size) != 0) + if (0 != kstrtoul(buf, 0, &size)) return -EINVAL; ret = pcie_set_readrq(pci_dev, (int)size); diff --git a/lib/librte_eal/linuxapp/kni/kni_vhost.c b/lib/librte_eal/linuxapp/kni/kni_vhost.c index fe512c2..ba0c1ac 100644 --- a/lib/librte_eal/linuxapp/kni/kni_vhost.c +++ b/lib/librte_eal/linuxapp/kni/kni_vhost.c @@ -739,7 +739,7 @@ set_sock_en(struct device *dev, struct device_attribute *attr, unsigned long en; int err = 0; - if (0 != strict_strtoul(buf, 0, &en)) + if (0 != kstrtoul(buf, 0, &en)) return -EINVAL; if (en) diff --git a/lib/librte_eal/linuxapp/xen_dom0/dom0_mm_misc.c b/lib/librte_eal/linuxapp/xen_dom0/dom0_mm_misc.c index dfb271d..8a3727d 100644 --- a/lib/librte_eal/linuxapp/xen_dom0/dom0_mm_misc.c +++ b/lib/librte_eal/linuxapp/xen_dom0/dom0_mm_misc.c @@ -123,7 +123,7 @@ store_memsize(struct device *dev, struct device_attribute *attr, int err = 0; unsigned long mem_size; - if (0 != strict_strtoul(buf, 0, &mem_size)) + if (0 != kstrtoul(buf, 0, &mem_size)) return -EINVAL; mutex_lock(&dom0_dev.data_lock); -- 1.7.1
[dpdk-dev] flow director - perfect match filter
Hi, after setting filter.l4type to RTE_FDIR_L4TYPE_UDP, packets that were supposed to be matched were (finally!) matched, so I am more than grateful! Thank you!!! What do you mean by 'sending an IP packet'? Is ICMP an IP packet (has no layer 4), or? Once again, thank you! BR, Newman P. On Fri, Oct 31, 2014 at 1:48 AM, Wu, Jingjing wrote: > Hi, Poborsky > > Please try sending an IP packet (not UDP, TCP or SCTP). > > Or you can try to set filter.l4type = RTE_FDIR_L4TYPE_TCP when adding a > filter. > > I guess it is because the NIC already classify you packet as TCP one. > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Newman Poborsky > > Sent: Thursday, October 30, 2014 11:18 PM > > To: dev at dpdk.org > > Subject: [dpdk-dev] flow director - perfect match filter > > > > Hi, > > > > I'm not sure this is the right place to post a question like this, but > I've been > > stuck with the same problem for days now. > > > > I'm trying to use flow director perfect match filters and so far I > haven't been > > able to get it working. I have tried writing my own simple app (based on > given > > examples) and I tried adding filter using something as simple as: > > > > //setting the mask to watch for src IP > > memset(&fdir_masks, 0x00, sizeof(struct rte_fdir_masks)); > > fdir_masks.src_ipv4_mask = 0x; ret = > > rte_eth_dev_fdir_set_masks(portid, &fdir_masks); //adding filter > > memset(&filter, 0, sizeof(struct rte_fdir_filter)); > filter.ip_src.ipv4_addr = > > htonl(ipv4_src); filter.l4type = RTE_FDIR_L4TYPE_NONE; filter.iptype = > > RTE_FDIR_IPTYPE_IPV4; ret = > > rte_eth_dev_fdir_add_perfect_filter(portid,&filter,3,queue,0); > > ... > > > > > > After running this code and using using tcpreplay to push traffic to > interface, I > > get all the misses in the stats and no matches. As far as I understand, > to > > match only on src IP, all rte_fdir_filter elements should be set to 0, > and only > > src_ip should be masked (with 1's). > > > > After this I tried running testpmd application but also no luck. The > commands > > I used are: > > set_masks_filter 0 only_ip_flow 0 src_mask 0x 0x dst_mask > > 0x 0x flexbytes 0 vlan_id 0 vlan_prio 0 add_perfect_filter 0 > ip > > src 10.10.10.10 0 dst 0.0.0.0 0 flexbytes 0 vlan 0 queue 1 soft 3 > > > > Filter is added but after sending packets to this interface, I only see > misses in > > stats. > > > > What I am doing wrong? I've read the docs and looked at API reference > but > > didn't find anything that could help me. > > > > Configuring flow director filter using ethtool and sending same packets > > results in matches, so packets I'm sending should be matched. > > > > Thank you for any help! > > > > Newman P. >
[dpdk-dev] DPDK on Xen Dom-U hangs during hugepage setup
Hello, Xen does not support hugepages, so you have to use a kernel module called rte_dom0_mm. The instructions are in the getting started guide in the seccion 2.3.3. If you manage to execute any example please tell me, because I am stuck during the execution of the examples after configuring the environment. El 30/10/14 a las 19:15, Kiran KN escribi?: > Hello, > > I am trying to bring up DPDK on Xen Dom-U. > > Have followed all the steps in DPDK programmers guide in section 14.3. > > However, when I try to run testpmd or any other example application, it is > getting stuck during hugepage setup. > > It hangs after the print "EAL: Setting up memory..." > > Has anyone faced similar issue before? > > Thanks, > Kiran > >
[dpdk-dev] [PATCH v2 1/3] ethdev: define ctrl_pkt filter type and its structure
Hi Jingjing,
I'm sorry, but your explanations are not sufficient.
Please keep in mind that the user of the API don't know i40e internals.
2014-10-31 07:05, Wu, Jingjing:
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > 2014-10-22 16:19, Jingjing Wu:
> > > +/**
> > > + * Define all structures for Control Packet Filter type corresponding
> > > with
> > specific operations.
> > > + */
> >
> > Please explain what is a control packet.
>
> A control element in Fortville can be used to receive control packets and
> control other switching elements. Control packet filter can filter control
> packet (such as LLDP) to different queues in receive and identify the switch
> element that should process the packets in transmit.
> At the same time, we also can use this filter to route non-control packets to
> queue or other engine by filtering mac and ether_type. The name "control
> packet filter" comes from Fortville.
I still don't know what is a control packet.
> > > +#define RTE_CONTROL_PACKET_FLAGS_IGNORE_MAC0x0001
> > > +#define RTE_CONTROL_PACKET_FLAGS_DROP 0x0002
> > > +#define RTE_CONTROL_PACKET_FLAGS_TO_QUEUE 0x0004
> > > +#define RTE_CONTROL_PACKET_FLAGS_TX0x0008
> > > +#define RTE_CONTROL_PACKET_FLAGS_RX0x
> >
> > Flag RX is 0?
>
> Yes, RX is default value. Maybe it need to be removed.
No, it doesn't need to be removed. But a flag must not be 0.
0 means none.
It's impossible to disable this flag.
Moreover, you should comment each flag.
> > > +/**
> > > + * A structure used to define the control packet filter entry
> > > + * to support RTE_ETH_FILTER_CTRL_PKT with RTE_ETH_FILTER_ADD
> > > + * and RTE_ETH_FILTER_DELETE operations.
> > > + */
> > > +struct rte_ctrl_pkt_filter {
> > > + struct ether_addr mac_addr; /**< mac address to match. */
> > > + uint16_t ether_type; /**< ether type to match */
> > > + uint16_t flags; /**< options for filter's behavior*/
> > > + uint16_t dest_id; /**< destination vsi id or pool id*/
> >
> > vsi id and pool id cannot be understood in a generic context.
> > Please explain what you mean and why queue is not enough.
>
> If queue is not specified, dest_id defines which element (vsi) will get the
> packet.
> If queue is specified, the queue need belong to the destination element.
You really need to define what is a vsi id and pool id. These notions are not
known in the API layer.
> > > + uint16_t queue; /**< queue assign to if TO QUEUE flag is
> > > set
> > */
> >
> > TO QUEUE is not defined. Is it really needed?
> >
> TO QUEUE is just the flag RTE_CONTROL_PACKET_FLAGS_TO_QUEUE above.
OK, please use the same wording or users will get lost.
--
Thomas
[dpdk-dev] [PATCH v3 7/8] ethdev: support of multiple sizes of redirection table
2014-10-31 01:39, Zhang, Helin: > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > 2014-10-28 00:37, Zhang, Helin: > > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > > 2014-10-22 19:53, Helin Zhang: > > > > > +#define RTE_BIT_WIDTH_64 (CHAR_BIT * sizeof(uint64_t)) > > > > > > > > How can it be different of 64? > > > > Using 64 would be simpler to understand than RTE_BIT_WIDTH_64. > > > > > > > > > + uint8_t reta[RTE_BIT_WIDTH_64]; /**< 64 redirection table > > > > > entries. */ > > > We always try to use macro in code to replace numeric, this can get the > > > numeric > > more understandable. > > > > How bit width 64 is more understandable than 64? > > Especially when you count a number of entries, not a bit width. > > RETA_ENTRIES_MAX would be more understandable. > > Renaming the macro is needed. I plan to rename it to RTE_RETA_GROUP_SIZE, > as it is a group of 64 reta entries, but not the maximum number of valid > entries. OK, good. -- Thomas
[dpdk-dev] [PATCH] igb_uio: fix build for longterm kernel 2.6.32.63
Hi Jincheng,
2014-10-31 09:54, Jincheng Miao:
> This patch will make RHEL6 build failed.
>
> The root cause is that RHEL-based kernel is slightly different with
> upstream kernel.
> It has some functions (pci_num_vf, kstrtoul, etc) which don't exist in
> upstream longterm kernel.
Yes it seems that the functions are stub-defined in RHEL if CONFIG_PCI_IOV
is not defined.
> For better compatibility, IMHO it is distinguishing RHEL-based kernel
> and upstream one.
Yes we have to handle the RedHat difference.
> Using macro like:
> ```
> #if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 34) && \
> !(defined(RHEL_RELEASE_CODE) && RHEL_RELEASE_CODE >=
> RHEL_RELEASE_VERSION(6, 3))
>
> static int pci_num_vf(struct pci_dev *dev)
> {
> ```
>
> But this is RHEL-specified fix. For other distros, if they have some
> problem, we should hack it in the same way.
>
> Thanks and regards,
> Jincheng Miao
>
>
> On 10/30/2014 04:18 PM, Jincheng Miao wrote:
> > There is a logical error in igb_uio/compat.h when define pci_num_vf().
> > Only CONFIG_PCI_IOV enabled, this function could be defined.
> >
> > This patch fix the following error for linux-2.6.32.63:
> > CC [M]
> > /root/dpdk-source/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.o
> > /root/dpdk-source/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.c: In
> > function ?show_max_vfs?:
> > /root/dpdk-source/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.c:75:
> > error: implicit declaration of function ?pci_num_vf?
> >
> > Signed-off-by: Jincheng Miao
> > ---
> > lib/librte_eal/linuxapp/igb_uio/compat.h |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/lib/librte_eal/linuxapp/igb_uio/compat.h
> > b/lib/librte_eal/linuxapp/igb_uio/compat.h
> > index 676fa1b..0af0cae 100644
> > --- a/lib/librte_eal/linuxapp/igb_uio/compat.h
> > +++ b/lib/librte_eal/linuxapp/igb_uio/compat.h
> > @@ -21,7 +21,7 @@
> > #endif
> >
> > #if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 34) && \
> > - !defined(CONFIG_PCI_IOV)
> > + defined(CONFIG_PCI_IOV)
> >
> > static int pci_num_vf(struct pci_dev *dev)
> > {
[dpdk-dev] [PATCH] mk: --no-as-needed by default for linux exec-env
> From: Neil Horman [mailto:nhorman at tuxdriver.com] > Subject: Re: [dpdk-dev] [PATCH] mk: --no-as-needed by default for linux > exec-env > > Thank you, it does, though it raises an intersting question. By flipping that > switch around you definately solve the problem at hand, but you don't really > close the bug completely. The problem arises because librte_eal doesn't add > a DT_NEEDED entry for librte_mempool despite the fact that it references > symbols in that library. It does this because we don't explicitly link with - > lrte_mempool when we build librte_eal. Normally thats ok, because libraries > don't load on their own, and every application that needs to link rte_eal also > needs to link rte_mempool, so the symbols happen to resolve properly. But > that may not always be the case for all libraries. It gives rise to the > argument > that building a single large library may be preferable, as we might otherwise > need to create dependency chains where libraries fully specify their > dependencies in their DT_NEEDED sections > > Neil > That is a better explanation of what is really going on :) , and it does rise an interesting question. In that regard, there is an open RFC to discuss how to improve the current build system. http://dpdk.org/ml/archives/dev/2014-October/007389.html Thanks, Sergio
[dpdk-dev] [PATCH v4 0/8] support of multiple sizes of redirection table
As e1000, ixgbe and i40e hardware use different sizes of redirection table in PF or VF, ethdev and PMDs need to be reworked to support multiple sizes of that table. In addition, commands in testpmd also need to be reworked to support these changes. v2 changes: * Reorganized the patches. * Added code style fixes. * Added support of reta updating/querying in i40e VF. v3 changes: * Reorganized the patch set. * Added returning default RX/TX configurations in VF (igb/ixgbe/i40e), as the patch set of it for PF has been accepted recently. v4 changes: * Renamed RTE_BIT_WIDTH_64 to RTE_RETA_GROUP_SIZE. * Added more comments to rte_eth_dev_rss_reta_update() and rte_eth_dev_rss_reta_query(). Helin Zhang (8): app/testpmd: code style fix i40evf: code style fix i40e: support of setting hash lookup table size igb: implement ops of 'dev_infos_get' for PF and VF respectively ixgbe: implement ops of 'dev_infos_get' for PF and VF respectively i40e: rework of ops of 'dev_infos_get' for both PF and VF ethdev: support of multiple sizes of redirection table i40evf: support of updating/querying redirection table app/test-pmd/cmdline.c | 166 + app/test-pmd/config.c| 37 --- app/test-pmd/testpmd.h | 4 +- lib/librte_ether/rte_ethdev.c| 116 lib/librte_ether/rte_ethdev.h| 45 +--- lib/librte_pmd_e1000/igb_ethdev.c| 170 +++--- lib/librte_pmd_i40e/i40e_ethdev.c| 123 -- lib/librte_pmd_i40e/i40e_ethdev.h| 25 - lib/librte_pmd_i40e/i40e_ethdev_vf.c | 124 +- lib/librte_pmd_ixgbe/ixgbe_ethdev.c | 198 ++- 10 files changed, 689 insertions(+), 319 deletions(-) -- 1.8.1.4
[dpdk-dev] [PATCH v4 2/8] i40evf: code style fix
Fix of several code style issues. Signed-off-by: Helin Zhang --- lib/librte_pmd_i40e/i40e_ethdev_vf.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/lib/librte_pmd_i40e/i40e_ethdev_vf.c b/lib/librte_pmd_i40e/i40e_ethdev_vf.c index fa838e6..5b8a3bf 100644 --- a/lib/librte_pmd_i40e/i40e_ethdev_vf.c +++ b/lib/librte_pmd_i40e/i40e_ethdev_vf.c @@ -131,10 +131,14 @@ static int i40evf_dev_rss_hash_update(struct rte_eth_dev *dev, struct rte_eth_rss_conf *rss_conf); static int i40evf_dev_rss_hash_conf_get(struct rte_eth_dev *dev, struct rte_eth_rss_conf *rss_conf); -static int i40evf_dev_rx_queue_start(struct rte_eth_dev *, uint16_t); -static int i40evf_dev_rx_queue_stop(struct rte_eth_dev *, uint16_t); -static int i40evf_dev_tx_queue_start(struct rte_eth_dev *, uint16_t); -static int i40evf_dev_tx_queue_stop(struct rte_eth_dev *, uint16_t); +static int i40evf_dev_rx_queue_start(struct rte_eth_dev *dev, +uint16_t rx_queue_id); +static int i40evf_dev_rx_queue_stop(struct rte_eth_dev *dev, + uint16_t rx_queue_id); +static int i40evf_dev_tx_queue_start(struct rte_eth_dev *dev, +uint16_t tx_queue_id); +static int i40evf_dev_tx_queue_stop(struct rte_eth_dev *dev, + uint16_t tx_queue_id); /* Default hash key buffer for RSS */ static uint32_t rss_key_default[I40E_VFQF_HKEY_MAX_INDEX + 1]; -- 1.8.1.4
[dpdk-dev] [PATCH v4 1/8] app/testpmd: code style fix
Fix of several code style issues.
Signed-off-by: Helin Zhang
---
app/test-pmd/cmdline.c | 28 +++-
app/test-pmd/config.c | 2 +-
2 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 4c3fc76..daba286 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -1602,7 +1602,7 @@ parse_reta_config(const char *str, struct
rte_eth_rss_reta *reta_conf)
nb_queue = (uint8_t)int_fld[FLD_QUEUE];
if (hash_index >= ETH_RSS_RETA_NUM_ENTRIES) {
- printf("Invalid RETA hash index=%d",hash_index);
+ printf("Invalid RETA hash index=%d", hash_index);
return -1;
}
@@ -1619,22 +1619,24 @@ parse_reta_config(const char *str, struct
rte_eth_rss_reta *reta_conf)
static void
cmd_set_rss_reta_parsed(void *parsed_result,
- __attribute__((unused)) struct cmdline *cl,
- __attribute__((unused)) void *data)
+ __attribute__((unused)) struct cmdline *cl,
+ __attribute__((unused)) void *data)
{
int ret;
struct rte_eth_rss_reta reta_conf;
struct cmd_config_rss_reta *res = parsed_result;
- memset(&reta_conf,0,sizeof(struct rte_eth_rss_reta));
+ memset(&reta_conf, 0, sizeof(struct rte_eth_rss_reta));
if (!strcmp(res->list_name, "reta")) {
if (parse_reta_config(res->list_of_items, &reta_conf)) {
- printf("Invalid RSS Redirection Table config
entered\n");
+ printf("Invalid RSS Redirection Table config "
+ "entered\n");
return;
}
ret = rte_eth_dev_rss_reta_update(res->port_id, &reta_conf);
if (ret != 0)
- printf("Bad redirection table parameter, return code =
%d \n",ret);
+ printf("Bad redirection table parameter, "
+ "return code = %d \n", ret);
}
}
@@ -1696,19 +1698,19 @@ static void cmd_showport_reta_parsed(void
*parsed_result,
}
cmdline_parse_token_string_t cmd_showport_reta_show =
-TOKEN_STRING_INITIALIZER(struct cmd_showport_reta, show, "show");
+ TOKEN_STRING_INITIALIZER(struct cmd_showport_reta, show, "show");
cmdline_parse_token_string_t cmd_showport_reta_port =
-TOKEN_STRING_INITIALIZER(struct cmd_showport_reta, port, "port");
+ TOKEN_STRING_INITIALIZER(struct cmd_showport_reta, port, "port");
cmdline_parse_token_num_t cmd_showport_reta_port_id =
-TOKEN_NUM_INITIALIZER(struct cmd_showport_reta, port_id, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_showport_reta, port_id, UINT8);
cmdline_parse_token_string_t cmd_showport_reta_rss =
-TOKEN_STRING_INITIALIZER(struct cmd_showport_reta, rss, "rss");
+ TOKEN_STRING_INITIALIZER(struct cmd_showport_reta, rss, "rss");
cmdline_parse_token_string_t cmd_showport_reta_reta =
-TOKEN_STRING_INITIALIZER(struct cmd_showport_reta, reta, "reta");
+ TOKEN_STRING_INITIALIZER(struct cmd_showport_reta, reta, "reta");
cmdline_parse_token_num_t cmd_showport_reta_mask_lo =
-TOKEN_NUM_INITIALIZER(struct cmd_showport_reta,mask_lo,UINT64);
+ TOKEN_NUM_INITIALIZER(struct cmd_showport_reta, mask_lo, UINT64);
cmdline_parse_token_num_t cmd_showport_reta_mask_hi =
- TOKEN_NUM_INITIALIZER(struct cmd_showport_reta,mask_hi,UINT64);
+ TOKEN_NUM_INITIALIZER(struct cmd_showport_reta, mask_hi, UINT64);
cmdline_parse_inst_t cmd_showport_reta = {
.f = cmd_showport_reta_parsed,
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 9bc08f4..73afcf5 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -764,7 +764,7 @@ rxtx_config_display(void)
void
port_rss_reta_info(portid_t port_id,struct rte_eth_rss_reta *reta_conf)
{
- uint8_t i,j;
+ uint8_t i, j;
int ret;
if (port_id_is_invalid(port_id))
--
1.8.1.4
[dpdk-dev] [PATCH v4 3/8] i40e: support of setting hash lookup table size
Add support of setting hash lookup table size according
to the hardawre capability.
Signed-off-by: Helin Zhang
---
lib/librte_ether/rte_ethdev.h | 3 +++
lib/librte_pmd_i40e/i40e_ethdev.c | 14 +-
lib/librte_pmd_i40e/i40e_ethdev.h | 1 +
3 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 8bf274d..cdfa579 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -430,6 +430,9 @@ struct rte_eth_rss_conf {
/* Definitions used for redirection table entry size */
#define ETH_RSS_RETA_NUM_ENTRIES 128
#define ETH_RSS_RETA_MAX_QUEUE 16
+#define ETH_RSS_RETA_SIZE_64 64
+#define ETH_RSS_RETA_SIZE_128 128
+#define ETH_RSS_RETA_SIZE_512 512
/* Definitions used for VMDQ and DCB functionality */
#define ETH_VMDQ_MAX_VLAN_FILTERS 64 /**< Maximum nb. of VMDQ vlan filters.
*/
diff --git a/lib/librte_pmd_i40e/i40e_ethdev.c
b/lib/librte_pmd_i40e/i40e_ethdev.c
index d768a08..0efbcd8 100644
--- a/lib/librte_pmd_i40e/i40e_ethdev.c
+++ b/lib/librte_pmd_i40e/i40e_ethdev.c
@@ -3081,7 +3081,19 @@ i40e_pf_setup(struct i40e_pf *pf)
/* Configure filter control */
memset(&settings, 0, sizeof(settings));
- settings.hash_lut_size = I40E_HASH_LUT_SIZE_128;
+ if (hw->func_caps.rss_table_size == ETH_RSS_RETA_SIZE_128)
+ settings.hash_lut_size = I40E_HASH_LUT_SIZE_128;
+ else if (hw->func_caps.rss_table_size == ETH_RSS_RETA_SIZE_512)
+ settings.hash_lut_size = I40E_HASH_LUT_SIZE_512;
+ else {
+ PMD_DRV_LOG(ERR, "Hash lookup table size (%u) not supported\n",
+ hw->func_caps.rss_table_size);
+ return I40E_ERR_PARAM;
+ }
+ PMD_DRV_LOG(INFO, "Hardware capability of hash lookup table "
+ "size: %u\n", hw->func_caps.rss_table_size);
+ pf->hash_lut_size = hw->func_caps.rss_table_size;
+
/* Enable ethtype and macvlan filters */
settings.enable_ethtype = TRUE;
settings.enable_macvlan = TRUE;
diff --git a/lib/librte_pmd_i40e/i40e_ethdev.h
b/lib/librte_pmd_i40e/i40e_ethdev.h
index e61d258..ce72720 100644
--- a/lib/librte_pmd_i40e/i40e_ethdev.h
+++ b/lib/librte_pmd_i40e/i40e_ethdev.h
@@ -260,6 +260,7 @@ struct i40e_pf {
uint16_t vmdq_nb_qps; /* The number of queue pairs of VMDq */
uint16_t vf_nb_qps; /* The number of queue pairs of VF */
uint16_t fdir_nb_qps; /* The number of queue pairs of Flow Director */
+ uint16_t hash_lut_size; /* The size of hash lookup table */
/* store VXLAN UDP ports */
uint16_t vxlan_ports[I40E_MAX_PF_UDP_OFFLOAD_PORTS];
--
1.8.1.4
[dpdk-dev] [PATCH v4 5/8] ixgbe: implement ops of 'dev_infos_get' for PF and VF respectively
As more and more information are different between PF
and VF, ops of 'dev_infos_get' has been implemented
respectively. In addition, returning redirection table
size has been supported in it.
Signed-off-by: Helin Zhang
---
lib/librte_pmd_ixgbe/ixgbe_ethdev.c | 90 +
1 file changed, 71 insertions(+), 19 deletions(-)
v2 changes:
* Added new function for ops of 'dev_infos_get' specifically for ixgbe VF.
v3 changes:
* Returning default RX/TX configurations has been added in ops of
'dev_infos_get' for VF, as it was added recently in that for PF.
diff --git a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
b/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
index c5e4b71..da140c8 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
+++ b/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
@@ -132,8 +132,9 @@ static int ixgbe_dev_queue_stats_mapping_set(struct
rte_eth_dev *eth_dev,
uint8_t stat_idx,
uint8_t is_rx);
static void ixgbe_dev_info_get(struct rte_eth_dev *dev,
- struct rte_eth_dev_info *dev_info);
-
+ struct rte_eth_dev_info *dev_info);
+static void ixgbevf_dev_info_get(struct rte_eth_dev *dev,
+struct rte_eth_dev_info *dev_info);
static int ixgbe_dev_mtu_set(struct rte_eth_dev *dev, uint16_t mtu);
static int ixgbe_vlan_filter_set(struct rte_eth_dev *dev,
@@ -391,7 +392,7 @@ static struct eth_dev_ops ixgbevf_eth_dev_ops = {
.stats_get= ixgbevf_dev_stats_get,
.stats_reset = ixgbevf_dev_stats_reset,
.dev_close= ixgbevf_dev_close,
- .dev_infos_get= ixgbe_dev_info_get,
+ .dev_infos_get= ixgbevf_dev_info_get,
.mtu_set = ixgbevf_dev_set_mtu,
.vlan_filter_set = ixgbevf_vlan_filter_set,
.vlan_strip_queue_set = ixgbevf_vlan_strip_queue_set,
@@ -1963,25 +1964,76 @@ ixgbe_dev_info_get(struct rte_eth_dev *dev, struct
rte_eth_dev_info *dev_info)
DEV_TX_OFFLOAD_SCTP_CKSUM;
dev_info->default_rxconf = (struct rte_eth_rxconf) {
- .rx_thresh = {
- .pthresh = IXGBE_DEFAULT_RX_PTHRESH,
- .hthresh = IXGBE_DEFAULT_RX_HTHRESH,
- .wthresh = IXGBE_DEFAULT_RX_WTHRESH,
- },
- .rx_free_thresh = IXGBE_DEFAULT_RX_FREE_THRESH,
- .rx_drop_en = 0,
+ .rx_thresh = {
+ .pthresh = IXGBE_DEFAULT_RX_PTHRESH,
+ .hthresh = IXGBE_DEFAULT_RX_HTHRESH,
+ .wthresh = IXGBE_DEFAULT_RX_WTHRESH,
+ },
+ .rx_free_thresh = IXGBE_DEFAULT_RX_FREE_THRESH,
+ .rx_drop_en = 0,
+ };
+
+ dev_info->default_txconf = (struct rte_eth_txconf) {
+ .tx_thresh = {
+ .pthresh = IXGBE_DEFAULT_TX_PTHRESH,
+ .hthresh = IXGBE_DEFAULT_TX_HTHRESH,
+ .wthresh = IXGBE_DEFAULT_TX_WTHRESH,
+ },
+ .tx_free_thresh = IXGBE_DEFAULT_TX_FREE_THRESH,
+ .tx_rs_thresh = IXGBE_DEFAULT_TX_RSBIT_THRESH,
+ .txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
+ ETH_TXQ_FLAGS_NOOFFLOADS,
};
+ dev_info->reta_size = ETH_RSS_RETA_SIZE_128;
+}
+static void
+ixgbevf_dev_info_get(struct rte_eth_dev *dev,
+struct rte_eth_dev_info *dev_info)
+{
+ struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+ dev_info->max_rx_queues = (uint16_t)hw->mac.max_rx_queues;
+ dev_info->max_tx_queues = (uint16_t)hw->mac.max_tx_queues;
+ dev_info->min_rx_bufsize = 1024; /* cf BSIZEPACKET in SRRCTL reg */
+ dev_info->max_rx_pktlen = 15872; /* includes CRC, cf MAXFRS reg */
+ dev_info->max_mac_addrs = hw->mac.num_rar_entries;
+ dev_info->max_hash_mac_addrs = IXGBE_VMDQ_NUM_UC_MAC;
+ dev_info->max_vfs = dev->pci_dev->max_vfs;
+ if (hw->mac.type == ixgbe_mac_82598EB)
+ dev_info->max_vmdq_pools = ETH_16_POOLS;
+ else
+ dev_info->max_vmdq_pools = ETH_64_POOLS;
+ dev_info->rx_offload_capa = DEV_RX_OFFLOAD_VLAN_STRIP |
+ DEV_RX_OFFLOAD_IPV4_CKSUM |
+ DEV_RX_OFFLOAD_UDP_CKSUM |
+ DEV_RX_OFFLOAD_TCP_CKSUM;
+ dev_info->tx_offload_capa = DEV_TX_OFFLOAD_VLAN_INSERT |
+ DEV_TX_OFFLOAD_IPV4_CKSUM |
+ DEV_TX_OFFLOAD_UDP_CKSUM |
+ DEV_TX_OFFLOAD_TCP_CKSUM |
+ DEV_TX_OFFLOAD_SCTP_CKSUM;
+
+ dev_info->default_rxconf = (struct rte_eth_rxconf) {
+ .rx_thresh = {
+
[dpdk-dev] [PATCH v4 7/8] ethdev: support of multiple sizes of redirection table
As 40G NIC supports different sizes (128/512/64 entries)
of redirection table from that (128 entries) of 1G and
10G NICs, support of multiple sizes of redirection table
is needed. It includes,
* Redefine 'struct rte_eth_rss_reta' in ethdev.
- To 'struct rte_eth_rss_reta_entry64' which contains 64
entries and 64 bits mask.
- Array of above new structure can be used for any number
of redirection table entries, as long as the number is
multiple of 64. This is quite flexible for the future
expanding of redirection table.
* Redefinition of relevant interfaces in ethdev.
- Interface of reta update has been redefined with new
parameters.
- Interface of reta query has been redefined with new
parameters.
* Rework of 1G PMD in igb.
- reta update has been reworked.
- reta query has been reworked.
* Rework of 10G PMD in ixgbe.
- reta update has been reworked.
- reta query has been reworked.
* Rework of 40G PMD (PF only) in i40e.
- reta update has been reworked.
- reta query has been reworked.
* Implement relevant commands in testpmd.
Signed-off-by: Helin Zhang
---
app/test-pmd/cmdline.c | 150 ++--
app/test-pmd/config.c | 37 +
app/test-pmd/testpmd.h | 4 +-
lib/librte_ether/rte_ethdev.c | 116 +---
lib/librte_ether/rte_ethdev.h | 40 ++
lib/librte_pmd_e1000/igb_ethdev.c | 109 +-
lib/librte_pmd_i40e/i40e_ethdev.c | 93 --
lib/librte_pmd_i40e/i40e_ethdev.h | 13 +++-
lib/librte_pmd_ixgbe/ixgbe_ethdev.c | 108 ++
9 files changed, 406 insertions(+), 264 deletions(-)
v2 changes:
* Put rework of updating/querying igb reta to a single patch.
* Put rework of updating/querying ixgbe reta to a single patch.
* Put rework of updating/querying i40e reta to a single patch.
v3 changes:
* Put all redefinitions of structures and interfaces into a
single patch.
* Put all reworks of igb/igbe/i40e of supporting multiple sizes
of reta into the same patch.
* Put all relevant testpmd reworks of supporting multiple sizes
of reta into the same patch.
v4 changes:
* Renamed RTE_BIT_WIDTH_64 to RTE_RETA_GROUP_SIZE.
* Added more comments to rte_eth_dev_rss_reta_update() and
rte_eth_dev_rss_reta_query().
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index daba286..cf252e1 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -59,6 +59,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -186,6 +187,11 @@ static void cmd_help_long_parsed(void *parsed_result,
"show port (info|stats|xstats|fdir|stat_qmap)
(port_id|all)\n"
"Display information for port_id, or all.\n\n"
+ "show port X rss reta (size) (mask0,mask1,...)\n"
+ "Display the rss redirection table entry indicated"
+ " by masks on port X. size is used to indicate the"
+ " hardware supported reta size\n\n"
+
"show port rss-hash [key]\n"
"Display the RSS hash functions and RSS hash key"
" of port X\n\n"
@@ -1562,11 +1568,13 @@ struct cmd_config_rss_reta {
};
static int
-parse_reta_config(const char *str, struct rte_eth_rss_reta *reta_conf)
+parse_reta_config(const char *str,
+ struct rte_eth_rss_reta_entry64 *reta_conf,
+ uint16_t nb_entries)
{
int i;
unsigned size;
- uint8_t hash_index;
+ uint16_t hash_index, idx, shift;
uint8_t nb_queue;
char s[256];
const char *p, *p0 = str;
@@ -1594,24 +1602,23 @@ parse_reta_config(const char *str, struct
rte_eth_rss_reta *reta_conf)
for (i = 0; i < _NUM_FLD; i++) {
errno = 0;
int_fld[i] = strtoul(str_fld[i], &end, 0);
- if (errno != 0 || end == str_fld[i] || int_fld[i] > 255)
+ if (errno != 0 || end == str_fld[i] ||
+ int_fld[i] > 65535)
return -1;
}
- hash_index = (uint8_t)int_fld[FLD_HASH_INDEX];
+ hash_index = (uint16_t)int_fld[FLD_HASH_INDEX];
nb_queue = (uint8_t)int_fld[FLD_QUEUE];
- if (hash_index >= ETH_RSS_RETA_NUM_ENTRIES) {
- printf("Invalid RETA hash index=%d", hash_index);
+ if (hash_index >= nb_entries) {
+ printf("Invalid RETA hash index=%d\n", hash_index);
return -1;
}
- if (hash_index < ETH_RSS_RETA_NUM_ENTRIES/2)
- reta_conf->mask_lo |= (1ULL << hash_index);
- else
- reta_conf->mask_hi |= (1ULL << (
[dpdk-dev] [PATCH v4 8/8] i40evf: support of updating/querying redirection table
Support of updating/querying redirection table has been
added for VF.
Signed-off-by: Helin Zhang
---
lib/librte_pmd_i40e/i40e_ethdev_vf.c | 99 ++--
1 file changed, 94 insertions(+), 5 deletions(-)
v2 changes:
* Add support of updating/querying i40e reta of VF.
v4 changes:
* Renamed RTE_BIT_WIDTH_64 to RTE_RETA_GROUP_SIZE.
diff --git a/lib/librte_pmd_i40e/i40e_ethdev_vf.c
b/lib/librte_pmd_i40e/i40e_ethdev_vf.c
index 3e64666..03bc28e 100644
--- a/lib/librte_pmd_i40e/i40e_ethdev_vf.c
+++ b/lib/librte_pmd_i40e/i40e_ethdev_vf.c
@@ -126,11 +126,6 @@ static void i40evf_dev_allmulticast_disable(struct
rte_eth_dev *dev);
static int i40evf_get_link_status(struct rte_eth_dev *dev,
struct rte_eth_link *link);
static int i40evf_init_vlan(struct rte_eth_dev *dev);
-static int i40evf_config_rss(struct i40e_vf *vf);
-static int i40evf_dev_rss_hash_update(struct rte_eth_dev *dev,
- struct rte_eth_rss_conf *rss_conf);
-static int i40evf_dev_rss_hash_conf_get(struct rte_eth_dev *dev,
- struct rte_eth_rss_conf *rss_conf);
static int i40evf_dev_rx_queue_start(struct rte_eth_dev *dev,
uint16_t rx_queue_id);
static int i40evf_dev_rx_queue_stop(struct rte_eth_dev *dev,
@@ -139,6 +134,17 @@ static int i40evf_dev_tx_queue_start(struct rte_eth_dev
*dev,
uint16_t tx_queue_id);
static int i40evf_dev_tx_queue_stop(struct rte_eth_dev *dev,
uint16_t tx_queue_id);
+static int i40evf_dev_rss_reta_update(struct rte_eth_dev *dev,
+ struct rte_eth_rss_reta_entry64 *reta_conf,
+ uint16_t reta_size);
+static int i40evf_dev_rss_reta_query(struct rte_eth_dev *dev,
+ struct rte_eth_rss_reta_entry64 *reta_conf,
+ uint16_t reta_size);
+static int i40evf_config_rss(struct i40e_vf *vf);
+static int i40evf_dev_rss_hash_update(struct rte_eth_dev *dev,
+ struct rte_eth_rss_conf *rss_conf);
+static int i40evf_dev_rss_hash_conf_get(struct rte_eth_dev *dev,
+ struct rte_eth_rss_conf *rss_conf);
/* Default hash key buffer for RSS */
static uint32_t rss_key_default[I40E_VFQF_HKEY_MAX_INDEX + 1];
@@ -166,6 +172,8 @@ static struct eth_dev_ops i40evf_eth_dev_ops = {
.rx_queue_release = i40e_dev_rx_queue_release,
.tx_queue_setup = i40e_dev_tx_queue_setup,
.tx_queue_release = i40e_dev_tx_queue_release,
+ .reta_update = i40evf_dev_rss_reta_update,
+ .reta_query = i40evf_dev_rss_reta_query,
.rss_hash_update = i40evf_dev_rss_hash_update,
.rss_hash_conf_get= i40evf_dev_rss_hash_conf_get,
};
@@ -1611,6 +1619,87 @@ i40evf_dev_close(struct rte_eth_dev *dev)
}
static int
+i40evf_dev_rss_reta_update(struct rte_eth_dev *dev,
+ struct rte_eth_rss_reta_entry64 *reta_conf,
+ uint16_t reta_size)
+{
+ struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+ uint32_t lut, l;
+ uint16_t i, j;
+ uint16_t idx, shift;
+ uint8_t mask;
+
+ if (reta_size != ETH_RSS_RETA_SIZE_64) {
+ PMD_DRV_LOG(ERR, "The size of hash lookup table configured "
+ "(%d) doesn't match the number of hardware can"
+ "support (%d)\n", reta_size, ETH_RSS_RETA_SIZE_64);
+ return -EINVAL;
+ }
+
+ for (i = 0; i < reta_size; i += I40E_4_BIT_WIDTH) {
+ idx = i / RTE_RETA_GROUP_SIZE;
+ shift = i % RTE_RETA_GROUP_SIZE;
+ mask = (uint8_t)((reta_conf[idx].mask >> shift) &
+ I40E_4_BIT_MASK);
+ if (!mask)
+ continue;
+ if (mask == I40E_4_BIT_MASK)
+ l = 0;
+ else
+ l = I40E_READ_REG(hw, I40E_VFQF_HLUT(i >> 2));
+
+ for (j = 0, lut = 0; j < I40E_4_BIT_WIDTH; j++) {
+ if (mask & (0x1 << j))
+ lut |= reta_conf[idx].reta[shift + j] <<
+ (CHAR_BIT * j);
+ else
+ lut |= l & (I40E_8_BIT_MASK << (CHAR_BIT * j));
+ }
+ I40E_WRITE_REG(hw, I40E_VFQF_HLUT(i >> 2), lut);
+ }
+
+ return 0;
+}
+
+static int
+i40evf_dev_rss_reta_query(struct rte_eth_dev *dev,
+ struct rte_eth_rss_reta_entry64 *reta_conf,
+ uint16_t reta_size)
+{
+ struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+ uint32_t lut;
+ uint16_t i, j;
+ uint16_t idx, shift;
+ uint8_
[dpdk-dev] [PATCH v4 4/8] igb: implement ops of 'dev_infos_get' for PF and VF respectively
As more and more information are different between PF and VF,
ops of 'dev_infos_get' has been implemented respectively. In
addition, new field of 'reta_size' has been added in
'struct rte_eth_dev_info' for returning redirection table size.
Signed-off-by: Helin Zhang
---
lib/librte_ether/rte_ethdev.h | 2 ++
lib/librte_pmd_e1000/igb_ethdev.c | 61 ---
2 files changed, 52 insertions(+), 11 deletions(-)
v2 changes:
* Added new function for ops of 'dev_infos_get' specifically for igb VF.
v3 changes:
* Put the adding new element of 'reta_size' in ethdev into this patch,
as it is needed.
* Returning default RX/TX configurations has been added in ops of
'dev_infos_get', as it was accepted recently in another patches.
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index cdfa579..cd6d5a2 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -919,6 +919,8 @@ struct rte_eth_dev_info {
uint16_t max_vmdq_pools; /**< Maximum number of VMDq pools. */
uint32_t rx_offload_capa; /**< Device RX offload capabilities. */
uint32_t tx_offload_capa; /**< Device TX offload capabilities. */
+ uint16_t reta_size;
+ /**< Device redirection table size, the total number of entries. */
struct rte_eth_rxconf default_rxconf; /**< Default RX configuration */
struct rte_eth_txconf default_txconf; /**< Default TX configuration */
};
diff --git a/lib/librte_pmd_e1000/igb_ethdev.c
b/lib/librte_pmd_e1000/igb_ethdev.c
index 9e5665f..79998cf 100644
--- a/lib/librte_pmd_e1000/igb_ethdev.c
+++ b/lib/librte_pmd_e1000/igb_ethdev.c
@@ -83,6 +83,8 @@ static void eth_igb_stats_get(struct rte_eth_dev *dev,
struct rte_eth_stats *rte_stats);
static void eth_igb_stats_reset(struct rte_eth_dev *dev);
static void eth_igb_infos_get(struct rte_eth_dev *dev,
+ struct rte_eth_dev_info *dev_info);
+static void eth_igbvf_infos_get(struct rte_eth_dev *dev,
struct rte_eth_dev_info *dev_info);
static int eth_igb_flow_ctrl_get(struct rte_eth_dev *dev,
struct rte_eth_fc_conf *fc_conf);
@@ -282,7 +284,7 @@ static struct eth_dev_ops igbvf_eth_dev_ops = {
.stats_get= eth_igbvf_stats_get,
.stats_reset = eth_igbvf_stats_reset,
.vlan_filter_set = igbvf_vlan_filter_set,
- .dev_infos_get= eth_igb_infos_get,
+ .dev_infos_get= eth_igbvf_infos_get,
.rx_queue_setup = eth_igb_rx_queue_setup,
.rx_queue_release = eth_igb_rx_queue_release,
.tx_queue_setup = eth_igb_tx_queue_setup,
@@ -1268,8 +1270,7 @@ eth_igbvf_stats_reset(struct rte_eth_dev *dev)
}
static void
-eth_igb_infos_get(struct rte_eth_dev *dev,
- struct rte_eth_dev_info *dev_info)
+eth_igb_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
{
struct e1000_hw *hw = E1000_DEV_PRIVATE_TO_HW(dev->data->dev_private);
@@ -1330,23 +1331,61 @@ eth_igb_infos_get(struct rte_eth_dev *dev,
dev_info->max_vmdq_pools = 0;
break;
+ default:
+ /* Should not happen */
+ break;
+ }
+ dev_info->reta_size = ETH_RSS_RETA_SIZE_128;
+
+ dev_info->default_rxconf = (struct rte_eth_rxconf) {
+ .rx_thresh = {
+ .pthresh = IGB_DEFAULT_RX_PTHRESH,
+ .hthresh = IGB_DEFAULT_RX_HTHRESH,
+ .wthresh = IGB_DEFAULT_RX_WTHRESH,
+ },
+ .rx_free_thresh = IGB_DEFAULT_RX_FREE_THRESH,
+ .rx_drop_en = 0,
+ };
+
+ dev_info->default_txconf = (struct rte_eth_txconf) {
+ .tx_thresh = {
+ .pthresh = IGB_DEFAULT_TX_PTHRESH,
+ .hthresh = IGB_DEFAULT_TX_HTHRESH,
+ .wthresh = IGB_DEFAULT_TX_WTHRESH,
+ },
+ .txq_flags = 0,
+ };
+}
+
+static void
+eth_igbvf_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
+{
+ struct e1000_hw *hw = E1000_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+ dev_info->min_rx_bufsize = 256; /* See BSIZE field of RCTL register. */
+ dev_info->max_rx_pktlen = 0x3FFF; /* See RLPML register. */
+ dev_info->max_mac_addrs = hw->mac.rar_entry_count;
+ dev_info->rx_offload_capa = DEV_RX_OFFLOAD_VLAN_STRIP |
+ DEV_RX_OFFLOAD_IPV4_CKSUM |
+ DEV_RX_OFFLOAD_UDP_CKSUM |
+ DEV_RX_OFFLOAD_TCP_CKSUM;
+ dev_info->tx_offload_capa = DEV_TX_OFFLOAD_VLAN_INSERT |
+ DEV_TX_OFFLOAD_IPV4_CKSUM |
+ DEV_TX_OFFLOAD_UDP_CKSUM |
+ DEV_TX_OFFLOAD_TCP_CKSUM |
+
[dpdk-dev] [PATCH v4 6/8] i40e: rework of ops of 'dev_infos_get' for both PF and VF
Returning redirection table size has been supported in
ops of 'dev_infos_get' for both PF and VF. Default
RX/TX configurations of VF can be returned in ops of
'dev_infos_get', while it was missed before.
Signed-off-by: Helin Zhang
---
lib/librte_pmd_i40e/i40e_ethdev.c| 16 +++-
lib/librte_pmd_i40e/i40e_ethdev.h| 11 +++
lib/librte_pmd_i40e/i40e_ethdev_vf.c | 23 +++
3 files changed, 37 insertions(+), 13 deletions(-)
v2 changes:
* Put getting reta size of both i40e PF and VF into a single patch.
v3 changes:
* Returning default RX/TX configurations has been added in ops of
'dev_infos_get' for VF, as it was added recently in that for PF.
diff --git a/lib/librte_pmd_i40e/i40e_ethdev.c
b/lib/librte_pmd_i40e/i40e_ethdev.c
index 0efbcd8..ce67552 100644
--- a/lib/librte_pmd_i40e/i40e_ethdev.c
+++ b/lib/librte_pmd_i40e/i40e_ethdev.c
@@ -58,17 +58,6 @@
#include "i40e_rxtx.h"
#include "i40e_pf.h"
-#define I40E_DEFAULT_RX_FREE_THRESH 32
-#define I40E_DEFAULT_RX_PTHRESH 8
-#define I40E_DEFAULT_RX_HTHRESH 8
-#define I40E_DEFAULT_RX_WTHRESH 0
-
-#define I40E_DEFAULT_TX_FREE_THRESH 32
-#define I40E_DEFAULT_TX_PTHRESH 32
-#define I40E_DEFAULT_TX_HTHRESH 0
-#define I40E_DEFAULT_TX_WTHRESH 0
-#define I40E_DEFAULT_TX_RSBIT_THRESH 32
-
/* Maximun number of MAC addresses */
#define I40E_NUM_MACADDR_MAX 64
#define I40E_CLEAR_PXE_WAIT_MS 200
@@ -1395,6 +1384,7 @@ i40e_dev_info_get(struct rte_eth_dev *dev, struct
rte_eth_dev_info *dev_info)
DEV_TX_OFFLOAD_UDP_CKSUM |
DEV_TX_OFFLOAD_TCP_CKSUM |
DEV_TX_OFFLOAD_SCTP_CKSUM;
+ dev_info->reta_size = pf->hash_lut_size;
dev_info->default_rxconf = (struct rte_eth_rxconf) {
.rx_thresh = {
@@ -1414,9 +1404,9 @@ i40e_dev_info_get(struct rte_eth_dev *dev, struct
rte_eth_dev_info *dev_info)
},
.tx_free_thresh = I40E_DEFAULT_TX_FREE_THRESH,
.tx_rs_thresh = I40E_DEFAULT_TX_RSBIT_THRESH,
- .txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
ETH_TXQ_FLAGS_NOOFFLOADS,
+ .txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
+ ETH_TXQ_FLAGS_NOOFFLOADS,
};
-
}
static int
diff --git a/lib/librte_pmd_i40e/i40e_ethdev.h
b/lib/librte_pmd_i40e/i40e_ethdev.h
index ce72720..bc14edc 100644
--- a/lib/librte_pmd_i40e/i40e_ethdev.h
+++ b/lib/librte_pmd_i40e/i40e_ethdev.h
@@ -54,6 +54,17 @@
/* Default TC traffic in case DCB is not enabled */
#define I40E_DEFAULT_TCMAP0x1
+#define I40E_DEFAULT_RX_FREE_THRESH 32
+#define I40E_DEFAULT_RX_PTHRESH 8
+#define I40E_DEFAULT_RX_HTHRESH 8
+#define I40E_DEFAULT_RX_WTHRESH 0
+
+#define I40E_DEFAULT_TX_FREE_THRESH 32
+#define I40E_DEFAULT_TX_PTHRESH 32
+#define I40E_DEFAULT_TX_HTHRESH 0
+#define I40E_DEFAULT_TX_WTHRESH 0
+#define I40E_DEFAULT_TX_RSBIT_THRESH 32
+
/* i40e flags */
#define I40E_FLAG_RSS (1ULL << 0)
#define I40E_FLAG_DCB (1ULL << 1)
diff --git a/lib/librte_pmd_i40e/i40e_ethdev_vf.c
b/lib/librte_pmd_i40e/i40e_ethdev_vf.c
index 5b8a3bf..3e64666 100644
--- a/lib/librte_pmd_i40e/i40e_ethdev_vf.c
+++ b/lib/librte_pmd_i40e/i40e_ethdev_vf.c
@@ -1567,6 +1567,29 @@ i40evf_dev_info_get(struct rte_eth_dev *dev, struct
rte_eth_dev_info *dev_info)
dev_info->max_tx_queues = vf->vsi_res->num_queue_pairs;
dev_info->min_rx_bufsize = I40E_BUF_SIZE_MIN;
dev_info->max_rx_pktlen = I40E_FRAME_SIZE_MAX;
+ dev_info->reta_size = ETH_RSS_RETA_SIZE_64;
+
+ dev_info->default_rxconf = (struct rte_eth_rxconf) {
+ .rx_thresh = {
+ .pthresh = I40E_DEFAULT_RX_PTHRESH,
+ .hthresh = I40E_DEFAULT_RX_HTHRESH,
+ .wthresh = I40E_DEFAULT_RX_WTHRESH,
+ },
+ .rx_free_thresh = I40E_DEFAULT_RX_FREE_THRESH,
+ .rx_drop_en = 0,
+ };
+
+ dev_info->default_txconf = (struct rte_eth_txconf) {
+ .tx_thresh = {
+ .pthresh = I40E_DEFAULT_TX_PTHRESH,
+ .hthresh = I40E_DEFAULT_TX_HTHRESH,
+ .wthresh = I40E_DEFAULT_TX_WTHRESH,
+ },
+ .tx_free_thresh = I40E_DEFAULT_TX_FREE_THRESH,
+ .tx_rs_thresh = I40E_DEFAULT_TX_RSBIT_THRESH,
+ .txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
+ ETH_TXQ_FLAGS_NOOFFLOADS,
+ };
}
static void
--
1.8.1.4
[dpdk-dev] [PATCH v2] i40e:fix MAC filter issues in i40e_ethdev.c
2014-10-31 11:28, Jijiang Liu: > This patch fixes two issues: one is to fix the log issues, the other is to > set filter type when updating the default MAC filter. > > v2 changes: > Fix the remaining PMD log issues. > > Signed-off-by: Jijiang Liu Lesson learned: patches are better reviewed when they are applied. It's probably my fault: the macvlan patchset was 1 week old and had no review. So I assumed that there was no problem. To the i40e developers: please understand that we need more reviews to close integration of the i40e features. The good conclusion is that it's now fixed; acked and applied. Thanks -- Thomas
[dpdk-dev] [PATCH] librte_ether:change rte_eth_mac_filter structure
2014-10-31 10:26, Jijiang Liu:
> As the filter type in i40e is defined enum type, so this patch changes
> the filter_type filed in the rte_eth_mac_filter for fixing the compilation
> error under ICC compiler.
Commit log is wrong. It's not because of i40e, it's only an API problem.
But I know you mix i40e and generic API.
> Signed-off-by: Jijiang Liu
> --- a/lib/librte_ether/rte_eth_ctrl.h
> +++ b/lib/librte_ether/rte_eth_ctrl.h
> @@ -91,7 +91,7 @@ enum rte_mac_filter_type {
> struct rte_eth_mac_filter {
> uint8_t is_vf; /**< 1 for VF, 0 for port dev */
> uint16_t dst_id; /** - uint16_t filter_type; /**< MAC filter type */
> + enum rte_mac_filter_type filter_type; /**< MAC filter type */
> struct ether_addr mac_addr;
> };
I didn't catch this error during my review. That's why we need more eyes to
carefully review patches.
Acked and applied
Thanks
--
Thomas
[dpdk-dev] Relationship between H/W ring and S/W ring
On Fri, Oct 31, 2014 at 09:51:56AM +0900, Gyumin wrote: > Thanks Bruce. > > I also agree with that the size of the S/W ring depends on the configuration > parameters because the size of the S/W ring is /sizeof(struct igb_rx_entry) > * len/ in the ixgbe_dev_rx_queue_setup function. H/W ring is also allocated > in the same function by using the ring_dma_zone_reserve function, and its > size is RX_RING_SZ. I don't think the RX_RING_SZ is configurable but it is > fixed value. Is there any other code configuring the size of H/W ring? > Indeed you are right, my mistake. The comment indicates that we always reserve the memory to be the maximum size so that we can resize the rings easier later on. In terms of runtime usage, though, if you look a the RX functions, you can see that the two rings are always kept in sync. For example, looking at ixgbe_rxq_rearm in ixgbe_rxtx_vec.c, you will see that rxdp and rxep values both start at offset "rxq->rxrearm_start" at the top of the function, and that in the main rearm loop, both are incremented twice each iteration (rxep += 2 in the for statment itself, and two rxdp++'s are used in the last two lines of the loop body). Regards, /Bruce > 2014-10-30 ?? 6:55? Bruce Richardson ?(?) ? ?: > >On Thu, Oct 30, 2014 at 04:32:16PM +0900, Gyumin wrote: > >>Hi > >> > >>I`m reading the ixgbe code especially about H/W ring and S/W ring. Is the > >>relationship between H/W ring and S/W ring one-to-one mapping? > >>As far as I know, H/W ring size is determined in the code(hard coded) while > >>S/W ring size is determined in port configuration time. > >>In the ixgbe_rx_alloc_bufs function, H/W ring header address and packet > >>address indicate the DMA address of S/W ring's mbuf. I understand it means > >>that the relationship between the H/W ring and S/W ring is one-to-one > >>mapping. For example, if the size of H/W ring is greater than the size of > >>S/W ring then some portion of H/W ring is unused. Is it correct? > >> > >>Thanks > >Hi, > > > >Yes, there is a 1:1 mapping between the hardware and software ring entries, > >and both are sized depending on the configuration parameters passed to the > >ring setup APIs. As you state, the HW ring contains the DMA addresses of the > >packet buffers, while the sw_ring contains the pointers to the original > >mbufs. The two rings are always kept in sync in the code. > > > >/Bruce > > >
[dpdk-dev] [PATCH RFC] Update/Improve build system
> From: Matthew Hall [mailto:mhall at mhcomputing.net] > Sent: Thursday, October 30, 2014 8:50 PM > > On Thu, Oct 30, 2014 at 09:18:23AM +, Gonzalez Monroy, Sergio wrote: > > I would say that D) is a good balance, although not being the simplest. > > A, or D. Depending on things such as, "If you run the DPDK on Random > Platform X," where X could be something like Power CPUs or other weird > stuff, will all of the things needed for the Combined Lib 1) be compilable, 2) > be able to load w/o errors. > > For example, I could see probe ctor functions from various PMD's blowing up > on unsupported hardware. Like how the rte_pmd_virtio had issues when I > tried it on my VM system. > IMHO the underlying issue was that virtio was unsupported for that platform. What I am trying to say is that any app built against a combined shared lib or combined/separated static lib will have that same issue if the feature/PMD is unsupported for the platform. In the virtio case, building against combined shared or combined/separated static DPDK libs would have the same result because the virtio PMD would be in the app. > If we think we can make sure no platform specific stuff breaks when it ends > up in Combined Lib A then A is probably the easiest for all. > I agree, a combined lib would simplify all app/lib linking, making it easier for the user and less error prone. One of the downsides that comes to mind is a flow work (I think you mentioned it) where you have multiple apps building against a single DPDK copy, and each app uses different features/PMDs. In that scenario, having separated libs would make your life easier as you would not need to have multiple DPDK copies customized for each app, giving you the flexibility to hand pick each lib you want to include into your app. That flow work still presents some issues as they may be features that are incompatible between each other and would need to be in different DPDK copies. Regards, Sergio > Matthew.
[dpdk-dev] DPDK Community Conference Call - Friday 31st October
This is just a reminder for anybody who's interested that this will be on in 30 minutes, and that we'll be discussing the feature list for the DPDK 2.0 release in March 2015. Audio bridge details are: France: +33 1588 77298 Germany:+49 8999 143191 Israel: +972 2589 6577 Russia: +7 495 641 4663 UK: +44 1793 402663 USA/Canada: +1 916 356 2663 or +1-888-875-9370 Bridge: 5 Conference ID: 1264677285 Tim > -Original Message- > From: O'driscoll, Tim > Sent: Friday, October 24, 2014 10:22 AM > To: dev at dpdk.org > Subject: DPDK Community Conference Call - Friday 31st October > > We're planning to hold our first community conference call on Friday 31st > October. It's impossible to find a time that suits everybody, so we've chosen > to do this in the afternoon/evening in Europe, which is the morning in the > USA. This does unfortunately limit participation from PRC, Japan and other > parts of the world. Here's the time and date in a variety of time zones: > > Dublin (Ireland) Friday, October 31, 2014 at > 4:00:00 PMGMT UTC > Paris (France)Friday, October 31, 2014 at > 5:00:00 > PMCET UTC+1 hour > San Francisco (U.S.A. - California) Friday, October 31, 2014 at 9:00:00 > AMPDT UTC-7 hours > New York (U.S.A. - New York) Friday, October 31, 2014 at 12:00:00 > Noon EDT UTC-4 hours > Tel Aviv (Israel) Friday, October 31, 2014 at > 6:00:00 > PMIST UTC+2 hours > Moscow (Russia) Friday, October 31, 2014 at 7:00:00 > PMMSK UTC+3 hours > > > Audio bridge details are: > France: +33 1588 77298 > Germany: +49 8999 143191 > Israel: +972 2589 6577 > Russia: +7 495 641 4663 > UK: +44 1793 402663 > USA: +1 916 356 2663 > > Bridge: 5 > Conference ID: 1264677285 > > If anybody needs an access number for another country, let me know. > > > Agenda: > Discuss feature list for DPDK 2.0 (Q1 2015). > Suggestions for topics for future calls. > > > Thanks, > Tim
[dpdk-dev] eal_flags_autotest fails with tailq fully local
Hi, Since release 1.7.1 and patchset "tailq fully local", the test eal_flags_autotest doesn't work anymore. It fails because it doesn't find any free hugepage (rte_memzone_reserve). The interesting commits are: http://dpdk.org/browse/dpdk/commit/?id=e3f3b68c6e42 http://dpdk.org/browse/dpdk/commit/?id=dd0024ccbc70 The test works only when these patches are reverted. Here is how to reproduce: git revert e3f3b68c6e42 git revert dd0024ccbc70 make config T=x86_64-native-linuxapp-gcc make mkdir -p /mnt/huge mount -t hugetlbfs nodev /mnt/huge echo 9 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages build/app/test -c 1 -n 1 -m 1 eal_flags_autotest I'd like this regression to be fixed for the coming release. If someone has an idea, he's welcome :) Thanks -- Thomas
[dpdk-dev] [PATCH v2] pmd: Add generic support for TCP TSO (Transmit Segmentation Offload)
Hello Miroslaw, On 10/21/2014 01:29 PM, miroslaw.walukiewicz at intel.com wrote: > From: Miroslaw Walukiewicz > > The NICs supported by DPDK have a possibility to accelerate TCP > traffic by sergnention offload. The application preprares a packet > with valid TCP header with size up to 64K and NIC makes packet > segmenation generating valid checksums and TCP segments. > > The patch defines a generic support for TSO offload. > - Add new PKT_TX_TCP_SEG flag. > Only packets with this flag set in ol_flags will be handled as > TSO packets. > > - Add new fields in indicating TCP TSO segment size and TCP header len. > The TSO requires from application setting following fields in mbuf. > 1. L2 header len including MAC/VLANs/SNAP if present > 2. L3 header len including IP options > 3. L4 header len (new field) including TCP options > 4. tso_segsz (new field) the size of TCP segment > > The apllication has obligation to compute the pseudo header checksum > instead of full TCP checksum and put it in the TCP header csum field. > > Handling complexity of creation combined l2_l3_len field > a new macro RTE_MBUF_TO_L2_L3_LEN() is defined to retrieve this > part of rte_mbuf. > The patch you submitted does not include any changes in a driver (let's say ixgbe as it is the reference) taking advantage it. So it's difficult to validate that your modifications are sufficient to implement TSO. In addition of a driver, I think that testpmd should be modified to validate your changes and give an example to people wanting to use this feature. Based on your patch, I'll try to submit a series in the coming days (maybe today if the winds are favourable) that includes the remaining patches from the original TSO series [1] that were not applied by Bruce's mbuf rework. Regards, Olivier [1] http://dpdk.org/ml/archives/dev/2014-May/002537.html
[dpdk-dev] [PATCH] doc: fix a typo
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jincheng Miao > Sent: Friday, October 24, 2014 8:08 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH] doc: fix a typo > > Signed-off-by: Jincheng Miao Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc. > --- > doc/guides/linux_gsg/sys_reqs.rst | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >
[dpdk-dev] [PULL REQUEST] doc: release notes, programmers guide, sample app. guide and fix to linux getting started guide.
These changes are a conversion of the Release Notes, Programmers Guide and Sample App. Guide from MSWord files to Sphinx rst files. There is also a patch to the Linux Getting Started Guide. The following changes since commit 94cae38575e50d0a300db2dbec08e6807cfa95be: examples/vhost: allow mergeable packets with vector ixgbe (2014-10-30 09:38:52 +0100) are available in the git repository at: git://dpdk.org/next/dpdk-doc master Bernard Iremonger (3): doc: release notes for DPDK 1.7 doc: programmers guide doc: sample applications user guide Jincheng Miao (1): doc: fix a typo doc/guides/index.rst |3 + doc/guides/linux_gsg/sys_reqs.rst |2 +- doc/guides/prog_guide/build_app.rst| 128 ++ doc/guides/prog_guide/dev_kit_build_system.rst | 418 + doc/guides/prog_guide/dev_kit_root_make_help.rst | 255 +++ doc/guides/prog_guide/driver_vm_emul_dev.rst | 178 ++ doc/guides/prog_guide/env_abstraction_layer.rst| 213 +++ doc/guides/prog_guide/ext_app_lib_make_help.rst| 125 ++ doc/guides/prog_guide/extend_intel_dpdk.rst| 136 ++ doc/guides/prog_guide/glossary.rst | 199 +++ doc/guides/prog_guide/hash_lib.rst | 134 ++ .../prog_guide/i40e_ixgbe_igb_virt_func_drv.rst| 545 ++ doc/guides/prog_guide/images/Figure33.png | Bin 0 -> 71160 bytes doc/guides/prog_guide/images/Figure35.png | Bin 0 -> 80648 bytes doc/guides/prog_guide/images/Figure39.png | Bin 0 -> 69916 bytes doc/guides/prog_guide/images/LinkBonding1.png | Bin 0 -> 172141 bytes doc/guides/prog_guide/images/LinkBonding1_orig.png | Bin 0 -> 360139 bytes doc/guides/prog_guide/images/Object_1.png | Bin 0 -> 10165 bytes .../prog_guide/images/PacketDistributor1.png | Bin 0 -> 297427 bytes doc/guides/prog_guide/images/image10.png | Bin 0 -> 18083 bytes doc/guides/prog_guide/images/image11.png | Bin 0 -> 18262 bytes doc/guides/prog_guide/images/image12.png | Bin 0 -> 20681 bytes doc/guides/prog_guide/images/image13.png | Bin 0 -> 23177 bytes doc/guides/prog_guide/images/image14.png | Bin 0 -> 38537 bytes doc/guides/prog_guide/images/image15.png | Bin 0 -> 23739 bytes doc/guides/prog_guide/images/image16.png | Bin 0 -> 17167 bytes doc/guides/prog_guide/images/image17.png | Bin 0 -> 12931 bytes doc/guides/prog_guide/images/image18.png | Bin 0 -> 13397 bytes doc/guides/prog_guide/images/image19.png | Bin 0 -> 16089 bytes doc/guides/prog_guide/images/image2.png| Bin 0 -> 239605 bytes doc/guides/prog_guide/images/image20.png | Bin 0 -> 18059 bytes doc/guides/prog_guide/images/image21.png | Bin 0 -> 49727 bytes doc/guides/prog_guide/images/image22.png | Bin 0 -> 19303 bytes doc/guides/prog_guide/images/image23.png | Bin 0 -> 22430 bytes doc/guides/prog_guide/images/image24.png | Bin 0 -> 425314 bytes doc/guides/prog_guide/images/image25.png | Bin 0 -> 343322 bytes doc/guides/prog_guide/images/image26.png | Bin 0 -> 313238 bytes doc/guides/prog_guide/images/image27.png | Bin 0 -> 370244 bytes doc/guides/prog_guide/images/image28.png | Bin 0 -> 48088 bytes doc/guides/prog_guide/images/image29.png | Bin 0 -> 18967 bytes doc/guides/prog_guide/images/image3.png| Bin 0 -> 56284 bytes doc/guides/prog_guide/images/image30.png | Bin 0 -> 40850 bytes doc/guides/prog_guide/images/image31.png | Bin 0 -> 17475 bytes doc/guides/prog_guide/images/image32.png | Bin 0 -> 107542 bytes doc/guides/prog_guide/images/image33.png | Bin 0 -> 123082 bytes doc/guides/prog_guide/images/image34.png | Bin 0 -> 172288 bytes doc/guides/prog_guide/images/image35.png | Bin 0 -> 163842 bytes doc/guides/prog_guide/images/image36.png | Bin 0 -> 96762 bytes doc/guides/prog_guide/images/image37.png | Bin 0 -> 6405 bytes doc/guides/prog_guide/images/image38.png | Bin 0 -> 7356 bytes doc/guides/prog_guide/images/image39.png | Bin 0 -> 95193 bytes doc/guides/prog_guide/images/image4.png| Bin 0 -> 79187 bytes doc/guides/prog_guide/images/image40.png | Bin 0 -> 114003 bytes doc/guides/prog_guide/images/image41.png | Bin 0 -> 87035 bytes doc/guides/prog_guide/images/image42.png | Bin 0 -> 29078 bytes doc/guides/prog_guide/images/image43.png | Bin 0 -> 185839 bytes doc/guides/prog_guide/images/image44.png | Bin 0 -> 51088 bytes doc/guides/prog_guide/images/image45.png | Bin 0 -> 251431 bytes doc/guides/prog_guide/images/image46.png | Bin 0 -> 366308 bytes doc/guides/prog_guide/images/image47.png
[dpdk-dev] DPDK Community Conference Call - Friday 31st October
Thanks again to those who attended the call earlier. Hopefully people found it useful. We'll schedule a follow-up call for 2 weeks' time. One thing that we do want to look into is an easy way to allow screen sharing, so that we can use some slides to guide the discussion. Internally within Intel we use MS Lync. We can try that, but it's not always very user-friendly for external participants, and doesn't have a Linux client. Other options would include GoToMeeting or WebEx. If anybody has input on a good tool for this, let me know. We covered the following features from our 2.0 list today, and will discuss the remainder on the next call. I've called out below who on our side was describing each of the features, and included their email addresses. If anybody has further questions on these, feel free to either ask openly on the mailing list, or else contact the relevant person directly. Bifurcated Driver (Danny.Zhou at intel.com) Packet Reordering/Packet Distributor (Bruce.Richardson at intel.com) New Hardware Support (Walter.E.Gilmore at intel.com) Fortville features (Heqing.Zhu at intel.com) Support Multiple Threads per Core (Venky.Venkatesan at intel.com) Cuckoo Hash (Bruce.Richardson at intel.com, Venky.Venkatesan at intel.com) The Cuckoo Hash paper that was mentioned is available at: http://www.cs.cmu.edu/~dongz/papers/cuckooswitch.pdf. Finally, if anybody has suggestions for topics for future calls, please let me know. Thanks, Tim > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of O'driscoll, Tim > Sent: Friday, October 31, 2014 3:35 PM > To: 'dev at dpdk.org' > Subject: Re: [dpdk-dev] DPDK Community Conference Call - Friday 31st > October > > This is just a reminder for anybody who's interested that this will be on in > 30 > minutes, and that we'll be discussing the feature list for the DPDK 2.0 > release > in March 2015. > > Audio bridge details are: > France: +33 1588 77298 > Germany: +49 8999 143191 > Israel: +972 2589 6577 > Russia: +7 495 641 4663 > UK: +44 1793 402663 > USA/Canada: +1 916 356 2663 or +1-888-875-9370 > > Bridge: 5 > Conference ID: 1264677285 > > > Tim > > > -Original Message- > > From: O'driscoll, Tim > > Sent: Friday, October 24, 2014 10:22 AM > > To: dev at dpdk.org > > Subject: DPDK Community Conference Call - Friday 31st October > > > > We're planning to hold our first community conference call on Friday > > 31st October. It's impossible to find a time that suits everybody, so > > we've chosen to do this in the afternoon/evening in Europe, which is > > the morning in the USA. This does unfortunately limit participation > > from PRC, Japan and other parts of the world. Here's the time and date in a > variety of time zones: > > > > Dublin (Ireland)Friday, October 31, 2014 at > > 4:00:00 PMGMT UTC > > Paris (France) Friday, October 31, 2014 at > > 5:00:00 > > PMCET UTC+1 hour > > San Francisco (U.S.A. - California) Friday, October 31, 2014 at 9:00:00 > > AMPDT UTC-7 hours > > New York (U.S.A. - New York)Friday, October 31, 2014 at > 12:00:00 > > Noon EDT UTC-4 hours > > Tel Aviv (Israel) Friday, October 31, 2014 at > 6:00:00 > > PMIST UTC+2 hours > > Moscow (Russia) Friday, October 31, 2014 at 7:00:00 > > PMMSK UTC+3 hours > > > > > > Audio bridge details are: > > France: +33 1588 77298 > > Germany:+49 8999 143191 > > Israel: +972 2589 6577 > > Russia: +7 495 641 4663 > > UK: +44 1793 402663 > > USA:+1 916 356 2663 > > > > Bridge: 5 > > Conference ID: 1264677285 > > > > If anybody needs an access number for another country, let me know. > > > > > > Agenda: > > Discuss feature list for DPDK 2.0 (Q1 2015). > > Suggestions for topics for future calls. > > > > > > Thanks, > > Tim
[dpdk-dev] [PULL REQUEST] doc: release notes, programmers guide, sample app. guide and fix to linux getting started guide.
Hi Bernard, There are some conversion issues with the text of these images: > doc/guides/prog_guide/images/image18.png | Bin 0 -> 13397 bytes > doc/guides/prog_guide/images/image3.png| Bin 0 -> 56284 bytes > doc/guides/sample_app_ug/images/image18.png| Bin 0 -> 22301 bytes > doc/guides/sample_app_ug/images/image2.png | Bin 0 -> 60504 bytes > doc/guides/sample_app_ug/images/image4.png | Bin 0 -> 11906 bytes Please could you fix it and submit another pull request? Ideally the conversion of the images should be done dynamically when building the documentation but it's a future improvement. Thanks -- Thomas
[dpdk-dev] DPDK on Xen Dom-U hangs during hugepage setup
Hello Murillo, Yes, am using rte_dom0_mm as explained in DPDK programmers guide section 14.3.3 step (4). The examples work when using --no-huge option. Are you able to go past the hugepage setup? If so can you tell what are the steps you followed in addition to the ones explained in section 14.3. Thanks, Kiran -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Murillo Sent: Friday, October 31, 2014 1:11 AM To: dev at dpdk.org Subject: Re: [dpdk-dev] DPDK on Xen Dom-U hangs during hugepage setup Hello, Xen does not support hugepages, so you have to use a kernel module called rte_dom0_mm. The instructions are in the getting started guide in the seccion 2.3.3. If you manage to execute any example please tell me, because I am stuck during the execution of the examples after configuring the environment. El 30/10/14 a las 19:15, Kiran KN escribi?: > Hello, > > I am trying to bring up DPDK on Xen Dom-U. > > Have followed all the steps in DPDK programmers guide in section 14.3. > > However, when I try to run testpmd or any other example application, it is > getting stuck during hugepage setup. > > It hangs after the print "EAL: Setting up memory..." > > Has anyone faced similar issue before? > > Thanks, > Kiran > >
[dpdk-dev] [PATCH] ixgbe: logic change in ixgbe_check_mac_link_vf().
From: Lee Roberts
This patch corrects an issue where "testpmd" run against
ixgbevf ports in the host OS reports speed as 100 Mbps
and half-duplex.
If the link status is still needed, set speed to zero,
change ret_val and goto quick exit. Otherwise, continue
processing to get the correct link speed.
Signed-off by: Lee Roberts
---
lib/librte_pmd_ixgbe/ixgbe/ixgbe_vf.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/lib/librte_pmd_ixgbe/ixgbe/ixgbe_vf.c
b/lib/librte_pmd_ixgbe/ixgbe/ixgbe_vf.c
index e6b6c51..04a962b 100644
--- a/lib/librte_pmd_ixgbe/ixgbe/ixgbe_vf.c
+++ b/lib/librte_pmd_ixgbe/ixgbe/ixgbe_vf.c
@@ -550,11 +550,12 @@ s32 ixgbe_check_mac_link_vf(struct ixgbe_hw *hw,
ixgbe_link_speed *speed,
UNREFERENCED_1PARAMETER(autoneg_wait_to_complete);
/* If we were hit with a reset drop the link */
- if (!mbx->ops.check_for_rst(hw, 0) || !mbx->timeout)
+ if (!mbx->ops.check_for_rst(hw, 0) || !mbx->timeout) {
mac->get_link_status = true;
-
- if (!mac->get_link_status)
+ *speed = 0;
+ ret_val = -1;
goto out;
+ }
/* if link status is down no point in checking to see if pf is up */
links_reg = IXGBE_READ_REG(hw, IXGBE_VFLINKS);
--
1.7.10.4
[dpdk-dev] Q on contribution to DPDK
Hello DPDK development team, I am interested in contributing to DPDK and wanted to know a way of contributing to it. Some questions 1. Will DPDK accept patches from community? I will be individual contributor with no affiliation to any company. 2. If answer is "Yes" to previous question, should I look at DPDK development roadmap and pick one from that? Inputs appreciated. Thanks, Ravi
[dpdk-dev] [dpdk-announce] DPDK Features for Q1 2015
Hi Tetsuya: I am implementing vhost-user, and the functionality works now. During this work, I have refactored vhost code a bit for better modularization, basically virtio part, control message part(vhost-user, vhost cuse) and data part. :). Let us see your patch, if its modularization is further, I will generate the vhost-user patch based on yours rather than mine, :). > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Tetsuya Mukawa > Sent: Wednesday, October 22, 2014 8:17 PM > To: O'driscoll, Tim > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [dpdk-announce] DPDK Features for Q1 2015 > > Hi All, > > (2014/10/22 22:48), O'driscoll, Tim wrote: > > Single Virtio Driver: Merge existing Virtio drivers into a single > > implementation, > incorporating the best features from each of the existing drivers. > > It's nice plan. We should do it. > In my understanding, the following drivers could be merged into a single > virtio PMD since they consist of similar code for handling the virtio ring. > > - librte_pmd_virtio > - librte_pmd_xenvirt > - librte_vhost (cuse) > > librte_vhost is not a PMD, but we can easily write a librte_pmd_vhost > based on librte_vhost. > Before doing it, we need to consider vhost-user extension for librte_vhost. > > BTW, I have a RFC patch for librte_vhost to handle vhost-user. > It may be the first step to merge all virtio drivers. > > My patch introduces an abstraction layer to hide differences between > legacy cuse vhost and vhost-user from DPDK apps. > Also in my patch, virtio negotiation and initialization code and virtio > handling code is separated. > So, legacy cuse vhost and vhost-user can share virtio handling code > > Anyway, I will send a RFC patch soon as the first step of merging all > virtio drivers. > > Thanks, > Tetsuya
[dpdk-dev] Q on code contribution to DPDK
Hello DPDK development team, This is the 3rd email i am sending but it never shows up. I am subscribed to the list though. I am interested in contributing to DPDK and wanted to know a way of contributing to it. Some questions 1. Will DPDK accept patches from community? I will be individual contributor with no affiliation to any company. 2. If answer is "Yes" to previous question, should I look at DPDK development roadmap and pick one from that? Inputs appreciated. Thanks, Ravi
[dpdk-dev] Q on contribution to DPDK
Ravi: DPDK is an open source community project. Anyone and everyone are welcome and encouraged to contribute patches. There should not be any concern about individual contributors versus company affiliation. What matters is useful code. Please review the Development page on the site for guidance: http://dpdk.org/dev If you have particular areas of interest or expertise just share that with the list. I look forward to your contributions. Jim -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of r k Sent: Friday, October 31, 2014 2:39 PM To: dev at dpdk.org Subject: [dpdk-dev] Q on contribution to DPDK Hello DPDK development team, I am interested in contributing to DPDK and wanted to know a way of contributing to it. Some questions 1. Will DPDK accept patches from community? I will be individual contributor with no affiliation to any company. 2. If answer is "Yes" to previous question, should I look at DPDK development roadmap and pick one from that? Inputs appreciated. Thanks, Ravi
[dpdk-dev] [PATCH RFC] Update/Improve build system
On Fri, Oct 31, 2014 at 10:45:07AM +, Gonzalez Monroy, Sergio wrote: > That flow work still presents some issues as they may be features that are > incompatible between each other and would need to be in different DPDK > copies. > > Regards, > Sergio So I think the two questions are: 1) Will there ever be cases where something will compile on some platform but break at runtime and thus need to be excluded from a library? 2) Are there incompatible features where the library could break if both are enabled at once? If the answer to both questions is 'No' then the simple single-shared, single-static, is definitely simplest and most reliable. Matthew.
[dpdk-dev] Fwd: FOSDEM conference - call for participation
Hi, Talks related to DPDK can be proposed for FOSDEM 2015: https://fosdem.org/2015/ This conference will take place in Belgium on 31 January & 1 February. -- Thomas Forwarded Message Subject: Network devroom call for participation Date: Fri, 31 Oct 2014 17:33:33 -0400 From: Dave Neary To: Pavel Simerda , network-devroom at lists.fosdem.org, fosdem at lists.fosdem.org Hi everyone, We are pleased to announce the Call for Participation in the FOSDEM 2015 Networking DevRoom! Important dates: * Nov 25: Deadline for submissions * Dec 1: Speakers notified of acceptance * Dec 5: Schedule published This is the first time that networking has been included as a stand-alone DevRoom, and this year the topics will cover two distinct fields: * Software Defined Networking (SDN), covering virtual switching, open source SDN controllers, virtual routing * Network management, covering host-level networking - NetworkManager, ConnMan, systemd, wicked, kernel network services, network security, etc We are now inviting proposals for talks about Free/Libre/Open-source Software on the topics of SDN and network management. This is an exciting and growing field, and this is a unique opportunity to show novel ideas and developments to a very knowledgeable technical audience. Topics accepted include, but are not limited to: SDN: * SDN controllers - OpenDaylight, OpenContrail, OpenStack Neutron * Dataplane processing: DPDK, OpenDataplane, netdev, netfilter * Virtual switches: Open vSwitch, Snabb Switch, VDE * Open network protocols: OpenFlow, NETCONF, OpenLISP Network management: * Network management: NetworkManager, ConnMan, systemd-networkd, interoperability among these projects * Common code infrastructure: libnl, libmnl, libsystemd, ell, pyroute2 * Network services: DHCP, DNS, DNSSEC, PPP * Connection management: Wifi, tethering, connection sharing, metric and source based routing, Talks should be aimed at a technical audience, but should not assume that attendees are already familiar with your project or how it solves a general problem. Talk proposals can be very specific solutions to a problem, or can be higher level project overviews for lesser known projects. Please include the following information when submitting a proposal: Your name The title of your talk (please be descriptive, as titles will be listed with around 250 from other projects) Short abstract of one or two paragraphs Short bio (with photo) The deadline for submissions is November 25th 2014. FOSDEM will be held on the weekend of January 31st-February 1st 2015 and the Networking DevRoom will take place on Saturday, January 31st 2015. Please use the following website to submit your proposals: https://penta.fosdem.org/submission/FOSDEM15 (you do not need to create a new Pentabarf account if you already have one from past years). You can also join the devroom?s mailing list, which is the official communication channel for the DevRoom: network-devroom at lists.fosdem.org (subscription page: https://lists.fosdem.org/listinfo/network-devroom) ? The Networking DevRoom 2015 Organization Team -- Dave Neary - NFV/SDN Community Strategy Open Source and Standards, Red Hat - http://community.redhat.com Ph: +1-978-399-2182 / Cell: +1-978-799-3338
[dpdk-dev] Q on contribution to DPDK
Hi Jim, Thanks for your response. I did check DPDK roadmap and it wasn't clear to me what's available to be implemented. In addition, roadmap lists features but doesn't give description as to what needs to be done. It might be no brainer for original developers but it will definitely help outsiders if some information is provided. Also I was thinking if I can start-off with bug fixing initially to get acquainted with the code and then start off with more things. Please let me know your inputs. Thanks, Ravi On Fri, Oct 31, 2014 at 3:16 PM, St Leger, Jim wrote: > Ravi: > > DPDK is an open source community project. Anyone and everyone are welcome and > encouraged to contribute patches. There should not be any concern about > individual contributors versus company affiliation. What matters is useful > code. > Please review the Development page on the site for guidance: > http://dpdk.org/dev > > If you have particular areas of interest or expertise just share that with > the list. > > I look forward to your contributions. > > Jim > > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of r k > Sent: Friday, October 31, 2014 2:39 PM > To: dev at dpdk.org > Subject: [dpdk-dev] Q on contribution to DPDK > > Hello DPDK development team, > > I am interested in contributing to DPDK and wanted to know a way of > contributing to it. Some questions > > 1. Will DPDK accept patches from community? I will be individual contributor > with no affiliation to any company. > > 2. If answer is "Yes" to previous question, should I look at DPDK development > roadmap and pick one from that? > > Inputs appreciated. > > Thanks, > Ravi
