[dpdk-dev] [Bug 522] Performance degradation on AWS ena driver
https://bugs.dpdk.org/show_bug.cgi?id=522 Bug ID: 522 Summary: Performance degradation on AWS ena driver Product: DPDK Version: 19.11 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: ethdev Assignee: dev@dpdk.org Reporter: tudor.cor...@gmail.com Target Milestone: --- Created attachment 115 --> https://bugs.dpdk.org/attachment.cgi?id=115&action=edit AWS ena comparison between 18.11 and 19.11 Greetings, I ran a test with DPDK 19.11 over the AWS ena driver, and seem to get lower performance than with the previous release, 18.11 It seems that more CPU is being spent in ena_com_prepare_tx,compared to the previous release. I have attached a file, containing more detailed measurements OS: Ubuntu 18 AWS Instance Type: C5.4xlarge DPDK 19.11 + pktgen 19.12 Tx Rate: 1800 Mbits/s 18.11 + Pktgen 3.7.0 Tx Rate: 400 Mbits/s Could somebody confirm if there is indeed a degradation between builds, and point me to a possible fix ? Thanks, Tudor -- You are receiving this mail because: You are the assignee for the bug.
[dpdk-dev] [PATCH] Virtio TX: reverting a small change causing Virtio standard TX broken
Virtio Standard TX broken : Reverting a small change added few months back
which has caused breakage in Virtio Standard TX path.
During basic ping Tx/Rx testing of net_virtio pmd driver using standard Tx
path, We saw TX is broken since anomaly code added by below patch once submitted
http://git.dpdk.org/dpdk/patch/?id=57f90f89458807bccc63425e4b72796870177977
Signed-off-by: Vipul Ashri
---
drivers/net/virtio/virtqueue.h | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/virtio/virtqueue.h b/drivers/net/virtio/virtqueue.h
index 105a9c00c..81118d9fb 100644
--- a/drivers/net/virtio/virtqueue.h
+++ b/drivers/net/virtio/virtqueue.h
@@ -607,10 +607,8 @@ virtqueue_notify(struct virtqueue *vq)
/* avoid write operation when necessary, to lessen cache issues */
#define ASSIGN_UNLESS_EQUAL(var, val) do { \
- typeof(var) var_ = (var); \
- typeof(val) val_ = (val); \
- if ((var_) != (val_)) \
- (var_) = (val_);\
+ if ((var) != (val)) \
+ (var) = (val); \
} while (0)
#define virtqueue_clear_net_hdr(hdr) do { \
--
2.28.0.windows.1
Re: [dpdk-dev] [PATCH v3] doc: update RSS action with best effort
Hi Andrew, > -Original Message- > From: Andrew Rybchenko > > On 8/7/20 8:02 AM, Ori Kam wrote: > > Using the rte_flow action RSS types field, > > may result in undefined outcome. > > > > For example selecting both UDP and TCP, > > selecting TCP RSS type but the pattern is targeting UDP traffic. > > another option is that the PMD doesn't support all requested types. > > > > Until now, it wasn't clear what will happen in such cases. > > This commit clarify this issue by stating that the PMD > > will work in the best-effort mode, and will fail > > in case the requested type is not supported. > > > > Signed-off-by: Ori Kam > > --- > > v3: > > * Address ML comments. > > > > v2: > > * Address ML comments. > > --- > > doc/guides/prog_guide/rte_flow.rst | 12 > > 1 file changed, 12 insertions(+) > > > > diff --git a/doc/guides/prog_guide/rte_flow.rst > b/doc/guides/prog_guide/rte_flow.rst > > index 3e5cd1e..eada283 100644 > > --- a/doc/guides/prog_guide/rte_flow.rst > > +++ b/doc/guides/prog_guide/rte_flow.rst > > @@ -1735,6 +1735,18 @@ unspecified "best-effort" settings from the > underlying PMD, which depending > > on the flow rule, may result in anything ranging from empty (single queue) > > to all-inclusive RSS. > > > > +In case there are Non-applicable RSS types in the rule, > > +Best effort will be used. > > +This may be the result of: > > + > > +- Setting both UDP and TCP on the same rule. > > + > > +- Setting RSS types that don't match the requested pattern, > > + for example, matching on UDP and hashing RSS on TCP. > > + > > +If requested RSS hash type is not supported in ``dev_info``. > > +The flow creation will fail. > > + > > Consider: > If non-applicable for matching packets RSS types are requested, > these RSS types are simply ignored. For example, it happens if: > > - Hashing of both TCP and UDP ports is requested > (only one can present in a packet). > > - Requested RSS types contradict to flow rule pattern > (e.g. pattern has UDP item, but RSS types contain TCP). > > If requested RSS types are not supported by the Ethernet device > at all (not reported in ``dev_info.flow_type_rss_offloads``), > the flow creation will fail. > Sure sounds good, but since this is just copying your words, I will add your Signed-off-by to this patch, is that O.K? > > Note: RSS hash result is stored in the ``hash.rss`` mbuf field which > > overlaps ``hash.fdir.lo``. Since `Action: MARK`_ sets the ``hash.fdir.hi`` > > field only, both can be requested simultaneously. > >
Re: [dpdk-dev] Userspace testing
On 03-Aug-20 3:31 PM, Owen Hilyard wrote: On Fri, Jul 31, 2020 at 5:12 AM Burakov, Anatoly mailto:anatoly.bura...@intel.com>> wrote: On 30-Jul-20 5:54 PM, Owen Hilyard wrote: > Thanks for the advice. > > I was wondering about the state of the "Setup VFIO permissions" option > in the setup script. It seems to just modify the character device's > permissions and then check their memory limit. Should this option also > handle the hugepages setup? I was under the (mis?)impression that the hugepage setup part of the script did that? It doesn't appear to set them up so that non-root users can use them. From what I can tell it only creates the pages, but doesn't change permissions on them in any way. Right. Then, it probably should (or perhaps it should be added as another menu option, as probably not everyone would want to do a chmod/chown on hugepage mounts). -- Thanks, Anatoly
[dpdk-dev] [PATCH] doc: clarify abi reference version to use in patches
Clarify the ABI reference version (DPDK_ABI_REF_VERSION) tag, to use when testing builds with devtools/test_build[_meson].sh before submitting patches. Signed-off-by: Ray Kinsella --- doc/guides/contributing/patches.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst index de493a9..877d2e2 100644 --- a/doc/guides/contributing/patches.rst +++ b/doc/guides/contributing/patches.rst @@ -532,7 +532,8 @@ Checking ABI compatibility By default, ABI compatibility checks are disabled. To enable them, a reference version must be selected via the environment -variable ``DPDK_ABI_REF_VERSION``. +variable ``DPDK_ABI_REF_VERSION``. Contributors should ordinarily reference the +git tag of most recent release of DPDK in DPDK_ABI_REF_VERSION. The ``devtools/test-build.sh`` and ``devtools/test-meson-builds.sh`` scripts then build this reference version in a temporary directory and store the -- 2.7.4
Re: [dpdk-dev] [PATCH] doc: scheduler API deprecation notice
I see there are 3 ACKs: original (see the commit message) from Fan, then Thomas and Akhil. This page: http://patches.dpdk.org/project/dpdk/list/?series=11317 also shows it has 3 ACKs. Can I ask why it didn't go into 20.08 then? Adam > -Original Message- > From: Thomas Monjalon > Sent: Saturday, 8 August, 2020 00:05 > To: Dybkowski, AdamX > Cc: dev@dpdk.org; Trahe, Fiona ; Zhang, Roy Fan > ; step...@networkplumber.org; Burakov, > Anatoly ; bl...@debian.org; Akhil Goyal > > Subject: Re: [dpdk-dev] [PATCH] doc: scheduler API deprecation notice > > 06/08/2020 19:18, Akhil Goyal: > > > 27/07/2020 11:41, Adam Dybkowski: > > > > This patch adds a deprecation notice about upcoming changes in > > > > public API of the Scheduler PMD. > > > > > > > > Signed-off-by: Adam Dybkowski > > > > Acked-by: Fan Zhang > > > > --- > > > > +* scheduler: The functions > > > > +``rte_cryptodev_scheduler_slave_attach``, > > > > + ``rte_cryptodev_scheduler_slave_detach`` and > > > > + ``rte_cryptodev_scheduler_slaves_get`` will be replaced in > > > > +20.11 by > > > > + ``rte_cryptodev_scheduler_worker_attach``, > > > > + ``rte_cryptodev_scheduler_worker_detach`` and > > > > + ``rte_cryptodev_scheduler_workers_get`` accordingly. > > > > > > Acked-by: Thomas Monjalon > > > > > I wonder how this patch got missed. > > > > Acked-by: Akhil Goyal > > Sorry it is missing an ack. > >
Re: [dpdk-dev] [PATCH 20.11 00/12] add max SIMD bitwidth to EAL
Hi Stephen, To give an overview of the rationale behind the patchset: - It allows other apps such as OVS and VPP which already make use of AVX-512 to indicate that they are happy for DPDK to use AVX-512 too. - It allows the end-user to override those settings if so desired. - It allows an easy way for the user to test with different vector paths by limiting bitwidths. I can add some documentation for this in a v2, thanks for the suggestion. - Ciara >-Original Message- >From: Stephen Hemminger >Sent: Friday 7 August 2020 17:19 >To: Power, Ciara >Cc: dev@dpdk.org; Richardson, Bruce >Subject: Re: [dpdk-dev] [PATCH 20.11 00/12] add max SIMD bitwidth to EAL > >On Fri, 7 Aug 2020 16:58:47 +0100 >Ciara Power wrote: > >> A number of components in DPDK have optional AVX-512 or other vector >> code paths which can be selected at runtime. Rather than having each >> component provide its own mechanism to select a code path, this >> patchset adds support for a single setting to control what code paths are >used. >> This can be used to enable some non-default code paths e.g. ones using >> AVX-512, but also to limit the code paths to certain vector widths, or >> to scalar code only, which is useful for testing. >> >> The max SIMD bitwidth setting can be set by the app itself through use >> of the available API, or can be overriden by a commandline argument >> passed by the user. >> >> Ciara Power (12): >> eal: add max SIMD bitwidth >> eal: add default SIMD bitwidth values >> net/i40e: add checks for max SIMD bitwidth >> net/axgbe: add checks for max SIMD bitwidth >> net/bnxt: add checks for max SIMD bitwidth >> net/enic: add checks for max SIMD bitwidth >> net/fm10k: add checks for max SIMD bitwidth >> net/iavf: add checks for max SIMD bitwidth >> net/ice: add checks for max SIMD bitwidth >> net/ixgbe: add checks for max SIMD bitwidth >> net/mlx5: add checks for max SIMD bitwidth >> net/virtio: add checks for max SIMD bitwidth >> >> drivers/net/axgbe/axgbe_rxtx.c | 3 +- >> drivers/net/bnxt/bnxt_ethdev.c | 6 ++- >> drivers/net/enic/enic_rxtx_vec_avx2.c | 3 +- >> drivers/net/fm10k/fm10k_ethdev.c | 11 ++-- >> drivers/net/i40e/i40e_rxtx.c | 19 --- >> drivers/net/iavf/iavf_rxtx.c | 16 +++--- >> drivers/net/ice/ice_rxtx.c | 20 --- >> drivers/net/ixgbe/ixgbe_rxtx.c | 7 ++- >> drivers/net/mlx5/mlx5_ethdev.c | 3 +- >> drivers/net/virtio/virtio_ethdev.c | 12 +++-- >> lib/librte_eal/arm/include/rte_vect.h | 2 + >> lib/librte_eal/common/eal_common_options.c | 63 >++ >> lib/librte_eal/common/eal_internal_cfg.h | 8 +++ >> lib/librte_eal/common/eal_options.h| 2 + >> lib/librte_eal/include/generic/rte_vect.h | 2 + >> lib/librte_eal/include/rte_eal.h | 31 +++ >> lib/librte_eal/ppc/include/rte_vect.h | 2 + >> lib/librte_eal/rte_eal_version.map | 4 ++ >> lib/librte_eal/x86/include/rte_vect.h | 2 + >> 19 files changed, 184 insertions(+), 32 deletions(-) >> > >This looks useful, could you add some documentation on rationale and how >you expect application to set it.
Re: [dpdk-dev] [PATCH v3] doc: update RSS action with best effort
On 8/10/20 10:40 AM, Ori Kam wrote: > Hi Andrew, > > >> -Original Message- >> From: Andrew Rybchenko >> >> On 8/7/20 8:02 AM, Ori Kam wrote: >>> Using the rte_flow action RSS types field, >>> may result in undefined outcome. >>> >>> For example selecting both UDP and TCP, >>> selecting TCP RSS type but the pattern is targeting UDP traffic. >>> another option is that the PMD doesn't support all requested types. >>> >>> Until now, it wasn't clear what will happen in such cases. >>> This commit clarify this issue by stating that the PMD >>> will work in the best-effort mode, and will fail >>> in case the requested type is not supported. >>> >>> Signed-off-by: Ori Kam >>> --- >>> v3: >>> * Address ML comments. >>> >>> v2: >>> * Address ML comments. >>> --- >>> doc/guides/prog_guide/rte_flow.rst | 12 >>> 1 file changed, 12 insertions(+) >>> >>> diff --git a/doc/guides/prog_guide/rte_flow.rst >> b/doc/guides/prog_guide/rte_flow.rst >>> index 3e5cd1e..eada283 100644 >>> --- a/doc/guides/prog_guide/rte_flow.rst >>> +++ b/doc/guides/prog_guide/rte_flow.rst >>> @@ -1735,6 +1735,18 @@ unspecified "best-effort" settings from the >> underlying PMD, which depending >>> on the flow rule, may result in anything ranging from empty (single queue) >>> to all-inclusive RSS. >>> >>> +In case there are Non-applicable RSS types in the rule, >>> +Best effort will be used. >>> +This may be the result of: >>> + >>> +- Setting both UDP and TCP on the same rule. >>> + >>> +- Setting RSS types that don't match the requested pattern, >>> + for example, matching on UDP and hashing RSS on TCP. >>> + >>> +If requested RSS hash type is not supported in ``dev_info``. >>> +The flow creation will fail. >>> + >> Consider: >> If non-applicable for matching packets RSS types are requested, >> these RSS types are simply ignored. For example, it happens if: >> >> - Hashing of both TCP and UDP ports is requested >> (only one can present in a packet). >> >> - Requested RSS types contradict to flow rule pattern >> (e.g. pattern has UDP item, but RSS types contain TCP). >> >> If requested RSS types are not supported by the Ethernet device >> at all (not reported in ``dev_info.flow_type_rss_offloads``), >> the flow creation will fail. >> > Sure sounds good, but since this is just copying your words, > I will add your Signed-off-by to this patch, is that O.K? OK >>> Note: RSS hash result is stored in the ``hash.rss`` mbuf field which >>> overlaps ``hash.fdir.lo``. Since `Action: MARK`_ sets the ``hash.fdir.hi`` >>> field only, both can be requested simultaneously. >>>
Re: [dpdk-dev] [PATCH] doc: scheduler API deprecation notice
10/08/2020 11:47, Dybkowski, AdamX: > I see there are 3 ACKs: original (see the commit message) from Fan, then > Thomas and Akhil. > This page: http://patches.dpdk.org/project/dpdk/list/?series=11317 > also shows it has 3 ACKs. Sorry I missed initial ack. > Can I ask why it didn't go into 20.08 then? Because it was completed late, I missed and nobody replied. In general, I would like more support in last days of release, to avoid such miss. > From: Thomas Monjalon > > 06/08/2020 19:18, Akhil Goyal: > > > > 27/07/2020 11:41, Adam Dybkowski: > > > > > This patch adds a deprecation notice about upcoming changes in > > > > > public API of the Scheduler PMD. > > > > > > > > > > Signed-off-by: Adam Dybkowski > > > > > Acked-by: Fan Zhang > > > > > --- > > > > > +* scheduler: The functions > > > > > +``rte_cryptodev_scheduler_slave_attach``, > > > > > + ``rte_cryptodev_scheduler_slave_detach`` and > > > > > + ``rte_cryptodev_scheduler_slaves_get`` will be replaced in > > > > > +20.11 by > > > > > + ``rte_cryptodev_scheduler_worker_attach``, > > > > > + ``rte_cryptodev_scheduler_worker_detach`` and > > > > > + ``rte_cryptodev_scheduler_workers_get`` accordingly. > > > > > > > > Acked-by: Thomas Monjalon > > > > > > > I wonder how this patch got missed. > > > > > > Acked-by: Akhil Goyal > > > > Sorry it is missing an ack.
[dpdk-dev] [PATCH] net/octeontx2: fix multi seg mode for jumbo packets
Scatter gather mode should get enabled:
- If mbuf size is less than max received packet length.
- MTU is reconfigured greater than mbuf size.
Fixes: 0e2efd02db58 ("net/octeontx2: add MTU set operation")
Cc: sta...@dpdk.org
Signed-off-by: Harman Kalra
---
drivers/net/octeontx2/otx2_ethdev.c | 30 +
drivers/net/octeontx2/otx2_ethdev.h | 2 ++
drivers/net/octeontx2/otx2_ethdev_ops.c | 9 +---
3 files changed, 33 insertions(+), 8 deletions(-)
diff --git a/drivers/net/octeontx2/otx2_ethdev.c
b/drivers/net/octeontx2/otx2_ethdev.c
index 33b72bd4d..bee1e2a76 100644
--- a/drivers/net/octeontx2/otx2_ethdev.c
+++ b/drivers/net/octeontx2/otx2_ethdev.c
@@ -657,6 +657,9 @@ otx2_nix_rx_queue_setup(struct rte_eth_dev *eth_dev,
uint16_t rq,
}
}
+ /* Setup scatter mode if needed by jumbo */
+ otx2_nix_enable_mseg_on_jumbo(rxq);
+
return 0;
free_rxq:
@@ -878,6 +881,33 @@ nix_sqb_unlock(struct rte_mempool *mp)
return 0;
}
+void
+otx2_nix_enable_mseg_on_jumbo(struct otx2_eth_rxq *rxq)
+{
+ struct rte_pktmbuf_pool_private *mbp_priv;
+ struct rte_eth_dev *eth_dev;
+ struct otx2_eth_dev *dev;
+ uint32_t buffsz;
+
+ eth_dev = rxq->eth_dev;
+ dev = otx2_eth_pmd_priv(eth_dev);
+
+ /* Get rx buffer size */
+ mbp_priv = rte_mempool_get_priv(rxq->pool);
+ buffsz = mbp_priv->mbuf_data_room_size - RTE_PKTMBUF_HEADROOM;
+
+ if (eth_dev->data->dev_conf.rxmode.max_rx_pkt_len > buffsz) {
+ dev->rx_offloads |= DEV_RX_OFFLOAD_SCATTER;
+ dev->tx_offloads |= DEV_TX_OFFLOAD_MULTI_SEGS;
+
+ /* Setting up the rx[tx]_offload_flags due to change
+* in rx[tx]_offloads.
+*/
+ dev->rx_offload_flags |= nix_rx_offload_flags(eth_dev);
+ dev->tx_offload_flags |= nix_tx_offload_flags(eth_dev);
+ }
+}
+
static int
nix_sq_init(struct otx2_eth_txq *txq)
{
diff --git a/drivers/net/octeontx2/otx2_ethdev.h
b/drivers/net/octeontx2/otx2_ethdev.h
index e9efe52bb..11cdd8afd 100644
--- a/drivers/net/octeontx2/otx2_ethdev.h
+++ b/drivers/net/octeontx2/otx2_ethdev.h
@@ -437,6 +437,8 @@ int otx2_nix_set_mc_addr_list(struct rte_eth_dev *eth_dev,
/* MTU */
int otx2_nix_mtu_set(struct rte_eth_dev *eth_dev, uint16_t mtu);
int otx2_nix_recalc_mtu(struct rte_eth_dev *eth_dev);
+void otx2_nix_enable_mseg_on_jumbo(struct otx2_eth_rxq *rxq);
+
/* Link */
void otx2_nix_toggle_flag_link_cfg(struct otx2_eth_dev *dev, bool set);
diff --git a/drivers/net/octeontx2/otx2_ethdev_ops.c
b/drivers/net/octeontx2/otx2_ethdev_ops.c
index faecf216c..b36d37b9f 100644
--- a/drivers/net/octeontx2/otx2_ethdev_ops.c
+++ b/drivers/net/octeontx2/otx2_ethdev_ops.c
@@ -72,22 +72,15 @@ otx2_nix_mtu_set(struct rte_eth_dev *eth_dev, uint16_t mtu)
int
otx2_nix_recalc_mtu(struct rte_eth_dev *eth_dev)
{
- struct otx2_eth_dev *dev = otx2_eth_pmd_priv(eth_dev);
struct rte_eth_dev_data *data = eth_dev->data;
- struct rte_pktmbuf_pool_private *mbp_priv;
struct otx2_eth_rxq *rxq;
- uint32_t buffsz;
uint16_t mtu;
int rc;
- /* Get rx buffer size */
rxq = data->rx_queues[0];
- mbp_priv = rte_mempool_get_priv(rxq->pool);
- buffsz = mbp_priv->mbuf_data_room_size - RTE_PKTMBUF_HEADROOM;
/* Setup scatter mode if needed by jumbo */
- if (data->dev_conf.rxmode.max_rx_pkt_len > buffsz)
- dev->rx_offloads |= DEV_RX_OFFLOAD_SCATTER;
+ otx2_nix_enable_mseg_on_jumbo(rxq);
/* Setup MTU based on max_rx_pkt_len */
mtu = data->dev_conf.rxmode.max_rx_pkt_len - NIX_L2_OVERHEAD;
--
2.18.0
Re: [dpdk-dev] [PATCH] doc: scheduler API deprecation notice
Sorry about that Thomas, Akhil, we should have chased up acks sooner. Given the proposed content of the patch, and the similar changes that are recommended and agreed throughout DPDK do you think an exception can be made and that this change can get into 20.11 even without the deprecation notice being in 20.08? > -Original Message- > From: Thomas Monjalon > Sent: Monday, August 10, 2020 11:19 AM > To: Dybkowski, AdamX > Cc: dev@dpdk.org; Trahe, Fiona ; Zhang, Roy Fan > ; > step...@networkplumber.org; Burakov, Anatoly ; > bl...@debian.org; > Akhil Goyal ; Richardson, Bruce > ; Mcnamara, John > > Subject: Re: [dpdk-dev] [PATCH] doc: scheduler API deprecation notice > > 10/08/2020 11:47, Dybkowski, AdamX: > > I see there are 3 ACKs: original (see the commit message) from Fan, then > > Thomas and Akhil. > > This page: http://patches.dpdk.org/project/dpdk/list/?series=11317 > > also shows it has 3 ACKs. > > Sorry I missed initial ack. > > > Can I ask why it didn't go into 20.08 then? > > Because it was completed late, I missed and nobody replied. > > In general, I would like more support in last days of release, > to avoid such miss. > > > > From: Thomas Monjalon > > > 06/08/2020 19:18, Akhil Goyal: > > > > > 27/07/2020 11:41, Adam Dybkowski: > > > > > > This patch adds a deprecation notice about upcoming changes in > > > > > > public API of the Scheduler PMD. > > > > > > > > > > > > Signed-off-by: Adam Dybkowski > > > > > > Acked-by: Fan Zhang > > > > > > --- > > > > > > +* scheduler: The functions > > > > > > +``rte_cryptodev_scheduler_slave_attach``, > > > > > > + ``rte_cryptodev_scheduler_slave_detach`` and > > > > > > + ``rte_cryptodev_scheduler_slaves_get`` will be replaced in > > > > > > +20.11 by > > > > > > + ``rte_cryptodev_scheduler_worker_attach``, > > > > > > + ``rte_cryptodev_scheduler_worker_detach`` and > > > > > > + ``rte_cryptodev_scheduler_workers_get`` accordingly. > > > > > > > > > > Acked-by: Thomas Monjalon > > > > > > > > > I wonder how this patch got missed. > > > > > > > > Acked-by: Akhil Goyal > > > > > > Sorry it is missing an ack. > >
Re: [dpdk-dev] [PATCH] doc: scheduler API deprecation notice
10/08/2020 13:49, Trahe, Fiona: > Sorry about that Thomas, Akhil, we should have chased up acks sooner. > > Given the proposed content of the patch, and the similar changes that are > recommended and agreed > throughout DPDK do you think an exception can be made and that this change > can get into 20.11 even > without the deprecation notice being in 20.08? That's a question for techboard. PS: please avoid top-posting > From: Thomas Monjalon > > 10/08/2020 11:47, Dybkowski, AdamX: > > > I see there are 3 ACKs: original (see the commit message) from Fan, then > > > Thomas and Akhil. > > > This page: http://patches.dpdk.org/project/dpdk/list/?series=11317 > > > also shows it has 3 ACKs. > > > > Sorry I missed initial ack. > > > > > Can I ask why it didn't go into 20.08 then? > > > > Because it was completed late, I missed and nobody replied. > > > > In general, I would like more support in last days of release, > > to avoid such miss. > > > > > > > From: Thomas Monjalon > > > > 06/08/2020 19:18, Akhil Goyal: > > > > > > 27/07/2020 11:41, Adam Dybkowski: > > > > > > > This patch adds a deprecation notice about upcoming changes in > > > > > > > public API of the Scheduler PMD. > > > > > > > > > > > > > > Signed-off-by: Adam Dybkowski > > > > > > > Acked-by: Fan Zhang > > > > > > > --- > > > > > > > +* scheduler: The functions > > > > > > > +``rte_cryptodev_scheduler_slave_attach``, > > > > > > > + ``rte_cryptodev_scheduler_slave_detach`` and > > > > > > > + ``rte_cryptodev_scheduler_slaves_get`` will be replaced in > > > > > > > +20.11 by > > > > > > > + ``rte_cryptodev_scheduler_worker_attach``, > > > > > > > + ``rte_cryptodev_scheduler_worker_detach`` and > > > > > > > + ``rte_cryptodev_scheduler_workers_get`` accordingly. > > > > > > > > > > > > Acked-by: Thomas Monjalon > > > > > > > > > > > I wonder how this patch got missed. > > > > > > > > > > Acked-by: Akhil Goyal > > > > > > > > Sorry it is missing an ack. > > > > > >
[dpdk-dev] [RFC] eal: introduce function to get lcore thread id
Introduce function in to retrieve a lcore worker
thread's pthread id.
This change allows applications to do things like changing the name of
a lcore thread, or detect if it's getting interrupted (e.g. getting
preempted by another thread).
Signed-off-by: Mattias Rönnblom
---
lib/librte_eal/common/eal_common_thread.c | 8
lib/librte_eal/include/rte_lcore.h| 14 ++
lib/librte_eal/rte_eal_version.map| 3 +++
3 files changed, 25 insertions(+)
diff --git a/lib/librte_eal/common/eal_common_thread.c
b/lib/librte_eal/common/eal_common_thread.c
index 73a055902..6233aef11 100644
--- a/lib/librte_eal/common/eal_common_thread.c
+++ b/lib/librte_eal/common/eal_common_thread.c
@@ -294,3 +294,11 @@ rte_thread_unregister(void)
RTE_LOG(DEBUG, EAL, "Unregistered non-EAL thread (was lcore
%u).\n",
lcore_id);
}
+
+int rte_lcore_thread_id(unsigned int lcore_id, pthread_t *id)
+{
+ if (lcore_id >= RTE_MAX_LCORE)
+ return -1;
+ *id = lcore_config[lcore_id].thread_id;
+ return 0;
+}
diff --git a/lib/librte_eal/include/rte_lcore.h
b/lib/librte_eal/include/rte_lcore.h
index b8b64a625..dae8d11ca 100644
--- a/lib/librte_eal/include/rte_lcore.h
+++ b/lib/librte_eal/include/rte_lcore.h
@@ -363,6 +363,20 @@ int rte_thread_set_affinity(rte_cpuset_t *cpusetp);
*/
void rte_thread_get_affinity(rte_cpuset_t *cpusetp);
+/**
+ * Get the thread id of a lcore worker thread.
+ *
+ * @param lcore_id
+ * The identifier of the lcore, which MUST be between 0 and RTE_MAX_LCORE-1.
+ * @param[out] id
+ * A pointer that will be filled in with the lcore worker thread's POSIX
+ * thread id, on success.
+ * @return
+ * On success, return 0; otherwise return a negative value.
+ */
+__rte_experimental
+int rte_lcore_thread_id(unsigned int lcore_id, pthread_t *id);
+
/**
* Set thread names.
*
diff --git a/lib/librte_eal/rte_eal_version.map
b/lib/librte_eal/rte_eal_version.map
index bf0c17c23..571aacd17 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -403,6 +403,9 @@ EXPERIMENTAL {
rte_mp_disable;
rte_thread_register;
rte_thread_unregister;
+
+ # added in 20.11
+ rte_lcore_thread_id;
};
INTERNAL {
--
2.25.1
[dpdk-dev] [Bug 523] vhost iotlb cache incorrectly assumes to be single consumer
https://bugs.dpdk.org/show_bug.cgi?id=523 Bug ID: 523 Summary: vhost iotlb cache incorrectly assumes to be single consumer Product: DPDK Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: vhost/virtio Assignee: dev@dpdk.org Reporter: eup...@gmail.com Target Milestone: --- Using testpmd as a vhost-user with iommu: /home/dpdk/build/app/dpdk-testpmd -l 1,3 --vdev net_vhost0,iface=/tmp/vhost-user1,queues=1,iommu-support=1 -- --auto-start --stats-period 5 --forward-mode=txonly And qemu with packed virtqueue: ... -- Is it possible to consume the iotlb's entries of the mempoo from different threads. Thread sanitizer output: WARNING: ThreadSanitizer: data race (pid=76927) Write of size 8 at 0x00017ffd5628 by thread T5: #0 vhost_user_iotlb_cache_insert ../lib/librte_vhost/iotlb.c:181 (dpdk-testpmd+0x769343) #1 vhost_user_iotlb_msg ../lib/librte_vhost/vhost_user.c:2380 (dpdk-testpmd+0x78e4bf) #2 vhost_user_msg_handler ../lib/librte_vhost/vhost_user.c:2848 (dpdk-testpmd+0x78fcf8) #3 vhost_user_read_cb ../lib/librte_vhost/socket.c:311 (dpdk-testpmd+0x770162) #4 fdset_event_dispatch ../lib/librte_vhost/fd_man.c:286 (dpdk-testpmd+0x7591c2) #5 ctrl_thread_init ../lib/librte_eal/common/eal_common_thread.c:193 (dpdk-testpmd+0xa2890b) #6 (libtsan.so.0+0x2a68d) Previous read of size 8 at 0x00017ffd5628 by thread T3: #0 vhost_user_iotlb_cache_find ../lib/librte_vhost/iotlb.c:252 (dpdk-testpmd+0x76ee96) #1 __vhost_iova_to_vva ../lib/librte_vhost/vhost.c:42 (dpdk-testpmd+0x77488c) #2 vhost_iova_to_vva ../lib/librte_vhost/vhost.h:753 (dpdk-testpmd+0x7abeb3) #3 map_one_desc ../lib/librte_vhost/virtio_net.c:497 (dpdk-testpmd+0x7abeb3) #4 fill_vec_buf_packed ../lib/librte_vhost/virtio_net.c:751 (dpdk-testpmd+0x7abeb3) #5 vhost_enqueue_single_packed ../lib/librte_vhost/virtio_net.c:1170 (dpdk-testpmd+0x7abeb3) #6 virtio_dev_rx_single_packed ../lib/librte_vhost/virtio_net.c:1346 (dpdk-testpmd+0x7abeb3) #7 virtio_dev_rx_packed ../lib/librte_vhost/virtio_net.c:1384 (dpdk-testpmd+0x7abeb3) #8 virtio_dev_rx ../lib/librte_vhost/virtio_net.c:1435 (dpdk-testpmd+0x7b0654) #9 rte_vhost_enqueue_burst ../lib/librte_vhost/virtio_net.c:1465 (dpdk-testpmd+0x7b0654) #10 eth_vhost_tx ../drivers/net/vhost/rte_eth_vhost.c:470 (dpdk-testpmd+0x1ddfbd8) #11 rte_eth_tx_burst ../lib/librte_ethdev/rte_ethdev.h:4800 (dpdk-testpmd+0x505fdb) #12 pkt_burst_transmit ../app/test-pmd/txonly.c:365 (dpdk-testpmd+0x5106ad) #13 run_pkt_fwd_on_lcore ../app/test-pmd/testpmd.c:2080 (dpdk-testpmd+0x4f8951) #14 start_pkt_forward_on_core ../app/test-pmd/testpmd.c:2106 (dpdk-testpmd+0x4f89d7) #15 eal_thread_loop ../lib/librte_eal/linux/eal_thread.c:127 (dpdk-testpmd+0xa5b20a) #16 (libtsan.so.0+0x2a68d) Location is global '' at 0x (rtemap_0+0x3ffd5628) Thread T5 'vhost-events' (tid=76933, running) created by main thread at: #0 pthread_create (libtsan.so.0+0x2cd42) #1 rte_ctrl_thread_create ../lib/librte_eal/common/eal_common_thread.c:216 (dpdk-testpmd+0xa289e7) #2 rte_vhost_driver_start ../lib/librte_vhost/socket.c:1190 (dpdk-testpmd+0x7728ef) #3 vhost_driver_setup ../drivers/net/vhost/rte_eth_vhost.c:1028 (dpdk-testpmd+0x1de233d) #4 eth_dev_configure ../drivers/net/vhost/rte_eth_vhost.c:1126 (dpdk-testpmd+0x1de29cc) #5 rte_eth_dev_configure ../lib/librte_ethdev/rte_ethdev.c:1439 (dpdk-testpmd+0x991ce2) #6 start_port ../app/test-pmd/testpmd.c:2450 (dpdk-testpmd+0x4f9b45) #7 main ../app/test-pmd/testpmd.c:3777 (dpdk-testpmd+0x4fe1ac) Thread T3 'lcore-slave-3' (tid=76931, running) created by main thread at: #0 pthread_create (libtsan.so.0+0x2cd42) #1 rte_eal_init ../lib/librte_eal/linux/eal.c:1244 (dpdk-testpmd+0xa46e2b) #2 main ../app/test-pmd/testpmd.c:3673 (dpdk-testpmd+0x4fdd75) -- Or: WARNING: ThreadSanitizer: data race (pid=76927) Write of size 1 at 0x00017ffd00f8 by thread T5: #0 vhost_user_iotlb_cache_insert ../lib/librte_vhost/iotlb.c:182 (dpdk-testpmd+0x769370) #1 vhost_user_iotlb_msg ../lib/librte_vhost/vhost_user.c:2380 (dpdk-testpmd+0x78e4bf) #2 vhost_user_msg_handler ../lib/librte_vhost/vhost_user.c:2848 (dpdk-testpmd+0x78fcf8) #3 vhost_user_read_cb ../lib/librte_vhost/socket.c:311 (dpdk-testpmd+0x770162) #4 fdset_event_dispatch ../lib/librte_vhost/fd_man.c:286 (dpdk-testpmd+0x7591c2) #5 ctrl_thread_init ../lib/librte_eal/common/eal_common_thread.c:193 (dpdk-testpmd+0xa2890b) #6 (libtsan.so.0+0x2a68d) Previous write of size 1 at 0x00017ffd00f8 by thread T3: #0 vhost_user_iotlb_pending_insert ../lib/librte_vhost/iotlb.c:86 (dpdk-testpmd+0x75eb0c) #1 __vhost_iova_to_vva .
[dpdk-dev] [PATCH 1/1] vhost: fix iotlb mempool single-consumer flag
Bugzilla bug: 523 Using testpmd as a vhost-user with iommu: /home/dpdk/build/app/dpdk-testpmd -l 1,3 \ --vdev net_vhost0,iface=/tmp/vhost-user1,queues=1,iommu-support=1 \ -- --auto-start --stats-period 5 --forward-mode=txonly And qemu with packed virtqueue: ... -- Is it possible to consume the iotlb's entries of the mempoo from different threads. Thread sanitizer example output (after change rwlocks to POSIX ones): WARNING: ThreadSanitizer: data race (pid=76927) Write of size 8 at 0x00017ffd5628 by thread T5: #0 vhost_user_iotlb_cache_insert ../lib/librte_vhost/iotlb.c:181 (dpdk-testpmd+0x769343) #1 vhost_user_iotlb_msg ../lib/librte_vhost/vhost_user.c:2380 (dpdk-testpmd+0x78e4bf) #2 vhost_user_msg_handler ../lib/librte_vhost/vhost_user.c:2848 (dpdk-testpmd+0x78fcf8) #3 vhost_user_read_cb ../lib/librte_vhost/socket.c:311 (dpdk-testpmd+0x770162) #4 fdset_event_dispatch ../lib/librte_vhost/fd_man.c:286 (dpdk-testpmd+0x7591c2) #5 ctrl_thread_init ../lib/librte_eal/common/eal_common_thread.c:193 (dpdk-testpmd+0xa2890b) #6 (libtsan.so.0+0x2a68d) Previous read of size 8 at 0x00017ffd5628 by thread T3: #0 vhost_user_iotlb_cache_find ../lib/librte_vhost/iotlb.c:252 (dpdk-testpmd+0x76ee96) #1 __vhost_iova_to_vva ../lib/librte_vhost/vhost.c:42 (dpdk-testpmd+0x77488c) #2 vhost_iova_to_vva ../lib/librte_vhost/vhost.h:753 (dpdk-testpmd+0x7abeb3) #3 map_one_desc ../lib/librte_vhost/virtio_net.c:497 (dpdk-testpmd+0x7abeb3) #4 fill_vec_buf_packed ../lib/librte_vhost/virtio_net.c:751 (dpdk-testpmd+0x7abeb3) #5 vhost_enqueue_single_packed ../lib/librte_vhost/virtio_net.c:1170 (dpdk-testpmd+0x7abeb3) #6 virtio_dev_rx_single_packed ../lib/librte_vhost/virtio_net.c:1346 (dpdk-testpmd+0x7abeb3) #7 virtio_dev_rx_packed ../lib/librte_vhost/virtio_net.c:1384 (dpdk-testpmd+0x7abeb3) #8 virtio_dev_rx ../lib/librte_vhost/virtio_net.c:1435 (dpdk-testpmd+0x7b0654) #9 rte_vhost_enqueue_burst ../lib/librte_vhost/virtio_net.c:1465 (dpdk-testpmd+0x7b0654) #10 eth_vhost_tx ../drivers/net/vhost/rte_eth_vhost.c:470 (dpdk-testpmd+0x1ddfbd8) #11 rte_eth_tx_burst ../lib/librte_ethdev/rte_ethdev.h:4800 (dpdk-testpmd+0x505fdb) #12 pkt_burst_transmit ../app/test-pmd/txonly.c:365 (dpdk-testpmd+0x5106ad) #13 run_pkt_fwd_on_lcore ../app/test-pmd/testpmd.c:2080 (dpdk-testpmd+0x4f8951) #14 start_pkt_forward_on_core ../app/test-pmd/testpmd.c:2106 (dpdk-testpmd+0x4f89d7) #15 eal_thread_loop ../lib/librte_eal/linux/eal_thread.c:127 (dpdk-testpmd+0xa5b20a) #16 (libtsan.so.0+0x2a68d) Location is global '' at 0x (rtemap_0+0x3ffd5628) Thread T5 'vhost-events' (tid=76933, running) created by main thread at: #0 pthread_create (libtsan.so.0+0x2cd42) #1 rte_ctrl_thread_create ../lib/librte_eal/common/eal_common_thread.c:216 (dpdk-testpmd+0xa289e7) #2 rte_vhost_driver_start ../lib/librte_vhost/socket.c:1190 (dpdk-testpmd+0x7728ef) #3 vhost_driver_setup ../drivers/net/vhost/rte_eth_vhost.c:1028 (dpdk-testpmd+0x1de233d) #4 eth_dev_configure ../drivers/net/vhost/rte_eth_vhost.c:1126 (dpdk-testpmd+0x1de29cc) #5 rte_eth_dev_configure ../lib/librte_ethdev/rte_ethdev.c:1439 (dpdk-testpmd+0x991ce2) #6 start_port ../app/test-pmd/testpmd.c:2450 (dpdk-testpmd+0x4f9b45) #7 main ../app/test-pmd/testpmd.c:3777 (dpdk-testpmd+0x4fe1ac) Thread T3 'lcore-slave-3' (tid=76931, running) created by main thread at: #0 pthread_create (libtsan.so.0+0x2cd42) #1 rte_eal_init ../lib/librte_eal/linux/eal.c:1244 (dpdk-testpmd+0xa46e2b) #2 main ../app/test-pmd/testpmd.c:3673 (dpdk-testpmd+0x4fdd75) -- Or: WARNING: ThreadSanitizer: data race (pid=76927) Write of size 1 at 0x00017ffd00f8 by thread T5: #0 vhost_user_iotlb_cache_insert ../lib/librte_vhost/iotlb.c:182 (dpdk-testpmd+0x769370) #1 vhost_user_iotlb_msg ../lib/librte_vhost/vhost_user.c:2380 (dpdk-testpmd+0x78e4bf) #2 vhost_user_msg_handler ../lib/librte_vhost/vhost_user.c:2848 (dpdk-testpmd+0x78fcf8) #3 vhost_user_read_cb ../lib/librte_vhost/socket.c:311 (dpdk-testpmd+0x770162) #4 fdset_event_dispatch ../lib/librte_vhost/fd_man.c:286 (dpdk-testpmd+0x7591c2) #5 ctrl_thread_init ../lib/librte_eal/common/eal_common_thread.c:193 (dpdk-testpmd+0xa2890b) #6 (libtsan.so.0+0x2a68d) Previous write of size 1 at 0x00017ffd00f8 by thread T3: #0 vhost_user_iotlb_pending_insert ../lib/librte_vhost/iotlb.c:86 (dpdk-testpmd+0x75eb0c) #1 __vhost_iova_to_vva ../lib/librte_vhost/vhost.c:58 (dpdk-testpmd+0x774926) #2 vhost_iova_to_vva ../lib/librte_vhost/vhost.h:753 (dpdk-testpmd+0x7a79d1) #3 virtio_dev_rx_batch_packed ../lib/librte_vhost/virtio_net.c:1295 (dpdk-testpmd+0x7a79d1) #4 virtio_dev_rx_packed ../lib/librte_vhost/virtio_net.c:1376 (dpdk-testpmd+0x7a79d1) #5 virtio_dev_rx ../lib/librte_vhost/virtio_n
[dpdk-dev] [PATCH 0/1] vhost: fix iotlb mempool single-consumer flag
Bugzilla bug: 523 Using testpmd as a vhost-user with iommu: /home/dpdk/build/app/dpdk-testpmd -l 1,3 \ --vdev net_vhost0,iface=/tmp/vhost-user1,queues=1,iommu-support=1 \ -- --auto-start --stats-period 5 --forward-mode=txonly And qemu with packed virtqueue: ... -- Is it possible to consume the iotlb's entries of the mempoo from different threads. Thread sanitizer example output (after change rwlocks to POSIX ones): WARNING: ThreadSanitizer: data race (pid=76927) Write of size 8 at 0x00017ffd5628 by thread T5: #0 vhost_user_iotlb_cache_insert ../lib/librte_vhost/iotlb.c:181 (dpdk-testpmd+0x769343) #1 vhost_user_iotlb_msg ../lib/librte_vhost/vhost_user.c:2380 (dpdk-testpmd+0x78e4bf) #2 vhost_user_msg_handler ../lib/librte_vhost/vhost_user.c:2848 (dpdk-testpmd+0x78fcf8) #3 vhost_user_read_cb ../lib/librte_vhost/socket.c:311 (dpdk-testpmd+0x770162) #4 fdset_event_dispatch ../lib/librte_vhost/fd_man.c:286 (dpdk-testpmd+0x7591c2) #5 ctrl_thread_init ../lib/librte_eal/common/eal_common_thread.c:193 (dpdk-testpmd+0xa2890b) #6 (libtsan.so.0+0x2a68d) Previous read of size 8 at 0x00017ffd5628 by thread T3: #0 vhost_user_iotlb_cache_find ../lib/librte_vhost/iotlb.c:252 (dpdk-testpmd+0x76ee96) #1 __vhost_iova_to_vva ../lib/librte_vhost/vhost.c:42 (dpdk-testpmd+0x77488c) #2 vhost_iova_to_vva ../lib/librte_vhost/vhost.h:753 (dpdk-testpmd+0x7abeb3) #3 map_one_desc ../lib/librte_vhost/virtio_net.c:497 (dpdk-testpmd+0x7abeb3) #4 fill_vec_buf_packed ../lib/librte_vhost/virtio_net.c:751 (dpdk-testpmd+0x7abeb3) #5 vhost_enqueue_single_packed ../lib/librte_vhost/virtio_net.c:1170 (dpdk-testpmd+0x7abeb3) #6 virtio_dev_rx_single_packed ../lib/librte_vhost/virtio_net.c:1346 (dpdk-testpmd+0x7abeb3) #7 virtio_dev_rx_packed ../lib/librte_vhost/virtio_net.c:1384 (dpdk-testpmd+0x7abeb3) #8 virtio_dev_rx ../lib/librte_vhost/virtio_net.c:1435 (dpdk-testpmd+0x7b0654) #9 rte_vhost_enqueue_burst ../lib/librte_vhost/virtio_net.c:1465 (dpdk-testpmd+0x7b0654) #10 eth_vhost_tx ../drivers/net/vhost/rte_eth_vhost.c:470 (dpdk-testpmd+0x1ddfbd8) #11 rte_eth_tx_burst ../lib/librte_ethdev/rte_ethdev.h:4800 (dpdk-testpmd+0x505fdb) #12 pkt_burst_transmit ../app/test-pmd/txonly.c:365 (dpdk-testpmd+0x5106ad) #13 run_pkt_fwd_on_lcore ../app/test-pmd/testpmd.c:2080 (dpdk-testpmd+0x4f8951) #14 start_pkt_forward_on_core ../app/test-pmd/testpmd.c:2106 (dpdk-testpmd+0x4f89d7) #15 eal_thread_loop ../lib/librte_eal/linux/eal_thread.c:127 (dpdk-testpmd+0xa5b20a) #16 (libtsan.so.0+0x2a68d) Location is global '' at 0x (rtemap_0+0x3ffd5628) Thread T5 'vhost-events' (tid=76933, running) created by main thread at: #0 pthread_create (libtsan.so.0+0x2cd42) #1 rte_ctrl_thread_create ../lib/librte_eal/common/eal_common_thread.c:216 (dpdk-testpmd+0xa289e7) #2 rte_vhost_driver_start ../lib/librte_vhost/socket.c:1190 (dpdk-testpmd+0x7728ef) #3 vhost_driver_setup ../drivers/net/vhost/rte_eth_vhost.c:1028 (dpdk-testpmd+0x1de233d) #4 eth_dev_configure ../drivers/net/vhost/rte_eth_vhost.c:1126 (dpdk-testpmd+0x1de29cc) #5 rte_eth_dev_configure ../lib/librte_ethdev/rte_ethdev.c:1439 (dpdk-testpmd+0x991ce2) #6 start_port ../app/test-pmd/testpmd.c:2450 (dpdk-testpmd+0x4f9b45) #7 main ../app/test-pmd/testpmd.c:3777 (dpdk-testpmd+0x4fe1ac) Thread T3 'lcore-slave-3' (tid=76931, running) created by main thread at: #0 pthread_create (libtsan.so.0+0x2cd42) #1 rte_eal_init ../lib/librte_eal/linux/eal.c:1244 (dpdk-testpmd+0xa46e2b) #2 main ../app/test-pmd/testpmd.c:3673 (dpdk-testpmd+0x4fdd75) -- Or: WARNING: ThreadSanitizer: data race (pid=76927) Write of size 1 at 0x00017ffd00f8 by thread T5: #0 vhost_user_iotlb_cache_insert ../lib/librte_vhost/iotlb.c:182 (dpdk-testpmd+0x769370) #1 vhost_user_iotlb_msg ../lib/librte_vhost/vhost_user.c:2380 (dpdk-testpmd+0x78e4bf) #2 vhost_user_msg_handler ../lib/librte_vhost/vhost_user.c:2848 (dpdk-testpmd+0x78fcf8) #3 vhost_user_read_cb ../lib/librte_vhost/socket.c:311 (dpdk-testpmd+0x770162) #4 fdset_event_dispatch ../lib/librte_vhost/fd_man.c:286 (dpdk-testpmd+0x7591c2) #5 ctrl_thread_init ../lib/librte_eal/common/eal_common_thread.c:193 (dpdk-testpmd+0xa2890b) #6 (libtsan.so.0+0x2a68d) Previous write of size 1 at 0x00017ffd00f8 by thread T3: #0 vhost_user_iotlb_pending_insert ../lib/librte_vhost/iotlb.c:86 (dpdk-testpmd+0x75eb0c) #1 __vhost_iova_to_vva ../lib/librte_vhost/vhost.c:58 (dpdk-testpmd+0x774926) #2 vhost_iova_to_vva ../lib/librte_vhost/vhost.h:753 (dpdk-testpmd+0x7a79d1) #3 virtio_dev_rx_batch_packed ../lib/librte_vhost/virtio_net.c:1295 (dpdk-testpmd+0x7a79d1) #4 virtio_dev_rx_packed ../lib/librte_vhost/virtio_net.c:1376 (dpdk-testpmd+0x7a79d1) #5 virtio_dev_rx ../lib/librte_vhost/virtio_n
[dpdk-dev] [PATCH v4] doc: update RSS action with best effort
Using the rte_flow action RSS types field, may result in undefined outcome. For example selecting both UDP and TCP, selecting TCP RSS type but the pattern is targeting UDP traffic. another option is that the PMD doesn't support all requested types. Until now, it wasn't clear what will happen in such cases. This commit clarify this issue by stating that the PMD will work in the best-effort mode, and will fail in case the requested type is not supported. Signed-off-by: Ori Kam Signed-off-by: Andrew Rybchenko --- doc/guides/prog_guide/rte_flow.rst | 13 + 1 file changed, 13 insertions(+) diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst index 3e5cd1e..944e824 100644 --- a/doc/guides/prog_guide/rte_flow.rst +++ b/doc/guides/prog_guide/rte_flow.rst @@ -1735,6 +1735,19 @@ unspecified "best-effort" settings from the underlying PMD, which depending on the flow rule, may result in anything ranging from empty (single queue) to all-inclusive RSS. +If non-applicable for matching packets RSS types are requested, +these RSS types are simply ignored. For example, it happens if: + +- Hashing of both TCP and UDP ports is requested + (only one can present in a packet). + +- Requested RSS types contradict to flow rule pattern + (e.g. pattern has UDP item, but RSS types contain TCP). + +If requested RSS hash types are not supported by the Ethernet device at all +(not reported in ``dev_info.flow_tpe_rss_offloads``), +the flow creation will fail. + Note: RSS hash result is stored in the ``hash.rss`` mbuf field which overlaps ``hash.fdir.lo``. Since `Action: MARK`_ sets the ``hash.fdir.hi`` field only, both can be requested simultaneously. -- 1.8.3.1
[dpdk-dev] [PATCH] version: 20.11-rc0
Start a new release cycle with empty release notes.
ABI check is disabled in 20.11 cycle.
Signed-off-by: Thomas Monjalon
---
.travis.yml| 26 -
ABI_VERSION| 2 +-
VERSION| 2 +-
doc/guides/rel_notes/index.rst | 1 +
doc/guides/rel_notes/release_20_11.rst | 136 +
5 files changed, 139 insertions(+), 28 deletions(-)
create mode 100644 doc/guides/rel_notes/release_20_11.rst
diff --git a/.travis.yml b/.travis.yml
index 14f8124233..d6eeab371d 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -2,9 +2,6 @@
language: c
cache:
ccache: true
- directories:
-- libabigail
-- reference
dist: bionic
@@ -21,9 +18,6 @@ _aarch64_packages: &aarch64_packages
- *required_packages
- [gcc-aarch64-linux-gnu, libc6-dev-arm64-cross,
pkg-config-aarch64-linux-gnu]
-_libabigail_build_packages: &libabigail_build_packages
- - [autoconf, automake, libtool, pkg-config, libxml2-dev, libdw-dev]
-
_build_32b_packages: &build_32b_packages
- *required_packages
- [gcc-multilib]
@@ -34,10 +28,6 @@ _doc_packages: &doc_packages
before_install: ./.ci/${TRAVIS_OS_NAME}-setup.sh
script: ./.ci/${TRAVIS_OS_NAME}-build.sh
-env:
- global:
-- REF_GIT_TAG=v20.05
-
jobs:
include:
# x86_64 gcc jobs
@@ -55,14 +45,6 @@ jobs:
packages:
- *required_packages
- *doc_packages
- - env: DEF_LIB="shared" ABI_CHECKS=1
-arch: amd64
-compiler: gcc
-addons:
- apt:
-packages:
- - *required_packages
- - *libabigail_build_packages
# x86_64 clang jobs
- env: DEF_LIB="static"
arch: amd64
@@ -116,14 +98,6 @@ jobs:
packages:
- *required_packages
- *doc_packages
- - env: DEF_LIB="shared" ABI_CHECKS=1
-arch: arm64
-compiler: gcc
-addons:
- apt:
-packages:
- - *required_packages
- - *libabigail_build_packages
# aarch64 clang jobs
- env: DEF_LIB="static"
arch: arm64
diff --git a/ABI_VERSION b/ABI_VERSION
index a9ac8dacb0..0ffaf17a11 100644
--- a/ABI_VERSION
+++ b/ABI_VERSION
@@ -1 +1 @@
-20.0.3
+20.0.4
diff --git a/VERSION b/VERSION
index 85e33446f8..8b0beab16a 100644
--- a/VERSION
+++ b/VERSION
@@ -1 +1 @@
-20.08.0
+20.11.0
diff --git a/doc/guides/rel_notes/index.rst b/doc/guides/rel_notes/index.rst
index 05c9d837a4..fb70d1a5f3 100644
--- a/doc/guides/rel_notes/index.rst
+++ b/doc/guides/rel_notes/index.rst
@@ -8,6 +8,7 @@ Release Notes
:maxdepth: 1
:numbered:
+release_20_11
release_20_08
release_20_05
release_20_02
diff --git a/doc/guides/rel_notes/release_20_11.rst
b/doc/guides/rel_notes/release_20_11.rst
new file mode 100644
index 00..df227a1773
--- /dev/null
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -0,0 +1,136 @@
+.. SPDX-License-Identifier: BSD-3-Clause
+ Copyright 2020 The DPDK contributors
+
+.. include::
+
+DPDK Release 20.11
+==
+
+.. **Read this first.**
+
+ The text in the sections below explains how to update the release notes.
+
+ Use proper spelling, capitalization and punctuation in all sections.
+
+ Variable and config names should be quoted as fixed width text:
+ ``LIKE_THIS``.
+
+ Build the docs and view the output file to ensure the changes are correct::
+
+ make doc-guides-html
+ xdg-open build/doc/html/guides/rel_notes/release_20_11.html
+
+
+New Features
+
+
+.. This section should contain new features added in this release.
+ Sample format:
+
+ * **Add a title in the past tense with a full stop.**
+
+ Add a short 1-2 sentence description in the past tense.
+ The description should be enough to allow someone scanning
+ the release notes to understand the new feature.
+
+ If the feature adds a lot of sub-features you can use a bullet list
+ like this:
+
+ * Added feature foo to do something.
+ * Enhanced feature bar to do something else.
+
+ Refer to the previous release notes for examples.
+
+ Suggested order in release notes items:
+ * Core libs (EAL, mempool, ring, mbuf, buses)
+ * Device abstraction libs and PMDs
+ - ethdev (lib, PMDs)
+ - cryptodev (lib, PMDs)
+ - eventdev (lib, PMDs)
+ - etc
+ * Other libs
+ * Apps, Examples, Tools (if significant)
+
+ This section is a comment. Do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ ===
+
+
+Removed Items
+-
+
+.. This section should contain removed items in this release. Sample format:
+
+ * Add a short 1-2 sentence description of the removed item
+ in the past tense.
+
+ This section is a comment. Do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ ===
+
+
+API Changes
Re: [dpdk-dev] [PATCH 20.11 11/12] net/mlx5: add checks for max SIMD bitwidth
> -Original Message-
> From: dev On Behalf Of Ciara Power
> Sent: Friday, August 7, 2020 11:59
> To: dev@dpdk.org
> Cc: bruce.richard...@intel.com; Ciara Power ; Matan
> Azrad ; Shahaf Shuler ;
> Viacheslav Ovsiienko
> Subject: [dpdk-dev] [PATCH 20.11 11/12] net/mlx5: add checks for max SIMD
> bitwidth
>
> When choosing a vector path to take, an extra condition must be satisfied to
> ensure the max SIMD bitwidth allows for the CPU enabled path.
>
> Cc: Matan Azrad
> Cc: Shahaf Shuler
> Cc: Viacheslav Ovsiienko
>
> Signed-off-by: Ciara Power
> ---
> drivers/net/mlx5/mlx5_ethdev.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
> index cefb45064e..f322f82029 100644
> --- a/drivers/net/mlx5/mlx5_ethdev.c
> +++ b/drivers/net/mlx5/mlx5_ethdev.c
> @@ -479,7 +479,8 @@ mlx5_select_rx_function(struct rte_eth_dev *dev)
> eth_rx_burst_t rx_pkt_burst = mlx5_rx_burst;
>
> MLX5_ASSERT(dev != NULL);
> - if (mlx5_check_vec_rx_support(dev) > 0) {
> + if (mlx5_check_vec_rx_support(dev) > 0 &&
> + rte_get_max_simd_bitwidth() >= RTE_MAX_128_SIMD)
> {
> rx_pkt_burst = mlx5_rx_burst_vec;
> DRV_LOG(DEBUG, "port %u selected Rx vectorized function",
> dev->data->port_id);
> --
> 2.17.1
Hi Ciara, what do you think about moving this condition inside the
mlx5_check_vec_rx_support() function?
[dpdk-dev] [PATCH] net/ixgbe: fix fdir flows with RTE_FLOW_ITEM_TYPE_RAW
Flows like IP4 / UDP / RAW are not working because after parsing
RTE_FLOW_ITEM_TYPE_RAW item pointer is not advanced. This make whole
parsing fail.
Fixes: f35fec63dde1 ("net/ixgbe: enable flex bytes for generic flow API")
Cc: qi.z.zh...@intel.com
Signed-off-by: Pawel Wodkowski
---
drivers/net/ixgbe/ixgbe_flow.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ixgbe/ixgbe_flow.c b/drivers/net/ixgbe/ixgbe_flow.c
index b2a2bfc02..a2cb599b1 100644
--- a/drivers/net/ixgbe/ixgbe_flow.c
+++ b/drivers/net/ixgbe/ixgbe_flow.c
@@ -2251,6 +2251,8 @@ ixgbe_parse_fdir_filter_normal(struct rte_eth_dev *dev,
(((uint16_t)raw_spec->pattern[1]) << 8) |
raw_spec->pattern[0];
rule->flex_bytes_offset = raw_spec->offset;
+
+ item = next_no_fuzzy_pattern(pattern, item);
}
if (item->type != RTE_FLOW_ITEM_TYPE_END) {
--
2.17.1
[dpdk-dev] [PATCH v2] tracepoint: fix compilation with C++
trace_mem is declared as 'void *' which triggers following error:
'...invalid conversion from ‘void*’ to ‘__rte_trace_header*’
[-fpermissive]...'
Fix this by adding proper typecast to 'struct __rte_trace_header *'.
Signed-off-by: Pawel Wodkowski
Fixes: ebaee6409702 ("trace: simplify trace point headers")
Cc: david.march...@redhat.com
---
lib/librte_eal/include/rte_trace_point.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/include/rte_trace_point.h
b/lib/librte_eal/include/rte_trace_point.h
index b45171275..875de195a 100644
--- a/lib/librte_eal/include/rte_trace_point.h
+++ b/lib/librte_eal/include/rte_trace_point.h
@@ -300,13 +300,13 @@ RTE_DECLARE_PER_LCORE(void *, trace_mem);
static __rte_always_inline void *
__rte_trace_mem_get(uint64_t in)
{
- struct __rte_trace_header *trace = RTE_PER_LCORE(trace_mem);
+ struct __rte_trace_header *trace = (struct __rte_trace_header
*)RTE_PER_LCORE(trace_mem);
const uint16_t sz = in & __RTE_TRACE_FIELD_SIZE_MASK;
/* Trace memory is not initialized for this thread */
if (unlikely(trace == NULL)) {
__rte_trace_mem_per_thread_alloc();
- trace = RTE_PER_LCORE(trace_mem);
+ trace = (struct __rte_trace_header *) RTE_PER_LCORE(trace_mem);
if (unlikely(trace == NULL))
return NULL;
}
--
2.17.1
[dpdk-dev] [PATCH v3 1/1] vfio: modify spapr iommu support to use static window sizing
The SPAPR IOMMU requires that a DMA window size be defined before memory
can be mapped for DMA. Current code dynamically modifies the DMA window
size in response to every new memory allocation which is potentially
dangerous because all existing mappings need to be unmapped/remapped in
order to resize the DMA window, leaving hardware holding IOVA addresses
that are temporarily unmapped. The new SPAPR code statically assigns
the DMA window size on first use, using the largest physical memory
memory address when IOVA=PA and the highest existing memseg virtual
address when IOVA=VA.
Signed-off-by: David Christensen
---
lib/librte_eal/linux/eal_vfio.c | 412 ++--
1 file changed, 186 insertions(+), 226 deletions(-)
diff --git a/lib/librte_eal/linux/eal_vfio.c b/lib/librte_eal/linux/eal_vfio.c
index e07979936..4456761fc 100644
--- a/lib/librte_eal/linux/eal_vfio.c
+++ b/lib/librte_eal/linux/eal_vfio.c
@@ -18,6 +18,7 @@
#include "eal_memcfg.h"
#include "eal_vfio.h"
#include "eal_private.h"
+#include "eal_internal_cfg.h"
#ifdef VFIO_PRESENT
@@ -536,17 +537,6 @@ vfio_mem_event_callback(enum rte_mem_event type, const
void *addr, size_t len,
return;
}
-#ifdef RTE_ARCH_PPC_64
- ms = rte_mem_virt2memseg(addr, msl);
- while (cur_len < len) {
- int idx = rte_fbarray_find_idx(&msl->memseg_arr, ms);
-
- rte_fbarray_set_free(&msl->memseg_arr, idx);
- cur_len += ms->len;
- ++ms;
- }
- cur_len = 0;
-#endif
/* memsegs are contiguous in memory */
ms = rte_mem_virt2memseg(addr, msl);
@@ -607,17 +597,6 @@ vfio_mem_event_callback(enum rte_mem_event type, const
void *addr, size_t len,
iova_expected - iova_start, 0);
}
}
-#ifdef RTE_ARCH_PPC_64
- cur_len = 0;
- ms = rte_mem_virt2memseg(addr, msl);
- while (cur_len < len) {
- int idx = rte_fbarray_find_idx(&msl->memseg_arr, ms);
-
- rte_fbarray_set_used(&msl->memseg_arr, idx);
- cur_len += ms->len;
- ++ms;
- }
-#endif
}
static int
@@ -1433,21 +1412,30 @@ vfio_type1_dma_map(int vfio_container_fd)
return rte_memseg_walk(type1_map, &vfio_container_fd);
}
+/* Track the size of the statically allocated DMA window for SPAPR */
+uint64_t spapr_dma_win_len;
+uint64_t spapr_dma_win_page_sz;
+
static int
vfio_spapr_dma_do_map(int vfio_container_fd, uint64_t vaddr, uint64_t iova,
uint64_t len, int do_map)
{
- struct vfio_iommu_type1_dma_map dma_map;
- struct vfio_iommu_type1_dma_unmap dma_unmap;
- int ret;
struct vfio_iommu_spapr_register_memory reg = {
.argsz = sizeof(reg),
+ .vaddr = (uintptr_t) vaddr,
+ .size = len,
.flags = 0
};
- reg.vaddr = (uintptr_t) vaddr;
- reg.size = len;
+ int ret;
if (do_map != 0) {
+ struct vfio_iommu_type1_dma_map dma_map;
+
+ if (iova + len > spapr_dma_win_len) {
+ RTE_LOG(ERR, EAL, " dma map attempt outside DMA
window\n");
+ return -1;
+ }
+
ret = ioctl(vfio_container_fd,
VFIO_IOMMU_SPAPR_REGISTER_MEMORY, ®);
if (ret) {
@@ -1466,24 +1454,14 @@ vfio_spapr_dma_do_map(int vfio_container_fd, uint64_t
vaddr, uint64_t iova,
ret = ioctl(vfio_container_fd, VFIO_IOMMU_MAP_DMA, &dma_map);
if (ret) {
- /**
-* In case the mapping was already done EBUSY will be
-* returned from kernel.
-*/
- if (errno == EBUSY) {
- RTE_LOG(DEBUG, EAL,
- " Memory segment is already mapped,"
- " skipping");
- } else {
- RTE_LOG(ERR, EAL,
- " cannot set up DMA remapping,"
- " error %i (%s)\n", errno,
- strerror(errno));
- return -1;
- }
+ RTE_LOG(ERR, EAL, " cannot map vaddr for IOMMU, "
+ "error %i (%s)\n", errno, strerror(errno));
+ return -1;
}
} else {
+ struct vfio_iommu_type1_dma_map dma_unmap;
+
memset(&dma_unmap, 0, sizeof(dma_unmap));
dma_unmap.argsz = sizeof(struct vfio_iommu_type1_dma_unmap);
dma_unmap.size = len;
@@ -1492,21 +1470,21 @@ vfio_spapr_dma_do_map(int vfio_container_fd, uint64_t
vaddr, uint64_t iova,
ret = ioctl(vf
[dpdk-dev] [PATCH v3 0/1] vfio: change spapr DMA window sizing operation
The SPAPR v2 IOMMU used on bare-metal PowerNV systems requires that a DMA window be defined before mapping/unmapping memory. The current VFIO code dynamically resizes this DMA window every time a new memory request is made, which requires that all existing memory be unmapped/remapped. While this strategy worked in DPDK 17.11 and earlier where memory was statically allocated during startup, it is potentially dangerous in DPDK 18.11 and later where memory can be allocated during runtime, temporarily invalidating IOVA memory used by hardware. This new code statically sizes the DMA window at startup, based on the amount of memory installed in the system, avoiding the need to unmap memory during runtime. --- v3: - Rebase for 20.08 v2: - Drop patch to wrap ppc64 code with ifdef's - Add warning when external memory detected - Change VA memory size detection to scan memseg list when setting DMA window for IOVA=VA - Add explicit error message when attempting to map outside the DMA window David Christensen (1): vfio: modify spapr iommu support to use static window sizing lib/librte_eal/linux/eal_vfio.c | 412 ++-- 1 file changed, 186 insertions(+), 226 deletions(-) -- 2.18.4
Re: [dpdk-dev] [PATCH v2] net/virtio: fix 57f90f8("net/virtio: reuse packed ring functions")
Hi Vipul,
> -Original Message-
> From: Vipul Ashri
> Sent: Tuesday, August 11, 2020 4:00 AM
> To: dev@dpdk.org
> Cc: Xia, Chenbo ; vipul.as...@oracle.com
> Subject: [PATCH v2] net/virtio: fix 57f90f8("net/virtio: reuse packed ring
> functions")
The title is not right. As I told you,
please put 'Fixes: 57f90f894588 ("net/virtio: reuse packed ring functions")'
between the commit message and your 'Signed-off-by'. Note that the prefix
should be 'Fixes' and the commit id length is 12.
Could you refer to other commit with 'Fixes' to make it right?
>
> tx packets are not going out and standard tx path is not working due to
> cleanup malfunctioning.
Could you tell me what problem you solved? You just describe the result but
not the root cause.
Thanks!
Chenbo
>
> Signed-off-by: Vipul Ashri
> ---
> drivers/net/virtio/virtqueue.h | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/virtio/virtqueue.h
> b/drivers/net/virtio/virtqueue.h
> index 105a9c00c..20c95471e 100644
> --- a/drivers/net/virtio/virtqueue.h
> +++ b/drivers/net/virtio/virtqueue.h
> @@ -607,10 +607,8 @@ virtqueue_notify(struct virtqueue *vq)
>
> /* avoid write operation when necessary, to lessen cache issues */
> #define ASSIGN_UNLESS_EQUAL(var, val) do { \
> - typeof(var) var_ = (var); \
> - typeof(val) val_ = (val); \
> - if ((var_) != (val_)) \
> - (var_) = (val_);\
> + if ((var) != (val)) \
> + (var) = (val); \
> } while (0)
>
> #define virtqueue_clear_net_hdr(hdr) do {\
> --
> 2.28.0.windows.1
[dpdk-dev] [PATCH 1/4] net/netvsc: move rxbuf_info from per-device to per-queue
From: Long Li
netvsc uses rxbuf_info buffer to track received packets attached via
rte_pktmbuf_attach_extbuf() and ack the host based on usage count. It uses
the transaction_id in the VMBus packet to locate where to use memory in the
rxbuf_info.
This is not correct in multiple channel setup, as different channels may
return idential transaction_ids at a time, and may corrupt the rxbuf_info
buffer.
Fix this by defining rxbuf_info for each queue.
Fixes: 4e9c73e96 ("net/netvsc: add Hyper-V network device")
Cc: sta...@dpdk.org
Signed-off-by: Long Li
---
drivers/net/netvsc/hn_nvs.c | 13 +
drivers/net/netvsc/hn_rxtx.c | 33 ++---
drivers/net/netvsc/hn_var.h | 6 +++---
3 files changed, 38 insertions(+), 14 deletions(-)
diff --git a/drivers/net/netvsc/hn_nvs.c b/drivers/net/netvsc/hn_nvs.c
index f88854daf..eeb82ab9e 100644
--- a/drivers/net/netvsc/hn_nvs.c
+++ b/drivers/net/netvsc/hn_nvs.c
@@ -223,9 +223,15 @@ hn_nvs_conn_rxbuf(struct hn_data *hv)
resp.nvs_sect[0].slotcnt);
hv->rxbuf_section_cnt = resp.nvs_sect[0].slotcnt;
- hv->rxbuf_info = rte_calloc("HN_RXBUF_INFO", hv->rxbuf_section_cnt,
- sizeof(*hv->rxbuf_info),
RTE_CACHE_LINE_SIZE);
- if (!hv->rxbuf_info) {
+ /*
+* Pimary queue's rxbuf_info is not allocated at creation time.
+* Now we can allocate it after we figure out the slotcnt.
+*/
+ hv->primary->rxbuf_info = rte_calloc("HN_RXBUF_INFO",
+ hv->rxbuf_section_cnt,
+ sizeof(*hv->primary->rxbuf_info),
+ RTE_CACHE_LINE_SIZE);
+ if (!hv->primary->rxbuf_info) {
PMD_DRV_LOG(ERR,
"could not allocate rxbuf info");
return -ENOMEM;
@@ -255,7 +261,6 @@ hn_nvs_disconn_rxbuf(struct hn_data *hv)
error);
}
- rte_free(hv->rxbuf_info);
/*
* Linger long enough for NVS to disconnect RXBUF.
*/
diff --git a/drivers/net/netvsc/hn_rxtx.c b/drivers/net/netvsc/hn_rxtx.c
index 87b1184bc..c8c4ee10c 100644
--- a/drivers/net/netvsc/hn_rxtx.c
+++ b/drivers/net/netvsc/hn_rxtx.c
@@ -524,21 +524,21 @@ hn_rndis_rxinfo(const void *info_data, unsigned int
info_dlen,
static void hn_rx_buf_free_cb(void *buf __rte_unused, void *opaque)
{
struct hn_rx_bufinfo *rxb = opaque;
- struct hn_data *hv = rxb->hv;
+ struct hn_rx_queue *rxq = rxb->rxq;
- rte_atomic32_dec(&hv->rxbuf_outstanding);
+ rte_atomic32_dec(&rxq->rxbuf_outstanding);
hn_nvs_ack_rxbuf(rxb->chan, rxb->xactid);
}
-static struct hn_rx_bufinfo *hn_rx_buf_init(const struct hn_rx_queue *rxq,
+static struct hn_rx_bufinfo *hn_rx_buf_init(struct hn_rx_queue *rxq,
const struct vmbus_chanpkt_rxbuf
*pkt)
{
struct hn_rx_bufinfo *rxb;
- rxb = rxq->hv->rxbuf_info + pkt->hdr.xactid;
+ rxb = rxq->rxbuf_info + pkt->hdr.xactid;
rxb->chan = rxq->chan;
rxb->xactid = pkt->hdr.xactid;
- rxb->hv = rxq->hv;
+ rxb->rxq = rxq;
rxb->shinfo.free_cb = hn_rx_buf_free_cb;
rxb->shinfo.fcb_opaque = rxb;
@@ -568,7 +568,7 @@ static void hn_rxpkt(struct hn_rx_queue *rxq, struct
hn_rx_bufinfo *rxb,
* some space available in receive area for later packets.
*/
if (dlen >= HN_RXCOPY_THRESHOLD &&
- (uint32_t)rte_atomic32_read(&hv->rxbuf_outstanding) <
+ (uint32_t)rte_atomic32_read(&rxq->rxbuf_outstanding) <
hv->rxbuf_section_cnt / 2) {
struct rte_mbuf_ext_shared_info *shinfo;
const void *rxbuf;
@@ -585,7 +585,7 @@ static void hn_rxpkt(struct hn_rx_queue *rxq, struct
hn_rx_bufinfo *rxb,
/* shinfo is already set to 1 by the caller */
if (rte_mbuf_ext_refcnt_update(shinfo, 1) == 2)
- rte_atomic32_inc(&hv->rxbuf_outstanding);
+ rte_atomic32_inc(&rxq->rxbuf_outstanding);
rte_pktmbuf_attach_extbuf(m, data, iova,
dlen + headroom, shinfo);
@@ -888,6 +888,23 @@ struct hn_rx_queue *hn_rx_queue_alloc(struct hn_data *hv,
return NULL;
}
+ /* setup rxbuf_info for non-primary queue */
+ if (queue_id) {
+ rxq->rxbuf_info = rte_calloc("HN_RXBUF_INFO",
+ hv->rxbuf_section_cnt,
+ sizeof(*rxq->rxbuf_info),
+ RTE_CACHE_LINE_SIZE);
+
+ if (!rxq->rxbuf_info) {
+ PMD_DRV_LOG(ERR,
+ "Could not allocate rxbuf info for queue %d\n",
+ queue_id);
+ rte_free(rxq->event_buf);
+ rte_free(rxq);
+
[dpdk-dev] [PATCH 4/4] net/netvsc: check for overflow on packet info from host
From: Stephen Hemminger
The data from the host is trusted but checked by the driver.
One check that is missing is that the packet offset and length
might cause wraparound.
Cc: sta...@dpdk.org
Signed-off-by: Stephen Hemminger
Signed-off-by: Long Li
---
drivers/net/netvsc/hn_rxtx.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/netvsc/hn_rxtx.c b/drivers/net/netvsc/hn_rxtx.c
index a388ff258..d8d3f07f5 100644
--- a/drivers/net/netvsc/hn_rxtx.c
+++ b/drivers/net/netvsc/hn_rxtx.c
@@ -666,7 +666,8 @@ static void hn_rndis_rx_data(struct hn_rx_queue *rxq,
struct hn_rx_bufinfo *rxb,
void *data, uint32_t dlen)
{
- unsigned int data_off, data_len, pktinfo_off, pktinfo_len;
+ unsigned int data_off, data_len, total_len;
+ unsigned int pktinfo_off, pktinfo_len;
const struct rndis_packet_msg *pkt = data;
struct hn_rxinfo info = {
.vlan_info = HN_NDIS_VLAN_INFO_INVALID,
@@ -711,7 +712,8 @@ static void hn_rndis_rx_data(struct hn_rx_queue *rxq,
goto error;
}
- if (unlikely(data_off + data_len > pkt->len))
+ if (__builtin_add_overflow(data_off, data_len, &total_len) ||
+ total_len > pkt->len)
goto error;
if (unlikely(data_len < RTE_ETHER_HDR_LEN))
--
2.25.1
[dpdk-dev] [PATCH 2/4] bus/vmbus: remove vmbus_send_interrupt
From: Long Li
netvsc is a high speed VMBus device that uses monitor bit to signal the
host. It's not necessary to send interrupts via INT bit.
Signed-off-by: Long Li
---
drivers/bus/vmbus/vmbus_channel.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/drivers/bus/vmbus/vmbus_channel.c
b/drivers/bus/vmbus/vmbus_channel.c
index 4f5578e2c..f67f1c438 100644
--- a/drivers/bus/vmbus/vmbus_channel.c
+++ b/drivers/bus/vmbus/vmbus_channel.c
@@ -26,18 +26,6 @@ vmbus_sync_set_bit(volatile uint32_t *addr, uint32_t mask)
__sync_or_and_fetch(addr, mask);
}
-static inline void
-vmbus_send_interrupt(const struct rte_vmbus_device *dev, uint32_t relid)
-{
- uint32_t *int_addr;
- uint32_t int_mask;
-
- int_addr = dev->int_page + relid / 32;
- int_mask = 1u << (relid % 32);
-
- vmbus_sync_set_bit(int_addr, int_mask);
-}
-
static inline void
vmbus_set_monitor(const struct rte_vmbus_device *dev, uint32_t monitor_id)
{
@@ -55,7 +43,6 @@ static void
vmbus_set_event(const struct rte_vmbus_device *dev,
const struct vmbus_channel *chan)
{
- vmbus_send_interrupt(dev, chan->relid);
vmbus_set_monitor(dev, chan->monitor_id);
}
--
2.25.1
[dpdk-dev] [PATCH 3/4] net/netvsc: mark chim_index as NVS_CHIM_IDX_INVALID after freeing it
From: Long Li
chim_index could potentially be used in other hn_txdesc when re-allocated.
Mark it as invalid to prevent stale value being used.
Signed-off-by: Long Li
---
drivers/net/netvsc/hn_rxtx.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/netvsc/hn_rxtx.c b/drivers/net/netvsc/hn_rxtx.c
index c8c4ee10c..a388ff258 100644
--- a/drivers/net/netvsc/hn_rxtx.c
+++ b/drivers/net/netvsc/hn_rxtx.c
@@ -419,8 +419,10 @@ hn_nvs_send_completed(struct rte_eth_dev *dev, uint16_t
queue_id,
++txq->stats.errors;
}
- if (txd->chim_index != NVS_CHIM_IDX_INVALID)
+ if (txd->chim_index != NVS_CHIM_IDX_INVALID) {
hn_chim_free(hv, txd->chim_index);
+ txd->chim_index = NVS_CHIM_IDX_INVALID;
+ }
rte_pktmbuf_free(txd->m);
hn_txd_put(txq, txd);
--
2.25.1
Re: [dpdk-dev] [PATCH v3] net/mlx5: relaxed ordering for multi-packet RQ buffer refcnt
> > > > > > > > > > @@ -1790,9 +1792,9 @@ mlx5_rx_burst_mprq(void *dpdk_rxq, > > > > struct > > > > > > > > rte_mbuf **pkts, uint16_t pkts_n) void *buf_addr; > > > > > > > > > > > > > > > > /* Increment the refcnt of the whole chunk. */ > > > > > > > > -rte_atomic16_add_return(&buf->refcnt, 1); > > > > > rte_atomic16_add_return includes a full barrier along with > > > > > atomic > > > > operation. > > > > > But is full barrier required here? For ex: > > > > > __atomic_add_fetch(&buf->refcnt, 1, > > > > > __ATOMIC_RELAXED) will offer atomicity, but no barrier. Would > > > > > that be enough? > > > > > > > > > > > > > -MLX5_ASSERT((uint16_t)rte_atomic16_read(&buf- > > > > > > > > >refcnt) <= > > > > > > > > -strd_n + 1); > > > > > > > > +__atomic_add_fetch(&buf->refcnt, 1, > > > > > > > > __ATOMIC_ACQUIRE); > > > > > > > > The atomic load in MLX5_ASSERT() accesses the same memory space as > > > > the previous __atomic_add_fetch() does. > > > > They will access this memory space in the program order when we > > > > enabled MLX5_PMD_DEBUG. So the ACQUIRE barrier in > > > > __atomic_add_fetch() becomes unnecessary. > > > > > > > > By changing it to RELAXED ordering, this patch got 7.6% > > > > performance improvement on N1 (making it generate A72 alike > instructions). > > > > > > > > Could you please also try it on your testbed, Alex? > > > > > > Situation got better with this modification, here are the results: > > > - no patch: 3.0 Mpps CPU cycles/packet=51.52 > > > - original patch:2.1 Mpps CPU cycles/packet=71.05 > > > - modified patch: 2.9 Mpps CPU cycles/packet=52.79 Also, I found > > > that the degradation is there only in case I enable bursts stats. > > > > > > Great! So this patch will not hurt the normal datapath performance. > > > > > > > Could you please turn on the following config options and see if you > > > can reproduce this as well? > > > CONFIG_RTE_TEST_PMD_RECORD_CORE_CYCLES=y > > > CONFIG_RTE_TEST_PMD_RECORD_BURST_STATS=y > > > > Thanks, Alex. Some updates. > > > > Slightly (about 1%) throughput degradation was detected after we > > enabled these two config options on N1 SoC. > > > > If we look insight the perf stats results, with this patch, both > > mlx5_rx_burst and mlx5_tx_burst consume fewer CPU cycles than the > original code. > > However, __memcpy_generic takes more cycles. I think that might be the > > reason for CPU cycles per packet increment after applying this patch. > > > > Original code: > > 98.07%--pkt_burst_io_forward > > | > > |--44.53%--__memcpy_generic > > | > > |--35.85%--mlx5_rx_burst_mprq > > | > > |--15.94%--mlx5_tx_burst_none_empw > > | | > > | |--7.32%--mlx5_tx_handle_completion.isra.0 > > | | > > | --0.50%--__memcpy_generic > > | > > --1.14%--memcpy@plt > > > > Use C11 with RELAXED ordering: > > 99.36%--pkt_burst_io_forward > > | > > |--47.40%--__memcpy_generic > > | > > |--34.62%--mlx5_rx_burst_mprq > > | > > |--15.55%--mlx5_tx_burst_none_empw > > | | > > | --7.08%--mlx5_tx_handle_completion.isra.0 > > | > > --1.17%--memcpy@plt > > > > BTW, all the atomic operations in this patch are not the hotspot. > > Phil, we are seeing much worse degradation on our ARM platform > unfortunately. > I don't think that discrepancy in memcpy can explain this behavior. > Your patch is not touching this area of code. Let me collect some perf stat on > our side. Are you testing the patch as is or have you made the changes that were discussed in the thread? > > > > > > > > > > > > > > > > Can you replace just the above line with the following lines and test > > > > > it? > > > > > > > > > > __atomic_add_fetch(&buf->refcnt, 1, __ATOMIC_RELAXED); > > > > > __atomic_thread_fence(__ATOMIC_ACQ_REL); > > > > > > > > > > This should make the generated code same as before this patch. > > > > > Let me know if you would prefer us to re-spin the patch instead > > > > > (for > > testing). > > > > > > > > > > > > > +MLX5_ASSERT(__atomic_load_n(&buf->refcnt, > > > > > > > > +__ATOMIC_RELAXED) <= strd_n + 1); > > > > > > > > buf_addr = RTE_PTR_SUB(addr, RTE_PKTMBUF_HEADROOM); > > > > > > > > /* > > > > > > > > * MLX5 device doesn't use iova but it is necessary in a > > > > > > > diff > > > > > > > > --git a/drivers/net/mlx5/mlx5_rxtx.h > > > > > > > > b/drivers/net/mlx5/mlx5_rxtx.h index 26621ff..0fc15f3 > > > > > > > > 100644 > > > > > > > > --- a/drivers/net/mlx5/mlx5_rxtx.h > > > > > > > > +++ b/drivers/net/mlx5/mlx5_rxtx.h > > > > > > >
Re: [dpdk-dev] [PATCH 20.11 00/12] add max SIMD bitwidth to EAL
Hi Ciara, I have not reviewed other patches in this series yet. Few questions inline. > -Original Message- > From: dev On Behalf Of Ciara Power > Sent: Friday, August 7, 2020 10:59 AM > To: dev@dpdk.org > Cc: bruce.richard...@intel.com; Ciara Power > Subject: [dpdk-dev] [PATCH 20.11 00/12] add max SIMD bitwidth to EAL > > A number of components in DPDK have optional AVX-512 or other vector code > paths which can be selected at runtime. Rather than having each component > provide its own mechanism to select a code path, this patchset adds support > for a single setting to control what code paths are used. Do you mean that all the components will have to use AVX-512? IMO, different libraries might behave differently to the use of different vector sizes. Are we taking away the ability to use different vector sizes for different components. > This can be used to enable some non-default code paths e.g. ones using AVX- > 512, but also to limit the code paths to certain vector widths, or to scalar > code only, which is useful for testing. > > The max SIMD bitwidth setting can be set by the app itself through use of the > available API, or can be overriden by a commandline argument passed by the > user. Arm platforms support SVE (scalable vector extensions) feature. With this feature, the code is agnostic to the vector size. i.e. same code can run on various vector sizes. There is no code yet in DPDK with this feature. But, it will be added in the near future. It would be good to handle this now so that we do not have issues in the future.. > > Ciara Power (12): > eal: add max SIMD bitwidth > eal: add default SIMD bitwidth values > net/i40e: add checks for max SIMD bitwidth > net/axgbe: add checks for max SIMD bitwidth > net/bnxt: add checks for max SIMD bitwidth > net/enic: add checks for max SIMD bitwidth > net/fm10k: add checks for max SIMD bitwidth > net/iavf: add checks for max SIMD bitwidth > net/ice: add checks for max SIMD bitwidth > net/ixgbe: add checks for max SIMD bitwidth > net/mlx5: add checks for max SIMD bitwidth > net/virtio: add checks for max SIMD bitwidth > > drivers/net/axgbe/axgbe_rxtx.c | 3 +- > drivers/net/bnxt/bnxt_ethdev.c | 6 ++- > drivers/net/enic/enic_rxtx_vec_avx2.c | 3 +- > drivers/net/fm10k/fm10k_ethdev.c | 11 ++-- > drivers/net/i40e/i40e_rxtx.c | 19 --- > drivers/net/iavf/iavf_rxtx.c | 16 +++--- > drivers/net/ice/ice_rxtx.c | 20 --- > drivers/net/ixgbe/ixgbe_rxtx.c | 7 ++- > drivers/net/mlx5/mlx5_ethdev.c | 3 +- > drivers/net/virtio/virtio_ethdev.c | 12 +++-- > lib/librte_eal/arm/include/rte_vect.h | 2 + > lib/librte_eal/common/eal_common_options.c | 63 > ++ > lib/librte_eal/common/eal_internal_cfg.h | 8 +++ > lib/librte_eal/common/eal_options.h| 2 + > lib/librte_eal/include/generic/rte_vect.h | 2 + > lib/librte_eal/include/rte_eal.h | 31 +++ > lib/librte_eal/ppc/include/rte_vect.h | 2 + > lib/librte_eal/rte_eal_version.map | 4 ++ > lib/librte_eal/x86/include/rte_vect.h | 2 + > 19 files changed, 184 insertions(+), 32 deletions(-) > > -- > 2.17.1
[dpdk-dev] [PATCH] app/testpmd: fix flow rules list after port stop
According to current RTE API, port flow rules must not be kept
after port stop.
Testpmd did not flush port flow rules after `port stop' command was
called. As the result, after the port was restarted, it showed bogus
flow rules.
Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
Cc: sta...@dpdk.org
Signed-off-by: Gregory Etelson
Acked-by: Ori Kam
---
app/test-pmd/testpmd.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 7842c3b781..4ba5c41c6e 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -2627,6 +2627,9 @@ stop_port(portid_t pid)
RTE_PORT_HANDLING) == 0)
continue;
+ if (port->flow_list)
+ port_flow_flush(pi);
+
rte_eth_dev_stop(pi);
if (rte_atomic16_cmpset(&(port->port_status),
--
2.25.1
[dpdk-dev] [PATCH v5 0/5] compiling ethdev lib under windows
Added needed changes in order to get ethdev compiling under windows.
Depends-on: series-10382 ("compile librte_net for windows")
v5: fixed style issues.
v4: added comments to #else and fixed code issue.
v3: rebased on current master, added more exports to export list
v2: fixed logging issue in telemetry lib.
Fady Bader (5):
eal: added interrupts empty stubs
eal: updated export list for Windows
ethdev: remove structs from export list
telemetry: implement empty stubs for Windows
ethdev: compiling ethdev under Windows
lib/librte_eal/rte_eal_exports.def | 11 +++
lib/librte_eal/windows/eal_interrupts.c | 18
lib/librte_eal/windows/meson.build | 1 +
lib/librte_ethdev/rte_ethdev_version.map | 2 --
lib/librte_telemetry/rte_telemetry.h | 4 +++
lib/librte_telemetry/telemetry.c | 50
lib/librte_telemetry/telemetry_legacy.c | 25
lib/meson.build | 3 +-
8 files changed, 111 insertions(+), 3 deletions(-)
create mode 100644 lib/librte_eal/windows/eal_interrupts.c
--
2.16.1.windows.4
[dpdk-dev] [PATCH v5 5/5] ethdev: compiling ethdev under Windows
Compiling needed libraries for ethdev under Windows. Signed-off-by: Fady Bader --- lib/meson.build | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/meson.build b/lib/meson.build index 6bbaf242a9..c145240eb9 100644 --- a/lib/meson.build +++ b/lib/meson.build @@ -38,9 +38,10 @@ libraries = [ if is_windows libraries = [ 'kvargs', + 'telemetry', 'eal', 'ring', - 'mempool', 'mbuf', 'pci', 'net', + 'mempool', 'mbuf', 'net', 'meter', 'ethdev', 'pci', # core ] # only supported libraries for windows endif -- 2.16.1.windows.4
[dpdk-dev] [PATCH v5 4/5] telemetry: implement empty stubs for Windows
Telemetry didn't compile under Windows.
Empty stubs implementation was added for Windows.
Signed-off-by: Fady Bader
---
lib/librte_telemetry/rte_telemetry.h| 4 +++
lib/librte_telemetry/telemetry.c| 50 +
lib/librte_telemetry/telemetry_legacy.c | 25 +
3 files changed, 79 insertions(+)
diff --git a/lib/librte_telemetry/rte_telemetry.h
b/lib/librte_telemetry/rte_telemetry.h
index d13010b8fb..c3c0e44599 100644
--- a/lib/librte_telemetry/rte_telemetry.h
+++ b/lib/librte_telemetry/rte_telemetry.h
@@ -5,6 +5,10 @@
#include
#include
+#ifdef RTE_EXEC_ENV_WINDOWS
+#include
+#endif
+
#ifndef _RTE_TELEMETRY_H_
#define _RTE_TELEMETRY_H_
diff --git a/lib/librte_telemetry/telemetry.c b/lib/librte_telemetry/telemetry.c
index 0252282735..59ad9cc7ec 100644
--- a/lib/librte_telemetry/telemetry.c
+++ b/lib/librte_telemetry/telemetry.c
@@ -2,6 +2,7 @@
* Copyright(c) 2020 Intel Corporation
*/
+#ifndef RTE_EXEC_ENV_WINDOWS
#include
#include
#include
@@ -20,6 +21,20 @@
#include "telemetry_data.h"
#include "rte_telemetry_legacy.h"
+#else /* RTE_EXEC_ENV_WINDOWS */
+
+/* includes for Windows */
+#include
+#include
+
+#include "rte_telemetry.h"
+#include "telemetry_json.h"
+#include "telemetry_data.h"
+#include "rte_telemetry_legacy.h"
+
+#endif
+
+#ifndef RTE_EXEC_ENV_WINDOWS
#define MAX_CMD_LEN 56
#define MAX_HELP_LEN 64
#define MAX_OUTPUT_LEN (1024 * 16)
@@ -42,17 +57,24 @@ struct socket {
};
static struct socket v2_socket; /* socket for v2 telemetry */
static struct socket v1_socket; /* socket for v1 telemetry */
+#endif
+
static char telemetry_log_error[1024]; /* Will contain error on init failure */
+
+#ifndef RTE_EXEC_ENV_WINDOWS
/* list of command callbacks, with one command registered by default */
static struct cmd_callback callbacks[TELEMETRY_MAX_CALLBACKS];
static int num_callbacks; /* How many commands are registered */
/* Used when accessing or modifying list of command callbacks */
static rte_spinlock_t callback_sl = RTE_SPINLOCK_INITIALIZER;
static uint16_t v2_clients;
+#endif
int
rte_telemetry_register_cmd(const char *cmd, telemetry_cb fn, const char *help)
{
+#ifndef RTE_EXEC_ENV_WINDOWS
+
int i = 0;
if (strlen(cmd) >= MAX_CMD_LEN || fn == NULL || cmd[0] != '/'
@@ -76,8 +98,19 @@ rte_telemetry_register_cmd(const char *cmd, telemetry_cb fn,
const char *help)
rte_spinlock_unlock(&callback_sl);
return 0;
+
+#else /* RTE_EXEC_ENV_WINDOWS */
+
+ RTE_SET_USED(cmd);
+ RTE_SET_USED(fn);
+ RTE_SET_USED(help);
+
+ return 0;
+
+#endif
}
+#ifndef RTE_EXEC_ENV_WINDOWS
static int
list_commands(const char *cmd __rte_unused, const char *params __rte_unused,
struct rte_tel_data *d)
@@ -411,11 +444,14 @@ telemetry_v2_init(const char *runtime_dir, rte_cpuset_t
*cpuset)
return 0;
}
+#endif
int32_t
rte_telemetry_init(const char *runtime_dir, rte_cpuset_t *cpuset,
const char **err_str)
{
+#ifndef RTE_EXEC_ENV_WINDOWS
+
if (telemetry_v2_init(runtime_dir, cpuset) != 0) {
*err_str = telemetry_log_error;
return -1;
@@ -424,4 +460,18 @@ rte_telemetry_init(const char *runtime_dir, rte_cpuset_t
*cpuset,
*err_str = telemetry_log_error;
}
return 0;
+
+#else /* RTE_EXEC_ENV_WINDOWS */
+
+ RTE_SET_USED(runtime_dir);
+ RTE_SET_USED(cpuset);
+ RTE_SET_USED(err_str);
+
+ snprintf(telemetry_log_error, sizeof(telemetry_log_error),
+ "Telemetry is not supported on Windows.");
+
+ return 0;
+
+#endif
}
+
diff --git a/lib/librte_telemetry/telemetry_legacy.c
b/lib/librte_telemetry/telemetry_legacy.c
index a341fe4ebd..40e7bbe2f8 100644
--- a/lib/librte_telemetry/telemetry_legacy.c
+++ b/lib/librte_telemetry/telemetry_legacy.c
@@ -2,6 +2,7 @@
* Copyright(c) 2020 Intel Corporation
*/
+#ifndef RTE_EXEC_ENV_WINDOWS
#include
#include
#include
@@ -15,6 +16,15 @@
#include "rte_telemetry_legacy.h"
+#else /* RTE_EXEC_ENV_WINDOWS */
+
+#include
+
+#include "rte_telemetry_legacy.h"
+
+#endif
+#ifndef RTE_EXEC_ENV_WINDOWS
+
#define MAX_LEN 128
#define BUF_SIZE 1024
#define CLIENTS_UNREG_ACTION "\"action\":2"
@@ -48,12 +58,15 @@ struct json_command
callbacks[TELEMETRY_LEGACY_MAX_CALLBACKS] = {
};
int num_legacy_callbacks = 1;
static rte_spinlock_t callback_sl = RTE_SPINLOCK_INITIALIZER;
+#endif
int
rte_telemetry_legacy_register(const char *cmd,
enum rte_telemetry_legacy_data_req data_req,
telemetry_legacy_cb fn)
{
+#ifndef RTE_EXEC_ENV_WINDOWS
+
if (fn == NULL)
return -EINVAL;
if (num_legacy_callbacks >= (int) RTE_DIM(callbacks))
@@ -71,8 +84,19 @@ rte_telemetry_legacy_register(const char *cmd,
rte_spinlock_unlock(&callback_sl);
return 0;
+
+#else /* RTE_EXEC_ENV_WINDOWS */
+
+ RTE_SET_USED(cmd);
+ RTE_SET
[dpdk-dev] [PATCH v5 2/5] eal: updated export list for Windows
Added eal functions used by ethdev lib to the export list under Windows. Signed-off-by: Fady Bader --- lib/librte_eal/rte_eal_exports.def | 11 +++ 1 file changed, 11 insertions(+) diff --git a/lib/librte_eal/rte_eal_exports.def b/lib/librte_eal/rte_eal_exports.def index 69204a92c6..782e6fc721 100644 --- a/lib/librte_eal/rte_eal_exports.def +++ b/lib/librte_eal/rte_eal_exports.def @@ -28,6 +28,7 @@ EXPORTS rte_eal_tailq_register rte_eal_using_phys_addrs rte_free + rte_get_tsc_hz rte_hexdump rte_malloc rte_malloc_dump_stats @@ -145,3 +146,13 @@ EXPORTS rte_mem_map rte_mem_page_size rte_mem_unmap + + rte_class_register + rte_devargs_parse + rte_class_find_by_name + rte_socket_id + rte_strerror + rte_intr_rx_ctl + rte_log_register + rte_log_set_level + rte_log_register_type_and_pick_level \ No newline at end of file -- 2.16.1.windows.4
[dpdk-dev] [PATCH v5 1/5] eal: added interrupts empty stubs
The ethdev lib uses interrupts. Interrupts are not implemented for Windows.
To solve this, empty interrupt stubs were added under Windows.
Signed-off-by: Fady Bader
---
lib/librte_eal/windows/eal_interrupts.c | 18 ++
lib/librte_eal/windows/meson.build | 1 +
2 files changed, 19 insertions(+)
create mode 100644 lib/librte_eal/windows/eal_interrupts.c
diff --git a/lib/librte_eal/windows/eal_interrupts.c
b/lib/librte_eal/windows/eal_interrupts.c
new file mode 100644
index 00..309e851493
--- /dev/null
+++ b/lib/librte_eal/windows/eal_interrupts.c
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2020 Mellanox Technologies, Ltd
+ */
+
+#include
+
+int
+rte_intr_rx_ctl(struct rte_intr_handle *intr_handle,
+ int epfd, int op, unsigned int vec, void *data)
+{
+ RTE_SET_USED(intr_handle);
+ RTE_SET_USED(epfd);
+ RTE_SET_USED(op);
+ RTE_SET_USED(vec);
+ RTE_SET_USED(data);
+
+ return -ENOTSUP;
+}
diff --git a/lib/librte_eal/windows/meson.build
b/lib/librte_eal/windows/meson.build
index 08c888e018..b690bc6b0a 100644
--- a/lib/librte_eal/windows/meson.build
+++ b/lib/librte_eal/windows/meson.build
@@ -8,6 +8,7 @@ sources += files(
'eal_debug.c',
'eal_file.c',
'eal_hugepages.c',
+ 'eal_interrupts.c',
'eal_lcore.c',
'eal_log.c',
'eal_memalloc.c',
--
2.16.1.windows.4
[dpdk-dev] [PATCH v5 3/5] ethdev: remove structs from export list
Some ethdev structs were present in ethdev export list.
There structs were removed from the export list.
Signed-off-by: Fady Bader
---
lib/librte_ethdev/rte_ethdev_version.map | 2 --
1 file changed, 2 deletions(-)
diff --git a/lib/librte_ethdev/rte_ethdev_version.map
b/lib/librte_ethdev/rte_ethdev_version.map
index 1212a17d32..21a2177756 100644
--- a/lib/librte_ethdev/rte_ethdev_version.map
+++ b/lib/librte_ethdev/rte_ethdev_version.map
@@ -89,7 +89,6 @@ DPDK_20.0 {
rte_eth_iterator_next;
rte_eth_led_off;
rte_eth_led_on;
- rte_eth_link;
rte_eth_link_get;
rte_eth_link_get_nowait;
rte_eth_macaddr_get;
@@ -104,7 +103,6 @@ DPDK_20.0 {
rte_eth_rx_queue_setup;
rte_eth_set_queue_rate_limit;
rte_eth_speed_bitflag;
- rte_eth_stats;
rte_eth_stats_get;
rte_eth_stats_reset;
rte_eth_timesync_adjust_time;
--
2.16.1.windows.4
[dpdk-dev] [PATCH 0/7] Bugs Porting from I40evf For IAVF Feature
These patches are bugs porting from i40evf to iavf. [PATCH 1/7] net/iavf: fix scattered Rx enabling [PATCH 2/7] net/iavf: set speed to undefined for default case [PATCH 3/7] net/iavf: fix port start during configuration restore [PATCH 4/7] net/iavf: fix setting of MAC address on iavf [PATCH 5/7] net/iavf: fix multiple interrupts for VF [PATCH 6/7] net/iavf: downgrade error log [PATCH 7/7] net/iavf: fix port close drivers/net/iavf/iavf.h| 1 + drivers/net/iavf/iavf_ethdev.c | 24 ++ drivers/net/iavf/iavf_vchnl.c | 58 +++--- 3 files changed, 65 insertions(+), 18 deletions(-) -- 2.17.1
[dpdk-dev] [PATCH 1/7] net/iavf: fix scattered Rx enabling
No need to add additional vlan tag size for max packet size, since
for i40e, the queue's Rx Max Frame Size (rxq->max_pkt_len) already
includes the vlan header size.
Fixes: 69dd4c3d0898 ("net/avf: enable queue and device")
Signed-off-by: SteveX Yang
---
drivers/net/iavf/iavf_ethdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/iavf/iavf_ethdev.c b/drivers/net/iavf/iavf_ethdev.c
index c3aa4cd72..f9dd5710c 100644
--- a/drivers/net/iavf/iavf_ethdev.c
+++ b/drivers/net/iavf/iavf_ethdev.c
@@ -253,7 +253,7 @@ iavf_init_rxq(struct rte_eth_dev *dev, struct iavf_rx_queue
*rxq)
rxq->max_pkt_len = max_pkt_len;
if ((dev_data->dev_conf.rxmode.offloads & DEV_RX_OFFLOAD_SCATTER) ||
- (rxq->max_pkt_len + 2 * IAVF_VLAN_TAG_SIZE) > buf_size) {
+ rxq->max_pkt_len > buf_size) {
dev_data->scattered_rx = 1;
}
IAVF_PCI_REG_WRITE(rxq->qrx_tail, rxq->nb_rx_desc - 1);
--
2.17.1
[dpdk-dev] [PATCH 2/7] net/iavf: set speed to undefined for default case
During PF/VF link update, a default speed value of 100M will be set
if get_link_info has failed or speed is unknown.
Consequently if PF is put in no-carrier state, VFs will switch to
"in carrier" state due to a link up + a link speed set to 100M
(default value if no speed detected).
To be consistent with linux drivers on which PF and VFs are in
same carrier state, sets default speed to undefined (instead of 100M)
and updates a link status of VF only if link is up and speed is
different from undefined.
Fixes: 48de41ca11f0 ("net/avf: enable link status update")
Signed-off-by: SteveX Yang
---
drivers/net/iavf/iavf_ethdev.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/iavf/iavf_ethdev.c b/drivers/net/iavf/iavf_ethdev.c
index f9dd5710c..ae508f2f0 100644
--- a/drivers/net/iavf/iavf_ethdev.c
+++ b/drivers/net/iavf/iavf_ethdev.c
@@ -620,8 +620,9 @@ iavf_dev_link_update(struct rte_eth_dev *dev,
}
new_link.link_duplex = ETH_LINK_FULL_DUPLEX;
- new_link.link_status = vf->link_up ? ETH_LINK_UP :
-ETH_LINK_DOWN;
+ new_link.link_status = (vf->link_up &&
+ new_link.link_speed != ETH_SPEED_NUM_NONE)
+ ? ETH_LINK_UP : ETH_LINK_DOWN;
new_link.link_autoneg = !(dev->data->dev_conf.link_speeds &
ETH_LINK_SPEED_FIXED);
--
2.17.1
[dpdk-dev] [PATCH 3/7] net/iavf: fix port start during configuration restore
If configuring VF promiscuous mode is not supported,
return -ENOTSUP error code in .promiscuous_enable/disable dev_ops.
This is to fix the port start during configuration restore,
where if .promiscuous_enable/disable dev_ops exists
and return any value other than -ENOTSUP, start will fail.
Same is done for .allmulticast_enable/disable dev_ops.
Fixes: ca041cd44fcc ("ethdev: change allmulticast callbacks to return status")
Fixes: 9039c8125730 ("ethdev: change promiscuous callbacks to return status")
Signed-off-by: SteveX Yang
---
drivers/net/iavf/iavf_ethdev.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/net/iavf/iavf_ethdev.c b/drivers/net/iavf/iavf_ethdev.c
index ae508f2f0..349c82cae 100644
--- a/drivers/net/iavf/iavf_ethdev.c
+++ b/drivers/net/iavf/iavf_ethdev.c
@@ -648,6 +648,8 @@ iavf_dev_promiscuous_enable(struct rte_eth_dev *dev)
ret = iavf_config_promisc(adapter, true, vf->promisc_multicast_enabled);
if (!ret)
vf->promisc_unicast_enabled = true;
+ else if (ret == IAVF_NOT_SUPPORTED)
+ ret = -ENOTSUP;
else
ret = -EAGAIN;
@@ -669,6 +671,8 @@ iavf_dev_promiscuous_disable(struct rte_eth_dev *dev)
vf->promisc_multicast_enabled);
if (!ret)
vf->promisc_unicast_enabled = false;
+ else if (ret == IAVF_NOT_SUPPORTED)
+ ret = -ENOTSUP;
else
ret = -EAGAIN;
@@ -689,6 +693,8 @@ iavf_dev_allmulticast_enable(struct rte_eth_dev *dev)
ret = iavf_config_promisc(adapter, vf->promisc_unicast_enabled, true);
if (!ret)
vf->promisc_multicast_enabled = true;
+ else if (ret == IAVF_NOT_SUPPORTED)
+ ret = -ENOTSUP;
else
ret = -EAGAIN;
@@ -709,6 +715,8 @@ iavf_dev_allmulticast_disable(struct rte_eth_dev *dev)
ret = iavf_config_promisc(adapter, vf->promisc_unicast_enabled, false);
if (!ret)
vf->promisc_multicast_enabled = false;
+ else if (ret == IAVF_NOT_SUPPORTED)
+ ret = -ENOTSUP;
else
ret = -EAGAIN;
--
2.17.1
[dpdk-dev] [PATCH 5/7] net/iavf: fix multiple interrupts for VF
Interrupt mapping should be 1:n queue(s).This patch fixes the
logic of interrupt bind by code reconstruction.
Fixes: 69dd4c3d0898 ("net/avf: enable queue and device")
Signed-off-by: SteveX Yang
---
drivers/net/iavf/iavf_vchnl.c | 56 ---
1 file changed, 45 insertions(+), 11 deletions(-)
diff --git a/drivers/net/iavf/iavf_vchnl.c b/drivers/net/iavf/iavf_vchnl.c
index 33acea54a..614ea7e79 100644
--- a/drivers/net/iavf/iavf_vchnl.c
+++ b/drivers/net/iavf/iavf_vchnl.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "iavf.h"
#include "iavf_rxtx.h"
@@ -686,20 +687,53 @@ int
iavf_config_irq_map(struct iavf_adapter *adapter)
{
struct iavf_info *vf = IAVF_DEV_PRIVATE_TO_VF(adapter);
+ struct iavf_cmd_info args;
+ uint8_t *cmd_buffer = NULL;
struct virtchnl_irq_map_info *map_info;
struct virtchnl_vector_map *vecmap;
- struct iavf_cmd_info args;
- int len, i, err;
+ struct rte_eth_dev *dev = adapter->eth_dev;
+ struct rte_pci_device *pci_dev = RTE_ETH_DEV_TO_PCI(dev);
+ struct rte_intr_handle *intr_handle = &pci_dev->intr_handle;
+ uint32_t vec, cmd_buffer_size, max_vectors, nb_msix, msix_base, i;
+ uint16_t rxq_map[vf->vf_res->max_vectors];
+ int err;
- len = sizeof(struct virtchnl_irq_map_info) +
- sizeof(struct virtchnl_vector_map) * vf->nb_msix;
+ memset(rxq_map, 0, sizeof(rxq_map));
+ if (dev->data->dev_conf.intr_conf.rxq &&
+ rte_intr_allow_others(intr_handle)) {
+ msix_base = IAVF_RX_VEC_START;
+ max_vectors = vf->vf_res->max_vectors - 1;
+ nb_msix = RTE_MIN(max_vectors, intr_handle->nb_efd);
+
+ vec = msix_base;
+ for (i = 0; i < dev->data->nb_rx_queues; i++) {
+ rxq_map[vec] |= 1 << i;
+ intr_handle->intr_vec[i] = vec++;
+ if (vec >= vf->vf_res->max_vectors)
+ vec = msix_base;
+ }
+ } else {
+ msix_base = IAVF_MISC_VEC_ID;
+ nb_msix = 1;
- map_info = rte_zmalloc("map_info", len, 0);
- if (!map_info)
- return -ENOMEM;
+ for (i = 0; i < dev->data->nb_rx_queues; i++) {
+ rxq_map[msix_base] |= 1 << i;
+ if (rte_intr_dp_is_en(intr_handle))
+ intr_handle->intr_vec[i] = msix_base;
+ }
+ }
- map_info->num_vectors = vf->nb_msix;
- for (i = 0; i < vf->nb_msix; i++) {
+ cmd_buffer_size = sizeof(struct virtchnl_irq_map_info) +
+ sizeof(struct virtchnl_vector_map) * nb_msix;
+ cmd_buffer = rte_zmalloc("iavf", cmd_buffer_size, 0);
+ if (!cmd_buffer) {
+ PMD_DRV_LOG(ERR, "Failed to allocate memory");
+ return IAVF_ERR_NO_MEMORY;
+ }
+
+ map_info = (struct virtchnl_irq_map_info *)cmd_buffer;
+ map_info->num_vectors = nb_msix;
+ for (i = 0; i < nb_msix; i++) {
vecmap = &map_info->vecmap[i];
vecmap->vsi_id = vf->vsi_res->vsi_id;
vecmap->rxitr_idx = IAVF_ITR_INDEX_DEFAULT;
@@ -709,8 +743,8 @@ iavf_config_irq_map(struct iavf_adapter *adapter)
}
args.ops = VIRTCHNL_OP_CONFIG_IRQ_MAP;
- args.in_args = (u8 *)map_info;
- args.in_args_size = len;
+ args.in_args = (u8 *)cmd_buffer;
+ args.in_args_size = cmd_buffer_size;
args.out_buffer = vf->aq_resp;
args.out_size = IAVF_AQ_BUF_SZ;
err = iavf_execute_vf_cmd(adapter, &args);
--
2.17.1
[dpdk-dev] [PATCH 4/7] net/iavf: fix setting of MAC address on iavf
When setting the MAC address, the ethdev layer copies the new mac
address in dev->data->mac_addrs[0] before calling the dev_ops.
Therefore, is_same_ether_addr(mac_addr, dev->data->mac_addrs) was
always true, and the MAC was never set. Remove this test to fix the
issue.
Fixes: 538da7a1cad2 ("net: add rte prefix to ether functions")
Signed-off-by: SteveX Yang
---
drivers/net/iavf/iavf_ethdev.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/iavf/iavf_ethdev.c b/drivers/net/iavf/iavf_ethdev.c
index 349c82cae..f16aff531 100644
--- a/drivers/net/iavf/iavf_ethdev.c
+++ b/drivers/net/iavf/iavf_ethdev.c
@@ -978,9 +978,6 @@ iavf_dev_set_default_mac_addr(struct rte_eth_dev *dev,
old_addr = (struct rte_ether_addr *)hw->mac.addr;
perm_addr = (struct rte_ether_addr *)hw->mac.perm_addr;
- if (rte_is_same_ether_addr(mac_addr, old_addr))
- return 0;
-
/* If the MAC address is configured by host, skip the setting */
if (rte_is_valid_assigned_ether_addr(perm_addr))
return -EPERM;
--
2.17.1
[dpdk-dev] [PATCH 7/7] net/iavf: fix port close
From: "Zhang, RobinX"
Port reset will call iavf_dev_uninit() to release resources. It wants
to call iavf_dev_close() to release resources. So there will be a
call conflict if calling iavf_dev_reset() and iavf_dev_close() at the
same time.
This patch added adapter->closed flag in iavf_dev_close()
to control the status of close.
Fixes: 83fe5e80692a ("net/iavf: move device state flag")
Signed-off-by: SteveX Yang
---
drivers/net/iavf/iavf.h| 1 +
drivers/net/iavf/iavf_ethdev.c | 6 ++
2 files changed, 7 insertions(+)
diff --git a/drivers/net/iavf/iavf.h b/drivers/net/iavf/iavf.h
index 9be8a2381..06cbe6089 100644
--- a/drivers/net/iavf/iavf.h
+++ b/drivers/net/iavf/iavf.h
@@ -161,6 +161,7 @@ struct iavf_adapter {
bool tx_vec_allowed;
const uint32_t *ptype_tbl;
bool stopped;
+ bool closed;
uint16_t fdir_ref_cnt;
};
diff --git a/drivers/net/iavf/iavf_ethdev.c b/drivers/net/iavf/iavf_ethdev.c
index f16aff531..b58e57b07 100644
--- a/drivers/net/iavf/iavf_ethdev.c
+++ b/drivers/net/iavf/iavf_ethdev.c
@@ -1367,6 +1367,7 @@ iavf_dev_init(struct rte_eth_dev *eth_dev)
hw->back = IAVF_DEV_PRIVATE_TO_ADAPTER(eth_dev->data->dev_private);
adapter->eth_dev = eth_dev;
adapter->stopped = 1;
+ adapter->closed = 0;
if (iavf_init_vf(eth_dev) != 0) {
PMD_INIT_LOG(ERR, "Init vf failed");
@@ -1423,6 +1424,9 @@ iavf_dev_close(struct rte_eth_dev *dev)
struct iavf_adapter *adapter =
IAVF_DEV_PRIVATE_TO_ADAPTER(dev->data->dev_private);
+ if (adapter->closed == 1)
+ return;
+
iavf_dev_stop(dev);
iavf_flow_flush(dev, NULL);
iavf_flow_uninit(adapter);
@@ -1434,6 +1438,8 @@ iavf_dev_close(struct rte_eth_dev *dev)
rte_intr_callback_unregister(intr_handle,
iavf_dev_interrupt_handler, dev);
iavf_disable_irq0(hw);
+
+ adapter->closed = 1;
}
static int
--
2.17.1
[dpdk-dev] [PATCH 6/7] net/iavf: downgrade error log
When receiving the unsupported AQ messages, it's taken as an
error. It's not appropriate and triggers too much unnecessary print.
Fixes: 22b123a36d07 ("net/avf: initialize PMD")
Signed-off-by: SteveX Yang
---
drivers/net/iavf/iavf_vchnl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/iavf/iavf_vchnl.c b/drivers/net/iavf/iavf_vchnl.c
index 614ea7e79..06eaae0e4 100644
--- a/drivers/net/iavf/iavf_vchnl.c
+++ b/drivers/net/iavf/iavf_vchnl.c
@@ -266,7 +266,7 @@ iavf_handle_virtchnl_msg(struct rte_eth_dev *dev)
}
break;
default:
- PMD_DRV_LOG(ERR, "Request %u is not supported yet",
+ PMD_DRV_LOG(DEBUG, "Request %u is not supported yet",
aq_opc);
break;
}
--
2.17.1
