date:20190512

[dpdk-dev] [PATCH v2] net/mlx5: fix device removal handler for multiport device

2019-05-12 Thread Viacheslav Ovsiienko

IBV_EVENT_DEVICE_FATAL event is generated by the driver once for
the entire multiport Infiniband device, not for each existing ports.
The port index is zero and it causes dropping the device removal
event. We should invoke the removal event processing routine
for each port we have installed handler for.

Fixes: 028b2a28c3cb ("net/mlx5: update event handler for multiport IB devices")

Signed-off-by: Viacheslav Ovsiienko 
---
v2: - address comments
- more detailed debug messages in the event handler
- removed port specific IBV_EVENT_DEVICE_FATAL handling code

v1: http://patches.dpdk.org/patch/53371/

 drivers/net/mlx5/mlx5_ethdev.c | 77 ++
 1 file changed, 62 insertions(+), 15 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index 80ee98f..a8a7ece 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -1116,6 +1116,35 @@ int mlx5_fw_version_get(struct rte_eth_dev *dev, char 
*fw_ver, size_t fw_size)
 }
 
 /**
+ * Handle asynchronous removal event for entire multiport device.
+ *
+ * @param sh
+ *   Infiniband device shared context.
+ */
+static void
+mlx5_dev_interrupt_device_fatal(struct mlx5_ibv_shared *sh)
+{
+   uint32_t i;
+
+   for (i = 0; i < sh->max_port; ++i) {
+   struct rte_eth_dev *dev;
+
+   if (sh->port[i].ih_port_id >= RTE_MAX_ETHPORTS) {
+   /*
+* Or not existing port either no
+* handler installed for this port.
+*/
+   continue;
+   }
+   dev = &rte_eth_devices[sh->port[i].ih_port_id];
+   assert(dev);
+   if (dev->data->dev_conf.intr_conf.rmv)
+   _rte_eth_dev_callback_process
+   (dev, RTE_ETH_EVENT_INTR_RMV, NULL);
+   }
+}
+
+/**
  * Handle shared asynchronous events the NIC (removal event
  * and link status change). Supports multiport IB device.
  *
@@ -1137,21 +1166,46 @@ int mlx5_fw_version_get(struct rte_eth_dev *dev, char 
*fw_ver, size_t fw_size)
break;
/* Retrieve and check IB port index. */
tmp = (uint32_t)event.element.port_num;
-   assert(tmp && (tmp <= sh->max_port));
-   if (!tmp ||
-   tmp > sh->max_port ||
-   sh->port[tmp - 1].ih_port_id >= RTE_MAX_ETHPORTS) {
+   if (!tmp && event.event_type == IBV_EVENT_DEVICE_FATAL) {
/*
-* Invalid IB port index or no handler
-* installed for this port.
+* The DEVICE_FATAL event is called once for
+* entire device without port specifying.
+* We should notify all existing ports.
 */
mlx5_glue->ack_async_event(&event);
+   mlx5_dev_interrupt_device_fatal(sh);
+   continue;
+   }
+   assert(tmp && (tmp <= sh->max_port));
+   if (!tmp) {
+   /* Unsupported devive level event. */
+   mlx5_glue->ack_async_event(&event);
+   DRV_LOG(DEBUG,
+   "unsupported common event (type %d)",
+   event.event_type);
+   continue;
+   }
+   if (tmp > sh->max_port) {
+   /* Invalid IB port index. */
+   mlx5_glue->ack_async_event(&event);
+   DRV_LOG(DEBUG,
+   "cannot handle an event (type %d)"
+   "due to invalid IB port index (%u)",
+   event.event_type, tmp);
+   continue;
+   }
+   if (sh->port[tmp - 1].ih_port_id >= RTE_MAX_ETHPORTS) {
+   /* No handler installed. */
+   mlx5_glue->ack_async_event(&event);
+   DRV_LOG(DEBUG,
+   "cannot handle an event (type %d)"
+   "due to no handler installed for port %u",
+   event.event_type, tmp);
continue;
}
/* Retrieve ethernet device descriptor. */
tmp = sh->port[tmp - 1].ih_port_id;
dev = &rte_eth_devices[tmp];
-   tmp = 0;
assert(dev);
if ((event.event_type == IBV_EVENT_PORT_ACTIVE ||
 event.event_type == IBV_EVENT_PORT_ERR) &&
@@ -1165,15 +1219,8 @@ int mlx5_fw_version_get(struct rte_eth_dev *dev, char 
*fw_ver, size_t fw_size)
(dev, RTE_ETH_EVENT_INTR_LSC, NULL);
continue;

Re: [dpdk-dev] [PATCH v2] net/mlx5: fix device removal handler for multiport device

2019-05-12 Thread Shahaf Shuler

Sunday, May 12, 2019 11:32 AM, Viacheslav Ovsiienko:
> Subject: [dpdk-dev] [PATCH v2] net/mlx5: fix device removal handler for
> multiport device
> 
> IBV_EVENT_DEVICE_FATAL event is generated by the driver once for the
> entire multiport Infiniband device, not for each existing ports.
> The port index is zero and it causes dropping the device removal event. We
> should invoke the removal event processing routine for each port we have
> installed handler for.
> 
> Fixes: 028b2a28c3cb ("net/mlx5: update event handler for multiport IB
> devices")
> 
> Signed-off-by: Viacheslav Ovsiienko 

Acked-by: Shahaf Shuler 

Thomas, Ferruh,
This one is a critical fix for mlx5. w/o it will break the support for failsafe 
at azure. 

Can you consider to integrate it?

> ---
> v2: - address comments
> - more detailed debug messages in the event handler
> - removed port specific IBV_EVENT_DEVICE_FATAL handling code
> 
> v1:
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatch
> es.dpdk.org%2Fpatch%2F53371%2F&data=02%7C01%7Cshahafs%40mel
> lanox.com%7C46fcede947654c45106e08d6d6b462e5%7Ca652971c7d2e4d9ba
> 6a4d149256f461b%7C0%7C0%7C636932467570850420&sdata=%2FN%2B
> D0OWf5y0hgtlvWj7om9qZrQPPIbmGXDIfsgqeUtY%3D&reserved=0
> 
>  drivers/net/mlx5/mlx5_ethdev.c | 77
> ++
>  1 file changed, 62 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/net/mlx5/mlx5_ethdev.c
> b/drivers/net/mlx5/mlx5_ethdev.c index 80ee98f..a8a7ece 100644
> --- a/drivers/net/mlx5/mlx5_ethdev.c
> +++ b/drivers/net/mlx5/mlx5_ethdev.c
> @@ -1116,6 +1116,35 @@ int mlx5_fw_version_get(struct rte_eth_dev
> *dev, char *fw_ver, size_t fw_size)  }
> 
>  /**
> + * Handle asynchronous removal event for entire multiport device.
> + *
> + * @param sh
> + *   Infiniband device shared context.
> + */
> +static void
> +mlx5_dev_interrupt_device_fatal(struct mlx5_ibv_shared *sh) {
> + uint32_t i;
> +
> + for (i = 0; i < sh->max_port; ++i) {
> + struct rte_eth_dev *dev;
> +
> + if (sh->port[i].ih_port_id >= RTE_MAX_ETHPORTS) {
> + /*
> +  * Or not existing port either no
> +  * handler installed for this port.
> +  */
> + continue;
> + }
> + dev = &rte_eth_devices[sh->port[i].ih_port_id];
> + assert(dev);
> + if (dev->data->dev_conf.intr_conf.rmv)
> + _rte_eth_dev_callback_process
> + (dev, RTE_ETH_EVENT_INTR_RMV, NULL);
> + }
> +}
> +
> +/**
>   * Handle shared asynchronous events the NIC (removal event
>   * and link status change). Supports multiport IB device.
>   *
> @@ -1137,21 +1166,46 @@ int mlx5_fw_version_get(struct rte_eth_dev
> *dev, char *fw_ver, size_t fw_size)
>   break;
>   /* Retrieve and check IB port index. */
>   tmp = (uint32_t)event.element.port_num;
> - assert(tmp && (tmp <= sh->max_port));
> - if (!tmp ||
> - tmp > sh->max_port ||
> - sh->port[tmp - 1].ih_port_id >= RTE_MAX_ETHPORTS) {
> + if (!tmp && event.event_type ==
> IBV_EVENT_DEVICE_FATAL) {
>   /*
> -  * Invalid IB port index or no handler
> -  * installed for this port.
> +  * The DEVICE_FATAL event is called once for
> +  * entire device without port specifying.
> +  * We should notify all existing ports.
>*/
>   mlx5_glue->ack_async_event(&event);
> + mlx5_dev_interrupt_device_fatal(sh);
> + continue;
> + }
> + assert(tmp && (tmp <= sh->max_port));
> + if (!tmp) {
> + /* Unsupported devive level event. */
> + mlx5_glue->ack_async_event(&event);
> + DRV_LOG(DEBUG,
> + "unsupported common event (type %d)",
> + event.event_type);
> + continue;
> + }
> + if (tmp > sh->max_port) {
> + /* Invalid IB port index. */
> + mlx5_glue->ack_async_event(&event);
> + DRV_LOG(DEBUG,
> + "cannot handle an event (type %d)"
> + "due to invalid IB port index (%u)",
> + event.event_type, tmp);
> + continue;
> + }
> + if (sh->port[tmp - 1].ih_port_id >= RTE_MAX_ETHPORTS) {
> + /* No handler installed. */
> + mlx5_glue->ack_async_event(&event);
> + DRV_LOG(DEBUG,
> + "cannot handle an event (type %d)"
> + "due to

Re: [dpdk-dev] [PATCH v2] net/mlx5: fix device removal handler for multiport device

2019-05-12 Thread Shahaf Shuler

Sunday, May 12, 2019 3:15 PM, Shahaf Shuler:
> Subject: Re: [dpdk-dev] [PATCH v2] net/mlx5: fix device removal handler for
> multiport device
> 
> Sunday, May 12, 2019 11:32 AM, Viacheslav Ovsiienko:
> > Subject: [dpdk-dev] [PATCH v2] net/mlx5: fix device removal handler
> > for multiport device
> >
> > IBV_EVENT_DEVICE_FATAL event is generated by the driver once for the
> > entire multiport Infiniband device, not for each existing ports.
> > The port index is zero and it causes dropping the device removal
> > event. We should invoke the removal event processing routine for each
> > port we have installed handler for.
> >
> > Fixes: 028b2a28c3cb ("net/mlx5: update event handler for multiport IB
> > devices")
> >
> > Signed-off-by: Viacheslav Ovsiienko 
> 
> Acked-by: Shahaf Shuler 
> 
> Thomas, Ferruh,
> This one is a critical fix for mlx5. w/o it will break the support for 
> failsafe at
> azure.
> 
> Can you consider to integrate it?

Applied it also to next-net-mlx, thanks. 

> 
> > ---
> > v2: - address comments
> > - more detailed debug messages in the event handler
> > - removed port specific IBV_EVENT_DEVICE_FATAL handling code
> >
> > v1:
> >
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatch
> >
> es.dpdk.org%2Fpatch%2F53371%2F&data=02%7C01%7Cshahafs%40mel
> >
> lanox.com%7C46fcede947654c45106e08d6d6b462e5%7Ca652971c7d2e4d9ba
> >
> 6a4d149256f461b%7C0%7C0%7C636932467570850420&sdata=%2FN%2B
> > D0OWf5y0hgtlvWj7om9qZrQPPIbmGXDIfsgqeUtY%3D&reserved=0
> >
> >  drivers/net/mlx5/mlx5_ethdev.c | 77
> > ++
> >  1 file changed, 62 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/net/mlx5/mlx5_ethdev.c
> > b/drivers/net/mlx5/mlx5_ethdev.c index 80ee98f..a8a7ece 100644
> > --- a/drivers/net/mlx5/mlx5_ethdev.c
> > +++ b/drivers/net/mlx5/mlx5_ethdev.c
> > @@ -1116,6 +1116,35 @@ int mlx5_fw_version_get(struct rte_eth_dev
> > *dev, char *fw_ver, size_t fw_size)  }
> >
> >  /**
> > + * Handle asynchronous removal event for entire multiport device.
> > + *
> > + * @param sh
> > + *   Infiniband device shared context.
> > + */
> > +static void
> > +mlx5_dev_interrupt_device_fatal(struct mlx5_ibv_shared *sh) {
> > +   uint32_t i;
> > +
> > +   for (i = 0; i < sh->max_port; ++i) {
> > +   struct rte_eth_dev *dev;
> > +
> > +   if (sh->port[i].ih_port_id >= RTE_MAX_ETHPORTS) {
> > +   /*
> > +* Or not existing port either no
> > +* handler installed for this port.
> > +*/
> > +   continue;
> > +   }
> > +   dev = &rte_eth_devices[sh->port[i].ih_port_id];
> > +   assert(dev);
> > +   if (dev->data->dev_conf.intr_conf.rmv)
> > +   _rte_eth_dev_callback_process
> > +   (dev, RTE_ETH_EVENT_INTR_RMV, NULL);
> > +   }
> > +}
> > +
> > +/**
> >   * Handle shared asynchronous events the NIC (removal event
> >   * and link status change). Supports multiport IB device.
> >   *
> > @@ -1137,21 +1166,46 @@ int mlx5_fw_version_get(struct rte_eth_dev
> > *dev, char *fw_ver, size_t fw_size)
> > break;
> > /* Retrieve and check IB port index. */
> > tmp = (uint32_t)event.element.port_num;
> > -   assert(tmp && (tmp <= sh->max_port));
> > -   if (!tmp ||
> > -   tmp > sh->max_port ||
> > -   sh->port[tmp - 1].ih_port_id >= RTE_MAX_ETHPORTS) {
> > +   if (!tmp && event.event_type ==
> > IBV_EVENT_DEVICE_FATAL) {
> > /*
> > -* Invalid IB port index or no handler
> > -* installed for this port.
> > +* The DEVICE_FATAL event is called once for
> > +* entire device without port specifying.
> > +* We should notify all existing ports.
> >  */
> > mlx5_glue->ack_async_event(&event);
> > +   mlx5_dev_interrupt_device_fatal(sh);
> > +   continue;
> > +   }
> > +   assert(tmp && (tmp <= sh->max_port));
> > +   if (!tmp) {
> > +   /* Unsupported devive level event. */
> > +   mlx5_glue->ack_async_event(&event);
> > +   DRV_LOG(DEBUG,
> > +   "unsupported common event (type %d)",
> > +   event.event_type);
> > +   continue;
> > +   }
> > +   if (tmp > sh->max_port) {
> > +   /* Invalid IB port index. */
> > +   mlx5_glue->ack_async_event(&event);
> > +   DRV_LOG(DEBUG,
> > +   "cannot handle an event (type %d)"
> > +   "due to invalid IB port index (%u)",
> > +   event.event_type, tmp);
> > +   continue;
> > +   }
> > +

[dpdk-dev] [PATCH] doc: fix update release notes for Mellanox drivers

2019-05-12 Thread Ori Kam

This patch adds some missing features to Mellanox drivers release notes.
It also updates the mlx5/mlx4 documentations.

Fixes: d85b204b5dba ("doc: update release notes for Mellanox drivers")
Cc: ys...@mellanox.com

Signed-off-by: Ori Kam 
---
 doc/guides/nics/mlx4.rst   |   2 +-
 doc/guides/nics/mlx5.rst   | 150 ++---
 doc/guides/rel_notes/release_19_05.rst |  10 ++-
 3 files changed, 109 insertions(+), 53 deletions(-)

diff --git a/doc/guides/nics/mlx4.rst b/doc/guides/nics/mlx4.rst
index f6d7a16..5c6bbde 100644
--- a/doc/guides/nics/mlx4.rst
+++ b/doc/guides/nics/mlx4.rst
@@ -253,7 +253,7 @@ thanks to these environment variables:
 Mellanox OFED as a fallback
 ~~~
 
-- `Mellanox OFED`_ version: **4.4, 4.5**.
+- `Mellanox OFED`_ version: **4.4, 4.5, 4.6**.
 - firmware version: **2.42.5000** and above.
 
 .. _`Mellanox OFED`: 
http://www.mellanox.com/page/products_dyn?product_family=26&mtag=linux_sw_drivers
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 325e9f6..175b6d0 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -7,7 +7,7 @@ MLX5 poll mode driver
 
 The MLX5 poll mode driver library (**librte_pmd_mlx5**) provides support
 for **Mellanox ConnectX-4**, **Mellanox ConnectX-4 Lx** , **Mellanox
-ConnectX-5**, **Mellanox ConnectX-6** and **Mellanox Bluefield** families
+ConnectX-5**, **Mellanox ConnectX-6** and **Mellanox BlueField** families
 of 10/25/40/50/100/200 Gb/s adapters as well as their virtual functions (VF)
 in SR-IOV context.
 
@@ -62,8 +62,8 @@ Features
 - RX VLAN stripping.
 - TX VLAN insertion.
 - RX CRC stripping configuration.
-- Promiscuous mode.
-- Multicast promiscuous mode.
+- Promiscuous mode on PF and VF.
+- Multicast promiscuous mode on PF and VF.
 - Hardware checksum offloads.
 - Flow director (RTE_FDIR_MODE_PERFECT, RTE_FDIR_MODE_PERFECT_MAC_VLAN and
   RTE_ETH_FDIR_REJECT).
@@ -78,6 +78,11 @@ Features
 - Rx HW timestamp.
 - Tunnel types: VXLAN, L3 VXLAN, VXLAN-GPE, GRE, MPLSoGRE, MPLSoUDP.
 - Tunnel HW offloads: packet type, inner/outer RSS, IP and UDP checksum 
verification.
+- Nic HW offloads: encapsulation (vxlan, gre, mplsoudp, mplsogre), NAT, 
routing, TTL
+  increment/decrement, count, drop, mark. For details please see 
:ref:`Supported hardware offloads using rte_flow API`.
+- Flow insertion rate of more then million flows per second. When using Direct 
Rules.
+- Support groups.
+- Support raw encapsulation offload.
 
 Limitations
 ---
@@ -112,8 +117,6 @@ Limitations
   is set to multi-packet send or Enhanced multi-packet send. Otherwise it must 
have
   less than 50 segments.
 
-- Count action for RTE flow is **only supported in Mellanox OFED**.
-
 - Flows with a VXLAN Network Identifier equal (or ends to be equal)
   to 0 are not supported.
 
@@ -124,13 +127,6 @@ Limitations
 - VF: flow rules created on VF devices can only match traffic targeted at the
   configured MAC addresses (see ``rte_eth_dev_mac_addr_add()``).
 
-.. note::
-
-   MAC addresses not already present in the bridge table of the associated
-   kernel network device will be added and cleaned up by the PMD when closing
-   the device. In case of ungraceful program termination, some entries may
-   remain present and should be removed manually by other means.
-
 - When Multi-Packet Rx queue is configured (``mprq_en``), a Rx packet can be
   externally attached to a user-provided mbuf with having EXT_ATTACHED_MBUF in
   ol_flags. As the mempool for the external buffer is managed by PMD, all the
@@ -147,30 +143,18 @@ Limitations
   To receive IPv6 Multicast messages on VM, explicitly set the relevant
   MAC address using rte_eth_dev_mac_addr_add() API.
 
-- E-Switch VXLAN tunnel is not supported together with outer VLAN.
-
-- E-Switch Flows with VNI pattern must include the VXLAN decapsulation action.
-
-- E-Switch VXLAN decapsulation Flow:
+- E-Switch decapsulation Flow:
 
   - can be applied to PF port only.
   - must specify VF port action (packet redirection from PF to VF).
-  - must specify tunnel outer UDP local (destination) port, wildcards not 
allowed.
-  - must specify tunnel outer VNI, wildcards not allowed.
-  - must specify tunnel outer local (destination)  IPv4 or IPv6 address, 
wildcards not allowed.
-  - optionally may specify tunnel outer remote (source) IPv4 or IPv6, 
wildcards or group IPs allowed.
   - optionally may specify tunnel inner source and destination MAC addresses.
 
-- E-Switch VXLAN encapsulation Flow:
+- E-Switch  encapsulation Flow:
 
   - can be applied to VF ports only.
   - must specify PF port action (packet redirection from VF to PF).
-  - must specify the VXLAN item with tunnel outer parameters.
-  - must specify the tunnel outer VNI in the VXLAN item.
-  - must specify the tunnel outer remote (destination) UDP port in the VXLAN 
item.
-  - must specify the tunnel outer local (source) IPv4 or IPv6 in the , this 
address will locally (with sc

[dpdk-dev] [PATCH v2] doc: fix update release notes for Mellanox drivers

2019-05-12 Thread Ori Kam

This patch adds some missing features to Mellanox drivers release notes.
It also updates the mlx5/mlx4 documentations.

Fixes: d85b204b5dba ("doc: update release notes for Mellanox drivers")
Cc: ys...@mellanox.com

Signed-off-by: Ori Kam 

---

v2:
 * fix checkpatch warning.

---
 doc/guides/nics/mlx4.rst   |   2 +-
 doc/guides/nics/mlx5.rst   | 150 ++---
 doc/guides/rel_notes/release_19_05.rst |  10 ++-
 3 files changed, 109 insertions(+), 53 deletions(-)

diff --git a/doc/guides/nics/mlx4.rst b/doc/guides/nics/mlx4.rst
index f6d7a16..5c6bbde 100644
--- a/doc/guides/nics/mlx4.rst
+++ b/doc/guides/nics/mlx4.rst
@@ -253,7 +253,7 @@ thanks to these environment variables:
 Mellanox OFED as a fallback
 ~~~
 
-- `Mellanox OFED`_ version: **4.4, 4.5**.
+- `Mellanox OFED`_ version: **4.4, 4.5, 4.6**.
 - firmware version: **2.42.5000** and above.
 
 .. _`Mellanox OFED`: 
http://www.mellanox.com/page/products_dyn?product_family=26&mtag=linux_sw_drivers
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 325e9f6..5cf7744 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -7,7 +7,7 @@ MLX5 poll mode driver
 
 The MLX5 poll mode driver library (**librte_pmd_mlx5**) provides support
 for **Mellanox ConnectX-4**, **Mellanox ConnectX-4 Lx** , **Mellanox
-ConnectX-5**, **Mellanox ConnectX-6** and **Mellanox Bluefield** families
+ConnectX-5**, **Mellanox ConnectX-6** and **Mellanox BlueField** families
 of 10/25/40/50/100/200 Gb/s adapters as well as their virtual functions (VF)
 in SR-IOV context.
 
@@ -62,8 +62,8 @@ Features
 - RX VLAN stripping.
 - TX VLAN insertion.
 - RX CRC stripping configuration.
-- Promiscuous mode.
-- Multicast promiscuous mode.
+- Promiscuous mode on PF and VF.
+- Multicast promiscuous mode on PF and VF.
 - Hardware checksum offloads.
 - Flow director (RTE_FDIR_MODE_PERFECT, RTE_FDIR_MODE_PERFECT_MAC_VLAN and
   RTE_ETH_FDIR_REJECT).
@@ -78,6 +78,11 @@ Features
 - Rx HW timestamp.
 - Tunnel types: VXLAN, L3 VXLAN, VXLAN-GPE, GRE, MPLSoGRE, MPLSoUDP.
 - Tunnel HW offloads: packet type, inner/outer RSS, IP and UDP checksum 
verification.
+- Nic HW offloads: encapsulation (vxlan, gre, mplsoudp, mplsogre), NAT, 
routing, TTL
+  increment/decrement, count, drop, mark. For details please see 
:ref:`Supported hardware offloads using rte_flow API`.
+- Flow insertion rate of more then million flows per second. When using Direct 
Rules.
+- Support groups.
+- Support raw encapsulation offload.
 
 Limitations
 ---
@@ -112,8 +117,6 @@ Limitations
   is set to multi-packet send or Enhanced multi-packet send. Otherwise it must 
have
   less than 50 segments.
 
-- Count action for RTE flow is **only supported in Mellanox OFED**.
-
 - Flows with a VXLAN Network Identifier equal (or ends to be equal)
   to 0 are not supported.
 
@@ -124,13 +127,6 @@ Limitations
 - VF: flow rules created on VF devices can only match traffic targeted at the
   configured MAC addresses (see ``rte_eth_dev_mac_addr_add()``).
 
-.. note::
-
-   MAC addresses not already present in the bridge table of the associated
-   kernel network device will be added and cleaned up by the PMD when closing
-   the device. In case of ungraceful program termination, some entries may
-   remain present and should be removed manually by other means.
-
 - When Multi-Packet Rx queue is configured (``mprq_en``), a Rx packet can be
   externally attached to a user-provided mbuf with having EXT_ATTACHED_MBUF in
   ol_flags. As the mempool for the external buffer is managed by PMD, all the
@@ -147,30 +143,18 @@ Limitations
   To receive IPv6 Multicast messages on VM, explicitly set the relevant
   MAC address using rte_eth_dev_mac_addr_add() API.
 
-- E-Switch VXLAN tunnel is not supported together with outer VLAN.
-
-- E-Switch Flows with VNI pattern must include the VXLAN decapsulation action.
-
-- E-Switch VXLAN decapsulation Flow:
+- E-Switch decapsulation Flow:
 
   - can be applied to PF port only.
   - must specify VF port action (packet redirection from PF to VF).
-  - must specify tunnel outer UDP local (destination) port, wildcards not 
allowed.
-  - must specify tunnel outer VNI, wildcards not allowed.
-  - must specify tunnel outer local (destination)  IPv4 or IPv6 address, 
wildcards not allowed.
-  - optionally may specify tunnel outer remote (source) IPv4 or IPv6, 
wildcards or group IPs allowed.
   - optionally may specify tunnel inner source and destination MAC addresses.
 
-- E-Switch VXLAN encapsulation Flow:
+- E-Switch  encapsulation Flow:
 
   - can be applied to VF ports only.
   - must specify PF port action (packet redirection from VF to PF).
-  - must specify the VXLAN item with tunnel outer parameters.
-  - must specify the tunnel outer VNI in the VXLAN item.
-  - must specify the tunnel outer remote (destination) UDP port in the VXLAN 
item.
-  - must specify the tunnel outer local (source) IPv4 or IPv6 in the

Re: [dpdk-dev] [PATCH] net/ixgbe: fix cancel link handler when port is being removed

2019-05-12 Thread Zhao1, Wei

Thank you for your more info!

Acked-by: Wei Zhao 



> -Original Message-
> From: wangyunjian [mailto:wangyunj...@huawei.com]
> Sent: Friday, May 10, 2019 7:38 PM
> To: Zhao1, Wei ; dev@dpdk.org
> Cc: i.maxim...@samsung.com; xudingke ;
> sta...@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH] net/ixgbe: fix cancel link handler when port 
> is
> being removed
> 
> 
> 
> > -Original Message-
> > From: Zhao1, Wei [mailto:wei.zh...@intel.com]
> > Sent: Friday, May 10, 2019 11:14 AM
> > To: wangyunjian ; dev@dpdk.org
> > Cc: i.maxim...@samsung.com; xudingke ;
> > sta...@dpdk.org
> > Subject: RE: [dpdk-dev] [PATCH] net/ixgbe: fix cancel link handler
> > when port is being removed
> >
> > Hi,  wangyunjian
> >
> > May I ask some more info about it?
> > Sure, we may this handler in ixgbe_dev_link_update_share (),  but we
> > have "rte_eal_alarm_cancel(ixgbe_dev_setup_link_alarm_handler, dev)"
> > in function ixgbe_dev_stop() and ixgbevf_dev_stop() to  cancel this handler.
> > If you want to remove dev, you will call ixgbe_dev_stop() first, RIGHT?
> > Maybe there is an accidental situation that some interrupt like LSC
> > trigger
> > ixgbe_dev_link_update() to set setup_link_alarm_handler just after dev stop?
> > Then we need to cancel it in eth_ixgbe_dev_uninit().
> > Is you issue the same as above or other?
> 
> Yes,  it is as above. It is easy to reproduce through fault injection. As 
> follow:
> 
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index 975fa47..a1e93c0 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -4055,7 +4055,7 @@ static int
> ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev,
> if (link_up == 0) {
> if (ixgbe_get_media_type(hw) == ixgbe_media_type_fiber) {
> intr->flags |= IXGBE_FLAG_NEED_LINK_CONFIG;
> -   rte_eal_alarm_set(10,
> +   rte_eal_alarm_set(500 * 1000,
> ixgbe_dev_setup_link_alarm_handler, dev);
> }
> return rte_eth_linkstatus_set(dev, &link);
> 
> >
> >
> > > -Original Message-
> > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of wangyunjian
> > > Sent: Wednesday, May 8, 2019 8:52 PM
> > > To: dev@dpdk.org
> > > Cc: i.maxim...@samsung.com; xudin...@huawei.com; Yunjian Wang
> > > ; sta...@dpdk.org
> > > Subject: [dpdk-dev] [PATCH] net/ixgbe: fix cancel link handler when
> > > port is being removed
> > >
> > > From: Yunjian Wang 
> > >
> > > The nic's interrupt source has some active handler, which maybe call
> > > ixgbe_dev_link_update() to set link handler. We should cancel the
> > > link handler before remove dev to prevent executing the link handler.
> > > It triggers segfault.
> > >
> > > Fixes: 0408f47ba4d6 ("net/ixgbe: fix busy polling while fiber link
> > > update")
> > > Cc: sta...@dpdk.org
> > >
> > > Signed-off-by: Yunjian Wang 
> > > ---
> > >  drivers/net/ixgbe/ixgbe_ethdev.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> > > b/drivers/net/ixgbe/ixgbe_ethdev.c
> > > index 975fa47..2470c89 100644
> > > --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> > > +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> > > @@ -1344,6 +1344,9 @@ struct rte_ixgbe_xstats_name_off {
> > >   /* cancel the delay handler before remove dev */
> > >   rte_eal_alarm_cancel(ixgbe_dev_interrupt_delayed_handler,
> > eth_dev);
> > >
> > > + /* cancel the link handler before remove dev */
> > > + rte_eal_alarm_cancel(ixgbe_dev_setup_link_alarm_handler,
> > eth_dev);
> > > +
> > >   /* uninitialize PF if max_vfs not zero */
> > >   ixgbe_pf_host_uninit(eth_dev);
> > >
> > > --
> > > 1.8.3.1
> > >

Re: [dpdk-dev] [PATCH v2] app/testpmd: remove port stop check for macsec

2019-05-12 Thread Zhao1, Wei

Tested-by: Peng Yuan 


> -Original Message-
> From: Zhao1, Wei
> Sent: Friday, May 10, 2019 4:41 PM
> To: dev@dpdk.org
> Cc: sta...@dpdk.org; Peng, Yuan ; Yigit, Ferruh
> ; Lu, Wenzhuo ; Zhao1, Wei
> 
> Subject: [PATCH v2] app/testpmd: remove port stop check for macsec
> 
> There is no need to do such a check when set macsec for ixgbe,
> reconfig_device_queueand is also useless. If we do not delete this unnessary
> code, users have to sotp port before enable or disable macsec, then restart 
> this
> port after make configuration. All these process is useless. As this cmdline 
> is a
> private API which is only used by ixgbe NIC, so remove it.
> 
> Fixes: 597f9fafe13b ("app/testpmd: convert to new Tx offloads API")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Wei Zhao 
> 
> ---
> 
> v2:
> -update log info and delete code in disable function
> ---
>  app/test-pmd/cmdline.c | 10 --
>  1 file changed, 10 deletions(-)
> 
> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> c1042dd..dd0f698 100644
> --- a/app/test-pmd/cmdline.c
> +++ b/app/test-pmd/cmdline.c
> @@ -14044,10 +14044,6 @@ cmd_set_macsec_offload_on_parsed(
> 
>   if (port_id_is_invalid(port_id, ENABLED_WARN))
>   return;
> - if (!port_is_stopped(port_id)) {
> - printf("Please stop port %d first\n", port_id);
> - return;
> - }
> 
>   rte_eth_dev_info_get(port_id, &dev_info);
>   if (dev_info.tx_offload_capa & DEV_TX_OFFLOAD_MACSEC_INSERT)
> { @@ -14062,7 +14058,6 @@ cmd_set_macsec_offload_on_parsed(
>   case 0:
>   ports[port_id].dev_conf.txmode.offloads |=
> 
>   DEV_TX_OFFLOAD_MACSEC_INSERT;
> - cmd_reconfig_device_queue(port_id, 1, 1);
>   break;
>   case -ENODEV:
>   printf("invalid port_id %d\n", port_id); @@ -14138,10 +14133,6
> @@ cmd_set_macsec_offload_off_parsed(
> 
>   if (port_id_is_invalid(port_id, ENABLED_WARN))
>   return;
> - if (!port_is_stopped(port_id)) {
> - printf("Please stop port %d first\n", port_id);
> - return;
> - }
> 
>   rte_eth_dev_info_get(port_id, &dev_info);
>   if (dev_info.tx_offload_capa & DEV_TX_OFFLOAD_MACSEC_INSERT)
> { @@ -14153,7 +14144,6 @@ cmd_set_macsec_offload_off_parsed(
>   case 0:
>   ports[port_id].dev_conf.txmode.offloads &=
> 
>   ~DEV_TX_OFFLOAD_MACSEC_INSERT;
> - cmd_reconfig_device_queue(port_id, 1, 1);
>   break;
>   case -ENODEV:
>   printf("invalid port_id %d\n", port_id);
> --
> 2.7.5

Re: [dpdk-dev] [PATCH] app/testpmd: fix offloads overwrite by default configuration

2019-05-12 Thread Zhao1, Wei

Tested-by: Peng Yuan 


> -Original Message-
> From: Zhao1, Wei
> Sent: Thursday, May 9, 2019 3:21 PM
> To: dev@dpdk.org
> Cc: sta...@dpdk.org; Peng, Yuan ; Yigit, Ferruh
> ; Lu, Wenzhuo ; Zhao1, Wei
> 
> Subject: [PATCH] app/testpmd: fix offloads overwrite by default configuration
> 
> There is an error in function rxtx_port_config(), which may overwrite offloads
> configuration get from function launch_args_parse() when run testpmd app. So
> rxtx_port_config() should do "or" for port offloads.
> 
> Fixes: d44f8a485f5d ("app/testpmd: enable per queue configure")
> cc: sta...@dpdk.org
> 
> Signed-off-by: Wei Zhao 
> ---
>  app/test-pmd/testpmd.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
> 6fbfd29..f0061d9 100644
> --- a/app/test-pmd/testpmd.c
> +++ b/app/test-pmd/testpmd.c
> @@ -2809,9 +2809,12 @@ static void
>  rxtx_port_config(struct rte_port *port)  {
>   uint16_t qid;
> + uint64_t offloads;
> 
>   for (qid = 0; qid < nb_rxq; qid++) {
> + offloads = port->rx_conf[qid].offloads;
>   port->rx_conf[qid] = port->dev_info.default_rxconf;
> + port->rx_conf[qid].offloads |= offloads;
> 
>   /* Check if any Rx parameters have been passed */
>   if (rx_pthresh != RTE_PMD_PARAM_UNSET) @@ -2833,7
> +2836,9 @@ rxtx_port_config(struct rte_port *port)
>   }
> 
>   for (qid = 0; qid < nb_txq; qid++) {
> + offloads = port->tx_conf[qid].offloads;
>   port->tx_conf[qid] = port->dev_info.default_txconf;
> + port->tx_conf[qid].offloads |= offloads;
> 
>   /* Check if any Tx parameters have been passed */
>   if (tx_pthresh != RTE_PMD_PARAM_UNSET)
> --
> 2.7.5

Re: [dpdk-dev] [dpdk-stable] [PATCH v3] eventdev: fix Rx adapter event flush logic

2019-05-12 Thread Elo, Matias (Nokia - FI/Espoo)



> On 2019-05-10 15:30, Thomas Monjalon wrote:
>> Any review please?
> 
> Reviewed-by: Mattias Rönnblom 
> 
> Mattias Elo reported "Thanks, I’ve tested this patch and can confirm that it 
> fixes the problem." for the (nearly identical) v2 of this patch.

I’ve now tested also the v3:

Tested-by: Matias Elo

[dpdk-dev] [Crypto-PMD and Libraries] Suggestions on porting/attaching existing libraries with Crypto PMDS

2019-05-12 Thread Suraj R Gupta

Hi,
This is in regards with using Cryptographic libraries with DPDK crypto
PMDs. Intel has its own Cryptographic libraries for various algorithms
hosted in git and some restricted channels.
I would like to know if any other library can be attached to the Crypto Pmd.

For e.g. I would like to know if any Kasumi algorithm library can be
attached with Kasumi Crypto PMD.

I would like to have your suggestions and help in this regard.

-- 
Thanks and Regards
Suraj R Gupta

Re: [dpdk-dev] [PATCH v2] doc: fix update release notes for Mellanox drivers

2019-05-12 Thread Shahaf Shuler

Hi Ori,

See some comments below. 

Sunday, May 12, 2019 11:33 PM, Ori Kam:
> Subject: [dpdk-dev] [PATCH v2] doc: fix update release notes for Mellanox
> drivers
> 
> This patch adds some missing features to Mellanox drivers release notes.
> It also updates the mlx5/mlx4 documentations.
> 
> Fixes: d85b204b5dba ("doc: update release notes for Mellanox drivers")
> Cc: ys...@mellanox.com
> 
> Signed-off-by: Ori Kam 
> 
> ---
> 
> v2:
>  * fix checkpatch warning.
> 
> ---
>  doc/guides/nics/mlx4.rst   |   2 +-
>  doc/guides/nics/mlx5.rst   | 150 
> ++---
>  doc/guides/rel_notes/release_19_05.rst |  10 ++-
>  3 files changed, 109 insertions(+), 53 deletions(-)
> 
> diff --git a/doc/guides/nics/mlx4.rst b/doc/guides/nics/mlx4.rst index
> f6d7a16..5c6bbde 100644
> --- a/doc/guides/nics/mlx4.rst
> +++ b/doc/guides/nics/mlx4.rst
> @@ -253,7 +253,7 @@ thanks to these environment variables:
>  Mellanox OFED as a fallback
>  ~~~
> 
> -- `Mellanox OFED`_ version: **4.4, 4.5**.
> +- `Mellanox OFED`_ version: **4.4, 4.5, 4.6**.
>  - firmware version: **2.42.5000** and above.
> 
>  .. _`Mellanox OFED`:
> http://www.mellanox.com/page/products_dyn?product_family=26&mtag=li
> nux_sw_drivers
> diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst index
> 325e9f6..5cf7744 100644
> --- a/doc/guides/nics/mlx5.rst
> +++ b/doc/guides/nics/mlx5.rst
> @@ -7,7 +7,7 @@ MLX5 poll mode driver
> 
>  The MLX5 poll mode driver library (**librte_pmd_mlx5**) provides support
> for **Mellanox ConnectX-4**, **Mellanox ConnectX-4 Lx** , **Mellanox -
> ConnectX-5**, **Mellanox ConnectX-6** and **Mellanox Bluefield**
> families
> +ConnectX-5**, **Mellanox ConnectX-6** and **Mellanox BlueField**
> +families
>  of 10/25/40/50/100/200 Gb/s adapters as well as their virtual functions (VF)
> in SR-IOV context.
> 
> @@ -62,8 +62,8 @@ Features
>  - RX VLAN stripping.
>  - TX VLAN insertion.
>  - RX CRC stripping configuration.
> -- Promiscuous mode.
> -- Multicast promiscuous mode.
> +- Promiscuous mode on PF and VF.
> +- Multicast promiscuous mode on PF and VF.
>  - Hardware checksum offloads.
>  - Flow director (RTE_FDIR_MODE_PERFECT,
> RTE_FDIR_MODE_PERFECT_MAC_VLAN and
>RTE_ETH_FDIR_REJECT).
> @@ -78,6 +78,11 @@ Features
>  - Rx HW timestamp.
>  - Tunnel types: VXLAN, L3 VXLAN, VXLAN-GPE, GRE, MPLSoGRE, MPLSoUDP.
>  - Tunnel HW offloads: packet type, inner/outer RSS, IP and UDP checksum
> verification.
> +- Nic HW offloads: encapsulation (vxlan, gre, mplsoudp, mplsogre), NAT,
> +routing, TTL
> +  increment/decrement, count, drop, mark. For details please see
> :ref:`Supported hardware offloads using rte_flow API`.
> +- Flow insertion rate of more then million flows per second. When using
> Direct Rules.

Replace '.' with ',' .

> +- Support groups.

Support for multiple rte_flow groups.

> +- Support raw encapsulation offload.

Can't it be part of the encapsulation part above?

> 
>  Limitations
>  ---
> @@ -112,8 +117,6 @@ Limitations
>is set to multi-packet send or Enhanced multi-packet send. Otherwise it
> must have
>less than 50 segments.
> 
> -- Count action for RTE flow is **only supported in Mellanox OFED**.
> -
>  - Flows with a VXLAN Network Identifier equal (or ends to be equal)
>to 0 are not supported.
> 
> @@ -124,13 +127,6 @@ Limitations
>  - VF: flow rules created on VF devices can only match traffic targeted at the
>configured MAC addresses (see ``rte_eth_dev_mac_addr_add()``).
> 
> -.. note::
> -
> -   MAC addresses not already present in the bridge table of the associated
> -   kernel network device will be added and cleaned up by the PMD when
> closing
> -   the device. In case of ungraceful program termination, some entries may
> -   remain present and should be removed manually by other means.
> -

This is still correct, why removed?

>  - When Multi-Packet Rx queue is configured (``mprq_en``), a Rx packet can
> be
>externally attached to a user-provided mbuf with having
> EXT_ATTACHED_MBUF in
>ol_flags. As the mempool for the external buffer is managed by PMD, all
> the @@ -147,30 +143,18 @@ Limitations
>To receive IPv6 Multicast messages on VM, explicitly set the relevant
>MAC address using rte_eth_dev_mac_addr_add() API.
> 
> -- E-Switch VXLAN tunnel is not supported together with outer VLAN.
> -
> -- E-Switch Flows with VNI pattern must include the VXLAN decapsulation
> action.
> -
> -- E-Switch VXLAN decapsulation Flow:
> +- E-Switch decapsulation Flow:
> 
>- can be applied to PF port only.
>- must specify VF port action (packet redirection from PF to VF).
> -  - must specify tunnel outer UDP local (destination) port, wildcards not
> allowed.
> -  - must specify tunnel outer VNI, wildcards not allowed.
> -  - must specify tunnel outer local (destination)  IPv4 or IPv6 address,
> wildcards not allowed.
> -  - optionally may specify tunnel outer remote (source) IPv4 or IPv6,
> wildcards or

Re: [dpdk-dev] [PATCH v2] doc: fix update release notes for Mellanox drivers

2019-05-12 Thread Ori Kam

Hi,

PSB

> -Original Message-
> From: Shahaf Shuler
> Sent: Monday, May 13, 2019 8:26 AM
> To: Ori Kam ; Yongseok Koh ;
> Matan Azrad ; Thomas Monjalon
> 
> Cc: dev@dpdk.org; Ori Kam 
> Subject: RE: [dpdk-dev] [PATCH v2] doc: fix update release notes for Mellanox
> drivers
> 
> Hi Ori,
> 
> See some comments below.
> 
> Sunday, May 12, 2019 11:33 PM, Ori Kam:
> > Subject: [dpdk-dev] [PATCH v2] doc: fix update release notes for Mellanox
> > drivers
> >
> > This patch adds some missing features to Mellanox drivers release notes.
> > It also updates the mlx5/mlx4 documentations.
> >
> > Fixes: d85b204b5dba ("doc: update release notes for Mellanox drivers")
> > Cc: ys...@mellanox.com
> >
> > Signed-off-by: Ori Kam 
> >
> > ---
> >
> > v2:
> >  * fix checkpatch warning.
> >
> > ---
> >  doc/guides/nics/mlx4.rst   |   2 +-
> >  doc/guides/nics/mlx5.rst   | 150 
> > ++---
> >  doc/guides/rel_notes/release_19_05.rst |  10 ++-
> >  3 files changed, 109 insertions(+), 53 deletions(-)
> >
> > diff --git a/doc/guides/nics/mlx4.rst b/doc/guides/nics/mlx4.rst index
> > f6d7a16..5c6bbde 100644
> > --- a/doc/guides/nics/mlx4.rst
> > +++ b/doc/guides/nics/mlx4.rst
> > @@ -253,7 +253,7 @@ thanks to these environment variables:
> >  Mellanox OFED as a fallback
> >  ~~~
> >
> > -- `Mellanox OFED`_ version: **4.4, 4.5**.
> > +- `Mellanox OFED`_ version: **4.4, 4.5, 4.6**.
> >  - firmware version: **2.42.5000** and above.
> >
> >  .. _`Mellanox OFED`:
> > http://www.mellanox.com/page/products_dyn?product_family=26&mtag=li
> > nux_sw_drivers
> > diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst index
> > 325e9f6..5cf7744 100644
> > --- a/doc/guides/nics/mlx5.rst
> > +++ b/doc/guides/nics/mlx5.rst
> > @@ -7,7 +7,7 @@ MLX5 poll mode driver
> >
> >  The MLX5 poll mode driver library (**librte_pmd_mlx5**) provides support
> > for **Mellanox ConnectX-4**, **Mellanox ConnectX-4 Lx** , **Mellanox -
> > ConnectX-5**, **Mellanox ConnectX-6** and **Mellanox Bluefield**
> > families
> > +ConnectX-5**, **Mellanox ConnectX-6** and **Mellanox BlueField**
> > +families
> >  of 10/25/40/50/100/200 Gb/s adapters as well as their virtual functions 
> > (VF)
> > in SR-IOV context.
> >
> > @@ -62,8 +62,8 @@ Features
> >  - RX VLAN stripping.
> >  - TX VLAN insertion.
> >  - RX CRC stripping configuration.
> > -- Promiscuous mode.
> > -- Multicast promiscuous mode.
> > +- Promiscuous mode on PF and VF.
> > +- Multicast promiscuous mode on PF and VF.
> >  - Hardware checksum offloads.
> >  - Flow director (RTE_FDIR_MODE_PERFECT,
> > RTE_FDIR_MODE_PERFECT_MAC_VLAN and
> >RTE_ETH_FDIR_REJECT).
> > @@ -78,6 +78,11 @@ Features
> >  - Rx HW timestamp.
> >  - Tunnel types: VXLAN, L3 VXLAN, VXLAN-GPE, GRE, MPLSoGRE, MPLSoUDP.
> >  - Tunnel HW offloads: packet type, inner/outer RSS, IP and UDP checksum
> > verification.
> > +- Nic HW offloads: encapsulation (vxlan, gre, mplsoudp, mplsogre), NAT,
> > +routing, TTL
> > +  increment/decrement, count, drop, mark. For details please see
> > :ref:`Supported hardware offloads using rte_flow API`.
> > +- Flow insertion rate of more then million flows per second. When using
> > Direct Rules.
> 
> Replace '.' with ',' .
> 

O.K

> > +- Support groups.
> 
> Support for multiple rte_flow groups.
> 

O.K

> > +- Support raw encapsulation offload.
> 
> Can't it be part of the encapsulation part above?
> 

Do you mean the tunnel HW offloads?
If yes I guess it can be there.

> >
> >  Limitations
> >  ---
> > @@ -112,8 +117,6 @@ Limitations
> >is set to multi-packet send or Enhanced multi-packet send. Otherwise it
> > must have
> >less than 50 segments.
> >
> > -- Count action for RTE flow is **only supported in Mellanox OFED**.
> > -
> >  - Flows with a VXLAN Network Identifier equal (or ends to be equal)
> >to 0 are not supported.
> >
> > @@ -124,13 +127,6 @@ Limitations
> >  - VF: flow rules created on VF devices can only match traffic targeted at 
> > the
> >configured MAC addresses (see ``rte_eth_dev_mac_addr_add()``).
> >
> > -.. note::
> > -
> > -   MAC addresses not already present in the bridge table of the associated
> > -   kernel network device will be added and cleaned up by the PMD when
> > closing
> > -   the device. In case of ungraceful program termination, some entries may
> > -   remain present and should be removed manually by other means.
> > -
> 
> This is still correct, why removed?
> 

Will return the code.

> >  - When Multi-Packet Rx queue is configured (``mprq_en``), a Rx packet can
> > be
> >externally attached to a user-provided mbuf with having
> > EXT_ATTACHED_MBUF in
> >ol_flags. As the mempool for the external buffer is managed by PMD, all
> > the @@ -147,30 +143,18 @@ Limitations
> >To receive IPv6 Multicast messages on VM, explicitly set the relevant
> >MAC address using rte_eth_dev_mac_addr_add() API.
> >
> > -- E-Switch VXLAN tunnel is not support

[dpdk-dev] [PATCH v2] net/mlx5: fix device removal handler for multiport device

Re: [dpdk-dev] [PATCH v2] net/mlx5: fix device removal handler for multiport device

Re: [dpdk-dev] [PATCH v2] net/mlx5: fix device removal handler for multiport device

[dpdk-dev] [PATCH] doc: fix update release notes for Mellanox drivers

[dpdk-dev] [PATCH v2] doc: fix update release notes for Mellanox drivers

Re: [dpdk-dev] [PATCH] net/ixgbe: fix cancel link handler when port is being removed

Re: [dpdk-dev] [PATCH v2] app/testpmd: remove port stop check for macsec

Re: [dpdk-dev] [PATCH] app/testpmd: fix offloads overwrite by default configuration

Re: [dpdk-dev] [dpdk-stable] [PATCH v3] eventdev: fix Rx adapter event flush logic

[dpdk-dev] [Crypto-PMD and Libraries] Suggestions on porting/attaching existing libraries with Crypto PMDS

Re: [dpdk-dev] [PATCH v2] doc: fix update release notes for Mellanox drivers

Re: [dpdk-dev] [PATCH v2] doc: fix update release notes for Mellanox drivers

12 matches

Site Navigation

Mail list logo

Footer information