[dpdk-dev] [PATCH v4 0/5] fix default max mtu size when device configured
testpmd will initialize default max packet length to 1518 which does't include vlan tag size in ether overheader. Once, send the max mtu length packet with vlan tag, the max packet length will exceed 1518 that will cause packets dropped directly from NIC hw side. configure the correct default max packet size in dev_config ops. v4: * add the adjust condition for max_rx_pkt_len; v3: * change the i40evf relative code; v2: * change the max_rx_pkt_len via mtu_set ops; SteveX Yang (5): net/e1000: fix max mtu size packets with vlan tag cannot be received by default net/igc: fix max mtu size packets with vlan tag cannot be received by default net/ice: fix max mtu size packets with vlan tag cannot be received by default net/i40e: fix max mtu size packets with vlan tag cannot be received by default net/iavf: fix max mtu size packets with vlan tag cannot be received by default drivers/net/e1000/em_ethdev.c | 12 drivers/net/i40e/i40e_ethdev.c| 11 +++ drivers/net/i40e/i40e_ethdev_vf.c | 13 - drivers/net/iavf/iavf_ethdev.c| 12 drivers/net/ice/ice_ethdev.c | 11 +++ drivers/net/igc/igc_ethdev.c | 13 - 6 files changed, 70 insertions(+), 2 deletions(-) -- 2.17.1
[dpdk-dev] [PATCH v4 2/5] net/igc: fix max mtu size packets with vlan tag cannot be received by default
testpmd will initialize default max packet length to 1518 which doesn't
include vlan tag size in ether overheader. Once, send the max mtu length
packet with vlan tag, the max packet length will exceed 1518 that will
cause packets dropped directly from NIC hw side.
igc can support single vlan tag that need more 4 bytes for max packet size,
so, configures the correct max packet size in dev_config ops.
Fixes: a5aeb2b9e225 ("net/igc: support Rx and Tx")
Signed-off-by: SteveX Yang
---
drivers/net/igc/igc_ethdev.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/net/igc/igc_ethdev.c b/drivers/net/igc/igc_ethdev.c
index 810568bc5..f47ea3e64 100644
--- a/drivers/net/igc/igc_ethdev.c
+++ b/drivers/net/igc/igc_ethdev.c
@@ -337,11 +337,22 @@ static int
eth_igc_configure(struct rte_eth_dev *dev)
{
struct igc_interrupt *intr = IGC_DEV_PRIVATE_INTR(dev);
+ uint32_t frame_size = dev->data->mtu + IGC_ETH_OVERHEAD;
int ret;
PMD_INIT_FUNC_TRACE();
- ret = igc_check_mq_mode(dev);
+ /**
+* Considering vlan tag packet, max frame size should be equal or
+* larger than total size of MTU and Ether overhead.
+*/
+ if (frame_size > dev->data->dev_conf.rxmode.max_rx_pkt_len) {
+ ret = eth_igc_mtu_set(dev, dev->data->mtu);
+ if (ret != 0)
+ return ret;
+ }
+
+ ret = igc_check_mq_mode(dev);
if (ret != 0)
return ret;
--
2.17.1
[dpdk-dev] [PATCH v4 1/5] net/e1000: fix max mtu size packets with vlan tag cannot be received by default
testpmd will initialize default max packet length to 1518 which doesn't
include vlan tag size in ether overheader. Once, send the max mtu length
packet with vlan tag, the max packet length will exceed 1518 that will
cause packets dropped directly from NIC hw side.
e1000 can support single vlan tags that need more 4 bytes for max packet
size, so, configures the correct max packet size in dev_config ops.
Fixes: 35b2d13fd6fd ("net: add rte prefix to ether defines")
Signed-off-by: SteveX Yang
---
drivers/net/e1000/em_ethdev.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index 1dc360713..96ff99951 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -437,10 +437,22 @@ eth_em_configure(struct rte_eth_dev *dev)
{
struct e1000_interrupt *intr =
E1000_DEV_PRIVATE_TO_INTR(dev->data->dev_private);
+ uint16_t frame_size = dev->data->mtu + E1000_ETH_OVERHEAD;
+ int rc = 0;
PMD_INIT_FUNC_TRACE();
intr->flags |= E1000_FLAG_NEED_LINK_UPDATE;
+ /**
+* Considering vlan tag packet, max frame size should be equal or
+* larger than total size of MTU and Ether overhead.
+*/
+ if (frame_size > dev->data->dev_conf.rxmode.max_rx_pkt_len) {
+ rc = eth_em_mtu_set(dev, dev->data->mtu);
+ if (rc != 0)
+ return rc;
+ }
+
PMD_INIT_FUNC_TRACE();
return 0;
--
2.17.1
[dpdk-dev] [PATCH v4 4/5] net/i40e: fix max mtu size packets with vlan tag cannot be received by default
testpmd will initialize default max packet length to 1518 which doesn't
include vlan tag size in ether overheader. Once, send the max mtu length
packet with vlan tag, the max packet length will exceed 1518 that will
cause packets dropped directly from NIC hw side. But for i40e/i40evf,
they should support dual vlan tags that need more 8 bytes for max packet
size, so, configure the correct max packet size in dev_config ops.
Fixes: ff8282f4bbcd ("net/i40e: consider QinQ when setting MTU")
Signed-off-by: SteveX Yang
---
drivers/net/i40e/i40e_ethdev.c| 11 +++
drivers/net/i40e/i40e_ethdev_vf.c | 13 -
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 6439baf2f..35ffe33ab 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -1916,6 +1916,7 @@ i40e_dev_configure(struct rte_eth_dev *dev)
struct i40e_pf *pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
enum rte_eth_rx_mq_mode mq_mode = dev->data->dev_conf.rxmode.mq_mode;
+ uint32_t frame_size = dev->data->mtu + I40E_ETH_OVERHEAD;
int i, ret;
ret = i40e_dev_sync_phy_type(hw);
@@ -1930,6 +1931,16 @@ i40e_dev_configure(struct rte_eth_dev *dev)
ad->tx_simple_allowed = true;
ad->tx_vec_allowed = true;
+ /**
+* Considering QinQ packet, max frame size should be equal or
+* larger than total size of MTU and Ether overhead.
+*/
+ if (frame_size > dev->data->dev_conf.rxmode.max_rx_pkt_len) {
+ ret = i40e_dev_mtu_set(dev, dev->data->mtu);
+ if (ret != 0)
+ return ret;
+ }
+
if (dev->data->dev_conf.rxmode.mq_mode & ETH_MQ_RX_RSS_FLAG)
dev->data->dev_conf.rxmode.offloads |= DEV_RX_OFFLOAD_RSS_HASH;
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c
b/drivers/net/i40e/i40e_ethdev_vf.c
index 8531cf6b1..e3c809037 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -1669,6 +1669,8 @@ i40evf_dev_configure(struct rte_eth_dev *dev)
I40E_DEV_PRIVATE_TO_ADAPTER(dev->data->dev_private);
uint16_t num_queue_pairs = RTE_MAX(dev->data->nb_rx_queues,
dev->data->nb_tx_queues);
+ uint32_t frame_size = dev->data->mtu + I40E_ETH_OVERHEAD;
+ int ret;
/* Initialize to TRUE. If any of Rx queues doesn't meet the bulk
* allocation or vector Rx preconditions we will reset it.
@@ -1681,9 +1683,18 @@ i40evf_dev_configure(struct rte_eth_dev *dev)
dev->data->dev_conf.intr_conf.lsc =
!!(dev->data->dev_flags & RTE_ETH_DEV_INTR_LSC);
+ /**
+* Considering QinQ packet, max frame size should be equal or
+* larger than total size of MTU and Ether overhead.
+*/
+ if (frame_size > dev->data->dev_conf.rxmode.max_rx_pkt_len) {
+ ret = i40evf_dev_mtu_set(dev, dev->data->mtu);
+ if (ret != 0)
+ return ret;
+ }
+
if (num_queue_pairs > vf->vsi_res->num_queue_pairs) {
struct i40e_hw *hw;
- int ret;
if (rte_eal_process_type() != RTE_PROC_PRIMARY) {
PMD_DRV_LOG(ERR,
--
2.17.1
[dpdk-dev] [PATCH v4 3/5] net/ice: fix max mtu size packets with vlan tag cannot be received by default
testpmd will initialize default max packet length to 1518 which doesn't
include vlan tag size in ether overheader. Once, send the max mtu length
packet with vlan tag, the max packet length will exceed 1518 that will
cause packets dropped directly from NIC hw side.
ice can support dual vlan tags that need more 8 bytes for max packet size,
so, configures the correct max packet size in dev_config ops.
Fixes: 50cc9d2a6e9d ("net/ice: fix max frame size")
Signed-off-by: SteveX Yang
---
drivers/net/ice/ice_ethdev.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c
index cfd357b05..6b7098444 100644
--- a/drivers/net/ice/ice_ethdev.c
+++ b/drivers/net/ice/ice_ethdev.c
@@ -3146,6 +3146,7 @@ ice_dev_configure(struct rte_eth_dev *dev)
struct ice_adapter *ad =
ICE_DEV_PRIVATE_TO_ADAPTER(dev->data->dev_private);
struct ice_pf *pf = ICE_DEV_PRIVATE_TO_PF(dev->data->dev_private);
+ uint32_t frame_size = dev->data->mtu + ICE_ETH_OVERHEAD;
int ret;
/* Initialize to TRUE. If any of Rx queues doesn't meet the
@@ -3157,6 +3158,16 @@ ice_dev_configure(struct rte_eth_dev *dev)
if (dev->data->dev_conf.rxmode.mq_mode & ETH_MQ_RX_RSS_FLAG)
dev->data->dev_conf.rxmode.offloads |= DEV_RX_OFFLOAD_RSS_HASH;
+ /**
+* Considering QinQ packet, max frame size should be equal or
+* larger than total size of MTU and Ether overhead.
+*/
+ if (frame_size > dev->data->dev_conf.rxmode.max_rx_pkt_len) {
+ ret = ice_mtu_set(dev, dev->data->mtu);
+ if (ret != 0)
+ return ret;
+ }
+
ret = ice_init_rss(pf);
if (ret) {
PMD_DRV_LOG(ERR, "Failed to enable rss for PF");
--
2.17.1
[dpdk-dev] [PATCH v4 5/5] net/iavf: fix max mtu size packets with vlan tag cannot be received by default
testpmd will initialize default max packet length to 1518 which doesn't
include vlan tag size in ether overheader. Once, send the max mtu length
packet with vlan tag, the max packet length will exceed 1518 that will
cause packets dropped directly from NIC hw side.
iavf can support dual vlan tags that need more 8 bytes for max packet size,
so, configures the correct max packet size in dev_config ops.
Fixes: 02d212ca3125 ("net/iavf: rename remaining avf strings")
Signed-off-by: SteveX Yang
---
drivers/net/iavf/iavf_ethdev.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/net/iavf/iavf_ethdev.c b/drivers/net/iavf/iavf_ethdev.c
index a88d53ab0..635d781eb 100644
--- a/drivers/net/iavf/iavf_ethdev.c
+++ b/drivers/net/iavf/iavf_ethdev.c
@@ -258,6 +258,8 @@ iavf_dev_configure(struct rte_eth_dev *dev)
IAVF_DEV_PRIVATE_TO_ADAPTER(dev->data->dev_private);
struct iavf_info *vf = IAVF_DEV_PRIVATE_TO_VF(ad);
struct rte_eth_conf *dev_conf = &dev->data->dev_conf;
+ uint32_t frame_size = dev->data->mtu + IAVF_ETH_OVERHEAD;
+ int ret;
ad->rx_bulk_alloc_allowed = true;
/* Initialize to TRUE. If any of Rx queues doesn't meet the
@@ -269,6 +271,16 @@ iavf_dev_configure(struct rte_eth_dev *dev)
if (dev->data->dev_conf.rxmode.mq_mode & ETH_MQ_RX_RSS_FLAG)
dev->data->dev_conf.rxmode.offloads |= DEV_RX_OFFLOAD_RSS_HASH;
+ /**
+* Considering QinQ packet, max frame size should be equal or
+* larger than total size of MTU and Ether overhead.
+*/
+ if (frame_size > dev->data->dev_conf.rxmode.max_rx_pkt_len) {
+ ret = iavf_dev_mtu_set(dev, dev->data->mtu);
+ if (ret != 0)
+ return ret;
+ }
+
/* Vlan stripping setting */
if (vf->vf_res->vf_cap_flags & VIRTCHNL_VF_OFFLOAD_VLAN) {
if (dev_conf->rxmode.offloads & DEV_RX_OFFLOAD_VLAN_STRIP)
--
2.17.1
Re: [dpdk-dev] [PATCH] net/ring: advertise multi segment support.
On 9/22/20 4:21 PM, Ferruh Yigit wrote: > On 9/18/2020 11:36 AM, Dumitru Ceara wrote: >> Even though ring interfaces don't support any other TX/RX offloads they >> do support sending multi segment packets and this should be advertised >> in order to not break applications that use ring interfaces. >> > > Does ring PMD support sending multi segmented packets? > Yes, sending multi segmented packets works fine with ring PMD. > As far as I can see ring PMD doesn't know about the mbuf segments. > Right, the PMD doesn't care about the mbuf segments but it implicitly supports sending multi segmented packets. From what I see it's actually the case for most of the PMDs, in the sense that most don't even check the DEV_TX_OFFLOAD_MULTI_SEGS flag and if the application sends multi segment packets they are just accepted. However, the fact that the ring PMD doesn't advertise this implicit support forces applications that use ring PMD to have a special case for handling ring interfaces. If the ring PMD would advertise DEV_TX_OFFLOAD_MULTI_SEGS this would allow upper layers to be oblivious to the type of underlying interface. Thanks, Dumitru
Re: [dpdk-dev] [PATCH V13 1/3] ethdev: introduce FEC API
On 9/25/20 11:39 AM, Min Hu (Connor) wrote:
> This patch adds Forward error correction(FEC) support for ethdev.
> Introduce APIs which support query and config FEC information in
> hardware.
>
> Signed-off-by: Min Hu (Connor)
> Reviewed-by: Wei Hu (Xavier)
> Reviewed-by: Chengwen Feng
> Reviewed-by: Chengchang Tang
With few nits below:
Acked-by: Andrew Rybchenko
> ---
> v12->v13:
> change fec get capa API.
> fix comment styles.
>
> ---
> v10->v11:
> allow to report capabilities per link speed.
> specify what should be reported if link is down
> when get FEC.
> change mode to capa bitmask.
>
> ---
> v9->v10:
> add macro RTE_ETH_FEC_MODE_CAPA_MASK(x) to indicate
> different FEC mode capa.
>
> ---
> v8->v9:
> added reviewed-by and acked-by.
>
> ---
> v7->v8:
> put AUTO just after NOFEC in rte_fec_mode definition.
>
> ---
> v6->v7:
> deleted RTE_ETH_FEC_NUM to prevent ABI breakage.
> add new macro to indicate translation from fec mode
> to capa.
>
> ---
> v5->v6:
> modified release notes.
> deleted check duplicated for FEC API
> fixed code styles according to DPDK coding style.
> added _eth prefix.
>
> ---
> v4->v5:
> Modifies FEC capa definitions using macros.
> Add RTE_ prefix for public FEC mode enum.
> add release notes about FEC for dpdk20_11.
>
> ---
> v2->v3:
> add function return value "-ENOTSUP" for API.
>
> ---
> doc/guides/rel_notes/release_20_11.rst | 5 ++
> lib/librte_ethdev/rte_ethdev.c | 43 +++
> lib/librte_ethdev/rte_ethdev.h | 94
>
> lib/librte_ethdev/rte_ethdev_driver.h| 80 +++
> lib/librte_ethdev/rte_ethdev_version.map | 3 +
> 5 files changed, 225 insertions(+)
>
> diff --git a/doc/guides/rel_notes/release_20_11.rst
> b/doc/guides/rel_notes/release_20_11.rst
> index c6642f5..1f04bd5 100644
> --- a/doc/guides/rel_notes/release_20_11.rst
> +++ b/doc/guides/rel_notes/release_20_11.rst
> @@ -78,6 +78,11 @@ New Features
> ``--portmask=N``
> where N represents the hexadecimal bitmask of ports used.
>
> +* **Added the FEC API, for a generic FEC query and config.**
> +
> + Added the FEC API which provides functions for query FEC capabilities and
> + current FEC mode from device. Also, API for configuring FEC mode is also
> provided.
> +
>
> Removed Items
> -
> diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
> index dfe5c1b..86ead87 100644
> --- a/lib/librte_ethdev/rte_ethdev.c
> +++ b/lib/librte_ethdev/rte_ethdev.c
> @@ -3679,6 +3679,49 @@ rte_eth_led_off(uint16_t port_id)
> return eth_err(port_id, (*dev->dev_ops->dev_led_off)(dev));
> }
>
> +int
> +rte_eth_fec_get_capability(uint16_t port_id,
> +struct rte_eth_fec_capa *speed_fec_capa,
> +unsigned int num)
> +{
> + struct rte_eth_dev *dev;
> + int ret;
if (speed_fec_capa == NULL && num > 0)
return -EINVAL;
> +
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> + dev = &rte_eth_devices[port_id];
> + RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->fec_get_capability, -ENOTSUP);
> + ret = (*dev->dev_ops->fec_get_capability)(dev, speed_fec_capa, num);
> + if (ret > (int)num)
> + RTE_ETHDEV_LOG(ERR, "Insufficient num, num should be no less
> than %d\n",
> +ret);
It is incorrect to log error, since
num = rte_eth_fec_get_capability(port_id, NULL, 0);
may be used to obtain required number of array elements
(nothing bad is happening).
> +
> + return ret;
> +}
> +
> +int
> +rte_eth_fec_get(uint16_t port_id, uint32_t *mode)
> +{
> + struct rte_eth_dev *dev;
> +
> + if (mode == NULL)
> + return -EINVAL;
> +
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> + dev = &rte_eth_devices[port_id];
> + RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->fec_get, -ENOTSUP);
> + return eth_err(port_id, (*dev->dev_ops->fec_get)(dev, mode));
> +}
> +
> +int
> +rte_eth_fec_set(uint16_t port_id, uint32_t mode)
> +{
> + struct rte_eth_dev *dev;
> +
RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> + dev = &rte_eth_devices[port_id];
> + RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->fec_set, -ENOTSUP);
> + return eth_err(port_id, (*dev->dev_ops->fec_set)(dev, mode));
> +}
> +
> /*
> * Returns index into MAC address array of addr. Use 00:00:00:00:00:00 to
> find
> * an empty spot.
> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
> index 645a186..04525a8 100644
> --- a/lib/librte_ethdev/rte_ethdev.h
> +++ b/lib/librte_ethdev/rte_ethdev.h
> @@ -1544,6 +1544,29 @@ struct rte_eth_dcb_info {
> struct rte_eth_dcb_tc_queue_mapping tc_queue;
> };
>
> +/**
> + * This enum indicates the possible Forward Error Correction (FEC) modes
> + * of an ethdev port.
> + */
> +enum rte_eth_fec_mode {
> + RTE_ETH_FEC_NOFEC = 0, /**< FEC is off */
> + RTE_ETH_FEC_AUTO, /
Re: [dpdk-dev] [PATCH] net/octeontx2: add support for VLAN based RSS hash
On Thu, Aug 13, 2020 at 12:53 PM wrote:
>
> From: Kiran Kumar K
>
> Adding support for VLAN based RSS hash. 2 bytes of SPI will
s/SPI/TCI
Fixed above comment on merge.
> be considered for hashing.
>
> Signed-off-by: Kiran Kumar K
Acked-by: Jerin Jacob
Applied to dpdk-next-net-mrvl/master. Thanks
> ---
> drivers/common/octeontx2/otx2_mbox.h | 2 ++
> drivers/net/octeontx2/otx2_ethdev.h | 2 +-
> drivers/net/octeontx2/otx2_rss.c | 3 +++
> 3 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/common/octeontx2/otx2_mbox.h
> b/drivers/common/octeontx2/otx2_mbox.h
> index 34b1d0663..831445703 100644
> --- a/drivers/common/octeontx2/otx2_mbox.h
> +++ b/drivers/common/octeontx2/otx2_mbox.h
> @@ -966,6 +966,8 @@ struct nix_rss_flowkey_cfg {
> #define FLOW_KEY_TYPE_INNR_SCTP BIT(16)
> #define FLOW_KEY_TYPE_INNR_ETH_DMAC BIT(17)
> #define FLOW_KEY_TYPE_CH_LEN_90B BIT(18)
> +#define FLOW_KEY_TYPE_CUSTOM0 BIT(19)
> +#define FLOW_KEY_TYPE_VLAN BIT(20)
> #define FLOW_KEY_TYPE_L4_DST BIT(28)
> #define FLOW_KEY_TYPE_L4_SRC BIT(29)
> #define FLOW_KEY_TYPE_L3_DST BIT(30)
> diff --git a/drivers/net/octeontx2/otx2_ethdev.h
> b/drivers/net/octeontx2/otx2_ethdev.h
> index e9efe52bb..c4cb09621 100644
> --- a/drivers/net/octeontx2/otx2_ethdev.h
> +++ b/drivers/net/octeontx2/otx2_ethdev.h
> @@ -119,7 +119,7 @@
> #define NIX_RSS_OFFLOAD(ETH_RSS_PORT | ETH_RSS_IP |
> ETH_RSS_UDP |\
> ETH_RSS_TCP | ETH_RSS_SCTP | \
> ETH_RSS_TUNNEL | ETH_RSS_L2_PAYLOAD | \
> -NIX_RSS_L3_L4_SRC_DST)
> +NIX_RSS_L3_L4_SRC_DST | ETH_RSS_C_VLAN)
>
> #define NIX_TX_OFFLOAD_CAPA ( \
> DEV_TX_OFFLOAD_MBUF_FAST_FREE | \
> diff --git a/drivers/net/octeontx2/otx2_rss.c
> b/drivers/net/octeontx2/otx2_rss.c
> index d859937e6..364dc623c 100644
> --- a/drivers/net/octeontx2/otx2_rss.c
> +++ b/drivers/net/octeontx2/otx2_rss.c
> @@ -238,6 +238,9 @@ otx2_rss_ethdev_to_nix(struct otx2_eth_dev *dev, uint64_t
> ethdev_rss,
> flowkey_cfg |= FLOW_KEY_TYPE_CH_LEN_90B;
> }
>
> + if (ethdev_rss & ETH_RSS_C_VLAN)
> + flowkey_cfg |= FLOW_KEY_TYPE_VLAN;
> +
> if (ethdev_rss & ETH_RSS_L3_SRC_ONLY)
> flowkey_cfg |= FLOW_KEY_TYPE_L3_SRC;
>
> --
> 2.25.1
>
[dpdk-dev] [PATCH 2/2] net/virtio: use indirect ring in packed datapath
Like split ring, packed ring will utilize indirect ring elements when
queuing mbufs need multiple descriptors. Thus each packet will take only
one slot when having multiple segments.
Signed-off-by: Marvin Liu
diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index f915b8a2c..b3b1586a7 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -1756,7 +1756,7 @@ virtio_xmit_pkts_packed(void *tx_queue, struct rte_mbuf
**tx_pkts,
for (nb_tx = 0; nb_tx < nb_pkts; nb_tx++) {
struct rte_mbuf *txm = tx_pkts[nb_tx];
- int can_push = 0, slots, need;
+ int can_push = 0, use_indirect = 0, slots, need;
/* optimize ring usage */
if ((vtpci_with_feature(hw, VIRTIO_F_ANY_LAYOUT) ||
@@ -1768,12 +1768,15 @@ virtio_xmit_pkts_packed(void *tx_queue, struct rte_mbuf
**tx_pkts,
rte_is_aligned(rte_pktmbuf_mtod(txm, char *),
__alignof__(struct virtio_net_hdr_mrg_rxbuf)))
can_push = 1;
-
+ else if (vtpci_with_feature(hw, VIRTIO_RING_F_INDIRECT_DESC) &&
+txm->nb_segs < VIRTIO_MAX_TX_INDIRECT)
+ use_indirect = 1;
/* How many main ring entries are needed to this Tx?
+* indirect => 1
* any_layout => number of segments
* default=> number of segments + 1
*/
- slots = txm->nb_segs + !can_push;
+ slots = use_indirect ? 1 : (txm->nb_segs + !can_push);
need = slots - vq->vq_free_cnt;
/* Positive value indicates it need free vring descriptors */
@@ -1791,7 +1794,8 @@ virtio_xmit_pkts_packed(void *tx_queue, struct rte_mbuf
**tx_pkts,
if (can_push)
virtqueue_enqueue_xmit_packed_fast(txvq, txm, in_order);
else
- virtqueue_enqueue_xmit_packed(txvq, txm, slots, 0,
+ virtqueue_enqueue_xmit_packed(txvq, txm, slots,
+ use_indirect, 0,
in_order);
virtio_update_packet_stats(&txvq->stats, txm);
diff --git a/drivers/net/virtio/virtio_rxtx_packed_avx.c
b/drivers/net/virtio/virtio_rxtx_packed_avx.c
index 6a8214725..ce035b574 100644
--- a/drivers/net/virtio/virtio_rxtx_packed_avx.c
+++ b/drivers/net/virtio/virtio_rxtx_packed_avx.c
@@ -207,19 +207,26 @@ virtqueue_enqueue_single_packed_vec(struct virtnet_tx
*txvq,
struct virtqueue *vq = txvq->vq;
struct virtio_hw *hw = vq->hw;
uint16_t hdr_size = hw->vtnet_hdr_size;
- uint16_t slots, can_push;
+ uint16_t slots, can_push = 0, use_indirect = 0;
int16_t need;
+ /* optimize ring usage */
+ if ((vtpci_with_feature(hw, VIRTIO_F_ANY_LAYOUT) ||
+ vtpci_with_feature(hw, VIRTIO_F_VERSION_1)) &&
+ rte_mbuf_refcnt_read(txm) == 1 &&
+ RTE_MBUF_DIRECT(txm) &&
+ txm->nb_segs == 1 &&
+ rte_pktmbuf_headroom(txm) >= hdr_size)
+ can_push = 1;
+ else if (vtpci_with_feature(hw, VIRTIO_RING_F_INDIRECT_DESC) &&
+txm->nb_segs < VIRTIO_MAX_TX_INDIRECT)
+ use_indirect = 1;
/* How many main ring entries are needed to this Tx?
+* indirect => 1
* any_layout => number of segments
* default=> number of segments + 1
*/
- can_push = rte_mbuf_refcnt_read(txm) == 1 &&
- RTE_MBUF_DIRECT(txm) &&
- txm->nb_segs == 1 &&
- rte_pktmbuf_headroom(txm) >= hdr_size;
-
- slots = txm->nb_segs + !can_push;
+ slots = use_indirect ? 1 : (txm->nb_segs + !can_push);
need = slots - vq->vq_free_cnt;
/* Positive value indicates it need free vring descriptors */
@@ -234,7 +241,8 @@ virtqueue_enqueue_single_packed_vec(struct virtnet_tx *txvq,
}
/* Enqueue Packet buffers */
- virtqueue_enqueue_xmit_packed(txvq, txm, slots, can_push, 1);
+ virtqueue_enqueue_xmit_packed(txvq, txm, slots, use_indirect,
+ can_push, 1);
txvq->stats.bytes += txm->pkt_len;
return 0;
diff --git a/drivers/net/virtio/virtqueue.h b/drivers/net/virtio/virtqueue.h
index 7d910a0a1..753dfb85c 100644
--- a/drivers/net/virtio/virtqueue.h
+++ b/drivers/net/virtio/virtqueue.h
@@ -686,7 +686,8 @@ virtqueue_xmit_offload(struct virtio_net_hdr *hdr,
static inline void
virtqueue_enqueue_xmit_packed(struct virtnet_tx *txvq, struct rte_mbuf *cookie,
- uint16_t needed, int can_push, int in_order)
+ uint16_t needed, int use_indirect, int can_push,
+ int in_order)
{
struct virtio_tx_region *txr = tx
[dpdk-dev] [PATCH 1/2] net/virtio: setup Tx region for packed ring
Add packed indirect descriptors format into virtio Tx region. When
initializing vring, packed indirect descriptors will be initialized if
ring type is packed.
Signed-off-by: Marvin Liu
diff --git a/drivers/net/virtio/virtio_ethdev.c
b/drivers/net/virtio/virtio_ethdev.c
index 013a2904e..320f99836 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -609,10 +609,9 @@ virtio_init_queue(struct rte_eth_dev *dev, uint16_t
vtpci_queue_idx)
txr = hdr_mz->addr;
memset(txr, 0, vq_size * sizeof(*txr));
for (i = 0; i < vq_size; i++) {
- struct vring_desc *start_dp = txr[i].tx_indir;
-
/* first indirect descriptor is always the tx header */
if (!vtpci_packed_queue(hw)) {
+ struct vring_desc *start_dp = txr[i].tx_indir;
vring_desc_init_split(start_dp,
RTE_DIM(txr[i].tx_indir));
start_dp->addr = txvq->virtio_net_hdr_mem
@@ -621,6 +620,16 @@ virtio_init_queue(struct rte_eth_dev *dev, uint16_t
vtpci_queue_idx)
tx_hdr);
start_dp->len = hw->vtnet_hdr_size;
start_dp->flags = VRING_DESC_F_NEXT;
+ } else {
+ struct vring_packed_desc *start_dp =
+ txr[i].tx_packed_indir;
+ vring_desc_init_indirect_packed(start_dp,
+ RTE_DIM(txr[i].tx_packed_indir));
+ start_dp->addr = txvq->virtio_net_hdr_mem
+ + i * sizeof(*txr)
+ + offsetof(struct virtio_tx_region,
+ tx_hdr);
+ start_dp->len = hw->vtnet_hdr_size;
}
}
}
diff --git a/drivers/net/virtio/virtqueue.h b/drivers/net/virtio/virtqueue.h
index 6ed50648c..7d910a0a1 100644
--- a/drivers/net/virtio/virtqueue.h
+++ b/drivers/net/virtio/virtqueue.h
@@ -329,8 +329,11 @@ struct virtio_net_hdr_mrg_rxbuf {
#define VIRTIO_MAX_TX_INDIRECT 8
struct virtio_tx_region {
struct virtio_net_hdr_mrg_rxbuf tx_hdr;
- struct vring_desc tx_indir[VIRTIO_MAX_TX_INDIRECT]
- __rte_aligned(16);
+ union {
+ struct vring_desc tx_indir[VIRTIO_MAX_TX_INDIRECT];
+ struct vring_packed_desc
+ tx_packed_indir[VIRTIO_MAX_TX_INDIRECT];
+ } __rte_aligned(16);
};
static inline int
@@ -368,6 +371,16 @@ vring_desc_init_split(struct vring_desc *dp, uint16_t n)
dp[i].next = VQ_RING_DESC_CHAIN_END;
}
+static inline void
+vring_desc_init_indirect_packed(struct vring_packed_desc *dp, int n)
+{
+ int i;
+ for (i = 0; i < n; i++) {
+ dp[i].id = (uint16_t)i;
+ dp[i].flags = VRING_DESC_F_WRITE;
+ }
+}
+
/**
* Tell the backend not to interrupt us. Implementation for packed virtqueues.
*/
--
2.17.1
[dpdk-dev] [PATCH v2] event/sw: performance improvements
Add minimum burst throughout the scheduler pipeline and a flush counter.
Replace ring API calls with local single threaded implementation
where possible.
Signed-off-by: Radu Nicolau
---
doc/guides/eventdevs/sw.rst| 22 +++
doc/guides/rel_notes/release_20_11.rst | 4 ++
drivers/event/sw/sw_evdev.c| 82 -
drivers/event/sw/sw_evdev.h| 20 ++-
drivers/event/sw/sw_evdev_scheduler.c | 83 +-
5 files changed, 191 insertions(+), 20 deletions(-)
diff --git a/doc/guides/eventdevs/sw.rst b/doc/guides/eventdevs/sw.rst
index 04c8b0305..69939ab9d 100644
--- a/doc/guides/eventdevs/sw.rst
+++ b/doc/guides/eventdevs/sw.rst
@@ -87,6 +87,28 @@ verify possible gains.
--vdev="event_sw0,credit_quanta=64"
+Scheduler tuning arguments
+~
+
+The scheduler minimum number of events that are processed can be increased to
+reduce per event overhead and increase internal burst sizes, which can
+improve throughput.
+
+* ``min_burst`` specifies the minimum number of inflight events that can be
+ moved to the next stage in the scheduler. Default value is 1.
+
+* ``refill_once`` is a switch that when set instructs the scheduler to deque
+ the events waiting in the ingress rings only once per call. The default
+ behavior is to dequeue as needed.
+
+* ``deq_burst`` is the burst size used to dequeue from the port rings.
+ Default value is 32, and it should be increased to 64 or 128 when setting
+ ``refill_once=1``.
+
+.. code-block:: console
+
+--vdev="event_sw0,min_burst=8,deq_burst=64,refill_once=1"
+
Limitations
---
diff --git a/doc/guides/rel_notes/release_20_11.rst
b/doc/guides/rel_notes/release_20_11.rst
index f377ab8e8..afc06ca37 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -78,6 +78,10 @@ New Features
``--portmask=N``
where N represents the hexadecimal bitmask of ports used.
+* **Updated Software Eventdev driver.**
+
+ Added performance tuning arguments to allow tuning the scheduler for
+ better throughtput in high core count use cases.
Removed Items
-
diff --git a/drivers/event/sw/sw_evdev.c b/drivers/event/sw/sw_evdev.c
index 98dae7164..04d05172c 100644
--- a/drivers/event/sw/sw_evdev.c
+++ b/drivers/event/sw/sw_evdev.c
@@ -19,6 +19,9 @@
#define NUMA_NODE_ARG "numa_node"
#define SCHED_QUANTA_ARG "sched_quanta"
#define CREDIT_QUANTA_ARG "credit_quanta"
+#define MIN_BURST_SIZE_ARG "min_burst"
+#define DEQ_BURST_SIZE_ARG "deq_burst"
+#define REFIL_ONCE_ARG "refill_once"
static void
sw_info_get(struct rte_eventdev *dev, struct rte_event_dev_info *info);
@@ -910,6 +913,35 @@ set_credit_quanta(const char *key __rte_unused, const char
*value, void *opaque)
return 0;
}
+static int
+set_deq_burst_sz(const char *key __rte_unused, const char *value, void *opaque)
+{
+ int *deq_burst_sz = opaque;
+ *deq_burst_sz = atoi(value);
+ if (*deq_burst_sz < 0 || *deq_burst_sz > SCHED_DEQUEUE_MAX_BURST_SIZE)
+ return -1;
+ return 0;
+}
+
+static int
+set_min_burst_sz(const char *key __rte_unused, const char *value, void *opaque)
+{
+ int *min_burst_sz = opaque;
+ *min_burst_sz = atoi(value);
+ if (*min_burst_sz < 0 || *min_burst_sz > SCHED_DEQUEUE_MAX_BURST_SIZE)
+ return -1;
+ return 0;
+}
+
+static int
+set_refill_once(const char *key __rte_unused, const char *value, void *opaque)
+{
+ int *refill_once_per_call = opaque;
+ *refill_once_per_call = atoi(value);
+ if (*refill_once_per_call < 0 || *refill_once_per_call > 1)
+ return -1;
+ return 0;
+}
static int32_t sw_sched_service_func(void *args)
{
@@ -957,6 +989,9 @@ sw_probe(struct rte_vdev_device *vdev)
NUMA_NODE_ARG,
SCHED_QUANTA_ARG,
CREDIT_QUANTA_ARG,
+ MIN_BURST_SIZE_ARG,
+ DEQ_BURST_SIZE_ARG,
+ REFIL_ONCE_ARG,
NULL
};
const char *name;
@@ -966,6 +1001,9 @@ sw_probe(struct rte_vdev_device *vdev)
int socket_id = rte_socket_id();
int sched_quanta = SW_DEFAULT_SCHED_QUANTA;
int credit_quanta = SW_DEFAULT_CREDIT_QUANTA;
+ int min_burst_size = 1;
+ int deq_burst_size = SCHED_DEQUEUE_DEFAULT_BURST_SIZE;
+ int refill_once = 0;
name = rte_vdev_device_name(vdev);
params = rte_vdev_device_args(vdev);
@@ -1007,13 +1045,46 @@ sw_probe(struct rte_vdev_device *vdev)
return ret;
}
+ ret = rte_kvargs_process(kvlist, MIN_BURST_SIZE_ARG,
+ set_min_burst_sz, &min_burst_size);
+ if (ret != 0) {
+ SW_LOG_ERR(
+ "%s: Error parsing minimum burst size
parameter",
+
[dpdk-dev] DPDK Compiling Error on New Fedora 32: drivers/net/ntacc/meson.build:31:0: ERROR: Include dir /include does not exist.
Hi, Compiling error: drivers/net/ntacc/meson.build:31:0: ERROR: Include dir /include does not exist. To fix: drivers/net/ntacc/meson.build 25| PATH = '/usr' Sincerely, Jack
Re: [dpdk-dev] [PATCH v2] eal: simplify exit functions
On Mon, Sep 28, 2020 at 02:00:48AM +0200, Thomas Monjalon wrote: > The option RTE_EAL_ALWAYS_PANIC_ON_ERROR was off by default, > and not customizable with meson. It is completely removed. > > The function rte_dump_registers is a trace of the bare metal support > era, and was not supported in userland. It is completely removed. > > Signed-off-by: Thomas Monjalon > Acked-by: Ray Kinsella > --- > The deprecation notice for this removal has been missed. > I assume it would not hurt anybody to remove this useless function > from DPDK 20.11. Asking the Technical Board for confirmation. > --- Acked-by: Bruce Richardson
Re: [dpdk-dev] DPDK Compiling Error on New Fedora 32: drivers/net/ntacc/meson.build:31:0: ERROR: Include dir /include does not exist.
On 9/25/2020 3:27 PM, Jack wrote: Hi, Compiling error: drivers/net/ntacc/meson.build:31:0: ERROR: Include dir /include does not exist. To fix: drivers/net/ntacc/meson.build 25| PATH = '/usr' Sincerely, Jack Hi Jack, Unfortunately Napatech drivers are not upstreamed, so it is not officially supported by project, and we can't help there, it is Napatech's problem to solve.
[dpdk-dev] [PATCH v1 0/4] Align device close operation with new behavior
From: Sachin Saxena - patches are rebased on v2 series: http://patches.dpdk.org/project/dpdk/list/?series=12533 Sachin Saxena (4): net/dpaa: release port upon close net/dpaa2: release port upon close net/pfe: release port upon close net/enetc: release port upon close drivers/net/dpaa/dpaa_ethdev.c | 113 ++- drivers/net/dpaa2/dpaa2_ethdev.c | 90 ++-- drivers/net/enetc/enetc_ethdev.c | 10 +-- drivers/net/pfe/pfe_ethdev.c | 38 --- 4 files changed, 105 insertions(+), 146 deletions(-) -- 2.28.0
[dpdk-dev] [PATCH v1 3/4] net/pfe: release port upon close
From: Sachin Saxena
With removal of old close behavior, the private
port resources must be released in the .dev_close callback.
Freeing of port private resources is moved from
the ".remove(device)" to the ".dev_close(port)" operation
Signed-off-by: Sachin Saxena
---
drivers/net/pfe/pfe_ethdev.c | 38 +---
1 file changed, 14 insertions(+), 24 deletions(-)
diff --git a/drivers/net/pfe/pfe_ethdev.c b/drivers/net/pfe/pfe_ethdev.c
index a7e9d97ba..f0de1c8a2 100644
--- a/drivers/net/pfe/pfe_ethdev.c
+++ b/drivers/net/pfe/pfe_ethdev.c
@@ -385,22 +385,11 @@ pfe_eth_stop(struct rte_eth_dev *dev/*, int wake*/)
dev->tx_pkt_burst = &pfe_dummy_xmit_pkts;
}
-static void
-pfe_eth_exit(struct rte_eth_dev *dev, struct pfe *pfe)
-{
- PMD_INIT_FUNC_TRACE();
-
- pfe_eth_stop(dev);
- /* Close the device file for link status */
- pfe_eth_close_cdev(dev->data->dev_private);
-
- rte_eth_dev_release_port(dev);
- pfe->nb_devs--;
-}
-
static int
pfe_eth_close(struct rte_eth_dev *dev)
{
+ PMD_INIT_FUNC_TRACE();
+
if (!dev)
return -1;
@@ -410,7 +399,12 @@ pfe_eth_close(struct rte_eth_dev *dev)
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
return 0;
- pfe_eth_exit(dev, g_pfe);
+ pfe_eth_stop(dev);
+ /* Close the device file for link status */
+ pfe_eth_close_cdev(dev->data->dev_private);
+
+ munmap(g_pfe->cbus_baseaddr, g_pfe->cbus_size);
+ g_pfe->nb_devs--;
if (g_pfe->nb_devs == 0) {
pfe_hif_exit(g_pfe);
@@ -1147,6 +1141,7 @@ pmd_pfe_remove(struct rte_vdev_device *vdev)
{
const char *name;
struct rte_eth_dev *eth_dev = NULL;
+ int ret = 0;
name = rte_vdev_device_name(vdev);
if (name == NULL)
@@ -1158,17 +1153,12 @@ pmd_pfe_remove(struct rte_vdev_device *vdev)
return 0;
eth_dev = rte_eth_dev_allocated(name);
- if (eth_dev != NULL)
- pfe_eth_exit(eth_dev, g_pfe);
- munmap(g_pfe->cbus_baseaddr, g_pfe->cbus_size);
-
- if (g_pfe->nb_devs == 0) {
- pfe_hif_exit(g_pfe);
- pfe_hif_lib_exit(g_pfe);
- rte_free(g_pfe);
- g_pfe = NULL;
+ if (eth_dev) {
+ pfe_eth_close(eth_dev);
+ ret = rte_eth_dev_release_port(eth_dev);
}
- return 0;
+
+ return ret;
}
static
--
2.28.0
[dpdk-dev] [PATCH v1 1/4] net/dpaa: release port upon close
From: Sachin Saxena
With removal of old close behavior, the private
port resources must be released in the .dev_close callback.
Freeing of port private resources is moved from
the ".remove(device)" to the ".dev_close(port)" operation
Signed-off-by: Sachin Saxena
---
drivers/net/dpaa/dpaa_ethdev.c | 113 ++---
1 file changed, 49 insertions(+), 64 deletions(-)
diff --git a/drivers/net/dpaa/dpaa_ethdev.c b/drivers/net/dpaa/dpaa_ethdev.c
index c029dd4f3..7e6a954d7 100644
--- a/drivers/net/dpaa/dpaa_ethdev.c
+++ b/drivers/net/dpaa/dpaa_ethdev.c
@@ -376,12 +376,25 @@ static int dpaa_eth_dev_close(struct rte_eth_dev *dev)
struct rte_device *rdev = dev->device;
struct rte_dpaa_device *dpaa_dev;
struct rte_intr_handle *intr_handle;
+ struct dpaa_if *dpaa_intf = dev->data->dev_private;
+ int loop;
PMD_INIT_FUNC_TRACE();
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
return 0;
+ if (!dpaa_intf) {
+ DPAA_PMD_WARN("Already closed or not started");
+ return -1;
+ }
+
+ /* DPAA FM deconfig */
+ if (!(default_q || fmc_q)) {
+ if (dpaa_fm_deconfig(dpaa_intf, dev->process_private))
+ DPAA_PMD_WARN("DPAA FM deconfig failed\n");
+ }
+
dpaa_dev = container_of(rdev, struct rte_dpaa_device, device);
intr_handle = &dpaa_dev->intr_handle;
__fif = container_of(fif, struct __fman_if, __if);
@@ -396,6 +409,38 @@ static int dpaa_eth_dev_close(struct rte_eth_dev *dev)
(void *)dev);
}
+ /* release configuration memory */
+ if (dpaa_intf->fc_conf)
+ rte_free(dpaa_intf->fc_conf);
+
+ /* Release RX congestion Groups */
+ if (dpaa_intf->cgr_rx) {
+ for (loop = 0; loop < dpaa_intf->nb_rx_queues; loop++)
+ qman_delete_cgr(&dpaa_intf->cgr_rx[loop]);
+
+ qman_release_cgrid_range(dpaa_intf->cgr_rx[loop].cgrid,
+dpaa_intf->nb_rx_queues);
+ }
+
+ rte_free(dpaa_intf->cgr_rx);
+ dpaa_intf->cgr_rx = NULL;
+ /* Release TX congestion Groups */
+ if (dpaa_intf->cgr_tx) {
+ for (loop = 0; loop < MAX_DPAA_CORES; loop++)
+ qman_delete_cgr(&dpaa_intf->cgr_tx[loop]);
+
+ qman_release_cgrid_range(dpaa_intf->cgr_tx[loop].cgrid,
+MAX_DPAA_CORES);
+ rte_free(dpaa_intf->cgr_tx);
+ dpaa_intf->cgr_tx = NULL;
+ }
+
+ rte_free(dpaa_intf->rx_queues);
+ dpaa_intf->rx_queues = NULL;
+
+ rte_free(dpaa_intf->tx_queues);
+ dpaa_intf->tx_queues = NULL;
+
return 0;
}
@@ -1980,66 +2025,6 @@ dpaa_dev_init(struct rte_eth_dev *eth_dev)
return ret;
}
-static int
-dpaa_dev_uninit(struct rte_eth_dev *dev)
-{
- struct dpaa_if *dpaa_intf = dev->data->dev_private;
- int loop;
-
- PMD_INIT_FUNC_TRACE();
-
- if (rte_eal_process_type() != RTE_PROC_PRIMARY)
- return -EPERM;
-
- if (!dpaa_intf) {
- DPAA_PMD_WARN("Already closed or not started");
- return -1;
- }
-
- /* DPAA FM deconfig */
- if (!(default_q || fmc_q)) {
- if (dpaa_fm_deconfig(dpaa_intf, dev->process_private))
- DPAA_PMD_WARN("DPAA FM deconfig failed\n");
- }
-
- dpaa_eth_dev_close(dev);
-
- /* release configuration memory */
- if (dpaa_intf->fc_conf)
- rte_free(dpaa_intf->fc_conf);
-
- /* Release RX congestion Groups */
- if (dpaa_intf->cgr_rx) {
- for (loop = 0; loop < dpaa_intf->nb_rx_queues; loop++)
- qman_delete_cgr(&dpaa_intf->cgr_rx[loop]);
-
- qman_release_cgrid_range(dpaa_intf->cgr_rx[loop].cgrid,
-dpaa_intf->nb_rx_queues);
- }
-
- rte_free(dpaa_intf->cgr_rx);
- dpaa_intf->cgr_rx = NULL;
-
- /* Release TX congestion Groups */
- if (dpaa_intf->cgr_tx) {
- for (loop = 0; loop < MAX_DPAA_CORES; loop++)
- qman_delete_cgr(&dpaa_intf->cgr_tx[loop]);
-
- qman_release_cgrid_range(dpaa_intf->cgr_tx[loop].cgrid,
-MAX_DPAA_CORES);
- rte_free(dpaa_intf->cgr_tx);
- dpaa_intf->cgr_tx = NULL;
- }
-
- rte_free(dpaa_intf->rx_queues);
- dpaa_intf->rx_queues = NULL;
-
- rte_free(dpaa_intf->tx_queues);
- dpaa_intf->tx_queues = NULL;
-
- return 0;
-}
-
static int
rte_dpaa_probe(struct rte_dpaa_driver *dpaa_drv,
struct rte_dpaa_device *dpaa_dev)
@@ -2156,15 +2141,15 @@ static int
rte_dpaa_remove(struct rte_dpaa_device *dpaa_dev)
{
struct rte_eth_dev *eth_dev;
+ int
[dpdk-dev] [PATCH v1 2/4] net/dpaa2: release port upon close
From: Sachin Saxena
With removal of old close behavior, the private
port resources must be released in the .dev_close callback.
Freeing of port private resources is moved from
the ".remove(device)" to the ".dev_close(port)" operation
Signed-off-by: Sachin Saxena
---
drivers/net/dpaa2/dpaa2_ethdev.c | 86 +---
1 file changed, 35 insertions(+), 51 deletions(-)
diff --git a/drivers/net/dpaa2/dpaa2_ethdev.c b/drivers/net/dpaa2/dpaa2_ethdev.c
index c81e75d53..3b87e8428 100644
--- a/drivers/net/dpaa2/dpaa2_ethdev.c
+++ b/drivers/net/dpaa2/dpaa2_ethdev.c
@@ -99,7 +99,6 @@ static const enum rte_filter_op dpaa2_supported_filter_ops[]
= {
};
static struct rte_dpaa2_driver rte_dpaa2_pmd;
-static int dpaa2_dev_uninit(struct rte_eth_dev *eth_dev);
static int dpaa2_dev_link_update(struct rte_eth_dev *dev,
int wait_to_complete);
static int dpaa2_dev_set_link_up(struct rte_eth_dev *dev);
@@ -1241,7 +1240,7 @@ dpaa2_dev_close(struct rte_eth_dev *dev)
{
struct dpaa2_dev_priv *priv = dev->data->dev_private;
struct fsl_mc_io *dpni = (struct fsl_mc_io *)dev->process_private;
- int ret;
+ int i, ret;
struct rte_eth_link link;
PMD_INIT_FUNC_TRACE();
@@ -1249,8 +1248,12 @@ dpaa2_dev_close(struct rte_eth_dev *dev)
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
return 0;
- dpaa2_flow_clean(dev);
+ if (!dpni) {
+ DPAA2_PMD_WARN("Already closed or not started");
+ return -1;
+ }
+ dpaa2_flow_clean(dev);
/* Clean the device first */
ret = dpni_reset(dpni, CMD_PRI_LOW, priv->token);
if (ret) {
@@ -1261,6 +1264,27 @@ dpaa2_dev_close(struct rte_eth_dev *dev)
memset(&link, 0, sizeof(link));
rte_eth_linkstatus_set(dev, &link);
+ /* Free private queues memory */
+ dpaa2_free_rx_tx_queues(dev);
+ /* Close the device at underlying layer*/
+ ret = dpni_close(dpni, CMD_PRI_LOW, priv->token);
+ if (ret) {
+ DPAA2_PMD_ERR("Failure closing dpni device with err code %d",
+ ret);
+ }
+
+ /* Free the allocated memory for ethernet private data and dpni*/
+ priv->hw = NULL;
+ dev->process_private = NULL;
+ rte_free(dpni);
+
+ for (i = 0; i < MAX_TCS; i++)
+ rte_free((void *)(size_t)priv->extract.tc_extract_param[i]);
+
+ if (priv->extract.qos_extract_param)
+ rte_free((void *)(size_t)priv->extract.qos_extract_param);
+
+ DPAA2_PMD_INFO("%s: netdev deleted", dev->data->name);
return 0;
}
@@ -2712,52 +2736,12 @@ dpaa2_dev_init(struct rte_eth_dev *eth_dev)
RTE_LOG(INFO, PMD, "%s: netdev created\n", eth_dev->data->name);
return 0;
init_err:
- dpaa2_dev_uninit(eth_dev);
- return ret;
-}
-
-static int
-dpaa2_dev_uninit(struct rte_eth_dev *eth_dev)
-{
- struct dpaa2_dev_priv *priv = eth_dev->data->dev_private;
- struct fsl_mc_io *dpni = (struct fsl_mc_io *)eth_dev->process_private;
- int i, ret;
-
- PMD_INIT_FUNC_TRACE();
-
- if (rte_eal_process_type() != RTE_PROC_PRIMARY)
- return 0;
-
- if (!dpni) {
- DPAA2_PMD_WARN("Already closed or not started");
- return -1;
- }
-
+ /* With new implementation of .close, port private data
+* will also be release by close callback.
+*/
dpaa2_dev_close(eth_dev);
- dpaa2_free_rx_tx_queues(eth_dev);
-
- /* Close the device at underlying layer*/
- ret = dpni_close(dpni, CMD_PRI_LOW, priv->token);
- if (ret) {
- DPAA2_PMD_ERR(
-"Failure closing dpni device with err code %d",
-ret);
- }
-
- /* Free the allocated memory for ethernet private data and dpni*/
- priv->hw = NULL;
- eth_dev->process_private = NULL;
- rte_free(dpni);
-
- for (i = 0; i < MAX_TCS; i++)
- rte_free((void *)(size_t)priv->extract.tc_extract_param[i]);
-
- if (priv->extract.qos_extract_param)
- rte_free((void *)(size_t)priv->extract.qos_extract_param);
-
- DPAA2_PMD_INFO("%s: netdev deleted", eth_dev->data->name);
- return 0;
+ return ret;
}
static int
@@ -2826,13 +2810,13 @@ static int
rte_dpaa2_remove(struct rte_dpaa2_device *dpaa2_dev)
{
struct rte_eth_dev *eth_dev;
+ int ret;
eth_dev = dpaa2_dev->eth_dev;
- dpaa2_dev_uninit(eth_dev);
-
- rte_eth_dev_release_port(eth_dev);
+ dpaa2_dev_close(eth_dev);
+ ret = rte_eth_dev_release_port(eth_dev);
- return 0;
+ return ret;
}
static struct rte_dpaa2_driver rte_dpaa2_pmd = {
--
2.28.0
[dpdk-dev] [PATCH v1 4/4] net/enetc: release port upon close
From: Sachin Saxena
With removal of old close behavior, the private
port resources must be released in the .dev_close callback.
Freeing of port private resources is moved from
the ".remove(device)" to the ".dev_close(port)" operation
Signed-off-by: Sachin Saxena
---
drivers/net/enetc/enetc_ethdev.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/enetc/enetc_ethdev.c b/drivers/net/enetc/enetc_ethdev.c
index d42add3ef..b3dec7e64 100644
--- a/drivers/net/enetc/enetc_ethdev.c
+++ b/drivers/net/enetc/enetc_ethdev.c
@@ -568,6 +568,9 @@ enetc_dev_close(struct rte_eth_dev *dev)
}
dev->data->nb_tx_queues = 0;
+ if (rte_eal_iova_mode() == RTE_IOVA_PA)
+ dpaax_iova_table_depopulate();
+
return 0;
}
@@ -919,14 +922,11 @@ enetc_dev_init(struct rte_eth_dev *eth_dev)
}
static int
-enetc_dev_uninit(struct rte_eth_dev *eth_dev __rte_unused)
+enetc_dev_uninit(struct rte_eth_dev *eth_dev)
{
PMD_INIT_FUNC_TRACE();
- if (rte_eal_iova_mode() == RTE_IOVA_PA)
- dpaax_iova_table_depopulate();
-
- return 0;
+ return enetc_dev_close(eth_dev);
}
static int
--
2.28.0
Re: [dpdk-dev] [PATCH v6 1/6] drivers: add generic API to find PCI extended cap
On Sun, Sep 27, 2020 at 2:21 PM Jerin Jacob wrote:
>
> On Fri, Sep 25, 2020 at 5:26 PM Manish Chopra wrote:
> >
> > By adding generic API, this patch removes individual
> > functions/defines implemented by drivers to find extended
> > PCI capabilities.
> >
> > Signed-off-by: Manish Chopra
> > Signed-off-by: Igor Russkikh
> > Reviewed-by: Gaetan Rivet
>
> Reviewed-by: Jerin Jacob
>
> @Thomas Monjalon @David Marchand @Ferruh Yigit
>
> Othe patches in the qede series is depending on this patch, Let me
> know, how we are planning to pull this patch? Is through main or
> dpdk-next-net or dpdk-next-net-mrvl?
Just two small comments, that can be fixed by whoever applies it.
- The title does not reflect that we are adding an API to the pci bus.
My suggestion is: "bus/pci: query PCI extended capabilities"
- There is an unneeded empty line added to lib/librte_pci/rte_pci.h:
diff --git a/lib/librte_pci/rte_pci.h b/lib/librte_pci/rte_pci.h
index 1d89651ec8..f89c7dbbea 100644
--- a/lib/librte_pci/rte_pci.h
+++ b/lib/librte_pci/rte_pci.h
@@ -22,7 +22,6 @@ extern "C" {
#include
#include
-
/*
* Conventional PCI and PCI-X Mode 1 devices have 256 bytes of
* configuration space. PCI-X Mode 2 and PCIe devices have 4096 bytes of
The patch is reviewed by Gaëtan.
Either through next-net or next-net-mrvl is fine to me.
I'll leave the decision to Ferruh.
--
David Marchand
Re: [dpdk-dev] [PATCH V5 1/2] dpdk: resolve compiling errors for per-queue stats
On 9/27/2020 4:16 AM, Min Hu (Connor) wrote:
From: Huisong Li
Currently, only statistics of rx/tx queues with queue_id less than
RTE_ETHDEV_QUEUE_STAT_CNTRS can be displayed. If there is a certain
application scenario that it needs to use 256 or more than 256 queues
and display all statistics of rx/tx queue. At this moment, we have to
change the macro to be equaled to the queue number.
However, modifying the macro to be greater than 256 will trigger
many errors and warnings from test-pmd, PMD drivers and librte_ethdev
during compiling dpdk project. But it is possible and permitted that
rx/tx queue number is greater than 256 and all statistics of rx/tx
queue need to be displayed. In addition, the data type of rx/tx queue
number in rte_eth_dev_configure API is 'uint16_t'. So It is unreasonable
to use the 'uint8_t' type for variables that control which per-queue
statistics can be displayed.
Fixes: ed30d9b691b2 ("app/testpmd: add stats per queue")
Fixes: 09c7e63a71f9 ("net/memif: introduce memory interface PMD")
Fixes: abf7275bbaa2 ("ixgbe: move to drivers/net/")
Fixes: e6defdfddc3b ("net/igc: enable statistics")
Fixes: 2265e4b4e84b ("net/octeontx2: add basic stats operation")
Fixes: 6c3169a3dc04 ("virtio: move to drivers/net/")
Signed-off-by: Huisong Li
Signed-off-by: Min Hu (Connor)
Reviewed-by: Wei Hu (Xavier)
Reviewed-by: Dongdong Liu
---
V4 -> V5:
add release notes updated.
---
v3->v4:
add a change in cmd_setqmap_mapvalue.
---
v2->v3:
change 'uint8_t i' to 'uint16_t i' in nic_stats_display function.
---
app/proc-info/main.c | 2 +-
app/test-pmd/cmdline.c | 4 ++--
app/test-pmd/config.c | 4 ++--
app/test-pmd/testpmd.c | 2 +-
app/test-pmd/testpmd.h | 5 +++--
doc/guides/rel_notes/release_20_11.rst | 5 +
drivers/net/igc/igc_ethdev.c | 4 ++--
drivers/net/ixgbe/ixgbe_ethdev.c | 4 ++--
drivers/net/memif/rte_eth_memif.c | 2 +-
drivers/net/octeontx2/otx2_ethdev.h| 2 +-
drivers/net/octeontx2/otx2_stats.c | 2 +-
drivers/net/virtio/virtio_ethdev.c | 4 ++--
lib/librte_ethdev/rte_ethdev.c | 6 +++---
lib/librte_ethdev/rte_ethdev.h | 4 ++--
lib/librte_ethdev/rte_ethdev_driver.h | 2 +-
15 files changed, 29 insertions(+), 23 deletions(-)
diff --git a/app/proc-info/main.c b/app/proc-info/main.c
index 64fb83b..26d9355 100644
--- a/app/proc-info/main.c
+++ b/app/proc-info/main.c
@@ -348,7 +348,7 @@ static void
nic_stats_display(uint16_t port_id)
{
struct rte_eth_stats stats;
- uint8_t i;
+ uint16_t i;
static const char *nic_stats_border = "";
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 08e123f..23e624f 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -8315,7 +8315,7 @@ struct cmd_set_qmap_result {
cmdline_fixed_string_t what;
portid_t port_id;
uint16_t queue_id;
- uint8_t map_value;
+ uint16_t map_value;
};
static void
@@ -8346,7 +8346,7 @@ cmdline_parse_token_num_t cmd_setqmap_queueid =
queue_id, UINT16);
cmdline_parse_token_num_t cmd_setqmap_mapvalue =
TOKEN_NUM_INITIALIZER(struct cmd_set_qmap_result,
- map_value, UINT8);
+ map_value, UINT16);
cmdline_parse_inst_t cmd_set_qmap = {
.f = cmd_set_qmap_parsed,
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 17a6efe..dfe5627 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -161,7 +161,7 @@ nic_stats_display(portid_t port_id)
uint64_t mpps_rx, mpps_tx, mbps_rx, mbps_tx;
struct rte_eth_stats stats;
struct rte_port *port = &ports[port_id];
- uint8_t i;
+ uint16_t i;
static const char *nic_stats_border = "";
@@ -3742,7 +3742,7 @@ tx_vlan_pvid_set(portid_t port_id, uint16_t vlan_id, int on)
}
void
-set_qmap(portid_t port_id, uint8_t is_rx, uint16_t queue_id, uint8_t map_value)
+set_qmap(portid_t port_id, uint8_t is_rx, uint16_t queue_id, uint16_t
map_value)
{
uint16_t i;
uint8_t existing_mapping_found = 0;
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index fe6450c..4b26c5c 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -1840,7 +1840,7 @@ fwd_stats_display(void)
fwd_cycles += fs->core_cycles;
}
for (i = 0; i < cur_fwd_config.nb_fwd_ports; i++) {
- uint8_t j;
+ uint16_t j;
pt_id = fwd_ports_ids[i];
port = &ports[pt_id];
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index c7e7e41..9ad002c 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -279,7 +279,7 @@ enum dcb_mode_enable
struct queue_stats_mappings {
portid_t port_id;
uint16_t queue_id;
- uint8
Re: [dpdk-dev] [PATCH V5 2/2] ethdev: change data type in TC rxq and TC txq
On 9/27/2020 4:16 AM, Min Hu (Connor) wrote:
From: Huisong Li
Currently, base and nb_queue in the tc_rxq and tc_txq information
of queue and TC mapping on both TX and RX paths are uint8_t.
However, these data will be truncated when queue number under a TC
is greater than 256. So it is necessary for base and nb_queue to
change from uint8_t to uint16_t.
Fixes: 01eb53eefeb40e8 ("ethdev: rename folder to library name")
Signed-off-by: Huisong Li
Signed-off-by: Min Hu (Connor)
Reviewed-by: Wei Hu (Xavier)
Reviewed-by: Dongdong Liu
---
V4 -> V5:
add release notes updated.
---
doc/guides/rel_notes/release_20_11.rst | 5 +
lib/librte_ethdev/rte_ethdev.h | 8
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/doc/guides/rel_notes/release_20_11.rst
b/doc/guides/rel_notes/release_20_11.rst
index 1ef6f0e..ad14fd7 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -183,6 +183,11 @@ API Changes
function will be changed from ``uint8_t`` to ``uint16_t``, which supports
for
using 256 or more than 256 queues and displaying all statistics of rx/tx
queue.
+* ethdev: Modified field type of base and nb_queue in struct
+ ``rte_eth_dcb_tc_queue_mapping`` from ``uint8_t`` to ``uint16_t``.
+ As the data of uint8_t will be truncated when queue number under
+ a TC is greater than 256.
+
ABI Changes
---
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index ff3a616..2270460 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -1522,13 +1522,13 @@ struct rte_eth_xstat_name {
struct rte_eth_dcb_tc_queue_mapping {
/** rx queues assigned to tc per Pool */
struct {
- uint8_t base;
- uint8_t nb_queue;
+ uint16_t base;
+ uint16_t nb_queue;
} tc_rxq[ETH_MAX_VMDQ_POOL][ETH_DCB_NUM_TCS];
/** rx queues assigned to tc per Pool */
struct {
- uint8_t base;
- uint8_t nb_queue;
+ uint16_t base;
+ uint16_t nb_queue;
} tc_txq[ETH_MAX_VMDQ_POOL][ETH_DCB_NUM_TCS];
};
cc'ed tech-board,
The patch breaks the ethdev ABI without a deprecation notice from previous
release(s).
It is increasing the storage size of the fields to support more than 255 queues.
Since the ethdev library already heavily breaks the ABI this release, I am for
getting this patch, instead of waiting for one more year for the update.
Can you please review the patch, is there any objection to proceed with it?
Re: [dpdk-dev] [PATCH v1 2/4] net/dpaa2: release port upon close
28/09/2020 10:57, Sachin Saxena (OSS): > + /* With new implementation of .close, port private data > + * will also be release by close callback. > + */ > dpaa2_dev_close(eth_dev); I think this comment is weird.
Re: [dpdk-dev] [PATCH] bus/pci: fix mapping of PCI resources
On 28-Sep-20 7:34 AM, alvinx.zh...@intel.com wrote:
From: Alvin Zhang
When mapping PCI bar resources around the MSI-X table, if the size
of the first part is 0, the second part should also be mapped if
its size is not 0.
Fixes: e200535c1ca3 ("mem: drop mapping API workaround")
Cc: sta...@dpdk.org
Signed-off-by: Alvin Zhang
---
drivers/bus/pci/linux/pci_vfio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bus/pci/linux/pci_vfio.c b/drivers/bus/pci/linux/pci_vfio.c
index 34b5da8..37bfda8 100644
--- a/drivers/bus/pci/linux/pci_vfio.c
+++ b/drivers/bus/pci/linux/pci_vfio.c
@@ -565,7 +565,7 @@
}
/* if there's a second part, try to map it */
- if (map_addr != NULL
+ if ((map_addr != NULL || memreg[0].size == 0)
&& memreg[1].offset && memreg[1].size) {
void *second_addr = RTE_PTR_ADD(bar_addr,
(uintptr_t)(memreg[1].offset -
Dupe of http://patches.dpdk.org/patch/78768/ ?
--
Thanks,
Anatoly
[dpdk-dev] [Bug 544] l3fwd attempts to create too many TX queues
https://bugs.dpdk.org/show_bug.cgi?id=544 Bug ID: 544 Summary: l3fwd attempts to create too many TX queues Product: DPDK Version: 20.08 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: examples Assignee: dev@dpdk.org Reporter: anatoly.bura...@intel.com Target Milestone: --- When initializing l3fwd, the number of TX queues will be decided by minimum of either max number of TX queues (set to max number of devices), or number of lcores. This prevents l3fwd from running when the number of lcores/devices exceeds the max number of queues per device. This is easily reproducible with creating a couple of pcap vdevs and attempting to do forwarding on them. -- You are receiving this mail because: You are the assignee for the bug.
[dpdk-dev] [Bug 545] l3fwd doesn't check offload configuration
https://bugs.dpdk.org/show_bug.cgi?id=545 Bug ID: 545 Summary: l3fwd doesn't check offload configuration Product: DPDK Version: 20.08 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: examples Assignee: dev@dpdk.org Reporter: anatoly.bura...@intel.com Target Milestone: --- When initializing l3fwd, the offload configuration is not checked, leading to requesting offloads from the device that might not be supported. This is easily verified by attempting to use a pcap vdev in l3fwd. -- You are receiving this mail because: You are the assignee for the bug.
Re: [dpdk-dev] [dpdk-techboard] [PATCH V5 1/2] dpdk: resolve compiling errors for per-queue stats
28/09/2020 10:59, Ferruh Yigit: > On 9/27/2020 4:16 AM, Min Hu (Connor) wrote: > > From: Huisong Li > > > > Currently, only statistics of rx/tx queues with queue_id less than > > RTE_ETHDEV_QUEUE_STAT_CNTRS can be displayed. If there is a certain > > application scenario that it needs to use 256 or more than 256 queues > > and display all statistics of rx/tx queue. At this moment, we have to > > change the macro to be equaled to the queue number. > > > > However, modifying the macro to be greater than 256 will trigger > > many errors and warnings from test-pmd, PMD drivers and librte_ethdev > > during compiling dpdk project. But it is possible and permitted that > > rx/tx queue number is greater than 256 and all statistics of rx/tx > > queue need to be displayed. In addition, the data type of rx/tx queue > > number in rte_eth_dev_configure API is 'uint16_t'. So It is unreasonable > > to use the 'uint8_t' type for variables that control which per-queue > > statistics can be displayed. The explanation is too much complex and misleading. You mean you cannot increase RTE_ETHDEV_QUEUE_STAT_CNTRS above 256 because it is an 8-bit type? [...] > > --- a/lib/librte_ethdev/rte_ethdev.h > > +++ b/lib/librte_ethdev/rte_ethdev.h > > int rte_eth_dev_set_tx_queue_stats_mapping(uint16_t port_id, > > - uint16_t tx_queue_id, uint8_t stat_idx); > > + uint16_t tx_queue_id, uint16_t stat_idx); [...] > > int rte_eth_dev_set_rx_queue_stats_mapping(uint16_t port_id, > >uint16_t rx_queue_id, > > - uint8_t stat_idx); > > + uint16_t stat_idx); [...] > cc'ed tech-board, > > The patch breaks the ethdev ABI without a deprecation notice from previous > release(s). > > It is mainly a fix to the port_id storage type, which we have updated from > uint8_t to uint16_t in past but some seems remained for > 'rte_eth_dev_set_tx_queue_stats_mapping()' & > 'rte_eth_dev_set_rx_queue_stats_mapping()' APIs. No, it is not related to the port id, but the number of limited stats. > Since the ethdev library already heavily breaks the ABI this release, I am > for > getting this fix, instead of waiting the fix for one more year. If stats can be managed for more than 256 queues, I think it means it is not limited. In this case, we probably don't need the API *_queue_stats_mapping which was invented for a limitation of ixgbe. The problem is probably somewhere else (in testpmd), that's why I am against this patch.
[dpdk-dev] [PATCH v2 0/4] vhost: remove dequeue zero-copy support
As announced in DPDK v20.08, this series removes dequeue zero-copy support to Vhost library. Support for the feature is also being removed in OVS. Changes in v2: -- * Fix build issue due to unused symbol (Chenbo) * Remove remaining zmbuf related struct definition (Chenbo) * Fix typo in commit message (Chenbo) * Remove helper string in Vhost PMD (Chenbo) Maxime Coquelin (4): net/vhost: remove dequeue zero-copy support examples/vhost_crypto: use vhost async-copy flag examples/vhost: remove dequeue zero-copy support vhost: remove dequeue zero-copy support doc/guides/prog_guide/vhost_lib.rst | 52 + drivers/net/vhost/rte_eth_vhost.c | 14 -- examples/vhost/main.c | 18 +- examples/vhost_crypto/main.c| 2 +- lib/librte_vhost/rte_vhost.h| 2 +- lib/librte_vhost/socket.c | 47 lib/librte_vhost/vhost.c| 14 -- lib/librte_vhost/vhost.h| 28 --- lib/librte_vhost/vhost_user.c | 80 +-- lib/librte_vhost/virtio_net.c | 326 +++- 10 files changed, 35 insertions(+), 548 deletions(-) -- 2.26.2
[dpdk-dev] [PATCH v2 1/4] net/vhost: remove dequeue zero-copy support
The dequeue zero-copy feature from the Vhost library is
being removed in this release, this patch remove its support
in the Vhost PMD.
Signed-off-by: Maxime Coquelin
---
drivers/net/vhost/rte_eth_vhost.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/net/vhost/rte_eth_vhost.c
b/drivers/net/vhost/rte_eth_vhost.c
index ce32be9ce3..5a39293083 100644
--- a/drivers/net/vhost/rte_eth_vhost.c
+++ b/drivers/net/vhost/rte_eth_vhost.c
@@ -29,7 +29,6 @@ enum {VIRTIO_RXQ, VIRTIO_TXQ, VIRTIO_QNUM};
#define ETH_VHOST_IFACE_ARG"iface"
#define ETH_VHOST_QUEUES_ARG "queues"
#define ETH_VHOST_CLIENT_ARG "client"
-#define ETH_VHOST_DEQUEUE_ZERO_COPY"dequeue-zero-copy"
#define ETH_VHOST_IOMMU_SUPPORT"iommu-support"
#define ETH_VHOST_POSTCOPY_SUPPORT "postcopy-support"
#define ETH_VHOST_VIRTIO_NET_F_HOST_TSO "tso"
@@ -41,7 +40,6 @@ static const char *valid_arguments[] = {
ETH_VHOST_IFACE_ARG,
ETH_VHOST_QUEUES_ARG,
ETH_VHOST_CLIENT_ARG,
- ETH_VHOST_DEQUEUE_ZERO_COPY,
ETH_VHOST_IOMMU_SUPPORT,
ETH_VHOST_POSTCOPY_SUPPORT,
ETH_VHOST_VIRTIO_NET_F_HOST_TSO,
@@ -1501,7 +1499,6 @@ rte_pmd_vhost_probe(struct rte_vdev_device *dev)
uint64_t flags = 0;
uint64_t disable_flags = 0;
int client_mode = 0;
- int dequeue_zero_copy = 0;
int iommu_support = 0;
int postcopy_support = 0;
int tso = 0;
@@ -1561,16 +1558,6 @@ rte_pmd_vhost_probe(struct rte_vdev_device *dev)
flags |= RTE_VHOST_USER_CLIENT;
}
- if (rte_kvargs_count(kvlist, ETH_VHOST_DEQUEUE_ZERO_COPY) == 1) {
- ret = rte_kvargs_process(kvlist, ETH_VHOST_DEQUEUE_ZERO_COPY,
-&open_int, &dequeue_zero_copy);
- if (ret < 0)
- goto out_free;
-
- if (dequeue_zero_copy)
- flags |= RTE_VHOST_USER_DEQUEUE_ZERO_COPY;
- }
-
if (rte_kvargs_count(kvlist, ETH_VHOST_IOMMU_SUPPORT) == 1) {
ret = rte_kvargs_process(kvlist, ETH_VHOST_IOMMU_SUPPORT,
&open_int, &iommu_support);
@@ -1674,7 +1661,6 @@ RTE_PMD_REGISTER_PARAM_STRING(net_vhost,
"iface= "
"queues= "
"client=<0|1> "
- "dequeue-zero-copy=<0|1> "
"iommu-support=<0|1> "
"postcopy-support=<0|1> "
"tso=<0|1> "
--
2.26.2
[dpdk-dev] [PATCH v2 2/4] examples/vhost_crypto: use vhost async-copy flag
The crypto backend uses RTE_VHOST_USER_DEQUEUE_ZERO_COPY only
for the shared areas to be populated at mmap time. It does
not use the other mechanisms the feature provides.
Now that RTE_VHOST_USER_DEQUEUE_ZERO_COPY is being removed,
let's use RTE_VHOST_USER_ASYNC_COPY instead which does the
same thing.
Signed-off-by: Maxime Coquelin
Reviewed-by: Chenbo Xia
---
examples/vhost_crypto/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/examples/vhost_crypto/main.c b/examples/vhost_crypto/main.c
index 1d7ba94196..4bdd12f695 100644
--- a/examples/vhost_crypto/main.c
+++ b/examples/vhost_crypto/main.c
@@ -588,7 +588,7 @@ main(int argc, char *argv[])
for (j = 0; j < lo->nb_sockets; j++) {
ret = rte_vhost_driver_register(lo->socket_files[j],
- RTE_VHOST_USER_DEQUEUE_ZERO_COPY);
+ RTE_VHOST_USER_ASYNC_COPY);
if (ret < 0) {
RTE_LOG(ERR, USER1, "socket %s already
exists\n",
lo->socket_files[j]);
--
2.26.2
[dpdk-dev] [PATCH v2 3/4] examples/vhost: remove dequeue zero-copy support
Dequeue zero-copy feature is being removed from the
Vhost library. This preliminary patch removes its uses
in the Vhost example application.
Signed-off-by: Maxime Coquelin
Reviewed-by: Chenbo Xia
---
examples/vhost/main.c | 18 +-
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/examples/vhost/main.c b/examples/vhost/main.c
index e1578e7956..959c0c2838 100644
--- a/examples/vhost/main.c
+++ b/examples/vhost/main.c
@@ -92,7 +92,6 @@ static uint32_t enable_tx_csum;
static uint32_t enable_tso;
static int client_mode;
-static int dequeue_zero_copy;
static int builtin_net_driver;
@@ -247,16 +246,6 @@ port_init(uint16_t port)
rx_ring_size = RTE_TEST_RX_DESC_DEFAULT;
tx_ring_size = RTE_TEST_TX_DESC_DEFAULT;
- /*
-* When dequeue zero copy is enabled, guest Tx used vring will be
-* updated only when corresponding mbuf is freed. Thus, the nb_tx_desc
-* (tx_ring_size here) must be small enough so that the driver will
-* hit the free threshold easily and free mbufs timely. Otherwise,
-* guest Tx vring would be starved.
-*/
- if (dequeue_zero_copy)
- tx_ring_size = 64;
-
tx_rings = (uint16_t)rte_lcore_count();
/* Get port configuration. */
@@ -457,8 +446,7 @@ us_vhost_usage(const char *prgname)
" --socket-file: The path of the socket file.\n"
" --tx-csum [0|1] disable/enable TX checksum offload.\n"
" --tso [0|1] disable/enable TCP segment offload.\n"
- " --client register a vhost-user socket as client mode.\n"
- " --dequeue-zero-copy enables dequeue zero copy\n",
+ " --client register a vhost-user socket as client
mode.\n",
prgname);
}
@@ -483,7 +471,6 @@ us_vhost_parse_args(int argc, char **argv)
{"tx-csum", required_argument, NULL, 0},
{"tso", required_argument, NULL, 0},
{"client", no_argument, &client_mode, 1},
- {"dequeue-zero-copy", no_argument, &dequeue_zero_copy, 1},
{"builtin-net-driver", no_argument, &builtin_net_driver, 1},
{NULL, 0, 0, 0},
};
@@ -1510,9 +1497,6 @@ main(int argc, char *argv[])
if (client_mode)
flags |= RTE_VHOST_USER_CLIENT;
- if (dequeue_zero_copy)
- flags |= RTE_VHOST_USER_DEQUEUE_ZERO_COPY;
-
/* Register vhost user driver to handle vhost messages. */
for (i = 0; i < nb_sockets; i++) {
char *file = socket_files + i * PATH_MAX;
--
2.26.2
[dpdk-dev] [PATCH v2 4/4] vhost: remove dequeue zero-copy support
Dequeue zero-copy removal was announced in DPDK v20.08.
This feature brings constraints which makes the maintenance
of the Vhost library difficult. Its limitations makes it also
difficult to use by the applications (Tx vring starvation).
Removing it makes it easier to add new features, and also remove
some code in the hot path, which should bring a performance
improvement for the standard path.
Signed-off-by: Maxime Coquelin
---
doc/guides/prog_guide/vhost_lib.rst | 52 +
lib/librte_vhost/rte_vhost.h| 2 +-
lib/librte_vhost/socket.c | 47
lib/librte_vhost/vhost.c| 14 --
lib/librte_vhost/vhost.h| 28 ---
lib/librte_vhost/vhost_user.c | 80 +--
lib/librte_vhost/virtio_net.c | 326 +++-
7 files changed, 33 insertions(+), 516 deletions(-)
diff --git a/doc/guides/prog_guide/vhost_lib.rst
b/doc/guides/prog_guide/vhost_lib.rst
index b892eec67a..ba4c62aeb8 100644
--- a/doc/guides/prog_guide/vhost_lib.rst
+++ b/doc/guides/prog_guide/vhost_lib.rst
@@ -51,50 +51,6 @@ The following is an overview of some key Vhost API functions:
This reconnect option is enabled by default. However, it can be turned off
by setting this flag.
- - ``RTE_VHOST_USER_DEQUEUE_ZERO_COPY``
-
-Dequeue zero copy will be enabled when this flag is set. It is disabled by
-default.
-
-There are some truths (including limitations) you might want to know while
-setting this flag:
-
-* zero copy is not good for small packets (typically for packet size below
- 512).
-
-* zero copy is really good for VM2VM case. For iperf between two VMs, the
- boost could be above 70% (when TSO is enabled).
-
-* For zero copy in VM2NIC case, guest Tx used vring may be starved if the
- PMD driver consume the mbuf but not release them timely.
-
- For example, i40e driver has an optimization to maximum NIC pipeline
which
- postpones returning transmitted mbuf until only tx_free_threshold free
- descs left. The virtio TX used ring will be starved if the formula
- (num_i40e_tx_desc - num_virtio_tx_desc > tx_free_threshold) is true,
since
- i40e will not return back mbuf.
-
- A performance tip for tuning zero copy in VM2NIC case is to adjust the
- frequency of mbuf free (i.e. adjust tx_free_threshold of i40e driver) to
- balance consumer and producer.
-
-* Guest memory should be backended with huge pages to achieve better
- performance. Using 1G page size is the best.
-
- When dequeue zero copy is enabled, the guest phys address and host phys
- address mapping has to be established. Using non-huge pages means far
- more page segments. To make it simple, DPDK vhost does a linear search
- of those segments, thus the fewer the segments, the quicker we will get
- the mapping. NOTE: we may speed it by using tree searching in future.
-
-* zero copy can not work when using vfio-pci with iommu mode currently,
this
- is because we don't setup iommu dma mapping for guest memory. If you have
- to use vfio-pci driver, please insert vfio-pci kernel module in noiommu
- mode.
-
-* The consumer of zero copy mbufs should consume these mbufs as soon as
- possible, otherwise it may block the operations in vhost.
-
- ``RTE_VHOST_USER_IOMMU_SUPPORT``
IOMMU support will be enabled when this flag is set. It is disabled by
@@ -362,16 +318,16 @@ Guest memory requirement
* Memory pre-allocation
- For non-zerocopy non-async data path, guest memory pre-allocation is not a
+ For non-async data path, guest memory pre-allocation is not a
must. This can help save of memory. If users really want the guest memory
to be pre-allocated (e.g., for performance reason), we can add option
``-mem-prealloc`` when starting QEMU. Or, we can lock all memory at vhost
side which will force memory to be allocated when mmap at vhost side;
option --mlockall in ovs-dpdk is an example in hand.
- For async and zerocopy data path, we force the VM memory to be
- pre-allocated at vhost lib when mapping the guest memory; and also we need
- to lock the memory to prevent pages being swapped out to disk.
+ For async data path, we force the VM memory to be pre-allocated at vhost
+ lib when mapping the guest memory; and also we need to lock the memory to
+ prevent pages being swapped out to disk.
* Memory sharing
diff --git a/lib/librte_vhost/rte_vhost.h b/lib/librte_vhost/rte_vhost.h
index a94c84134d..46019df6fe 100644
--- a/lib/librte_vhost/rte_vhost.h
+++ b/lib/librte_vhost/rte_vhost.h
@@ -28,7 +28,7 @@ extern "C" {
#define RTE_VHOST_USER_CLIENT (1ULL << 0)
#define RTE_VHOST_USER_NO_RECONNECT(1ULL << 1)
-#define RTE_VHOST_USER_DEQUEUE_ZERO_COPY (1ULL << 2)
+#define RTE_VHOST_USER_RESERVED_1 (1ULL << 2)
#define RTE_VHOST_USER_IOMMU_SUPPORT (1ULL << 3)
#define RTE_VHOST_USER_POSTCOPY_SUPPORT
Re: [dpdk-dev] [dpdk-techboard] [PATCH V5 2/2] ethdev: change data type in TC rxq and TC txq
28/09/2020 11:04, Ferruh Yigit:
> On 9/27/2020 4:16 AM, Min Hu (Connor) wrote:
> > From: Huisong Li
> >
> > Currently, base and nb_queue in the tc_rxq and tc_txq information
> > of queue and TC mapping on both TX and RX paths are uint8_t.
> > However, these data will be truncated when queue number under a TC
> > is greater than 256. So it is necessary for base and nb_queue to
> > change from uint8_t to uint16_t.
[...]
> > --- a/lib/librte_ethdev/rte_ethdev.h
> > +++ b/lib/librte_ethdev/rte_ethdev.h
> > struct rte_eth_dcb_tc_queue_mapping {
> > /** rx queues assigned to tc per Pool */
> > struct {
> > - uint8_t base;
> > - uint8_t nb_queue;
> > + uint16_t base;
> > + uint16_t nb_queue;
> > } tc_rxq[ETH_MAX_VMDQ_POOL][ETH_DCB_NUM_TCS];
> > /** rx queues assigned to tc per Pool */
> > struct {
> > - uint8_t base;
> > - uint8_t nb_queue;
> > + uint16_t base;
> > + uint16_t nb_queue;
> > } tc_txq[ETH_MAX_VMDQ_POOL][ETH_DCB_NUM_TCS];
> > };
> >
> >
>
> cc'ed tech-board,
>
> The patch breaks the ethdev ABI without a deprecation notice from previous
> release(s).
>
> It is increasing the storage size of the fields to support more than 255
> queues.
Yes queues are in 16-bit range.
> Since the ethdev library already heavily breaks the ABI this release, I am
> for
> getting this patch, instead of waiting for one more year for the update.
>
> Can you please review the patch, is there any objection to proceed with it?
Acked-by: Thomas Monjalon
Re: [dpdk-dev] [PATCH] [RFC] cryptodev: move AES-GMAC to aead algorithms
Hi Akhil, > -Original Message- > From: Akhil Goyal > Sent: Tuesday, September 22, 2020 8:18 PM > To: Kusztal, ArkadiuszX ; Doherty, Declan > ; > dev@dpdk.org > Cc: Trahe, Fiona ; ano...@marvell.com; > shal...@marvell.com; Zhang, Roy Fan > ; Ananyev, Konstantin > Subject: RE: [PATCH] [RFC] cryptodev: move AES-GMAC to aead algorithms > > Hi Arek, > > > > > Hi Akhil, > > > > @Akhil: Is there a chance getting this change into 20.11? > > > > Any more comments or anyone see any potential issues with this approach? > > > > I am ok to take this patch in 20.11 release. Could you please send a new > version > With complete patch, removing all references of RTE_CRYPTO_AUTH_AES_GMAC. > > Please explain in the release notes and deprecation notice as well. We're ok to live with it as is and don’t plan to send a patch at this time. > > > > Subject: Re: [PATCH] [RFC] cryptodev: move AES-GMAC to aead algorithms > > > > On 29/07/2020 3:22 PM, Arek Kusztal wrote: > > > This is proposal to move AES-GMAC algorithm to AEAD set of algorithms. > > > It is however not 100% conformant GMAC as instead of aad pointer data > > > to be authenticated is passed normally and aead.data.length field is > > > used to specify length of data to be authenticated. > > > Reason behind this move is that GMAC is variant of GCM so it may > > > simplify implementations that are using these algorithms (mainly IPsec). > > > AES-GMAC therefore needs to be removed from auth algorithms. > > > > > > Signed-off-by: Arek Kusztal > > > --- > > .. > > > > > > > I think this makes sense in light of how AES-GMAC support is specified in > > the > > IPsec GMAC rfc > > (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.iet > > f.org%2Fhtml%2Frfc4543&data=02%7C01%7Cakhil.goyal%40nxp.com%7Cf > > 0aec031674e4832272108d838f7e961%7C686ea1d3bc2b4c6fa92cd99c5c301635 > > %7C0%7C0%7C637321984712376305&sdata=OgaLnAqcAGg1xzD8QfSWn% > > 2F9Qa8vOkqEiZutDZcz5JLo%3D&reserved=0) > > > > Acked-by: Declan Doherty
Re: [dpdk-dev] [PATCH v5 0/3] pmdinfogen: rewrite in Python
Hello Dmitry, On Sun, Sep 27, 2020 at 11:48 PM Dmitry Kozlyuk wrote: > > This patchset implements existing pmdinfogen logic in Python, replaces > and removes the old code. The goals of rewriting are: > * support pmdinfo on Windows ? :-) > * easier maintenance by using a more high-level language, > * simpler build process without host application and libelf. > > Travis CI script is adjusted to install python3-pyelftools, but other CI > systems may need similar tweaking. Particularly, testing on FreeBSD and > big-endian targets is desired. This new requirement will impact mainly distribution packagers, developers and the CI. While I think this is fine for the first two categories (python-elftools is now available on most distributions, and you can also pip install it), the last category is a concern. If we want to move forward with this patch, this must be addressed in a timely manner as we don't want to break the CI. -- David Marchand
Re: [dpdk-dev] [PATCH] bus/pci: fix mapping BAR containing MSI-X table
On Fri, Sep 25, 2020 at 4:15 AM Hyong Youb Kim wrote:
>
> When the BAR contains MSI-X table, pci_vfio_mmap_bar() tries to skip
> the table and map the rest. "map around it" is the phrase used in the
> source. The function splits the BAR into two regions: the region
> before the table (first part or memreg[0]) and the region after the
> table (second part or memreg[1]).
>
> For hardware that has MSI-X vector table offset 0, the first part does
> not exist (memreg[0].size == 0).
>
> Capabilities: [60] MSI-X: Enable- Count=48 Masked-
> Vector table: BAR=2 offset=
> PBA: BAR=2 offset=1000
>
> The mapping part of the function maps the first part, if it
> exists. Then, it maps the second part, if it exists and "if mapping the
> first part succeeded".
>
> The recent change that replaces MAP_FAILED with NULL breaks the "if
> mapping the first part succeeded" condition (1) in the snippet below.
>
> void *map_addr = NULL;
> if (memreg[0].size) {
> /* actual map of first part */
> map_addr = pci_map_resource(...);
> }
>
> /* if there's a second part, try to map it */
> if (map_addr != NULL // -- (1)
> && memreg[1].offset && memreg[1].size) {
> [...]
> }
>
> if (map_addr == NULL) {
> RTE_LOG(ERR, EAL, "Failed to map pci BAR%d\n",
> bar_index);
> return -1;
> }
>
> When the first part does not exist, (1) sees map_addr is still NULL,
> and the function fails. This behavior is a regression and fails
> probing hardware with vector table offset 0.
>
> Previously, (1) was "map_addr != MAP_FAILED", which meant
> pci_map_resource() was actually attempted and failed. So, expand (1)
> to check if the first part exists as well, to match the semantics of
> MAP_FAILED.
>
> Bugzilla ID: 539
> Fixes: e200535c1ca3 ("mem: drop mapping API workaround")
>
> Signed-off-by: Hyong Youb Kim
Acked-by: Anatoly Burakov
Applied, thanks.
--
David Marchand
Re: [dpdk-dev] [PATCH] bus/pci: fix mapping of PCI resources
On Mon, Sep 28, 2020 at 11:11 AM Burakov, Anatoly wrote: > Dupe of http://patches.dpdk.org/patch/78768/ ? Yes. -- David Marchand
[dpdk-dev] [PATCH v3 0/2] enable large VF configuration
This patchset supports to configure up to 256 queue pairs per VF. If large VF is supported after capability negotiation, VF will request queues from PF as needed. New virtual channel opcodes and structures are used to indicate 256 queues, so VF is designed to handle the new function of configure VSI queues, IRQ mapping and enable/disable queues. Also, enable VF to query the max RSS queue region. Ting Xu (2): net/iavf: add IAVF request queues function net/iavf: enable large VF configuration --- v2->v3: Fix coding style issue. Move get max RSS queue region after VF reset. Add request queues capability negotiation. v1->v2: Change the communication with kernel PF. --- drivers/net/iavf/iavf.h| 40 ++- drivers/net/iavf/iavf_ethdev.c | 102 +++- drivers/net/iavf/iavf_rxtx.c | 27 +- drivers/net/iavf/iavf_vchnl.c | 444 ++--- 4 files changed, 558 insertions(+), 55 deletions(-) -- 2.17.1
[dpdk-dev] [PATCH v3 1/2] net/iavf: add IAVF request queues function
Add new virtchnl function to request additional queues from PF. Current
default queue pairs number when creating a VF is 16. In order to support
up to 256 queue pairs, enable this request queues function.
Since request queues command may return event message, modify function
iavf_read_msg_from_pf to identify event opcode and mark VF reset status.
Signed-off-by: Ting Xu
---
drivers/net/iavf/iavf.h| 17
drivers/net/iavf/iavf_ethdev.c | 12 ++-
drivers/net/iavf/iavf_vchnl.c | 145 ++---
3 files changed, 158 insertions(+), 16 deletions(-)
diff --git a/drivers/net/iavf/iavf.h b/drivers/net/iavf/iavf.h
index d56611608..1c40f9bdf 100644
--- a/drivers/net/iavf/iavf.h
+++ b/drivers/net/iavf/iavf.h
@@ -107,6 +107,21 @@ struct iavf_fdir_info {
/* TODO: is that correct to assume the max number to be 16 ?*/
#define IAVF_MAX_MSIX_VECTORS 16
+/* Event status from PF */
+enum pending_msg {
+ PFMSG_LINK_CHANGE = 0x1,
+ PFMSG_RESET_IMPENDING = 0x2,
+ PFMSG_DRIVER_CLOSE = 0x4,
+};
+
+/* Message type read in admin queue from PF */
+enum iavf_aq_result {
+ IAVF_MSG_ERR = -1, /* Meet error when accessing admin queue */
+ IAVF_MSG_NON, /* Read nothing from admin queue */
+ IAVF_MSG_SYS, /* Read system msg from admin queue */
+ IAVF_MSG_CMD, /* Read async command result */
+};
+
/* Structure to store private data specific for VF instance. */
struct iavf_info {
uint16_t num_queue_pairs;
@@ -123,6 +138,7 @@ struct iavf_info {
volatile enum virtchnl_ops pend_cmd; /* pending command not finished */
uint32_t cmd_retval; /* return value of the cmd response from PF */
uint8_t *aq_resp; /* buffer to store the adminq response from PF */
+ uint16_t pend_msg; /* flags indicates events from pf not handled yet */
/* Event from pf */
bool dev_closed;
@@ -301,4 +317,5 @@ int iavf_add_del_rss_cfg(struct iavf_adapter *adapter,
int iavf_add_del_mc_addr_list(struct iavf_adapter *adapter,
struct rte_ether_addr *mc_addrs,
uint32_t mc_addrs_num, bool add);
+int iavf_request_queues(struct rte_eth_dev *dev, uint16_t num);
#endif /* _IAVF_ETHDEV_H_ */
diff --git a/drivers/net/iavf/iavf_ethdev.c b/drivers/net/iavf/iavf_ethdev.c
index a88d53ab0..33745a7b2 100644
--- a/drivers/net/iavf/iavf_ethdev.c
+++ b/drivers/net/iavf/iavf_ethdev.c
@@ -1236,7 +1236,7 @@ iavf_dev_rx_queue_intr_disable(struct rte_eth_dev *dev,
uint16_t queue_id)
}
static int
-iavf_check_vf_reset_done(struct iavf_hw *hw)
+iavf_check_vf_reset_done(struct iavf_hw *hw, struct iavf_info *vf)
{
int i, reset;
@@ -1253,6 +1253,10 @@ iavf_check_vf_reset_done(struct iavf_hw *hw)
if (i >= IAVF_RESET_WAIT_CNT)
return -1;
+ /* VF is not in reset or reset is completed */
+ vf->vf_reset = false;
+ vf->pend_msg &= ~PFMSG_RESET_IMPENDING;
+
return 0;
}
@@ -1620,7 +1624,7 @@ iavf_init_vf(struct rte_eth_dev *dev)
goto err;
}
- err = iavf_check_vf_reset_done(hw);
+ err = iavf_check_vf_reset_done(hw, vf);
if (err) {
PMD_INIT_LOG(ERR, "VF is still resetting");
goto err;
@@ -1869,7 +1873,9 @@ iavf_dev_close(struct rte_eth_dev *dev)
iavf_dev_stop(dev);
iavf_flow_flush(dev, NULL);
- iavf_flow_uninit(adapter);
+ /* if VF is in reset, adminq is disabled, skip the process via adminq */
+ if (!vf->vf_reset)
+ iavf_flow_uninit(adapter);
iavf_shutdown_adminq(hw);
/* disable uio intr before callback unregister */
rte_intr_disable(intr_handle);
diff --git a/drivers/net/iavf/iavf_vchnl.c b/drivers/net/iavf/iavf_vchnl.c
index 7981dfa30..7a3344e28 100644
--- a/drivers/net/iavf/iavf_vchnl.c
+++ b/drivers/net/iavf/iavf_vchnl.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include "iavf.h"
@@ -26,13 +27,14 @@
#define ASQ_DELAY_MS 10
/* Read data in admin queue to get msg from pf driver */
-static enum iavf_status
+static enum iavf_aq_result
iavf_read_msg_from_pf(struct iavf_adapter *adapter, uint16_t buf_len,
uint8_t *buf)
{
struct iavf_hw *hw = IAVF_DEV_PRIVATE_TO_HW(adapter);
struct iavf_info *vf = IAVF_DEV_PRIVATE_TO_VF(adapter);
struct iavf_arq_event_info event;
+ enum iavf_aq_result result = IAVF_MSG_NON;
enum virtchnl_ops opcode;
int ret;
@@ -42,7 +44,9 @@ iavf_read_msg_from_pf(struct iavf_adapter *adapter, uint16_t
buf_len,
/* Can't read any msg from adminQ */
if (ret) {
PMD_DRV_LOG(DEBUG, "Can't read msg from AQ");
- return ret;
+ if (ret != IAVF_ERR_ADMIN_QUEUE_NO_WORK)
+ result = IAVF_MSG_ERR;
+ return result;
}
opcode = (enum virtchnl_ops)rte_le_to_cpu_32(event.des
Re: [dpdk-dev] [PATCH v2 02/25] ethdev: allow drivers to return error on close
For dpaa, dpaa2, enetc and pfe.
Reviewed-by: Sachin Saxena
On 28-Sep-20 5:12 AM, Thomas Monjalon wrote:
The device operation .dev_close was returning void.
This driver interface is changed to return an int.
Note that the API rte_eth_dev_close() is still returning void,
although a deprecation notice is pending to change it as well.
Signed-off-by: Thomas Monjalon
---
app/test/virtual_pmd.c| 6 --
drivers/net/af_packet/rte_eth_af_packet.c | 3 ++-
drivers/net/af_xdp/rte_eth_af_xdp.c | 4 +++-
drivers/net/ark/ark_ethdev.c | 6 --
drivers/net/atlantic/atl_ethdev.c | 6 --
drivers/net/avp/avp_ethdev.c | 5 +++--
drivers/net/axgbe/axgbe_ethdev.c | 5 +++--
drivers/net/bnx2x/bnx2x_ethdev.c | 4 +++-
drivers/net/bnxt/bnxt_ethdev.c| 4 +++-
drivers/net/bnxt/bnxt_reps.c | 3 ++-
drivers/net/bnxt/bnxt_reps.h | 2 +-
drivers/net/bonding/eth_bond_private.h| 2 +-
drivers/net/bonding/rte_eth_bond_pmd.c| 4 +++-
drivers/net/cxgbe/cxgbe_ethdev.c | 10 ++
drivers/net/cxgbe/cxgbe_pfvf.h| 2 +-
drivers/net/dpaa/dpaa_ethdev.c| 4 +++-
drivers/net/dpaa2/dpaa2_ethdev.c | 6 --
drivers/net/e1000/em_ethdev.c | 6 --
drivers/net/e1000/igb_ethdev.c| 12
drivers/net/ena/ena_ethdev.c | 6 --
drivers/net/enetc/enetc_ethdev.c | 4 +++-
drivers/net/enic/enic_ethdev.c| 4 +++-
drivers/net/enic/enic_vf_representor.c| 5 +++--
drivers/net/failsafe/failsafe_ops.c | 3 ++-
drivers/net/fm10k/fm10k_ethdev.c | 4 +++-
drivers/net/hinic/hinic_pmd_ethdev.c | 6 --
drivers/net/hns3/hns3_ethdev.c| 6 --
drivers/net/hns3/hns3_ethdev_vf.c | 6 --
drivers/net/i40e/i40e_ethdev.c| 5 +++--
drivers/net/i40e/i40e_ethdev_vf.c | 5 +++--
drivers/net/iavf/iavf_ethdev.c| 6 --
drivers/net/ice/ice_dcf_ethdev.c | 6 --
drivers/net/ice/ice_ethdev.c | 6 --
drivers/net/igc/igc_ethdev.c | 6 --
drivers/net/ionic/ionic_ethdev.c | 10 ++
drivers/net/ipn3ke/ipn3ke_representor.c | 4 +++-
drivers/net/ixgbe/ixgbe_ethdev.c | 11 +++
drivers/net/kni/rte_eth_kni.c | 4 +++-
drivers/net/liquidio/lio_ethdev.c | 4 +++-
drivers/net/memif/rte_eth_memif.c | 4 +++-
drivers/net/mlx4/mlx4.c | 3 ++-
drivers/net/mlx5/mlx5.c | 9 +
drivers/net/mlx5/mlx5.h | 2 +-
drivers/net/mvneta/mvneta_ethdev.c| 4 +++-
drivers/net/mvpp2/mrvl_ethdev.c | 4 +++-
drivers/net/netvsc/hn_ethdev.c| 4 +++-
drivers/net/nfb/nfb_ethdev.c | 4 +++-
drivers/net/nfp/nfp_net.c | 6 --
drivers/net/octeontx/octeontx_ethdev.c| 4 +++-
drivers/net/octeontx2/otx2_ethdev.c | 5 +++--
drivers/net/pcap/rte_eth_pcap.c | 3 ++-
drivers/net/pfe/pfe_ethdev.c | 8 +---
drivers/net/qede/qede_ethdev.c| 4 +++-
drivers/net/sfc/sfc_ethdev.c | 4 +++-
drivers/net/softnic/rte_eth_softnic.c | 4 ++--
drivers/net/szedata2/rte_eth_szedata2.c | 4 +++-
drivers/net/tap/rte_eth_tap.c | 4 +++-
drivers/net/thunderx/nicvf_ethdev.c | 4 +++-
drivers/net/vhost/rte_eth_vhost.c | 6 --
drivers/net/virtio/virtio_ethdev.c| 6 --
drivers/net/vmxnet3/vmxnet3_ethdev.c | 6 --
lib/librte_ethdev/rte_ethdev_driver.h | 2 +-
62 files changed, 206 insertions(+), 103 deletions(-)
diff --git a/app/test/virtual_pmd.c b/app/test/virtual_pmd.c
index b49089a33c..4bd4d1c9ad 100644
--- a/app/test/virtual_pmd.c
+++ b/app/test/virtual_pmd.c
@@ -62,9 +62,11 @@ static void virtual_ethdev_stop(struct rte_eth_dev *eth_dev
__rte_unused)
rte_pktmbuf_free(pkt);
}
-static void
+static int
virtual_ethdev_close(struct rte_eth_dev *dev __rte_unused)
-{}
+{
+ return 0;
+}
static int
virtual_ethdev_configure_success(struct rte_eth_dev *dev __rte_unused)
diff --git a/drivers/net/af_packet/rte_eth_af_packet.c
b/drivers/net/af_packet/rte_eth_af_packet.c
index b9723e9619..7d0ff1cbb3 100644
--- a/drivers/net/af_packet/rte_eth_af_packet.c
+++ b/drivers/net/af_packet/rte_eth_af_packet.c
@@ -376,9 +376,10 @@ eth_stats_reset(struct rte_eth_dev *dev)
return 0;
}
-static void
+static int
eth_dev_close(struct rte_eth_dev *dev __rte_unused)
{
+ return 0;
}
static void
diff --git a/drivers/net/af_xdp/rte_eth_af_xdp.c
b/drivers/net/af_xdp/rte_eth_af_xdp.c
index b65ee449fc..badbce63fb 100644
--- a/drivers/net/af_xdp/rte_eth_af_xdp.c
+++ b/drivers/net/af_xdp/rte_eth_af_xdp.c
@@ -7
[dpdk-dev] [PATCH v3 2/2] net/iavf: enable large VF configuration
Add support to negotiate large VF capability, configure VSI queues,
enable/disable queues and IRQ mapping for large VF. Use new virtchnl
opcodes and structures to support max 256 queue pairs. Request
additional queues from PF first if current allocated queues are not
enough. Query max RSS queue region for future RSS configuration.
Signed-off-by: Ting Xu
---
drivers/net/iavf/iavf.h| 23 ++-
drivers/net/iavf/iavf_ethdev.c | 90 --
drivers/net/iavf/iavf_rxtx.c | 27 ++-
drivers/net/iavf/iavf_vchnl.c | 301 ++---
4 files changed, 401 insertions(+), 40 deletions(-)
diff --git a/drivers/net/iavf/iavf.h b/drivers/net/iavf/iavf.h
index 1c40f9bdf..b2e896598 100644
--- a/drivers/net/iavf/iavf.h
+++ b/drivers/net/iavf/iavf.h
@@ -19,7 +19,10 @@
#define IAVF_FRAME_SIZE_MAX 9728
#define IAVF_QUEUE_BASE_ADDR_UNIT 128
-#define IAVF_MAX_NUM_QUEUES 16
+#define IAVF_MAX_NUM_QUEUES_DFLT16
+#define IAVF_MAX_NUM_QUEUES_LV 256
+#define IAVF_RXTX_QUEUE_CHUNKS_NUM 2
+#define IAVF_CFG_Q_NUM_PER_BUF 32
#define IAVF_NUM_MACADDR_MAX 64
@@ -104,8 +107,10 @@ struct iavf_fdir_info {
struct iavf_fdir_conf conf;
};
-/* TODO: is that correct to assume the max number to be 16 ?*/
-#define IAVF_MAX_MSIX_VECTORS 16
+struct iavf_qv_map {
+ uint16_t queue_id;
+ uint16_t vector_id;
+};
/* Event status from PF */
enum pending_msg {
@@ -157,14 +162,16 @@ struct iavf_info {
uint8_t *rss_key;
uint16_t nb_msix; /* number of MSI-X interrupts on Rx */
uint16_t msix_base; /* msix vector base from */
- /* queue bitmask for each vector */
- uint16_t rxq_map[IAVF_MAX_MSIX_VECTORS];
+ uint16_t max_rss_qregion; /* max RSS queue region supported by PF */
+ struct iavf_qv_map *qv_map; /* queue vector mapping */
struct iavf_flow_list flow_list;
rte_spinlock_t flow_ops_lock;
struct iavf_parser_list rss_parser_list;
struct iavf_parser_list dist_parser_list;
struct iavf_fdir_info fdir; /* flow director info */
+ /* indicate large VF support enabled or not */
+ bool lv_enabled;
};
#define IAVF_MAX_PKT_TYPE 1024
@@ -291,13 +298,18 @@ int iavf_enable_vlan_strip(struct iavf_adapter *adapter);
int iavf_disable_vlan_strip(struct iavf_adapter *adapter);
int iavf_switch_queue(struct iavf_adapter *adapter, uint16_t qid,
bool rx, bool on);
+int iavf_switch_queue_lv(struct iavf_adapter *adapter, uint16_t qid,
+bool rx, bool on);
int iavf_enable_queues(struct iavf_adapter *adapter);
+int iavf_enable_queues_lv(struct iavf_adapter *adapter);
int iavf_disable_queues(struct iavf_adapter *adapter);
+int iavf_disable_queues_lv(struct iavf_adapter *adapter);
int iavf_configure_rss_lut(struct iavf_adapter *adapter);
int iavf_configure_rss_key(struct iavf_adapter *adapter);
int iavf_configure_queues(struct iavf_adapter *adapter);
int iavf_get_supported_rxdid(struct iavf_adapter *adapter);
int iavf_config_irq_map(struct iavf_adapter *adapter);
+int iavf_config_irq_map_lv(struct iavf_adapter *adapter);
void iavf_add_del_all_mac_addr(struct iavf_adapter *adapter, bool add);
int iavf_dev_link_update(struct rte_eth_dev *dev,
__rte_unused int wait_to_complete);
@@ -318,4 +330,5 @@ int iavf_add_del_mc_addr_list(struct iavf_adapter *adapter,
struct rte_ether_addr *mc_addrs,
uint32_t mc_addrs_num, bool add);
int iavf_request_queues(struct rte_eth_dev *dev, uint16_t num);
+int iavf_get_max_rss_queue_region(struct iavf_adapter *adapter);
#endif /* _IAVF_ETHDEV_H_ */
diff --git a/drivers/net/iavf/iavf_ethdev.c b/drivers/net/iavf/iavf_ethdev.c
index 33745a7b2..fdb2294a8 100644
--- a/drivers/net/iavf/iavf_ethdev.c
+++ b/drivers/net/iavf/iavf_ethdev.c
@@ -205,7 +205,7 @@ iavf_init_rss(struct iavf_adapter *adapter)
rss_conf = &adapter->eth_dev->data->dev_conf.rx_adv_conf.rss_conf;
nb_q = RTE_MIN(adapter->eth_dev->data->nb_rx_queues,
- IAVF_MAX_NUM_QUEUES);
+ vf->max_rss_qregion);
if (!(vf->vf_res->vf_cap_flags & VIRTCHNL_VF_OFFLOAD_RSS_PF)) {
PMD_DRV_LOG(DEBUG, "RSS is not supported");
@@ -258,6 +258,9 @@ iavf_dev_configure(struct rte_eth_dev *dev)
IAVF_DEV_PRIVATE_TO_ADAPTER(dev->data->dev_private);
struct iavf_info *vf = IAVF_DEV_PRIVATE_TO_VF(ad);
struct rte_eth_conf *dev_conf = &dev->data->dev_conf;
+ uint16_t num_queue_pairs = RTE_MAX(dev->data->nb_rx_queues,
+ dev->data->nb_tx_queues);
+ int ret = 0;
ad->rx_bulk_alloc_allowed = true;
/* Initialize to TRUE. If any of Rx queues doesn't meet the
@@ -269,6 +272,45 @@ iavf_dev_configure(struct rte_eth_dev *dev)
if (dev->data->dev_conf.rxmode.mq_mode & ETH_MQ_RX_RSS_FLAG)
dev->data->dev_conf.rxmode.of
Re: [dpdk-dev] [PATCH v2 18/25] drivers/net: accept removing device without any port
For "net/pfe"
Reviewed-by: Sachin Saxena
On 28-Sep-20 5:12 AM, Thomas Monjalon wrote:
The ports can be closed (i.e. completely released)
before removing the whole device.
Such case was wrongly considered an error by some drivers.
If the device supports only one port, there is nothing much
to free after the port is closed.
Signed-off-by: Thomas Monjalon
Reviewed-by: Ferruh Yigit
Reviewed-by: Rosen Xu
---
drivers/net/ipn3ke/ipn3ke_ethdev.c | 6 ++
drivers/net/kni/rte_eth_kni.c | 16 +++-
drivers/net/netvsc/hn_ethdev.c | 2 +-
drivers/net/nfp/nfp_net.c | 2 ++
drivers/net/pfe/pfe_ethdev.c| 6 ++
drivers/net/szedata2/rte_eth_szedata2.c | 6 ++
6 files changed, 16 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ipn3ke/ipn3ke_ethdev.c
b/drivers/net/ipn3ke/ipn3ke_ethdev.c
index 027be29bd8..4446d2af9e 100644
--- a/drivers/net/ipn3ke/ipn3ke_ethdev.c
+++ b/drivers/net/ipn3ke/ipn3ke_ethdev.c
@@ -562,10 +562,8 @@ static int ipn3ke_vswitch_remove(struct rte_afu_device
*afu_dev)
afu_dev->device.name, i);
ethdev = rte_eth_dev_allocated(afu_dev->device.name);
- if (!ethdev)
- return -ENODEV;
-
- rte_eth_dev_destroy(ethdev, ipn3ke_rpst_uninit);
+ if (ethdev != NULL)
+ rte_eth_dev_destroy(ethdev, ipn3ke_rpst_uninit);
}
ret = rte_eth_switch_domain_free(hw->switch_domain_id);
diff --git a/drivers/net/kni/rte_eth_kni.c b/drivers/net/kni/rte_eth_kni.c
index 45ab1b17a8..2a4058f7b0 100644
--- a/drivers/net/kni/rte_eth_kni.c
+++ b/drivers/net/kni/rte_eth_kni.c
@@ -488,17 +488,15 @@ eth_kni_remove(struct rte_vdev_device *vdev)
/* find the ethdev entry */
eth_dev = rte_eth_dev_allocated(name);
- if (eth_dev == NULL)
- return -1;
-
- if (rte_eal_process_type() != RTE_PROC_PRIMARY) {
- eth_kni_dev_stop(eth_dev);
- return rte_eth_dev_release_port(eth_dev);
+ if (eth_dev != NULL) {
+ if (rte_eal_process_type() != RTE_PROC_PRIMARY) {
+ eth_kni_dev_stop(eth_dev);
+ return rte_eth_dev_release_port(eth_dev);
+ }
+ eth_kni_close(eth_dev);
+ rte_eth_dev_release_port(eth_dev);
}
- eth_kni_close(eth_dev);
- rte_eth_dev_release_port(eth_dev);
-
is_kni_initialized--;
if (is_kni_initialized == 0)
rte_kni_close();
diff --git a/drivers/net/netvsc/hn_ethdev.c b/drivers/net/netvsc/hn_ethdev.c
index 15d6e9762d..19a9eb6bc2 100644
--- a/drivers/net/netvsc/hn_ethdev.c
+++ b/drivers/net/netvsc/hn_ethdev.c
@@ -1092,7 +1092,7 @@ static int eth_hn_remove(struct rte_vmbus_device *dev)
eth_dev = rte_eth_dev_allocated(dev->device.name);
if (!eth_dev)
- return -ENODEV;
+ return 0; /* port already released */
ret = eth_hn_dev_uninit(eth_dev);
if (ret)
diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index 9509dc8bd6..ce25cf1ed4 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -3739,6 +3739,8 @@ static int eth_nfp_pci_remove(struct rte_pci_device
*pci_dev)
int port = 0;
eth_dev = rte_eth_dev_allocated(pci_dev->device.name);
+ if (eth_dev == NULL)
+ return 0; /* port already released */
if ((pci_dev->id.device_id == PCI_DEVICE_ID_NFP4000_PF_NIC) ||
(pci_dev->id.device_id == PCI_DEVICE_ID_NFP6000_PF_NIC)) {
port = get_pf_port_number(eth_dev->data->name);
diff --git a/drivers/net/pfe/pfe_ethdev.c b/drivers/net/pfe/pfe_ethdev.c
index 187a0019ff..9d5415d9b1 100644
--- a/drivers/net/pfe/pfe_ethdev.c
+++ b/drivers/net/pfe/pfe_ethdev.c
@@ -1155,10 +1155,8 @@ pmd_pfe_remove(struct rte_vdev_device *vdev)
return 0;
eth_dev = rte_eth_dev_allocated(name);
- if (eth_dev == NULL)
- return -ENODEV;
-
- pfe_eth_exit(eth_dev, g_pfe);
+ if (eth_dev != NULL)
+ pfe_eth_exit(eth_dev, g_pfe);
munmap(g_pfe->cbus_baseaddr, g_pfe->cbus_size);
if (g_pfe->nb_devs == 0) {
diff --git a/drivers/net/szedata2/rte_eth_szedata2.c
b/drivers/net/szedata2/rte_eth_szedata2.c
index 4325b9a30d..5f589dfa4c 100644
--- a/drivers/net/szedata2/rte_eth_szedata2.c
+++ b/drivers/net/szedata2/rte_eth_szedata2.c
@@ -1910,10 +1910,8 @@ static int szedata2_eth_pci_remove(struct rte_pci_device
*pci_dev)
pci_dev->device.name, i);
PMD_DRV_LOG(DEBUG, "Removing eth_dev %s", name);
eth_dev = rte_eth_dev_allocated(name);
- if (!eth_dev) {
- PMD_DRV_LOG(ERR, "eth_dev %s not found", name);
- retval = retval ? retval : -ENODEV;
- }
+ if (eth_dev == NULL)
+
Re: [dpdk-dev] [PATCH v2 19/25] drivers/net: check process type in close operation
For dpaa, dpaa2, enetc and pfe
Reviewed-by: Sachin Saxena
On 28-Sep-20 5:12 AM, Thomas Monjalon wrote:
The secondary processes are not allowed to release shared resources.
Only process-private ressources should be freed in a secondary process.
Most of the time, there is no process-private ressource,
so the close operation is just forbidden in a secondary process.
After adding proper check in the port close functions,
some redundant checks in the device remove functions are dropped.
Signed-off-by: Thomas Monjalon
---
drivers/net/af_xdp/rte_eth_af_xdp.c | 3 +++
drivers/net/ark/ark_ethdev.c| 3 +++
drivers/net/avp/avp_ethdev.c| 3 +++
drivers/net/bnxt/bnxt_ethdev.c | 3 +++
drivers/net/bnxt/bnxt_reps.c| 3 +++
drivers/net/cxgbe/cxgbe_ethdev.c| 3 +++
drivers/net/dpaa/dpaa_ethdev.c | 3 +++
drivers/net/dpaa2/dpaa2_ethdev.c| 3 +++
drivers/net/e1000/em_ethdev.c | 3 +++
drivers/net/e1000/igb_ethdev.c | 6 +
drivers/net/ena/ena_ethdev.c| 3 +++
drivers/net/enetc/enetc_ethdev.c| 3 +++
drivers/net/enic/enic_ethdev.c | 3 +++
drivers/net/fm10k/fm10k_ethdev.c| 9 ++-
drivers/net/hinic/hinic_pmd_ethdev.c| 3 +++
drivers/net/i40e/i40e_ethdev.c | 2 ++
drivers/net/i40e/i40e_ethdev_vf.c | 3 +++
drivers/net/iavf/iavf_ethdev.c | 3 +++
drivers/net/ice/ice_ethdev.c| 3 +++
drivers/net/igc/igc_ethdev.c| 6 ++---
drivers/net/ionic/ionic_ethdev.c| 2 ++
drivers/net/ipn3ke/ipn3ke_representor.c | 3 +++
drivers/net/ixgbe/ixgbe_ethdev.c| 4
drivers/net/kni/rte_eth_kni.c | 3 +++
drivers/net/liquidio/lio_ethdev.c | 3 +++
drivers/net/mlx4/mlx4.c | 2 ++
drivers/net/mvneta/mvneta_ethdev.c | 3 +++
drivers/net/mvpp2/mrvl_ethdev.c | 3 +++
drivers/net/netvsc/hn_ethdev.c | 2 ++
drivers/net/nfb/nfb_ethdev.c| 3 +++
drivers/net/nfp/nfp_net.c | 3 +++
drivers/net/octeontx/octeontx_ethdev.c | 2 ++
drivers/net/pfe/pfe_ethdev.c| 3 +++
drivers/net/sfc/sfc_ethdev.c| 32 -
drivers/net/szedata2/rte_eth_szedata2.c | 3 +++
drivers/net/thunderx/nicvf_ethdev.c | 7 +++---
drivers/net/vhost/rte_eth_vhost.c | 7 +++---
drivers/net/virtio/virtio_ethdev.c | 2 ++
drivers/net/vmxnet3/vmxnet3_ethdev.c| 2 ++
39 files changed, 125 insertions(+), 35 deletions(-)
diff --git a/drivers/net/af_xdp/rte_eth_af_xdp.c
b/drivers/net/af_xdp/rte_eth_af_xdp.c
index 60add9ead4..b289076e01 100644
--- a/drivers/net/af_xdp/rte_eth_af_xdp.c
+++ b/drivers/net/af_xdp/rte_eth_af_xdp.c
@@ -708,6 +708,9 @@ eth_dev_close(struct rte_eth_dev *dev)
struct pkt_rx_queue *rxq;
int i;
+ if (rte_eal_process_type() != RTE_PROC_PRIMARY)
+ return 0;
+
AF_XDP_LOG(INFO, "Closing AF_XDP ethdev on numa socket %u\n",
rte_socket_id());
diff --git a/drivers/net/ark/ark_ethdev.c b/drivers/net/ark/ark_ethdev.c
index 83dc4ecd2c..3e96445fdb 100644
--- a/drivers/net/ark/ark_ethdev.c
+++ b/drivers/net/ark/ark_ethdev.c
@@ -680,6 +680,9 @@ eth_ark_dev_close(struct rte_eth_dev *dev)
struct ark_adapter *ark = dev->data->dev_private;
uint16_t i;
+ if (rte_eal_process_type() != RTE_PROC_PRIMARY)
+ return 0;
+
if (ark->user_ext.dev_close)
ark->user_ext.dev_close(dev,
ark->user_data[dev->data->port_id]);
diff --git a/drivers/net/avp/avp_ethdev.c b/drivers/net/avp/avp_ethdev.c
index c730b7ab86..95fdb57451 100644
--- a/drivers/net/avp/avp_ethdev.c
+++ b/drivers/net/avp/avp_ethdev.c
@@ -2107,6 +2107,9 @@ avp_dev_close(struct rte_eth_dev *eth_dev)
struct avp_dev *avp = AVP_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
int ret;
+ if (rte_eal_process_type() != RTE_PROC_PRIMARY)
+ return 0;
+
rte_spinlock_lock(&avp->lock);
if (avp->flags & AVP_F_DETACHED) {
PMD_DRV_LOG(ERR, "Operation not supported during VM live
migration\n");
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index a77bab661d..d45347e8ca 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -1361,6 +1361,9 @@ static int bnxt_dev_close_op(struct rte_eth_dev *eth_dev)
{
struct bnxt *bp = eth_dev->data->dev_private;
+ if (rte_eal_process_type() != RTE_PROC_PRIMARY)
+ return 0;
+
/* cancel the recovery handler before remove dev */
rte_eal_alarm_cancel(bnxt_dev_reset_and_resume, (void *)bp);
rte_eal_alarm_cancel(bnxt_dev_recover, (void *)bp);
diff --git a/drivers/net/bnxt/bnxt_reps.c b/drivers/net/bnxt/bnxt_reps.c
index df8680c113..c419fe63b8 100644
--- a/drivers/net/bnxt/bnxt_reps.c
+++ b/drivers/ne
Re: [dpdk-dev] [PATCH] bus/pci: fix mapping of PCI resources
Tested-by: Ling, Wei Regards, Ling Wei > -Original Message- > From: dev On Behalf Of alvinx.zh...@intel.com > Sent: Monday, September 28, 2020 02:34 PM > To: david.march...@redhat.com; arybche...@solarflare.com > Cc: dev@dpdk.org; Zhang, AlvinX ; sta...@dpdk.org > Subject: [dpdk-dev] [PATCH] bus/pci: fix mapping of PCI resources >
Re: [dpdk-dev] [v3 PATCH] test_distributor: prevent memory leakages from the pool
On Fri, Sep 25, 2020 at 7:22 PM David Marchand
wrote:
> On Tue, Sep 8, 2020 at 12:22 PM Sarosh Arif
> wrote:
> >
> > rte_mempool_get_bulk is used to get bufs/many_bufs from the pool,
> > but at some locations when test fails the bufs/many_bufs are
> > not returned back to the pool.
> > Due to this, multiple executions of distributor_autotest gives the
> > following error message: Error getting mbufs from pool.
> > To resolve this issue rte_mempool_put_bulk is used whenever the test
> > fails and returns.
> >
> > Signed-off-by: Sarosh Arif
>
> It deserves a Fixes: line.
>
Fixes: c3eabff124e6 ("distributor: add unit tests")
Should I submit another version of this patch to add fixes?
>
> I can see a ack from Lukasz.
> David, review please?
>
>
> --
> David Marchand
>
>
[dpdk-dev] [PATCH v2] testpmd: add speed capability in device info
Called rte_eth_dev_info_get() in testpmd, to get device info
so that speed capabilities can be printed under "show device info"
Bugzilla ID: 496
Signed-off-by: Sarosh Arif
---
app/test-pmd/config.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 30bee3324..e2b3975a3 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -518,7 +518,9 @@ device_infos_display(const char *identifier)
struct rte_device *dev;
struct rte_devargs da;
portid_t port_id;
+ struct rte_eth_dev_info dev_info;
char devstr[128];
+ uint32_t speed_capa;
memset(&da, 0, sizeof(da));
if (!identifier)
@@ -569,6 +571,42 @@ device_infos_display(const char *identifier)
&mac_addr);
rte_eth_dev_get_name_by_port(port_id, name);
printf("\n\tDevice name: %s", name);
+ rte_eth_dev_info_get(port_id, &dev_info);
+ speed_capa = dev_info.speed_capa;
+
+ printf("\n\tDevice speed capability:");
+ if (speed_capa == ETH_LINK_SPEED_AUTONEG)
+ printf(" Autonegotiate (all speeds)");
+ if (speed_capa & ETH_LINK_SPEED_FIXED)
+ printf(" Disable autonegotiate (fixed
speed) ");
+ if (speed_capa & ETH_LINK_SPEED_10M_HD)
+ printf(" 10 Mbps half-duplex ");
+ if (speed_capa & ETH_LINK_SPEED_10M)
+ printf(" 10 Mbps full-duplex ");
+ if (speed_capa & ETH_LINK_SPEED_100M_HD)
+ printf(" 100 Mbps half-duplex ");
+ if (speed_capa & ETH_LINK_SPEED_100M)
+ printf(" 100 Mbps full-duplex ");
+ if (speed_capa & ETH_LINK_SPEED_1G)
+ printf(" 1 Gbps ");
+ if (speed_capa & ETH_LINK_SPEED_2_5G)
+ printf(" 2.5 Gbps ");
+ if (speed_capa & ETH_LINK_SPEED_5G)
+ printf(" 5 Gbps ");
+ if (speed_capa & ETH_LINK_SPEED_10G)
+ printf(" 10 Gbps ");
+ if (speed_capa & ETH_LINK_SPEED_20G)
+ printf(" 20 Gbps ");
+ if (speed_capa & ETH_LINK_SPEED_25G)
+ printf(" 25 Gbps ");
+ if (speed_capa & ETH_LINK_SPEED_50G)
+ printf(" 50 Gbps ");
+ if (speed_capa & ETH_LINK_SPEED_56G)
+ printf(" 56 Gbps ");
+ if (speed_capa & ETH_LINK_SPEED_100G)
+ printf(" 100 Gbps ");
+ if (speed_capa & ETH_LINK_SPEED_200G)
+ printf(" 200 Gbps ");
printf("\n");
}
}
--
2.25.1
[dpdk-dev] [Bug 539] [dpdk-20.11] distributor/test_multiple_ports: Failed to map pci BAR4 only in SLES15_SP1
https://bugs.dpdk.org/show_bug.cgi?id=539 lingwei (weix.l...@intel.com) changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #3 from lingwei (weix.l...@intel.com) --- Verified patchset http://patches.dpdk.org/patch/78968/ on baseline f5d6738c2ec10170b0e03eb9ff95544be0559641. Tested-by on sageville/SLES15-SP1 https://mails.dpdk.org/archives/dev/2020-September/183166.html -- You are receiving this mail because: You are the assignee for the bug.
Re: [dpdk-dev] [v3 PATCH] test_distributor: prevent memory leakages from the pool
On Mon, Sep 28, 2020 at 11:55 AM Sarosh Arif wrote:
> On Fri, Sep 25, 2020 at 7:22 PM David Marchand
> wrote:
>> It deserves a Fixes: line.
>
> Fixes: c3eabff124e6 ("distributor: add unit tests")
>
> Should I submit another version of this patch to add fixes?
I was waiting for a review from David H. and this Fixes line lgtm.
I will update when applying (with the other ut tests fixes from
Lukasz), no need for a new revision.
Thanks.
--
David Marchand
Re: [dpdk-dev] [PATCH] crypto/scheduler: rename slave to worker
> -Original Message- > From: Ruifeng Wang > Sent: Monday, 28 September, 2020 04:50 > To: Dybkowski, AdamX ; dev@dpdk.org; > Trahe, Fiona ; akhil.go...@nxp.com; Zhang, Roy > Fan > Cc: nd > Subject: RE: [dpdk-dev] [PATCH] crypto/scheduler: rename slave to worker > > > -Original Message- > > From: dev On Behalf Of Adam Dybkowski > > Sent: Wednesday, August 26, 2020 11:34 PM > > To: dev@dpdk.org; fiona.tr...@intel.com; akhil.go...@nxp.com; > > roy.fan.zh...@intel.com > > Cc: Adam Dybkowski > > Subject: [dpdk-dev] [PATCH] crypto/scheduler: rename slave to worker > > > > This patch replaces the usage of the word 'slave' with more > > appropriate word 'worker' in QAT PMD and Scheduler PMD as well as in > > their docs. Also the test app was modified to use the new wording. > > > > The Scheduler PMD's public API was modified according to the previous > > deprecation notice: > > rte_cryptodev_scheduler_slave_attach is now called > > rte_cryptodev_scheduler_worker_attach, > > rte_cryptodev_scheduler_slave_detach is > > rte_cryptodev_scheduler_worker_detach, > > rte_cryptodev_scheduler_slaves_get is > > rte_cryptodev_scheduler_workers_get. > > > > Also, the configuration value > > RTE_CRYPTODEV_SCHEDULER_MAX_NB_SLAVES > > was renamed to RTE_CRYPTODEV_SCHEDULER_MAX_NB_WORKERS. > > > > Signed-off-by: Adam Dybkowski > > --- > > app/test-crypto-perf/main.c | 2 +- > > app/test/test_cryptodev.c | 20 +- > > doc/guides/cryptodevs/qat.rst | 2 +- > > doc/guides/cryptodevs/scheduler.rst | 40 ++-- > > doc/guides/rel_notes/deprecation.rst | 2 +- > > .../scheduler/rte_cryptodev_scheduler.c | 114 +- > > .../scheduler/rte_cryptodev_scheduler.h | 35 ++- > > .../rte_cryptodev_scheduler_operations.h | 12 +- > > .../rte_pmd_crypto_scheduler_version.map | 6 +- > > drivers/crypto/scheduler/scheduler_failover.c | 83 +++ > > .../crypto/scheduler/scheduler_multicore.c| 54 ++--- > > .../scheduler/scheduler_pkt_size_distr.c | 142 ++-- > > drivers/crypto/scheduler/scheduler_pmd.c | 54 ++--- > > drivers/crypto/scheduler/scheduler_pmd_ops.c | 204 > > +- .../crypto/scheduler/scheduler_pmd_private.h | 12 +- > > .../crypto/scheduler/scheduler_roundrobin.c | 87 > > examples/l2fwd-crypto/main.c | 6 +- > > 17 files changed, 439 insertions(+), 436 deletions(-) > > > > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > > b/doc/guides/rel_notes/deprecation.rst > > index 345c38d5b..24d58060f 100644 > > --- a/doc/guides/rel_notes/deprecation.rst > > +++ b/doc/guides/rel_notes/deprecation.rst > > @@ -341,4 +341,4 @@ Deprecation Notices > > * dpdk-setup.sh: This old script relies on deprecated stuff, and especially > >``make``. Given environments are too much variables for such a > > simple script, > >it will be removed in DPDK 20.11. > > - Some useful parts may be converted into specific scripts. > > + Some useful parts may be converted into specific scripts. > > \ No newline at end of file > > This is not intended modification. > What should be deleted is section 'scheduler'. > And release note 20.11 needs update to indicate the API replacement. > > Thanks. > Ruifeng [Adam] OK, thanks for spotting this unintended modification. I'll send the next version together with release notes update later this week. Adam Dybkowski
Re: [dpdk-dev] [PATCH v2 1/5] lib/stack: fix inconsistent weak / strong cas
On Fri, Sep 25, 2020 at 7:44 PM Steven Lariau wrote: > > Fix cmpexchange usage of weak / strong. > The generated code is the same on x86 and ARM (there is no weak > cmpexchange), but the old usage was inconsistent. > For push and pop update size, weak is used because cmpexchange is inside > a loop. > For pop update root, strong is used even though cmpexchange is inside a > loop, because there may be a lot of operations to do in a loop iteration > (locate the new head). Is this patch backport material? Thanks. -- David Marchand
Re: [dpdk-dev] [PATCH] net/ring: advertise multi segment support.
On 9/28/2020 8:31 AM, Dumitru Ceara wrote: On 9/22/20 4:21 PM, Ferruh Yigit wrote: On 9/18/2020 11:36 AM, Dumitru Ceara wrote: Even though ring interfaces don't support any other TX/RX offloads they do support sending multi segment packets and this should be advertised in order to not break applications that use ring interfaces. Does ring PMD support sending multi segmented packets? Yes, sending multi segmented packets works fine with ring PMD. Define "works fine" :) All PMDs can put the first mbuf of the chained mbuf to the ring, in that case what is the difference between the ones supports 'DEV_TX_OFFLOAD_MULTI_SEGS' and the ones doesn't support? If the traffic is only from ring PMD to ring PMD, you won't recognize the difference between segmented or not-segmented mbufs, and it will look like segmented packets works fine. But if there is other PMDs involved in the forwarding, or if need to process the packets, will it still work fine? As far as I can see ring PMD doesn't know about the mbuf segments. Right, the PMD doesn't care about the mbuf segments but it implicitly supports sending multi segmented packets. From what I see it's actually the case for most of the PMDs, in the sense that most don't even check the DEV_TX_OFFLOAD_MULTI_SEGS flag and if the application sends multi segment packets they are just accepted. > As far as I can see, if the segmented packets sent, the ring PMD will put the first mbuf into the ring without doing anything specific to the next segments. If the 'DEV_TX_OFFLOAD_MULTI_SEGS' is supported I expect it should detect the segmented packets and put each chained mbuf into the separate field in the ring. However, the fact that the ring PMD doesn't advertise this implicit support forces applications that use ring PMD to have a special case for handling ring interfaces. If the ring PMD would advertise DEV_TX_OFFLOAD_MULTI_SEGS this would allow upper layers to be oblivious to the type of underlying interface. This is not handling the special case for the ring PMD, this is why he have the offload capability flag. Application should behave according capability flags, not per specific PMD. Is there any specific usecase you are trying to cover?
Re: [dpdk-dev] [PATCH V13 0/3] add FEC support
On 9/27/2020 8:08 AM, Min Hu (Connor) wrote: Hello, Are there any suggustions for this set patches ? 在 2020/9/25 16:39, Min Hu (Connor) 写道: This series add FEC support for ethdev. Min Hu (Connor) (3): ethdev: introduce FEC API net/hns3: support FEC app/testpmd: add FEC command app/test-pmd/cmdline.c | 223 +++ app/test-pmd/config.c | 91 app/test-pmd/testpmd.h | 2 + doc/guides/rel_notes/release_20_11.rst | 10 + drivers/net/hns3/hns3_cmd.h | 19 +- drivers/net/hns3/hns3_ethdev.c | 356 +++ drivers/net/hns3/hns3_ethdev.h | 1 + lib/librte_ethdev/rte_ethdev.c | 43 lib/librte_ethdev/rte_ethdev.h | 94 lib/librte_ethdev/rte_ethdev_driver.h | 80 +++ lib/librte_ethdev/rte_ethdev_version.map | 3 + 11 files changed, 921 insertions(+), 1 deletion(-) Hi Connor, Can you please make a new version addressing the minor issues Andrew highlighted and including his ack? Thanks, ferruh
Re: [dpdk-dev] [dpdk-stable] [PATCH] stack: fix possible uninitialized success variable
On Fri, Sep 25, 2020 at 7:02 AM wangyunjian wrote:
>
> From: Yunjian Wang
>
> This patch fixes an issue that uninitialized 'success'
> is used to be compared with '0'.
>
> Coverity issue: 337676
> Fixes: 3340202f5954 ("stack: add lock-free implementation")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Yunjian Wang
> ---
> lib/librte_stack/rte_stack_lf_generic.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/librte_stack/rte_stack_lf_generic.h
> b/lib/librte_stack/rte_stack_lf_generic.h
> index 3abbb5342..4850a05ee 100644
> --- a/lib/librte_stack/rte_stack_lf_generic.h
> +++ b/lib/librte_stack/rte_stack_lf_generic.h
> @@ -78,7 +78,7 @@ __rte_stack_lf_pop_elems(struct rte_stack_lf_list *list,
> struct rte_stack_lf_elem **last)
> {
> struct rte_stack_lf_head old_head;
> - int success;
> + int success = 0;
>
> /* Reserve num elements, if available */
> while (1) {
> --
> 2.23.0
>
Reviewed-by: David Marchand
--
David Marchand
Re: [dpdk-dev] [PATCH v6 1/6] drivers: add generic API to find PCI extended cap
On 9/28/2020 9:59 AM, David Marchand wrote:
On Sun, Sep 27, 2020 at 2:21 PM Jerin Jacob wrote:
On Fri, Sep 25, 2020 at 5:26 PM Manish Chopra wrote:
By adding generic API, this patch removes individual
functions/defines implemented by drivers to find extended
PCI capabilities.
Signed-off-by: Manish Chopra
Signed-off-by: Igor Russkikh
Reviewed-by: Gaetan Rivet
Reviewed-by: Jerin Jacob
@Thomas Monjalon @David Marchand @Ferruh Yigit
Othe patches in the qede series is depending on this patch, Let me
know, how we are planning to pull this patch? Is through main or
dpdk-next-net or dpdk-next-net-mrvl?
Just two small comments, that can be fixed by whoever applies it.
- The title does not reflect that we are adding an API to the pci bus.
My suggestion is: "bus/pci: query PCI extended capabilities"
- There is an unneeded empty line added to lib/librte_pci/rte_pci.h:
diff --git a/lib/librte_pci/rte_pci.h b/lib/librte_pci/rte_pci.h
index 1d89651ec8..f89c7dbbea 100644
--- a/lib/librte_pci/rte_pci.h
+++ b/lib/librte_pci/rte_pci.h
@@ -22,7 +22,6 @@ extern "C" {
#include
#include
-
/*
* Conventional PCI and PCI-X Mode 1 devices have 256 bytes of
* configuration space. PCI-X Mode 2 and PCIe devices have 4096 bytes of
The patch is reviewed by Gaëtan.
Either through next-net or next-net-mrvl is fine to me.
I'll leave the decision to Ferruh.
Since other patches in the set requires Jerin's review,
@Jerin can you get the patchset to dpdk-next-net-mrvl?
[dpdk-dev] [PATCH v8 02/10] usertools/dpdk-devbind: support python3 only
From: Louise Kilheeney
Changed script to explicitly use python3 only to avoid
maintaining python 2 and removed deprecation notice.
Signed-off-by: Louise Kilheeney
Reviewed-by: Bruce Richardson
---
usertools/dpdk-devbind.py | 22 --
1 file changed, 4 insertions(+), 18 deletions(-)
diff --git a/usertools/dpdk-devbind.py b/usertools/dpdk-devbind.py
index 094c2ffc8b..8278a748d4 100755
--- a/usertools/dpdk-devbind.py
+++ b/usertools/dpdk-devbind.py
@@ -1,9 +1,8 @@
-#! /usr/bin/env python
+#!/usr/bin/env python3
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2010-2014 Intel Corporation
#
-from __future__ import print_function
import sys
import os
import getopt
@@ -12,10 +11,6 @@
from os.path import exists, abspath, dirname, basename
from os.path import join as path_join
-if sys.version_info.major < 3:
-print("WARNING: Python 2 is deprecated for use in DPDK, and will not work
in future releases.", file=sys.stderr)
-print("Please use Python 3 instead", file=sys.stderr)
-
# The PCI base class for all devices
network_class = {'Class': '02', 'Vendor': None, 'Device': None,
'SVendor': None, 'SDevice': None}
@@ -154,14 +149,6 @@ def usage():
""" % locals()) # replace items from local variables
-
-# This is roughly compatible with check_output function in subprocess module
-# which is only available in python 2.7.
-def check_output(args, stderr=None):
-'''Run a command and capture its output'''
-return subprocess.Popen(args, stdout=subprocess.PIPE,
-stderr=stderr).communicate()[0]
-
# check if a specific kernel module is loaded
def module_is_loaded(module):
global loaded_modules
@@ -218,8 +205,7 @@ def get_pci_device_details(dev_id, probe_lspci):
device = {}
if probe_lspci:
-extra_info = check_output(["lspci", "-vmmks", dev_id]).splitlines()
-
+extra_info = subprocess.check_output(["lspci", "-vmmks",
dev_id]).splitlines()
# parse lspci details
for line in extra_info:
if len(line) == 0:
@@ -255,7 +241,7 @@ def get_device_details(devices_type):
# first loop through and read details for all devices
# request machine readable format, with numeric IDs and String
dev = {}
-dev_lines = check_output(["lspci", "-Dvmmnnk"]).splitlines()
+dev_lines = subprocess.check_output(["lspci", "-Dvmmnnk"]).splitlines()
for dev_line in dev_lines:
if len(dev_line) == 0:
if device_type_match(dev, devices_type):
@@ -283,7 +269,7 @@ def get_device_details(devices_type):
# check what is the interface if any for an ssh connection if
# any to this host, so we can mark it later.
ssh_if = []
-route = check_output(["ip", "-o", "route"])
+route = subprocess.check_output(["ip", "-o", "route"])
# filter out all lines for 169.254 routes
route = "\n".join(filter(lambda ln: not ln.startswith("169.254"),
route.decode().splitlines()))
--
2.25.1
[dpdk-dev] [PATCH v8 01/10] usertools/dpdk-telemetry-client: support python3 only
From: Louise Kilheeney
Changed script to explicitly use python3 only to avoid
maintaining python 2 and removed deprecation notice.
Cc: Kevin Laatz
Signed-off-by: Louise Kilheeney
Signed-off-by: Kevin Laatz
Acked-by: Bruce Richardson
---
v8: removed cleanup not related to python3 only support
---
usertools/dpdk-telemetry-client.py | 18 +++---
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/usertools/dpdk-telemetry-client.py
b/usertools/dpdk-telemetry-client.py
index 98d28fa89b..d8e439027c 100755
--- a/usertools/dpdk-telemetry-client.py
+++ b/usertools/dpdk-telemetry-client.py
@@ -1,10 +1,7 @@
-#! /usr/bin/env python
+#! /usr/bin/env python3
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2018 Intel Corporation
-from __future__ import print_function
-from __future__ import unicode_literals
-
import socket
import os
import sys
@@ -18,15 +15,6 @@
GLOBAL_METRICS_REQ =
"{\"action\":0,\"command\":\"global_stat_values\",\"data\":null}"
DEFAULT_FP = "/var/run/dpdk/default_client"
-try:
-raw_input # Python 2
-except NameError:
-raw_input = input # Python 3
-
-if sys.version_info.major < 3:
-print("WARNING: Python 2 is deprecated for use in DPDK, and will not work
in future releases.", file=sys.stderr)
-print("Please use Python 3 instead", file=sys.stderr)
-
class Socket:
def __init__(self):
@@ -86,7 +74,7 @@ def requestMetrics(self): # Requests metrics for given client
def repeatedlyRequestMetrics(self, sleep_time): # Recursively requests
metrics for given client
print("\nPlease enter the number of times you'd like to continuously
request Metrics:")
-n_requests = int(raw_input("\n:"))
+n_requests = int(input("\n:"))
print("\033[F") #Removes the user input from screen, cleans it up
print("\033[K")
for i in range(n_requests):
@@ -107,7 +95,7 @@ def interactiveMenu(self, sleep_time): # Creates Interactive
menu within the scr
print("[4] Unregister client")
try:
-self.choice = int(raw_input("\n:"))
+self.choice = int(input("\n:"))
print("\033[F") #Removes the user input for screen, cleans it
up
print("\033[K")
if self.choice == 1:
--
2.25.1
[dpdk-dev] [PATCH v8 00/10] adding support for python 3 only
This patch set converts all python scripts in the project to use python3 only and removes all deprecation notices associated with these changes. This is due to python2 being EOL in January 2020. --- v6: - rebased, removing conflict with make removal patchset. - added changes to buildtools/map_to_win.py v7: - typo in email Cc'ing David Marchand - added maintainers for buildtools patch v8: - removed unrelated cleanup - replaced integer cast with integer division operator Kevin Laatz (3): app/test-cmdline: support python3 only app/test: support python3 only buildtools: support python3 only Louise Kilheeney (7): usertools/dpdk-telemetry-client: support python3 only usertools/dpdk-devbind: support python3 only usertools/dpdk-pmdinfo: support python3 only usertools/cpu_layout: support python3 only devtools: support python3 only config/arm: support python3 only app/test-bbdev: support python3 only app/test-bbdev/test-bbdev.py | 7 +-- app/test-cmdline/cmdline_test.py | 9 ++--- app/test-cmdline/cmdline_test_data.py | 1 + app/test/autotest.py | 7 +-- app/test/autotest_data.py | 1 + app/test/autotest_runner.py | 21 - app/test/autotest_test_funcs.py | 1 + buildtools/map_to_win.py | 3 +-- config/arm/armv8_machine.py | 2 +- devtools/update_version_map_abi.py| 7 +-- usertools/cpu_layout.py | 13 ++--- usertools/dpdk-devbind.py | 22 -- usertools/dpdk-pmdinfo.py | 7 +-- usertools/dpdk-telemetry-client.py| 18 +++--- 14 files changed, 28 insertions(+), 91 deletions(-) -- 2.25.1
[dpdk-dev] [PATCH v8 04/10] usertools/cpu_layout: support python3 only
From: Louise Kilheeney
Changed script to explicitly use python3 only to avoid
maintaining python 2 and removed deprecation notice.
Signed-off-by: Louise Kilheeney
Reviewed-by: Bruce Richardson
---
usertools/cpu_layout.py | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/usertools/cpu_layout.py b/usertools/cpu_layout.py
index 5423c7965f..89a48cec46 100755
--- a/usertools/cpu_layout.py
+++ b/usertools/cpu_layout.py
@@ -1,18 +1,9 @@
-#!/usr/bin/env python
+#!/usr/bin/env python3
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2010-2014 Intel Corporation
# Copyright(c) 2017 Cavium, Inc. All rights reserved.
-from __future__ import print_function
import sys
-try:
-xrange # Python 2
-except NameError:
-xrange = range # Python 3
-
-if sys.version_info.major < 3:
-print("WARNING: Python 2 is deprecated for use in DPDK, and will not work
in future releases.", file=sys.stderr)
-print("Please use Python 3 instead", file=sys.stderr)
sockets = []
cores = []
@@ -21,7 +12,7 @@
fd = open("{}/kernel_max".format(base_path))
max_cpus = int(fd.read())
fd.close()
-for cpu in xrange(max_cpus + 1):
+for cpu in range(max_cpus + 1):
try:
fd = open("{}/cpu{}/topology/core_id".format(base_path, cpu))
except IOError:
--
2.25.1
[dpdk-dev] [PATCH v8 05/10] app/test-cmdline: support python3 only
Changed script to explicitly use python3 only to avoid
maintaining python 2 and removed deprecation notice.
Cc: Olivier Matz
Signed-off-by: Louise Kilheeney
Signed-off-by: Kevin Laatz
Reviewed-by: Bruce Richardson
---
v5:
- fixed python3 issue causing script to fail. Divisions without the
typecast lead to a floating point result, which was messing up the
loop.
v6:
- Removed changes to mk/rte.sdktest.mk since it no longer exists.
v8:
- Replaced integer cast with integer division operator.
---
app/test-cmdline/cmdline_test.py | 9 ++---
app/test-cmdline/cmdline_test_data.py | 1 +
2 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/app/test-cmdline/cmdline_test.py b/app/test-cmdline/cmdline_test.py
index 954428e2bf..f3377313e9 100755
--- a/app/test-cmdline/cmdline_test.py
+++ b/app/test-cmdline/cmdline_test.py
@@ -1,9 +1,8 @@
-#!/usr/bin/env python
+#!/usr/bin/env python3
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2010-2014 Intel Corporation
# Script that runs cmdline_test app and feeds keystrokes into it.
-from __future__ import print_function
import cmdline_test_data
import os
import pexpect
@@ -19,10 +18,6 @@ def runTest(child, test):
return 0
child.expect(test["Result"], 1)
-if sys.version_info.major < 3:
-print("WARNING: Python 2 is deprecated for use in DPDK, and will not work
in future releases.", file=sys.stderr)
-print("Please use Python 3 instead", file=sys.stderr)
-
#
# history test is a special case
#
@@ -43,7 +38,7 @@ def runHistoryTest(child):
i = 0
# fill the history with numbers
-while i < history_size / 10:
+while i < history_size // 10:
# add 1 to prevent from parsing as octals
child.send("1" + str(i).zfill(8) + cmdline_test_data.ENTER)
# the app will simply print out the number
diff --git a/app/test-cmdline/cmdline_test_data.py
b/app/test-cmdline/cmdline_test_data.py
index 114d2cb6a0..2d9b3262a6 100644
--- a/app/test-cmdline/cmdline_test_data.py
+++ b/app/test-cmdline/cmdline_test_data.py
@@ -1,3 +1,4 @@
+#!/usr/bin/env python3
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2010-2014 Intel Corporation
--
2.25.1
[dpdk-dev] [PATCH v8 03/10] usertools/dpdk-pmdinfo: support python3 only
From: Louise Kilheeney
Changed script to explicitly use python3 only to avoid
maintaining python 2 and removed deprecation notice.
Cc: Neil Horman
Signed-off-by: Louise Kilheeney
Reviewed-by: Bruce Richardson
Acked-by: Neil Horman
---
usertools/dpdk-pmdinfo.py | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/usertools/dpdk-pmdinfo.py b/usertools/dpdk-pmdinfo.py
index f9ed755176..1661982791 100755
--- a/usertools/dpdk-pmdinfo.py
+++ b/usertools/dpdk-pmdinfo.py
@@ -1,4 +1,4 @@
-#!/usr/bin/env python
+#!/usr/bin/env python3
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2016 Neil Horman
@@ -7,8 +7,6 @@
# Utility to dump PMD_INFO_STRING support from an object file
#
# -
-from __future__ import print_function
-from __future__ import unicode_literals
import json
import io
import os
@@ -28,9 +26,6 @@
pcidb = None
# ===
-if sys.version_info.major < 3:
-print("WARNING: Python 2 is deprecated for use in DPDK, and will not
work in future releases.", file=sys.stderr)
-print("Please use Python 3 instead", file=sys.stderr)
class Vendor:
"""
--
2.25.1
[dpdk-dev] [PATCH v8 07/10] devtools: support python3 only
From: Louise Kilheeney
Changed script to explicitly use python3 only to avoid
maintaining python 2 and removed deprecation notice.
Cc: Neil Horman
Cc: Ray Kinsella
Signed-off-by: Louise Kilheeney
Acked-by: Ray Kinsella
Acked-by: Neil Horman
---
devtools/update_version_map_abi.py | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/devtools/update_version_map_abi.py
b/devtools/update_version_map_abi.py
index 10c3bc8098..3536a54b44 100755
--- a/devtools/update_version_map_abi.py
+++ b/devtools/update_version_map_abi.py
@@ -1,4 +1,4 @@
-#!/usr/bin/env python
+#!/usr/bin/env python3
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2019 Intel Corporation
@@ -9,7 +9,6 @@
from the devtools/update-abi.sh utility.
"""
-from __future__ import print_function
import argparse
import sys
import re
@@ -160,10 +159,6 @@ def __generate_internal_abi(f_out, lines):
print("};", file=f_out)
def __main():
-if sys.version_info.major < 3:
-print("WARNING: Python 2 is deprecated for use in DPDK, and will not
work in future releases.", file=sys.stderr)
-print("Please use Python 3 instead", file=sys.stderr)
-
arg_parser = argparse.ArgumentParser(
description='Merge versions in linker version script.')
--
2.25.1
[dpdk-dev] [PATCH v8 06/10] app/test: support python3 only
Changed script to explicitly use python3 only to avoid
maintaining python 2 and removed deprecation notice.
Signed-off-by: Louise Kilheeney
Signed-off-by: Kevin Laatz
---
v6:
- Removed changes to mk/rte.sdktest.mk since the file no longer exists
---
app/test/autotest.py| 7 +--
app/test/autotest_data.py | 1 +
app/test/autotest_runner.py | 21 -
app/test/autotest_test_funcs.py | 1 +
4 files changed, 11 insertions(+), 19 deletions(-)
diff --git a/app/test/autotest.py b/app/test/autotest.py
index cf7584ccd7..9eef1efbe5 100644
--- a/app/test/autotest.py
+++ b/app/test/autotest.py
@@ -1,9 +1,8 @@
-#!/usr/bin/env python
+#!/usr/bin/env python3
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2010-2014 Intel Corporation
# Script that uses either test app or qemu controlled by python-pexpect
-from __future__ import print_function
import autotest_data
import autotest_runner
import sys
@@ -17,10 +16,6 @@ def usage():
usage()
sys.exit(1)
-if sys.version_info.major < 3:
-print("WARNING: Python 2 is deprecated for use in DPDK, and will not work
in future releases.", file=sys.stderr)
-print("Please use Python 3 instead", file=sys.stderr)
-
target = sys.argv[2]
test_whitelist = None
diff --git a/app/test/autotest_data.py b/app/test/autotest_data.py
index 4b7da45e09..097638941f 100644
--- a/app/test/autotest_data.py
+++ b/app/test/autotest_data.py
@@ -1,3 +1,4 @@
+#!/usr/bin/env python3
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2010-2014 Intel Corporation
diff --git a/app/test/autotest_runner.py b/app/test/autotest_runner.py
index 95e74c760d..998fe57a55 100644
--- a/app/test/autotest_runner.py
+++ b/app/test/autotest_runner.py
@@ -1,10 +1,10 @@
+#!/usr/bin/env python3
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2010-2014 Intel Corporation
# The main logic behind running autotests in parallel
-from __future__ import print_function
-import StringIO
+import io
import csv
from multiprocessing import Pool, Queue
import pexpect
@@ -50,11 +50,7 @@ def first_cpu_on_node(node_nr):
map(os.path.basename, cpu_path)
)
)
-# for compatibility between python 3 and 2 we need to make interable out
-# of filter return as it returns list in python 2 and a generator in 3
-m = next(iter(cpu_name))
-return int(m.group(1))
-
+return int(next(cpu_name).group(1))
pool_child = None # per-process child
@@ -78,7 +74,7 @@ def pool_init(queue, result_queue):
cmdline = "%s %s" % (cmdline, prefix_cmdline)
# prepare logging of init
-startuplog = StringIO.StringIO()
+startuplog = io.StringIO()
# run test app
try:
@@ -86,8 +82,7 @@ def pool_init(queue, result_queue):
print("\n%s %s\n" % ("=" * 20, prefix), file=startuplog)
print("\ncmdline=%s" % cmdline, file=startuplog)
-pool_child = pexpect.spawn(cmdline, logfile=startuplog)
-
+pool_child = pexpect.spawn(cmdline, logfile=startuplog,
encoding='utf-8')
# wait for target to boot
if not wait_prompt(pool_child):
pool_child.close()
@@ -138,7 +133,7 @@ def run_test(target, test):
# create log buffer for each test
# in multiprocessing environment, the logging would be
# interleaved and will create a mess, hence the buffering
-logfile = StringIO.StringIO()
+logfile = io.StringIO()
pool_child.logfile = logfile
# make a note when the test started
@@ -210,9 +205,9 @@ def __init__(self, cmdline, target, blacklist, whitelist,
n_processes):
# parse the binary for available test commands
binary = cmdline.split()[0]
stripped = 'not stripped' not in \
- subprocess.check_output(['file', binary])
+ subprocess.check_output(['file', binary]).decode()
if not stripped:
-symbols = subprocess.check_output(['nm', binary]).decode('utf-8')
+symbols = subprocess.check_output(['nm', binary]).decode()
self.avail_cmds = re.findall('test_register_(\w+)', symbols)
else:
self.avail_cmds = None
diff --git a/app/test/autotest_test_funcs.py b/app/test/autotest_test_funcs.py
index 26688b7132..775dfd1dc5 100644
--- a/app/test/autotest_test_funcs.py
+++ b/app/test/autotest_test_funcs.py
@@ -1,3 +1,4 @@
+#!/usr/bin/env python3
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2010-2014 Intel Corporation
--
2.25.1
[dpdk-dev] [PATCH v8 09/10] app/test-bbdev: support python3 only
From: Louise Kilheeney
Changed script to explicitly use python3 only to avoid
maintaining python 2 and removed deprecation notice.
Cc: Nicolas Chautru
Signed-off-by: Louise Kilheeney
---
app/test-bbdev/test-bbdev.py | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/app/test-bbdev/test-bbdev.py b/app/test-bbdev/test-bbdev.py
index 5ae2dc6c49..7d67dbe30a 100755
--- a/app/test-bbdev/test-bbdev.py
+++ b/app/test-bbdev/test-bbdev.py
@@ -1,9 +1,8 @@
-#!/usr/bin/env python
+#!/usr/bin/env python3
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017 Intel Corporation
-from __future__ import print_function
import sys
import os
import argparse
@@ -16,10 +15,6 @@ def kill(process):
print("ERROR: Test app timed out")
process.kill()
-if sys.version_info.major < 3:
-print("WARNING: Python 2 is deprecated for use in DPDK, and will not work
in future releases.", file=sys.stderr)
-print("Please use Python 3 instead", file=sys.stderr)
-
if "RTE_SDK" in os.environ:
dpdk_path = os.environ["RTE_SDK"]
else:
--
2.25.1
[dpdk-dev] [PATCH v8 08/10] config/arm: support python3 only
From: Louise Kilheeney Changed script to explicitly use python3 only to avoid maintaining python 2. Cc: Thomas Monjalon Signed-off-by: Louise Kilheeney --- config/arm/armv8_machine.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/config/arm/armv8_machine.py b/config/arm/armv8_machine.py index 404866d2f8..1f689d9a83 100755 --- a/config/arm/armv8_machine.py +++ b/config/arm/armv8_machine.py @@ -1,4 +1,4 @@ -#!/usr/bin/python +#!/usr/bin/env python3 # SPDX-License-Identifier: BSD-3-Clause # Copyright(c) 2017 Cavium, Inc -- 2.25.1
[dpdk-dev] [PATCH v8 10/10] buildtools: support python3 only
Changed script to explicitly use python3 only to avoid maintaining python 2 and removed deprecation notice. Cc: Dmitry Kozlyuk Cc: Narcisa Ana Maria Vasile Cc: Dmitry Malloy Cc: Pallavi Kadam Signed-off-by: Kevin Laatz --- v7: - Cc Maintainers --- buildtools/map_to_win.py | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/buildtools/map_to_win.py b/buildtools/map_to_win.py index 2990b58634..2a6cb88605 100644 --- a/buildtools/map_to_win.py +++ b/buildtools/map_to_win.py @@ -1,8 +1,7 @@ -#!/usr/bin/env python +#!/usr/bin/env python3 # SPDX-License-Identifier: BSD-3-Clause # Copyright(c) 2019 Intel Corporation -from __future__ import print_function import sys from os.path import dirname, basename, join, exists -- 2.25.1
[dpdk-dev] [PATCH v2] net/dpaa2: release port upon close
From: Sachin Saxena
With removal of old close behavior, the private
port resources must be released in the .dev_close callback.
Freeing of port private resources is moved from
the ".remove(device)" to the ".dev_close(port)" operation
Signed-off-by: Sachin Saxena
---
drivers/net/dpaa2/dpaa2_ethdev.c | 83
1 file changed, 32 insertions(+), 51 deletions(-)
diff --git a/drivers/net/dpaa2/dpaa2_ethdev.c b/drivers/net/dpaa2/dpaa2_ethdev.c
index c81e75d53..ba99a524f 100644
--- a/drivers/net/dpaa2/dpaa2_ethdev.c
+++ b/drivers/net/dpaa2/dpaa2_ethdev.c
@@ -99,7 +99,6 @@ static const enum rte_filter_op dpaa2_supported_filter_ops[]
= {
};
static struct rte_dpaa2_driver rte_dpaa2_pmd;
-static int dpaa2_dev_uninit(struct rte_eth_dev *eth_dev);
static int dpaa2_dev_link_update(struct rte_eth_dev *dev,
int wait_to_complete);
static int dpaa2_dev_set_link_up(struct rte_eth_dev *dev);
@@ -1241,7 +1240,7 @@ dpaa2_dev_close(struct rte_eth_dev *dev)
{
struct dpaa2_dev_priv *priv = dev->data->dev_private;
struct fsl_mc_io *dpni = (struct fsl_mc_io *)dev->process_private;
- int ret;
+ int i, ret;
struct rte_eth_link link;
PMD_INIT_FUNC_TRACE();
@@ -1249,8 +1248,12 @@ dpaa2_dev_close(struct rte_eth_dev *dev)
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
return 0;
- dpaa2_flow_clean(dev);
+ if (!dpni) {
+ DPAA2_PMD_WARN("Already closed or not started");
+ return -1;
+ }
+ dpaa2_flow_clean(dev);
/* Clean the device first */
ret = dpni_reset(dpni, CMD_PRI_LOW, priv->token);
if (ret) {
@@ -1261,6 +1264,27 @@ dpaa2_dev_close(struct rte_eth_dev *dev)
memset(&link, 0, sizeof(link));
rte_eth_linkstatus_set(dev, &link);
+ /* Free private queues memory */
+ dpaa2_free_rx_tx_queues(dev);
+ /* Close the device at underlying layer*/
+ ret = dpni_close(dpni, CMD_PRI_LOW, priv->token);
+ if (ret) {
+ DPAA2_PMD_ERR("Failure closing dpni device with err code %d",
+ ret);
+ }
+
+ /* Free the allocated memory for ethernet private data and dpni*/
+ priv->hw = NULL;
+ dev->process_private = NULL;
+ rte_free(dpni);
+
+ for (i = 0; i < MAX_TCS; i++)
+ rte_free((void *)(size_t)priv->extract.tc_extract_param[i]);
+
+ if (priv->extract.qos_extract_param)
+ rte_free((void *)(size_t)priv->extract.qos_extract_param);
+
+ DPAA2_PMD_INFO("%s: netdev deleted", dev->data->name);
return 0;
}
@@ -2712,52 +2736,9 @@ dpaa2_dev_init(struct rte_eth_dev *eth_dev)
RTE_LOG(INFO, PMD, "%s: netdev created\n", eth_dev->data->name);
return 0;
init_err:
- dpaa2_dev_uninit(eth_dev);
- return ret;
-}
-
-static int
-dpaa2_dev_uninit(struct rte_eth_dev *eth_dev)
-{
- struct dpaa2_dev_priv *priv = eth_dev->data->dev_private;
- struct fsl_mc_io *dpni = (struct fsl_mc_io *)eth_dev->process_private;
- int i, ret;
-
- PMD_INIT_FUNC_TRACE();
-
- if (rte_eal_process_type() != RTE_PROC_PRIMARY)
- return 0;
-
- if (!dpni) {
- DPAA2_PMD_WARN("Already closed or not started");
- return -1;
- }
-
dpaa2_dev_close(eth_dev);
- dpaa2_free_rx_tx_queues(eth_dev);
-
- /* Close the device at underlying layer*/
- ret = dpni_close(dpni, CMD_PRI_LOW, priv->token);
- if (ret) {
- DPAA2_PMD_ERR(
-"Failure closing dpni device with err code %d",
-ret);
- }
-
- /* Free the allocated memory for ethernet private data and dpni*/
- priv->hw = NULL;
- eth_dev->process_private = NULL;
- rte_free(dpni);
-
- for (i = 0; i < MAX_TCS; i++)
- rte_free((void *)(size_t)priv->extract.tc_extract_param[i]);
-
- if (priv->extract.qos_extract_param)
- rte_free((void *)(size_t)priv->extract.qos_extract_param);
-
- DPAA2_PMD_INFO("%s: netdev deleted", eth_dev->data->name);
- return 0;
+ return ret;
}
static int
@@ -2826,13 +2807,13 @@ static int
rte_dpaa2_remove(struct rte_dpaa2_device *dpaa2_dev)
{
struct rte_eth_dev *eth_dev;
+ int ret;
eth_dev = dpaa2_dev->eth_dev;
- dpaa2_dev_uninit(eth_dev);
-
- rte_eth_dev_release_port(eth_dev);
+ dpaa2_dev_close(eth_dev);
+ ret = rte_eth_dev_release_port(eth_dev);
- return 0;
+ return ret;
}
static struct rte_dpaa2_driver rte_dpaa2_pmd = {
--
2.28.0
Re: [dpdk-dev] [PATCH] vhost: fix external backends readiness
> -Original Message-
> From: Maxime Coquelin
> Sent: Wednesday, September 23, 2020 5:49 PM
> To: dev@dpdk.org; Xia, Chenbo ; ma...@mellanox.com;
> Zawadzki, Tomasz ; Liu, Changpeng
>
> Cc: Maxime Coquelin
> Subject: [PATCH] vhost: fix external backends readiness
>
> Commit d0fcc38f5fa4 ("vhost: improve device readiness notifications")
> makes the assumption that every Virtio devices are considered
> ready for preocessing as soon as first queue pair is configured
> and enabled.
>
> While this is true for Virtio-net, it isn't for Virtio-scsi
> and Virtio-blk.
>
> This patch fixes this by only making this assumption for
> the builtin Virtio-net backend, and restores back to previous
> behaviour for other backends.
>
> Fixes: d0fcc38f5fa4 ("vhost: improve device readiness notifications")
>
> Reported-by: Changpeng Liu
> Signed-off-by: Maxime Coquelin
> Signed-off-by: Changpeng Liu
> ---
> lib/librte_vhost/vhost_user.c | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
> index 501218e192..b00e1f91dc 100644
> --- a/lib/librte_vhost/vhost_user.c
> +++ b/lib/librte_vhost/vhost_user.c
> @@ -1343,21 +1343,28 @@ vq_is_ready(struct virtio_net *dev, struct
> vhost_virtqueue *vq)
> vq->enabled;
> }
>
> -#define VIRTIO_DEV_NUM_VQS_TO_BE_READY 2u
> +#define VIRTIO_BUILTIN_NUM_VQS_TO_BE_READY 2u
>
> static int
> virtio_is_ready(struct virtio_net *dev)
> {
> struct vhost_virtqueue *vq;
> - uint32_t i;
> + uint32_t i, nr_vring = dev->nr_vring;
>
> if (dev->flags & VIRTIO_DEV_READY)
> return 1;
>
> - if (dev->nr_vring < VIRTIO_DEV_NUM_VQS_TO_BE_READY)
> + if (!dev->nr_vring)
> return 0;
>
> - for (i = 0; i < VIRTIO_DEV_NUM_VQS_TO_BE_READY; i++) {
> + if (dev->flags & VIRTIO_DEV_BUILTIN_VIRTIO_NET) {
> + nr_vring = VIRTIO_BUILTIN_NUM_VQS_TO_BE_READY;
> +
> + if (dev->nr_vring < nr_vring)
> + return 0;
> + }
> +
> + for (i = 0; i < nr_vring; i++) {
> vq = dev->virtqueue[i];
>
> if (!vq_is_ready(dev, vq))
> --
> 2.26.2
Reviewed-by: Chenbo Xia
[dpdk-dev] [PATCH 2/6] vhost/crypto: fix incorrect descriptor deduction
From: Fan Zhang
This patch fixes the incorrect descriptor deduction for vhost crypto.
CVE-2020-14378
Fixes: 16d2e718b8ce ("vhost/crypto: fix possible out of bound access")
Cc: sta...@dpdk.org
Signed-off-by: Fan Zhang
Acked-by: Chenbo Xia
---
lib/librte_vhost/vhost_crypto.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/librte_vhost/vhost_crypto.c b/lib/librte_vhost/vhost_crypto.c
index 0f9df4059d..86747dd5f3 100644
--- a/lib/librte_vhost/vhost_crypto.c
+++ b/lib/librte_vhost/vhost_crypto.c
@@ -530,13 +530,14 @@ move_desc(struct vring_desc *head, struct vring_desc
**cur_desc,
int left = size - desc->len;
while ((desc->flags & VRING_DESC_F_NEXT) && left > 0) {
- (*nb_descs)--;
if (unlikely(*nb_descs == 0 || desc->next >= vq_size))
return -1;
desc = &head[desc->next];
rte_prefetch0(&head[desc->next]);
left -= desc->len;
+ if (left > 0)
+ (*nb_descs)--;
}
if (unlikely(left > 0))
--
2.26.2
[dpdk-dev] [PATCH 1/6] vhost/crypto: fix pool allocation
From: Fan Zhang
This patch fixes the missing iv space allocation in crypto
operation mempool.
Fixes: 709521f4c2cd ("examples/vhost_crypto: support multi-core")
Cc: sta...@dpdk.org
Signed-off-by: Fan Zhang
Acked-by: Chenbo Xia
---
examples/vhost_crypto/main.c| 2 +-
lib/librte_vhost/rte_vhost_crypto.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/examples/vhost_crypto/main.c b/examples/vhost_crypto/main.c
index 1d7ba94196..11b022e813 100644
--- a/examples/vhost_crypto/main.c
+++ b/examples/vhost_crypto/main.c
@@ -544,7 +544,7 @@ main(int argc, char *argv[])
snprintf(name, 127, "COPPOOL_%u", lo->lcore_id);
info->cop_pool = rte_crypto_op_pool_create(name,
RTE_CRYPTO_OP_TYPE_SYMMETRIC, NB_MEMPOOL_OBJS,
- NB_CACHE_OBJS, 0,
+ NB_CACHE_OBJS, VHOST_CRYPTO_MAX_IV_LEN,
rte_lcore_to_socket_id(lo->lcore_id));
if (!info->cop_pool) {
diff --git a/lib/librte_vhost/rte_vhost_crypto.h
b/lib/librte_vhost/rte_vhost_crypto.h
index d29871c7ea..866a592a5d 100644
--- a/lib/librte_vhost/rte_vhost_crypto.h
+++ b/lib/librte_vhost/rte_vhost_crypto.h
@@ -10,6 +10,7 @@
#define VHOST_CRYPTO_SESSION_MAP_ENTRIES (1024) /**< Max nb sessions */
/** max nb virtual queues in a burst for finalizing*/
#define VIRTIO_CRYPTO_MAX_NUM_BURST_VQS(64)
+#define VHOST_CRYPTO_MAX_IV_LEN(32)
enum rte_vhost_crypto_zero_copy {
RTE_VHOST_CRYPTO_ZERO_COPY_DISABLE = 0,
--
2.26.2
[dpdk-dev] [PATCH 3/6] vhost/crypto: fix missed request check for copy mode
From: Fan Zhang
This patch fixes the missed request check to vhost crypto
copy mode.
CVE-2020-14376
CVE-2020-14377
Fixes: 3bb595ecd682 ("vhost/crypto: add request handler")
Cc: sta...@dpdk.org
Signed-off-by: Fan Zhang
Acked-by: Chenbo Xia
---
lib/librte_vhost/vhost_crypto.c | 68 +++--
1 file changed, 47 insertions(+), 21 deletions(-)
diff --git a/lib/librte_vhost/vhost_crypto.c b/lib/librte_vhost/vhost_crypto.c
index 86747dd5f3..494f49084b 100644
--- a/lib/librte_vhost/vhost_crypto.c
+++ b/lib/librte_vhost/vhost_crypto.c
@@ -756,7 +756,7 @@ prepare_write_back_data(struct vhost_crypto_data_req
*vc_req,
}
wb_data->dst = dst;
- wb_data->len = desc->len - offset;
+ wb_data->len = RTE_MIN(desc->len - offset, write_back_len);
write_back_len -= wb_data->len;
src += offset + wb_data->len;
offset = 0;
@@ -840,6 +840,17 @@ prepare_write_back_data(struct vhost_crypto_data_req
*vc_req,
return NULL;
}
+static __rte_always_inline uint8_t
+vhost_crypto_check_cipher_request(struct virtio_crypto_cipher_data_req *req)
+{
+ if (likely((req->para.iv_len <= VHOST_CRYPTO_MAX_IV_LEN) &&
+ (req->para.src_data_len <= RTE_MBUF_DEFAULT_BUF_SIZE) &&
+ (req->para.dst_data_len >= req->para.src_data_len) &&
+ (req->para.dst_data_len <= RTE_MBUF_DEFAULT_BUF_SIZE)))
+ return VIRTIO_CRYPTO_OK;
+ return VIRTIO_CRYPTO_BADMSG;
+}
+
static uint8_t
prepare_sym_cipher_op(struct vhost_crypto *vcrypto, struct rte_crypto_op *op,
struct vhost_crypto_data_req *vc_req,
@@ -851,7 +862,10 @@ prepare_sym_cipher_op(struct vhost_crypto *vcrypto, struct
rte_crypto_op *op,
struct vhost_crypto_writeback_data *ewb = NULL;
struct rte_mbuf *m_src = op->sym->m_src, *m_dst = op->sym->m_dst;
uint8_t *iv_data = rte_crypto_op_ctod_offset(op, uint8_t *, IV_OFFSET);
- uint8_t ret = 0;
+ uint8_t ret = vhost_crypto_check_cipher_request(cipher);
+
+ if (unlikely(ret != VIRTIO_CRYPTO_OK))
+ goto error_exit;
/* prepare */
/* iv */
@@ -861,10 +875,9 @@ prepare_sym_cipher_op(struct vhost_crypto *vcrypto, struct
rte_crypto_op *op,
goto error_exit;
}
- m_src->data_len = cipher->para.src_data_len;
-
switch (vcrypto->option) {
case RTE_VHOST_CRYPTO_ZERO_COPY_ENABLE:
+ m_src->data_len = cipher->para.src_data_len;
m_src->buf_iova = gpa_to_hpa(vcrypto->dev, desc->addr,
cipher->para.src_data_len);
m_src->buf_addr = get_data_ptr(vc_req, desc, VHOST_ACCESS_RO);
@@ -886,13 +899,7 @@ prepare_sym_cipher_op(struct vhost_crypto *vcrypto, struct
rte_crypto_op *op,
break;
case RTE_VHOST_CRYPTO_ZERO_COPY_DISABLE:
vc_req->wb_pool = vcrypto->wb_pool;
-
- if (unlikely(cipher->para.src_data_len >
- RTE_MBUF_DEFAULT_BUF_SIZE)) {
- VC_LOG_ERR("Not enough space to do data copy");
- ret = VIRTIO_CRYPTO_ERR;
- goto error_exit;
- }
+ m_src->data_len = cipher->para.src_data_len;
if (unlikely(copy_data(rte_pktmbuf_mtod(m_src, uint8_t *),
vc_req, &desc, cipher->para.src_data_len,
nb_descs, vq_size) < 0)) {
@@ -975,6 +982,29 @@ prepare_sym_cipher_op(struct vhost_crypto *vcrypto, struct
rte_crypto_op *op,
return ret;
}
+static __rte_always_inline uint8_t
+vhost_crypto_check_chain_request(struct virtio_crypto_alg_chain_data_req *req)
+{
+ if (likely((req->para.iv_len <= VHOST_CRYPTO_MAX_IV_LEN) &&
+ (req->para.src_data_len <= RTE_MBUF_DEFAULT_DATAROOM) &&
+ (req->para.dst_data_len >= req->para.src_data_len) &&
+ (req->para.dst_data_len <= RTE_MBUF_DEFAULT_DATAROOM) &&
+ (req->para.cipher_start_src_offset <
+ RTE_MBUF_DEFAULT_DATAROOM) &&
+ (req->para.len_to_cipher < RTE_MBUF_DEFAULT_DATAROOM) &&
+ (req->para.hash_start_src_offset <
+ RTE_MBUF_DEFAULT_DATAROOM) &&
+ (req->para.len_to_hash < RTE_MBUF_DEFAULT_DATAROOM) &&
+ (req->para.cipher_start_src_offset + req->para.len_to_cipher <=
+ req->para.src_data_len) &&
+ (req->para.hash_start_src_offset + req->para.len_to_hash <=
+ req->para.src_data_len) &&
+ (req->para.dst_data_len + req->para.hash_result_len <=
+ RTE_MBUF_DEFAULT_DATAROOM)))
+ return VIRTIO_CRYPTO_OK;
+ return VIRTIO_CRYPTO_BADMSG;
+}
+
static uint8_t
prepare_sym_chain_op(struct vhost_crypto *vcrypto, struct rte_crypto
[dpdk-dev] [PATCH 4/6] vhost/crypto: fix incorrect write back source
From: Fan Zhang
This patch fixes vhost crypto library for the incorrect source and
destination buffer calculation in the copy mode.
Fixes: cd1e8f03abf0 ("vhost/crypto: fix packet copy in chaining mode")
Cc: sta...@dpdk.org
Signed-off-by: Fan Zhang
Acked-by: Chenbo Xia
---
lib/librte_vhost/vhost_crypto.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/librte_vhost/vhost_crypto.c b/lib/librte_vhost/vhost_crypto.c
index 494f49084b..f1cc32a9b2 100644
--- a/lib/librte_vhost/vhost_crypto.c
+++ b/lib/librte_vhost/vhost_crypto.c
@@ -749,14 +749,14 @@ prepare_write_back_data(struct vhost_crypto_data_req
*vc_req,
wb_data->src = src + offset;
dlen = desc->len;
dst = IOVA_TO_VVA(uint8_t *, vc_req, desc->addr,
- &dlen, VHOST_ACCESS_RW) + offset;
+ &dlen, VHOST_ACCESS_RW);
if (unlikely(!dst || dlen != desc->len)) {
VC_LOG_ERR("Failed to map descriptor");
goto error_exit;
}
- wb_data->dst = dst;
- wb_data->len = RTE_MIN(desc->len - offset, write_back_len);
+ wb_data->dst = dst + offset;
+ wb_data->len = RTE_MIN(dlen - offset, write_back_len);
write_back_len -= wb_data->len;
src += offset + wb_data->len;
offset = 0;
@@ -801,7 +801,7 @@ prepare_write_back_data(struct vhost_crypto_data_req
*vc_req,
goto error_exit;
}
- wb_data->src = src;
+ wb_data->src = src + offset;
wb_data->dst = dst;
wb_data->len = RTE_MIN(desc->len - offset, write_back_len);
write_back_len -= wb_data->len;
--
2.26.2
[dpdk-dev] [PATCH 5/6] vhost/crypto: fix data length check
From: Fan Zhang
This patch fixes the incorrect data length check to vhost crypto.
Instead of blindly accepting the descriptor length as data length, the
change compare the request provided data length and descriptor length
first. The security issue CVE-2020-14374 is not fixed alone by this
patch, part of the fix is done through:
"vhost/crypto: fix missed request check for copy mode".
CVE-2020-14374
Fixes: 3c79609fda7c ("vhost/crypto: handle virtually non-contiguous buffers")
Cc: sta...@dpdk.org
Signed-off-by: Fan Zhang
Acked-by: Chenbo Xia
---
lib/librte_vhost/vhost_crypto.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_vhost/vhost_crypto.c b/lib/librte_vhost/vhost_crypto.c
index f1cc32a9b2..cf9aa2566b 100644
--- a/lib/librte_vhost/vhost_crypto.c
+++ b/lib/librte_vhost/vhost_crypto.c
@@ -624,7 +624,7 @@ copy_data(void *dst_data, struct vhost_crypto_data_req
*vc_req,
desc = &vc_req->head[desc->next];
rte_prefetch0(&vc_req->head[desc->next]);
to_copy = RTE_MIN(desc->len, (uint32_t)left);
- dlen = desc->len;
+ dlen = to_copy;
src = IOVA_TO_VVA(uint8_t *, vc_req, desc->addr, &dlen,
VHOST_ACCESS_RO);
if (unlikely(!src || !dlen)) {
--
2.26.2
[dpdk-dev] [PATCH 6/6] vhost/crypto: fix possible TOCTOU attack
From: Fan Zhang
This patch fixes the possible time-of-check to time-of-use (TOCTOU)
attack problem by copying request data and descriptor index to local
variable prior to process.
Also the original sequential read of descriptors may lead to TOCTOU
attack. This patch fixes the problem by loading all descriptors of a
request to local buffer before processing.
CVE-2020-14375
Fixes: 3bb595ecd682 ("vhost/crypto: add request handler")
Cc: sta...@dpdk.org
Signed-off-by: Fan Zhang
Acked-by: Chenbo Xia
---
lib/librte_vhost/rte_vhost_crypto.h | 2 +
lib/librte_vhost/vhost_crypto.c | 391 ++--
2 files changed, 202 insertions(+), 191 deletions(-)
diff --git a/lib/librte_vhost/rte_vhost_crypto.h
b/lib/librte_vhost/rte_vhost_crypto.h
index 866a592a5d..b54d61db69 100644
--- a/lib/librte_vhost/rte_vhost_crypto.h
+++ b/lib/librte_vhost/rte_vhost_crypto.h
@@ -7,10 +7,12 @@
#define VHOST_CRYPTO_MBUF_POOL_SIZE(8192)
#define VHOST_CRYPTO_MAX_BURST_SIZE(64)
+#define VHOST_CRYPTO_MAX_DATA_SIZE (4096)
#define VHOST_CRYPTO_SESSION_MAP_ENTRIES (1024) /**< Max nb sessions */
/** max nb virtual queues in a burst for finalizing*/
#define VIRTIO_CRYPTO_MAX_NUM_BURST_VQS(64)
#define VHOST_CRYPTO_MAX_IV_LEN(32)
+#define VHOST_CRYPTO_MAX_N_DESC(32)
enum rte_vhost_crypto_zero_copy {
RTE_VHOST_CRYPTO_ZERO_COPY_DISABLE = 0,
diff --git a/lib/librte_vhost/vhost_crypto.c b/lib/librte_vhost/vhost_crypto.c
index cf9aa2566b..e08f9c6d75 100644
--- a/lib/librte_vhost/vhost_crypto.c
+++ b/lib/librte_vhost/vhost_crypto.c
@@ -46,6 +46,14 @@
#define IOVA_TO_VVA(t, r, a, l, p) \
((t)(uintptr_t)vhost_iova_to_vva(r->dev, r->vq, a, l, p))
+/*
+ * vhost_crypto_desc is used to copy original vring_desc to the local buffer
+ * before processing (except the next index). The copy result will be an
+ * array of vhost_crypto_desc elements that follows the sequence of original
+ * vring_desc.next is arranged.
+ */
+#define vhost_crypto_desc vring_desc
+
static int
cipher_algo_transform(uint32_t virtio_cipher_algo,
enum rte_crypto_cipher_algorithm *algo)
@@ -479,83 +487,71 @@ vhost_crypto_msg_post_handler(int vid, void *msg)
return ret;
}
-static __rte_always_inline struct vring_desc *
-find_write_desc(struct vring_desc *head, struct vring_desc *desc,
- uint32_t *nb_descs, uint32_t vq_size)
+static __rte_always_inline struct vhost_crypto_desc *
+find_write_desc(struct vhost_crypto_desc *head, struct vhost_crypto_desc *desc,
+ uint32_t max_n_descs)
{
- if (desc->flags & VRING_DESC_F_WRITE)
- return desc;
-
- while (desc->flags & VRING_DESC_F_NEXT) {
- if (unlikely(*nb_descs == 0 || desc->next >= vq_size))
- return NULL;
- (*nb_descs)--;
+ if (desc < head)
+ return NULL;
- desc = &head[desc->next];
+ while (desc - head < (int)max_n_descs) {
if (desc->flags & VRING_DESC_F_WRITE)
return desc;
+ desc++;
}
return NULL;
}
-static struct virtio_crypto_inhdr *
-reach_inhdr(struct vhost_crypto_data_req *vc_req, struct vring_desc *desc,
- uint32_t *nb_descs, uint32_t vq_size)
+static __rte_always_inline struct virtio_crypto_inhdr *
+reach_inhdr(struct vhost_crypto_data_req *vc_req,
+ struct vhost_crypto_desc *head,
+ uint32_t max_n_descs)
{
- uint64_t dlen;
struct virtio_crypto_inhdr *inhdr;
+ struct vhost_crypto_desc *last = head + (max_n_descs - 1);
+ uint64_t dlen = last->len;
- while (desc->flags & VRING_DESC_F_NEXT) {
- if (unlikely(*nb_descs == 0 || desc->next >= vq_size))
- return NULL;
- (*nb_descs)--;
- desc = &vc_req->head[desc->next];
- }
+ if (unlikely(dlen != sizeof(*inhdr)))
+ return NULL;
- dlen = desc->len;
- inhdr = IOVA_TO_VVA(struct virtio_crypto_inhdr *, vc_req, desc->addr,
+ inhdr = IOVA_TO_VVA(struct virtio_crypto_inhdr *, vc_req, last->addr,
&dlen, VHOST_ACCESS_WO);
- if (unlikely(!inhdr || dlen != desc->len))
+ if (unlikely(!inhdr || dlen != last->len))
return NULL;
return inhdr;
}
static __rte_always_inline int
-move_desc(struct vring_desc *head, struct vring_desc **cur_desc,
- uint32_t size, uint32_t *nb_descs, uint32_t vq_size)
+move_desc(struct vhost_crypto_desc *head,
+ struct vhost_crypto_desc **cur_desc,
+ uint32_t size, uint32_t max_n_descs)
{
- struct vring_desc *desc = *cur_desc;
+ struct vhost_crypto_desc *desc = *cur_desc;
int left = size - desc->len;
- while ((desc->fla
Re: [dpdk-dev] [PATCH] net/ring: advertise multi segment support.
> On 9/28/2020 8:31 AM, Dumitru Ceara wrote: > > On 9/22/20 4:21 PM, Ferruh Yigit wrote: > >> On 9/18/2020 11:36 AM, Dumitru Ceara wrote: > >>> Even though ring interfaces don't support any other TX/RX offloads they > >>> do support sending multi segment packets and this should be advertised > >>> in order to not break applications that use ring interfaces. > >>> > >> > >> Does ring PMD support sending multi segmented packets? > >> > > > > Yes, sending multi segmented packets works fine with ring PMD. > > > > Define "works fine" :) > > All PMDs can put the first mbuf of the chained mbuf to the ring, in that case > what is the difference between the ones supports 'DEV_TX_OFFLOAD_MULTI_SEGS' > and > the ones doesn't support? > > If the traffic is only from ring PMD to ring PMD, you won't recognize the > difference between segmented or not-segmented mbufs, and it will look like > segmented packets works fine. > But if there is other PMDs involved in the forwarding, or if need to process > the > packets, will it still work fine? > > >> As far as I can see ring PMD doesn't know about the mbuf segments. > >> > > > > Right, the PMD doesn't care about the mbuf segments but it implicitly > > supports sending multi segmented packets. From what I see it's actually > > the case for most of the PMDs, in the sense that most don't even check > > the DEV_TX_OFFLOAD_MULTI_SEGS flag and if the application sends multi > > segment packets they are just accepted. > > > > As far as I can see, if the segmented packets sent, the ring PMD will put the > first mbuf into the ring without doing anything specific to the next segments. > > If the 'DEV_TX_OFFLOAD_MULTI_SEGS' is supported I expect it should detect the > segmented packets and put each chained mbuf into the separate field in the > ring. Hmm, wonder why do you think this is necessary? From my perspective current behaviour is sufficient for TX-ing multi-seg packets over the ring. > > > > > However, the fact that the ring PMD doesn't advertise this implicit > > support forces applications that use ring PMD to have a special case for > > handling ring interfaces. If the ring PMD would advertise > > DEV_TX_OFFLOAD_MULTI_SEGS this would allow upper layers to be oblivious > > to the type of underlying interface. > > > > This is not handling the special case for the ring PMD, this is why he have > the > offload capability flag. Application should behave according capability flags, > not per specific PMD. > > Is there any specific usecase you are trying to cover?
Re: [dpdk-dev] [PATCH] net/ring: advertise multi segment support.
On Mon, Sep 28, 2020 at 11:25:34AM +0100, Ferruh Yigit wrote: > On 9/28/2020 8:31 AM, Dumitru Ceara wrote: > > On 9/22/20 4:21 PM, Ferruh Yigit wrote: > > > On 9/18/2020 11:36 AM, Dumitru Ceara wrote: > > > > Even though ring interfaces don't support any other TX/RX offloads they > > > > do support sending multi segment packets and this should be advertised > > > > in order to not break applications that use ring interfaces. > > > > > > > > > > Does ring PMD support sending multi segmented packets? > > > > > > > Yes, sending multi segmented packets works fine with ring PMD. > > > > Define "works fine" :) > > All PMDs can put the first mbuf of the chained mbuf to the ring, in that > case what is the difference between the ones supports > 'DEV_TX_OFFLOAD_MULTI_SEGS' and the ones doesn't support? > > If the traffic is only from ring PMD to ring PMD, you won't recognize the > difference between segmented or not-segmented mbufs, and it will look like > segmented packets works fine. > But if there is other PMDs involved in the forwarding, or if need to process > the packets, will it still work fine? > What other PMDs do or don't do should be irrelevant here, I think. The fact that multi-segment PMDs make it though the ring PMD in valid form should be sufficient to mark it as supported. > > > As far as I can see ring PMD doesn't know about the mbuf segments. > > > > > > > Right, the PMD doesn't care about the mbuf segments but it implicitly > > supports sending multi segmented packets. From what I see it's actually > > the case for most of the PMDs, in the sense that most don't even check > > the DEV_TX_OFFLOAD_MULTI_SEGS flag and if the application sends multi > > segment packets they are just accepted. > > > > As far as I can see, if the segmented packets sent, the ring PMD will put > the first mbuf into the ring without doing anything specific to the next > segments. > > If the 'DEV_TX_OFFLOAD_MULTI_SEGS' is supported I expect it should detect > the segmented packets and put each chained mbuf into the separate field in > the ring. > Why, what would be the advantage of that? Right now if you send in a valid packet chain to the Ring PMD, you get a valid packet chain out again the other side, so I don't see what needs to change about that behaviour. > > > > However, the fact that the ring PMD doesn't advertise this implicit > > support forces applications that use ring PMD to have a special case for > > handling ring interfaces. If the ring PMD would advertise > > DEV_TX_OFFLOAD_MULTI_SEGS this would allow upper layers to be oblivious > > to the type of underlying interface. > > > > This is not handling the special case for the ring PMD, this is why he have > the offload capability flag. Application should behave according capability > flags, not per specific PMD. > > Is there any specific usecase you are trying to cover?
Re: [dpdk-dev] [PATCH v2 1/4] net/vhost: remove dequeue zero-copy support
> -Original Message-
> From: Maxime Coquelin
> Sent: Monday, September 28, 2020 5:17 PM
> To: dev@dpdk.org; Xia, Chenbo ; Stokes, Ian
>
> Cc: Maxime Coquelin
> Subject: [PATCH v2 1/4] net/vhost: remove dequeue zero-copy support
>
> The dequeue zero-copy feature from the Vhost library is
> being removed in this release, this patch remove its support
> in the Vhost PMD.
>
> Signed-off-by: Maxime Coquelin
> ---
> drivers/net/vhost/rte_eth_vhost.c | 14 --
> 1 file changed, 14 deletions(-)
>
> diff --git a/drivers/net/vhost/rte_eth_vhost.c
> b/drivers/net/vhost/rte_eth_vhost.c
> index ce32be9ce3..5a39293083 100644
> --- a/drivers/net/vhost/rte_eth_vhost.c
> +++ b/drivers/net/vhost/rte_eth_vhost.c
> @@ -29,7 +29,6 @@ enum {VIRTIO_RXQ, VIRTIO_TXQ, VIRTIO_QNUM};
> #define ETH_VHOST_IFACE_ARG "iface"
> #define ETH_VHOST_QUEUES_ARG "queues"
> #define ETH_VHOST_CLIENT_ARG "client"
> -#define ETH_VHOST_DEQUEUE_ZERO_COPY "dequeue-zero-copy"
> #define ETH_VHOST_IOMMU_SUPPORT "iommu-support"
> #define ETH_VHOST_POSTCOPY_SUPPORT "postcopy-support"
> #define ETH_VHOST_VIRTIO_NET_F_HOST_TSO "tso"
> @@ -41,7 +40,6 @@ static const char *valid_arguments[] = {
> ETH_VHOST_IFACE_ARG,
> ETH_VHOST_QUEUES_ARG,
> ETH_VHOST_CLIENT_ARG,
> - ETH_VHOST_DEQUEUE_ZERO_COPY,
> ETH_VHOST_IOMMU_SUPPORT,
> ETH_VHOST_POSTCOPY_SUPPORT,
> ETH_VHOST_VIRTIO_NET_F_HOST_TSO,
> @@ -1501,7 +1499,6 @@ rte_pmd_vhost_probe(struct rte_vdev_device *dev)
> uint64_t flags = 0;
> uint64_t disable_flags = 0;
> int client_mode = 0;
> - int dequeue_zero_copy = 0;
> int iommu_support = 0;
> int postcopy_support = 0;
> int tso = 0;
> @@ -1561,16 +1558,6 @@ rte_pmd_vhost_probe(struct rte_vdev_device *dev)
> flags |= RTE_VHOST_USER_CLIENT;
> }
>
> - if (rte_kvargs_count(kvlist, ETH_VHOST_DEQUEUE_ZERO_COPY) == 1) {
> - ret = rte_kvargs_process(kvlist, ETH_VHOST_DEQUEUE_ZERO_COPY,
> - &open_int, &dequeue_zero_copy);
> - if (ret < 0)
> - goto out_free;
> -
> - if (dequeue_zero_copy)
> - flags |= RTE_VHOST_USER_DEQUEUE_ZERO_COPY;
> - }
> -
> if (rte_kvargs_count(kvlist, ETH_VHOST_IOMMU_SUPPORT) == 1) {
> ret = rte_kvargs_process(kvlist, ETH_VHOST_IOMMU_SUPPORT,
>&open_int, &iommu_support);
> @@ -1674,7 +1661,6 @@ RTE_PMD_REGISTER_PARAM_STRING(net_vhost,
> "iface= "
> "queues= "
> "client=<0|1> "
> - "dequeue-zero-copy=<0|1> "
> "iommu-support=<0|1> "
> "postcopy-support=<0|1> "
> "tso=<0|1> "
> --
> 2.26.2
Reviewed-by: Chenbo Xia
[dpdk-dev] [PATCH V14 1/3] ethdev: introduce FEC API
This patch adds Forward error correction(FEC) support for ethdev.
Introduce APIs which support query and config FEC information in
hardware.
Signed-off-by: Min Hu (Connor)
Reviewed-by: Wei Hu (Xavier)
Reviewed-by: Chengwen Feng
Reviewed-by: Chengchang Tang
Acked-by: Andrew Rybchenko
---
v13->v14:
change mode to fec_capa.
fix comment about API.
---
v12->v13:
change fec get capa API.
fix comment styles.
---
v10->v11:
allow to report capabilities per link speed.
specify what should be reported if link is down
when get FEC.
change mode to capa bitmask.
---
v9->v10:
add macro RTE_ETH_FEC_MODE_CAPA_MASK(x) to indicate
different FEC mode capa.
---
v8->v9:
added reviewed-by and acked-by.
---
v7->v8:
put AUTO just after NOFEC in rte_fec_mode definition.
---
v6->v7:
deleted RTE_ETH_FEC_NUM to prevent ABI breakage.
add new macro to indicate translation from fec mode
to capa.
---
v5->v6:
modified release notes.
deleted check duplicated for FEC API
fixed code styles according to DPDK coding style.
added _eth prefix.
---
v4->v5:
Modifies FEC capa definitions using macros.
Add RTE_ prefix for public FEC mode enum.
add release notes about FEC for dpdk20_11.
---
v2->v3:
add function return value "-ENOTSUP" for API.
---
doc/guides/rel_notes/release_20_11.rst | 5 ++
lib/librte_ethdev/rte_ethdev.c | 44 +
lib/librte_ethdev/rte_ethdev.h | 102 +++
lib/librte_ethdev/rte_ethdev_driver.h| 88 ++
lib/librte_ethdev/rte_ethdev_version.map | 3 +
5 files changed, 242 insertions(+)
diff --git a/doc/guides/rel_notes/release_20_11.rst
b/doc/guides/rel_notes/release_20_11.rst
index c6642f5..1f04bd5 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -78,6 +78,11 @@ New Features
``--portmask=N``
where N represents the hexadecimal bitmask of ports used.
+* **Added the FEC API, for a generic FEC query and config.**
+
+ Added the FEC API which provides functions for query FEC capabilities and
+ current FEC mode from device. Also, API for configuring FEC mode is also
provided.
+
Removed Items
-
diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index dfe5c1b..996d230 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -3679,6 +3679,50 @@ rte_eth_led_off(uint16_t port_id)
return eth_err(port_id, (*dev->dev_ops->dev_led_off)(dev));
}
+int
+rte_eth_fec_get_capability(uint16_t port_id,
+ struct rte_eth_fec_capa *speed_fec_capa,
+ unsigned int num)
+{
+ struct rte_eth_dev *dev;
+ int ret;
+
+ if (speed_fec_capa == NULL && num > 0)
+ return -EINVAL;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ dev = &rte_eth_devices[port_id];
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->fec_get_capability, -ENOTSUP);
+ ret = (*dev->dev_ops->fec_get_capability)(dev, speed_fec_capa, num);
+
+ return ret;
+}
+
+int
+rte_eth_fec_get(uint16_t port_id, uint32_t *fec_capa)
+{
+ struct rte_eth_dev *dev;
+
+ if (fec_capa == NULL)
+ return -EINVAL;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ dev = &rte_eth_devices[port_id];
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->fec_get, -ENOTSUP);
+ return eth_err(port_id, (*dev->dev_ops->fec_get)(dev, fec_capa));
+}
+
+int
+rte_eth_fec_set(uint16_t port_id, uint32_t mode)
+{
+ struct rte_eth_dev *dev;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ dev = &rte_eth_devices[port_id];
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->fec_set, -ENOTSUP);
+ return eth_err(port_id, (*dev->dev_ops->fec_set)(dev, mode));
+}
+
/*
* Returns index into MAC address array of addr. Use 00:00:00:00:00:00 to find
* an empty spot.
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index 645a186..50c5280 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -1544,6 +1544,29 @@ struct rte_eth_dcb_info {
struct rte_eth_dcb_tc_queue_mapping tc_queue;
};
+/**
+ * This enum indicates the possible Forward Error Correction (FEC) modes
+ * of an ethdev port.
+ */
+enum rte_eth_fec_mode {
+ RTE_ETH_FEC_NOFEC = 0, /**< FEC is off */
+ RTE_ETH_FEC_AUTO, /**< FEC autonegotiation modes */
+ RTE_ETH_FEC_BASER, /**< FEC using common algorithm */
+ RTE_ETH_FEC_RS, /**< FEC using RS algorithm */
+};
+
+/* Translate from FEC mode to FEC capa */
+#define RTE_ETH_FEC_MODE_TO_CAPA(x)(1U << (x))
+
+/* This macro indicates FEC capa mask */
+#define RTE_ETH_FEC_MODE_CAPA_MASK(x) (1U << (RTE_ETH_FEC_ ## x))
+
+/* A structure used to get capabilities per link speed */
+struct rte_eth_fec_capa {
+ uint32_t speed; /**< Link speed (see ETH_SPEED_NUM_*) */
+ uint32_t capa
[dpdk-dev] [PATCH V14 3/3] app/testpmd: add FEC command
This commit adds testpmd capability to query and config FEC
function of device. This includes:
- show FEC capabilities, example:
testpmd> show port 0 fec capabilities
- show FEC mode, example:
testpmd> show port 0 fec_mode
- config FEC mode, example:
testpmd> set port 0
where:
auto|off|rs|baser are four kinds of FEC mode which dev
support according to MAC link speed.
Signed-off-by: Min Hu (Connor)
Reviewed-by: Wei Hu (Xavier)
Reviewed-by: Chengwen Feng
Reviewed-by: Chengchang Tang
---
v12->v13:
change fec get capa interface.
---
v10->v11:
change mode to capa bitmask.
---
v8->v9:
added acked-by.
---
v6->v7:
used RTE_DIM(fec_mode_name) instead of RTE_ETH_FEC_NUM
---
v5->v6:
fixed code styles according to DPDK coding style.
added _eth prefix.
---
v4->v5:
Add RTE_ prefix for public FEC mode enum.
---
v3->v4:
adjust the display format of FEC mode
---
v2->v3:
adjust the display format of FEC capability.
---
app/test-pmd/cmdline.c | 223 +
app/test-pmd/config.c | 91
app/test-pmd/testpmd.h | 2 +
3 files changed, 316 insertions(+)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 5f93409..407513c 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -19161,6 +19161,226 @@ cmdline_parse_inst_t cmd_show_tx_metadata = {
},
};
+/* *** show fec capability per port configuration *** */
+struct cmd_show_fec_capability_result {
+ cmdline_fixed_string_t cmd_show;
+ cmdline_fixed_string_t cmd_port;
+ cmdline_fixed_string_t cmd_fec;
+ cmdline_fixed_string_t cmd_keyword;
+ portid_t cmd_pid;
+};
+
+static void
+cmd_show_fec_capability_parsed(void *parsed_result,
+ __rte_unused struct cmdline *cl,
+ __rte_unused void *data)
+{
+#define FEC_CAP_NUM 2
+ struct cmd_show_fec_capability_result *res = parsed_result;
+ struct rte_eth_fec_capa speed_fec_capa[FEC_CAP_NUM];
+ unsigned int num = FEC_CAP_NUM;
+ unsigned int ret_num;
+ int ret;
+
+ if (!rte_eth_dev_is_valid_port(res->cmd_pid)) {
+ printf("Invalid port id %u\n", res->cmd_pid);
+ return;
+ }
+
+ ret = rte_eth_fec_get_capability(res->cmd_pid, speed_fec_capa, num);
+ if (ret == -ENOTSUP) {
+ printf("Function not implemented\n");
+ return;
+ } else if (ret < 0) {
+ printf("Get FEC capability failed\n");
+ return;
+ }
+
+ ret_num = (unsigned int)ret;
+ show_fec_capability(ret_num, speed_fec_capa);
+}
+
+cmdline_parse_token_string_t cmd_show_fec_capability_show =
+ TOKEN_STRING_INITIALIZER(struct cmd_show_fec_capability_result,
+ cmd_show, "show");
+cmdline_parse_token_string_t cmd_show_fec_capability_port =
+ TOKEN_STRING_INITIALIZER(struct cmd_show_fec_capability_result,
+ cmd_port, "port");
+cmdline_parse_token_num_t cmd_show_fec_capability_pid =
+ TOKEN_NUM_INITIALIZER(struct cmd_show_fec_capability_result,
+ cmd_pid, UINT16);
+cmdline_parse_token_string_t cmd_show_fec_capability_fec =
+ TOKEN_STRING_INITIALIZER(struct cmd_show_fec_capability_result,
+ cmd_fec, "fec");
+cmdline_parse_token_string_t cmd_show_fec_capability_keyword =
+ TOKEN_STRING_INITIALIZER(struct cmd_show_fec_capability_result,
+ cmd_keyword, "capabilities");
+
+cmdline_parse_inst_t cmd_show_capability = {
+ .f = cmd_show_fec_capability_parsed,
+ .data = NULL,
+ .help_str = "show port fec capabilities",
+ .tokens = {
+ (void *)&cmd_show_fec_capability_show,
+ (void *)&cmd_show_fec_capability_port,
+ (void *)&cmd_show_fec_capability_pid,
+ (void *)&cmd_show_fec_capability_fec,
+ (void *)&cmd_show_fec_capability_keyword,
+ NULL,
+ },
+};
+
+/* *** show fec mode per port configuration *** */
+struct cmd_show_fec_metadata_result {
+ cmdline_fixed_string_t cmd_show;
+ cmdline_fixed_string_t cmd_port;
+ cmdline_fixed_string_t cmd_keyword;
+ portid_t cmd_pid;
+};
+
+static void
+cmd_show_fec_mode_parsed(void *parsed_result,
+ __rte_unused struct cmdline *cl,
+ __rte_unused void *data)
+{
+#define FEC_NAME_SIZE 16
+ struct cmd_show_fec_metadata_result *res = parsed_result;
+ uint32_t mode;
+ char buf[FEC_NAME_SIZE];
+ int ret;
+
+ if (!rte_eth_dev_is_valid_port(res->cmd_pid)) {
+ printf("Invalid port id %u\n", res->cmd_pid);
+ return;
+ }
+ ret = rte_eth_fec_get(res->cmd_pid, &mode);
+ if (ret == -ENOTSUP) {
+ printf("Function not implemented\n");
+ return;
+ } else if (ret < 0) {
+ printf("Get FEC
[dpdk-dev] [PATCH V14 2/3] net/hns3: support FEC
Forward error correction (FEC) is a bit error correction mode.
It adds error correction information to data packets at the
transmit end, and uses the error correction information to correct
the bit errors generated during data packet transmission at the
receive end. This improves signal quality but also brings a delay
to signals. This function can be enabled or disabled as required.
This patch adds FEC support for ethdev.Introduce ethdev
operations which support query and config FEC information in
hardware.
Signed-off-by: Min Hu (Connor)
Reviewed-by: Wei Hu (Xavier)
Reviewed-by: Chengwen Feng
Reviewed-by: Chengchang Tang
---
v13->v14:
change mode to fec_capa.
---
v12->v13:
change fec get capa interface.
---
v11->v12:
fix coding warning.
v10->v11:
allow to report capabilities per link speed.
specify what should be reported if link is down
when get FEC.
change mode to capa bitmask.
---
v9->v10:
use RTE_ETH_FEC_MODE_CAPA_MASK(x) which is just defined.
---
v7->v8:
FEC mode order defined in hns3 hardware is inconsistend with
that defined in the ethdev library. So the sequence needs
to be converted.
---
v5->v6:
fixed code styles according to DPDK coding style.
added _eth prefix.
---
v4->v5:
Data type for fec_cap is changed from uint8_t
to uint32_t for possible future expansion.
---
v2->v3:
adjust the return value of function.
---
doc/guides/rel_notes/release_20_11.rst | 5 +
drivers/net/hns3/hns3_cmd.h| 19 +-
drivers/net/hns3/hns3_ethdev.c | 356 +
drivers/net/hns3/hns3_ethdev.h | 1 +
4 files changed, 380 insertions(+), 1 deletion(-)
diff --git a/doc/guides/rel_notes/release_20_11.rst
b/doc/guides/rel_notes/release_20_11.rst
index 1f04bd5..eec6930 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -83,6 +83,11 @@ New Features
Added the FEC API which provides functions for query FEC capabilities and
current FEC mode from device. Also, API for configuring FEC mode is also
provided.
+* **Added hns3 FEC PMD, for supporting query and config FEC mode.**
+
+ Added the FEC PMD which provides functions for query FEC capabilities and
+ current FEC mode from device. Also, PMD for configuring FEC mode is also
provided.
+
Removed Items
-
diff --git a/drivers/net/hns3/hns3_cmd.h b/drivers/net/hns3/hns3_cmd.h
index 87d6053..a1e9604 100644
--- a/drivers/net/hns3/hns3_cmd.h
+++ b/drivers/net/hns3/hns3_cmd.h
@@ -100,6 +100,7 @@ enum hns3_opcode_type {
HNS3_OPC_QUERY_LINK_STATUS = 0x0307,
HNS3_OPC_CONFIG_MAX_FRM_SIZE= 0x0308,
HNS3_OPC_CONFIG_SPEED_DUP = 0x0309,
+ HNS3_OPC_CONFIG_FEC_MODE= 0x031A,
/* PFC/Pause commands */
HNS3_OPC_CFG_MAC_PAUSE_EN = 0x0701,
@@ -684,9 +685,25 @@ struct hns3_config_auto_neg_cmd {
uint8_t rsv[20];
};
+#define HNS3_MAC_CFG_FEC_AUTO_EN_B 0
+#define HNS3_MAC_CFG_FEC_MODE_S1
+#define HNS3_MAC_CFG_FEC_MODE_MGENMASK(3, 1)
+#define HNS3_MAC_FEC_OFF 0
+#define HNS3_MAC_FEC_BASER 1
+#define HNS3_MAC_FEC_RS2
+
struct hns3_sfp_speed_cmd {
uint32_t sfp_speed;
- uint32_t rsv[5];
+ uint8_t query_type; /* 0: sfp speed, 1: active fec */
+ uint8_t active_fec; /* current FEC mode */
+ uint16_t rsv1;
+ uint32_t rsv2[4];
+};
+
+/* Configure FEC mode, opcode:0x031A */
+struct hns3_config_fec_cmd {
+ uint8_t fec_mode;
+ uint8_t rsv[23];
};
#define HNS3_MAC_MGR_MASK_VLAN_B BIT(0)
diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
index 73d5042..2fa1aea 100644
--- a/drivers/net/hns3/hns3_ethdev.c
+++ b/drivers/net/hns3/hns3_ethdev.c
@@ -63,6 +63,11 @@
#define HNS3_RESET_WAIT_MS 100
#define HNS3_RESET_WAIT_CNT200
+/* FEC mode order defined in HNS3 hardware */
+#define HNS3_HW_FEC_MODE_NOFEC 0
+#define HNS3_HW_FEC_MODE_BASER 1
+#define HNS3_HW_FEC_MODE_RS 2
+
enum hns3_evt_cause {
HNS3_VECTOR0_EVENT_RST,
HNS3_VECTOR0_EVENT_MBX,
@@ -70,6 +75,34 @@ enum hns3_evt_cause {
HNS3_VECTOR0_EVENT_OTHER,
};
+static const struct rte_eth_fec_capa speed_fec_capa_tbl[] = {
+ { ETH_SPEED_NUM_10G, RTE_ETH_FEC_MODE_CAPA_MASK(NOFEC) |
+RTE_ETH_FEC_MODE_CAPA_MASK(AUTO) |
+RTE_ETH_FEC_MODE_CAPA_MASK(BASER) },
+
+ { ETH_SPEED_NUM_25G, RTE_ETH_FEC_MODE_CAPA_MASK(NOFEC) |
+RTE_ETH_FEC_MODE_CAPA_MASK(AUTO) |
+RTE_ETH_FEC_MODE_CAPA_MASK(BASER) |
+RTE_ETH_FEC_MODE_CAPA_MASK(RS) },
+
+ { ETH_SPEED_NUM_40G, RTE_ETH_FEC_MODE_CAPA_MASK(NOFEC) |
+RTE_ETH_FEC_MODE_CAPA_MASK(AUTO) |
+RTE_ETH_FEC_MODE_CAPA_MASK(BASER) },
+
+ { ETH_SPEED_NUM_50G, RTE_ETH_FEC_MODE_CAPA_MASK(NOF
[dpdk-dev] [PATCH V14 0/3] add FEC support
This series add FEC support for ethdev. Min Hu (Connor) (3): ethdev: introduce FEC API net/hns3: support FEC app/testpmd: add FEC command app/test-pmd/cmdline.c | 223 +++ app/test-pmd/config.c| 91 app/test-pmd/testpmd.h | 2 + doc/guides/rel_notes/release_20_11.rst | 10 + drivers/net/hns3/hns3_cmd.h | 19 +- drivers/net/hns3/hns3_ethdev.c | 356 +++ drivers/net/hns3/hns3_ethdev.h | 1 + lib/librte_ethdev/rte_ethdev.c | 44 lib/librte_ethdev/rte_ethdev.h | 102 + lib/librte_ethdev/rte_ethdev_driver.h| 88 lib/librte_ethdev/rte_ethdev_version.map | 3 + 11 files changed, 938 insertions(+), 1 deletion(-) -- 2.7.4
[dpdk-dev] Strongswan Support on DPDK
Hi, Does dpdk support Strongswan applications? If yes , Could you please share the steps/configuration/architecture for strongswan on dpdk?. Thank you. Jagadeesh
Re: [dpdk-dev] [PATCH V13 0/3] add FEC support
Hi, Ferruh, I've send a set of patches named V14, please check it ,thanks. 在 2020/9/28 18:27, Ferruh Yigit 写道: On 9/27/2020 8:08 AM, Min Hu (Connor) wrote: Hello, Are there any suggustions for this set patches ? 在 2020/9/25 16:39, Min Hu (Connor) 写道: This series add FEC support for ethdev. Min Hu (Connor) (3): ethdev: introduce FEC API net/hns3: support FEC app/testpmd: add FEC command app/test-pmd/cmdline.c | 223 +++ app/test-pmd/config.c | 91 app/test-pmd/testpmd.h | 2 + doc/guides/rel_notes/release_20_11.rst | 10 + drivers/net/hns3/hns3_cmd.h | 19 +- drivers/net/hns3/hns3_ethdev.c | 356 +++ drivers/net/hns3/hns3_ethdev.h | 1 + lib/librte_ethdev/rte_ethdev.c | 43 lib/librte_ethdev/rte_ethdev.h | 94 lib/librte_ethdev/rte_ethdev_driver.h | 80 +++ lib/librte_ethdev/rte_ethdev_version.map | 3 + 11 files changed, 921 insertions(+), 1 deletion(-) Hi Connor, Can you please make a new version addressing the minor issues Andrew highlighted and including his ack? Thanks, ferruh .
Re: [dpdk-dev] [PATCH V13 1/3] ethdev: introduce FEC API
Hi, Andrew,
I have sent V14, in which I fixed it as you suggested,
please check it out,thank you.
在 2020/9/28 15:35, Andrew Rybchenko 写道:
On 9/25/20 11:39 AM, Min Hu (Connor) wrote:
This patch adds Forward error correction(FEC) support for ethdev.
Introduce APIs which support query and config FEC information in
hardware.
Signed-off-by: Min Hu (Connor)
Reviewed-by: Wei Hu (Xavier)
Reviewed-by: Chengwen Feng
Reviewed-by: Chengchang Tang
With few nits below:
Acked-by: Andrew Rybchenko
---
v12->v13:
change fec get capa API.
fix comment styles.
---
v10->v11:
allow to report capabilities per link speed.
specify what should be reported if link is down
when get FEC.
change mode to capa bitmask.
---
v9->v10:
add macro RTE_ETH_FEC_MODE_CAPA_MASK(x) to indicate
different FEC mode capa.
---
v8->v9:
added reviewed-by and acked-by.
---
v7->v8:
put AUTO just after NOFEC in rte_fec_mode definition.
---
v6->v7:
deleted RTE_ETH_FEC_NUM to prevent ABI breakage.
add new macro to indicate translation from fec mode
to capa.
---
v5->v6:
modified release notes.
deleted check duplicated for FEC API
fixed code styles according to DPDK coding style.
added _eth prefix.
---
v4->v5:
Modifies FEC capa definitions using macros.
Add RTE_ prefix for public FEC mode enum.
add release notes about FEC for dpdk20_11.
---
v2->v3:
add function return value "-ENOTSUP" for API.
---
doc/guides/rel_notes/release_20_11.rst | 5 ++
lib/librte_ethdev/rte_ethdev.c | 43 +++
lib/librte_ethdev/rte_ethdev.h | 94
lib/librte_ethdev/rte_ethdev_driver.h| 80 +++
lib/librte_ethdev/rte_ethdev_version.map | 3 +
5 files changed, 225 insertions(+)
diff --git a/doc/guides/rel_notes/release_20_11.rst
b/doc/guides/rel_notes/release_20_11.rst
index c6642f5..1f04bd5 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -78,6 +78,11 @@ New Features
``--portmask=N``
where N represents the hexadecimal bitmask of ports used.
+* **Added the FEC API, for a generic FEC query and config.**
+
+ Added the FEC API which provides functions for query FEC capabilities and
+ current FEC mode from device. Also, API for configuring FEC mode is also
provided.
+
Removed Items
-
diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index dfe5c1b..86ead87 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -3679,6 +3679,49 @@ rte_eth_led_off(uint16_t port_id)
return eth_err(port_id, (*dev->dev_ops->dev_led_off)(dev));
}
+int
+rte_eth_fec_get_capability(uint16_t port_id,
+ struct rte_eth_fec_capa *speed_fec_capa,
+ unsigned int num)
+{
+ struct rte_eth_dev *dev;
+ int ret;
if (speed_fec_capa == NULL && num > 0)
return -EINVAL;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ dev = &rte_eth_devices[port_id];
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->fec_get_capability, -ENOTSUP);
+ ret = (*dev->dev_ops->fec_get_capability)(dev, speed_fec_capa, num);
+ if (ret > (int)num)
+ RTE_ETHDEV_LOG(ERR, "Insufficient num, num should be no less than
%d\n",
+ ret);
It is incorrect to log error, since
num = rte_eth_fec_get_capability(port_id, NULL, 0);
may be used to obtain required number of array elements
(nothing bad is happening).
+
+ return ret;
+}
+
+int
+rte_eth_fec_get(uint16_t port_id, uint32_t *mode)
+{
+ struct rte_eth_dev *dev;
+
+ if (mode == NULL)
+ return -EINVAL;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ dev = &rte_eth_devices[port_id];
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->fec_get, -ENOTSUP);
+ return eth_err(port_id, (*dev->dev_ops->fec_get)(dev, mode));
+}
+
+int
+rte_eth_fec_set(uint16_t port_id, uint32_t mode)
+{
+ struct rte_eth_dev *dev;
+
RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ dev = &rte_eth_devices[port_id];
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->fec_set, -ENOTSUP);
+ return eth_err(port_id, (*dev->dev_ops->fec_set)(dev, mode));
+}
+
/*
* Returns index into MAC address array of addr. Use 00:00:00:00:00:00 to find
* an empty spot.
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index 645a186..04525a8 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -1544,6 +1544,29 @@ struct rte_eth_dcb_info {
struct rte_eth_dcb_tc_queue_mapping tc_queue;
};
+/**
+ * This enum indicates the possible Forward Error Correction (FEC) modes
+ * of an ethdev port.
+ */
+enum rte_eth_fec_mode {
+ RTE_ETH_FEC_NOFEC = 0, /**< FEC is off */
+ RTE_ETH_FEC_AUTO, /**< FEC autonegotiation modes */
+ RTE_ETH_FEC_BASER,
Re: [dpdk-dev] [PATCH v2 4/4] vhost: remove dequeue zero-copy support
> -Original Message- > From: Maxime Coquelin > Sent: Monday, September 28, 2020 5:17 PM > To: dev@dpdk.org; Xia, Chenbo ; Stokes, Ian > > Cc: Maxime Coquelin > Subject: [PATCH v2 4/4] vhost: remove dequeue zero-copy support > > Dequeue zero-copy removal was announced in DPDK v20.08. > This feature brings constraints which makes the maintenance > of the Vhost library difficult. Its limitations makes it also > difficult to use by the applications (Tx vring starvation). > > Removing it makes it easier to add new features, and also remove > some code in the hot path, which should bring a performance > improvement for the standard path. > > Signed-off-by: Maxime Coquelin > --- > doc/guides/prog_guide/vhost_lib.rst | 52 + > lib/librte_vhost/rte_vhost.h| 2 +- > lib/librte_vhost/socket.c | 47 > lib/librte_vhost/vhost.c| 14 -- > lib/librte_vhost/vhost.h| 28 --- > lib/librte_vhost/vhost_user.c | 80 +-- > lib/librte_vhost/virtio_net.c | 326 +++- > 7 files changed, 33 insertions(+), 516 deletions(-) > > diff --git a/doc/guides/prog_guide/vhost_lib.rst > b/doc/guides/prog_guide/vhost_lib.rst > index b892eec67a..ba4c62aeb8 100644 > --- a/doc/guides/prog_guide/vhost_lib.rst > +++ b/doc/guides/prog_guide/vhost_lib.rst > @@ -51,50 +51,6 @@ The following is an overview of some key Vhost API > functions: > This reconnect option is enabled by default. However, it can be > turned off > by setting this flag. > > - - ``RTE_VHOST_USER_DEQUEUE_ZERO_COPY`` > - > -Dequeue zero copy will be enabled when this flag is set. It is > disabled by > -default. > - > -There are some truths (including limitations) you might want to know > while > -setting this flag: > - > -* zero copy is not good for small packets (typically for packet size > below > - 512). > - > -* zero copy is really good for VM2VM case. For iperf between two VMs, > the > - boost could be above 70% (when TSO is enabled). > - > -* For zero copy in VM2NIC case, guest Tx used vring may be starved if > the > - PMD driver consume the mbuf but not release them timely. > - > - For example, i40e driver has an optimization to maximum NIC > pipeline which > - postpones returning transmitted mbuf until only tx_free_threshold > free > - descs left. The virtio TX used ring will be starved if the formula > - (num_i40e_tx_desc - num_virtio_tx_desc > tx_free_threshold) is true, > since > - i40e will not return back mbuf. > - > - A performance tip for tuning zero copy in VM2NIC case is to adjust > the > - frequency of mbuf free (i.e. adjust tx_free_threshold of i40e > driver) to > - balance consumer and producer. > - > -* Guest memory should be backended with huge pages to achieve better > - performance. Using 1G page size is the best. > - > - When dequeue zero copy is enabled, the guest phys address and host > phys > - address mapping has to be established. Using non-huge pages means > far > - more page segments. To make it simple, DPDK vhost does a linear > search > - of those segments, thus the fewer the segments, the quicker we will > get > - the mapping. NOTE: we may speed it by using tree searching in > future. > - > -* zero copy can not work when using vfio-pci with iommu mode > currently, this > - is because we don't setup iommu dma mapping for guest memory. If > you have > - to use vfio-pci driver, please insert vfio-pci kernel module in > noiommu > - mode. > - > -* The consumer of zero copy mbufs should consume these mbufs as soon > as > - possible, otherwise it may block the operations in vhost. > - >- ``RTE_VHOST_USER_IOMMU_SUPPORT`` > > IOMMU support will be enabled when this flag is set. It is disabled > by > @@ -362,16 +318,16 @@ Guest memory requirement > > * Memory pre-allocation > > - For non-zerocopy non-async data path, guest memory pre-allocation is > not a > + For non-async data path, guest memory pre-allocation is not a >must. This can help save of memory. If users really want the guest > memory >to be pre-allocated (e.g., for performance reason), we can add option >``-mem-prealloc`` when starting QEMU. Or, we can lock all memory at > vhost >side which will force memory to be allocated when mmap at vhost side; >option --mlockall in ovs-dpdk is an example in hand. > > - For async and zerocopy data path, we force the VM memory to be > - pre-allocated at vhost lib when mapping the guest memory; and also we > need > - to lock the memory to prevent pages being swapped out to disk. > + For async data path, we force the VM memory to be pre-allocated at > vhost > + lib when mapping the guest memory; and also we need to lock the memory > to > + prevent pages being swapped out to disk. > > * Memory sharing > > diff --git a/lib/librte_vhost/rte_vhost.h b/lib/li
Re: [dpdk-dev] [dpdk-techboard] [PATCH v2] eal: simplify exit functions
> The option RTE_EAL_ALWAYS_PANIC_ON_ERROR was off by default,
> and not customizable with meson. It is completely removed.
>
> The function rte_dump_registers is a trace of the bare metal support
> era, and was not supported in userland. It is completely removed.
>
> Signed-off-by: Thomas Monjalon
> Acked-by: Ray Kinsella
> ---
> The deprecation notice for this removal has been missed.
> I assume it would not hurt anybody to remove this useless function
> from DPDK 20.11. Asking the Technical Board for confirmation.
> ---
> app/test/test_debug.c| 3 ---
> doc/guides/howto/debug_troubleshoot.rst | 2 +-
> doc/guides/rel_notes/release_20_11.rst | 2 ++
> lib/librte_eal/common/eal_common_debug.c | 17 +
> lib/librte_eal/include/rte_debug.h | 7 ---
> lib/librte_eal/rte_eal_version.map | 1 -
> 6 files changed, 4 insertions(+), 28 deletions(-)
>
> diff --git a/app/test/test_debug.c b/app/test/test_debug.c
> index 25eab97e2a..834a7386f5 100644
> --- a/app/test/test_debug.c
> +++ b/app/test/test_debug.c
> @@ -66,13 +66,11 @@ test_exit_val(int exit_val)
> }
> wait(&status);
> printf("Child process status: %d\n", status);
> -#ifndef RTE_EAL_ALWAYS_PANIC_ON_ERROR
> if(!WIFEXITED(status) || WEXITSTATUS(status) != (uint8_t)exit_val){
> printf("Child process terminated with incorrect status
> (expected = %d)!\n",
> exit_val);
> return -1;
> }
> -#endif
> return 0;
> }
>
> @@ -113,7 +111,6 @@ static int
> test_debug(void)
> {
> rte_dump_stack();
> - rte_dump_registers();
> if (test_panic() < 0)
> return -1;
> if (test_exit() < 0)
> diff --git a/doc/guides/howto/debug_troubleshoot.rst
> b/doc/guides/howto/debug_troubleshoot.rst
> index 5a46f5fba3..50bd32a8ef 100644
> --- a/doc/guides/howto/debug_troubleshoot.rst
> +++ b/doc/guides/howto/debug_troubleshoot.rst
> @@ -314,7 +314,7 @@ Custom worker function :numref:`dtg_distributor_worker`.
> * For high-performance execution logic ensure running it on correct NUMA
> and non-master core.
>
> - * Analyze run logic with ``rte_dump_stack``, ``rte_dump_registers`` and
> + * Analyze run logic with ``rte_dump_stack`` and
> ``rte_memdump`` for more insights.
>
> * Make use of objdump to ensure opcode is matching to the desired state.
> diff --git a/doc/guides/rel_notes/release_20_11.rst
> b/doc/guides/rel_notes/release_20_11.rst
> index f377ab8e87..c0b83e9554 100644
> --- a/doc/guides/rel_notes/release_20_11.rst
> +++ b/doc/guides/rel_notes/release_20_11.rst
> @@ -184,6 +184,8 @@ ABI Changes
> Also, make sure to start the actual text at the margin.
> ===
>
> +* eal: Removed the not implemented function ``rte_dump_registers()``.
> +
> * ``ethdev`` changes
>
>* Following device operation function pointers moved
> diff --git a/lib/librte_eal/common/eal_common_debug.c
> b/lib/librte_eal/common/eal_common_debug.c
> index 722468754d..15418e957f 100644
> --- a/lib/librte_eal/common/eal_common_debug.c
> +++ b/lib/librte_eal/common/eal_common_debug.c
> @@ -7,14 +7,6 @@
> #include
> #include
>
> -/* not implemented */
> -void
> -rte_dump_registers(void)
> -{
> - return;
> -}
> -
> -/* call abort(), it will generate a coredump if enabled */
> void
> __rte_panic(const char *funcname, const char *format, ...)
> {
> @@ -25,8 +17,7 @@ __rte_panic(const char *funcname, const char *format, ...)
> rte_vlog(RTE_LOG_CRIT, RTE_LOGTYPE_EAL, format, ap);
> va_end(ap);
> rte_dump_stack();
> - rte_dump_registers();
> - abort();
> + abort(); /* generate a coredump if enabled */
> }
>
> /*
> @@ -46,14 +37,8 @@ rte_exit(int exit_code, const char *format, ...)
> rte_vlog(RTE_LOG_CRIT, RTE_LOGTYPE_EAL, format, ap);
> va_end(ap);
>
> -#ifndef RTE_EAL_ALWAYS_PANIC_ON_ERROR
> if (rte_eal_cleanup() != 0)
> RTE_LOG(CRIT, EAL,
> "EAL could not release all resources\n");
> exit(exit_code);
> -#else
> - rte_dump_stack();
> - rte_dump_registers();
> - abort();
> -#endif
> }
> diff --git a/lib/librte_eal/include/rte_debug.h
> b/lib/librte_eal/include/rte_debug.h
> index 50052c5a90..c4bc71ce28 100644
> --- a/lib/librte_eal/include/rte_debug.h
> +++ b/lib/librte_eal/include/rte_debug.h
> @@ -26,13 +26,6 @@ extern "C" {
> */
> void rte_dump_stack(void);
>
> -/**
> - * Dump the registers of the calling core to the console.
> - *
> - * Note: Not implemented in a userapp environment; use gdb instead.
> - */
> -void rte_dump_registers(void);
> -
> /**
> * Provide notification of a critical non-recoverable error and terminate
> * execution abnormally.
> diff --git a/lib/librte_eal/rte_eal_version.map
> b/lib/librte_eal/rte_eal_version.map
> index c32461c663..cd1a90b95f 100644
> --- a/lib/librte_eal/rte_eal_ve
Re: [dpdk-dev] [PATCH v8 10/10] buildtools: support python3 only
Hi Kevin, all, 2020-09-28, Kevin Laatz: > Changed script to explicitly use python3 only to avoid > maintaining python 2 and removed deprecation notice. > > Cc: Dmitry Kozlyuk > Cc: Narcisa Ana Maria Vasile > Cc: Dmitry Malloy > Cc: Pallavi Kadam > > Signed-off-by: Kevin Laatz Acked-by: Robin Jarry
Re: [dpdk-dev] [PATCH v8 02/10] usertools/dpdk-devbind: support python3 only
Hi Kevin, all, 2020-09-28, Kevin Laatz: > From: Louise Kilheeney > > Changed script to explicitly use python3 only to avoid > maintaining python 2 and removed deprecation notice. > > Signed-off-by: Louise Kilheeney > Reviewed-by: Bruce Richardson Acked-by: Robin Jarry
Re: [dpdk-dev] [PATCH v8 01/10] usertools/dpdk-telemetry-client: support python3 only
Hi Kevin, all, 2020-09-28, Kevin Laatz: > From: Louise Kilheeney > > Changed script to explicitly use python3 only to avoid > maintaining python 2 and removed deprecation notice. > > Cc: Kevin Laatz > > Signed-off-by: Louise Kilheeney > Signed-off-by: Kevin Laatz > Acked-by: Bruce Richardson Acked-by: Robin Jarry
Re: [dpdk-dev] [PATCH v8 03/10] usertools/dpdk-pmdinfo: support python3 only
Hi Kevin, all, 2020-09-28, Kevin Laatz: > From: Louise Kilheeney > > Changed script to explicitly use python3 only to avoid > maintaining python 2 and removed deprecation notice. > > Cc: Neil Horman > > Signed-off-by: Louise Kilheeney > Reviewed-by: Bruce Richardson > Acked-by: Neil Horman Acked-by: Robin Jarry
Re: [dpdk-dev] [PATCH v8 04/10] usertools/cpu_layout: support python3 only
Hi Kevin, all, 2020-09-28, Kevin Laatz: > From: Louise Kilheeney > > Changed script to explicitly use python3 only to avoid > maintaining python 2 and removed deprecation notice. > > Signed-off-by: Louise Kilheeney > Reviewed-by: Bruce Richardson Acked-by: Robin Jarry
Re: [dpdk-dev] [PATCH v8 05/10] app/test-cmdline: support python3 only
Hi Kevin, all, 2020-09-28, Kevin Laatz: > Changed script to explicitly use python3 only to avoid > maintaining python 2 and removed deprecation notice. > > Cc: Olivier Matz > > Signed-off-by: Louise Kilheeney > Signed-off-by: Kevin Laatz > Reviewed-by: Bruce Richardson > > --- > v5: > - fixed python3 issue causing script to fail. Divisions without the > typecast lead to a floating point result, which was messing up the > loop. > > v6: > - Removed changes to mk/rte.sdktest.mk since it no longer exists. > > v8: > - Replaced integer cast with integer division operator. Acked-by: Robin Jarry
Re: [dpdk-dev] [PATCH v8 00/10] adding support for python 3 only
Hi Kevin, all, 2020-09-28, Kevin Laatz: > This patch set converts all python scripts in the project to use > python3 only and removes all deprecation notices associated with these > changes. This is due to python2 being EOL in January 2020. > > --- > v6: > - rebased, removing conflict with make removal patchset. > - added changes to buildtools/map_to_win.py > > v7: > - typo in email Cc'ing David Marchand > - added maintainers for buildtools patch > > v8: > - removed unrelated cleanup > - replaced integer cast with integer division operator For all patches in the series: Acked-by: Robin Jarry
Re: [dpdk-dev] [dpdk-techboard] [PATCH V5 1/2] dpdk: resolve compiling errors for per-queue stats
>
> On 9/27/2020 4:16 AM, Min Hu (Connor) wrote:
> > From: Huisong Li
> >
> > Currently, only statistics of rx/tx queues with queue_id less than
> > RTE_ETHDEV_QUEUE_STAT_CNTRS can be displayed. If there is a certain
> > application scenario that it needs to use 256 or more than 256 queues
> > and display all statistics of rx/tx queue. At this moment, we have to
> > change the macro to be equaled to the queue number.
> >
> > However, modifying the macro to be greater than 256 will trigger
> > many errors and warnings from test-pmd, PMD drivers and librte_ethdev
> > during compiling dpdk project. But it is possible and permitted that
> > rx/tx queue number is greater than 256 and all statistics of rx/tx
> > queue need to be displayed. In addition, the data type of rx/tx queue
> > number in rte_eth_dev_configure API is 'uint16_t'. So It is unreasonable
> > to use the 'uint8_t' type for variables that control which per-queue
> > statistics can be displayed.
> >
> > Fixes: ed30d9b691b2 ("app/testpmd: add stats per queue")
> > Fixes: 09c7e63a71f9 ("net/memif: introduce memory interface PMD")
> > Fixes: abf7275bbaa2 ("ixgbe: move to drivers/net/")
> > Fixes: e6defdfddc3b ("net/igc: enable statistics")
> > Fixes: 2265e4b4e84b ("net/octeontx2: add basic stats operation")
> > Fixes: 6c3169a3dc04 ("virtio: move to drivers/net/")
> >
> > Signed-off-by: Huisong Li
> > Signed-off-by: Min Hu (Connor)
> > Reviewed-by: Wei Hu (Xavier)
> > Reviewed-by: Dongdong Liu
> > ---
> > V4 -> V5:
> > add release notes updated.
> >
> > ---
> > v3->v4:
> > add a change in cmd_setqmap_mapvalue.
> >
> > ---
> > v2->v3:
> > change 'uint8_t i' to 'uint16_t i' in nic_stats_display function.
> >
> > ---
> > app/proc-info/main.c | 2 +-
> > app/test-pmd/cmdline.c | 4 ++--
> > app/test-pmd/config.c | 4 ++--
> > app/test-pmd/testpmd.c | 2 +-
> > app/test-pmd/testpmd.h | 5 +++--
> > doc/guides/rel_notes/release_20_11.rst | 5 +
> > drivers/net/igc/igc_ethdev.c | 4 ++--
> > drivers/net/ixgbe/ixgbe_ethdev.c | 4 ++--
> > drivers/net/memif/rte_eth_memif.c | 2 +-
> > drivers/net/octeontx2/otx2_ethdev.h| 2 +-
> > drivers/net/octeontx2/otx2_stats.c | 2 +-
> > drivers/net/virtio/virtio_ethdev.c | 4 ++--
> > lib/librte_ethdev/rte_ethdev.c | 6 +++---
> > lib/librte_ethdev/rte_ethdev.h | 4 ++--
> > lib/librte_ethdev/rte_ethdev_driver.h | 2 +-
> > 15 files changed, 29 insertions(+), 23 deletions(-)
> >
> > diff --git a/app/proc-info/main.c b/app/proc-info/main.c
> > index 64fb83b..26d9355 100644
> > --- a/app/proc-info/main.c
> > +++ b/app/proc-info/main.c
> > @@ -348,7 +348,7 @@ static void
> > nic_stats_display(uint16_t port_id)
> > {
> > struct rte_eth_stats stats;
> > - uint8_t i;
> > + uint16_t i;
> >
> > static const char *nic_stats_border = "";
> >
> > diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
> > index 08e123f..23e624f 100644
> > --- a/app/test-pmd/cmdline.c
> > +++ b/app/test-pmd/cmdline.c
> > @@ -8315,7 +8315,7 @@ struct cmd_set_qmap_result {
> > cmdline_fixed_string_t what;
> > portid_t port_id;
> > uint16_t queue_id;
> > - uint8_t map_value;
> > + uint16_t map_value;
> > };
> >
> > static void
> > @@ -8346,7 +8346,7 @@ cmdline_parse_token_num_t cmd_setqmap_queueid =
> > queue_id, UINT16);
> > cmdline_parse_token_num_t cmd_setqmap_mapvalue =
> > TOKEN_NUM_INITIALIZER(struct cmd_set_qmap_result,
> > - map_value, UINT8);
> > + map_value, UINT16);
> >
> > cmdline_parse_inst_t cmd_set_qmap = {
> > .f = cmd_set_qmap_parsed,
> > diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
> > index 17a6efe..dfe5627 100644
> > --- a/app/test-pmd/config.c
> > +++ b/app/test-pmd/config.c
> > @@ -161,7 +161,7 @@ nic_stats_display(portid_t port_id)
> > uint64_t mpps_rx, mpps_tx, mbps_rx, mbps_tx;
> > struct rte_eth_stats stats;
> > struct rte_port *port = &ports[port_id];
> > - uint8_t i;
> > + uint16_t i;
> >
> > static const char *nic_stats_border = "";
> >
> > @@ -3742,7 +3742,7 @@ tx_vlan_pvid_set(portid_t port_id, uint16_t vlan_id,
> > int on)
> > }
> >
> > void
> > -set_qmap(portid_t port_id, uint8_t is_rx, uint16_t queue_id, uint8_t
> > map_value)
> > +set_qmap(portid_t port_id, uint8_t is_rx, uint16_t queue_id, uint16_t
> > map_value)
> > {
> > uint16_t i;
> > uint8_t existing_mapping_found = 0;
> > diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
> > index fe6450c..4b26c5c 100644
> > --- a/app/test-pmd/testpmd.c
> > +++ b/app/test-pmd/testpmd.c
> > @@ -1840,7 +1840,7 @@ fwd_stats_display(void)
> > fwd_cycles += fs->core_cycles;
> > }
> > for (i = 0; i < cur_fwd_config.nb_fwd_ports; i++) {
> > - uint8_t j;
> >
Re: [dpdk-dev] [dpdk-techboard] [PATCH V5 1/2] dpdk: resolve compiling errors for per-queue stats
> 28/09/2020 10:59, Ferruh Yigit: > > On 9/27/2020 4:16 AM, Min Hu (Connor) wrote: > > > From: Huisong Li > > > > > > Currently, only statistics of rx/tx queues with queue_id less than > > > RTE_ETHDEV_QUEUE_STAT_CNTRS can be displayed. If there is a certain > > > application scenario that it needs to use 256 or more than 256 queues > > > and display all statistics of rx/tx queue. At this moment, we have to > > > change the macro to be equaled to the queue number. > > > > > > However, modifying the macro to be greater than 256 will trigger > > > many errors and warnings from test-pmd, PMD drivers and librte_ethdev > > > during compiling dpdk project. But it is possible and permitted that > > > rx/tx queue number is greater than 256 and all statistics of rx/tx > > > queue need to be displayed. In addition, the data type of rx/tx queue > > > number in rte_eth_dev_configure API is 'uint16_t'. So It is unreasonable > > > to use the 'uint8_t' type for variables that control which per-queue > > > statistics can be displayed. > > The explanation is too much complex and misleading. > You mean you cannot increase RTE_ETHDEV_QUEUE_STAT_CNTRS > above 256 because it is an 8-bit type? > > [...] > > > --- a/lib/librte_ethdev/rte_ethdev.h > > > +++ b/lib/librte_ethdev/rte_ethdev.h > > > int rte_eth_dev_set_tx_queue_stats_mapping(uint16_t port_id, > > > - uint16_t tx_queue_id, uint8_t stat_idx); > > > + uint16_t tx_queue_id, uint16_t stat_idx); > [...] > > > int rte_eth_dev_set_rx_queue_stats_mapping(uint16_t port_id, > > > uint16_t rx_queue_id, > > > -uint8_t stat_idx); > > > +uint16_t stat_idx); > [...] > > cc'ed tech-board, > > > > The patch breaks the ethdev ABI without a deprecation notice from previous > > release(s). > > > > It is mainly a fix to the port_id storage type, which we have updated from > > uint8_t to uint16_t in past but some seems remained for > > 'rte_eth_dev_set_tx_queue_stats_mapping()' & > > 'rte_eth_dev_set_rx_queue_stats_mapping()' APIs. > > No, it is not related to the port id, but the number of limited stats.it > it is not limited. In this case, we probably don't need the API > *_queue_stats_mapping which was invented for a limitation of ixgbe. It is probably a bit unusual specially for modern NICs, but I think it still possible in principle. Let say NIC has up to 16K queues, but can map stats only for 1K, or so. So formally - yes, I think both queue_idx and stats_idx have to be same type. Also I can't foresee problems such change could introduce (except formal API/ABI break). So: Acked-by: Konstantin Ananyev > > The problem is probably somewhere else (in testpmd), > that's why I am against this patch. >
Re: [dpdk-dev] [PATCH 1/2] app/testpmd: update Rx RSS HASH offload when setting MQ RSS
Hi, Ferruh Yigit
On 2020/9/23 17:35, Ferruh Yigit wrote:
On 9/23/2020 8:04 AM, Wei Hu (Xavier) wrote:
Hi, Ferruh Yigit
On 2020/9/23 0:21, Ferruh Yigit wrote:
On 9/8/2020 3:16 AM, Wei Hu (Xavier) wrote:
From: Huisong Li
Currently, when starting testpmd application without
'--disable-rss' and
the number of Rx queue configured is greater than 1, ETH_MQ_RX_RSS
flag
is set in port->dev_conf.rxmode.mq_mode in testpmd application, and
DEV_RX_OFFLOAD_RSS_HASH flag is set in rx_offloads
(dev->data->dev_conf.rxmode.offloads) according to the ETH_MQ_RX_RSS
flag of rxmode.mq_mode in PMD drivers.
However, DEV_RX_OFFLOAD_RSS_HASH is not set to rx_offloads maintained
in testpmd application, this will cause the inconsistent problem that
rx_offloads is different for testpmd and PMD drivers.
Yes for DEV_RX_OFFLOAD_RSS_HASH, application rx_offload config and
PMD one diverges, for *some* PMDs.
This is done to have the backward compatibility of the PMD behavior.
The PMDs that would like to write the provide the calculated hash
value back, overwrites the offload config to enable
'DEV_RX_OFFLOAD_RSS_HASH'. And does more work than user requested,
this shouldn't have any side affect.
Some doesn't provide the hash unless user explicitly requests it.
Applications shouldn't set it blindly, at least first check if PMD
supports it but even that case, unless it is needed I think HASH
offload shouldn't be requested by default.
OK, we are going to do modification to add check if PMD support
DEV_RX_OFFLOAD_RSS_HASH before setting it as below:
@@ -3356,11 +3356,13 @@ init_port_config(void)
}
if (port->dcb_flag == 0) {
if (port->dev_conf.rx_adv_conf.rss_conf.rss_hf != 0) {
port->dev_conf.rxmode.mq_mode =
(enum rte_eth_rx_mq_mode)
(rx_mq_mode & ETH_MQ_RX_RSS);
if (port->dev_info.rx_offload_capa &
DEV_RX_OFFLOAD_RSS_HASH)
port->dev_conf.rxmode.offloads |=
DEV_RX_OFFLOAD_RSS_HASH;
} else
port->dev_conf.rxmode.mq_mode = ETH_MQ_RX_NONE;
}
Hi Xavier,
The capability check is correct thing to do, but even in that case I
am not sure if we should set the config by default.
The reason to extract the 'DEV_RX_OFFLOAD_RSS_HASH' offload is to gain
performance for some NICs, enabling it by default defeats the purpose.
The offload should be enabled when application needs the provided hash
value.
I can see you are trying to remove the divergence between PMD and
application config, this can be fixed when all PMDs take this user
offload request into account instead of overwriting, but for some PMDs
it is cheaper to provide the hash value instead of checks, so this
divergence is not easy to address.
OK, please ignore this patch and the V2 patch.
http://patches.dpdk.org/patch/78502/
Thanks.
Regards
Xavier
Re: [dpdk-dev] [PATCH] net/ring: advertise multi segment support.
On 9/28/2020 12:00 PM, Ananyev, Konstantin wrote: On 9/28/2020 8:31 AM, Dumitru Ceara wrote: On 9/22/20 4:21 PM, Ferruh Yigit wrote: On 9/18/2020 11:36 AM, Dumitru Ceara wrote: Even though ring interfaces don't support any other TX/RX offloads they do support sending multi segment packets and this should be advertised in order to not break applications that use ring interfaces. Does ring PMD support sending multi segmented packets? Yes, sending multi segmented packets works fine with ring PMD. Define "works fine" :) All PMDs can put the first mbuf of the chained mbuf to the ring, in that case what is the difference between the ones supports 'DEV_TX_OFFLOAD_MULTI_SEGS' and the ones doesn't support? If the traffic is only from ring PMD to ring PMD, you won't recognize the difference between segmented or not-segmented mbufs, and it will look like segmented packets works fine. But if there is other PMDs involved in the forwarding, or if need to process the packets, will it still work fine? As far as I can see ring PMD doesn't know about the mbuf segments. Right, the PMD doesn't care about the mbuf segments but it implicitly supports sending multi segmented packets. From what I see it's actually the case for most of the PMDs, in the sense that most don't even check the DEV_TX_OFFLOAD_MULTI_SEGS flag and if the application sends multi segment packets they are just accepted. > As far as I can see, if the segmented packets sent, the ring PMD will put the first mbuf into the ring without doing anything specific to the next segments. If the 'DEV_TX_OFFLOAD_MULTI_SEGS' is supported I expect it should detect the segmented packets and put each chained mbuf into the separate field in the ring. Hmm, wonder why do you think this is necessary? From my perspective current behaviour is sufficient for TX-ing multi-seg packets over the ring. I was thinking based on what some PMDs already doing, but right ring may not need to do it. Also for the case, one application is sending multi segmented packets to the ring, and other application pulling packets from the ring and sending to a PMD that does NOT support the multi-seg TX. I thought ring PMD claiming the multi-seg Tx support should serialize packets to support this case, but instead ring claiming 'DEV_RX_OFFLOAD_SCATTER' capability can work by pushing the responsibility to the application. So in this case ring should support both 'DEV_TX_OFFLOAD_MULTI_SEGS' & 'DEV_RX_OFFLOAD_SCATTER', what do you think? However, the fact that the ring PMD doesn't advertise this implicit support forces applications that use ring PMD to have a special case for handling ring interfaces. If the ring PMD would advertise DEV_TX_OFFLOAD_MULTI_SEGS this would allow upper layers to be oblivious to the type of underlying interface. This is not handling the special case for the ring PMD, this is why he have the offload capability flag. Application should behave according capability flags, not per specific PMD. Is there any specific usecase you are trying to cover?
[dpdk-dev] [PATCH] net/fm10k: fix memory leak when thresh check fails
From: Yunjian Wang
In fm10k_rx_queue_setup(), we allocate memory for the queue
structure but not released when thresh check fails.
Fixes: 6cfe8969c969 ("fm10k: add Rx queue setup/release")
Cc: sta...@dpdk.org
Signed-off-by: Yunjian Wang
---
drivers/net/fm10k/fm10k_ethdev.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index 5771d83b5..98e396b8e 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -1841,9 +1841,10 @@ fm10k_rx_queue_setup(struct rte_eth_dev *dev, uint16_t
queue_id,
q->tail_ptr = (volatile uint32_t *)
&((uint32_t *)hw->hw_addr)[FM10K_RDT(queue_id)];
q->offloads = offloads;
- if (handle_rxconf(q, conf))
+ if (handle_rxconf(q, conf)) {
+ rte_free(q);
return -EINVAL;
-
+ }
/* allocate memory for the software ring */
q->sw_ring = rte_zmalloc_socket("fm10k sw ring",
(nb_desc + q->nb_fake_desc) * sizeof(struct rte_mbuf *),
--
2.23.0
Re: [dpdk-dev] [PATCH] net/ring: advertise multi segment support.
On 9/28/2020 12:01 PM, Bruce Richardson wrote: On Mon, Sep 28, 2020 at 11:25:34AM +0100, Ferruh Yigit wrote: On 9/28/2020 8:31 AM, Dumitru Ceara wrote: On 9/22/20 4:21 PM, Ferruh Yigit wrote: On 9/18/2020 11:36 AM, Dumitru Ceara wrote: Even though ring interfaces don't support any other TX/RX offloads they do support sending multi segment packets and this should be advertised in order to not break applications that use ring interfaces. Does ring PMD support sending multi segmented packets? Yes, sending multi segmented packets works fine with ring PMD. Define "works fine" :) All PMDs can put the first mbuf of the chained mbuf to the ring, in that case what is the difference between the ones supports 'DEV_TX_OFFLOAD_MULTI_SEGS' and the ones doesn't support? If the traffic is only from ring PMD to ring PMD, you won't recognize the difference between segmented or not-segmented mbufs, and it will look like segmented packets works fine. But if there is other PMDs involved in the forwarding, or if need to process the packets, will it still work fine? What other PMDs do or don't do should be irrelevant here, I think. The fact that multi-segment PMDs make it though the ring PMD in valid form should be sufficient to mark it as supported. As far as I can see ring PMD doesn't know about the mbuf segments. Right, the PMD doesn't care about the mbuf segments but it implicitly supports sending multi segmented packets. From what I see it's actually the case for most of the PMDs, in the sense that most don't even check the DEV_TX_OFFLOAD_MULTI_SEGS flag and if the application sends multi segment packets they are just accepted. As far as I can see, if the segmented packets sent, the ring PMD will put the first mbuf into the ring without doing anything specific to the next segments. If the 'DEV_TX_OFFLOAD_MULTI_SEGS' is supported I expect it should detect the segmented packets and put each chained mbuf into the separate field in the ring. Why, what would be the advantage of that? Right now if you send in a valid packet chain to the Ring PMD, you get a valid packet chain out again the other side, so I don't see what needs to change about that behaviour. Got it. Konstantin also had similar comment, I have replied there. However, the fact that the ring PMD doesn't advertise this implicit support forces applications that use ring PMD to have a special case for handling ring interfaces. If the ring PMD would advertise DEV_TX_OFFLOAD_MULTI_SEGS this would allow upper layers to be oblivious to the type of underlying interface. This is not handling the special case for the ring PMD, this is why he have the offload capability flag. Application should behave according capability flags, not per specific PMD. Is there any specific usecase you are trying to cover?
Re: [dpdk-dev] [PATCH V14 1/3] ethdev: introduce FEC API
On 9/28/20 2:08 PM, Min Hu (Connor) wrote:
> This patch adds Forward error correction(FEC) support for ethdev.
> Introduce APIs which support query and config FEC information in
> hardware.
>
> Signed-off-by: Min Hu (Connor)
> Reviewed-by: Wei Hu (Xavier)
> Reviewed-by: Chengwen Feng
> Reviewed-by: Chengchang Tang
> Acked-by: Andrew Rybchenko
[snip]
> diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
> index dfe5c1b..996d230 100644
> --- a/lib/librte_ethdev/rte_ethdev.c
> +++ b/lib/librte_ethdev/rte_ethdev.c
> @@ -3679,6 +3679,50 @@ rte_eth_led_off(uint16_t port_id)
> return eth_err(port_id, (*dev->dev_ops->dev_led_off)(dev));
> }
>
> +int
> +rte_eth_fec_get_capability(uint16_t port_id,
> +struct rte_eth_fec_capa *speed_fec_capa,
> +unsigned int num)
> +{
> + struct rte_eth_dev *dev;
> + int ret;
> +
> + if (speed_fec_capa == NULL && num > 0)
> + return -EINVAL;
> +
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> + dev = &rte_eth_devices[port_id];
> + RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->fec_get_capability, -ENOTSUP);
> + ret = (*dev->dev_ops->fec_get_capability)(dev, speed_fec_capa, num);
> +
> + return ret;
> +}
> +
> +int
> +rte_eth_fec_get(uint16_t port_id, uint32_t *fec_capa)
> +{
> + struct rte_eth_dev *dev;
> +
> + if (fec_capa == NULL)
> + return -EINVAL;
> +
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> + dev = &rte_eth_devices[port_id];
> + RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->fec_get, -ENOTSUP);
> + return eth_err(port_id, (*dev->dev_ops->fec_get)(dev, fec_capa));
> +}
> +
> +int
> +rte_eth_fec_set(uint16_t port_id, uint32_t mode)
mode -> fec_capa, since it is not a single mode
> +{
> + struct rte_eth_dev *dev;
> +
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> + dev = &rte_eth_devices[port_id];
> + RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->fec_set, -ENOTSUP);
> + return eth_err(port_id, (*dev->dev_ops->fec_set)(dev, mode));
> +}
> +
> /*
> * Returns index into MAC address array of addr. Use 00:00:00:00:00:00 to
> find
> * an empty spot.
> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
> index 645a186..50c5280 100644
> --- a/lib/librte_ethdev/rte_ethdev.h
> +++ b/lib/librte_ethdev/rte_ethdev.h
[snip]
> @@ -3397,6 +3420,85 @@ int rte_eth_led_on(uint16_t port_id);
> int rte_eth_led_off(uint16_t port_id);
>
> /**
> + * @warning
> + * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
> + *
> + * Get Forward Error Correction(FEC) capability.
> + *
> + * @param port_id
> + * The port identifier of the Ethernet device.
> + * @param speed_fec_capa
> + * speed_fec_capa is out only with per-speed capabilities.
> + * If set to NULL, the function returns the required number
> + * of required array entries.
> + * @param num
> + * a number of elements in an speed_fec_capa array.
> + *
> + * @return
> + * - A positive value lower or equal to num: success. The return value
positive -> non-negative
since 0 is OK if FEC is not applicable/supported
> + * is the number of entries filled in the fec capa array.
> + * - A positive value higher than num: error, the given fec capa array
same, positive -> non-negative
> + * is too small. The return value corresponds to the num that should
> + * be given to succeed. The entries in fec capa array are not valid and
> + * shall not be used by the caller.
OK for me, possible option is to fill in just provided entries
(up to num)
> + * - (-ENOTSUP) if underlying hardware OR driver doesn't support.
> + * that operation.
> + * - (-EIO) if device is removed.
> + * - (-ENODEV) if *port_id* invalid.
> + * - (-EINVAL) if *num* or *speed_fec_capa* invalid
> + */
> +__rte_experimental
> +int rte_eth_fec_get_capability(uint16_t port_id,
> +struct rte_eth_fec_capa *speed_fec_capa,
> +unsigned int num);
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
> + *
> + * Get current Forward Error Correction(FEC) mode.
> + * If link is down and AUTO is enabled, AUTO is returned, otherwise,
> + * configured FEC mode is returned.
> + * If link is up, current FEC mode is returned.
> + *
> + * @param port_id
> + * The port identifier of the Ethernet device.
> + * @param fec_capa
> + * A bitmask of enabled FEC modes. If AUTO bit is set, other
> + * bits specify FEC modes which may be negotiated. If AUTO
> + * bit is clear, specify FEC modes to be used (only one valid
> + * mode per speed may be set).
> + * @return
> + * - (0) if successful.
> + * - (-ENOTSUP) if underlying hardware OR driver doesn't support.
> + * that operation.
> + * - (-EIO) if device is removed.
> + * - (-ENODEV) if *port_id* invalid.
> + */
> +__rte_experiment
