* [dpdk-dev] [PATCH] ci: fix package installation in GitHub Actions
@ 2020-12-19 8:26 4% David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2020-12-19 8:26 UTC (permalink / raw)
To: dev; +Cc: Aaron Conole, Michael Santana, Thomas Monjalon
APT cache must be updated to avoid trying to install an unavailable
version of a package.
Fixes: 87009585e293 ("ci: hook to GitHub Actions")
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
I did not find a way for the update to be done by GHA itself,
so adding an explicit step.
The robot hits this issue on all 32-bits builds at the moment.
I will apply this quickly.
---
.github/workflows/build.yml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
index 05eb59527f..0b72df0ebe 100644
--- a/.github/workflows/build.yml
+++ b/.github/workflows/build.yml
@@ -87,6 +87,8 @@ jobs:
with:
path: reference
key: ${{ steps.get_ref_keys.outputs.abi }}
+ - name: Update APT cache
+ run: sudo apt update
- name: Install packages
run: sudo apt install -y ccache libnuma-dev python3-setuptools
python3-wheel python3-pip ninja-build libbsd-dev libpcap-dev
--
2.23.0
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH 00/40] net/virtio: Virtio PMD rework
@ 2020-12-20 21:13 2% Maxime Coquelin
2020-12-21 10:58 0% ` [dpdk-dev] [PATCH 00/40] net/virtio: Virtio PMD rework Maxime Coquelin
0 siblings, 2 replies; 200+ results
From: Maxime Coquelin @ 2020-12-20 21:13 UTC (permalink / raw)
To: dev, chenbo.xia, olivier.matz, amorenoz, david.marchand; +Cc: Maxime Coquelin
This series significantly rework Virtio PMD to improve
the Virtio-user PMD and its backends integration.
First part of the series (first 21 patches) removes the
dependency of Virtio-user ethdev on Virtio PCI, by
creating generic files, adding per-bus meta data, ...
Main (if not single) functionnal change of this first
part is to remove the hack for Virtio-user to work in
IOVA as PA mode, this hack being very fragile. Now, the
user has to manually pass --iova-mode=va in EAL
parameters, otherwise vdev probe will fail. In v21.11,
when ABI/API can be changed, I will add vdev driver
flags so that the Virtio-user PMD can request IOVA as VA
mode to be used.
Second part of the series reworks Virtio-user internal,
by reworking the requests handling so that vDPA and Kernel
backends no more hack into being Vhost-user backend. It
implies implementing new ops for all the request types.
Also, all the backend specific actions are moved from the
virtio_user_dev.c and virtio_user_ethdev.c to their
backend files.
Only functionnal change in this second part is making the
Vhost-user server mode blocking at init time, as long as
a client is not connected. The goal of this change is to
make the Vhost-user support much more robust, as without
blocking, the driver has to assume features that are going
to be supported by the client, which is very fragile and
error prone. As a side-effect, it also simplifies the
logic nin several place of the virtio-user PMD.
Plese note that I haven't tested the last 5 patches yet,
I will conduct more testing early next week.
Maxime Coquelin (40):
bus/vdev: add helper to get vdev from eth dev
net/virtio: Introduce Virtio bus type
net/virtio: refactor virtio-user device
net/virtio: introduce PCI device metadata
net/virtio: move PCI device init in dedicated file
net/virtio: move PCI specific dev init to PCI ethdev init
net/virtio: move MSIX detection to PCI ethdev
net/virtio: force IOVA as VA mode for Virtio-user
net/virtio: store PCI type in Virtio device metadata
net/virtio: add callback for device closing
net/virtio: validate features at bus level
net/virtio: remove bus type enum
net/virtio: move PCI-specific fields to PCI device
net/virtio: pack virtio HW struct
net/virtio: move legacy IO to Virtio PCI
net/virtio: introduce generic virtio header
net/virtio: move features definition to generic header
net/virtio: move virtqueue defines in generic header
net/virtio: move config definitions to generic header
net/virtio: make interrupt handling more generic
net/virtio: move vring alignment to generic header
net/virtio: remove last PCI refs in non-PCI code
net/virtio: make Vhost-user req sender consistent
net/virtio: add Virtio-user ops to set owner
net/virtio: add Virtio-user features ops
net/virtio: add Virtio-user protocol features ops
net/virtio: add Virtio-user memory tables ops
net/virtio: add Virtio-user vring setting ops
net/virtio: add Virtio-user vring file ops
net/virtio: add Virtio-user vring address ops
net/virtio: add Virtio-user status ops
net/virtio: remove useless request ops
net/virtio: improve Virtio-user errors handling
net/virtio: move Vhost-user reqs to Vhost-user backend
net/virtio: make server mode blocking
net/virtio: move protocol features to Vhost-user
net/virtio: introduce backend data
net/virtio: move Vhost-user specifics to its backend
net/virtio: move Vhost-kernel data to its backend
net/virtio: move Vhost-vDPA data to its backend
drivers/bus/vdev/rte_bus_vdev.h | 2 +
drivers/net/virtio/meson.build | 6 +-
drivers/net/virtio/virtio.c | 71 ++
drivers/net/virtio/virtio.h | 247 ++++++
drivers/net/virtio/virtio_ethdev.c | 441 +++------
drivers/net/virtio/virtio_ethdev.h | 5 +-
drivers/net/virtio/virtio_pci.c | 399 +++++----
drivers/net/virtio/virtio_pci.h | 286 +-----
drivers/net/virtio/virtio_pci_ethdev.c | 225 +++++
drivers/net/virtio/virtio_ring.h | 2 +-
drivers/net/virtio/virtio_rxtx.c | 90 +-
drivers/net/virtio/virtio_rxtx_packed_avx.c | 18 +-
drivers/net/virtio/virtio_rxtx_simple.h | 3 +-
drivers/net/virtio/virtio_user/vhost.h | 80 +-
drivers/net/virtio/virtio_user/vhost_kernel.c | 435 ++++++---
.../net/virtio/virtio_user/vhost_kernel_tap.c | 25 +-
.../net/virtio/virtio_user/vhost_kernel_tap.h | 1 +
drivers/net/virtio/virtio_user/vhost_user.c | 835 ++++++++++++++----
drivers/net/virtio/virtio_user/vhost_vdpa.c | 257 ++++--
.../net/virtio/virtio_user/virtio_user_dev.c | 490 +++++-----
.../net/virtio/virtio_user/virtio_user_dev.h | 22 +-
drivers/net/virtio/virtio_user_ethdev.c | 304 ++-----
drivers/net/virtio/virtqueue.c | 6 +-
drivers/net/virtio/virtqueue.h | 41 +-
24 files changed, 2481 insertions(+), 1810 deletions(-)
create mode 100644 drivers/net/virtio/virtio.c
create mode 100644 drivers/net/virtio/virtio.h
create mode 100644 drivers/net/virtio/virtio_pci_ethdev.c
--
2.29.2
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [PATCH 00/40] net/virtio: Virtio PMD rework
2020-12-20 21:13 2% [dpdk-dev] [PATCH 00/40] net/virtio: Virtio PMD rework Maxime Coquelin
@ 2020-12-21 10:58 0% ` Maxime Coquelin
1 sibling, 0 replies; 200+ results
From: Maxime Coquelin @ 2020-12-21 10:58 UTC (permalink / raw)
To: dev, chenbo.xia, olivier.matz, amorenoz, david.marchand
On 12/20/20 10:13 PM, Maxime Coquelin wrote:
> This series significantly rework Virtio PMD to improve
> the Virtio-user PMD and its backends integration.
>
> First part of the series (first 21 patches) removes the
> dependency of Virtio-user ethdev on Virtio PCI, by
> creating generic files, adding per-bus meta data, ...
>
> Main (if not single) functionnal change of this first
> part is to remove the hack for Virtio-user to work in
> IOVA as PA mode, this hack being very fragile. Now, the
> user has to manually pass --iova-mode=va in EAL
> parameters, otherwise vdev probe will fail. In v21.11,
> when ABI/API can be changed, I will add vdev driver
> flags so that the Virtio-user PMD can request IOVA as VA
> mode to be used.
>
> Second part of the series reworks Virtio-user internal,
> by reworking the requests handling so that vDPA and Kernel
> backends no more hack into being Vhost-user backend. It
> implies implementing new ops for all the request types.
> Also, all the backend specific actions are moved from the
> virtio_user_dev.c and virtio_user_ethdev.c to their
> backend files.
>
> Only functionnal change in this second part is making the
> Vhost-user server mode blocking at init time, as long as
> a client is not connected. The goal of this change is to
> make the Vhost-user support much more robust, as without
> blocking, the driver has to assume features that are going
> to be supported by the client, which is very fragile and
> error prone. As a side-effect, it also simplifies the
> logic nin several place of the virtio-user PMD.
>
> Plese note that I haven't tested the last 5 patches yet,
> I will conduct more testing early next week.
I forgot to add the remaining things to do in next release:
1. More testing
2. Rebase on top of Vhost-vDPA batching support
3. Rebase on top of Olivier's protocol features fix
4. (Maybe) Loosen restrictions on IOVA as VA mode, by making Vhost-
backend to use IOVA instead of directly VAs, but still warn IOVA
as VA mode is advised to ensure init won't fail.
Regards,
Maxime
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC] mem_debug add more log
@ 2020-12-21 18:44 3% ` Stephen Hemminger
2020-12-25 7:20 3% ` Peng, ZhihongX
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2020-12-21 18:44 UTC (permalink / raw)
To: Peng, ZhihongX
Cc: Wang, Haiyue, Zhang, Qi Z, Xing, Beilei, dev, Lin, Xueqin, Yu, PingX
On Mon, 21 Dec 2020 07:35:10 +0000
"Peng, ZhihongX" <zhihongx.peng@intel.com> wrote:
> 1. I think this implement doesn't add significant overhead. Overhead only will be occurred in rte_malloc and rte_free.
>
> 2. Current existing address sanitizer infrastructure only support libc malloc.
>
> Regards,
> Peng,Zhihong
>
> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Saturday, December 19, 2020 2:54 AM
> To: Peng, ZhihongX <zhihongx.peng@intel.com>
> Cc: Wang, Haiyue <haiyue.wang@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>; Xing, Beilei <beilei.xing@intel.com>; dev@dpdk.org
> Subject: Re: [dpdk-dev] [RFC] mem_debug add more log
>
> On Fri, 18 Dec 2020 14:21:09 -0500
> Peng Zhihong <zhihongx.peng@intel.com> wrote:
>
> > 1. The debugging log in current DPDK RTE_MALLOC_DEBUG mode is insufficient,
> > which makes it difficult to locate the issues, such as:
> > a) When a memeory overlflow occur in rte_free, there is a little log
> > information. Even if abort here, we can find which API is core
> > dumped but we still need to read the source code to find out where
> > the requested memory is overflowed.
> > b) Current DPDK can NOT find that the overflow if the memory has been
> > used and not released.
> > c) If there are two pieces of continuous memory, when the first block
> > is not released and an overflow is occured and also the second block
> > of memory is covered, a memory overflow will be detected once the second
> > block of memory is released. However, current DPDK can not find the
> > correct point of memory overflow. It only detect the memory overflow
> > of the second block but should dedect the one of first block.
> > ----------------------------------------------------------------------------------
> > | header cookie | data1 | trailer cookie | header cookie | data2 |trailer cookie |
> >
> > ----------------------------------------------------------------------
> > ------------ 2. To fix above issues, we can store the requested
> > information When DPDK
> > request memory. Including the requested address and requested momory's
> > file, function and numbers of rows and then put it into a list.
> > -------------------- ---------------------- ----------------------
> > | struct list_head |---->| struct malloc_info |---->| struct malloc_info |
> > -------------------- ---------------------- ----------------------
> > The above 3 problems can be solved through this implementation:
> > a) If there is a memory overflow in rte_free, you can traverse the
> > list to find the information of overflow memory and print the
> > overflow memory information. like this:
> > code:
> > 37 char *p = rte_zmalloc(NULL, 64, 0);
> > 38 memset(p, 0, 65);
> > 39 rte_free(p);
> > 40 //rte_malloc_validate_all_memory();
> > memory error:
> > EAL: Error: Invalid memory
> > malloc memory address 0x17ff2c340 overflow in \
> > file:../examples/helloworld/main.c function:main line:37
> > b)c) Provide a interface to check all memory overflow in function
> > rte_malloc_validate_all_memory, this function will check all
> > memory on the list. Call this funcation manually at the exit
> > point of business logic, we can find all overflow points in time.
> >
> > Signed-off-by: Peng Zhihong <zhihongx.peng@intel.com>
>
> Good concept, but doesn't this add significant overhead?
>
> Maybe we could make rte_malloc work with existing address sanitizer infrastructure in gcc/clang? That would provide faster and more immediate better diagnostic info.
Everybody builds there own custom debug hooks, and some of these are worth sharing.
But lots of time debug code becomes a technical debt, creates API/ABI issues and
causes more trouble than it is worth.
Therefore my desire is for DPDK to be better supported by standard tools such
as valgrind and address sanitizer. The standard tools catch more errors faster and
do not create project maintenance workload.
See:
https://github.com/google/sanitizers/wiki/AddressSanitizerAlgorithm
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v7 1/2] cryptodev: support enqueue and dequeue callback functions
@ 2020-12-22 14:42 2% ` Abhinandan Gujjar
2021-01-04 6:59 0% ` Gujjar, Abhinandan S
0 siblings, 2 replies; 200+ results
From: Abhinandan Gujjar @ 2020-12-22 14:42 UTC (permalink / raw)
To: dev, akhil.goyal, konstantin.ananyev; +Cc: abhinandan.gujjar
This patch adds APIs to add/remove callback functions on crypto
enqueue/dequeue burst. The callback function will be called for
each burst of crypto ops received/sent on a given crypto device
queue pair.
Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
---
config/rte_config.h | 1 +
doc/guides/prog_guide/cryptodev_lib.rst | 44 +++
doc/guides/rel_notes/release_21_02.rst | 9 +
lib/librte_cryptodev/meson.build | 2 +-
lib/librte_cryptodev/rte_cryptodev.c | 398 +++++++++++++++++++++++-
lib/librte_cryptodev/rte_cryptodev.h | 246 ++++++++++++++-
lib/librte_cryptodev/version.map | 7 +
7 files changed, 702 insertions(+), 5 deletions(-)
diff --git a/config/rte_config.h b/config/rte_config.h
index a0b5160ff..87f9786d7 100644
--- a/config/rte_config.h
+++ b/config/rte_config.h
@@ -62,6 +62,7 @@
/* cryptodev defines */
#define RTE_CRYPTO_MAX_DEVS 64
#define RTE_CRYPTODEV_NAME_LEN 64
+#define RTE_CRYPTO_CALLBACKS 1
/* compressdev defines */
#define RTE_COMPRESS_MAX_DEVS 64
diff --git a/doc/guides/prog_guide/cryptodev_lib.rst b/doc/guides/prog_guide/cryptodev_lib.rst
index 473b014a1..9b1cf8d49 100644
--- a/doc/guides/prog_guide/cryptodev_lib.rst
+++ b/doc/guides/prog_guide/cryptodev_lib.rst
@@ -338,6 +338,50 @@ start of private data information. The offset is counted from the start of the
rte_crypto_op including other crypto information such as the IVs (since there can
be an IV also for authentication).
+User callback APIs
+~~~~~~~~~~~~~~~~~~
+The add APIs configures a user callback function to be called for each burst of crypto
+ops received/sent on a given crypto device queue pair. The return value is a pointer
+that can be used later to remove the callback using remove API. Application is expected
+to register a callback function of type ``rte_cryptodev_callback_fn``. Multiple callback
+functions can be added for a given queue pair. API does not restrict on maximum number of
+callbacks.
+
+Callbacks registered by application would not survive ``rte_cryptodev_configure`` as it
+reinitializes the callback list. It is user responsibility to remove all installed
+callbacks before calling ``rte_cryptodev_configure`` to avoid possible memory leakage.
+
+So, the application is expected to add user callback after ``rte_cryptodev_configure``.
+The callbacks can also be added at the runtime. These callbacks get executed when
+``rte_cryptodev_enqueue_burst``/``rte_cryptodev_dequeue_burst`` is called.
+
+.. code-block:: c
+
+ struct rte_cryptodev_cb *
+ rte_cryptodev_add_enq_callback(uint8_t dev_id, uint16_t qp_id,
+ rte_cryptodev_callback_fn cb_fn,
+ void *cb_arg);
+
+ struct rte_cryptodev_cb *
+ rte_cryptodev_add_deq_callback(uint8_t dev_id, uint16_t qp_id,
+ rte_cryptodev_callback_fn cb_fn,
+ void *cb_arg);
+
+ uint16_t (* rte_cryptodev_callback_fn)(uint16_t dev_id, uint16_t qp_id,
+ struct rte_crypto_op **ops,
+ uint16_t nb_ops, void *user_param);
+
+The remove API removes a callback function added by
+``rte_cryptodev_add_enq_callback``/``rte_cryptodev_add_deq_callback``.
+
+.. code-block:: c
+
+ int rte_cryptodev_remove_enq_callback(uint8_t dev_id, uint16_t qp_id,
+ struct rte_cryptodev_cb *cb);
+
+ int rte_cryptodev_remove_deq_callback(uint8_t dev_id, uint16_t qp_id,
+ struct rte_cryptodev_cb *cb);
+
Enqueue / Dequeue Burst APIs
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/doc/guides/rel_notes/release_21_02.rst b/doc/guides/rel_notes/release_21_02.rst
index 638f98168..8c7866401 100644
--- a/doc/guides/rel_notes/release_21_02.rst
+++ b/doc/guides/rel_notes/release_21_02.rst
@@ -55,6 +55,13 @@ New Features
Also, make sure to start the actual text at the margin.
=======================================================
+* **Added enqueue & dequeue callback APIs for cryptodev library.**
+
+ Cryptodev library is added with enqueue & dequeue callback APIs to
+ enable applications to add/remove user callbacks which gets called
+ for every enqueue/dequeue operation.
+
+
Removed Items
-------------
@@ -84,6 +91,8 @@ API Changes
Also, make sure to start the actual text at the margin.
=======================================================
+* cryptodev: The structure ``rte_cryptodev`` has been updated with pointers
+ for adding enqueue and dequeue callbacks.
ABI Changes
-----------
diff --git a/lib/librte_cryptodev/meson.build b/lib/librte_cryptodev/meson.build
index c4c6b3b6a..8c5493f4c 100644
--- a/lib/librte_cryptodev/meson.build
+++ b/lib/librte_cryptodev/meson.build
@@ -9,4 +9,4 @@ headers = files('rte_cryptodev.h',
'rte_crypto.h',
'rte_crypto_sym.h',
'rte_crypto_asym.h')
-deps += ['kvargs', 'mbuf']
+deps += ['kvargs', 'mbuf', 'rcu']
diff --git a/lib/librte_cryptodev/rte_cryptodev.c b/lib/librte_cryptodev/rte_cryptodev.c
index 3d95ac6ea..40f55a3cd 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -448,6 +448,122 @@ rte_cryptodev_asym_xform_capability_check_modlen(
return 0;
}
+/* spinlock for crypto device enq callbacks */
+static rte_spinlock_t rte_cryptodev_callback_lock = RTE_SPINLOCK_INITIALIZER;
+
+static void
+cryptodev_cb_cleanup(struct rte_cryptodev *dev)
+{
+ struct rte_cryptodev_cb_rcu *list;
+ struct rte_cryptodev_cb *cb, *next;
+ uint16_t qp_id;
+
+ if (dev->enq_cbs == NULL && dev->deq_cbs == NULL)
+ return;
+
+ for (qp_id = 0; qp_id < dev->data->nb_queue_pairs; qp_id++) {
+ list = &dev->enq_cbs[qp_id];
+ cb = list->next;
+ while (cb != NULL) {
+ next = cb->next;
+ rte_free(cb);
+ cb = next;
+ }
+
+ rte_free(list->qsbr);
+ }
+
+ for (qp_id = 0; qp_id < dev->data->nb_queue_pairs; qp_id++) {
+ list = &dev->deq_cbs[qp_id];
+ cb = list->next;
+ while (cb != NULL) {
+ next = cb->next;
+ rte_free(cb);
+ cb = next;
+ }
+
+ rte_free(list->qsbr);
+ }
+
+ rte_free(dev->enq_cbs);
+ dev->enq_cbs = NULL;
+ rte_free(dev->deq_cbs);
+ dev->deq_cbs = NULL;
+}
+
+static int
+cryptodev_cb_init(struct rte_cryptodev *dev)
+{
+ struct rte_cryptodev_cb_rcu *list;
+ struct rte_rcu_qsbr *qsbr;
+ uint16_t qp_id;
+ size_t size;
+
+ /* Max thread set to 1, as one DP thread accessing a queue-pair */
+ const uint32_t max_threads = 1;
+
+ dev->enq_cbs = rte_zmalloc(NULL,
+ sizeof(struct rte_cryptodev_cb_rcu) *
+ dev->data->nb_queue_pairs, 0);
+ if (dev->enq_cbs == NULL) {
+ CDEV_LOG_ERR("Failed to allocate memory for enq callbacks");
+ return -ENOMEM;
+ }
+
+ dev->deq_cbs = rte_zmalloc(NULL,
+ sizeof(struct rte_cryptodev_cb_rcu) *
+ dev->data->nb_queue_pairs, 0);
+ if (dev->deq_cbs == NULL) {
+ CDEV_LOG_ERR("Failed to allocate memory for deq callbacks");
+ rte_free(dev->enq_cbs);
+ return -ENOMEM;
+ }
+
+ /* Create RCU QSBR variable */
+ size = rte_rcu_qsbr_get_memsize(max_threads);
+
+ for (qp_id = 0; qp_id < dev->data->nb_queue_pairs; qp_id++) {
+ list = &dev->enq_cbs[qp_id];
+ qsbr = rte_zmalloc(NULL, size, RTE_CACHE_LINE_SIZE);
+ if (qsbr == NULL) {
+ CDEV_LOG_ERR("Failed to allocate memory for RCU on "
+ "queue_pair_id=%d", qp_id);
+ goto cb_init_err;
+ }
+
+ if (rte_rcu_qsbr_init(qsbr, max_threads)) {
+ CDEV_LOG_ERR("Failed to initialize for RCU on "
+ "queue_pair_id=%d", qp_id);
+ goto cb_init_err;
+ }
+
+ list->qsbr = qsbr;
+ }
+
+ for (qp_id = 0; qp_id < dev->data->nb_queue_pairs; qp_id++) {
+ list = &dev->deq_cbs[qp_id];
+ qsbr = rte_zmalloc(NULL, size, RTE_CACHE_LINE_SIZE);
+ if (qsbr == NULL) {
+ CDEV_LOG_ERR("Failed to allocate memory for RCU on "
+ "queue_pair_id=%d", qp_id);
+ goto cb_init_err;
+ }
+
+ if (rte_rcu_qsbr_init(qsbr, max_threads)) {
+ CDEV_LOG_ERR("Failed to initialize for RCU on "
+ "queue_pair_id=%d", qp_id);
+ goto cb_init_err;
+ }
+
+ list->qsbr = qsbr;
+ }
+
+ return 0;
+
+cb_init_err:
+ cryptodev_cb_cleanup(dev);
+ return -ENOMEM;
+}
const char *
rte_cryptodev_get_feature_name(uint64_t flag)
@@ -927,6 +1043,10 @@ rte_cryptodev_configure(uint8_t dev_id, struct rte_cryptodev_config *config)
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_configure, -ENOTSUP);
+ rte_spinlock_lock(&rte_cryptodev_callback_lock);
+ cryptodev_cb_cleanup(dev);
+ rte_spinlock_unlock(&rte_cryptodev_callback_lock);
+
/* Setup new number of queue pairs and reconfigure device. */
diag = rte_cryptodev_queue_pairs_config(dev, config->nb_queue_pairs,
config->socket_id);
@@ -936,11 +1056,18 @@ rte_cryptodev_configure(uint8_t dev_id, struct rte_cryptodev_config *config)
return diag;
}
+ rte_spinlock_lock(&rte_cryptodev_callback_lock);
+ diag = cryptodev_cb_init(dev);
+ rte_spinlock_unlock(&rte_cryptodev_callback_lock);
+ if (diag) {
+ CDEV_LOG_ERR("Callback init failed for dev_id=%d", dev_id);
+ return diag;
+ }
+
rte_cryptodev_trace_configure(dev_id, config);
return (*dev->dev_ops->dev_configure)(dev, config);
}
-
int
rte_cryptodev_start(uint8_t dev_id)
{
@@ -1136,6 +1263,275 @@ rte_cryptodev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
socket_id);
}
+struct rte_cryptodev_cb *
+rte_cryptodev_add_enq_callback(uint8_t dev_id,
+ uint16_t qp_id,
+ rte_cryptodev_callback_fn cb_fn,
+ void *cb_arg)
+{
+ struct rte_cryptodev *dev;
+ struct rte_cryptodev_cb_rcu *list;
+ struct rte_cryptodev_cb *cb, *tail;
+
+ if (!cb_fn) {
+ CDEV_LOG_ERR("Callback is NULL on dev_id=%d", dev_id);
+ rte_errno = EINVAL;
+ return NULL;
+ }
+
+ if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
+ CDEV_LOG_ERR("Invalid dev_id=%d", dev_id);
+ rte_errno = ENODEV;
+ return NULL;
+ }
+
+ dev = &rte_crypto_devices[dev_id];
+ if (qp_id >= dev->data->nb_queue_pairs) {
+ CDEV_LOG_ERR("Invalid queue_pair_id=%d", qp_id);
+ rte_errno = ENODEV;
+ return NULL;
+ }
+
+ cb = rte_zmalloc(NULL, sizeof(*cb), 0);
+ if (cb == NULL) {
+ CDEV_LOG_ERR("Failed to allocate memory for callback on "
+ "dev=%d, queue_pair_id=%d", dev_id, qp_id);
+ rte_errno = ENOMEM;
+ return NULL;
+ }
+
+ rte_spinlock_lock(&rte_cryptodev_callback_lock);
+
+ cb->fn = cb_fn;
+ cb->arg = cb_arg;
+
+ /* Add the callbacks in fifo order. */
+ list = &dev->enq_cbs[qp_id];
+ tail = list->next;
+
+ if (tail) {
+ while (tail->next)
+ tail = tail->next;
+ /* Stores to cb->fn and cb->param should complete before
+ * cb is visible to data plane.
+ */
+ __atomic_store_n(&tail->next, cb, __ATOMIC_RELEASE);
+ } else {
+ /* Stores to cb->fn and cb->param should complete before
+ * cb is visible to data plane.
+ */
+ __atomic_store_n(&list->next, cb, __ATOMIC_RELEASE);
+ }
+
+ rte_spinlock_unlock(&rte_cryptodev_callback_lock);
+
+ return cb;
+}
+
+int
+rte_cryptodev_remove_enq_callback(uint8_t dev_id,
+ uint16_t qp_id,
+ struct rte_cryptodev_cb *cb)
+{
+ struct rte_cryptodev *dev;
+ struct rte_cryptodev_cb **prev_cb, *curr_cb;
+ struct rte_cryptodev_cb_rcu *list;
+ int ret;
+
+ ret = -EINVAL;
+
+ if (!cb) {
+ CDEV_LOG_ERR("Callback is NULL");
+ return -EINVAL;
+ }
+
+ if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
+ CDEV_LOG_ERR("Invalid dev_id=%d", dev_id);
+ return -ENODEV;
+ }
+
+ dev = &rte_crypto_devices[dev_id];
+ if (qp_id >= dev->data->nb_queue_pairs) {
+ CDEV_LOG_ERR("Invalid queue_pair_id=%d", qp_id);
+ return -ENODEV;
+ }
+
+ rte_spinlock_lock(&rte_cryptodev_callback_lock);
+ if (dev->enq_cbs == NULL) {
+ CDEV_LOG_ERR("Callback not initialized");
+ goto cb_err;
+ }
+
+ list = &dev->enq_cbs[qp_id];
+ if (list == NULL) {
+ CDEV_LOG_ERR("Callback list is NULL");
+ goto cb_err;
+ }
+
+ if (list->qsbr == NULL) {
+ CDEV_LOG_ERR("Rcu qsbr is NULL");
+ goto cb_err;
+ }
+
+ prev_cb = &list->next;
+ for (; *prev_cb != NULL; prev_cb = &curr_cb->next) {
+ curr_cb = *prev_cb;
+ if (curr_cb == cb) {
+ /* Remove the user cb from the callback list. */
+ __atomic_store_n(prev_cb, curr_cb->next,
+ __ATOMIC_RELAXED);
+ ret = 0;
+ break;
+ }
+ }
+
+ if (!ret) {
+ /* Call sync with invalid thread id as this is part of
+ * control plane API
+ */
+ rte_rcu_qsbr_synchronize(list->qsbr, RTE_QSBR_THRID_INVALID);
+ rte_free(cb);
+ }
+
+cb_err:
+ rte_spinlock_unlock(&rte_cryptodev_callback_lock);
+ return ret;
+}
+
+struct rte_cryptodev_cb *
+rte_cryptodev_add_deq_callback(uint8_t dev_id,
+ uint16_t qp_id,
+ rte_cryptodev_callback_fn cb_fn,
+ void *cb_arg)
+{
+ struct rte_cryptodev *dev;
+ struct rte_cryptodev_cb_rcu *list;
+ struct rte_cryptodev_cb *cb, *tail;
+
+ if (!cb_fn) {
+ CDEV_LOG_ERR("Callback is NULL on dev_id=%d", dev_id);
+ rte_errno = EINVAL;
+ return NULL;
+ }
+
+ if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
+ CDEV_LOG_ERR("Invalid dev_id=%d", dev_id);
+ rte_errno = ENODEV;
+ return NULL;
+ }
+
+ dev = &rte_crypto_devices[dev_id];
+ if (qp_id >= dev->data->nb_queue_pairs) {
+ CDEV_LOG_ERR("Invalid queue_pair_id=%d", qp_id);
+ rte_errno = ENODEV;
+ return NULL;
+ }
+
+ cb = rte_zmalloc(NULL, sizeof(*cb), 0);
+ if (cb == NULL) {
+ CDEV_LOG_ERR("Failed to allocate memory for callback on "
+ "dev=%d, queue_pair_id=%d", dev_id, qp_id);
+ rte_errno = ENOMEM;
+ return NULL;
+ }
+
+ rte_spinlock_lock(&rte_cryptodev_callback_lock);
+
+ cb->fn = cb_fn;
+ cb->arg = cb_arg;
+
+ /* Add the callbacks in fifo order. */
+ list = &dev->deq_cbs[qp_id];
+ tail = list->next;
+
+ if (tail) {
+ while (tail->next)
+ tail = tail->next;
+ /* Stores to cb->fn and cb->param should complete before
+ * cb is visible to data plane.
+ */
+ __atomic_store_n(&tail->next, cb, __ATOMIC_RELEASE);
+ } else {
+ /* Stores to cb->fn and cb->param should complete before
+ * cb is visible to data plane.
+ */
+ __atomic_store_n(&list->next, cb, __ATOMIC_RELEASE);
+ }
+
+ rte_spinlock_unlock(&rte_cryptodev_callback_lock);
+
+ return cb;
+}
+
+int
+rte_cryptodev_remove_deq_callback(uint8_t dev_id,
+ uint16_t qp_id,
+ struct rte_cryptodev_cb *cb)
+{
+ struct rte_cryptodev *dev;
+ struct rte_cryptodev_cb **prev_cb, *curr_cb;
+ struct rte_cryptodev_cb_rcu *list;
+ int ret;
+
+ ret = -EINVAL;
+
+ if (!cb) {
+ CDEV_LOG_ERR("Callback is NULL");
+ return -EINVAL;
+ }
+
+ if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
+ CDEV_LOG_ERR("Invalid dev_id=%d", dev_id);
+ return -ENODEV;
+ }
+
+ dev = &rte_crypto_devices[dev_id];
+ if (qp_id >= dev->data->nb_queue_pairs) {
+ CDEV_LOG_ERR("Invalid queue_pair_id=%d", qp_id);
+ return -ENODEV;
+ }
+
+ rte_spinlock_lock(&rte_cryptodev_callback_lock);
+ if (dev->enq_cbs == NULL) {
+ CDEV_LOG_ERR("Callback not initialized");
+ goto cb_err;
+ }
+
+ list = &dev->deq_cbs[qp_id];
+ if (list == NULL) {
+ CDEV_LOG_ERR("Callback list is NULL");
+ goto cb_err;
+ }
+
+ if (list->qsbr == NULL) {
+ CDEV_LOG_ERR("Rcu qsbr is NULL");
+ goto cb_err;
+ }
+
+ prev_cb = &list->next;
+ for (; *prev_cb != NULL; prev_cb = &curr_cb->next) {
+ curr_cb = *prev_cb;
+ if (curr_cb == cb) {
+ /* Remove the user cb from the callback list. */
+ __atomic_store_n(prev_cb, curr_cb->next,
+ __ATOMIC_RELAXED);
+ ret = 0;
+ break;
+ }
+ }
+
+ if (!ret) {
+ /* Call sync with invalid thread id as this is part of
+ * control plane API
+ */
+ rte_rcu_qsbr_synchronize(list->qsbr, RTE_QSBR_THRID_INVALID);
+ rte_free(cb);
+ }
+
+cb_err:
+ rte_spinlock_unlock(&rte_cryptodev_callback_lock);
+ return ret;
+}
int
rte_cryptodev_stats_get(uint8_t dev_id, struct rte_cryptodev_stats *stats)
diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h
index 0935fd587..ae34f33f6 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -23,6 +23,7 @@ extern "C" {
#include "rte_dev.h"
#include <rte_common.h>
#include <rte_config.h>
+#include <rte_rcu_qsbr.h>
#include "rte_cryptodev_trace_fp.h"
@@ -522,6 +523,30 @@ struct rte_cryptodev_qp_conf {
/**< The mempool for creating sess private data in sessionless mode */
};
+/**
+ * Function type used for processing crypto ops when enqueue/dequeue burst is
+ * called.
+ *
+ * The callback function is called on enqueue/dequeue burst immediately.
+ *
+ * @param dev_id The identifier of the device.
+ * @param qp_id The index of the queue pair on which ops are
+ * enqueued/dequeued. The value must be in the
+ * range [0, nb_queue_pairs - 1] previously
+ * supplied to *rte_cryptodev_configure*.
+ * @param ops The address of an array of *nb_ops* pointers
+ * to *rte_crypto_op* structures which contain
+ * the crypto operations to be processed.
+ * @param nb_ops The number of operations to process.
+ * @param user_param The arbitrary user parameter passed in by the
+ * application when the callback was originally
+ * registered.
+ * @return The number of ops to be enqueued to the
+ * crypto device.
+ */
+typedef uint16_t (*rte_cryptodev_callback_fn)(uint16_t dev_id, uint16_t qp_id,
+ struct rte_crypto_op **ops, uint16_t nb_ops, void *user_param);
+
/**
* Typedef for application callback function to be registered by application
* software for notification of device events
@@ -822,7 +847,6 @@ rte_cryptodev_callback_unregister(uint8_t dev_id,
enum rte_cryptodev_event_type event,
rte_cryptodev_cb_fn cb_fn, void *cb_arg);
-
typedef uint16_t (*dequeue_pkt_burst_t)(void *qp,
struct rte_crypto_op **ops, uint16_t nb_ops);
/**< Dequeue processed packets from queue pair of a device. */
@@ -839,6 +863,30 @@ struct rte_cryptodev_callback;
/** Structure to keep track of registered callbacks */
TAILQ_HEAD(rte_cryptodev_cb_list, rte_cryptodev_callback);
+/**
+ * Structure used to hold information about the callbacks to be called for a
+ * queue pair on enqueue/dequeue.
+ */
+struct rte_cryptodev_cb {
+ struct rte_cryptodev_cb *next;
+ /**< Pointer to next callback */
+ rte_cryptodev_callback_fn fn;
+ /**< Pointer to callback function */
+ void *arg;
+ /**< Pointer to argument */
+};
+
+/**
+ * @internal
+ * Structure used to hold information about the RCU for a queue pair.
+ */
+struct rte_cryptodev_cb_rcu {
+ struct rte_cryptodev_cb *next;
+ /**< Pointer to next callback */
+ struct rte_rcu_qsbr *qsbr;
+ /**< RCU QSBR variable per queue pair */
+};
+
/** The data structure associated with each crypto device. */
struct rte_cryptodev {
dequeue_pkt_burst_t dequeue_burst;
@@ -867,6 +915,12 @@ struct rte_cryptodev {
__extension__
uint8_t attached : 1;
/**< Flag indicating the device is attached */
+
+ struct rte_cryptodev_cb_rcu *enq_cbs;
+ /**< User application callback for pre enqueue processing */
+
+ struct rte_cryptodev_cb_rcu *deq_cbs;
+ /**< User application callback for post dequeue processing */
} __rte_cache_aligned;
void *
@@ -945,10 +999,33 @@ rte_cryptodev_dequeue_burst(uint8_t dev_id, uint16_t qp_id,
{
struct rte_cryptodev *dev = &rte_cryptodevs[dev_id];
+ rte_cryptodev_trace_dequeue_burst(dev_id, qp_id, (void **)ops, nb_ops);
nb_ops = (*dev->dequeue_burst)
(dev->data->queue_pairs[qp_id], ops, nb_ops);
-
- rte_cryptodev_trace_dequeue_burst(dev_id, qp_id, (void **)ops, nb_ops);
+#ifdef RTE_CRYPTO_CALLBACKS
+ if (unlikely(dev->deq_cbs != NULL)) {
+ struct rte_cryptodev_cb_rcu *list;
+ struct rte_cryptodev_cb *cb;
+
+ /* __ATOMIC_RELEASE memory order was used when the
+ * call back was inserted into the list.
+ * Since there is a clear dependency between loading
+ * cb and cb->fn/cb->next, __ATOMIC_ACQUIRE memory order is
+ * not required.
+ */
+ list = &dev->deq_cbs[qp_id];
+ rte_rcu_qsbr_thread_online(list->qsbr, 0);
+ cb = __atomic_load_n(&list->next, __ATOMIC_RELAXED);
+
+ while (cb != NULL) {
+ nb_ops = cb->fn(dev_id, qp_id, ops, nb_ops,
+ cb->arg);
+ cb = cb->next;
+ };
+
+ rte_rcu_qsbr_thread_offline(list->qsbr, 0);
+ }
+#endif
return nb_ops;
}
@@ -989,6 +1066,31 @@ rte_cryptodev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
{
struct rte_cryptodev *dev = &rte_cryptodevs[dev_id];
+#ifdef RTE_CRYPTO_CALLBACKS
+ if (unlikely(dev->enq_cbs != NULL)) {
+ struct rte_cryptodev_cb_rcu *list;
+ struct rte_cryptodev_cb *cb;
+
+ /* __ATOMIC_RELEASE memory order was used when the
+ * call back was inserted into the list.
+ * Since there is a clear dependency between loading
+ * cb and cb->fn/cb->next, __ATOMIC_ACQUIRE memory order is
+ * not required.
+ */
+ list = &dev->enq_cbs[qp_id];
+ rte_rcu_qsbr_thread_online(list->qsbr, 0);
+ cb = __atomic_load_n(&list->next, __ATOMIC_RELAXED);
+
+ while (cb != NULL) {
+ nb_ops = cb->fn(dev_id, qp_id, ops, nb_ops,
+ cb->arg);
+ cb = cb->next;
+ };
+
+ rte_rcu_qsbr_thread_offline(list->qsbr, 0);
+ }
+#endif
+
rte_cryptodev_trace_enqueue_burst(dev_id, qp_id, (void **)ops, nb_ops);
return (*dev->enqueue_burst)(
dev->data->queue_pairs[qp_id], ops, nb_ops);
@@ -1730,6 +1832,144 @@ int
rte_cryptodev_raw_dequeue_done(struct rte_crypto_raw_dp_ctx *ctx,
uint32_t n);
+/**
+ * Add a user callback for a given crypto device and queue pair which will be
+ * called on crypto ops enqueue.
+ *
+ * This API configures a function to be called for each burst of crypto ops
+ * received on a given crypto device queue pair. The return value is a pointer
+ * that can be used later to remove the callback using
+ * rte_cryptodev_remove_enq_callback().
+ *
+ * Callbacks registered by application would not survive
+ * rte_cryptodev_configure() as it reinitializes the callback list.
+ * It is user responsibility to remove all installed callbacks before
+ * calling rte_cryptodev_configure() to avoid possible memory leakage.
+ * Application is expected to call add API after rte_cryptodev_configure().
+ *
+ * Multiple functions can be registered per queue pair & they are called
+ * in the order they were added. The API does not restrict on maximum number
+ * of callbacks.
+ *
+ * @param dev_id The identifier of the device.
+ * @param qp_id The index of the queue pair on which ops are
+ * to be enqueued for processing. The value
+ * must be in the range [0, nb_queue_pairs - 1]
+ * previously supplied to
+ * *rte_cryptodev_configure*.
+ * @param cb_fn The callback function
+ * @param cb_arg A generic pointer parameter which will be passed
+ * to each invocation of the callback function on
+ * this crypto device and queue pair.
+ *
+ * @return
+ * - NULL on error & rte_errno will contain the error code.
+ * - On success, a pointer value which can later be used to remove the
+ * callback.
+ */
+
+__rte_experimental
+struct rte_cryptodev_cb *
+rte_cryptodev_add_enq_callback(uint8_t dev_id,
+ uint16_t qp_id,
+ rte_cryptodev_callback_fn cb_fn,
+ void *cb_arg);
+
+/**
+ * Remove a user callback function for given crypto device and queue pair.
+ *
+ * This function is used to remove enqueue callbacks that were added to a
+ * crypto device queue pair using rte_cryptodev_add_enq_callback().
+ *
+ *
+ *
+ * @param dev_id The identifier of the device.
+ * @param qp_id The index of the queue pair on which ops are
+ * to be enqueued. The value must be in the
+ * range [0, nb_queue_pairs - 1] previously
+ * supplied to *rte_cryptodev_configure*.
+ * @param cb Pointer to user supplied callback created via
+ * rte_cryptodev_add_enq_callback().
+ *
+ * @return
+ * - 0: Success. Callback was removed.
+ * - <0: The dev_id or the qp_id is out of range, or the callback
+ * is NULL or not found for the crypto device queue pair.
+ */
+
+__rte_experimental
+int rte_cryptodev_remove_enq_callback(uint8_t dev_id,
+ uint16_t qp_id,
+ struct rte_cryptodev_cb *cb);
+
+/**
+ * Add a user callback for a given crypto device and queue pair which will be
+ * called on crypto ops dequeue.
+ *
+ * This API configures a function to be called for each burst of crypto ops
+ * received on a given crypto device queue pair. The return value is a pointer
+ * that can be used later to remove the callback using
+ * rte_cryptodev_remove_deq_callback().
+ *
+ * Callbacks registered by application would not survive
+ * rte_cryptodev_configure() as it reinitializes the callback list.
+ * It is user responsibility to remove all installed callbacks before
+ * calling rte_cryptodev_configure() to avoid possible memory leakage.
+ * Application is expected to call add API after rte_cryptodev_configure().
+ *
+ * Multiple functions can be registered per queue pair & they are called
+ * in the order they were added. The API does not restrict on maximum number
+ * of callbacks.
+ *
+ * @param dev_id The identifier of the device.
+ * @param qp_id The index of the queue pair on which ops are
+ * to be dequeued. The value must be in the
+ * range [0, nb_queue_pairs - 1] previously
+ * supplied to *rte_cryptodev_configure*.
+ * @param cb_fn The callback function
+ * @param cb_arg A generic pointer parameter which will be passed
+ * to each invocation of the callback function on
+ * this crypto device and queue pair.
+ *
+ * @return
+ * - NULL on error & rte_errno will contain the error code.
+ * - On success, a pointer value which can later be used to remove the
+ * callback.
+ */
+
+__rte_experimental
+struct rte_cryptodev_cb *
+rte_cryptodev_add_deq_callback(uint8_t dev_id,
+ uint16_t qp_id,
+ rte_cryptodev_callback_fn cb_fn,
+ void *cb_arg);
+
+/**
+ * Remove a user callback function for given crypto device and queue pair.
+ *
+ * This function is used to remove dequeue callbacks that were added to a
+ * crypto device queue pair using rte_cryptodev_add_deq_callback().
+ *
+ *
+ *
+ * @param dev_id The identifier of the device.
+ * @param qp_id The index of the queue pair on which ops are
+ * to be dequeued. The value must be in the
+ * range [0, nb_queue_pairs - 1] previously
+ * supplied to *rte_cryptodev_configure*.
+ * @param cb Pointer to user supplied callback created via
+ * rte_cryptodev_add_deq_callback().
+ *
+ * @return
+ * - 0: Success. Callback was removed.
+ * - <0: The dev_id or the qp_id is out of range, or the callback
+ * is NULL or not found for the crypto device queue pair.
+ */
+__rte_experimental
+int rte_cryptodev_remove_deq_callback(uint8_t dev_id,
+ uint16_t qp_id,
+ struct rte_cryptodev_cb *cb);
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_cryptodev/version.map b/lib/librte_cryptodev/version.map
index 7e4360ff0..9f04737ae 100644
--- a/lib/librte_cryptodev/version.map
+++ b/lib/librte_cryptodev/version.map
@@ -109,4 +109,11 @@ EXPERIMENTAL {
rte_cryptodev_raw_enqueue;
rte_cryptodev_raw_enqueue_burst;
rte_cryptodev_raw_enqueue_done;
+
+ # added in 21.02
+ rte_cryptodev_add_deq_callback;
+ rte_cryptodev_add_enq_callback;
+ rte_cryptodev_remove_deq_callback;
+ rte_cryptodev_remove_enq_callback;
+
};
--
2.25.1
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [RFC] mem_debug add more log
2020-12-21 18:44 3% ` Stephen Hemminger
@ 2020-12-25 7:20 3% ` Peng, ZhihongX
0 siblings, 0 replies; 200+ results
From: Peng, ZhihongX @ 2020-12-25 7:20 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Wang, Haiyue, Zhang, Qi Z, Xing, Beilei, dev, Lin, Xueqin, Yu, PingX
The performance of our simple scheme is better than asan. We are trying the asan solution.
Regards,
Peng,Zhihong
-----Original Message-----
From: Stephen Hemminger <stephen@networkplumber.org>
Sent: Tuesday, December 22, 2020 2:44 AM
To: Peng, ZhihongX <zhihongx.peng@intel.com>
Cc: Wang, Haiyue <haiyue.wang@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>; Xing, Beilei <beilei.xing@intel.com>; dev@dpdk.org; Lin, Xueqin <xueqin.lin@intel.com>; Yu, PingX <pingx.yu@intel.com>
Subject: Re: [dpdk-dev] [RFC] mem_debug add more log
On Mon, 21 Dec 2020 07:35:10 +0000
"Peng, ZhihongX" <zhihongx.peng@intel.com> wrote:
> 1. I think this implement doesn't add significant overhead. Overhead only will be occurred in rte_malloc and rte_free.
>
> 2. Current existing address sanitizer infrastructure only support libc malloc.
>
> Regards,
> Peng,Zhihong
>
> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Saturday, December 19, 2020 2:54 AM
> To: Peng, ZhihongX <zhihongx.peng@intel.com>
> Cc: Wang, Haiyue <haiyue.wang@intel.com>; Zhang, Qi Z
> <qi.z.zhang@intel.com>; Xing, Beilei <beilei.xing@intel.com>;
> dev@dpdk.org
> Subject: Re: [dpdk-dev] [RFC] mem_debug add more log
>
> On Fri, 18 Dec 2020 14:21:09 -0500
> Peng Zhihong <zhihongx.peng@intel.com> wrote:
>
> > 1. The debugging log in current DPDK RTE_MALLOC_DEBUG mode is insufficient,
> > which makes it difficult to locate the issues, such as:
> > a) When a memeory overlflow occur in rte_free, there is a little log
> > information. Even if abort here, we can find which API is core
> > dumped but we still need to read the source code to find out where
> > the requested memory is overflowed.
> > b) Current DPDK can NOT find that the overflow if the memory has been
> > used and not released.
> > c) If there are two pieces of continuous memory, when the first block
> > is not released and an overflow is occured and also the second block
> > of memory is covered, a memory overflow will be detected once the second
> > block of memory is released. However, current DPDK can not find the
> > correct point of memory overflow. It only detect the memory overflow
> > of the second block but should dedect the one of first block.
> > ----------------------------------------------------------------------------------
> > | header cookie | data1 | trailer cookie | header cookie |
> > data2 |trailer cookie |
> >
> > --------------------------------------------------------------------
> > --
> > ------------ 2. To fix above issues, we can store the requested
> > information When DPDK
> > request memory. Including the requested address and requested momory's
> > file, function and numbers of rows and then put it into a list.
> > -------------------- ---------------------- ----------------------
> > | struct list_head |---->| struct malloc_info |---->| struct malloc_info |
> > -------------------- ---------------------- ----------------------
> > The above 3 problems can be solved through this implementation:
> > a) If there is a memory overflow in rte_free, you can traverse the
> > list to find the information of overflow memory and print the
> > overflow memory information. like this:
> > code:
> > 37 char *p = rte_zmalloc(NULL, 64, 0);
> > 38 memset(p, 0, 65);
> > 39 rte_free(p);
> > 40 //rte_malloc_validate_all_memory();
> > memory error:
> > EAL: Error: Invalid memory
> > malloc memory address 0x17ff2c340 overflow in \
> > file:../examples/helloworld/main.c function:main line:37
> > b)c) Provide a interface to check all memory overflow in function
> > rte_malloc_validate_all_memory, this function will check all
> > memory on the list. Call this funcation manually at the exit
> > point of business logic, we can find all overflow points in time.
> >
> > Signed-off-by: Peng Zhihong <zhihongx.peng@intel.com>
>
> Good concept, but doesn't this add significant overhead?
>
> Maybe we could make rte_malloc work with existing address sanitizer infrastructure in gcc/clang? That would provide faster and more immediate better diagnostic info.
Everybody builds there own custom debug hooks, and some of these are worth sharing.
But lots of time debug code becomes a technical debt, creates API/ABI issues and causes more trouble than it is worth.
Therefore my desire is for DPDK to be better supported by standard tools such as valgrind and address sanitizer. The standard tools catch more errors faster and do not create project maintenance workload.
See:
https://github.com/google/sanitizers/wiki/AddressSanitizerAlgorithm
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v7 1/2] cryptodev: support enqueue and dequeue callback functions
2020-12-22 14:42 2% ` [dpdk-dev] [PATCH v7 1/2] cryptodev: support enqueue and dequeue callback functions Abhinandan Gujjar
@ 2021-01-04 6:59 0% ` Gujjar, Abhinandan S
1 sibling, 0 replies; 200+ results
From: Gujjar, Abhinandan S @ 2021-01-04 6:59 UTC (permalink / raw)
To: dev, akhil.goyal, Ananyev, Konstantin
Hi Akhil,
Could you please review the patches?
Regards
Abhinandan
> -----Original Message-----
> From: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>
> Sent: Tuesday, December 22, 2020 8:13 PM
> To: dev@dpdk.org; akhil.goyal@nxp.com; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>
> Cc: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>
> Subject: [PATCH v7 1/2] cryptodev: support enqueue and dequeue callback
> functions
>
> This patch adds APIs to add/remove callback functions on crypto
> enqueue/dequeue burst. The callback function will be called for each burst of
> crypto ops received/sent on a given crypto device queue pair.
>
> Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> ---
> config/rte_config.h | 1 +
> doc/guides/prog_guide/cryptodev_lib.rst | 44 +++
> doc/guides/rel_notes/release_21_02.rst | 9 +
> lib/librte_cryptodev/meson.build | 2 +-
> lib/librte_cryptodev/rte_cryptodev.c | 398 +++++++++++++++++++++++-
> lib/librte_cryptodev/rte_cryptodev.h | 246 ++++++++++++++-
> lib/librte_cryptodev/version.map | 7 +
> 7 files changed, 702 insertions(+), 5 deletions(-)
>
> diff --git a/config/rte_config.h b/config/rte_config.h index
> a0b5160ff..87f9786d7 100644
> --- a/config/rte_config.h
> +++ b/config/rte_config.h
> @@ -62,6 +62,7 @@
> /* cryptodev defines */
> #define RTE_CRYPTO_MAX_DEVS 64
> #define RTE_CRYPTODEV_NAME_LEN 64
> +#define RTE_CRYPTO_CALLBACKS 1
>
> /* compressdev defines */
> #define RTE_COMPRESS_MAX_DEVS 64
> diff --git a/doc/guides/prog_guide/cryptodev_lib.rst
> b/doc/guides/prog_guide/cryptodev_lib.rst
> index 473b014a1..9b1cf8d49 100644
> --- a/doc/guides/prog_guide/cryptodev_lib.rst
> +++ b/doc/guides/prog_guide/cryptodev_lib.rst
> @@ -338,6 +338,50 @@ start of private data information. The offset is counted
> from the start of the rte_crypto_op including other crypto information such as
> the IVs (since there can be an IV also for authentication).
>
> +User callback APIs
> +~~~~~~~~~~~~~~~~~~
> +The add APIs configures a user callback function to be called for each
> +burst of crypto ops received/sent on a given crypto device queue pair.
> +The return value is a pointer that can be used later to remove the
> +callback using remove API. Application is expected to register a
> +callback function of type ``rte_cryptodev_callback_fn``. Multiple
> +callback functions can be added for a given queue pair. API does not restrict
> on maximum number of callbacks.
> +
> +Callbacks registered by application would not survive
> +``rte_cryptodev_configure`` as it reinitializes the callback list. It
> +is user responsibility to remove all installed callbacks before calling
> ``rte_cryptodev_configure`` to avoid possible memory leakage.
> +
> +So, the application is expected to add user callback after
> ``rte_cryptodev_configure``.
> +The callbacks can also be added at the runtime. These callbacks get
> +executed when
> ``rte_cryptodev_enqueue_burst``/``rte_cryptodev_dequeue_burst`` is called.
> +
> +.. code-block:: c
> +
> + struct rte_cryptodev_cb *
> + rte_cryptodev_add_enq_callback(uint8_t dev_id, uint16_t
> qp_id,
> + rte_cryptodev_callback_fn cb_fn,
> + void *cb_arg);
> +
> + struct rte_cryptodev_cb *
> + rte_cryptodev_add_deq_callback(uint8_t dev_id, uint16_t
> qp_id,
> + rte_cryptodev_callback_fn cb_fn,
> + void *cb_arg);
> +
> + uint16_t (* rte_cryptodev_callback_fn)(uint16_t dev_id, uint16_t qp_id,
> + struct rte_crypto_op **ops,
> + uint16_t nb_ops, void
> *user_param);
> +
> +The remove API removes a callback function added by
> +``rte_cryptodev_add_enq_callback``/``rte_cryptodev_add_deq_callback``.
> +
> +.. code-block:: c
> +
> + int rte_cryptodev_remove_enq_callback(uint8_t dev_id, uint16_t
> qp_id,
> + struct rte_cryptodev_cb *cb);
> +
> + int rte_cryptodev_remove_deq_callback(uint8_t dev_id, uint16_t
> qp_id,
> + struct rte_cryptodev_cb *cb);
> +
>
> Enqueue / Dequeue Burst APIs
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> diff --git a/doc/guides/rel_notes/release_21_02.rst
> b/doc/guides/rel_notes/release_21_02.rst
> index 638f98168..8c7866401 100644
> --- a/doc/guides/rel_notes/release_21_02.rst
> +++ b/doc/guides/rel_notes/release_21_02.rst
> @@ -55,6 +55,13 @@ New Features
> Also, make sure to start the actual text at the margin.
> =======================================================
>
> +* **Added enqueue & dequeue callback APIs for cryptodev library.**
> +
> + Cryptodev library is added with enqueue & dequeue callback APIs to
> + enable applications to add/remove user callbacks which gets called
> + for every enqueue/dequeue operation.
> +
> +
>
> Removed Items
> -------------
> @@ -84,6 +91,8 @@ API Changes
> Also, make sure to start the actual text at the margin.
> =======================================================
>
> +* cryptodev: The structure ``rte_cryptodev`` has been updated with
> +pointers
> + for adding enqueue and dequeue callbacks.
>
> ABI Changes
> -----------
> diff --git a/lib/librte_cryptodev/meson.build b/lib/librte_cryptodev/meson.build
> index c4c6b3b6a..8c5493f4c 100644
> --- a/lib/librte_cryptodev/meson.build
> +++ b/lib/librte_cryptodev/meson.build
> @@ -9,4 +9,4 @@ headers = files('rte_cryptodev.h',
> 'rte_crypto.h',
> 'rte_crypto_sym.h',
> 'rte_crypto_asym.h')
> -deps += ['kvargs', 'mbuf']
> +deps += ['kvargs', 'mbuf', 'rcu']
> diff --git a/lib/librte_cryptodev/rte_cryptodev.c
> b/lib/librte_cryptodev/rte_cryptodev.c
> index 3d95ac6ea..40f55a3cd 100644
> --- a/lib/librte_cryptodev/rte_cryptodev.c
> +++ b/lib/librte_cryptodev/rte_cryptodev.c
> @@ -448,6 +448,122 @@
> rte_cryptodev_asym_xform_capability_check_modlen(
> return 0;
> }
>
> +/* spinlock for crypto device enq callbacks */ static rte_spinlock_t
> +rte_cryptodev_callback_lock = RTE_SPINLOCK_INITIALIZER;
> +
> +static void
> +cryptodev_cb_cleanup(struct rte_cryptodev *dev) {
> + struct rte_cryptodev_cb_rcu *list;
> + struct rte_cryptodev_cb *cb, *next;
> + uint16_t qp_id;
> +
> + if (dev->enq_cbs == NULL && dev->deq_cbs == NULL)
> + return;
> +
> + for (qp_id = 0; qp_id < dev->data->nb_queue_pairs; qp_id++) {
> + list = &dev->enq_cbs[qp_id];
> + cb = list->next;
> + while (cb != NULL) {
> + next = cb->next;
> + rte_free(cb);
> + cb = next;
> + }
> +
> + rte_free(list->qsbr);
> + }
> +
> + for (qp_id = 0; qp_id < dev->data->nb_queue_pairs; qp_id++) {
> + list = &dev->deq_cbs[qp_id];
> + cb = list->next;
> + while (cb != NULL) {
> + next = cb->next;
> + rte_free(cb);
> + cb = next;
> + }
> +
> + rte_free(list->qsbr);
> + }
> +
> + rte_free(dev->enq_cbs);
> + dev->enq_cbs = NULL;
> + rte_free(dev->deq_cbs);
> + dev->deq_cbs = NULL;
> +}
> +
> +static int
> +cryptodev_cb_init(struct rte_cryptodev *dev) {
> + struct rte_cryptodev_cb_rcu *list;
> + struct rte_rcu_qsbr *qsbr;
> + uint16_t qp_id;
> + size_t size;
> +
> + /* Max thread set to 1, as one DP thread accessing a queue-pair */
> + const uint32_t max_threads = 1;
> +
> + dev->enq_cbs = rte_zmalloc(NULL,
> + sizeof(struct rte_cryptodev_cb_rcu) *
> + dev->data->nb_queue_pairs, 0);
> + if (dev->enq_cbs == NULL) {
> + CDEV_LOG_ERR("Failed to allocate memory for enq
> callbacks");
> + return -ENOMEM;
> + }
> +
> + dev->deq_cbs = rte_zmalloc(NULL,
> + sizeof(struct rte_cryptodev_cb_rcu) *
> + dev->data->nb_queue_pairs, 0);
> + if (dev->deq_cbs == NULL) {
> + CDEV_LOG_ERR("Failed to allocate memory for deq
> callbacks");
> + rte_free(dev->enq_cbs);
> + return -ENOMEM;
> + }
> +
> + /* Create RCU QSBR variable */
> + size = rte_rcu_qsbr_get_memsize(max_threads);
> +
> + for (qp_id = 0; qp_id < dev->data->nb_queue_pairs; qp_id++) {
> + list = &dev->enq_cbs[qp_id];
> + qsbr = rte_zmalloc(NULL, size, RTE_CACHE_LINE_SIZE);
> + if (qsbr == NULL) {
> + CDEV_LOG_ERR("Failed to allocate memory for RCU
> on "
> + "queue_pair_id=%d", qp_id);
> + goto cb_init_err;
> + }
> +
> + if (rte_rcu_qsbr_init(qsbr, max_threads)) {
> + CDEV_LOG_ERR("Failed to initialize for RCU on "
> + "queue_pair_id=%d", qp_id);
> + goto cb_init_err;
> + }
> +
> + list->qsbr = qsbr;
> + }
> +
> + for (qp_id = 0; qp_id < dev->data->nb_queue_pairs; qp_id++) {
> + list = &dev->deq_cbs[qp_id];
> + qsbr = rte_zmalloc(NULL, size, RTE_CACHE_LINE_SIZE);
> + if (qsbr == NULL) {
> + CDEV_LOG_ERR("Failed to allocate memory for RCU
> on "
> + "queue_pair_id=%d", qp_id);
> + goto cb_init_err;
> + }
> +
> + if (rte_rcu_qsbr_init(qsbr, max_threads)) {
> + CDEV_LOG_ERR("Failed to initialize for RCU on "
> + "queue_pair_id=%d", qp_id);
> + goto cb_init_err;
> + }
> +
> + list->qsbr = qsbr;
> + }
> +
> + return 0;
> +
> +cb_init_err:
> + cryptodev_cb_cleanup(dev);
> + return -ENOMEM;
> +}
>
> const char *
> rte_cryptodev_get_feature_name(uint64_t flag) @@ -927,6 +1043,10 @@
> rte_cryptodev_configure(uint8_t dev_id, struct rte_cryptodev_config *config)
>
> RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_configure, -
> ENOTSUP);
>
> + rte_spinlock_lock(&rte_cryptodev_callback_lock);
> + cryptodev_cb_cleanup(dev);
> + rte_spinlock_unlock(&rte_cryptodev_callback_lock);
> +
> /* Setup new number of queue pairs and reconfigure device. */
> diag = rte_cryptodev_queue_pairs_config(dev, config-
> >nb_queue_pairs,
> config->socket_id);
> @@ -936,11 +1056,18 @@ rte_cryptodev_configure(uint8_t dev_id, struct
> rte_cryptodev_config *config)
> return diag;
> }
>
> + rte_spinlock_lock(&rte_cryptodev_callback_lock);
> + diag = cryptodev_cb_init(dev);
> + rte_spinlock_unlock(&rte_cryptodev_callback_lock);
> + if (diag) {
> + CDEV_LOG_ERR("Callback init failed for dev_id=%d", dev_id);
> + return diag;
> + }
> +
> rte_cryptodev_trace_configure(dev_id, config);
> return (*dev->dev_ops->dev_configure)(dev, config); }
>
> -
> int
> rte_cryptodev_start(uint8_t dev_id)
> {
> @@ -1136,6 +1263,275 @@ rte_cryptodev_queue_pair_setup(uint8_t dev_id,
> uint16_t queue_pair_id,
> socket_id);
> }
>
> +struct rte_cryptodev_cb *
> +rte_cryptodev_add_enq_callback(uint8_t dev_id,
> + uint16_t qp_id,
> + rte_cryptodev_callback_fn cb_fn,
> + void *cb_arg)
> +{
> + struct rte_cryptodev *dev;
> + struct rte_cryptodev_cb_rcu *list;
> + struct rte_cryptodev_cb *cb, *tail;
> +
> + if (!cb_fn) {
> + CDEV_LOG_ERR("Callback is NULL on dev_id=%d", dev_id);
> + rte_errno = EINVAL;
> + return NULL;
> + }
> +
> + if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
> + CDEV_LOG_ERR("Invalid dev_id=%d", dev_id);
> + rte_errno = ENODEV;
> + return NULL;
> + }
> +
> + dev = &rte_crypto_devices[dev_id];
> + if (qp_id >= dev->data->nb_queue_pairs) {
> + CDEV_LOG_ERR("Invalid queue_pair_id=%d", qp_id);
> + rte_errno = ENODEV;
> + return NULL;
> + }
> +
> + cb = rte_zmalloc(NULL, sizeof(*cb), 0);
> + if (cb == NULL) {
> + CDEV_LOG_ERR("Failed to allocate memory for callback on "
> + "dev=%d, queue_pair_id=%d", dev_id, qp_id);
> + rte_errno = ENOMEM;
> + return NULL;
> + }
> +
> + rte_spinlock_lock(&rte_cryptodev_callback_lock);
> +
> + cb->fn = cb_fn;
> + cb->arg = cb_arg;
> +
> + /* Add the callbacks in fifo order. */
> + list = &dev->enq_cbs[qp_id];
> + tail = list->next;
> +
> + if (tail) {
> + while (tail->next)
> + tail = tail->next;
> + /* Stores to cb->fn and cb->param should complete before
> + * cb is visible to data plane.
> + */
> + __atomic_store_n(&tail->next, cb, __ATOMIC_RELEASE);
> + } else {
> + /* Stores to cb->fn and cb->param should complete before
> + * cb is visible to data plane.
> + */
> + __atomic_store_n(&list->next, cb, __ATOMIC_RELEASE);
> + }
> +
> + rte_spinlock_unlock(&rte_cryptodev_callback_lock);
> +
> + return cb;
> +}
> +
> +int
> +rte_cryptodev_remove_enq_callback(uint8_t dev_id,
> + uint16_t qp_id,
> + struct rte_cryptodev_cb *cb)
> +{
> + struct rte_cryptodev *dev;
> + struct rte_cryptodev_cb **prev_cb, *curr_cb;
> + struct rte_cryptodev_cb_rcu *list;
> + int ret;
> +
> + ret = -EINVAL;
> +
> + if (!cb) {
> + CDEV_LOG_ERR("Callback is NULL");
> + return -EINVAL;
> + }
> +
> + if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
> + CDEV_LOG_ERR("Invalid dev_id=%d", dev_id);
> + return -ENODEV;
> + }
> +
> + dev = &rte_crypto_devices[dev_id];
> + if (qp_id >= dev->data->nb_queue_pairs) {
> + CDEV_LOG_ERR("Invalid queue_pair_id=%d", qp_id);
> + return -ENODEV;
> + }
> +
> + rte_spinlock_lock(&rte_cryptodev_callback_lock);
> + if (dev->enq_cbs == NULL) {
> + CDEV_LOG_ERR("Callback not initialized");
> + goto cb_err;
> + }
> +
> + list = &dev->enq_cbs[qp_id];
> + if (list == NULL) {
> + CDEV_LOG_ERR("Callback list is NULL");
> + goto cb_err;
> + }
> +
> + if (list->qsbr == NULL) {
> + CDEV_LOG_ERR("Rcu qsbr is NULL");
> + goto cb_err;
> + }
> +
> + prev_cb = &list->next;
> + for (; *prev_cb != NULL; prev_cb = &curr_cb->next) {
> + curr_cb = *prev_cb;
> + if (curr_cb == cb) {
> + /* Remove the user cb from the callback list. */
> + __atomic_store_n(prev_cb, curr_cb->next,
> + __ATOMIC_RELAXED);
> + ret = 0;
> + break;
> + }
> + }
> +
> + if (!ret) {
> + /* Call sync with invalid thread id as this is part of
> + * control plane API
> + */
> + rte_rcu_qsbr_synchronize(list->qsbr,
> RTE_QSBR_THRID_INVALID);
> + rte_free(cb);
> + }
> +
> +cb_err:
> + rte_spinlock_unlock(&rte_cryptodev_callback_lock);
> + return ret;
> +}
> +
> +struct rte_cryptodev_cb *
> +rte_cryptodev_add_deq_callback(uint8_t dev_id,
> + uint16_t qp_id,
> + rte_cryptodev_callback_fn cb_fn,
> + void *cb_arg)
> +{
> + struct rte_cryptodev *dev;
> + struct rte_cryptodev_cb_rcu *list;
> + struct rte_cryptodev_cb *cb, *tail;
> +
> + if (!cb_fn) {
> + CDEV_LOG_ERR("Callback is NULL on dev_id=%d", dev_id);
> + rte_errno = EINVAL;
> + return NULL;
> + }
> +
> + if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
> + CDEV_LOG_ERR("Invalid dev_id=%d", dev_id);
> + rte_errno = ENODEV;
> + return NULL;
> + }
> +
> + dev = &rte_crypto_devices[dev_id];
> + if (qp_id >= dev->data->nb_queue_pairs) {
> + CDEV_LOG_ERR("Invalid queue_pair_id=%d", qp_id);
> + rte_errno = ENODEV;
> + return NULL;
> + }
> +
> + cb = rte_zmalloc(NULL, sizeof(*cb), 0);
> + if (cb == NULL) {
> + CDEV_LOG_ERR("Failed to allocate memory for callback on "
> + "dev=%d, queue_pair_id=%d", dev_id, qp_id);
> + rte_errno = ENOMEM;
> + return NULL;
> + }
> +
> + rte_spinlock_lock(&rte_cryptodev_callback_lock);
> +
> + cb->fn = cb_fn;
> + cb->arg = cb_arg;
> +
> + /* Add the callbacks in fifo order. */
> + list = &dev->deq_cbs[qp_id];
> + tail = list->next;
> +
> + if (tail) {
> + while (tail->next)
> + tail = tail->next;
> + /* Stores to cb->fn and cb->param should complete before
> + * cb is visible to data plane.
> + */
> + __atomic_store_n(&tail->next, cb, __ATOMIC_RELEASE);
> + } else {
> + /* Stores to cb->fn and cb->param should complete before
> + * cb is visible to data plane.
> + */
> + __atomic_store_n(&list->next, cb, __ATOMIC_RELEASE);
> + }
> +
> + rte_spinlock_unlock(&rte_cryptodev_callback_lock);
> +
> + return cb;
> +}
> +
> +int
> +rte_cryptodev_remove_deq_callback(uint8_t dev_id,
> + uint16_t qp_id,
> + struct rte_cryptodev_cb *cb)
> +{
> + struct rte_cryptodev *dev;
> + struct rte_cryptodev_cb **prev_cb, *curr_cb;
> + struct rte_cryptodev_cb_rcu *list;
> + int ret;
> +
> + ret = -EINVAL;
> +
> + if (!cb) {
> + CDEV_LOG_ERR("Callback is NULL");
> + return -EINVAL;
> + }
> +
> + if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
> + CDEV_LOG_ERR("Invalid dev_id=%d", dev_id);
> + return -ENODEV;
> + }
> +
> + dev = &rte_crypto_devices[dev_id];
> + if (qp_id >= dev->data->nb_queue_pairs) {
> + CDEV_LOG_ERR("Invalid queue_pair_id=%d", qp_id);
> + return -ENODEV;
> + }
> +
> + rte_spinlock_lock(&rte_cryptodev_callback_lock);
> + if (dev->enq_cbs == NULL) {
> + CDEV_LOG_ERR("Callback not initialized");
> + goto cb_err;
> + }
> +
> + list = &dev->deq_cbs[qp_id];
> + if (list == NULL) {
> + CDEV_LOG_ERR("Callback list is NULL");
> + goto cb_err;
> + }
> +
> + if (list->qsbr == NULL) {
> + CDEV_LOG_ERR("Rcu qsbr is NULL");
> + goto cb_err;
> + }
> +
> + prev_cb = &list->next;
> + for (; *prev_cb != NULL; prev_cb = &curr_cb->next) {
> + curr_cb = *prev_cb;
> + if (curr_cb == cb) {
> + /* Remove the user cb from the callback list. */
> + __atomic_store_n(prev_cb, curr_cb->next,
> + __ATOMIC_RELAXED);
> + ret = 0;
> + break;
> + }
> + }
> +
> + if (!ret) {
> + /* Call sync with invalid thread id as this is part of
> + * control plane API
> + */
> + rte_rcu_qsbr_synchronize(list->qsbr,
> RTE_QSBR_THRID_INVALID);
> + rte_free(cb);
> + }
> +
> +cb_err:
> + rte_spinlock_unlock(&rte_cryptodev_callback_lock);
> + return ret;
> +}
>
> int
> rte_cryptodev_stats_get(uint8_t dev_id, struct rte_cryptodev_stats *stats) diff
> --git a/lib/librte_cryptodev/rte_cryptodev.h
> b/lib/librte_cryptodev/rte_cryptodev.h
> index 0935fd587..ae34f33f6 100644
> --- a/lib/librte_cryptodev/rte_cryptodev.h
> +++ b/lib/librte_cryptodev/rte_cryptodev.h
> @@ -23,6 +23,7 @@ extern "C" {
> #include "rte_dev.h"
> #include <rte_common.h>
> #include <rte_config.h>
> +#include <rte_rcu_qsbr.h>
>
> #include "rte_cryptodev_trace_fp.h"
>
> @@ -522,6 +523,30 @@ struct rte_cryptodev_qp_conf {
> /**< The mempool for creating sess private data in sessionless mode
> */ };
>
> +/**
> + * Function type used for processing crypto ops when enqueue/dequeue
> +burst is
> + * called.
> + *
> + * The callback function is called on enqueue/dequeue burst immediately.
> + *
> + * @param dev_id The identifier of the device.
> + * @param qp_id The index of the queue pair on which ops are
> + * enqueued/dequeued. The value must be in the
> + * range [0, nb_queue_pairs - 1] previously
> + * supplied to *rte_cryptodev_configure*.
> + * @param ops The address of an array of *nb_ops* pointers
> + * to *rte_crypto_op* structures which contain
> + * the crypto operations to be processed.
> + * @param nb_ops The number of operations to process.
> + * @param user_param The arbitrary user parameter passed in by the
> + * application when the callback was originally
> + * registered.
> + * @return The number of ops to be enqueued to the
> + * crypto device.
> + */
> +typedef uint16_t (*rte_cryptodev_callback_fn)(uint16_t dev_id, uint16_t
> qp_id,
> + struct rte_crypto_op **ops, uint16_t nb_ops, void
> *user_param);
> +
> /**
> * Typedef for application callback function to be registered by application
> * software for notification of device events @@ -822,7 +847,6 @@
> rte_cryptodev_callback_unregister(uint8_t dev_id,
> enum rte_cryptodev_event_type event,
> rte_cryptodev_cb_fn cb_fn, void *cb_arg);
>
> -
> typedef uint16_t (*dequeue_pkt_burst_t)(void *qp,
> struct rte_crypto_op **ops, uint16_t nb_ops);
> /**< Dequeue processed packets from queue pair of a device. */ @@ -839,6
> +863,30 @@ struct rte_cryptodev_callback;
> /** Structure to keep track of registered callbacks */
> TAILQ_HEAD(rte_cryptodev_cb_list, rte_cryptodev_callback);
>
> +/**
> + * Structure used to hold information about the callbacks to be called
> +for a
> + * queue pair on enqueue/dequeue.
> + */
> +struct rte_cryptodev_cb {
> + struct rte_cryptodev_cb *next;
> + /**< Pointer to next callback */
> + rte_cryptodev_callback_fn fn;
> + /**< Pointer to callback function */
> + void *arg;
> + /**< Pointer to argument */
> +};
> +
> +/**
> + * @internal
> + * Structure used to hold information about the RCU for a queue pair.
> + */
> +struct rte_cryptodev_cb_rcu {
> + struct rte_cryptodev_cb *next;
> + /**< Pointer to next callback */
> + struct rte_rcu_qsbr *qsbr;
> + /**< RCU QSBR variable per queue pair */ };
> +
> /** The data structure associated with each crypto device. */ struct
> rte_cryptodev {
> dequeue_pkt_burst_t dequeue_burst;
> @@ -867,6 +915,12 @@ struct rte_cryptodev {
> __extension__
> uint8_t attached : 1;
> /**< Flag indicating the device is attached */
> +
> + struct rte_cryptodev_cb_rcu *enq_cbs;
> + /**< User application callback for pre enqueue processing */
> +
> + struct rte_cryptodev_cb_rcu *deq_cbs;
> + /**< User application callback for post dequeue processing */
> } __rte_cache_aligned;
>
> void *
> @@ -945,10 +999,33 @@ rte_cryptodev_dequeue_burst(uint8_t dev_id,
> uint16_t qp_id, {
> struct rte_cryptodev *dev = &rte_cryptodevs[dev_id];
>
> + rte_cryptodev_trace_dequeue_burst(dev_id, qp_id, (void **)ops,
> +nb_ops);
> nb_ops = (*dev->dequeue_burst)
> (dev->data->queue_pairs[qp_id], ops, nb_ops);
> -
> - rte_cryptodev_trace_dequeue_burst(dev_id, qp_id, (void **)ops,
> nb_ops);
> +#ifdef RTE_CRYPTO_CALLBACKS
> + if (unlikely(dev->deq_cbs != NULL)) {
> + struct rte_cryptodev_cb_rcu *list;
> + struct rte_cryptodev_cb *cb;
> +
> + /* __ATOMIC_RELEASE memory order was used when the
> + * call back was inserted into the list.
> + * Since there is a clear dependency between loading
> + * cb and cb->fn/cb->next, __ATOMIC_ACQUIRE memory order
> is
> + * not required.
> + */
> + list = &dev->deq_cbs[qp_id];
> + rte_rcu_qsbr_thread_online(list->qsbr, 0);
> + cb = __atomic_load_n(&list->next, __ATOMIC_RELAXED);
> +
> + while (cb != NULL) {
> + nb_ops = cb->fn(dev_id, qp_id, ops, nb_ops,
> + cb->arg);
> + cb = cb->next;
> + };
> +
> + rte_rcu_qsbr_thread_offline(list->qsbr, 0);
> + }
> +#endif
> return nb_ops;
> }
>
> @@ -989,6 +1066,31 @@ rte_cryptodev_enqueue_burst(uint8_t dev_id,
> uint16_t qp_id, {
> struct rte_cryptodev *dev = &rte_cryptodevs[dev_id];
>
> +#ifdef RTE_CRYPTO_CALLBACKS
> + if (unlikely(dev->enq_cbs != NULL)) {
> + struct rte_cryptodev_cb_rcu *list;
> + struct rte_cryptodev_cb *cb;
> +
> + /* __ATOMIC_RELEASE memory order was used when the
> + * call back was inserted into the list.
> + * Since there is a clear dependency between loading
> + * cb and cb->fn/cb->next, __ATOMIC_ACQUIRE memory order
> is
> + * not required.
> + */
> + list = &dev->enq_cbs[qp_id];
> + rte_rcu_qsbr_thread_online(list->qsbr, 0);
> + cb = __atomic_load_n(&list->next, __ATOMIC_RELAXED);
> +
> + while (cb != NULL) {
> + nb_ops = cb->fn(dev_id, qp_id, ops, nb_ops,
> + cb->arg);
> + cb = cb->next;
> + };
> +
> + rte_rcu_qsbr_thread_offline(list->qsbr, 0);
> + }
> +#endif
> +
> rte_cryptodev_trace_enqueue_burst(dev_id, qp_id, (void **)ops,
> nb_ops);
> return (*dev->enqueue_burst)(
> dev->data->queue_pairs[qp_id], ops, nb_ops); @@ -
> 1730,6 +1832,144 @@ int rte_cryptodev_raw_dequeue_done(struct
> rte_crypto_raw_dp_ctx *ctx,
> uint32_t n);
>
> +/**
> + * Add a user callback for a given crypto device and queue pair which
> +will be
> + * called on crypto ops enqueue.
> + *
> + * This API configures a function to be called for each burst of crypto
> +ops
> + * received on a given crypto device queue pair. The return value is a
> +pointer
> + * that can be used later to remove the callback using
> + * rte_cryptodev_remove_enq_callback().
> + *
> + * Callbacks registered by application would not survive
> + * rte_cryptodev_configure() as it reinitializes the callback list.
> + * It is user responsibility to remove all installed callbacks before
> + * calling rte_cryptodev_configure() to avoid possible memory leakage.
> + * Application is expected to call add API after rte_cryptodev_configure().
> + *
> + * Multiple functions can be registered per queue pair & they are
> +called
> + * in the order they were added. The API does not restrict on maximum
> +number
> + * of callbacks.
> + *
> + * @param dev_id The identifier of the device.
> + * @param qp_id The index of the queue pair on which ops are
> + * to be enqueued for processing. The value
> + * must be in the range [0, nb_queue_pairs - 1]
> + * previously supplied to
> + * *rte_cryptodev_configure*.
> + * @param cb_fn The callback function
> + * @param cb_arg A generic pointer parameter which will be
> passed
> + * to each invocation of the callback function on
> + * this crypto device and queue pair.
> + *
> + * @return
> + * - NULL on error & rte_errno will contain the error code.
> + * - On success, a pointer value which can later be used to remove the
> + * callback.
> + */
> +
> +__rte_experimental
> +struct rte_cryptodev_cb *
> +rte_cryptodev_add_enq_callback(uint8_t dev_id,
> + uint16_t qp_id,
> + rte_cryptodev_callback_fn cb_fn,
> + void *cb_arg);
> +
> +/**
> + * Remove a user callback function for given crypto device and queue pair.
> + *
> + * This function is used to remove enqueue callbacks that were added to
> +a
> + * crypto device queue pair using rte_cryptodev_add_enq_callback().
> + *
> + *
> + *
> + * @param dev_id The identifier of the device.
> + * @param qp_id The index of the queue pair on which ops are
> + * to be enqueued. The value must be in the
> + * range [0, nb_queue_pairs - 1] previously
> + * supplied to *rte_cryptodev_configure*.
> + * @param cb Pointer to user supplied callback created via
> + * rte_cryptodev_add_enq_callback().
> + *
> + * @return
> + * - 0: Success. Callback was removed.
> + * - <0: The dev_id or the qp_id is out of range, or the callback
> + * is NULL or not found for the crypto device queue pair.
> + */
> +
> +__rte_experimental
> +int rte_cryptodev_remove_enq_callback(uint8_t dev_id,
> + uint16_t qp_id,
> + struct rte_cryptodev_cb *cb);
> +
> +/**
> + * Add a user callback for a given crypto device and queue pair which
> +will be
> + * called on crypto ops dequeue.
> + *
> + * This API configures a function to be called for each burst of crypto
> +ops
> + * received on a given crypto device queue pair. The return value is a
> +pointer
> + * that can be used later to remove the callback using
> + * rte_cryptodev_remove_deq_callback().
> + *
> + * Callbacks registered by application would not survive
> + * rte_cryptodev_configure() as it reinitializes the callback list.
> + * It is user responsibility to remove all installed callbacks before
> + * calling rte_cryptodev_configure() to avoid possible memory leakage.
> + * Application is expected to call add API after rte_cryptodev_configure().
> + *
> + * Multiple functions can be registered per queue pair & they are
> +called
> + * in the order they were added. The API does not restrict on maximum
> +number
> + * of callbacks.
> + *
> + * @param dev_id The identifier of the device.
> + * @param qp_id The index of the queue pair on which ops are
> + * to be dequeued. The value must be in the
> + * range [0, nb_queue_pairs - 1] previously
> + * supplied to *rte_cryptodev_configure*.
> + * @param cb_fn The callback function
> + * @param cb_arg A generic pointer parameter which will be
> passed
> + * to each invocation of the callback function on
> + * this crypto device and queue pair.
> + *
> + * @return
> + * - NULL on error & rte_errno will contain the error code.
> + * - On success, a pointer value which can later be used to remove the
> + * callback.
> + */
> +
> +__rte_experimental
> +struct rte_cryptodev_cb *
> +rte_cryptodev_add_deq_callback(uint8_t dev_id,
> + uint16_t qp_id,
> + rte_cryptodev_callback_fn cb_fn,
> + void *cb_arg);
> +
> +/**
> + * Remove a user callback function for given crypto device and queue pair.
> + *
> + * This function is used to remove dequeue callbacks that were added to
> +a
> + * crypto device queue pair using rte_cryptodev_add_deq_callback().
> + *
> + *
> + *
> + * @param dev_id The identifier of the device.
> + * @param qp_id The index of the queue pair on which ops are
> + * to be dequeued. The value must be in the
> + * range [0, nb_queue_pairs - 1] previously
> + * supplied to *rte_cryptodev_configure*.
> + * @param cb Pointer to user supplied callback created via
> + * rte_cryptodev_add_deq_callback().
> + *
> + * @return
> + * - 0: Success. Callback was removed.
> + * - <0: The dev_id or the qp_id is out of range, or the callback
> + * is NULL or not found for the crypto device queue pair.
> + */
> +__rte_experimental
> +int rte_cryptodev_remove_deq_callback(uint8_t dev_id,
> + uint16_t qp_id,
> + struct rte_cryptodev_cb *cb);
> +
> #ifdef __cplusplus
> }
> #endif
> diff --git a/lib/librte_cryptodev/version.map b/lib/librte_cryptodev/version.map
> index 7e4360ff0..9f04737ae 100644
> --- a/lib/librte_cryptodev/version.map
> +++ b/lib/librte_cryptodev/version.map
> @@ -109,4 +109,11 @@ EXPERIMENTAL {
> rte_cryptodev_raw_enqueue;
> rte_cryptodev_raw_enqueue_burst;
> rte_cryptodev_raw_enqueue_done;
> +
> + # added in 21.02
> + rte_cryptodev_add_deq_callback;
> + rte_cryptodev_add_enq_callback;
> + rte_cryptodev_remove_deq_callback;
> + rte_cryptodev_remove_enq_callback;
> +
> };
> --
> 2.25.1
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC 3/7] devarg: change reprsentor ID to bitmap
@ 2021-01-05 6:19 3% ` Xueming(Steven) Li
0 siblings, 0 replies; 200+ results
From: Xueming(Steven) Li @ 2021-01-05 6:19 UTC (permalink / raw)
To: Andrew Rybchenko, Slava Ovsiienko, NBU-Contact-Thomas Monjalon,
Ferruh Yigit, Olivier Matz, Matan Azrad
Cc: dev, Asaf Penso
Hi Andrew,
>-----Original Message-----
>From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>Sent: Monday, December 28, 2020 9:37 PM
>To: Xueming(Steven) Li <xuemingl@nvidia.com>; Slava Ovsiienko
><viacheslavo@nvidia.com>; NBU-Contact-Thomas Monjalon
><thomas@monjalon.net>; Ferruh Yigit <ferruh.yigit@intel.com>; Olivier Matz
><olivier.matz@6wind.com>; Matan Azrad <matan@nvidia.com>
>Cc: dev@dpdk.org; Asaf Penso <asafp@nvidia.com>
>Subject: Re: [RFC 3/7] devarg: change reprsentor ID to bitmap
>
>On 12/18/20 5:55 PM, Xueming Li wrote:
>> In eth representor comparer callback, ethdev was compared with devarg.
>
>comparer -> comparator?
>
>> Since ethdev representor port didn't contain controller(host) and
>> owner port information, callback only compared representor port and
>> returned representor port on other PF port.
>>
>> This patch changes representor port to bitmap encoding, expands and
>> updates representor port ID after parsing, when device representor ID
>> uses the same bitmap encoding, the eth representor comparer callback
>> returns correct ethdev.
>>
>> Representor port ID bitmap definition:
>> Representor ID bitmap:
>> xxxx xxxx xxxx xxxx
>> |||| |LLL LLLL LLLL vf/sf id
>> |||| L 1:sf, 0:vf
>> ||LL pf id
>
>Just 2 bits for PF ID is definitely not future proof.
Yes, this is a valid concern, to keep ABI compatibility, need to wait next LTS to
change it to u32 or u64.
>
>> LL controller(host) id
>
>Same here.
>
>In general, I'm not sure that such approch with bitmap makes sense. I think
>we need a new API which returns information about available functions which
>could be represented and IDs there could be used as representor IDs.
Agree, will introduce rte_eth_representor_id_encode() and rte_eth_representor_id_parse()
in next vesion.
>
>>
>> Signed-off-by: Xueming Li <xuemingl@nvidia.com>
>> ---
>> 0000-cover-letter.patch | 44 +++++++++++++++++++++++++++
>
>I guess it should not be added to the changeset.
>
>> lib/librte_ethdev/ethdev_private.c | 42 ++++++++++++++++++++++++-
>> lib/librte_ethdev/rte_ethdev_driver.h | 22 ++++++++++++++
>> 3 files changed, 107 insertions(+), 1 deletion(-) create mode 100644
>> 0000-cover-letter.patch
>>
>> diff --git a/0000-cover-letter.patch b/0000-cover-letter.patch new
>> file mode 100644 index 0000000000..3f8ce2be72
>> --- /dev/null
>> +++ b/0000-cover-letter.patch
>> @@ -0,0 +1,44 @@
>> +From 4e1f8fc062fa6813e0b57f78ad72760601ca1d98 Mon Sep 17 00:00:00
>> +2001
>> +From: Xueming Li <xuemingl@nvidia.com>
>> +Date: Fri, 18 Dec 2020 22:31:53 +0800
>> +Subject: [RFC 0/7] *** SUBJECT HERE ***
>> +To: Viacheslav Ovsiienko <viacheslavo@nvidia.com>,
>> + Thomas Monjalon <thomas@monjalon.net>,
>> + Ferruh Yigit <ferruh.yigit@intel.com>,
>> + Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
>> + Olivier Matz <olivier.matz@6wind.com>,
>> + Matan Azrad <matan@nvidia.com>
>> +Cc: dev@dpdk.org,
>> + xuemingl@nvidia.com,
>> + Asaf Penso <asafp@nvidia.com>
>> +
>> +*** BLURB HERE ***
>> +
>> +Xueming Li (7):
>> + ethdev: support sub function representor
>> + ethdev: support multi-host representor
>> + devarg: change reprsentor ID to bitmap
>> + ethdev: capability for new representor syntax
>> + kvargs: update parser for new representor syntax
>> + common/mlx5: update representor name parsing
>> + net/mlx5: support representor of sub function
>> +
>> + config/rte_config.h | 1 +
>> + drivers/common/mlx5/linux/mlx5_common_os.c | 32 ++--
>> + drivers/common/mlx5/linux/mlx5_nl.c | 2 +
>> + drivers/common/mlx5/mlx5_common.h | 2 +
>> + drivers/net/mlx5/linux/mlx5_ethdev_os.c | 5 +
>> + drivers/net/mlx5/linux/mlx5_os.c | 69 ++++++++-
>> + drivers/net/mlx5/mlx5_ethdev.c | 2 +
>> + lib/librte_ethdev/ethdev_private.c | 163 ++++++++++++++-------
>> + lib/librte_ethdev/ethdev_private.h | 3 -
>> + lib/librte_ethdev/rte_class_eth.c | 7 +-
>> + lib/librte_ethdev/rte_ethdev.c | 5 +-
>> + lib/librte_ethdev/rte_ethdev.h | 2 +
>> + lib/librte_ethdev/rte_ethdev_driver.h | 35 +++++
>> + lib/librte_kvargs/rte_kvargs.c | 82 +++++++----
>> + 14 files changed, 306 insertions(+), 104 deletions(-)
>> +
>> +--
>> +2.25.1
>> +
>> diff --git a/lib/librte_ethdev/ethdev_private.c
>> b/lib/librte_ethdev/ethdev_private.c
>> index 3e455acea9..a0fc187378 100644
>> --- a/lib/librte_ethdev/ethdev_private.c
>> +++ b/lib/librte_ethdev/ethdev_private.c
>> @@ -93,16 +93,20 @@ rte_eth_devargs_process_list(char *str, uint16_t
>> *list, uint16_t *len_list, }
>>
>> /*
>> - * representor format:
>> + * Parse representor ports, expand and update representor port ID.
>> + * Representor format:
>> * #: range or single number of VF representor - legacy
>> * [[c#]pf#]vf#: VF port representor/s
>> * [[c#]pf#]sf#: SF port representor/s
>> + *
>> + * See RTE_ETH_REPR() for representor ID format.
>> */
>> int
>> rte_eth_devargs_parse_representor_ports(char *str, void *data) {
>> struct rte_eth_devargs *eth_da = data;
>> int ret;
>> + uint32_t c, p, f, i = 0;
>>
>> eth_da->type = RTE_ETH_REPRESENTOR_NONE;
>> if (str[0] == 'c') {
>> @@ -136,6 +140,42 @@ rte_eth_devargs_parse_representor_ports(char
>*str, void *data)
>> }
>> ret = rte_eth_devargs_process_list(str, eth_da->representor_ports,
>> ð_da->nb_representor_ports, RTE_MAX_ETHPORTS);
>> + if (ret < 0)
>> + goto err;
>> +
>> + /* Set default values, expand and update representor ID. */
>> + if (!eth_da->nb_mh_controllers) {
>
>DPDK coding style requires to compare vs 0 expliticly.
>
>> + eth_da->nb_mh_controllers = 1;
>> + eth_da->mh_controllers[0] = 0;
>> + }
>> + if (!eth_da->nb_ports) {
>
>DPDK coding style requires to compare vs 0 expliticly.
>
>> + eth_da->nb_ports = 1;
>> + eth_da->ports[0] = 0;
>> + }
>> + if (!eth_da->nb_representor_ports) {
>
>DPDK coding style requires to compare vs 0 expliticly.
>
>> + eth_da->nb_representor_ports = 1;
>> + eth_da->representor_ports[0] = 0;
>> + }
>> + for (c = 0; c < eth_da->nb_mh_controllers; ++c) {
>> + for (p = 0; p < eth_da->nb_ports; ++p) {
>> + for (f = 0; f < eth_da->nb_representor_ports; ++f) {
>> + i = c * eth_da->nb_ports *
>> + eth_da->nb_representor_ports +
>> + p * eth_da->nb_representor_ports + f;
>> + if (i >= RTE_DIM(eth_da->representor_ports))
>{
>> + RTE_LOG(ERR, EAL, "too many
>representor specified: %s",
>
>Missing \n
>
>> + str);
>> + return -EINVAL;
>> + }
>> + eth_da->representor_ports[i] =
>RTE_ETH_REPR(
>> + eth_da->mh_controllers[c],
>> + eth_da->ports[p],
>> + eth_da->type ==
>RTE_ETH_REPRESENTOR_SF,
>> + eth_da->representor_ports[f]);
>> + }
>> + }
>> + }
>> + eth_da->nb_representor_ports = i + 1;
>> err:
>> if (ret < 0)
>> RTE_LOG(ERR, EAL, "wrong representor format: %s", str); diff -
>-git
>> a/lib/librte_ethdev/rte_ethdev_driver.h
>> b/lib/librte_ethdev/rte_ethdev_driver.h
>> index a7969c9408..dbad55c704 100644
>> --- a/lib/librte_ethdev/rte_ethdev_driver.h
>> +++ b/lib/librte_ethdev/rte_ethdev_driver.h
>> @@ -1218,6 +1218,28 @@ struct rte_eth_devargs {
>> enum rte_eth_representor_type type; /* type of representor */ };
>>
>> +/**
>> + * Encoding representor port ID.
>> + *
>> + * The compact format is used for device iterator that comparing
>> + * ethdev representor ID with target devargs.
>> + *
>> + * xxxx xxxx xxxx xxxx
>> + * |||| |LLL LLLL LLLL vf/sf id
>> + * |||| L 1:sf, 0:vf
>> + * ||LL pf id
>> + * LL controller(host) id
>> + */
>> +#define RTE_ETH_REPR(c, pf, sf, port) \
>> + ((((c) & 3) << 14) | \
>> + (((pf) & 3) << 12) | \
>> + (!!(sf) << 11) | \
>> + ((port) & 0x7ff))
>> +/** Get 'pf' port id from representor ID */ #define
>> +RTE_ETH_REPR_PF(repr) (((repr) >> 12) & 3)
>> +/** Get 'vf' or 'sf' port from representor ID */ #define
>> +RTE_ETH_REPR_PORT(repr) ((repr) & 0x7ff)
>> +
>> /**
>> * PMD helper function to parse ethdev arguments
>> *
>>
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH] ci: fix default ccache in GitHub Actions
@ 2021-01-05 12:16 5% David Marchand
2021-01-05 14:09 0% ` Aaron Conole
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2021-01-05 12:16 UTC (permalink / raw)
To: dev, aconole; +Cc: Michael Santana, Thomas Monjalon
'main' might not be the default branch name.
Fixes: 87009585e293 ("ci: hook to GitHub Actions")
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
I found no other option but to call to the remote repository since github
does not seem to expose a HEAD symbolic reference.
The other alternative would be to simply rename ovsrobot/dpdk default
branch from 'master' to 'main'.
Example: https://github.com/ovsrobot/dpdk/runs/1641274373?check_suite_focus=true#step:4:4
---
.github/workflows/build.yml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
index 0b72df0ebe..751eb82c16 100644
--- a/.github/workflows/build.yml
+++ b/.github/workflows/build.yml
@@ -67,13 +67,15 @@ jobs:
echo 'libabigail-${{ matrix.config.os }}'
echo -n '::set-output name=abi::'
echo 'abi-${{ matrix.config.os }}-${{ matrix.config.compiler }}-${{ matrix.config.cross }}-${{ env.LIBABIGAIL_VERSION }}-${{ env.REF_GIT_TAG }}'
+ echo -n '::set-output name=default_branch::'
+ git ls-remote --symref origin HEAD |awk '/^ref:/ {print $2}'
- name: Retrieve ccache cache
uses: actions/cache@v2
with:
path: ~/.ccache
key: ${{ steps.get_ref_keys.outputs.ccache }}-${{ github.ref }}
restore-keys: |
- ${{ steps.get_ref_keys.outputs.ccache }}-refs/heads/main
+ ${{ steps.get_ref_keys.outputs.ccache }}-${{ steps.get_ref_keys.outputs.default_branch }}
- name: Retrieve libabigail cache
id: libabigail-cache
uses: actions/cache@v2
--
2.23.0
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH] ci: fix default ccache in GitHub Actions
2021-01-05 12:16 5% [dpdk-dev] [PATCH] ci: fix default ccache in GitHub Actions David Marchand
@ 2021-01-05 14:09 0% ` Aaron Conole
0 siblings, 0 replies; 200+ results
From: Aaron Conole @ 2021-01-05 14:09 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Michael Santana, Thomas Monjalon
David Marchand <david.marchand@redhat.com> writes:
> 'main' might not be the default branch name.
>
> Fixes: 87009585e293 ("ci: hook to GitHub Actions")
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
> I found no other option but to call to the remote repository since github
> does not seem to expose a HEAD symbolic reference.
Ugh... I thought I had set it to 'main' during DPDKs transition, but
seems I didn't (guess it was just an oversight on my part - sorry).
> The other alternative would be to simply rename ovsrobot/dpdk default
> branch from 'master' to 'main'.
I will do that rename anyway - it should be consistent.
> Example: https://github.com/ovsrobot/dpdk/runs/1641274373?check_suite_focus=true#step:4:4
>
> ---
> .github/workflows/build.yml | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
> index 0b72df0ebe..751eb82c16 100644
> --- a/.github/workflows/build.yml
> +++ b/.github/workflows/build.yml
> @@ -67,13 +67,15 @@ jobs:
> echo 'libabigail-${{ matrix.config.os }}'
> echo -n '::set-output name=abi::'
> echo 'abi-${{ matrix.config.os }}-${{ matrix.config.compiler }}-${{ matrix.config.cross }}-${{ env.LIBABIGAIL_VERSION }}-${{ env.REF_GIT_TAG }}'
> + echo -n '::set-output name=default_branch::'
> + git ls-remote --symref origin HEAD |awk '/^ref:/ {print $2}'
> - name: Retrieve ccache cache
> uses: actions/cache@v2
> with:
> path: ~/.ccache
> key: ${{ steps.get_ref_keys.outputs.ccache }}-${{ github.ref }}
> restore-keys: |
> - ${{ steps.get_ref_keys.outputs.ccache }}-refs/heads/main
> + ${{ steps.get_ref_keys.outputs.ccache }}-${{ steps.get_ref_keys.outputs.default_branch }}
> - name: Retrieve libabigail cache
> id: libabigail-cache
> uses: actions/cache@v2
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 08/40] net/virtio: force IOVA as VA mode for Virtio-user
@ 2021-01-06 9:06 4% ` David Marchand
2021-01-06 9:11 3% ` Thomas Monjalon
2021-01-06 9:14 0% ` Maxime Coquelin
0 siblings, 2 replies; 200+ results
From: David Marchand @ 2021-01-06 9:06 UTC (permalink / raw)
To: Maxime Coquelin, Ray Kinsella, Thomas Monjalon
Cc: dev, Xia, Chenbo, Olivier Matz, Adrian Moreno Zapata
On Sun, Dec 20, 2020 at 10:14 PM Maxime Coquelin
<maxime.coquelin@redhat.com> wrote:
> diff --git a/drivers/net/virtio/virtio_user_ethdev.c b/drivers/net/virtio/virtio_user_ethdev.c
> index 1f1f63a1a5..f4775ff141 100644
> --- a/drivers/net/virtio/virtio_user_ethdev.c
> +++ b/drivers/net/virtio/virtio_user_ethdev.c
> @@ -663,6 +663,17 @@ virtio_user_pmd_probe(struct rte_vdev_device *vdev)
> char *mac_addr = NULL;
> int ret = -1;
>
> + /*
> + * ToDo 1: Implement detection mechanism at vdev bus level as PCI, but
> + * it implies API breakage.
Extending rte_vdev_driver to implement this detection would be an ABI breakage.
This is a driver-only API (rte_vdev_driver is only used by the vdev
bus and drivers afaics).
Doing this is allowed as per my understanding of the ABI policy which
guarantees ABI stability for applications.
We do not guarantee this stability for OOT drivers.
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 08/40] net/virtio: force IOVA as VA mode for Virtio-user
2021-01-06 9:06 4% ` David Marchand
@ 2021-01-06 9:11 3% ` Thomas Monjalon
2021-01-06 9:22 0% ` Maxime Coquelin
2021-01-06 16:37 0% ` Kinsella, Ray
2021-01-06 9:14 0% ` Maxime Coquelin
1 sibling, 2 replies; 200+ results
From: Thomas Monjalon @ 2021-01-06 9:11 UTC (permalink / raw)
To: Maxime Coquelin, David Marchand
Cc: Ray Kinsella, dev, Xia, Chenbo, Olivier Matz, Adrian Moreno Zapata
06/01/2021 10:06, David Marchand:
> On Sun, Dec 20, 2020 at 10:14 PM Maxime Coquelin
> <maxime.coquelin@redhat.com> wrote:
> > diff --git a/drivers/net/virtio/virtio_user_ethdev.c b/drivers/net/virtio/virtio_user_ethdev.c
> > index 1f1f63a1a5..f4775ff141 100644
> > --- a/drivers/net/virtio/virtio_user_ethdev.c
> > +++ b/drivers/net/virtio/virtio_user_ethdev.c
> > @@ -663,6 +663,17 @@ virtio_user_pmd_probe(struct rte_vdev_device *vdev)
> > char *mac_addr = NULL;
> > int ret = -1;
> >
> > + /*
> > + * ToDo 1: Implement detection mechanism at vdev bus level as PCI, but
> > + * it implies API breakage.
>
> Extending rte_vdev_driver to implement this detection would be an ABI breakage.
> This is a driver-only API (rte_vdev_driver is only used by the vdev
> bus and drivers afaics).
>
> Doing this is allowed as per my understanding of the ABI policy which
> guarantees ABI stability for applications.
> We do not guarantee this stability for OOT drivers.
I agree.
As a reminder, the A in ABI stands for Application.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 08/40] net/virtio: force IOVA as VA mode for Virtio-user
2021-01-06 9:06 4% ` David Marchand
2021-01-06 9:11 3% ` Thomas Monjalon
@ 2021-01-06 9:14 0% ` Maxime Coquelin
1 sibling, 0 replies; 200+ results
From: Maxime Coquelin @ 2021-01-06 9:14 UTC (permalink / raw)
To: David Marchand, Ray Kinsella, Thomas Monjalon
Cc: dev, Xia, Chenbo, Olivier Matz, Adrian Moreno Zapata
On 1/6/21 10:06 AM, David Marchand wrote:
> On Sun, Dec 20, 2020 at 10:14 PM Maxime Coquelin
> <maxime.coquelin@redhat.com> wrote:
>> diff --git a/drivers/net/virtio/virtio_user_ethdev.c b/drivers/net/virtio/virtio_user_ethdev.c
>> index 1f1f63a1a5..f4775ff141 100644
>> --- a/drivers/net/virtio/virtio_user_ethdev.c
>> +++ b/drivers/net/virtio/virtio_user_ethdev.c
>> @@ -663,6 +663,17 @@ virtio_user_pmd_probe(struct rte_vdev_device *vdev)
>> char *mac_addr = NULL;
>> int ret = -1;
>>
>> + /*
>> + * ToDo 1: Implement detection mechanism at vdev bus level as PCI, but
>> + * it implies API breakage.
>
> Extending rte_vdev_driver to implement this detection would be an ABI breakage.
> This is a driver-only API (rte_vdev_driver is only used by the vdev
> bus and drivers afaics).
>
> Doing this is allowed as per my understanding of the ABI policy which
> guarantees ABI stability for applications.
> We do not guarantee this stability for OOT drivers.
>
That would be a good news, as it would remove impacting the user by
requiring him to manually add --iova-mode=va in the EAL parameters.
I can change this in the v2 if this is confirmed. Ray, Thomas, is that
OK for you?
Thanks,
Maxime
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 08/40] net/virtio: force IOVA as VA mode for Virtio-user
2021-01-06 9:11 3% ` Thomas Monjalon
@ 2021-01-06 9:22 0% ` Maxime Coquelin
2021-01-06 16:37 0% ` Kinsella, Ray
1 sibling, 0 replies; 200+ results
From: Maxime Coquelin @ 2021-01-06 9:22 UTC (permalink / raw)
To: Thomas Monjalon, David Marchand
Cc: Ray Kinsella, dev, Xia, Chenbo, Olivier Matz, Adrian Moreno Zapata
On 1/6/21 10:11 AM, Thomas Monjalon wrote:
> 06/01/2021 10:06, David Marchand:
>> On Sun, Dec 20, 2020 at 10:14 PM Maxime Coquelin
>> <maxime.coquelin@redhat.com> wrote:
>>> diff --git a/drivers/net/virtio/virtio_user_ethdev.c b/drivers/net/virtio/virtio_user_ethdev.c
>>> index 1f1f63a1a5..f4775ff141 100644
>>> --- a/drivers/net/virtio/virtio_user_ethdev.c
>>> +++ b/drivers/net/virtio/virtio_user_ethdev.c
>>> @@ -663,6 +663,17 @@ virtio_user_pmd_probe(struct rte_vdev_device *vdev)
>>> char *mac_addr = NULL;
>>> int ret = -1;
>>>
>>> + /*
>>> + * ToDo 1: Implement detection mechanism at vdev bus level as PCI, but
>>> + * it implies API breakage.
>>
>> Extending rte_vdev_driver to implement this detection would be an ABI breakage.
>> This is a driver-only API (rte_vdev_driver is only used by the vdev
>> bus and drivers afaics).
>>
>> Doing this is allowed as per my understanding of the ABI policy which
>> guarantees ABI stability for applications.
>> We do not guarantee this stability for OOT drivers.
>
> I agree.
> As a reminder, the A in ABI stands for Application.
Cool, so we're all good.
Thanks for the prompt reply!
Maxime
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 08/40] net/virtio: force IOVA as VA mode for Virtio-user
2021-01-06 9:11 3% ` Thomas Monjalon
2021-01-06 9:22 0% ` Maxime Coquelin
@ 2021-01-06 16:37 0% ` Kinsella, Ray
1 sibling, 0 replies; 200+ results
From: Kinsella, Ray @ 2021-01-06 16:37 UTC (permalink / raw)
To: Thomas Monjalon, Maxime Coquelin, David Marchand
Cc: dev, Xia, Chenbo, Olivier Matz, Adrian Moreno Zapata
On 06/01/2021 09:11, Thomas Monjalon wrote:
> 06/01/2021 10:06, David Marchand:
>> On Sun, Dec 20, 2020 at 10:14 PM Maxime Coquelin
>> <maxime.coquelin@redhat.com> wrote:
>>> diff --git a/drivers/net/virtio/virtio_user_ethdev.c b/drivers/net/virtio/virtio_user_ethdev.c
>>> index 1f1f63a1a5..f4775ff141 100644
>>> --- a/drivers/net/virtio/virtio_user_ethdev.c
>>> +++ b/drivers/net/virtio/virtio_user_ethdev.c
>>> @@ -663,6 +663,17 @@ virtio_user_pmd_probe(struct rte_vdev_device *vdev)
>>> char *mac_addr = NULL;
>>> int ret = -1;
>>>
>>> + /*
>>> + * ToDo 1: Implement detection mechanism at vdev bus level as PCI, but
>>> + * it implies API breakage.
>>
>> Extending rte_vdev_driver to implement this detection would be an ABI breakage.
>> This is a driver-only API (rte_vdev_driver is only used by the vdev
>> bus and drivers afaics).
>>
>> Doing this is allowed as per my understanding of the ABI policy which
>> guarantees ABI stability for applications.
>> We do not guarantee this stability for OOT drivers.
>
> I agree.
> As a reminder, the A in ABI stands for Application.
>
+1, as long as the binary interface remains the same, we are good.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
@ 2021-01-06 22:12 3% ` Thomas Monjalon
2021-01-07 9:32 3% ` Guo, Jia
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2021-01-06 22:12 UTC (permalink / raw)
To: Jeff Guo
Cc: qi.z.zhang, jingjing.wu, qiming.yang, haiyue.wang, dev,
ferruh.yigit, andrew.rybchenko
24/12/2020 07:59, Jeff Guo:
> Add type of RTE_TUNNEL_TYPE_ECPRI into the enum of ethdev tunnel type.
>
> Signed-off-by: Jeff Guo <jia.guo@intel.com>
> Reviewed-by: Qi Zhang <qi.z.zhang@intel.com>
[...]
> --- a/lib/librte_ethdev/rte_ethdev.h
> +++ b/lib/librte_ethdev/rte_ethdev.h
> @@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
> RTE_TUNNEL_TYPE_IP_IN_GRE,
> RTE_L2_TUNNEL_TYPE_E_TAG,
> RTE_TUNNEL_TYPE_VXLAN_GPE,
> + RTE_TUNNEL_TYPE_ECPRI,
> RTE_TUNNEL_TYPE_MAX,
> };
We tried to remove all these legacy API in DPDK 20.11.
Andrew decided to not remove this one because it is
not yet completely replaced by rte_flow in all drivers.
However, I am against continuing to update this API.
The opposite work should be done: migrate to rte_flow.
Sorry, it is a nack.
BTW, it is probably breaking the ABI because of RTE_TUNNEL_TYPE_MAX.
PS: please Cc ethdev maintainers for such patch, thanks.
tip: use --cc-cmd devtools/get-maintainer.sh
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
2021-01-06 22:12 3% ` Thomas Monjalon
@ 2021-01-07 9:32 3% ` Guo, Jia
2021-01-07 10:11 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Guo, Jia @ 2021-01-07 9:32 UTC (permalink / raw)
To: Thomas Monjalon
Cc: Zhang, Qi Z, Wu, Jingjing, Yang, Qiming, Wang, Haiyue, dev,
Yigit, Ferruh, andrew.rybchenko
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Thursday, January 7, 2021 6:12 AM
> To: Guo, Jia <jia.guo@intel.com>
> Cc: Zhang, Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing
> <jingjing.wu@intel.com>; Yang, Qiming <qiming.yang@intel.com>; Wang,
> Haiyue <haiyue.wang@intel.com>; dev@dpdk.org; Yigit, Ferruh
> <ferruh.yigit@intel.com>; andrew.rybchenko@oktetlabs.ru
> Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for
> ecpri
>
> 24/12/2020 07:59, Jeff Guo:
> > Add type of RTE_TUNNEL_TYPE_ECPRI into the enum of ethdev tunnel
> type.
> >
> > Signed-off-by: Jeff Guo <jia.guo@intel.com>
> > Reviewed-by: Qi Zhang <qi.z.zhang@intel.com>
> [...]
> > --- a/lib/librte_ethdev/rte_ethdev.h
> > +++ b/lib/librte_ethdev/rte_ethdev.h
> > @@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
> > RTE_TUNNEL_TYPE_IP_IN_GRE,
> > RTE_L2_TUNNEL_TYPE_E_TAG,
> > RTE_TUNNEL_TYPE_VXLAN_GPE,
> > + RTE_TUNNEL_TYPE_ECPRI,
> > RTE_TUNNEL_TYPE_MAX,
> > };
>
> We tried to remove all these legacy API in DPDK 20.11.
> Andrew decided to not remove this one because it is not yet completely
> replaced by rte_flow in all drivers.
> However, I am against continuing to update this API.
> The opposite work should be done: migrate to rte_flow.
>
Agree but seems that the legacy api and driver legacy implementation still keep in this release, and there is no a general way to replace the legacy by rte_flow right now.
> Sorry, it is a nack.
> BTW, it is probably breaking the ABI because of RTE_TUNNEL_TYPE_MAX.
>
Oh, the ABI break should be a problem.
> PS: please Cc ethdev maintainers for such patch, thanks.
> tip: use --cc-cmd devtools/get-maintainer.sh
>
Thanks for your helpful tip.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
2021-01-07 9:32 3% ` Guo, Jia
@ 2021-01-07 10:11 0% ` Thomas Monjalon
2021-01-07 12:47 4% ` Zhang, Qi Z
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2021-01-07 10:11 UTC (permalink / raw)
To: Guo, Jia
Cc: Zhang, Qi Z, Wu, Jingjing, Yang, Qiming, Wang, Haiyue, dev,
Yigit, Ferruh, andrew.rybchenko, orika, getelson
07/01/2021 10:32, Guo, Jia:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 24/12/2020 07:59, Jeff Guo:
> > > Add type of RTE_TUNNEL_TYPE_ECPRI into the enum of ethdev tunnel
> > type.
> > >
> > > Signed-off-by: Jeff Guo <jia.guo@intel.com>
> > > Reviewed-by: Qi Zhang <qi.z.zhang@intel.com>
> > [...]
> > > --- a/lib/librte_ethdev/rte_ethdev.h
> > > +++ b/lib/librte_ethdev/rte_ethdev.h
> > > @@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
> > > RTE_TUNNEL_TYPE_IP_IN_GRE,
> > > RTE_L2_TUNNEL_TYPE_E_TAG,
> > > RTE_TUNNEL_TYPE_VXLAN_GPE,
> > > + RTE_TUNNEL_TYPE_ECPRI,
> > > RTE_TUNNEL_TYPE_MAX,
> > > };
> >
> > We tried to remove all these legacy API in DPDK 20.11.
> > Andrew decided to not remove this one because it is not yet completely
> > replaced by rte_flow in all drivers.
> > However, I am against continuing to update this API.
> > The opposite work should be done: migrate to rte_flow.
>
> Agree but seems that the legacy api and driver legacy implementation
> still keep in this release, and there is no a general way to replace
> the legacy by rte_flow right now.
I think rte_flow is a complete replacement with more features.
You can match, encap, decap.
There is even a new API to get tunnel infos after decap.
What is missing?
> > Sorry, it is a nack.
> > BTW, it is probably breaking the ABI because of RTE_TUNNEL_TYPE_MAX.
>
> Oh, the ABI break should be a problem.
>
> > PS: please Cc ethdev maintainers for such patch, thanks.
> > tip: use --cc-cmd devtools/get-maintainer.sh
>
> Thanks for your helpful tip.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
2021-01-07 10:11 0% ` Thomas Monjalon
@ 2021-01-07 12:47 4% ` Zhang, Qi Z
2021-01-07 13:33 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Zhang, Qi Z @ 2021-01-07 12:47 UTC (permalink / raw)
To: Thomas Monjalon, Guo, Jia
Cc: Wu, Jingjing, Yang, Qiming, Wang, Haiyue, dev, Yigit, Ferruh,
andrew.rybchenko, orika, getelson
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Thursday, January 7, 2021 6:12 PM
> To: Guo, Jia <jia.guo@intel.com>
> Cc: Zhang, Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>;
> Yang, Qiming <qiming.yang@intel.com>; Wang, Haiyue
> <haiyue.wang@intel.com>; dev@dpdk.org; Yigit, Ferruh
> <ferruh.yigit@intel.com>; andrew.rybchenko@oktetlabs.ru; orika@nvidia.com;
> getelson@nvidia.com
> Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
>
> 07/01/2021 10:32, Guo, Jia:
> > From: Thomas Monjalon <thomas@monjalon.net>
> > > 24/12/2020 07:59, Jeff Guo:
> > > > Add type of RTE_TUNNEL_TYPE_ECPRI into the enum of ethdev tunnel
> > > type.
> > > >
> > > > Signed-off-by: Jeff Guo <jia.guo@intel.com>
> > > > Reviewed-by: Qi Zhang <qi.z.zhang@intel.com>
> > > [...]
> > > > --- a/lib/librte_ethdev/rte_ethdev.h
> > > > +++ b/lib/librte_ethdev/rte_ethdev.h
> > > > @@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
> > > > RTE_TUNNEL_TYPE_IP_IN_GRE,
> > > > RTE_L2_TUNNEL_TYPE_E_TAG,
> > > > RTE_TUNNEL_TYPE_VXLAN_GPE,
> > > > + RTE_TUNNEL_TYPE_ECPRI,
> > > > RTE_TUNNEL_TYPE_MAX,
> > > > };
> > >
> > > We tried to remove all these legacy API in DPDK 20.11.
> > > Andrew decided to not remove this one because it is not yet
> > > completely replaced by rte_flow in all drivers.
> > > However, I am against continuing to update this API.
> > > The opposite work should be done: migrate to rte_flow.
> >
> > Agree but seems that the legacy api and driver legacy implementation
> > still keep in this release, and there is no a general way to replace
> > the legacy by rte_flow right now.
>
> I think rte_flow is a complete replacement with more features.
Thomas, I may not agree with this.
Actually the "enum rte_eth_tunnel_type" is used by rte_eth_dev_udp_tunnel_port_add
A packet with specific dst udp port will be recognized as a specific tunnel packet type (e.g. vxlan, vxlan-gpe, ecpri...)
In Intel NIC, the API actually changes the configuration of the packet parser in HW but not add a filter rule and I guess all other devices may enable it in a similar way.
so naturally it should be a device (port) level configuration but not a rte_flow rule for match, encap, decap...
So I think it's not a good idea to replace the rte_eth_dev_udp_tunnel_port_add with rte_flow config
and also there is no existing rte_flow_action can cover this requirement unless we introduce some new one.
> You can match, encap, decap.
> There is even a new API to get tunnel infos after decap.
> What is missing?
>
>
> > > Sorry, it is a nack.
> > > BTW, it is probably breaking the ABI because of RTE_TUNNEL_TYPE_MAX.
Yes that may break the ABI but fortunately the checking-abi-compatibility tool shows negative :) , thanks Ferruh' s guide.
https://github.com/ferruhy/dpdk/actions/runs/468859673
Thanks
Qi
> >
> > Oh, the ABI break should be a problem.
> >
> > > PS: please Cc ethdev maintainers for such patch, thanks.
> > > tip: use --cc-cmd devtools/get-maintainer.sh
> >
> > Thanks for your helpful tip.
>
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
2021-01-07 12:47 4% ` Zhang, Qi Z
@ 2021-01-07 13:33 0% ` Thomas Monjalon
2021-01-07 13:45 0% ` David Marchand
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Thomas Monjalon @ 2021-01-07 13:33 UTC (permalink / raw)
To: Guo, Jia, Zhang, Qi Z
Cc: Wu, Jingjing, Yang, Qiming, Wang, Haiyue, dev, Yigit, Ferruh,
andrew.rybchenko, orika, getelson, Dodji Seketeli
07/01/2021 13:47, Zhang, Qi Z:
>
> > -----Original Message-----
> > From: Thomas Monjalon <thomas@monjalon.net>
> > Sent: Thursday, January 7, 2021 6:12 PM
> > To: Guo, Jia <jia.guo@intel.com>
> > Cc: Zhang, Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>;
> > Yang, Qiming <qiming.yang@intel.com>; Wang, Haiyue
> > <haiyue.wang@intel.com>; dev@dpdk.org; Yigit, Ferruh
> > <ferruh.yigit@intel.com>; andrew.rybchenko@oktetlabs.ru; orika@nvidia.com;
> > getelson@nvidia.com
> > Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
> >
> > 07/01/2021 10:32, Guo, Jia:
> > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > 24/12/2020 07:59, Jeff Guo:
> > > > > Add type of RTE_TUNNEL_TYPE_ECPRI into the enum of ethdev tunnel
> > > > type.
> > > > >
> > > > > Signed-off-by: Jeff Guo <jia.guo@intel.com>
> > > > > Reviewed-by: Qi Zhang <qi.z.zhang@intel.com>
> > > > [...]
> > > > > --- a/lib/librte_ethdev/rte_ethdev.h
> > > > > +++ b/lib/librte_ethdev/rte_ethdev.h
> > > > > @@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
> > > > > RTE_TUNNEL_TYPE_IP_IN_GRE,
> > > > > RTE_L2_TUNNEL_TYPE_E_TAG,
> > > > > RTE_TUNNEL_TYPE_VXLAN_GPE,
> > > > > + RTE_TUNNEL_TYPE_ECPRI,
> > > > > RTE_TUNNEL_TYPE_MAX,
> > > > > };
> > > >
> > > > We tried to remove all these legacy API in DPDK 20.11.
> > > > Andrew decided to not remove this one because it is not yet
> > > > completely replaced by rte_flow in all drivers.
> > > > However, I am against continuing to update this API.
> > > > The opposite work should be done: migrate to rte_flow.
> > >
> > > Agree but seems that the legacy api and driver legacy implementation
> > > still keep in this release, and there is no a general way to replace
> > > the legacy by rte_flow right now.
> >
> > I think rte_flow is a complete replacement with more features.
>
> Thomas, I may not agree with this.
>
> Actually the "enum rte_eth_tunnel_type" is used by rte_eth_dev_udp_tunnel_port_add
> A packet with specific dst udp port will be recognized as a specific tunnel packet type (e.g. vxlan, vxlan-gpe, ecpri...)
> In Intel NIC, the API actually changes the configuration of the packet parser in HW but not add a filter rule and I guess all other devices may enable it in a similar way.
> so naturally it should be a device (port) level configuration but not a rte_flow rule for match, encap, decap...
I don't understand how it helps to identify an UDP port
if there is no rule for this tunnel.
What is the usage?
> So I think it's not a good idea to replace
> the rte_eth_dev_udp_tunnel_port_add with rte_flow config
> and also there is no existing rte_flow_action
> can cover this requirement unless we introduce some new one.
>
> > You can match, encap, decap.
> > There is even a new API to get tunnel infos after decap.
> > What is missing?
I still don't see which use case is missing.
> > > > Sorry, it is a nack.
> > > > BTW, it is probably breaking the ABI because of RTE_TUNNEL_TYPE_MAX.
>
> Yes that may break the ABI but fortunately the checking-abi-compatibility tool shows negative :) , thanks Ferruh' s guide.
> https://github.com/ferruhy/dpdk/actions/runs/468859673
That's very strange. An enum value is changed.
Why it is not flagged by libabigail?
> > > Oh, the ABI break should be a problem.
> > >
> > > > PS: please Cc ethdev maintainers for such patch, thanks.
> > > > tip: use --cc-cmd devtools/get-maintainer.sh
> > >
> > > Thanks for your helpful tip.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
2021-01-07 13:33 0% ` Thomas Monjalon
@ 2021-01-07 13:45 0% ` David Marchand
2021-01-07 14:27 3% ` Dodji Seketeli
2021-01-07 15:24 0% ` Zhang, Qi Z
2021-01-08 9:22 0% ` Ferruh Yigit
2 siblings, 1 reply; 200+ results
From: David Marchand @ 2021-01-07 13:45 UTC (permalink / raw)
To: Thomas Monjalon
Cc: Guo, Jia, Zhang, Qi Z, Wu, Jingjing, Yang, Qiming, Wang, Haiyue,
dev, Yigit, Ferruh, andrew.rybchenko, orika, getelson,
Dodji Seketeli
On Thu, Jan 7, 2021 at 2:33 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> > Yes that may break the ABI but fortunately the checking-abi-compatibility tool shows negative :) , thanks Ferruh' s guide.
> > https://github.com/ferruhy/dpdk/actions/runs/468859673
>
> That's very strange. An enum value is changed.
> Why it is not flagged by libabigail?
I suspect this is because the enum is not referenced in any object...
all I see is an integer with a comment that it should be filled with
values from the enum.
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
2021-01-07 13:45 0% ` David Marchand
@ 2021-01-07 14:27 3% ` Dodji Seketeli
0 siblings, 0 replies; 200+ results
From: Dodji Seketeli @ 2021-01-07 14:27 UTC (permalink / raw)
To: David Marchand
Cc: Thomas Monjalon, Guo, Jia, Zhang, Qi Z, Wu, Jingjing, Yang,
Qiming, Wang, Haiyue, dev, Yigit, Ferruh, andrew.rybchenko,
orika, getelson
David Marchand <david.marchand@redhat.com> writes:
> On Thu, Jan 7, 2021 at 2:33 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>> > Yes that may break the ABI but fortunately the checking-abi-compatibility tool shows negative :) , thanks Ferruh' s guide.
>> > https://github.com/ferruhy/dpdk/actions/runs/468859673
>>
>> That's very strange. An enum value is changed.
>> Why it is not flagged by libabigail?
>
> I suspect this is because the enum is not referenced in any object...
> all I see is an integer with a comment that it should be filled with
> values from the enum.
I am not sure about the full context but David is right in theory.
If the enum is not reachable from a publically exported interface
(function or global variable) then it won't we considered as being part
of the ABI and changes to that enum won't be reported.
I am not sure if that is what is happening in this particular case,
though.
Cheers,
--
Dodji
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
2021-01-07 13:33 0% ` Thomas Monjalon
2021-01-07 13:45 0% ` David Marchand
@ 2021-01-07 15:24 0% ` Zhang, Qi Z
2021-01-08 9:22 0% ` Ferruh Yigit
2 siblings, 0 replies; 200+ results
From: Zhang, Qi Z @ 2021-01-07 15:24 UTC (permalink / raw)
To: Thomas Monjalon, Guo, Jia
Cc: Wu, Jingjing, Yang, Qiming, Wang, Haiyue, dev, Yigit, Ferruh,
andrew.rybchenko, orika, getelson, Dodji Seketeli
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Thursday, January 7, 2021 9:34 PM
> To: Guo, Jia <jia.guo@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>
> Cc: Wu, Jingjing <jingjing.wu@intel.com>; Yang, Qiming
> <qiming.yang@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>;
> dev@dpdk.org; Yigit, Ferruh <ferruh.yigit@intel.com>;
> andrew.rybchenko@oktetlabs.ru; orika@nvidia.com; getelson@nvidia.com;
> Dodji Seketeli <dodji@redhat.com>
> Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
>
> 07/01/2021 13:47, Zhang, Qi Z:
> >
> > > -----Original Message-----
> > > From: Thomas Monjalon <thomas@monjalon.net>
> > > Sent: Thursday, January 7, 2021 6:12 PM
> > > To: Guo, Jia <jia.guo@intel.com>
> > > Cc: Zhang, Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing
> > > <jingjing.wu@intel.com>; Yang, Qiming <qiming.yang@intel.com>; Wang,
> > > Haiyue <haiyue.wang@intel.com>; dev@dpdk.org; Yigit, Ferruh
> > > <ferruh.yigit@intel.com>; andrew.rybchenko@oktetlabs.ru;
> > > orika@nvidia.com; getelson@nvidia.com
> > > Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel
> > > type for ecpri
> > >
> > > 07/01/2021 10:32, Guo, Jia:
> > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > 24/12/2020 07:59, Jeff Guo:
> > > > > > Add type of RTE_TUNNEL_TYPE_ECPRI into the enum of ethdev
> > > > > > tunnel
> > > > > type.
> > > > > >
> > > > > > Signed-off-by: Jeff Guo <jia.guo@intel.com>
> > > > > > Reviewed-by: Qi Zhang <qi.z.zhang@intel.com>
> > > > > [...]
> > > > > > --- a/lib/librte_ethdev/rte_ethdev.h
> > > > > > +++ b/lib/librte_ethdev/rte_ethdev.h
> > > > > > @@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
> > > > > > RTE_TUNNEL_TYPE_IP_IN_GRE,
> > > > > > RTE_L2_TUNNEL_TYPE_E_TAG,
> > > > > > RTE_TUNNEL_TYPE_VXLAN_GPE,
> > > > > > + RTE_TUNNEL_TYPE_ECPRI,
> > > > > > RTE_TUNNEL_TYPE_MAX,
> > > > > > };
> > > > >
> > > > > We tried to remove all these legacy API in DPDK 20.11.
> > > > > Andrew decided to not remove this one because it is not yet
> > > > > completely replaced by rte_flow in all drivers.
> > > > > However, I am against continuing to update this API.
> > > > > The opposite work should be done: migrate to rte_flow.
> > > >
> > > > Agree but seems that the legacy api and driver legacy
> > > > implementation still keep in this release, and there is no a
> > > > general way to replace the legacy by rte_flow right now.
> > >
> > > I think rte_flow is a complete replacement with more features.
> >
> > Thomas, I may not agree with this.
> >
> > Actually the "enum rte_eth_tunnel_type" is used by
> > rte_eth_dev_udp_tunnel_port_add A packet with specific dst udp port
> > will be recognized as a specific tunnel packet type (e.g. vxlan, vxlan-gpe,
> ecpri...) In Intel NIC, the API actually changes the configuration of the packet
> parser in HW but not add a filter rule and I guess all other devices may enable it
> in a similar way.
> > so naturally it should be a device (port) level configuration but not a rte_flow
> rule for match, encap, decap...
>
> I don't understand how it helps to identify an UDP port if there is no rule for
> this tunnel.
> What is the usage?
Yes, in general It is a rule, it matches a udp packet's dst port and the action is "now the packet is identified as vxlan packet" then all other rte_flow rules that match for a vlxan as pattern will take effect. but somehow, I think they are not rules in the same domain, just like we have dedicate API for mac/vlan filter, we'd better have a dedicate API for this also. ( RFC for Vxlan explains why we need this. https://tools.ietf.org/html/rfc7348).
"Destination Port: IANA has assigned the value 4789 for the
VXLAN UDP port, and this value SHOULD be used by default as the
destination UDP port. Some early implementations of VXLAN have
used other values for the destination port. To enable
interoperability with these implementations, the destination
port SHOULD be configurable."
Thanks
Qi
>
> > So I think it's not a good idea to replace the
> > rte_eth_dev_udp_tunnel_port_add with rte_flow config and also there is
> > no existing rte_flow_action can cover this requirement unless we
> > introduce some new one.
> >
> > > You can match, encap, decap.
> > > There is even a new API to get tunnel infos after decap.
> > > What is missing?
>
> I still don't see which use case is missing.
>
>
> > > > > Sorry, it is a nack.
> > > > > BTW, it is probably breaking the ABI because of
> RTE_TUNNEL_TYPE_MAX.
> >
> > Yes that may break the ABI but fortunately the checking-abi-compatibility tool
> shows negative :) , thanks Ferruh' s guide.
> > https://github.com/ferruhy/dpdk/actions/runs/468859673
>
> That's very strange. An enum value is changed.
> Why it is not flagged by libabigail?
>
>
> > > > Oh, the ABI break should be a problem.
> > > >
> > > > > PS: please Cc ethdev maintainers for such patch, thanks.
> > > > > tip: use --cc-cmd devtools/get-maintainer.sh
> > > >
> > > > Thanks for your helpful tip.
>
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
2021-01-07 13:33 0% ` Thomas Monjalon
2021-01-07 13:45 0% ` David Marchand
2021-01-07 15:24 0% ` Zhang, Qi Z
@ 2021-01-08 9:22 0% ` Ferruh Yigit
2021-01-08 10:23 3% ` Thomas Monjalon
2 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2021-01-08 9:22 UTC (permalink / raw)
To: Thomas Monjalon, Guo, Jia, Zhang, Qi Z
Cc: Wu, Jingjing, Yang, Qiming, Wang, Haiyue, dev, andrew.rybchenko,
orika, getelson, Dodji Seketeli
On 1/7/2021 1:33 PM, Thomas Monjalon wrote:
> 07/01/2021 13:47, Zhang, Qi Z:
>>
>>> -----Original Message-----
>>> From: Thomas Monjalon <thomas@monjalon.net>
>>> Sent: Thursday, January 7, 2021 6:12 PM
>>> To: Guo, Jia <jia.guo@intel.com>
>>> Cc: Zhang, Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>;
>>> Yang, Qiming <qiming.yang@intel.com>; Wang, Haiyue
>>> <haiyue.wang@intel.com>; dev@dpdk.org; Yigit, Ferruh
>>> <ferruh.yigit@intel.com>; andrew.rybchenko@oktetlabs.ru; orika@nvidia.com;
>>> getelson@nvidia.com
>>> Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
>>>
>>> 07/01/2021 10:32, Guo, Jia:
>>>> From: Thomas Monjalon <thomas@monjalon.net>
>>>>> 24/12/2020 07:59, Jeff Guo:
>>>>>> Add type of RTE_TUNNEL_TYPE_ECPRI into the enum of ethdev tunnel
>>>>> type.
>>>>>>
>>>>>> Signed-off-by: Jeff Guo <jia.guo@intel.com>
>>>>>> Reviewed-by: Qi Zhang <qi.z.zhang@intel.com>
>>>>> [...]
>>>>>> --- a/lib/librte_ethdev/rte_ethdev.h
>>>>>> +++ b/lib/librte_ethdev/rte_ethdev.h
>>>>>> @@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
>>>>>> RTE_TUNNEL_TYPE_IP_IN_GRE,
>>>>>> RTE_L2_TUNNEL_TYPE_E_TAG,
>>>>>> RTE_TUNNEL_TYPE_VXLAN_GPE,
>>>>>> + RTE_TUNNEL_TYPE_ECPRI,
>>>>>> RTE_TUNNEL_TYPE_MAX,
>>>>>> };
>>>>>
>>>>> We tried to remove all these legacy API in DPDK 20.11.
>>>>> Andrew decided to not remove this one because it is not yet
>>>>> completely replaced by rte_flow in all drivers.
>>>>> However, I am against continuing to update this API.
>>>>> The opposite work should be done: migrate to rte_flow.
>>>>
>>>> Agree but seems that the legacy api and driver legacy implementation
>>>> still keep in this release, and there is no a general way to replace
>>>> the legacy by rte_flow right now.
>>>
>>> I think rte_flow is a complete replacement with more features.
>>
>> Thomas, I may not agree with this.
>>
>> Actually the "enum rte_eth_tunnel_type" is used by rte_eth_dev_udp_tunnel_port_add
>> A packet with specific dst udp port will be recognized as a specific tunnel packet type (e.g. vxlan, vxlan-gpe, ecpri...)
>> In Intel NIC, the API actually changes the configuration of the packet parser in HW but not add a filter rule and I guess all other devices may enable it in a similar way.
>> so naturally it should be a device (port) level configuration but not a rte_flow rule for match, encap, decap...
>
> I don't understand how it helps to identify an UDP port
> if there is no rule for this tunnel.
> What is the usage?
>
>> So I think it's not a good idea to replace
>> the rte_eth_dev_udp_tunnel_port_add with rte_flow config
>> and also there is no existing rte_flow_action
>> can cover this requirement unless we introduce some new one.
>>
>>> You can match, encap, decap.
>>> There is even a new API to get tunnel infos after decap.
>>> What is missing?
>
> I still don't see which use case is missing.
>
>
>>>>> Sorry, it is a nack.
>>>>> BTW, it is probably breaking the ABI because of RTE_TUNNEL_TYPE_MAX.
>>
>> Yes that may break the ABI but fortunately the checking-abi-compatibility tool shows negative :) , thanks Ferruh' s guide.
>> https://github.com/ferruhy/dpdk/actions/runs/468859673
>
> That's very strange. An enum value is changed.
> Why it is not flagged by libabigail?
>
As long as the enum values not sent to the application and kept within the
library, changing their values shouldn't be problem.
>
>>>> Oh, the ABI break should be a problem.
>>>>
>>>>> PS: please Cc ethdev maintainers for such patch, thanks.
>>>>> tip: use --cc-cmd devtools/get-maintainer.sh
>>>>
>>>> Thanks for your helpful tip.
>
>
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
2021-01-08 9:22 0% ` Ferruh Yigit
@ 2021-01-08 10:23 3% ` Thomas Monjalon
2021-01-08 10:43 3% ` Ferruh Yigit
2021-01-08 12:38 0% ` Kinsella, Ray
0 siblings, 2 replies; 200+ results
From: Thomas Monjalon @ 2021-01-08 10:23 UTC (permalink / raw)
To: Guo, Jia, Zhang, Qi Z, Ferruh Yigit
Cc: Wu, Jingjing, Yang, Qiming, Wang, Haiyue, dev, andrew.rybchenko,
orika, getelson, Dodji Seketeli, ray.kinsella
08/01/2021 10:22, Ferruh Yigit:
> On 1/7/2021 1:33 PM, Thomas Monjalon wrote:
> > 07/01/2021 13:47, Zhang, Qi Z:
> >> From: Thomas Monjalon <thomas@monjalon.net>
> >>> 07/01/2021 10:32, Guo, Jia:
> >>>> From: Thomas Monjalon <thomas@monjalon.net>
> >>>>> Sorry, it is a nack.
> >>>>> BTW, it is probably breaking the ABI because of RTE_TUNNEL_TYPE_MAX.
> >>
> >> Yes that may break the ABI but fortunately the checking-abi-compatibility tool shows negative :) , thanks Ferruh' s guide.
> >> https://github.com/ferruhy/dpdk/actions/runs/468859673
> >
> > That's very strange. An enum value is changed.
> > Why it is not flagged by libabigail?
>
> As long as the enum values not sent to the application and kept within the
> library, changing their values shouldn't be problem.
But RTE_TUNNEL_TYPE_MAX is part of lib/librte_ethdev/rte_ethdev.h
so it is exposed to the application.
I think it is a case of ABI breakage.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
2021-01-08 10:23 3% ` Thomas Monjalon
@ 2021-01-08 10:43 3% ` Ferruh Yigit
2021-01-08 14:06 3% ` Thomas Monjalon
2021-01-08 12:38 0% ` Kinsella, Ray
1 sibling, 1 reply; 200+ results
From: Ferruh Yigit @ 2021-01-08 10:43 UTC (permalink / raw)
To: Thomas Monjalon, Guo, Jia, Zhang, Qi Z
Cc: Wu, Jingjing, Yang, Qiming, Wang, Haiyue, dev, andrew.rybchenko,
orika, getelson, Dodji Seketeli, ray.kinsella
On 1/8/2021 10:23 AM, Thomas Monjalon wrote:
> 08/01/2021 10:22, Ferruh Yigit:
>> On 1/7/2021 1:33 PM, Thomas Monjalon wrote:
>>> 07/01/2021 13:47, Zhang, Qi Z:
>>>> From: Thomas Monjalon <thomas@monjalon.net>
>>>>> 07/01/2021 10:32, Guo, Jia:
>>>>>> From: Thomas Monjalon <thomas@monjalon.net>
>>>>>>> Sorry, it is a nack.
>>>>>>> BTW, it is probably breaking the ABI because of RTE_TUNNEL_TYPE_MAX.
>>>>
>>>> Yes that may break the ABI but fortunately the checking-abi-compatibility tool shows negative :) , thanks Ferruh' s guide.
>>>> https://github.com/ferruhy/dpdk/actions/runs/468859673
>>>
>>> That's very strange. An enum value is changed.
>>> Why it is not flagged by libabigail?
>>
>> As long as the enum values not sent to the application and kept within the
>> library, changing their values shouldn't be problem.
>
> But RTE_TUNNEL_TYPE_MAX is part of lib/librte_ethdev/rte_ethdev.h
> so it is exposed to the application.
> I think it is a case of ABI breakage.
>
Yes it is exposed to the application. But in runtime does it exchanged between
library and application is the issue I think.
For this case it seems it is not, so not an ABI break.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
2021-01-08 10:43 3% ` Ferruh Yigit
@ 2021-01-08 14:06 3% ` Thomas Monjalon
2021-01-08 14:07 0% ` Kinsella, Ray
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2021-01-08 14:06 UTC (permalink / raw)
To: Guo, Jia, Zhang, Qi Z, Ferruh Yigit
Cc: Wu, Jingjing, Yang, Qiming, Wang, Haiyue, dev, andrew.rybchenko,
orika, getelson, Dodji Seketeli, ray.kinsella
08/01/2021 11:43, Ferruh Yigit:
> On 1/8/2021 10:23 AM, Thomas Monjalon wrote:
> > 08/01/2021 10:22, Ferruh Yigit:
> >> On 1/7/2021 1:33 PM, Thomas Monjalon wrote:
> >>> 07/01/2021 13:47, Zhang, Qi Z:
> >>>> From: Thomas Monjalon <thomas@monjalon.net>
> >>>>> 07/01/2021 10:32, Guo, Jia:
> >>>>>> From: Thomas Monjalon <thomas@monjalon.net>
> >>>>>>> Sorry, it is a nack.
> >>>>>>> BTW, it is probably breaking the ABI because of RTE_TUNNEL_TYPE_MAX.
> >>>>
> >>>> Yes that may break the ABI but fortunately the checking-abi-compatibility tool shows negative :) , thanks Ferruh' s guide.
> >>>> https://github.com/ferruhy/dpdk/actions/runs/468859673
> >>>
> >>> That's very strange. An enum value is changed.
> >>> Why it is not flagged by libabigail?
> >>
> >> As long as the enum values not sent to the application and kept within the
> >> library, changing their values shouldn't be problem.
> >
> > But RTE_TUNNEL_TYPE_MAX is part of lib/librte_ethdev/rte_ethdev.h
> > so it is exposed to the application.
> > I think it is a case of ABI breakage.
>
> Yes it is exposed to the application. But in runtime does it exchanged between
> library and application is the issue I think.
> For this case it seems it is not, so not an ABI break.
If I create a table of size RTE_TUNNEL_TYPE_MAX with DPDK 20.11,
I will get an overflow when writing to the new ECPRI index.
The question is: can I receive the ECPRI value dynamically from ethdev?
If yes, it is an ABI breakage. But I cannot think of such case now.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
2021-01-08 14:07 0% ` Kinsella, Ray
@ 2021-01-08 14:10 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2021-01-08 14:10 UTC (permalink / raw)
To: Guo, Jia, Zhang, Qi Z, Yigit, Ferruh, Kinsella, Ray
Cc: Wu, Jingjing, Yang, Qiming, Wang, Haiyue, dev, andrew.rybchenko,
orika, getelson, Dodji Seketeli
08/01/2021 15:07, Kinsella, Ray:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 08/01/2021 11:43, Ferruh Yigit:
> > > On 1/8/2021 10:23 AM, Thomas Monjalon wrote:
> > > > 08/01/2021 10:22, Ferruh Yigit:
> > > >> On 1/7/2021 1:33 PM, Thomas Monjalon wrote:
> > > >>> 07/01/2021 13:47, Zhang, Qi Z:
> > > >>>> From: Thomas Monjalon <thomas@monjalon.net>
> > > >>>>> 07/01/2021 10:32, Guo, Jia:
> > > >>>>>> From: Thomas Monjalon <thomas@monjalon.net>
> > > >>>>>>> Sorry, it is a nack.
> > > >>>>>>> BTW, it is probably breaking the ABI because of
> > RTE_TUNNEL_TYPE_MAX.
> > > >>>>
> > > >>>> Yes that may break the ABI but fortunately the checking-abi-
> > compatibility tool shows negative :) , thanks Ferruh' s guide.
> > > >>>> https://github.com/ferruhy/dpdk/actions/runs/468859673
> > > >>>
> > > >>> That's very strange. An enum value is changed.
> > > >>> Why it is not flagged by libabigail?
> > > >>
> > > >> As long as the enum values not sent to the application and kept
> > > >> within the library, changing their values shouldn't be problem.
> > > >
> > > > But RTE_TUNNEL_TYPE_MAX is part of lib/librte_ethdev/rte_ethdev.h
> > so
> > > > it is exposed to the application.
> > > > I think it is a case of ABI breakage.
> > >
> > > Yes it is exposed to the application. But in runtime does it
> > exchanged
> > > between library and application is the issue I think.
> > > For this case it seems it is not, so not an ABI break.
> >
> > If I create a table of size RTE_TUNNEL_TYPE_MAX with DPDK 20.11, I will
> > get an overflow when writing to the new ECPRI index.
>
> I guess the question is - are you likely to do this?
As said below, no I cannot think about such a case myself.
> > The question is: can I receive the ECPRI value dynamically from ethdev?
> > If yes, it is an ABI breakage. But I cannot think of such case now.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
2021-01-08 12:38 0% ` Kinsella, Ray
@ 2021-01-08 14:27 0% ` Ferruh Yigit
2021-01-08 14:31 0% ` Kinsella, Ray
2021-01-08 17:34 0% ` Kinsella, Ray
0 siblings, 2 replies; 200+ results
From: Ferruh Yigit @ 2021-01-08 14:27 UTC (permalink / raw)
To: Kinsella, Ray, Thomas Monjalon, Guo, Jia, Zhang, Qi Z
Cc: Wu, Jingjing, Yang, Qiming, Wang, Haiyue, dev, andrew.rybchenko,
orika, getelson, Dodji Seketeli
On 1/8/2021 12:38 PM, Kinsella, Ray wrote:
>
>
>> -----Original Message-----
>> From: Thomas Monjalon <thomas@monjalon.net>
>> Sent: Friday 8 January 2021 10:24
>> To: Guo, Jia <jia.guo@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>;
>> Yigit, Ferruh <ferruh.yigit@intel.com>
>> Cc: Wu, Jingjing <jingjing.wu@intel.com>; Yang, Qiming
>> <qiming.yang@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>;
>> dev@dpdk.org; andrew.rybchenko@oktetlabs.ru; orika@nvidia.com;
>> getelson@nvidia.com; Dodji Seketeli <dodji@redhat.com>; Kinsella, Ray
>> <ray.kinsella@intel.com>
>> Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type
>> for ecpri
>>
>> 08/01/2021 10:22, Ferruh Yigit:
>>> On 1/7/2021 1:33 PM, Thomas Monjalon wrote:
>>>> 07/01/2021 13:47, Zhang, Qi Z:
>>>>> From: Thomas Monjalon <thomas@monjalon.net>
>>>>>> 07/01/2021 10:32, Guo, Jia:
>>>>>>> From: Thomas Monjalon <thomas@monjalon.net>
>>>>>>>> Sorry, it is a nack.
>>>>>>>> BTW, it is probably breaking the ABI because of
>> RTE_TUNNEL_TYPE_MAX.
>>>>>
>>>>> Yes that may break the ABI but fortunately the checking-abi-
>> compatibility tool shows negative :) , thanks Ferruh' s guide.
>>>>> https://github.com/ferruhy/dpdk/actions/runs/468859673
>>>>
>>>> That's very strange. An enum value is changed.
>>>> Why it is not flagged by libabigail?
>>>
>>> As long as the enum values not sent to the application and kept
>> within
>>> the library, changing their values shouldn't be problem.
>>
>> But RTE_TUNNEL_TYPE_MAX is part of lib/librte_ethdev/rte_ethdev.h so it
>> is exposed to the application.
>> I think it is a case of ABI breakage.
>>
>
> Really a lot depends on context, Thomas is right it is hard to predict how these _MAX values are used.
>
> We have seen cases in the past where _MAX enumeration values have been used to size arrays the like - I don't immediately see that issue here. My understanding is that the only consumer of this enumeration is rte_eth_dev_udp_tunnel_port_add and rte_eth_dev_udp_tunnel_port_delete, right? On face value, impact looks negligible.
>
> I will take a look at why libabigail doesn't complain.
>
Application can use the enum, including MAX as they desire, we can't really
assume anything there.
In previous case, library was providing an enum value back to application. And
the problem was application can use those values blindly and new unexpected
values may cause trouble.
For this case, even the application create a table with RTE_TUNNEL_TYPE_MAX
size, library is not sending any type of this enum to application to cause any
problem, at least abigail seems not able to finding any instance of it.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v12 00/11] Add PMD power management
@ 2021-01-08 16:42 0% ` Burakov, Anatoly
2021-01-11 8:44 0% ` David Marchand
0 siblings, 1 reply; 200+ results
From: Burakov, Anatoly @ 2021-01-08 16:42 UTC (permalink / raw)
To: David Marchand
Cc: dev, Thomas Monjalon, Ananyev, Konstantin, Gage Eads,
Timothy McDaniel, David Hunt, Bruce Richardson, chris.macnamara,
Ray Kinsella, Yigit, Ferruh
On 17-Dec-20 4:12 PM, David Marchand wrote:
> On Thu, Dec 17, 2020 at 3:06 PM Anatoly Burakov
> <anatoly.burakov@intel.com> wrote:
>>
>> This patchset proposes a simple API for Ethernet drivers to cause the
>> CPU to enter a power-optimized state while waiting for packets to
>> arrive. This is achieved through cooperation with the NIC driver that
>> will allow us to know address of wake up event, and wait for writes on
>> it.
>>
>> On IA, this is achieved through using UMONITOR/UMWAIT instructions. They
>> are used in their raw opcode form because there is no widespread
>> compiler support for them yet. Still, the API is made generic enough to
>> hopefully support other architectures, if they happen to implement
>> similar instructions.
>>
>> To achieve power savings, there is a very simple mechanism used: we're
>> counting empty polls, and if a certain threshold is reached, we get the
>> address of next RX ring descriptor from the NIC driver, arm the
>> monitoring hardware, and enter a power-optimized state. We will then
>> wake up when either a timeout happens, or a write happens (or generally
>> whenever CPU feels like waking up - this is platform-specific), and
>> proceed as normal. The empty poll counter is reset whenever we actually
>> get packets, so we only go to sleep when we know nothing is going on.
>> The mechanism is generic which can be used for any write back
>> descriptor.
>>
>> This patchset also introduces a few changes into existing power
>> management-related intrinsics, namely to provide a native way of waking
>> up a sleeping core without application being responsible for it, as well
>> as general robustness improvements. There's quite a bit of locking going
>> on, but these locks are per-thread and very little (if any) contention
>> is expected, so the performance impact shouldn't be that bad (and in any
>> case the locking happens when we're about to sleep anyway, not on a
>> hotpath).
>>
>> Why are we putting it into ethdev as opposed to leaving this up to the
>> application? Our customers specifically requested a way to do it wit
>> minimal changes to the application code. The current approach allows to
>> just flip a switch and automatically have power savings.
>>
>> - Only 1:1 core to queue mapping is supported, meaning that each lcore
>> must at most handle RX on a single queue
>> - Support 3 type policies. Monitor/Pause/Frequency Scaling
>> - Power management is enabled per-queue
>> - The API doesn't extend to other device types
>
> Fyi, ovsrobot Travis being KO, you probably missed that GHA CI caught this:
> https://github.com/ovsrobot/dpdk/runs/1571056574?check_suite_focus=true#step:13:16082
>
> We will have to put an exception on driver only ABI.
>
>
Why does aarch64 build fail there? The functions in question are in the
version map file, but the build complains that they aren't.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v13 01/11] eal: uninline power intrinsics
@ 2021-01-08 17:42 2% ` Anatoly Burakov
2021-01-12 15:54 0% ` Ananyev, Konstantin
1 sibling, 1 reply; 200+ results
From: Anatoly Burakov @ 2021-01-08 17:42 UTC (permalink / raw)
To: dev
Cc: Jan Viktorin, Ruifeng Wang, Jerin Jacob, David Christensen,
Ray Kinsella, Neil Horman, Bruce Richardson, Konstantin Ananyev,
thomas, gage.eads, timothy.mcdaniel, david.hunt, chris.macnamara
Currently, power intrinsics are inline functions. Make them part of the
ABI so that we can have various internal data associated with them
without exposing said data to the outside world.
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
---
.../arm/include/rte_power_intrinsics.h | 6 +-
.../include/generic/rte_power_intrinsics.h | 6 +-
.../ppc/include/rte_power_intrinsics.h | 6 +-
lib/librte_eal/version.map | 5 +
.../x86/include/rte_power_intrinsics.h | 115 -----------------
lib/librte_eal/x86/meson.build | 1 +
lib/librte_eal/x86/rte_power_intrinsics.c | 120 ++++++++++++++++++
7 files changed, 135 insertions(+), 124 deletions(-)
create mode 100644 lib/librte_eal/x86/rte_power_intrinsics.c
diff --git a/lib/librte_eal/arm/include/rte_power_intrinsics.h b/lib/librte_eal/arm/include/rte_power_intrinsics.h
index a4a1bc1159..5e384d380e 100644
--- a/lib/librte_eal/arm/include/rte_power_intrinsics.h
+++ b/lib/librte_eal/arm/include/rte_power_intrinsics.h
@@ -16,7 +16,7 @@ extern "C" {
/**
* This function is not supported on ARM.
*/
-static inline void
+void
rte_power_monitor(const volatile void *p, const uint64_t expected_value,
const uint64_t value_mask, const uint64_t tsc_timestamp,
const uint8_t data_sz)
@@ -31,7 +31,7 @@ rte_power_monitor(const volatile void *p, const uint64_t expected_value,
/**
* This function is not supported on ARM.
*/
-static inline void
+void
rte_power_monitor_sync(const volatile void *p, const uint64_t expected_value,
const uint64_t value_mask, const uint64_t tsc_timestamp,
const uint8_t data_sz, rte_spinlock_t *lck)
@@ -47,7 +47,7 @@ rte_power_monitor_sync(const volatile void *p, const uint64_t expected_value,
/**
* This function is not supported on ARM.
*/
-static inline void
+void
rte_power_pause(const uint64_t tsc_timestamp)
{
RTE_SET_USED(tsc_timestamp);
diff --git a/lib/librte_eal/include/generic/rte_power_intrinsics.h b/lib/librte_eal/include/generic/rte_power_intrinsics.h
index dd520d90fa..67977bd511 100644
--- a/lib/librte_eal/include/generic/rte_power_intrinsics.h
+++ b/lib/librte_eal/include/generic/rte_power_intrinsics.h
@@ -52,7 +52,7 @@
* to undefined result.
*/
__rte_experimental
-static inline void rte_power_monitor(const volatile void *p,
+void rte_power_monitor(const volatile void *p,
const uint64_t expected_value, const uint64_t value_mask,
const uint64_t tsc_timestamp, const uint8_t data_sz);
@@ -97,7 +97,7 @@ static inline void rte_power_monitor(const volatile void *p,
* wakes up.
*/
__rte_experimental
-static inline void rte_power_monitor_sync(const volatile void *p,
+void rte_power_monitor_sync(const volatile void *p,
const uint64_t expected_value, const uint64_t value_mask,
const uint64_t tsc_timestamp, const uint8_t data_sz,
rte_spinlock_t *lck);
@@ -118,6 +118,6 @@ static inline void rte_power_monitor_sync(const volatile void *p,
* architecture-dependent.
*/
__rte_experimental
-static inline void rte_power_pause(const uint64_t tsc_timestamp);
+void rte_power_pause(const uint64_t tsc_timestamp);
#endif /* _RTE_POWER_INTRINSIC_H_ */
diff --git a/lib/librte_eal/ppc/include/rte_power_intrinsics.h b/lib/librte_eal/ppc/include/rte_power_intrinsics.h
index 4ed03d521f..4cb5560c02 100644
--- a/lib/librte_eal/ppc/include/rte_power_intrinsics.h
+++ b/lib/librte_eal/ppc/include/rte_power_intrinsics.h
@@ -16,7 +16,7 @@ extern "C" {
/**
* This function is not supported on PPC64.
*/
-static inline void
+void
rte_power_monitor(const volatile void *p, const uint64_t expected_value,
const uint64_t value_mask, const uint64_t tsc_timestamp,
const uint8_t data_sz)
@@ -31,7 +31,7 @@ rte_power_monitor(const volatile void *p, const uint64_t expected_value,
/**
* This function is not supported on PPC64.
*/
-static inline void
+void
rte_power_monitor_sync(const volatile void *p, const uint64_t expected_value,
const uint64_t value_mask, const uint64_t tsc_timestamp,
const uint8_t data_sz, rte_spinlock_t *lck)
@@ -47,7 +47,7 @@ rte_power_monitor_sync(const volatile void *p, const uint64_t expected_value,
/**
* This function is not supported on PPC64.
*/
-static inline void
+void
rte_power_pause(const uint64_t tsc_timestamp)
{
RTE_SET_USED(tsc_timestamp);
diff --git a/lib/librte_eal/version.map b/lib/librte_eal/version.map
index 354c068f31..31bf76ae81 100644
--- a/lib/librte_eal/version.map
+++ b/lib/librte_eal/version.map
@@ -403,6 +403,11 @@ EXPERIMENTAL {
rte_service_lcore_may_be_active;
rte_vect_get_max_simd_bitwidth;
rte_vect_set_max_simd_bitwidth;
+
+ # added in 21.02
+ rte_power_monitor;
+ rte_power_monitor_sync;
+ rte_power_pause;
};
INTERNAL {
diff --git a/lib/librte_eal/x86/include/rte_power_intrinsics.h b/lib/librte_eal/x86/include/rte_power_intrinsics.h
index c7d790c854..e4c2b87f73 100644
--- a/lib/librte_eal/x86/include/rte_power_intrinsics.h
+++ b/lib/librte_eal/x86/include/rte_power_intrinsics.h
@@ -13,121 +13,6 @@ extern "C" {
#include "generic/rte_power_intrinsics.h"
-static inline uint64_t
-__rte_power_get_umwait_val(const volatile void *p, const uint8_t sz)
-{
- switch (sz) {
- case sizeof(uint8_t):
- return *(const volatile uint8_t *)p;
- case sizeof(uint16_t):
- return *(const volatile uint16_t *)p;
- case sizeof(uint32_t):
- return *(const volatile uint32_t *)p;
- case sizeof(uint64_t):
- return *(const volatile uint64_t *)p;
- default:
- /* this is an intrinsic, so we can't have any error handling */
- RTE_ASSERT(0);
- return 0;
- }
-}
-
-/**
- * This function uses UMONITOR/UMWAIT instructions and will enter C0.2 state.
- * For more information about usage of these instructions, please refer to
- * Intel(R) 64 and IA-32 Architectures Software Developer's Manual.
- */
-static inline void
-rte_power_monitor(const volatile void *p, const uint64_t expected_value,
- const uint64_t value_mask, const uint64_t tsc_timestamp,
- const uint8_t data_sz)
-{
- const uint32_t tsc_l = (uint32_t)tsc_timestamp;
- const uint32_t tsc_h = (uint32_t)(tsc_timestamp >> 32);
- /*
- * we're using raw byte codes for now as only the newest compiler
- * versions support this instruction natively.
- */
-
- /* set address for UMONITOR */
- asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
- :
- : "D"(p));
-
- if (value_mask) {
- const uint64_t cur_value = __rte_power_get_umwait_val(p, data_sz);
- const uint64_t masked = cur_value & value_mask;
-
- /* if the masked value is already matching, abort */
- if (masked == expected_value)
- return;
- }
- /* execute UMWAIT */
- asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
- : /* ignore rflags */
- : "D"(0), /* enter C0.2 */
- "a"(tsc_l), "d"(tsc_h));
-}
-
-/**
- * This function uses UMONITOR/UMWAIT instructions and will enter C0.2 state.
- * For more information about usage of these instructions, please refer to
- * Intel(R) 64 and IA-32 Architectures Software Developer's Manual.
- */
-static inline void
-rte_power_monitor_sync(const volatile void *p, const uint64_t expected_value,
- const uint64_t value_mask, const uint64_t tsc_timestamp,
- const uint8_t data_sz, rte_spinlock_t *lck)
-{
- const uint32_t tsc_l = (uint32_t)tsc_timestamp;
- const uint32_t tsc_h = (uint32_t)(tsc_timestamp >> 32);
- /*
- * we're using raw byte codes for now as only the newest compiler
- * versions support this instruction natively.
- */
-
- /* set address for UMONITOR */
- asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
- :
- : "D"(p));
-
- if (value_mask) {
- const uint64_t cur_value = __rte_power_get_umwait_val(p, data_sz);
- const uint64_t masked = cur_value & value_mask;
-
- /* if the masked value is already matching, abort */
- if (masked == expected_value)
- return;
- }
- rte_spinlock_unlock(lck);
-
- /* execute UMWAIT */
- asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
- : /* ignore rflags */
- : "D"(0), /* enter C0.2 */
- "a"(tsc_l), "d"(tsc_h));
-
- rte_spinlock_lock(lck);
-}
-
-/**
- * This function uses TPAUSE instruction and will enter C0.2 state. For more
- * information about usage of this instruction, please refer to Intel(R) 64 and
- * IA-32 Architectures Software Developer's Manual.
- */
-static inline void
-rte_power_pause(const uint64_t tsc_timestamp)
-{
- const uint32_t tsc_l = (uint32_t)tsc_timestamp;
- const uint32_t tsc_h = (uint32_t)(tsc_timestamp >> 32);
-
- /* execute TPAUSE */
- asm volatile(".byte 0x66, 0x0f, 0xae, 0xf7;"
- : /* ignore rflags */
- : "D"(0), /* enter C0.2 */
- "a"(tsc_l), "d"(tsc_h));
-}
-
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_eal/x86/meson.build b/lib/librte_eal/x86/meson.build
index e78f29002e..dfd42dee0c 100644
--- a/lib/librte_eal/x86/meson.build
+++ b/lib/librte_eal/x86/meson.build
@@ -8,4 +8,5 @@ sources += files(
'rte_cycles.c',
'rte_hypervisor.c',
'rte_spinlock.c',
+ 'rte_power_intrinsics.c',
)
diff --git a/lib/librte_eal/x86/rte_power_intrinsics.c b/lib/librte_eal/x86/rte_power_intrinsics.c
new file mode 100644
index 0000000000..34c5fd9c3e
--- /dev/null
+++ b/lib/librte_eal/x86/rte_power_intrinsics.c
@@ -0,0 +1,120 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2020 Intel Corporation
+ */
+
+#include "rte_power_intrinsics.h"
+
+static inline uint64_t
+__get_umwait_val(const volatile void *p, const uint8_t sz)
+{
+ switch (sz) {
+ case sizeof(uint8_t):
+ return *(const volatile uint8_t *)p;
+ case sizeof(uint16_t):
+ return *(const volatile uint16_t *)p;
+ case sizeof(uint32_t):
+ return *(const volatile uint32_t *)p;
+ case sizeof(uint64_t):
+ return *(const volatile uint64_t *)p;
+ default:
+ /* this is an intrinsic, so we can't have any error handling */
+ RTE_ASSERT(0);
+ return 0;
+ }
+}
+
+/**
+ * This function uses UMONITOR/UMWAIT instructions and will enter C0.2 state.
+ * For more information about usage of these instructions, please refer to
+ * Intel(R) 64 and IA-32 Architectures Software Developer's Manual.
+ */
+void
+rte_power_monitor(const volatile void *p, const uint64_t expected_value,
+ const uint64_t value_mask, const uint64_t tsc_timestamp,
+ const uint8_t data_sz)
+{
+ const uint32_t tsc_l = (uint32_t)tsc_timestamp;
+ const uint32_t tsc_h = (uint32_t)(tsc_timestamp >> 32);
+ /*
+ * we're using raw byte codes for now as only the newest compiler
+ * versions support this instruction natively.
+ */
+
+ /* set address for UMONITOR */
+ asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
+ :
+ : "D"(p));
+
+ if (value_mask) {
+ const uint64_t cur_value = __get_umwait_val(p, data_sz);
+ const uint64_t masked = cur_value & value_mask;
+
+ /* if the masked value is already matching, abort */
+ if (masked == expected_value)
+ return;
+ }
+ /* execute UMWAIT */
+ asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
+ : /* ignore rflags */
+ : "D"(0), /* enter C0.2 */
+ "a"(tsc_l), "d"(tsc_h));
+}
+
+/**
+ * This function uses UMONITOR/UMWAIT instructions and will enter C0.2 state.
+ * For more information about usage of these instructions, please refer to
+ * Intel(R) 64 and IA-32 Architectures Software Developer's Manual.
+ */
+void
+rte_power_monitor_sync(const volatile void *p, const uint64_t expected_value,
+ const uint64_t value_mask, const uint64_t tsc_timestamp,
+ const uint8_t data_sz, rte_spinlock_t *lck)
+{
+ const uint32_t tsc_l = (uint32_t)tsc_timestamp;
+ const uint32_t tsc_h = (uint32_t)(tsc_timestamp >> 32);
+ /*
+ * we're using raw byte codes for now as only the newest compiler
+ * versions support this instruction natively.
+ */
+
+ /* set address for UMONITOR */
+ asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
+ :
+ : "D"(p));
+
+ if (value_mask) {
+ const uint64_t cur_value = __get_umwait_val(p, data_sz);
+ const uint64_t masked = cur_value & value_mask;
+
+ /* if the masked value is already matching, abort */
+ if (masked == expected_value)
+ return;
+ }
+ rte_spinlock_unlock(lck);
+
+ /* execute UMWAIT */
+ asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
+ : /* ignore rflags */
+ : "D"(0), /* enter C0.2 */
+ "a"(tsc_l), "d"(tsc_h));
+
+ rte_spinlock_lock(lck);
+}
+
+/**
+ * This function uses TPAUSE instruction and will enter C0.2 state. For more
+ * information about usage of this instruction, please refer to Intel(R) 64 and
+ * IA-32 Architectures Software Developer's Manual.
+ */
+void
+rte_power_pause(const uint64_t tsc_timestamp)
+{
+ const uint32_t tsc_l = (uint32_t)tsc_timestamp;
+ const uint32_t tsc_h = (uint32_t)(tsc_timestamp >> 32);
+
+ /* execute TPAUSE */
+ asm volatile(".byte 0x66, 0x0f, 0xae, 0xf7;"
+ : /* ignore rflags */
+ : "D"(0), /* enter C0.2 */
+ "a"(tsc_l), "d"(tsc_h));
+}
--
2.25.1
^ permalink raw reply [relevance 2%]
* [dpdk-dev] Reader-Writer lock starvation issues
@ 2021-01-08 19:13 4% Stephen Hemminger
2021-01-08 21:27 0% ` Honnappa Nagarahalli
2021-01-12 1:04 3% ` [dpdk-dev] [PATCH] eal/rwlock: add note about writer starvation Stephen Hemminger
0 siblings, 2 replies; 200+ results
From: Stephen Hemminger @ 2021-01-08 19:13 UTC (permalink / raw)
To: dev
The current version of rte_rwlock doesn't do what it says in the documentation.
" The lock is used to protect data that allows multiple readers in parallel,
but only one writer. All readers are blocked until the writer is finished
writing."
The problem is that the current implementation does not stop a a new reader
from acquiring the lock while a writer is waiting.
Writer:
repeat until x = __atomic_load(&counter) == 0;
__atomic_compare_exchange(&counter, &x, -1);
Reader:
x = __atomic_load(&counter);
__atomic_compare_exchange(&counter, &x, x + 1);
Fixing it likely would require an ABI change to add additional state.
For more background on reader-writer locks see:
https://www.cs.rochester.edu/research/synchronization/pseudocode/rw.html
The code in DPDK is actually effectively the same as the first example
"Simple, non-scalable reader-preference lock"
It looks like doing the right thing will require increasing the size of
the rte_rwlock structure and cause an ABI breakage.
I am running with an alternative which uses ticket locks to do:
"Simple, non-scalable writer-preference lock"
My recommendation would be:
1. Fix documentation in rte_rwlock.h (and add release note) and put this in 20.02 and LTS.
2. Add new rte_ticket_rwlock.h which provides the correct semantics.
Comments?
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] Reader-Writer lock starvation issues
2021-01-08 19:13 4% [dpdk-dev] Reader-Writer lock starvation issues Stephen Hemminger
@ 2021-01-08 21:27 0% ` Honnappa Nagarahalli
2021-01-11 11:52 0% ` Ferruh Yigit
2021-01-12 1:04 3% ` [dpdk-dev] [PATCH] eal/rwlock: add note about writer starvation Stephen Hemminger
1 sibling, 1 reply; 200+ results
From: Honnappa Nagarahalli @ 2021-01-08 21:27 UTC (permalink / raw)
To: Stephen Hemminger, dev; +Cc: Honnappa Nagarahalli, nd, nd
<snip>
>
> The current version of rte_rwlock doesn't do what it says in the
> documentation.
> " The lock is used to protect data that allows multiple readers in parallel, but
> only one writer. All readers are blocked until the writer is finished writing."
>
> The problem is that the current implementation does not stop a a new reader
> from acquiring the lock while a writer is waiting.
Agree, essentially the arbitration is left to the hardware.
>
> Writer:
> repeat until x = __atomic_load(&counter) == 0;
> __atomic_compare_exchange(&counter, &x, -1);
>
> Reader:
> x = __atomic_load(&counter);
> __atomic_compare_exchange(&counter, &x, x + 1);
>
>
> Fixing it likely would require an ABI change to add additional state.
>
> For more background on reader-writer locks see:
>
> https://www.cs.rochester.edu/research/synchronization/pseudocode/rw.htm
> l
>
> The code in DPDK is actually effectively the same as the first example
> "Simple, non-scalable reader-preference lock"
I do not think the DPDK implementation has reader-preference. There is no code to control the arbitration between writers and readers. It is possible that if there are multiple writers the readers might be starved depending on how the hardware does the arbitration.
>
> It looks like doing the right thing will require increasing the size of the
> rte_rwlock structure and cause an ABI breakage.
>
> I am running with an alternative which uses ticket locks to do:
> "Simple, non-scalable writer-preference lock"
Does it provide good scalability?
>
> My recommendation would be:
>
> 1. Fix documentation in rte_rwlock.h (and add release note) and put this in
> 20.02 and LTS.
Agree, the document is not clear on the arbitration.
> 2. Add new rte_ticket_rwlock.h which provides the correct semantics.
Agree.
>
> Comments?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v12 00/11] Add PMD power management
2021-01-08 16:42 0% ` Burakov, Anatoly
@ 2021-01-11 8:44 0% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2021-01-11 8:44 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: dev, Thomas Monjalon, Ananyev, Konstantin, Gage Eads,
Timothy McDaniel, David Hunt, Bruce Richardson, chris.macnamara,
Ray Kinsella, Yigit, Ferruh
On Fri, Jan 8, 2021 at 5:42 PM Burakov, Anatoly
<anatoly.burakov@intel.com> wrote:
>
> On 17-Dec-20 4:12 PM, David Marchand wrote:
> > On Thu, Dec 17, 2020 at 3:06 PM Anatoly Burakov
> > <anatoly.burakov@intel.com> wrote:
> >>
> >> This patchset proposes a simple API for Ethernet drivers to cause the
> >> CPU to enter a power-optimized state while waiting for packets to
> >> arrive. This is achieved through cooperation with the NIC driver that
> >> will allow us to know address of wake up event, and wait for writes on
> >> it.
> >>
> >> On IA, this is achieved through using UMONITOR/UMWAIT instructions. They
> >> are used in their raw opcode form because there is no widespread
> >> compiler support for them yet. Still, the API is made generic enough to
> >> hopefully support other architectures, if they happen to implement
> >> similar instructions.
> >>
> >> To achieve power savings, there is a very simple mechanism used: we're
> >> counting empty polls, and if a certain threshold is reached, we get the
> >> address of next RX ring descriptor from the NIC driver, arm the
> >> monitoring hardware, and enter a power-optimized state. We will then
> >> wake up when either a timeout happens, or a write happens (or generally
> >> whenever CPU feels like waking up - this is platform-specific), and
> >> proceed as normal. The empty poll counter is reset whenever we actually
> >> get packets, so we only go to sleep when we know nothing is going on.
> >> The mechanism is generic which can be used for any write back
> >> descriptor.
> >>
> >> This patchset also introduces a few changes into existing power
> >> management-related intrinsics, namely to provide a native way of waking
> >> up a sleeping core without application being responsible for it, as well
> >> as general robustness improvements. There's quite a bit of locking going
> >> on, but these locks are per-thread and very little (if any) contention
> >> is expected, so the performance impact shouldn't be that bad (and in any
> >> case the locking happens when we're about to sleep anyway, not on a
> >> hotpath).
> >>
> >> Why are we putting it into ethdev as opposed to leaving this up to the
> >> application? Our customers specifically requested a way to do it wit
> >> minimal changes to the application code. The current approach allows to
> >> just flip a switch and automatically have power savings.
> >>
> >> - Only 1:1 core to queue mapping is supported, meaning that each lcore
> >> must at most handle RX on a single queue
> >> - Support 3 type policies. Monitor/Pause/Frequency Scaling
> >> - Power management is enabled per-queue
> >> - The API doesn't extend to other device types
> >
> > Fyi, ovsrobot Travis being KO, you probably missed that GHA CI caught this:
> > https://github.com/ovsrobot/dpdk/runs/1571056574?check_suite_focus=true#step:13:16082
> >
> > We will have to put an exception on driver only ABI.
> >
> >
>
> Why does aarch64 build fail there? The functions in question are in the
> version map file, but the build complains that they aren't.
From what I can see, this series puts rte_power_* symbols in a .h.
So it will be seen as symbols exported by any library including such a header.
The check then complains about this as it sees exported symbols
unknown of the library version.map.
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] Reader-Writer lock starvation issues
2021-01-08 21:27 0% ` Honnappa Nagarahalli
@ 2021-01-11 11:52 0% ` Ferruh Yigit
2021-01-11 13:05 0% ` Honnappa Nagarahalli
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2021-01-11 11:52 UTC (permalink / raw)
To: Honnappa Nagarahalli, Stephen Hemminger, dev; +Cc: nd
On 1/8/2021 9:27 PM, Honnappa Nagarahalli wrote:
> <snip>
>
>>
>> The current version of rte_rwlock doesn't do what it says in the
>> documentation.
>> " The lock is used to protect data that allows multiple readers in parallel, but
>> only one writer. All readers are blocked until the writer is finished writing."
>>
>> The problem is that the current implementation does not stop a a new reader
>> from acquiring the lock while a writer is waiting.
> Agree, essentially the arbitration is left to the hardware.
>
>>
>> Writer:
>> repeat until x = __atomic_load(&counter) == 0;
>> __atomic_compare_exchange(&counter, &x, -1);
>>
>> Reader:
>> x = __atomic_load(&counter);
>> __atomic_compare_exchange(&counter, &x, x + 1);
>>
>>
>> Fixing it likely would require an ABI change to add additional state.
>>
>> For more background on reader-writer locks see:
>>
>> https://www.cs.rochester.edu/research/synchronization/pseudocode/rw.htm
>> l
>>
>> The code in DPDK is actually effectively the same as the first example
>> "Simple, non-scalable reader-preference lock"
> I do not think the DPDK implementation has reader-preference. There is no code to control the arbitration between writers and readers. It is possible that if there are multiple writers the readers might be starved depending on how the hardware does the arbitration.
>
As far as I can see, in current implementation:
When writer has the lock, both writers and readers needs to wait, and when
writer releases reader or writer has chance to acquire the lock.
When reader has the lock, other readers can acquire the lock and writers has to
wait, and if readers keep coming it can cause writer starvation. Overall this
doesn't look fair reader-writer lock ...
>>
>> It looks like doing the right thing will require increasing the size of the
>> rte_rwlock structure and cause an ABI breakage.
>>
>> I am running with an alternative which uses ticket locks to do:
>> "Simple, non-scalable writer-preference lock"
> Does it provide good scalability?
>
>>
>> My recommendation would be:
>>
>> 1. Fix documentation in rte_rwlock.h (and add release note) and put this in
>> 20.02 and LTS.
> Agree, the document is not clear on the arbitration.
>
>> 2. Add new rte_ticket_rwlock.h which provides the correct semantics.
> Agree.
>
>>
>> Comments?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
2021-01-08 10:23 3% ` Thomas Monjalon
2021-01-08 10:43 3% ` Ferruh Yigit
@ 2021-01-08 12:38 0% ` Kinsella, Ray
2021-01-08 14:27 0% ` Ferruh Yigit
1 sibling, 1 reply; 200+ results
From: Kinsella, Ray @ 2021-01-08 12:38 UTC (permalink / raw)
To: Thomas Monjalon, Guo, Jia, Zhang, Qi Z, Yigit, Ferruh
Cc: Wu, Jingjing, Yang, Qiming, Wang, Haiyue, dev, andrew.rybchenko,
orika, getelson, Dodji Seketeli
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Friday 8 January 2021 10:24
> To: Guo, Jia <jia.guo@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>;
> Yigit, Ferruh <ferruh.yigit@intel.com>
> Cc: Wu, Jingjing <jingjing.wu@intel.com>; Yang, Qiming
> <qiming.yang@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>;
> dev@dpdk.org; andrew.rybchenko@oktetlabs.ru; orika@nvidia.com;
> getelson@nvidia.com; Dodji Seketeli <dodji@redhat.com>; Kinsella, Ray
> <ray.kinsella@intel.com>
> Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type
> for ecpri
>
> 08/01/2021 10:22, Ferruh Yigit:
> > On 1/7/2021 1:33 PM, Thomas Monjalon wrote:
> > > 07/01/2021 13:47, Zhang, Qi Z:
> > >> From: Thomas Monjalon <thomas@monjalon.net>
> > >>> 07/01/2021 10:32, Guo, Jia:
> > >>>> From: Thomas Monjalon <thomas@monjalon.net>
> > >>>>> Sorry, it is a nack.
> > >>>>> BTW, it is probably breaking the ABI because of
> RTE_TUNNEL_TYPE_MAX.
> > >>
> > >> Yes that may break the ABI but fortunately the checking-abi-
> compatibility tool shows negative :) , thanks Ferruh' s guide.
> > >> https://github.com/ferruhy/dpdk/actions/runs/468859673
> > >
> > > That's very strange. An enum value is changed.
> > > Why it is not flagged by libabigail?
> >
> > As long as the enum values not sent to the application and kept
> within
> > the library, changing their values shouldn't be problem.
>
> But RTE_TUNNEL_TYPE_MAX is part of lib/librte_ethdev/rte_ethdev.h so it
> is exposed to the application.
> I think it is a case of ABI breakage.
>
Really a lot depends on context, Thomas is right it is hard to predict how these _MAX values are used.
We have seen cases in the past where _MAX enumeration values have been used to size arrays the like - I don't immediately see that issue here. My understanding is that the only consumer of this enumeration is rte_eth_dev_udp_tunnel_port_add and rte_eth_dev_udp_tunnel_port_delete, right? On face value, impact looks negligible.
I will take a look at why libabigail doesn't complain.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
2021-01-08 14:06 3% ` Thomas Monjalon
@ 2021-01-08 14:07 0% ` Kinsella, Ray
2021-01-08 14:10 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Kinsella, Ray @ 2021-01-08 14:07 UTC (permalink / raw)
To: Thomas Monjalon, Guo, Jia, Zhang, Qi Z, Yigit, Ferruh
Cc: Wu, Jingjing, Yang, Qiming, Wang, Haiyue, dev, andrew.rybchenko,
orika, getelson, Dodji Seketeli
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Friday 8 January 2021 14:06
> To: Guo, Jia <jia.guo@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>;
> Yigit, Ferruh <ferruh.yigit@intel.com>
> Cc: Wu, Jingjing <jingjing.wu@intel.com>; Yang, Qiming
> <qiming.yang@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>;
> dev@dpdk.org; andrew.rybchenko@oktetlabs.ru; orika@nvidia.com;
> getelson@nvidia.com; Dodji Seketeli <dodji@redhat.com>; Kinsella, Ray
> <ray.kinsella@intel.com>
> Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type
> for ecpri
>
> 08/01/2021 11:43, Ferruh Yigit:
> > On 1/8/2021 10:23 AM, Thomas Monjalon wrote:
> > > 08/01/2021 10:22, Ferruh Yigit:
> > >> On 1/7/2021 1:33 PM, Thomas Monjalon wrote:
> > >>> 07/01/2021 13:47, Zhang, Qi Z:
> > >>>> From: Thomas Monjalon <thomas@monjalon.net>
> > >>>>> 07/01/2021 10:32, Guo, Jia:
> > >>>>>> From: Thomas Monjalon <thomas@monjalon.net>
> > >>>>>>> Sorry, it is a nack.
> > >>>>>>> BTW, it is probably breaking the ABI because of
> RTE_TUNNEL_TYPE_MAX.
> > >>>>
> > >>>> Yes that may break the ABI but fortunately the checking-abi-
> compatibility tool shows negative :) , thanks Ferruh' s guide.
> > >>>> https://github.com/ferruhy/dpdk/actions/runs/468859673
> > >>>
> > >>> That's very strange. An enum value is changed.
> > >>> Why it is not flagged by libabigail?
> > >>
> > >> As long as the enum values not sent to the application and kept
> > >> within the library, changing their values shouldn't be problem.
> > >
> > > But RTE_TUNNEL_TYPE_MAX is part of lib/librte_ethdev/rte_ethdev.h
> so
> > > it is exposed to the application.
> > > I think it is a case of ABI breakage.
> >
> > Yes it is exposed to the application. But in runtime does it
> exchanged
> > between library and application is the issue I think.
> > For this case it seems it is not, so not an ABI break.
>
> If I create a table of size RTE_TUNNEL_TYPE_MAX with DPDK 20.11, I will
> get an overflow when writing to the new ECPRI index.
I guess the question is - are you likely to do this?
> The question is: can I receive the ECPRI value dynamically from ethdev?
> If yes, it is an ABI breakage. But I cannot think of such case now.
Ray K
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
2021-01-08 14:27 0% ` Ferruh Yigit
@ 2021-01-08 14:31 0% ` Kinsella, Ray
2021-01-08 17:34 0% ` Kinsella, Ray
1 sibling, 0 replies; 200+ results
From: Kinsella, Ray @ 2021-01-08 14:31 UTC (permalink / raw)
To: Yigit, Ferruh, Thomas Monjalon, Guo, Jia, Zhang, Qi Z
Cc: Wu, Jingjing, Yang, Qiming, Wang, Haiyue, dev, andrew.rybchenko,
orika, getelson, Dodji Seketeli
> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> Sent: Friday 8 January 2021 14:27
> To: Kinsella, Ray <ray.kinsella@intel.com>; Thomas Monjalon
> <thomas@monjalon.net>; Guo, Jia <jia.guo@intel.com>; Zhang, Qi Z
> <qi.z.zhang@intel.com>
> Cc: Wu, Jingjing <jingjing.wu@intel.com>; Yang, Qiming
> <qiming.yang@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>;
> dev@dpdk.org; andrew.rybchenko@oktetlabs.ru; orika@nvidia.com;
> getelson@nvidia.com; Dodji Seketeli <dodji@redhat.com>
> Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type
> for ecpri
>
> On 1/8/2021 12:38 PM, Kinsella, Ray wrote:
> >
> >
> >> -----Original Message-----
> >> From: Thomas Monjalon <thomas@monjalon.net>
> >> Sent: Friday 8 January 2021 10:24
> >> To: Guo, Jia <jia.guo@intel.com>; Zhang, Qi Z
> <qi.z.zhang@intel.com>;
> >> Yigit, Ferruh <ferruh.yigit@intel.com>
> >> Cc: Wu, Jingjing <jingjing.wu@intel.com>; Yang, Qiming
> >> <qiming.yang@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>;
> >> dev@dpdk.org; andrew.rybchenko@oktetlabs.ru; orika@nvidia.com;
> >> getelson@nvidia.com; Dodji Seketeli <dodji@redhat.com>; Kinsella,
> Ray
> >> <ray.kinsella@intel.com>
> >> Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel
> type
> >> for ecpri
> >>
> >> 08/01/2021 10:22, Ferruh Yigit:
> >>> On 1/7/2021 1:33 PM, Thomas Monjalon wrote:
> >>>> 07/01/2021 13:47, Zhang, Qi Z:
> >>>>> From: Thomas Monjalon <thomas@monjalon.net>
> >>>>>> 07/01/2021 10:32, Guo, Jia:
> >>>>>>> From: Thomas Monjalon <thomas@monjalon.net>
> >>>>>>>> Sorry, it is a nack.
> >>>>>>>> BTW, it is probably breaking the ABI because of
> >> RTE_TUNNEL_TYPE_MAX.
> >>>>>
> >>>>> Yes that may break the ABI but fortunately the checking-abi-
> >> compatibility tool shows negative :) , thanks Ferruh' s guide.
> >>>>> https://github.com/ferruhy/dpdk/actions/runs/468859673
> >>>>
> >>>> That's very strange. An enum value is changed.
> >>>> Why it is not flagged by libabigail?
> >>>
> >>> As long as the enum values not sent to the application and kept
> >> within
> >>> the library, changing their values shouldn't be problem.
> >>
> >> But RTE_TUNNEL_TYPE_MAX is part of lib/librte_ethdev/rte_ethdev.h so
> >> it is exposed to the application.
> >> I think it is a case of ABI breakage.
> >>
> >
> > Really a lot depends on context, Thomas is right it is hard to
> predict how these _MAX values are used.
> >
> > We have seen cases in the past where _MAX enumeration values have
> been used to size arrays the like - I don't immediately see that issue
> here. My understanding is that the only consumer of this enumeration is
> rte_eth_dev_udp_tunnel_port_add and rte_eth_dev_udp_tunnel_port_delete,
> right? On face value, impact looks negligible.
> >
> > I will take a look at why libabigail doesn't complain.
> >
>
> Application can use the enum, including MAX as they desire, we can't
> really assume anything there.
>
> In previous case, library was providing an enum value back to
> application. And the problem was application can use those values
> blindly and new unexpected values may cause trouble.
>
> For this case, even the application create a table with
> RTE_TUNNEL_TYPE_MAX size, library is not sending any type of this enum
> to application to cause any problem, at least abigail seems not able to
> finding any instance of it.
Yes - it makes any problem associated with unlikely then.
Ray K
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri
2021-01-08 14:27 0% ` Ferruh Yigit
2021-01-08 14:31 0% ` Kinsella, Ray
@ 2021-01-08 17:34 0% ` Kinsella, Ray
1 sibling, 0 replies; 200+ results
From: Kinsella, Ray @ 2021-01-08 17:34 UTC (permalink / raw)
To: Yigit, Ferruh, Thomas Monjalon, Guo, Jia, Zhang, Qi Z
Cc: Wu, Jingjing, Yang, Qiming, Wang, Haiyue, dev, andrew.rybchenko,
orika, getelson, Dodji Seketeli
> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> Sent: Friday 8 January 2021 14:27
> To: Kinsella, Ray <ray.kinsella@intel.com>; Thomas Monjalon
> <thomas@monjalon.net>; Guo, Jia <jia.guo@intel.com>; Zhang, Qi Z
> <qi.z.zhang@intel.com>
> Cc: Wu, Jingjing <jingjing.wu@intel.com>; Yang, Qiming
> <qiming.yang@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>;
> dev@dpdk.org; andrew.rybchenko@oktetlabs.ru; orika@nvidia.com;
> getelson@nvidia.com; Dodji Seketeli <dodji@redhat.com>
> Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type
> for ecpri
>
> On 1/8/2021 12:38 PM, Kinsella, Ray wrote:
> >
> >
> >> -----Original Message-----
> >> From: Thomas Monjalon <thomas@monjalon.net>
> >> Sent: Friday 8 January 2021 10:24
> >> To: Guo, Jia <jia.guo@intel.com>; Zhang, Qi Z
> <qi.z.zhang@intel.com>;
> >> Yigit, Ferruh <ferruh.yigit@intel.com>
> >> Cc: Wu, Jingjing <jingjing.wu@intel.com>; Yang, Qiming
> >> <qiming.yang@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>;
> >> dev@dpdk.org; andrew.rybchenko@oktetlabs.ru; orika@nvidia.com;
> >> getelson@nvidia.com; Dodji Seketeli <dodji@redhat.com>; Kinsella,
> Ray
> >> <ray.kinsella@intel.com>
> >> Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel
> type
> >> for ecpri
> >>
> >> 08/01/2021 10:22, Ferruh Yigit:
> >>> On 1/7/2021 1:33 PM, Thomas Monjalon wrote:
> >>>> 07/01/2021 13:47, Zhang, Qi Z:
> >>>>> From: Thomas Monjalon <thomas@monjalon.net>
> >>>>>> 07/01/2021 10:32, Guo, Jia:
> >>>>>>> From: Thomas Monjalon <thomas@monjalon.net>
> >>>>>>>> Sorry, it is a nack.
> >>>>>>>> BTW, it is probably breaking the ABI because of
> >> RTE_TUNNEL_TYPE_MAX.
> >>>>>
> >>>>> Yes that may break the ABI but fortunately the checking-abi-
> >> compatibility tool shows negative :) , thanks Ferruh' s guide.
> >>>>> https://github.com/ferruhy/dpdk/actions/runs/468859673
> >>>>
> >>>> That's very strange. An enum value is changed.
> >>>> Why it is not flagged by libabigail?
> >>>
> >>> As long as the enum values not sent to the application and kept
> >> within
> >>> the library, changing their values shouldn't be problem.
> >>
> >> But RTE_TUNNEL_TYPE_MAX is part of lib/librte_ethdev/rte_ethdev.h so
> >> it is exposed to the application.
> >> I think it is a case of ABI breakage.
> >>
> >
> > Really a lot depends on context, Thomas is right it is hard to
> predict how these _MAX values are used.
> >
> > We have seen cases in the past where _MAX enumeration values have
> been used to size arrays the like - I don't immediately see that issue
> here. My understanding is that the only consumer of this enumeration is
> rte_eth_dev_udp_tunnel_port_add and rte_eth_dev_udp_tunnel_port_delete,
> right? On face value, impact looks negligible.
> >
> > I will take a look at why libabigail doesn't complain.
So I spent some time looking a bit closer at why libabigail didn't complain,
I am summarizing it is because there is no symbol that obviously uses enum rte_eth_tunnel_type.
The prot_type field in rte_eth_udp_tunnel is declared as a uint8_t, not as enum rte_eth_tunnel_type.
Is there a particular reason an enumerated field would be declared as unsigned int instead?
/**
* UDP tunneling configuration.
* Used to config the UDP port for a type of tunnel.
* NICs need the UDP port to identify the tunnel type.
* Normally a type of tunnel has a default UDP port, this structure can be used
* in case if the users want to change or support more UDP port.
*/
struct rte_eth_udp_tunnel {
uint16_t udp_port; /**< UDP port used for the tunnel. */
uint8_t prot_type; /**< Tunnel type. Defined in rte_eth_tunnel_type. */
};
>
> Application can use the enum, including MAX as they desire, we can't
> really assume anything there.
>
> In previous case, library was providing an enum value back to
> application. And the problem was application can use those values
> blindly and new unexpected values may cause trouble.
>
> For this case, even the application create a table with
> RTE_TUNNEL_TYPE_MAX size, library is not sending any type of this enum
> to application to cause any problem, at least abigail seems not able to
> finding any instance of it.
I agree - I think this has marginal risk.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] Reader-Writer lock starvation issues
2021-01-11 11:52 0% ` Ferruh Yigit
@ 2021-01-11 13:05 0% ` Honnappa Nagarahalli
0 siblings, 0 replies; 200+ results
From: Honnappa Nagarahalli @ 2021-01-11 13:05 UTC (permalink / raw)
To: Ferruh Yigit, Stephen Hemminger, dev; +Cc: nd, Honnappa Nagarahalli, nd
<snip>
> >
> >>
> >> The current version of rte_rwlock doesn't do what it says in the
> >> documentation.
> >> " The lock is used to protect data that allows multiple readers in
> >> parallel, but only one writer. All readers are blocked until the writer is
> finished writing."
> >>
> >> The problem is that the current implementation does not stop a a new
> >> reader from acquiring the lock while a writer is waiting.
> > Agree, essentially the arbitration is left to the hardware.
> >
> >>
> >> Writer:
> >> repeat until x = __atomic_load(&counter) == 0;
> >> __atomic_compare_exchange(&counter, &x, -1);
> >>
> >> Reader:
> >> x = __atomic_load(&counter);
> >> __atomic_compare_exchange(&counter, &x, x + 1);
> >>
> >>
> >> Fixing it likely would require an ABI change to add additional state.
> >>
> >> For more background on reader-writer locks see:
> >>
> >> https://www.cs.rochester.edu/research/synchronization/pseudocode/rw.h
> >> tm
> >> l
> >>
> >> The code in DPDK is actually effectively the same as the first
> >> example "Simple, non-scalable reader-preference lock"
> > I do not think the DPDK implementation has reader-preference. There is no
> code to control the arbitration between writers and readers. It is possible that if
> there are multiple writers the readers might be starved depending on how the
> hardware does the arbitration.
> >
>
> As far as I can see, in current implementation:
>
> When writer has the lock, both writers and readers needs to wait, and when
> writer releases reader or writer has chance to acquire the lock.
Yes, since reader or writer can acquire the lock (when writer releases), I do not think we can call the current implementation as 'reader-preference'.
>
> When reader has the lock, other readers can acquire the lock and writers has to
> wait, and if readers keep coming it can cause writer starvation. Overall this
> doesn't look fair reader-writer lock ...
Agree
>
> >>
> >> It looks like doing the right thing will require increasing the size
> >> of the rte_rwlock structure and cause an ABI breakage.
> >>
> >> I am running with an alternative which uses ticket locks to do:
> >> "Simple, non-scalable writer-preference lock"
> > Does it provide good scalability?
> >
> >>
> >> My recommendation would be:
> >>
> >> 1. Fix documentation in rte_rwlock.h (and add release note) and put
> >> this in
> >> 20.02 and LTS.
> > Agree, the document is not clear on the arbitration.
> >
> >> 2. Add new rte_ticket_rwlock.h which provides the correct semantics.
> > Agree.
> >
> >>
> >> Comments?
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v14 01/11] eal: uninline power intrinsics
@ 2021-01-11 14:35 2% ` Anatoly Burakov
1 sibling, 0 replies; 200+ results
From: Anatoly Burakov @ 2021-01-11 14:35 UTC (permalink / raw)
To: dev
Cc: Jerin Jacob, Ruifeng Wang, Jan Viktorin, David Christensen,
Ray Kinsella, Neil Horman, Bruce Richardson, Konstantin Ananyev,
thomas, timothy.mcdaniel, david.hunt, chris.macnamara
Currently, power intrinsics are inline functions. Make them part of the
ABI so that we can have various internal data associated with them
without exposing said data to the outside world.
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
---
Notes:
v14:
- Fix compile issues on ARM and PPC64 by moving implementations to .c files
.../arm/include/rte_power_intrinsics.h | 40 ------
lib/librte_eal/arm/meson.build | 1 +
lib/librte_eal/arm/rte_power_intrinsics.c | 42 ++++++
.../include/generic/rte_power_intrinsics.h | 6 +-
.../ppc/include/rte_power_intrinsics.h | 40 ------
lib/librte_eal/ppc/meson.build | 1 +
lib/librte_eal/ppc/rte_power_intrinsics.c | 42 ++++++
lib/librte_eal/version.map | 5 +
.../x86/include/rte_power_intrinsics.h | 115 -----------------
lib/librte_eal/x86/meson.build | 1 +
lib/librte_eal/x86/rte_power_intrinsics.c | 120 ++++++++++++++++++
11 files changed, 215 insertions(+), 198 deletions(-)
create mode 100644 lib/librte_eal/arm/rte_power_intrinsics.c
create mode 100644 lib/librte_eal/ppc/rte_power_intrinsics.c
create mode 100644 lib/librte_eal/x86/rte_power_intrinsics.c
diff --git a/lib/librte_eal/arm/include/rte_power_intrinsics.h b/lib/librte_eal/arm/include/rte_power_intrinsics.h
index a4a1bc1159..9e498e9ebf 100644
--- a/lib/librte_eal/arm/include/rte_power_intrinsics.h
+++ b/lib/librte_eal/arm/include/rte_power_intrinsics.h
@@ -13,46 +13,6 @@ extern "C" {
#include "generic/rte_power_intrinsics.h"
-/**
- * This function is not supported on ARM.
- */
-static inline void
-rte_power_monitor(const volatile void *p, const uint64_t expected_value,
- const uint64_t value_mask, const uint64_t tsc_timestamp,
- const uint8_t data_sz)
-{
- RTE_SET_USED(p);
- RTE_SET_USED(expected_value);
- RTE_SET_USED(value_mask);
- RTE_SET_USED(tsc_timestamp);
- RTE_SET_USED(data_sz);
-}
-
-/**
- * This function is not supported on ARM.
- */
-static inline void
-rte_power_monitor_sync(const volatile void *p, const uint64_t expected_value,
- const uint64_t value_mask, const uint64_t tsc_timestamp,
- const uint8_t data_sz, rte_spinlock_t *lck)
-{
- RTE_SET_USED(p);
- RTE_SET_USED(expected_value);
- RTE_SET_USED(value_mask);
- RTE_SET_USED(tsc_timestamp);
- RTE_SET_USED(lck);
- RTE_SET_USED(data_sz);
-}
-
-/**
- * This function is not supported on ARM.
- */
-static inline void
-rte_power_pause(const uint64_t tsc_timestamp)
-{
- RTE_SET_USED(tsc_timestamp);
-}
-
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_eal/arm/meson.build b/lib/librte_eal/arm/meson.build
index d62875ebae..6ec53ea03a 100644
--- a/lib/librte_eal/arm/meson.build
+++ b/lib/librte_eal/arm/meson.build
@@ -7,4 +7,5 @@ sources += files(
'rte_cpuflags.c',
'rte_cycles.c',
'rte_hypervisor.c',
+ 'rte_power_intrinsics.c',
)
diff --git a/lib/librte_eal/arm/rte_power_intrinsics.c b/lib/librte_eal/arm/rte_power_intrinsics.c
new file mode 100644
index 0000000000..e5a49facb4
--- /dev/null
+++ b/lib/librte_eal/arm/rte_power_intrinsics.c
@@ -0,0 +1,42 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2021 Intel Corporation
+ */
+
+#include "rte_power_intrinsics.h"
+
+/**
+ * This function is not supported on ARM.
+ */
+void rte_power_monitor(const volatile void *p, const uint64_t expected_value,
+ const uint64_t value_mask, const uint64_t tsc_timestamp,
+ const uint8_t data_sz)
+{
+ RTE_SET_USED(p);
+ RTE_SET_USED(expected_value);
+ RTE_SET_USED(value_mask);
+ RTE_SET_USED(tsc_timestamp);
+ RTE_SET_USED(data_sz);
+}
+
+/**
+ * This function is not supported on ARM.
+ */
+void rte_power_monitor_sync(const volatile void *p, const uint64_t expected_value,
+ const uint64_t value_mask, const uint64_t tsc_timestamp,
+ const uint8_t data_sz, rte_spinlock_t *lck)
+{
+ RTE_SET_USED(p);
+ RTE_SET_USED(expected_value);
+ RTE_SET_USED(value_mask);
+ RTE_SET_USED(tsc_timestamp);
+ RTE_SET_USED(lck);
+ RTE_SET_USED(data_sz);
+}
+
+/**
+ * This function is not supported on ARM.
+ */
+void rte_power_pause(const uint64_t tsc_timestamp)
+{
+ RTE_SET_USED(tsc_timestamp);
+}
diff --git a/lib/librte_eal/include/generic/rte_power_intrinsics.h b/lib/librte_eal/include/generic/rte_power_intrinsics.h
index dd520d90fa..67977bd511 100644
--- a/lib/librte_eal/include/generic/rte_power_intrinsics.h
+++ b/lib/librte_eal/include/generic/rte_power_intrinsics.h
@@ -52,7 +52,7 @@
* to undefined result.
*/
__rte_experimental
-static inline void rte_power_monitor(const volatile void *p,
+void rte_power_monitor(const volatile void *p,
const uint64_t expected_value, const uint64_t value_mask,
const uint64_t tsc_timestamp, const uint8_t data_sz);
@@ -97,7 +97,7 @@ static inline void rte_power_monitor(const volatile void *p,
* wakes up.
*/
__rte_experimental
-static inline void rte_power_monitor_sync(const volatile void *p,
+void rte_power_monitor_sync(const volatile void *p,
const uint64_t expected_value, const uint64_t value_mask,
const uint64_t tsc_timestamp, const uint8_t data_sz,
rte_spinlock_t *lck);
@@ -118,6 +118,6 @@ static inline void rte_power_monitor_sync(const volatile void *p,
* architecture-dependent.
*/
__rte_experimental
-static inline void rte_power_pause(const uint64_t tsc_timestamp);
+void rte_power_pause(const uint64_t tsc_timestamp);
#endif /* _RTE_POWER_INTRINSIC_H_ */
diff --git a/lib/librte_eal/ppc/include/rte_power_intrinsics.h b/lib/librte_eal/ppc/include/rte_power_intrinsics.h
index 4ed03d521f..c0e9ac279f 100644
--- a/lib/librte_eal/ppc/include/rte_power_intrinsics.h
+++ b/lib/librte_eal/ppc/include/rte_power_intrinsics.h
@@ -13,46 +13,6 @@ extern "C" {
#include "generic/rte_power_intrinsics.h"
-/**
- * This function is not supported on PPC64.
- */
-static inline void
-rte_power_monitor(const volatile void *p, const uint64_t expected_value,
- const uint64_t value_mask, const uint64_t tsc_timestamp,
- const uint8_t data_sz)
-{
- RTE_SET_USED(p);
- RTE_SET_USED(expected_value);
- RTE_SET_USED(value_mask);
- RTE_SET_USED(tsc_timestamp);
- RTE_SET_USED(data_sz);
-}
-
-/**
- * This function is not supported on PPC64.
- */
-static inline void
-rte_power_monitor_sync(const volatile void *p, const uint64_t expected_value,
- const uint64_t value_mask, const uint64_t tsc_timestamp,
- const uint8_t data_sz, rte_spinlock_t *lck)
-{
- RTE_SET_USED(p);
- RTE_SET_USED(expected_value);
- RTE_SET_USED(value_mask);
- RTE_SET_USED(tsc_timestamp);
- RTE_SET_USED(lck);
- RTE_SET_USED(data_sz);
-}
-
-/**
- * This function is not supported on PPC64.
- */
-static inline void
-rte_power_pause(const uint64_t tsc_timestamp)
-{
- RTE_SET_USED(tsc_timestamp);
-}
-
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_eal/ppc/meson.build b/lib/librte_eal/ppc/meson.build
index f4b6d95c42..43c46542fb 100644
--- a/lib/librte_eal/ppc/meson.build
+++ b/lib/librte_eal/ppc/meson.build
@@ -7,4 +7,5 @@ sources += files(
'rte_cpuflags.c',
'rte_cycles.c',
'rte_hypervisor.c',
+ 'rte_power_intrinsics.c',
)
diff --git a/lib/librte_eal/ppc/rte_power_intrinsics.c b/lib/librte_eal/ppc/rte_power_intrinsics.c
new file mode 100644
index 0000000000..785effabe6
--- /dev/null
+++ b/lib/librte_eal/ppc/rte_power_intrinsics.c
@@ -0,0 +1,42 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2021 Intel Corporation
+ */
+
+#include "rte_power_intrinsics.h"
+
+/**
+ * This function is not supported on PPC64.
+ */
+void rte_power_monitor(const volatile void *p, const uint64_t expected_value,
+ const uint64_t value_mask, const uint64_t tsc_timestamp,
+ const uint8_t data_sz)
+{
+ RTE_SET_USED(p);
+ RTE_SET_USED(expected_value);
+ RTE_SET_USED(value_mask);
+ RTE_SET_USED(tsc_timestamp);
+ RTE_SET_USED(data_sz);
+}
+
+/**
+ * This function is not supported on PPC64.
+ */
+void rte_power_monitor_sync(const volatile void *p, const uint64_t expected_value,
+ const uint64_t value_mask, const uint64_t tsc_timestamp,
+ const uint8_t data_sz, rte_spinlock_t *lck)
+{
+ RTE_SET_USED(p);
+ RTE_SET_USED(expected_value);
+ RTE_SET_USED(value_mask);
+ RTE_SET_USED(tsc_timestamp);
+ RTE_SET_USED(lck);
+ RTE_SET_USED(data_sz);
+}
+
+/**
+ * This function is not supported on PPC64.
+ */
+void rte_power_pause(const uint64_t tsc_timestamp)
+{
+ RTE_SET_USED(tsc_timestamp);
+}
diff --git a/lib/librte_eal/version.map b/lib/librte_eal/version.map
index 354c068f31..31bf76ae81 100644
--- a/lib/librte_eal/version.map
+++ b/lib/librte_eal/version.map
@@ -403,6 +403,11 @@ EXPERIMENTAL {
rte_service_lcore_may_be_active;
rte_vect_get_max_simd_bitwidth;
rte_vect_set_max_simd_bitwidth;
+
+ # added in 21.02
+ rte_power_monitor;
+ rte_power_monitor_sync;
+ rte_power_pause;
};
INTERNAL {
diff --git a/lib/librte_eal/x86/include/rte_power_intrinsics.h b/lib/librte_eal/x86/include/rte_power_intrinsics.h
index c7d790c854..e4c2b87f73 100644
--- a/lib/librte_eal/x86/include/rte_power_intrinsics.h
+++ b/lib/librte_eal/x86/include/rte_power_intrinsics.h
@@ -13,121 +13,6 @@ extern "C" {
#include "generic/rte_power_intrinsics.h"
-static inline uint64_t
-__rte_power_get_umwait_val(const volatile void *p, const uint8_t sz)
-{
- switch (sz) {
- case sizeof(uint8_t):
- return *(const volatile uint8_t *)p;
- case sizeof(uint16_t):
- return *(const volatile uint16_t *)p;
- case sizeof(uint32_t):
- return *(const volatile uint32_t *)p;
- case sizeof(uint64_t):
- return *(const volatile uint64_t *)p;
- default:
- /* this is an intrinsic, so we can't have any error handling */
- RTE_ASSERT(0);
- return 0;
- }
-}
-
-/**
- * This function uses UMONITOR/UMWAIT instructions and will enter C0.2 state.
- * For more information about usage of these instructions, please refer to
- * Intel(R) 64 and IA-32 Architectures Software Developer's Manual.
- */
-static inline void
-rte_power_monitor(const volatile void *p, const uint64_t expected_value,
- const uint64_t value_mask, const uint64_t tsc_timestamp,
- const uint8_t data_sz)
-{
- const uint32_t tsc_l = (uint32_t)tsc_timestamp;
- const uint32_t tsc_h = (uint32_t)(tsc_timestamp >> 32);
- /*
- * we're using raw byte codes for now as only the newest compiler
- * versions support this instruction natively.
- */
-
- /* set address for UMONITOR */
- asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
- :
- : "D"(p));
-
- if (value_mask) {
- const uint64_t cur_value = __rte_power_get_umwait_val(p, data_sz);
- const uint64_t masked = cur_value & value_mask;
-
- /* if the masked value is already matching, abort */
- if (masked == expected_value)
- return;
- }
- /* execute UMWAIT */
- asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
- : /* ignore rflags */
- : "D"(0), /* enter C0.2 */
- "a"(tsc_l), "d"(tsc_h));
-}
-
-/**
- * This function uses UMONITOR/UMWAIT instructions and will enter C0.2 state.
- * For more information about usage of these instructions, please refer to
- * Intel(R) 64 and IA-32 Architectures Software Developer's Manual.
- */
-static inline void
-rte_power_monitor_sync(const volatile void *p, const uint64_t expected_value,
- const uint64_t value_mask, const uint64_t tsc_timestamp,
- const uint8_t data_sz, rte_spinlock_t *lck)
-{
- const uint32_t tsc_l = (uint32_t)tsc_timestamp;
- const uint32_t tsc_h = (uint32_t)(tsc_timestamp >> 32);
- /*
- * we're using raw byte codes for now as only the newest compiler
- * versions support this instruction natively.
- */
-
- /* set address for UMONITOR */
- asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
- :
- : "D"(p));
-
- if (value_mask) {
- const uint64_t cur_value = __rte_power_get_umwait_val(p, data_sz);
- const uint64_t masked = cur_value & value_mask;
-
- /* if the masked value is already matching, abort */
- if (masked == expected_value)
- return;
- }
- rte_spinlock_unlock(lck);
-
- /* execute UMWAIT */
- asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
- : /* ignore rflags */
- : "D"(0), /* enter C0.2 */
- "a"(tsc_l), "d"(tsc_h));
-
- rte_spinlock_lock(lck);
-}
-
-/**
- * This function uses TPAUSE instruction and will enter C0.2 state. For more
- * information about usage of this instruction, please refer to Intel(R) 64 and
- * IA-32 Architectures Software Developer's Manual.
- */
-static inline void
-rte_power_pause(const uint64_t tsc_timestamp)
-{
- const uint32_t tsc_l = (uint32_t)tsc_timestamp;
- const uint32_t tsc_h = (uint32_t)(tsc_timestamp >> 32);
-
- /* execute TPAUSE */
- asm volatile(".byte 0x66, 0x0f, 0xae, 0xf7;"
- : /* ignore rflags */
- : "D"(0), /* enter C0.2 */
- "a"(tsc_l), "d"(tsc_h));
-}
-
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_eal/x86/meson.build b/lib/librte_eal/x86/meson.build
index e78f29002e..dfd42dee0c 100644
--- a/lib/librte_eal/x86/meson.build
+++ b/lib/librte_eal/x86/meson.build
@@ -8,4 +8,5 @@ sources += files(
'rte_cycles.c',
'rte_hypervisor.c',
'rte_spinlock.c',
+ 'rte_power_intrinsics.c',
)
diff --git a/lib/librte_eal/x86/rte_power_intrinsics.c b/lib/librte_eal/x86/rte_power_intrinsics.c
new file mode 100644
index 0000000000..34c5fd9c3e
--- /dev/null
+++ b/lib/librte_eal/x86/rte_power_intrinsics.c
@@ -0,0 +1,120 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2020 Intel Corporation
+ */
+
+#include "rte_power_intrinsics.h"
+
+static inline uint64_t
+__get_umwait_val(const volatile void *p, const uint8_t sz)
+{
+ switch (sz) {
+ case sizeof(uint8_t):
+ return *(const volatile uint8_t *)p;
+ case sizeof(uint16_t):
+ return *(const volatile uint16_t *)p;
+ case sizeof(uint32_t):
+ return *(const volatile uint32_t *)p;
+ case sizeof(uint64_t):
+ return *(const volatile uint64_t *)p;
+ default:
+ /* this is an intrinsic, so we can't have any error handling */
+ RTE_ASSERT(0);
+ return 0;
+ }
+}
+
+/**
+ * This function uses UMONITOR/UMWAIT instructions and will enter C0.2 state.
+ * For more information about usage of these instructions, please refer to
+ * Intel(R) 64 and IA-32 Architectures Software Developer's Manual.
+ */
+void
+rte_power_monitor(const volatile void *p, const uint64_t expected_value,
+ const uint64_t value_mask, const uint64_t tsc_timestamp,
+ const uint8_t data_sz)
+{
+ const uint32_t tsc_l = (uint32_t)tsc_timestamp;
+ const uint32_t tsc_h = (uint32_t)(tsc_timestamp >> 32);
+ /*
+ * we're using raw byte codes for now as only the newest compiler
+ * versions support this instruction natively.
+ */
+
+ /* set address for UMONITOR */
+ asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
+ :
+ : "D"(p));
+
+ if (value_mask) {
+ const uint64_t cur_value = __get_umwait_val(p, data_sz);
+ const uint64_t masked = cur_value & value_mask;
+
+ /* if the masked value is already matching, abort */
+ if (masked == expected_value)
+ return;
+ }
+ /* execute UMWAIT */
+ asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
+ : /* ignore rflags */
+ : "D"(0), /* enter C0.2 */
+ "a"(tsc_l), "d"(tsc_h));
+}
+
+/**
+ * This function uses UMONITOR/UMWAIT instructions and will enter C0.2 state.
+ * For more information about usage of these instructions, please refer to
+ * Intel(R) 64 and IA-32 Architectures Software Developer's Manual.
+ */
+void
+rte_power_monitor_sync(const volatile void *p, const uint64_t expected_value,
+ const uint64_t value_mask, const uint64_t tsc_timestamp,
+ const uint8_t data_sz, rte_spinlock_t *lck)
+{
+ const uint32_t tsc_l = (uint32_t)tsc_timestamp;
+ const uint32_t tsc_h = (uint32_t)(tsc_timestamp >> 32);
+ /*
+ * we're using raw byte codes for now as only the newest compiler
+ * versions support this instruction natively.
+ */
+
+ /* set address for UMONITOR */
+ asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
+ :
+ : "D"(p));
+
+ if (value_mask) {
+ const uint64_t cur_value = __get_umwait_val(p, data_sz);
+ const uint64_t masked = cur_value & value_mask;
+
+ /* if the masked value is already matching, abort */
+ if (masked == expected_value)
+ return;
+ }
+ rte_spinlock_unlock(lck);
+
+ /* execute UMWAIT */
+ asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
+ : /* ignore rflags */
+ : "D"(0), /* enter C0.2 */
+ "a"(tsc_l), "d"(tsc_h));
+
+ rte_spinlock_lock(lck);
+}
+
+/**
+ * This function uses TPAUSE instruction and will enter C0.2 state. For more
+ * information about usage of this instruction, please refer to Intel(R) 64 and
+ * IA-32 Architectures Software Developer's Manual.
+ */
+void
+rte_power_pause(const uint64_t tsc_timestamp)
+{
+ const uint32_t tsc_l = (uint32_t)tsc_timestamp;
+ const uint32_t tsc_h = (uint32_t)(tsc_timestamp >> 32);
+
+ /* execute TPAUSE */
+ asm volatile(".byte 0x66, 0x0f, 0xae, 0xf7;"
+ : /* ignore rflags */
+ : "D"(0), /* enter C0.2 */
+ "a"(tsc_l), "d"(tsc_h));
+}
--
2.25.1
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v15 01/11] eal: uninline power intrinsics
@ 2021-01-11 14:58 2% ` Anatoly Burakov
1 sibling, 0 replies; 200+ results
From: Anatoly Burakov @ 2021-01-11 14:58 UTC (permalink / raw)
To: dev
Cc: Jan Viktorin, Ruifeng Wang, Jerin Jacob, David Christensen,
Ray Kinsella, Neil Horman, Bruce Richardson, Konstantin Ananyev,
thomas, timothy.mcdaniel, david.hunt, chris.macnamara
Currently, power intrinsics are inline functions. Make them part of the
ABI so that we can have various internal data associated with them
without exposing said data to the outside world.
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
---
Notes:
v14:
- Fix compile issues on ARM and PPC64 by moving implementations to .c files
.../arm/include/rte_power_intrinsics.h | 40 ------
lib/librte_eal/arm/meson.build | 1 +
lib/librte_eal/arm/rte_power_intrinsics.c | 42 ++++++
.../include/generic/rte_power_intrinsics.h | 6 +-
.../ppc/include/rte_power_intrinsics.h | 40 ------
lib/librte_eal/ppc/meson.build | 1 +
lib/librte_eal/ppc/rte_power_intrinsics.c | 42 ++++++
lib/librte_eal/version.map | 5 +
.../x86/include/rte_power_intrinsics.h | 115 -----------------
lib/librte_eal/x86/meson.build | 1 +
lib/librte_eal/x86/rte_power_intrinsics.c | 120 ++++++++++++++++++
11 files changed, 215 insertions(+), 198 deletions(-)
create mode 100644 lib/librte_eal/arm/rte_power_intrinsics.c
create mode 100644 lib/librte_eal/ppc/rte_power_intrinsics.c
create mode 100644 lib/librte_eal/x86/rte_power_intrinsics.c
diff --git a/lib/librte_eal/arm/include/rte_power_intrinsics.h b/lib/librte_eal/arm/include/rte_power_intrinsics.h
index a4a1bc1159..9e498e9ebf 100644
--- a/lib/librte_eal/arm/include/rte_power_intrinsics.h
+++ b/lib/librte_eal/arm/include/rte_power_intrinsics.h
@@ -13,46 +13,6 @@ extern "C" {
#include "generic/rte_power_intrinsics.h"
-/**
- * This function is not supported on ARM.
- */
-static inline void
-rte_power_monitor(const volatile void *p, const uint64_t expected_value,
- const uint64_t value_mask, const uint64_t tsc_timestamp,
- const uint8_t data_sz)
-{
- RTE_SET_USED(p);
- RTE_SET_USED(expected_value);
- RTE_SET_USED(value_mask);
- RTE_SET_USED(tsc_timestamp);
- RTE_SET_USED(data_sz);
-}
-
-/**
- * This function is not supported on ARM.
- */
-static inline void
-rte_power_monitor_sync(const volatile void *p, const uint64_t expected_value,
- const uint64_t value_mask, const uint64_t tsc_timestamp,
- const uint8_t data_sz, rte_spinlock_t *lck)
-{
- RTE_SET_USED(p);
- RTE_SET_USED(expected_value);
- RTE_SET_USED(value_mask);
- RTE_SET_USED(tsc_timestamp);
- RTE_SET_USED(lck);
- RTE_SET_USED(data_sz);
-}
-
-/**
- * This function is not supported on ARM.
- */
-static inline void
-rte_power_pause(const uint64_t tsc_timestamp)
-{
- RTE_SET_USED(tsc_timestamp);
-}
-
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_eal/arm/meson.build b/lib/librte_eal/arm/meson.build
index d62875ebae..6ec53ea03a 100644
--- a/lib/librte_eal/arm/meson.build
+++ b/lib/librte_eal/arm/meson.build
@@ -7,4 +7,5 @@ sources += files(
'rte_cpuflags.c',
'rte_cycles.c',
'rte_hypervisor.c',
+ 'rte_power_intrinsics.c',
)
diff --git a/lib/librte_eal/arm/rte_power_intrinsics.c b/lib/librte_eal/arm/rte_power_intrinsics.c
new file mode 100644
index 0000000000..e5a49facb4
--- /dev/null
+++ b/lib/librte_eal/arm/rte_power_intrinsics.c
@@ -0,0 +1,42 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2021 Intel Corporation
+ */
+
+#include "rte_power_intrinsics.h"
+
+/**
+ * This function is not supported on ARM.
+ */
+void rte_power_monitor(const volatile void *p, const uint64_t expected_value,
+ const uint64_t value_mask, const uint64_t tsc_timestamp,
+ const uint8_t data_sz)
+{
+ RTE_SET_USED(p);
+ RTE_SET_USED(expected_value);
+ RTE_SET_USED(value_mask);
+ RTE_SET_USED(tsc_timestamp);
+ RTE_SET_USED(data_sz);
+}
+
+/**
+ * This function is not supported on ARM.
+ */
+void rte_power_monitor_sync(const volatile void *p, const uint64_t expected_value,
+ const uint64_t value_mask, const uint64_t tsc_timestamp,
+ const uint8_t data_sz, rte_spinlock_t *lck)
+{
+ RTE_SET_USED(p);
+ RTE_SET_USED(expected_value);
+ RTE_SET_USED(value_mask);
+ RTE_SET_USED(tsc_timestamp);
+ RTE_SET_USED(lck);
+ RTE_SET_USED(data_sz);
+}
+
+/**
+ * This function is not supported on ARM.
+ */
+void rte_power_pause(const uint64_t tsc_timestamp)
+{
+ RTE_SET_USED(tsc_timestamp);
+}
diff --git a/lib/librte_eal/include/generic/rte_power_intrinsics.h b/lib/librte_eal/include/generic/rte_power_intrinsics.h
index dd520d90fa..67977bd511 100644
--- a/lib/librte_eal/include/generic/rte_power_intrinsics.h
+++ b/lib/librte_eal/include/generic/rte_power_intrinsics.h
@@ -52,7 +52,7 @@
* to undefined result.
*/
__rte_experimental
-static inline void rte_power_monitor(const volatile void *p,
+void rte_power_monitor(const volatile void *p,
const uint64_t expected_value, const uint64_t value_mask,
const uint64_t tsc_timestamp, const uint8_t data_sz);
@@ -97,7 +97,7 @@ static inline void rte_power_monitor(const volatile void *p,
* wakes up.
*/
__rte_experimental
-static inline void rte_power_monitor_sync(const volatile void *p,
+void rte_power_monitor_sync(const volatile void *p,
const uint64_t expected_value, const uint64_t value_mask,
const uint64_t tsc_timestamp, const uint8_t data_sz,
rte_spinlock_t *lck);
@@ -118,6 +118,6 @@ static inline void rte_power_monitor_sync(const volatile void *p,
* architecture-dependent.
*/
__rte_experimental
-static inline void rte_power_pause(const uint64_t tsc_timestamp);
+void rte_power_pause(const uint64_t tsc_timestamp);
#endif /* _RTE_POWER_INTRINSIC_H_ */
diff --git a/lib/librte_eal/ppc/include/rte_power_intrinsics.h b/lib/librte_eal/ppc/include/rte_power_intrinsics.h
index 4ed03d521f..c0e9ac279f 100644
--- a/lib/librte_eal/ppc/include/rte_power_intrinsics.h
+++ b/lib/librte_eal/ppc/include/rte_power_intrinsics.h
@@ -13,46 +13,6 @@ extern "C" {
#include "generic/rte_power_intrinsics.h"
-/**
- * This function is not supported on PPC64.
- */
-static inline void
-rte_power_monitor(const volatile void *p, const uint64_t expected_value,
- const uint64_t value_mask, const uint64_t tsc_timestamp,
- const uint8_t data_sz)
-{
- RTE_SET_USED(p);
- RTE_SET_USED(expected_value);
- RTE_SET_USED(value_mask);
- RTE_SET_USED(tsc_timestamp);
- RTE_SET_USED(data_sz);
-}
-
-/**
- * This function is not supported on PPC64.
- */
-static inline void
-rte_power_monitor_sync(const volatile void *p, const uint64_t expected_value,
- const uint64_t value_mask, const uint64_t tsc_timestamp,
- const uint8_t data_sz, rte_spinlock_t *lck)
-{
- RTE_SET_USED(p);
- RTE_SET_USED(expected_value);
- RTE_SET_USED(value_mask);
- RTE_SET_USED(tsc_timestamp);
- RTE_SET_USED(lck);
- RTE_SET_USED(data_sz);
-}
-
-/**
- * This function is not supported on PPC64.
- */
-static inline void
-rte_power_pause(const uint64_t tsc_timestamp)
-{
- RTE_SET_USED(tsc_timestamp);
-}
-
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_eal/ppc/meson.build b/lib/librte_eal/ppc/meson.build
index f4b6d95c42..43c46542fb 100644
--- a/lib/librte_eal/ppc/meson.build
+++ b/lib/librte_eal/ppc/meson.build
@@ -7,4 +7,5 @@ sources += files(
'rte_cpuflags.c',
'rte_cycles.c',
'rte_hypervisor.c',
+ 'rte_power_intrinsics.c',
)
diff --git a/lib/librte_eal/ppc/rte_power_intrinsics.c b/lib/librte_eal/ppc/rte_power_intrinsics.c
new file mode 100644
index 0000000000..785effabe6
--- /dev/null
+++ b/lib/librte_eal/ppc/rte_power_intrinsics.c
@@ -0,0 +1,42 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2021 Intel Corporation
+ */
+
+#include "rte_power_intrinsics.h"
+
+/**
+ * This function is not supported on PPC64.
+ */
+void rte_power_monitor(const volatile void *p, const uint64_t expected_value,
+ const uint64_t value_mask, const uint64_t tsc_timestamp,
+ const uint8_t data_sz)
+{
+ RTE_SET_USED(p);
+ RTE_SET_USED(expected_value);
+ RTE_SET_USED(value_mask);
+ RTE_SET_USED(tsc_timestamp);
+ RTE_SET_USED(data_sz);
+}
+
+/**
+ * This function is not supported on PPC64.
+ */
+void rte_power_monitor_sync(const volatile void *p, const uint64_t expected_value,
+ const uint64_t value_mask, const uint64_t tsc_timestamp,
+ const uint8_t data_sz, rte_spinlock_t *lck)
+{
+ RTE_SET_USED(p);
+ RTE_SET_USED(expected_value);
+ RTE_SET_USED(value_mask);
+ RTE_SET_USED(tsc_timestamp);
+ RTE_SET_USED(lck);
+ RTE_SET_USED(data_sz);
+}
+
+/**
+ * This function is not supported on PPC64.
+ */
+void rte_power_pause(const uint64_t tsc_timestamp)
+{
+ RTE_SET_USED(tsc_timestamp);
+}
diff --git a/lib/librte_eal/version.map b/lib/librte_eal/version.map
index 354c068f31..31bf76ae81 100644
--- a/lib/librte_eal/version.map
+++ b/lib/librte_eal/version.map
@@ -403,6 +403,11 @@ EXPERIMENTAL {
rte_service_lcore_may_be_active;
rte_vect_get_max_simd_bitwidth;
rte_vect_set_max_simd_bitwidth;
+
+ # added in 21.02
+ rte_power_monitor;
+ rte_power_monitor_sync;
+ rte_power_pause;
};
INTERNAL {
diff --git a/lib/librte_eal/x86/include/rte_power_intrinsics.h b/lib/librte_eal/x86/include/rte_power_intrinsics.h
index c7d790c854..e4c2b87f73 100644
--- a/lib/librte_eal/x86/include/rte_power_intrinsics.h
+++ b/lib/librte_eal/x86/include/rte_power_intrinsics.h
@@ -13,121 +13,6 @@ extern "C" {
#include "generic/rte_power_intrinsics.h"
-static inline uint64_t
-__rte_power_get_umwait_val(const volatile void *p, const uint8_t sz)
-{
- switch (sz) {
- case sizeof(uint8_t):
- return *(const volatile uint8_t *)p;
- case sizeof(uint16_t):
- return *(const volatile uint16_t *)p;
- case sizeof(uint32_t):
- return *(const volatile uint32_t *)p;
- case sizeof(uint64_t):
- return *(const volatile uint64_t *)p;
- default:
- /* this is an intrinsic, so we can't have any error handling */
- RTE_ASSERT(0);
- return 0;
- }
-}
-
-/**
- * This function uses UMONITOR/UMWAIT instructions and will enter C0.2 state.
- * For more information about usage of these instructions, please refer to
- * Intel(R) 64 and IA-32 Architectures Software Developer's Manual.
- */
-static inline void
-rte_power_monitor(const volatile void *p, const uint64_t expected_value,
- const uint64_t value_mask, const uint64_t tsc_timestamp,
- const uint8_t data_sz)
-{
- const uint32_t tsc_l = (uint32_t)tsc_timestamp;
- const uint32_t tsc_h = (uint32_t)(tsc_timestamp >> 32);
- /*
- * we're using raw byte codes for now as only the newest compiler
- * versions support this instruction natively.
- */
-
- /* set address for UMONITOR */
- asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
- :
- : "D"(p));
-
- if (value_mask) {
- const uint64_t cur_value = __rte_power_get_umwait_val(p, data_sz);
- const uint64_t masked = cur_value & value_mask;
-
- /* if the masked value is already matching, abort */
- if (masked == expected_value)
- return;
- }
- /* execute UMWAIT */
- asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
- : /* ignore rflags */
- : "D"(0), /* enter C0.2 */
- "a"(tsc_l), "d"(tsc_h));
-}
-
-/**
- * This function uses UMONITOR/UMWAIT instructions and will enter C0.2 state.
- * For more information about usage of these instructions, please refer to
- * Intel(R) 64 and IA-32 Architectures Software Developer's Manual.
- */
-static inline void
-rte_power_monitor_sync(const volatile void *p, const uint64_t expected_value,
- const uint64_t value_mask, const uint64_t tsc_timestamp,
- const uint8_t data_sz, rte_spinlock_t *lck)
-{
- const uint32_t tsc_l = (uint32_t)tsc_timestamp;
- const uint32_t tsc_h = (uint32_t)(tsc_timestamp >> 32);
- /*
- * we're using raw byte codes for now as only the newest compiler
- * versions support this instruction natively.
- */
-
- /* set address for UMONITOR */
- asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
- :
- : "D"(p));
-
- if (value_mask) {
- const uint64_t cur_value = __rte_power_get_umwait_val(p, data_sz);
- const uint64_t masked = cur_value & value_mask;
-
- /* if the masked value is already matching, abort */
- if (masked == expected_value)
- return;
- }
- rte_spinlock_unlock(lck);
-
- /* execute UMWAIT */
- asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
- : /* ignore rflags */
- : "D"(0), /* enter C0.2 */
- "a"(tsc_l), "d"(tsc_h));
-
- rte_spinlock_lock(lck);
-}
-
-/**
- * This function uses TPAUSE instruction and will enter C0.2 state. For more
- * information about usage of this instruction, please refer to Intel(R) 64 and
- * IA-32 Architectures Software Developer's Manual.
- */
-static inline void
-rte_power_pause(const uint64_t tsc_timestamp)
-{
- const uint32_t tsc_l = (uint32_t)tsc_timestamp;
- const uint32_t tsc_h = (uint32_t)(tsc_timestamp >> 32);
-
- /* execute TPAUSE */
- asm volatile(".byte 0x66, 0x0f, 0xae, 0xf7;"
- : /* ignore rflags */
- : "D"(0), /* enter C0.2 */
- "a"(tsc_l), "d"(tsc_h));
-}
-
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_eal/x86/meson.build b/lib/librte_eal/x86/meson.build
index e78f29002e..dfd42dee0c 100644
--- a/lib/librte_eal/x86/meson.build
+++ b/lib/librte_eal/x86/meson.build
@@ -8,4 +8,5 @@ sources += files(
'rte_cycles.c',
'rte_hypervisor.c',
'rte_spinlock.c',
+ 'rte_power_intrinsics.c',
)
diff --git a/lib/librte_eal/x86/rte_power_intrinsics.c b/lib/librte_eal/x86/rte_power_intrinsics.c
new file mode 100644
index 0000000000..34c5fd9c3e
--- /dev/null
+++ b/lib/librte_eal/x86/rte_power_intrinsics.c
@@ -0,0 +1,120 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2020 Intel Corporation
+ */
+
+#include "rte_power_intrinsics.h"
+
+static inline uint64_t
+__get_umwait_val(const volatile void *p, const uint8_t sz)
+{
+ switch (sz) {
+ case sizeof(uint8_t):
+ return *(const volatile uint8_t *)p;
+ case sizeof(uint16_t):
+ return *(const volatile uint16_t *)p;
+ case sizeof(uint32_t):
+ return *(const volatile uint32_t *)p;
+ case sizeof(uint64_t):
+ return *(const volatile uint64_t *)p;
+ default:
+ /* this is an intrinsic, so we can't have any error handling */
+ RTE_ASSERT(0);
+ return 0;
+ }
+}
+
+/**
+ * This function uses UMONITOR/UMWAIT instructions and will enter C0.2 state.
+ * For more information about usage of these instructions, please refer to
+ * Intel(R) 64 and IA-32 Architectures Software Developer's Manual.
+ */
+void
+rte_power_monitor(const volatile void *p, const uint64_t expected_value,
+ const uint64_t value_mask, const uint64_t tsc_timestamp,
+ const uint8_t data_sz)
+{
+ const uint32_t tsc_l = (uint32_t)tsc_timestamp;
+ const uint32_t tsc_h = (uint32_t)(tsc_timestamp >> 32);
+ /*
+ * we're using raw byte codes for now as only the newest compiler
+ * versions support this instruction natively.
+ */
+
+ /* set address for UMONITOR */
+ asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
+ :
+ : "D"(p));
+
+ if (value_mask) {
+ const uint64_t cur_value = __get_umwait_val(p, data_sz);
+ const uint64_t masked = cur_value & value_mask;
+
+ /* if the masked value is already matching, abort */
+ if (masked == expected_value)
+ return;
+ }
+ /* execute UMWAIT */
+ asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
+ : /* ignore rflags */
+ : "D"(0), /* enter C0.2 */
+ "a"(tsc_l), "d"(tsc_h));
+}
+
+/**
+ * This function uses UMONITOR/UMWAIT instructions and will enter C0.2 state.
+ * For more information about usage of these instructions, please refer to
+ * Intel(R) 64 and IA-32 Architectures Software Developer's Manual.
+ */
+void
+rte_power_monitor_sync(const volatile void *p, const uint64_t expected_value,
+ const uint64_t value_mask, const uint64_t tsc_timestamp,
+ const uint8_t data_sz, rte_spinlock_t *lck)
+{
+ const uint32_t tsc_l = (uint32_t)tsc_timestamp;
+ const uint32_t tsc_h = (uint32_t)(tsc_timestamp >> 32);
+ /*
+ * we're using raw byte codes for now as only the newest compiler
+ * versions support this instruction natively.
+ */
+
+ /* set address for UMONITOR */
+ asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
+ :
+ : "D"(p));
+
+ if (value_mask) {
+ const uint64_t cur_value = __get_umwait_val(p, data_sz);
+ const uint64_t masked = cur_value & value_mask;
+
+ /* if the masked value is already matching, abort */
+ if (masked == expected_value)
+ return;
+ }
+ rte_spinlock_unlock(lck);
+
+ /* execute UMWAIT */
+ asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
+ : /* ignore rflags */
+ : "D"(0), /* enter C0.2 */
+ "a"(tsc_l), "d"(tsc_h));
+
+ rte_spinlock_lock(lck);
+}
+
+/**
+ * This function uses TPAUSE instruction and will enter C0.2 state. For more
+ * information about usage of this instruction, please refer to Intel(R) 64 and
+ * IA-32 Architectures Software Developer's Manual.
+ */
+void
+rte_power_pause(const uint64_t tsc_timestamp)
+{
+ const uint32_t tsc_l = (uint32_t)tsc_timestamp;
+ const uint32_t tsc_h = (uint32_t)(tsc_timestamp >> 32);
+
+ /* execute TPAUSE */
+ asm volatile(".byte 0x66, 0x0f, 0xae, 0xf7;"
+ : /* ignore rflags */
+ : "D"(0), /* enter C0.2 */
+ "a"(tsc_l), "d"(tsc_h));
+}
--
2.25.1
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH] eal/rwlock: add note about writer starvation
2021-01-08 19:13 4% [dpdk-dev] Reader-Writer lock starvation issues Stephen Hemminger
2021-01-08 21:27 0% ` Honnappa Nagarahalli
@ 2021-01-12 1:04 3% ` Stephen Hemminger
2021-01-14 16:55 3% ` [dpdk-dev] [PATCH v2] " Stephen Hemminger
1 sibling, 1 reply; 200+ results
From: Stephen Hemminger @ 2021-01-12 1:04 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger, stable
The implementation of reader/writer locks in DPDK (from first release)
is simple and fast. But it can lead to writer starvation issues.
It is not easy to fix this without changing ABI and potentially
breaking customer applications that are expect the unfair behavior.
Therfore this patch just changes the documentation.
The wikipedia page on reader-writer problem has a similar example
which summarizes the problem pretty well.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Cc: stable@dpdk.org
---
lib/librte_eal/include/generic/rte_rwlock.h | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/lib/librte_eal/include/generic/rte_rwlock.h b/lib/librte_eal/include/generic/rte_rwlock.h
index da9bc3e9c0e2..0b30c780fc34 100644
--- a/lib/librte_eal/include/generic/rte_rwlock.h
+++ b/lib/librte_eal/include/generic/rte_rwlock.h
@@ -15,6 +15,14 @@
* one writer. All readers are blocked until the writer is finished
* writing.
*
+ * Note: This version of reader/writer locks is not fair because
+ * readers do not block for pending writers. A stream of readers can
+ * subsequently lock all potential writers out and starve them.
+ * This is because after the first reader locks the resource,
+ * no writer can lock it, before it gets released.
+ * And it will only be released by the last reader.
+ *
+ * See also: https://en.wikipedia.org/wiki/Readers%E2%80%93writers_problem
*/
#ifdef __cplusplus
--
2.29.2
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v13 01/11] eal: uninline power intrinsics
2021-01-08 17:42 2% ` [dpdk-dev] [PATCH v13 01/11] eal: uninline power intrinsics Anatoly Burakov
@ 2021-01-12 15:54 0% ` Ananyev, Konstantin
0 siblings, 0 replies; 200+ results
From: Ananyev, Konstantin @ 2021-01-12 15:54 UTC (permalink / raw)
To: Burakov, Anatoly, dev
Cc: Jan Viktorin, Ruifeng Wang, Jerin Jacob, David Christensen,
Ray Kinsella, Neil Horman, Richardson, Bruce, thomas, McDaniel,
Timothy, Hunt, David, Macnamara, Chris
> -----Original Message-----
> From: Burakov, Anatoly <anatoly.burakov@intel.com>
> Sent: Friday, January 8, 2021 5:42 PM
> To: dev@dpdk.org
> Cc: Jan Viktorin <viktorin@rehivetech.com>; Ruifeng Wang <ruifeng.wang@arm.com>; Jerin Jacob <jerinj@marvell.com>; David
> Christensen <drc@linux.vnet.ibm.com>; Ray Kinsella <mdr@ashroe.eu>; Neil Horman <nhorman@tuxdriver.com>; Richardson, Bruce
> <bruce.richardson@intel.com>; Ananyev, Konstantin <konstantin.ananyev@intel.com>; thomas@monjalon.net; gage.eads@intel.com;
> McDaniel, Timothy <timothy.mcdaniel@intel.com>; Hunt, David <david.hunt@intel.com>; Macnamara, Chris
> <chris.macnamara@intel.com>
> Subject: [PATCH v13 01/11] eal: uninline power intrinsics
>
> Currently, power intrinsics are inline functions. Make them part of the
> ABI so that we can have various internal data associated with them
> without exposing said data to the outside world.
>
> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> ---
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> --
> 2.25.1
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v16 01/11] eal: uninline power intrinsics
@ 2021-01-12 17:37 2% ` Anatoly Burakov
2021-01-14 9:36 9% ` [dpdk-dev] [PATCH v16 00/11] Add PMD power management David Marchand
2021-01-14 14:46 2% ` [dpdk-dev] [PATCH v17 " Anatoly Burakov
2 siblings, 0 replies; 200+ results
From: Anatoly Burakov @ 2021-01-12 17:37 UTC (permalink / raw)
To: dev
Cc: Jan Viktorin, Ruifeng Wang, Jerin Jacob, David Christensen,
Ray Kinsella, Neil Horman, Bruce Richardson, Konstantin Ananyev,
thomas, timothy.mcdaniel, david.hunt, chris.macnamara
Currently, power intrinsics are inline functions. Make them part of the
ABI so that we can have various internal data associated with them
without exposing said data to the outside world.
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
---
Notes:
v14:
- Fix compile issues on ARM and PPC64 by moving implementations to .c files
.../arm/include/rte_power_intrinsics.h | 40 ------
lib/librte_eal/arm/meson.build | 1 +
lib/librte_eal/arm/rte_power_intrinsics.c | 45 +++++++
.../include/generic/rte_power_intrinsics.h | 6 +-
.../ppc/include/rte_power_intrinsics.h | 40 ------
lib/librte_eal/ppc/meson.build | 1 +
lib/librte_eal/ppc/rte_power_intrinsics.c | 45 +++++++
lib/librte_eal/version.map | 3 +
.../x86/include/rte_power_intrinsics.h | 115 -----------------
lib/librte_eal/x86/meson.build | 1 +
lib/librte_eal/x86/rte_power_intrinsics.c | 120 ++++++++++++++++++
11 files changed, 219 insertions(+), 198 deletions(-)
create mode 100644 lib/librte_eal/arm/rte_power_intrinsics.c
create mode 100644 lib/librte_eal/ppc/rte_power_intrinsics.c
create mode 100644 lib/librte_eal/x86/rte_power_intrinsics.c
diff --git a/lib/librte_eal/arm/include/rte_power_intrinsics.h b/lib/librte_eal/arm/include/rte_power_intrinsics.h
index a4a1bc1159..9e498e9ebf 100644
--- a/lib/librte_eal/arm/include/rte_power_intrinsics.h
+++ b/lib/librte_eal/arm/include/rte_power_intrinsics.h
@@ -13,46 +13,6 @@ extern "C" {
#include "generic/rte_power_intrinsics.h"
-/**
- * This function is not supported on ARM.
- */
-static inline void
-rte_power_monitor(const volatile void *p, const uint64_t expected_value,
- const uint64_t value_mask, const uint64_t tsc_timestamp,
- const uint8_t data_sz)
-{
- RTE_SET_USED(p);
- RTE_SET_USED(expected_value);
- RTE_SET_USED(value_mask);
- RTE_SET_USED(tsc_timestamp);
- RTE_SET_USED(data_sz);
-}
-
-/**
- * This function is not supported on ARM.
- */
-static inline void
-rte_power_monitor_sync(const volatile void *p, const uint64_t expected_value,
- const uint64_t value_mask, const uint64_t tsc_timestamp,
- const uint8_t data_sz, rte_spinlock_t *lck)
-{
- RTE_SET_USED(p);
- RTE_SET_USED(expected_value);
- RTE_SET_USED(value_mask);
- RTE_SET_USED(tsc_timestamp);
- RTE_SET_USED(lck);
- RTE_SET_USED(data_sz);
-}
-
-/**
- * This function is not supported on ARM.
- */
-static inline void
-rte_power_pause(const uint64_t tsc_timestamp)
-{
- RTE_SET_USED(tsc_timestamp);
-}
-
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_eal/arm/meson.build b/lib/librte_eal/arm/meson.build
index d62875ebae..6ec53ea03a 100644
--- a/lib/librte_eal/arm/meson.build
+++ b/lib/librte_eal/arm/meson.build
@@ -7,4 +7,5 @@ sources += files(
'rte_cpuflags.c',
'rte_cycles.c',
'rte_hypervisor.c',
+ 'rte_power_intrinsics.c',
)
diff --git a/lib/librte_eal/arm/rte_power_intrinsics.c b/lib/librte_eal/arm/rte_power_intrinsics.c
new file mode 100644
index 0000000000..ab1f44f611
--- /dev/null
+++ b/lib/librte_eal/arm/rte_power_intrinsics.c
@@ -0,0 +1,45 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2021 Intel Corporation
+ */
+
+#include "rte_power_intrinsics.h"
+
+/**
+ * This function is not supported on ARM.
+ */
+void
+rte_power_monitor(const volatile void *p, const uint64_t expected_value,
+ const uint64_t value_mask, const uint64_t tsc_timestamp,
+ const uint8_t data_sz)
+{
+ RTE_SET_USED(p);
+ RTE_SET_USED(expected_value);
+ RTE_SET_USED(value_mask);
+ RTE_SET_USED(tsc_timestamp);
+ RTE_SET_USED(data_sz);
+}
+
+/**
+ * This function is not supported on ARM.
+ */
+void
+rte_power_monitor_sync(const volatile void *p, const uint64_t expected_value,
+ const uint64_t value_mask, const uint64_t tsc_timestamp,
+ const uint8_t data_sz, rte_spinlock_t *lck)
+{
+ RTE_SET_USED(p);
+ RTE_SET_USED(expected_value);
+ RTE_SET_USED(value_mask);
+ RTE_SET_USED(tsc_timestamp);
+ RTE_SET_USED(lck);
+ RTE_SET_USED(data_sz);
+}
+
+/**
+ * This function is not supported on ARM.
+ */
+void
+rte_power_pause(const uint64_t tsc_timestamp)
+{
+ RTE_SET_USED(tsc_timestamp);
+}
diff --git a/lib/librte_eal/include/generic/rte_power_intrinsics.h b/lib/librte_eal/include/generic/rte_power_intrinsics.h
index dd520d90fa..67977bd511 100644
--- a/lib/librte_eal/include/generic/rte_power_intrinsics.h
+++ b/lib/librte_eal/include/generic/rte_power_intrinsics.h
@@ -52,7 +52,7 @@
* to undefined result.
*/
__rte_experimental
-static inline void rte_power_monitor(const volatile void *p,
+void rte_power_monitor(const volatile void *p,
const uint64_t expected_value, const uint64_t value_mask,
const uint64_t tsc_timestamp, const uint8_t data_sz);
@@ -97,7 +97,7 @@ static inline void rte_power_monitor(const volatile void *p,
* wakes up.
*/
__rte_experimental
-static inline void rte_power_monitor_sync(const volatile void *p,
+void rte_power_monitor_sync(const volatile void *p,
const uint64_t expected_value, const uint64_t value_mask,
const uint64_t tsc_timestamp, const uint8_t data_sz,
rte_spinlock_t *lck);
@@ -118,6 +118,6 @@ static inline void rte_power_monitor_sync(const volatile void *p,
* architecture-dependent.
*/
__rte_experimental
-static inline void rte_power_pause(const uint64_t tsc_timestamp);
+void rte_power_pause(const uint64_t tsc_timestamp);
#endif /* _RTE_POWER_INTRINSIC_H_ */
diff --git a/lib/librte_eal/ppc/include/rte_power_intrinsics.h b/lib/librte_eal/ppc/include/rte_power_intrinsics.h
index 4ed03d521f..c0e9ac279f 100644
--- a/lib/librte_eal/ppc/include/rte_power_intrinsics.h
+++ b/lib/librte_eal/ppc/include/rte_power_intrinsics.h
@@ -13,46 +13,6 @@ extern "C" {
#include "generic/rte_power_intrinsics.h"
-/**
- * This function is not supported on PPC64.
- */
-static inline void
-rte_power_monitor(const volatile void *p, const uint64_t expected_value,
- const uint64_t value_mask, const uint64_t tsc_timestamp,
- const uint8_t data_sz)
-{
- RTE_SET_USED(p);
- RTE_SET_USED(expected_value);
- RTE_SET_USED(value_mask);
- RTE_SET_USED(tsc_timestamp);
- RTE_SET_USED(data_sz);
-}
-
-/**
- * This function is not supported on PPC64.
- */
-static inline void
-rte_power_monitor_sync(const volatile void *p, const uint64_t expected_value,
- const uint64_t value_mask, const uint64_t tsc_timestamp,
- const uint8_t data_sz, rte_spinlock_t *lck)
-{
- RTE_SET_USED(p);
- RTE_SET_USED(expected_value);
- RTE_SET_USED(value_mask);
- RTE_SET_USED(tsc_timestamp);
- RTE_SET_USED(lck);
- RTE_SET_USED(data_sz);
-}
-
-/**
- * This function is not supported on PPC64.
- */
-static inline void
-rte_power_pause(const uint64_t tsc_timestamp)
-{
- RTE_SET_USED(tsc_timestamp);
-}
-
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_eal/ppc/meson.build b/lib/librte_eal/ppc/meson.build
index f4b6d95c42..43c46542fb 100644
--- a/lib/librte_eal/ppc/meson.build
+++ b/lib/librte_eal/ppc/meson.build
@@ -7,4 +7,5 @@ sources += files(
'rte_cpuflags.c',
'rte_cycles.c',
'rte_hypervisor.c',
+ 'rte_power_intrinsics.c',
)
diff --git a/lib/librte_eal/ppc/rte_power_intrinsics.c b/lib/librte_eal/ppc/rte_power_intrinsics.c
new file mode 100644
index 0000000000..84340ca2a4
--- /dev/null
+++ b/lib/librte_eal/ppc/rte_power_intrinsics.c
@@ -0,0 +1,45 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2021 Intel Corporation
+ */
+
+#include "rte_power_intrinsics.h"
+
+/**
+ * This function is not supported on PPC64.
+ */
+void
+rte_power_monitor(const volatile void *p, const uint64_t expected_value,
+ const uint64_t value_mask, const uint64_t tsc_timestamp,
+ const uint8_t data_sz)
+{
+ RTE_SET_USED(p);
+ RTE_SET_USED(expected_value);
+ RTE_SET_USED(value_mask);
+ RTE_SET_USED(tsc_timestamp);
+ RTE_SET_USED(data_sz);
+}
+
+/**
+ * This function is not supported on PPC64.
+ */
+void
+rte_power_monitor_sync(const volatile void *p, const uint64_t expected_value,
+ const uint64_t value_mask, const uint64_t tsc_timestamp,
+ const uint8_t data_sz, rte_spinlock_t *lck)
+{
+ RTE_SET_USED(p);
+ RTE_SET_USED(expected_value);
+ RTE_SET_USED(value_mask);
+ RTE_SET_USED(tsc_timestamp);
+ RTE_SET_USED(lck);
+ RTE_SET_USED(data_sz);
+}
+
+/**
+ * This function is not supported on PPC64.
+ */
+void
+rte_power_pause(const uint64_t tsc_timestamp)
+{
+ RTE_SET_USED(tsc_timestamp);
+}
diff --git a/lib/librte_eal/version.map b/lib/librte_eal/version.map
index b1db7ec795..32eceb8869 100644
--- a/lib/librte_eal/version.map
+++ b/lib/librte_eal/version.map
@@ -405,6 +405,9 @@ EXPERIMENTAL {
rte_vect_set_max_simd_bitwidth;
# added in 21.02
+ rte_power_monitor;
+ rte_power_monitor_sync;
+ rte_power_pause;
rte_thread_tls_key_create;
rte_thread_tls_key_delete;
rte_thread_tls_value_get;
diff --git a/lib/librte_eal/x86/include/rte_power_intrinsics.h b/lib/librte_eal/x86/include/rte_power_intrinsics.h
index c7d790c854..e4c2b87f73 100644
--- a/lib/librte_eal/x86/include/rte_power_intrinsics.h
+++ b/lib/librte_eal/x86/include/rte_power_intrinsics.h
@@ -13,121 +13,6 @@ extern "C" {
#include "generic/rte_power_intrinsics.h"
-static inline uint64_t
-__rte_power_get_umwait_val(const volatile void *p, const uint8_t sz)
-{
- switch (sz) {
- case sizeof(uint8_t):
- return *(const volatile uint8_t *)p;
- case sizeof(uint16_t):
- return *(const volatile uint16_t *)p;
- case sizeof(uint32_t):
- return *(const volatile uint32_t *)p;
- case sizeof(uint64_t):
- return *(const volatile uint64_t *)p;
- default:
- /* this is an intrinsic, so we can't have any error handling */
- RTE_ASSERT(0);
- return 0;
- }
-}
-
-/**
- * This function uses UMONITOR/UMWAIT instructions and will enter C0.2 state.
- * For more information about usage of these instructions, please refer to
- * Intel(R) 64 and IA-32 Architectures Software Developer's Manual.
- */
-static inline void
-rte_power_monitor(const volatile void *p, const uint64_t expected_value,
- const uint64_t value_mask, const uint64_t tsc_timestamp,
- const uint8_t data_sz)
-{
- const uint32_t tsc_l = (uint32_t)tsc_timestamp;
- const uint32_t tsc_h = (uint32_t)(tsc_timestamp >> 32);
- /*
- * we're using raw byte codes for now as only the newest compiler
- * versions support this instruction natively.
- */
-
- /* set address for UMONITOR */
- asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
- :
- : "D"(p));
-
- if (value_mask) {
- const uint64_t cur_value = __rte_power_get_umwait_val(p, data_sz);
- const uint64_t masked = cur_value & value_mask;
-
- /* if the masked value is already matching, abort */
- if (masked == expected_value)
- return;
- }
- /* execute UMWAIT */
- asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
- : /* ignore rflags */
- : "D"(0), /* enter C0.2 */
- "a"(tsc_l), "d"(tsc_h));
-}
-
-/**
- * This function uses UMONITOR/UMWAIT instructions and will enter C0.2 state.
- * For more information about usage of these instructions, please refer to
- * Intel(R) 64 and IA-32 Architectures Software Developer's Manual.
- */
-static inline void
-rte_power_monitor_sync(const volatile void *p, const uint64_t expected_value,
- const uint64_t value_mask, const uint64_t tsc_timestamp,
- const uint8_t data_sz, rte_spinlock_t *lck)
-{
- const uint32_t tsc_l = (uint32_t)tsc_timestamp;
- const uint32_t tsc_h = (uint32_t)(tsc_timestamp >> 32);
- /*
- * we're using raw byte codes for now as only the newest compiler
- * versions support this instruction natively.
- */
-
- /* set address for UMONITOR */
- asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
- :
- : "D"(p));
-
- if (value_mask) {
- const uint64_t cur_value = __rte_power_get_umwait_val(p, data_sz);
- const uint64_t masked = cur_value & value_mask;
-
- /* if the masked value is already matching, abort */
- if (masked == expected_value)
- return;
- }
- rte_spinlock_unlock(lck);
-
- /* execute UMWAIT */
- asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
- : /* ignore rflags */
- : "D"(0), /* enter C0.2 */
- "a"(tsc_l), "d"(tsc_h));
-
- rte_spinlock_lock(lck);
-}
-
-/**
- * This function uses TPAUSE instruction and will enter C0.2 state. For more
- * information about usage of this instruction, please refer to Intel(R) 64 and
- * IA-32 Architectures Software Developer's Manual.
- */
-static inline void
-rte_power_pause(const uint64_t tsc_timestamp)
-{
- const uint32_t tsc_l = (uint32_t)tsc_timestamp;
- const uint32_t tsc_h = (uint32_t)(tsc_timestamp >> 32);
-
- /* execute TPAUSE */
- asm volatile(".byte 0x66, 0x0f, 0xae, 0xf7;"
- : /* ignore rflags */
- : "D"(0), /* enter C0.2 */
- "a"(tsc_l), "d"(tsc_h));
-}
-
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_eal/x86/meson.build b/lib/librte_eal/x86/meson.build
index e78f29002e..dfd42dee0c 100644
--- a/lib/librte_eal/x86/meson.build
+++ b/lib/librte_eal/x86/meson.build
@@ -8,4 +8,5 @@ sources += files(
'rte_cycles.c',
'rte_hypervisor.c',
'rte_spinlock.c',
+ 'rte_power_intrinsics.c',
)
diff --git a/lib/librte_eal/x86/rte_power_intrinsics.c b/lib/librte_eal/x86/rte_power_intrinsics.c
new file mode 100644
index 0000000000..34c5fd9c3e
--- /dev/null
+++ b/lib/librte_eal/x86/rte_power_intrinsics.c
@@ -0,0 +1,120 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2020 Intel Corporation
+ */
+
+#include "rte_power_intrinsics.h"
+
+static inline uint64_t
+__get_umwait_val(const volatile void *p, const uint8_t sz)
+{
+ switch (sz) {
+ case sizeof(uint8_t):
+ return *(const volatile uint8_t *)p;
+ case sizeof(uint16_t):
+ return *(const volatile uint16_t *)p;
+ case sizeof(uint32_t):
+ return *(const volatile uint32_t *)p;
+ case sizeof(uint64_t):
+ return *(const volatile uint64_t *)p;
+ default:
+ /* this is an intrinsic, so we can't have any error handling */
+ RTE_ASSERT(0);
+ return 0;
+ }
+}
+
+/**
+ * This function uses UMONITOR/UMWAIT instructions and will enter C0.2 state.
+ * For more information about usage of these instructions, please refer to
+ * Intel(R) 64 and IA-32 Architectures Software Developer's Manual.
+ */
+void
+rte_power_monitor(const volatile void *p, const uint64_t expected_value,
+ const uint64_t value_mask, const uint64_t tsc_timestamp,
+ const uint8_t data_sz)
+{
+ const uint32_t tsc_l = (uint32_t)tsc_timestamp;
+ const uint32_t tsc_h = (uint32_t)(tsc_timestamp >> 32);
+ /*
+ * we're using raw byte codes for now as only the newest compiler
+ * versions support this instruction natively.
+ */
+
+ /* set address for UMONITOR */
+ asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
+ :
+ : "D"(p));
+
+ if (value_mask) {
+ const uint64_t cur_value = __get_umwait_val(p, data_sz);
+ const uint64_t masked = cur_value & value_mask;
+
+ /* if the masked value is already matching, abort */
+ if (masked == expected_value)
+ return;
+ }
+ /* execute UMWAIT */
+ asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
+ : /* ignore rflags */
+ : "D"(0), /* enter C0.2 */
+ "a"(tsc_l), "d"(tsc_h));
+}
+
+/**
+ * This function uses UMONITOR/UMWAIT instructions and will enter C0.2 state.
+ * For more information about usage of these instructions, please refer to
+ * Intel(R) 64 and IA-32 Architectures Software Developer's Manual.
+ */
+void
+rte_power_monitor_sync(const volatile void *p, const uint64_t expected_value,
+ const uint64_t value_mask, const uint64_t tsc_timestamp,
+ const uint8_t data_sz, rte_spinlock_t *lck)
+{
+ const uint32_t tsc_l = (uint32_t)tsc_timestamp;
+ const uint32_t tsc_h = (uint32_t)(tsc_timestamp >> 32);
+ /*
+ * we're using raw byte codes for now as only the newest compiler
+ * versions support this instruction natively.
+ */
+
+ /* set address for UMONITOR */
+ asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
+ :
+ : "D"(p));
+
+ if (value_mask) {
+ const uint64_t cur_value = __get_umwait_val(p, data_sz);
+ const uint64_t masked = cur_value & value_mask;
+
+ /* if the masked value is already matching, abort */
+ if (masked == expected_value)
+ return;
+ }
+ rte_spinlock_unlock(lck);
+
+ /* execute UMWAIT */
+ asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
+ : /* ignore rflags */
+ : "D"(0), /* enter C0.2 */
+ "a"(tsc_l), "d"(tsc_h));
+
+ rte_spinlock_lock(lck);
+}
+
+/**
+ * This function uses TPAUSE instruction and will enter C0.2 state. For more
+ * information about usage of this instruction, please refer to Intel(R) 64 and
+ * IA-32 Architectures Software Developer's Manual.
+ */
+void
+rte_power_pause(const uint64_t tsc_timestamp)
+{
+ const uint32_t tsc_l = (uint32_t)tsc_timestamp;
+ const uint32_t tsc_h = (uint32_t)(tsc_timestamp >> 32);
+
+ /* execute TPAUSE */
+ asm volatile(".byte 0x66, 0x0f, 0xae, 0xf7;"
+ : /* ignore rflags */
+ : "D"(0), /* enter C0.2 */
+ "a"(tsc_l), "d"(tsc_h));
+}
--
2.25.1
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH] doc: recommend GitHub Actions for CI
@ 2021-01-13 9:03 5% David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2021-01-13 9:03 UTC (permalink / raw)
To: dev; +Cc: thomas, Aaron Conole
Update the contributing guidelines to describe GitHub Actions first and
add a warning about Travis usage.
Fixes: 87009585e293 ("ci: hook to GitHub Actions")
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
doc/guides/contributing/patches.rst | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index 4e9140bca4..6dbbd5f8d1 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -32,9 +32,12 @@ The mailing list for DPDK development is `dev@dpdk.org <https://mails.dpdk.org/a
Contributors will need to `register for the mailing list <https://mails.dpdk.org/listinfo/dev>`_ in order to submit patches.
It is also worth registering for the DPDK `Patchwork <https://patches.dpdk.org/project/dpdk/list/>`_
-If you are using the GitHub service, you can link your repository to
-the ``travis-ci.org`` build service. When you push patches to your GitHub
-repository, the travis service will automatically build your changes.
+If you are using the GitHub service, pushing to a branch will trigger GitHub
+Actions to automatically build your changes and run unit tests and ABI checks.
+
+Additionally, a Travis configuration is available in DPDK but Travis free usage
+is limited to a few builds.
+You can link your repository to the ``travis-ci.com`` build service.
The development process requires some familiarity with the ``git`` version control system.
Refer to the `Pro Git Book <http://www.git-scm.com/book/>`_ for further information.
--
2.23.0
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH v2 1/1] devtools: adjust verbosity of ABI check
@ 2021-01-13 9:21 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2021-01-13 9:21 UTC (permalink / raw)
To: dev; +Cc: david.marchand, bruce.richardson, Ray Kinsella, Neil Horman
17/12/2020 10:05, Thomas Monjalon:
> The scripts gen-abi.sh and check-abi.sh are updated
> to print error messages to stderr so they are likely never ignored.
>
> When called from test-meson-builds.sh, the standard messages on stdout
> can be more quiet depending on the verbosity settings.
> The beginning of the ABI check is announced in verbose mode.
> The commands are printed in very verbose mode.
> The check result details are available in verbose mode.
>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> ---
> v2: remove abidiff command from stdout (already printed on error)
Applied
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v12 06/11] ethdev: add simple power management API
@ 2021-01-13 13:25 3% ` Ananyev, Konstantin
0 siblings, 0 replies; 200+ results
From: Ananyev, Konstantin @ 2021-01-13 13:25 UTC (permalink / raw)
To: Burakov, Anatoly, Lance Richardson
Cc: dev, Ma, Liang J, Thomas Monjalon, Yigit, Ferruh,
Andrew Rybchenko, Ray Kinsella, Neil Horman, gage.eads, McDaniel,
Timothy, Hunt, David, Richardson, Bruce, Macnamara, Chris
>
> On 12-Jan-21 8:32 PM, Lance Richardson wrote:
> > On Thu, Dec 17, 2020 at 9:08 AM Anatoly Burakov
> > <anatoly.burakov@intel.com> wrote:
> >>
> >> From: Liang Ma <liang.j.ma@intel.com>
> >>
> >> Add a simple API to allow getting the monitor conditions for
> >> power-optimized monitoring of the RX queues from the PMD, as well as
> >> release notes information.
> >>
> >> Signed-off-by: Liang Ma <liang.j.ma@intel.com>
> >> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> >> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> >> ---
> > <snip>
> >> /**
> >> * @internal A structure containing the functions exported by an Ethernet driver.
> >> */
> >> @@ -917,6 +937,8 @@ struct eth_dev_ops {
> >> /**< Set up the connection between the pair of hairpin queues. */
> >> eth_hairpin_queue_peer_unbind_t hairpin_queue_peer_unbind;
> >> /**< Disconnect the hairpin queues of a pair from each other. */
> >> + eth_get_monitor_addr_t get_monitor_addr;
> >> + /**< Get next RX queue ring entry address. */
> >> };
> >>
> >
> > The implementation of get_monitor_addr will have much in common with
> > the rx_descriptor_status API in struct rte_eth_dev, including the property
> > that it will likely not make sense for it to be called concurrently with
> > rx_pkt_burst on a given queue. Might it make more sense to have this
> > API in struct rte_eth_dev instead of struct eth_dev_ops?
> >
>
> I don't have an opinion on this as this code isn't really my area of
> expertise. I'm fine with wherever the community thinks this code should
> be. Any other opinions?
>
I don't think it is a good idea to push new members into rte_eth_dev.
It either means an ABI breakage or wasting of one of our reserved fields.
IMO this function is not that performance critical to justify such insersion.
In fact, I think we should look in different direction -
remove rx/tx_descriptor_status() functions from rte_eth_dev,
or even better make rte_eth_dev an opaque pointer.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 0/6] power: fix make build for power apps
@ 2021-01-13 17:30 3% ` Burakov, Anatoly
0 siblings, 0 replies; 200+ results
From: Burakov, Anatoly @ 2021-01-13 17:30 UTC (permalink / raw)
To: David Hunt, dev; +Cc: stable
On 13-Jan-21 1:25 PM, David Hunt wrote:
>
> On 13/1/2021 11:18 AM, Burakov, Anatoly wrote:
>> On 13-Jan-21 11:14 AM, David Hunt wrote:
>>> Hi Anatoly,
>>>
>>> On 13/1/2021 11:08 AM, Burakov, Anatoly wrote:
>>>> On 08-Jan-21 2:30 PM, David Hunt wrote:
>>>>> The power example applications that uses the virtio-serial method of
>>>>> communication cannot currently be built with make, and can only be
>>>>> built
>>>>> using meson/ninja.
>>>>>
>>>>> The guest channel message definitions and functions in guest_channel.h
>>>>> are needed by applications and need to be made public.
>>>>>
>>>>> This worked pre-20.11, but now with all the meson/ninja changes,
>>>>> making
>>>>> these apps externally no longer works. To fix, we need to move the
>>>>> header
>>>>> file with the API definitions for the channel commands public, and
>>>>> rename
>>>>> the functions accordingly.
>>>>>
>>>>> The main change is to rename channel_commands.h to
>>>>> rte_power_guest_channel.h so that it gets picked up by the
>>>>> installer and
>>>>> copied to /usr/local/include. Other changes include renaming
>>>>> #defines to
>>>>> have RTE_ at the beginning instead of CPU_. Finally we refactor the
>>>>> code
>>>>> to work with those changes.
>>>>>
>>>>> ---
>>>>> v2 changes
>>>>> - re-worked from monolithic patch to a 6 patch patchset for
>>>>> easier review
>>>>>
>>>>> [PATCH v2 1/6] power: create guest channel public header file
>>>>> [PATCH v2 2/6] power: make channel msg functions public
>>>>> [PATCH v2 3/6] power: rename public structs
>>>>> [PATCH v2 4/6] power: rename defines
>>>>> [PATCH v2 5/6] power: add new header file to export list
>>>>> [PATCH v2 6/6] power: clean up includes
>>>>>
>>>>
>>>> Just a general question: wouldn't it be better to move this stuff
>>>> entirely into sample app and not bother with keeping it in the
>>>> library? There is precedent - ethtool app has a "library" and an
>>>> "application" part, i think you should be able to move it out of the
>>>> library and into the sample app entirely without too much trouble,
>>>> as code looks to be fairly self-contained.
>>>>
>>>
>>> Agreed, that's a great idea. I could have a common lib under
>>> examples/vm_power_manager, then two apps, vm_power_manager and
>>> guest_cli. That would keep everything nicely local, and not expose
>>> the channel API publicly. The only reason we were making it public
>>> was to allow "make" to work, so that's not a good enought reason,
>>> tbh. I'll throw a prototype together today.
>>
>> Yep, IIRC Make works perfectly fine with ethtool, so i don't see why
>> it wouldn't work for your sample app as well. Thanks!
>
>
> Hi Anatoly,
>
> OK, so I was investigating this, and have come across a blocker on this
> method.
>
> There are three methods for managing frequency, acpi, pstate and vm.
> It's the third method that's causing the problem with moving the channel
> functionality out into a sample library alongside vm_power_manger. VM's
> can call channel functions in the power library to affect frequency for
> their cores, and these functions use api function calls and several
> structures and #defines in their code, which is currently part of the
> power management library. These function declarations, structs and
> #defines ere needed in both the examples lib/apps and the power library
> itself, and the prototype changes I made ended up looking very much like
> the patch set that's already on the mailing list.
>
> So, while I would have liked to have a solution along the lines of what
> you've proposed, it's not possible based on the dependencies on common
> structues and #defines.
>
> Thanks for the suggestion, though.
>
> Rgds,
> Dave.
>
OK, i guess we can live with that. I wonder if there's another way to do
this, but since i can't think of anything that doesn't involve serious
API/ABI breakages, this is OK IMO.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v2 1/1] devtools: avoid installing static binaries
@ 2021-01-13 19:05 13% ` Thomas Monjalon
2021-01-13 22:01 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2021-01-13 19:05 UTC (permalink / raw)
To: dev; +Cc: david.marchand, bruce.richardson
When testing compilation and checking ABI compatibility,
there is no real need of static binaries eating disks.
The static linkage of applications was already well tested,
though the static examples tested with meson were limited to "l3fwd" only.
The static build test with make is limited to "helloworld" example.
The ABI compatibility is checked on shared libraries,
and there is no need to test again on similar builds.
A new parameter is added to the function "build",
so the ABI check is enabled only for native gcc and clang shared builds,
32-bit, generic armv8 and ppc cross compilations.
In other words, it is disabled for some static builds and some Arm ones.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
v2:
- separate ABI check enablement from default library
- disable ABI check in specific Arm builds
---
devtools/test-meson-builds.sh | 32 ++++++++++++++++++++++----------
1 file changed, 22 insertions(+), 10 deletions(-)
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index 00e3d0b443..0e79e1b2bd 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -146,13 +146,15 @@ install_target () # <builddir> <installdir>
DESTDIR=$2 $ninja_cmd -C $1 install >&$veryverbose
}
-build () # <directory> <target compiler | cross file> <meson options>
+build () # <directory> <target cc | cross file> <ABI check> [meson options]
{
targetdir=$1
shift
crossfile=
[ -r $1 ] && crossfile=$1 || targetcc=$1
shift
+ abicheck=$1
+ shift
# skip build if compiler not available
command -v ${CC##* } >/dev/null 2>&1 || return 0
if [ -n "$crossfile" ] ; then
@@ -165,7 +167,7 @@ build () # <directory> <target compiler | cross file> <meson options>
load_env $targetcc || return 0
config $srcdir $builds_dir/$targetdir $cross --werror $*
compile $builds_dir/$targetdir
- if [ -n "$DPDK_ABI_REF_VERSION" ]; then
+ if [ -n "$DPDK_ABI_REF_VERSION" -a "$abicheck" = ABI ] ; then
abirefdir=${DPDK_ABI_REF_DIR:-reference}/$DPDK_ABI_REF_VERSION
if [ ! -d $abirefdir/$targetdir ]; then
# clone current sources
@@ -207,8 +209,13 @@ build () # <directory> <target compiler | cross file> <meson options>
for c in gcc clang ; do
command -v $c >/dev/null 2>&1 || continue
for s in static shared ; do
+ if [ $s = shared ] ; then
+ abicheck=ABI
+ else
+ abicheck=skipABI # save time and disk space
+ fi
export CC="$CCACHE $c"
- build build-$c-$s $c --default-library=$s
+ build build-$c-$s $c $abicheck --default-library=$s
unset CC
done
done
@@ -220,7 +227,8 @@ default_machine='nehalem'
if ! check_cc_flags "-march=$default_machine" ; then
default_machine='corei7'
fi
-build build-x86-default cc -Dlibdir=lib -Dmachine=$default_machine $use_shared
+build build-x86-default cc ABI \
+ -Dlibdir=lib -Dmachine=$default_machine $use_shared
# 32-bit with default compiler
if check_cc_flags '-m32' ; then
@@ -235,29 +243,32 @@ if check_cc_flags '-m32' ; then
export PKG_CONFIG_LIBDIR='/usr/lib/pkgconfig'
fi
target_override='i386-pc-linux-gnu'
- build build-32b cc -Dc_args='-m32' -Dc_link_args='-m32'
+ build build-32b cc ABI -Dc_args='-m32' -Dc_link_args='-m32'
target_override=
unset PKG_CONFIG_LIBDIR
fi
# x86 MinGW
-build build-x86-mingw $srcdir/config/x86/cross-mingw -Dexamples=helloworld
+build build-x86-mingw $srcdir/config/x86/cross-mingw skipABI \
+ -Dexamples=helloworld
# generic armv8a with clang as host compiler
f=$srcdir/config/arm/arm64_armv8_linux_gcc
export CC="clang"
-build build-arm64-host-clang $f $use_shared
+build build-arm64-host-clang $f ABI $use_shared
unset CC
# some gcc/arm configurations
for f in $srcdir/config/arm/arm64_[bdo]*gcc ; do
export CC="$CCACHE gcc"
- build build-$(basename $f | tr '_' '-' | cut -d'-' -f-2) $f $use_shared
+ targetdir=build-$(basename $f | tr '_' '-' | cut -d'-' -f-2)
+ build $targetdir $f skipABI $use_shared
unset CC
done
# ppc configurations
for f in $srcdir/config/ppc/ppc* ; do
- build build-$(basename $f | cut -d'-' -f-2) $f $use_shared
+ targetdir=build-$(basename $f | cut -d'-' -f-2)
+ build $targetdir $f ABI $use_shared
done
# Test installation of the x86-default target, to be used for checking
@@ -279,7 +290,8 @@ if pkg-config --define-prefix libdpdk >/dev/null 2>&1; then
export PKGCONF="pkg-config --define-prefix"
for example in $examples; do
echo "## Building $example"
+ [ $example = helloworld ] && static=static || static= # save disk space
$MAKE -C $DESTDIR/usr/local/share/dpdk/examples/$example \
- clean shared static >&$veryverbose
+ clean shared $static >&$veryverbose
done
fi
--
2.29.2
^ permalink raw reply [relevance 13%]
* Re: [dpdk-dev] [PATCH v2 1/1] devtools: avoid installing static binaries
2021-01-13 19:05 13% ` [dpdk-dev] [PATCH v2 " Thomas Monjalon
@ 2021-01-13 22:01 0% ` Thomas Monjalon
2021-01-15 15:24 3% ` David Marchand
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2021-01-13 22:01 UTC (permalink / raw)
To: dev; +Cc: david.marchand, bruce.richardson
13/01/2021 20:05, Thomas Monjalon:
> When testing compilation and checking ABI compatibility,
> there is no real need of static binaries eating disks.
>
> The static linkage of applications was already well tested,
> though the static examples tested with meson were limited to "l3fwd" only.
> The static build test with make is limited to "helloworld" example.
>
> The ABI compatibility is checked on shared libraries,
> and there is no need to test again on similar builds.
> A new parameter is added to the function "build",
> so the ABI check is enabled only for native gcc and clang shared builds,
> 32-bit, generic armv8 and ppc cross compilations.
> In other words, it is disabled for some static builds and some Arm ones.
>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> ---
> v2:
> - separate ABI check enablement from default library
> - disable ABI check in specific Arm builds
> ---
[...]
> -build build-x86-default cc -Dlibdir=lib -Dmachine=$default_machine $use_shared
> +build build-x86-default cc ABI \
> + -Dlibdir=lib -Dmachine=$default_machine $use_shared
After a second thought, I think this one should be "skipABI".
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v16 00/11] Add PMD power management
2021-01-12 17:37 2% ` [dpdk-dev] [PATCH v16 01/11] eal: uninline power intrinsics Anatoly Burakov
@ 2021-01-14 9:36 9% ` David Marchand
2021-01-14 10:25 0% ` Burakov, Anatoly
2021-01-14 14:46 2% ` [dpdk-dev] [PATCH v17 " Anatoly Burakov
2 siblings, 1 reply; 200+ results
From: David Marchand @ 2021-01-14 9:36 UTC (permalink / raw)
To: Anatoly Burakov, Ray Kinsella
Cc: dev, Thomas Monjalon, Ananyev, Konstantin, Timothy McDaniel,
David Hunt, Bruce Richardson, chris.macnamara, Kevin Traynor
On Tue, Jan 12, 2021 at 6:37 PM Anatoly Burakov
<anatoly.burakov@intel.com> wrote:
>
> This patchset proposes a simple API for Ethernet drivers to cause the
> CPU to enter a power-optimized state while waiting for packets to
> arrive. There are multiple proposed mechanisms to achieve said power
> savings: simple frequency scaling, idle loop, and monitoring the Rx
> queue for incoming packages. The latter is achieved through cooperation
> with the NIC driver that will allow us to know address of wake up event,
> and wait for writes on that address.
>
> On IA, this is achieved through using UMONITOR/UMWAIT instructions. They
> are used in their raw opcode form because there is no widespread
> compiler support for them yet. Still, the API is made generic enough to
> hopefully support other architectures, if they happen to implement
> similar instructions.
>
> To achieve power savings, there is a very simple mechanism used: we're
> counting empty polls, and if a certain threshold is reached, we employ
> one of the suggested power management schemes automatically, from within
> a Rx callback inside the PMD. Once there's traffic again, the empty poll
> counter is reset.
>
> This patchset also introduces a few changes into existing power
> management-related intrinsics, namely to provide a native way of waking
> up a sleeping core without application being responsible for it, as well
> as general robustness improvements. There's quite a bit of locking going
> on, but these locks are per-thread and very little (if any) contention
> is expected, so the performance impact shouldn't be that bad (and in any
> case the locking happens when we're about to sleep anyway).
>
> Why are we putting it into ethdev as opposed to leaving this up to the
> application? Our customers specifically requested a way to do it with
> minimal changes to the application code. The current approach allows to
> just flip a switch and automatically have power savings.
>
> Things of note:
>
> - Only 1:1 core to queue mapping is supported, meaning that each lcore
> must at most handle RX on a single queue
If we want to save power, it is likely we would poll more rxqs on a thread.
> - Support 3 type policies. Monitor/Pause/Frequency Scaling
> - Power management is enabled per-queue
> - The API doesn't extend to other device types
>
> v16:
> - Implemented Konstantin's suggestions and comments
> - Added return values to the API
- This revision breaks SPDK build (reported by UNH):
http://mails.dpdk.org/archives/test-report/2021-January/174069.html
- Build is broken for ARM and PPC at patch:
86491d5bd4 - (HEAD) eal: add monitor wakeup function (25 minutes ago)
<Anatoly Burakov>
Only pasting the ARM failure:
ninja: Entering directory `/home/dmarchan/builds/build-arm64-host-clang'
[1/297] Compiling C object
'lib/76b5a35@@rte_eal@sta/librte_eal_arm_rte_power_intrinsics.c.o'.
FAILED: lib/76b5a35@@rte_eal@sta/librte_eal_arm_rte_power_intrinsics.c.o
aarch64-linux-gnu-gcc -Ilib/76b5a35@@rte_eal@sta -Ilib
-I../../dpdk/lib -I. -I../../dpdk/ -Iconfig -I../../dpdk/config
-Ilib/librte_eal/include -I../../dpdk/lib/librte_eal/include
-Ilib/librte_eal/linux/include
-I../../dpdk/lib/librte_eal/linux/include -Ilib/librte_eal/arm/include
-I../../dpdk/lib/librte_eal/arm/include -Ilib/librte_eal/common
-I../../dpdk/lib/librte_eal/common -Ilib/librte_eal
-I../../dpdk/lib/librte_eal -Ilib/librte_kvargs
-I../../dpdk/lib/librte_kvargs
-Ilib/librte_telemetry/../librte_metrics
-I../../dpdk/lib/librte_telemetry/../librte_metrics
-Ilib/librte_telemetry -I../../dpdk/lib/librte_telemetry
-fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall
-Winvalid-pch -Werror -O2 -g -include rte_config.h -Wextra -Wcast-qual
-Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security
-Wmissing-declarations -Wmissing-prototypes -Wnested-externs
-Wold-style-definition -Wpointer-arith -Wsign-compare
-Wstrict-prototypes -Wundef -Wwrite-strings -Wno-packed-not-aligned
-Wno-missing-field-initializers -D_GNU_SOURCE -fPIC -march=armv8-a+crc
-DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -Wno-format-truncation
'-DABI_VERSION="21.1"' -DRTE_LIBEAL_USE_GETENTROPY -MD -MQ
'lib/76b5a35@@rte_eal@sta/librte_eal_arm_rte_power_intrinsics.c.o' -MF
'lib/76b5a35@@rte_eal@sta/librte_eal_arm_rte_power_intrinsics.c.o.d'
-o 'lib/76b5a35@@rte_eal@sta/librte_eal_arm_rte_power_intrinsics.c.o'
-c ../../dpdk/lib/librte_eal/arm/rte_power_intrinsics.c
../../dpdk/lib/librte_eal/arm/rte_power_intrinsics.c:35:1: error:
conflicting types for ‘rte_power_monitor_wakeup’
rte_power_monitor_wakeup(const unsigned int lcore_id)
^~~~~~~~~~~~~~~~~~~~~~~~
In file included from
../../dpdk/lib/librte_eal/arm/include/rte_power_intrinsics.h:14,
from ../../dpdk/lib/librte_eal/arm/rte_power_intrinsics.c:5:
../../dpdk/lib/librte_eal/include/generic/rte_power_intrinsics.h:79:5:
note: previous declaration of ‘rte_power_monitor_wakeup’ was here
int rte_power_monitor_wakeup(const unsigned int lcore_id);
^~~~~~~~~~~~~~~~~~~~~~~~
ninja: build stopped: subcommand failed.
- The ABI check is still not happy as I reported earlier.
Reproduced on v16 (GHA had a hiccup on this revision, but previous
ones had the failure too):
1 Changed variable:
[C] 'rte_eth_dev rte_eth_devices[]' was changed at rte_ethdev_core.h:196:1:
type of variable changed:
array element type 'struct rte_eth_dev' changed:
type size hasn't changed
1 data member change:
type of 'const eth_dev_ops* rte_eth_dev::dev_ops' changed:
in pointed to type 'const eth_dev_ops':
in unqualified underlying type 'struct eth_dev_ops' at
rte_ethdev_driver.h:789:1:
type size changed from 6208 to 6272 (in bits)
1 data member insertion:
'eth_get_monitor_addr_t
eth_dev_ops::get_monitor_addr', at offset 6208 (in bits) at
rte_ethdev_driver.h:940:1
no data member changes (94 filtered);
type size hasn't changed
Error: ABI issue reported for 'abidiff --suppr
/home/dmarchan/dpdk/devtools/../devtools/libabigail.abignore
--no-added-syms --headers-dir1
/home/dmarchan/abi/v20.11/build-gcc-static/usr/local/include
--headers-dir2 /home/dmarchan/builds/build-gcc-static/install/usr/local/include
/home/dmarchan/abi/v20.11/build-gcc-static/dump/librte_ethdev.dump
/home/dmarchan/builds/build-gcc-static/install/dump/librte_ethdev.dump'
ABIDIFF_ABI_CHANGE, this change requires a review (abidiff flagged
this as a potential issue).
One solution is to add an exception on the eth_dev_ops structure.
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -7,3 +7,7 @@
symbol_version = INTERNAL
[suppress_variable]
symbol_version = INTERNAL
+
+; Explicit ignore for driver-only ABI
+[suppress_type]
+ name = eth_dev_ops
--
David marchand
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] [PATCH v16 00/11] Add PMD power management
2021-01-14 9:36 9% ` [dpdk-dev] [PATCH v16 00/11] Add PMD power management David Marchand
@ 2021-01-14 10:25 0% ` Burakov, Anatoly
0 siblings, 0 replies; 200+ results
From: Burakov, Anatoly @ 2021-01-14 10:25 UTC (permalink / raw)
To: David Marchand, Ray Kinsella
Cc: dev, Thomas Monjalon, Ananyev, Konstantin, Timothy McDaniel,
David Hunt, Bruce Richardson, chris.macnamara, Kevin Traynor
On 14-Jan-21 9:36 AM, David Marchand wrote:
> On Tue, Jan 12, 2021 at 6:37 PM Anatoly Burakov
> <anatoly.burakov@intel.com> wrote:
>>
>> This patchset proposes a simple API for Ethernet drivers to cause the
>> CPU to enter a power-optimized state while waiting for packets to
>> arrive. There are multiple proposed mechanisms to achieve said power
>> savings: simple frequency scaling, idle loop, and monitoring the Rx
>> queue for incoming packages. The latter is achieved through cooperation
>> with the NIC driver that will allow us to know address of wake up event,
>> and wait for writes on that address.
>>
>> On IA, this is achieved through using UMONITOR/UMWAIT instructions. They
>> are used in their raw opcode form because there is no widespread
>> compiler support for them yet. Still, the API is made generic enough to
>> hopefully support other architectures, if they happen to implement
>> similar instructions.
>>
>> To achieve power savings, there is a very simple mechanism used: we're
>> counting empty polls, and if a certain threshold is reached, we employ
>> one of the suggested power management schemes automatically, from within
>> a Rx callback inside the PMD. Once there's traffic again, the empty poll
>> counter is reset.
>>
>> This patchset also introduces a few changes into existing power
>> management-related intrinsics, namely to provide a native way of waking
>> up a sleeping core without application being responsible for it, as well
>> as general robustness improvements. There's quite a bit of locking going
>> on, but these locks are per-thread and very little (if any) contention
>> is expected, so the performance impact shouldn't be that bad (and in any
>> case the locking happens when we're about to sleep anyway).
>>
>> Why are we putting it into ethdev as opposed to leaving this up to the
>> application? Our customers specifically requested a way to do it with
>> minimal changes to the application code. The current approach allows to
>> just flip a switch and automatically have power savings.
>>
>> Things of note:
>>
>> - Only 1:1 core to queue mapping is supported, meaning that each lcore
>> must at most handle RX on a single queue
>
> If we want to save power, it is likely we would poll more rxqs on a thread.
We are investigating possibilities to make that happen, but for this
patchset, this is the limitation.
>
>
>> - Support 3 type policies. Monitor/Pause/Frequency Scaling
>> - Power management is enabled per-queue
>> - The API doesn't extend to other device types
>>
>> v16:
>> - Implemented Konstantin's suggestions and comments
>> - Added return values to the API
>
> - This revision breaks SPDK build (reported by UNH):
> http://mails.dpdk.org/archives/test-report/2021-January/174069.html
>
>
> - Build is broken for ARM and PPC at patch:
> 86491d5bd4 - (HEAD) eal: add monitor wakeup function (25 minutes ago)
> <Anatoly Burakov>
>
> Only pasting the ARM failure:
> ninja: Entering directory `/home/dmarchan/builds/build-arm64-host-clang'
> [1/297] Compiling C object
> 'lib/76b5a35@@rte_eal@sta/librte_eal_arm_rte_power_intrinsics.c.o'.
> FAILED: lib/76b5a35@@rte_eal@sta/librte_eal_arm_rte_power_intrinsics.c.o
> aarch64-linux-gnu-gcc -Ilib/76b5a35@@rte_eal@sta -Ilib
> -I../../dpdk/lib -I. -I../../dpdk/ -Iconfig -I../../dpdk/config
> -Ilib/librte_eal/include -I../../dpdk/lib/librte_eal/include
> -Ilib/librte_eal/linux/include
> -I../../dpdk/lib/librte_eal/linux/include -Ilib/librte_eal/arm/include
> -I../../dpdk/lib/librte_eal/arm/include -Ilib/librte_eal/common
> -I../../dpdk/lib/librte_eal/common -Ilib/librte_eal
> -I../../dpdk/lib/librte_eal -Ilib/librte_kvargs
> -I../../dpdk/lib/librte_kvargs
> -Ilib/librte_telemetry/../librte_metrics
> -I../../dpdk/lib/librte_telemetry/../librte_metrics
> -Ilib/librte_telemetry -I../../dpdk/lib/librte_telemetry
> -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall
> -Winvalid-pch -Werror -O2 -g -include rte_config.h -Wextra -Wcast-qual
> -Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security
> -Wmissing-declarations -Wmissing-prototypes -Wnested-externs
> -Wold-style-definition -Wpointer-arith -Wsign-compare
> -Wstrict-prototypes -Wundef -Wwrite-strings -Wno-packed-not-aligned
> -Wno-missing-field-initializers -D_GNU_SOURCE -fPIC -march=armv8-a+crc
> -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -Wno-format-truncation
> '-DABI_VERSION="21.1"' -DRTE_LIBEAL_USE_GETENTROPY -MD -MQ
> 'lib/76b5a35@@rte_eal@sta/librte_eal_arm_rte_power_intrinsics.c.o' -MF
> 'lib/76b5a35@@rte_eal@sta/librte_eal_arm_rte_power_intrinsics.c.o.d'
> -o 'lib/76b5a35@@rte_eal@sta/librte_eal_arm_rte_power_intrinsics.c.o'
> -c ../../dpdk/lib/librte_eal/arm/rte_power_intrinsics.c
> ../../dpdk/lib/librte_eal/arm/rte_power_intrinsics.c:35:1: error:
> conflicting types for ‘rte_power_monitor_wakeup’
> rte_power_monitor_wakeup(const unsigned int lcore_id)
> ^~~~~~~~~~~~~~~~~~~~~~~~
> In file included from
> ../../dpdk/lib/librte_eal/arm/include/rte_power_intrinsics.h:14,
> from ../../dpdk/lib/librte_eal/arm/rte_power_intrinsics.c:5:
> ../../dpdk/lib/librte_eal/include/generic/rte_power_intrinsics.h:79:5:
> note: previous declaration of ‘rte_power_monitor_wakeup’ was here
> int rte_power_monitor_wakeup(const unsigned int lcore_id);
> ^~~~~~~~~~~~~~~~~~~~~~~~
> ninja: build stopped: subcommand failed.
Woops, wrong return value in the .c files. Will fix!
>
>
>
> - The ABI check is still not happy as I reported earlier.
> Reproduced on v16 (GHA had a hiccup on this revision, but previous
> ones had the failure too):
>
> 1 Changed variable:
>
> [C] 'rte_eth_dev rte_eth_devices[]' was changed at rte_ethdev_core.h:196:1:
> type of variable changed:
> array element type 'struct rte_eth_dev' changed:
> type size hasn't changed
> 1 data member change:
> type of 'const eth_dev_ops* rte_eth_dev::dev_ops' changed:
> in pointed to type 'const eth_dev_ops':
> in unqualified underlying type 'struct eth_dev_ops' at
> rte_ethdev_driver.h:789:1:
> type size changed from 6208 to 6272 (in bits)
> 1 data member insertion:
> 'eth_get_monitor_addr_t
> eth_dev_ops::get_monitor_addr', at offset 6208 (in bits) at
> rte_ethdev_driver.h:940:1
> no data member changes (94 filtered);
> type size hasn't changed
>
> Error: ABI issue reported for 'abidiff --suppr
> /home/dmarchan/dpdk/devtools/../devtools/libabigail.abignore
> --no-added-syms --headers-dir1
> /home/dmarchan/abi/v20.11/build-gcc-static/usr/local/include
> --headers-dir2 /home/dmarchan/builds/build-gcc-static/install/usr/local/include
> /home/dmarchan/abi/v20.11/build-gcc-static/dump/librte_ethdev.dump
> /home/dmarchan/builds/build-gcc-static/install/dump/librte_ethdev.dump'
>
> ABIDIFF_ABI_CHANGE, this change requires a review (abidiff flagged
> this as a potential issue).
>
> One solution is to add an exception on the eth_dev_ops structure.
>
> --- a/devtools/libabigail.abignore
> +++ b/devtools/libabigail.abignore
> @@ -7,3 +7,7 @@
> symbol_version = INTERNAL
> [suppress_variable]
> symbol_version = INTERNAL
> +
> +; Explicit ignore for driver-only ABI
> +[suppress_type]
> + name = eth_dev_ops
>
>
Right, OK. I didn't realize an "exception" is something you actually do
in code, not an ad-hoc community process type thing :) I'll add this in
the next revision.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v17 00/11] Add PMD power management
2021-01-12 17:37 2% ` [dpdk-dev] [PATCH v16 01/11] eal: uninline power intrinsics Anatoly Burakov
2021-01-14 9:36 9% ` [dpdk-dev] [PATCH v16 00/11] Add PMD power management David Marchand
@ 2021-01-14 14:46 2% ` Anatoly Burakov
2021-01-14 14:46 2% ` [dpdk-dev] [PATCH v17 01/11] eal: uninline power intrinsics Anatoly Burakov
` (2 more replies)
2 siblings, 3 replies; 200+ results
From: Anatoly Burakov @ 2021-01-14 14:46 UTC (permalink / raw)
To: dev
Cc: thomas, konstantin.ananyev, timothy.mcdaniel, david.hunt,
bruce.richardson, chris.macnamara
This patchset proposes a simple API for Ethernet drivers to cause the
CPU to enter a power-optimized state while waiting for packets to
arrive. There are multiple proposed mechanisms to achieve said power
savings: simple frequency scaling, idle loop, and monitoring the Rx
queue for incoming packages. The latter is achieved through cooperation
with the NIC driver that will allow us to know address of wake up event,
and wait for writes on that address.
On IA, this is achieved through using UMONITOR/UMWAIT instructions. They
are used in their raw opcode form because there is no widespread
compiler support for them yet. Still, the API is made generic enough to
hopefully support other architectures, if they happen to implement
similar instructions.
To achieve power savings, there is a very simple mechanism used: we're
counting empty polls, and if a certain threshold is reached, we employ
one of the suggested power management schemes automatically, from within
a Rx callback inside the PMD. Once there's traffic again, the empty poll
counter is reset.
This patchset also introduces a few changes into existing power
management-related intrinsics, namely to provide a native way of waking
up a sleeping core without application being responsible for it, as well
as general robustness improvements. There's quite a bit of locking going
on, but these locks are per-thread and very little (if any) contention
is expected, so the performance impact shouldn't be that bad (and in any
case the locking happens when we're about to sleep anyway).
Why are we putting it into ethdev as opposed to leaving this up to the
application? Our customers specifically requested a way to do it with
minimal changes to the application code. The current approach allows to
just flip a switch and automatically have power savings.
Things of note:
- Only 1:1 core to queue mapping is supported, meaning that each lcore
must at most handle RX on a single queue
- Support 3 type policies. Monitor/Pause/Frequency Scaling
- Power management is enabled per-queue
- The API doesn't extend to other device types
v17:
- Added exception for ethdev driver-only ABI
- Added memory barriers for monitor/wakeup (Konstantin)
- Fixed compiled issues on non-x86 platforms (hopefully!)
v16:
- Implemented Konstantin's suggestions and comments
- Added return values to the API
v15:
- Fixed incorrect check in UMWAIT callback
- Fixed accidental whitespace changes
v14:
- Fixed ARM/PPC builds
- Addressed various review comments
v13:
- Reworked the librte_power code to require less locking and handle invalid
parameters better
- Fix numerous rebase errors present in v12
v12:
- Rebase on top of 21.02
- Rework of power intrinsics code
Anatoly Burakov (5):
eal: uninline power intrinsics
eal: avoid invalid API usage in power intrinsics
eal: change API of power intrinsics
eal: remove sync version of power monitor
eal: add monitor wakeup function
Liang Ma (6):
ethdev: add simple power management API
power: add PMD power management API and callback
net/ixgbe: implement power management API
net/i40e: implement power management API
net/ice: implement power management API
examples/l3fwd-power: enable PMD power mgmt
devtools/libabigail.abignore | 3 +
doc/guides/prog_guide/power_man.rst | 44 +++
doc/guides/rel_notes/release_21_02.rst | 15 +
.../sample_app_ug/l3_forward_power_man.rst | 35 ++
drivers/event/dlb/dlb.c | 10 +-
drivers/event/dlb2/dlb2.c | 10 +-
drivers/net/i40e/i40e_ethdev.c | 1 +
drivers/net/i40e/i40e_rxtx.c | 25 ++
drivers/net/i40e/i40e_rxtx.h | 1 +
drivers/net/ice/ice_ethdev.c | 1 +
drivers/net/ice/ice_rxtx.c | 26 ++
drivers/net/ice/ice_rxtx.h | 1 +
drivers/net/ixgbe/ixgbe_ethdev.c | 1 +
drivers/net/ixgbe/ixgbe_rxtx.c | 25 ++
drivers/net/ixgbe/ixgbe_rxtx.h | 1 +
examples/l3fwd-power/main.c | 89 ++++-
.../arm/include/rte_power_intrinsics.h | 40 --
lib/librte_eal/arm/meson.build | 1 +
lib/librte_eal/arm/rte_power_intrinsics.c | 40 ++
.../include/generic/rte_power_intrinsics.h | 88 ++---
.../ppc/include/rte_power_intrinsics.h | 40 --
lib/librte_eal/ppc/meson.build | 1 +
lib/librte_eal/ppc/rte_power_intrinsics.c | 40 ++
lib/librte_eal/version.map | 3 +
.../x86/include/rte_power_intrinsics.h | 115 ------
lib/librte_eal/x86/meson.build | 1 +
lib/librte_eal/x86/rte_power_intrinsics.c | 215 +++++++++++
lib/librte_ethdev/rte_ethdev.c | 28 ++
lib/librte_ethdev/rte_ethdev.h | 25 ++
lib/librte_ethdev/rte_ethdev_driver.h | 22 ++
lib/librte_ethdev/version.map | 3 +
lib/librte_power/meson.build | 5 +-
lib/librte_power/rte_power_pmd_mgmt.c | 364 ++++++++++++++++++
lib/librte_power/rte_power_pmd_mgmt.h | 90 +++++
lib/librte_power/version.map | 5 +
35 files changed, 1155 insertions(+), 259 deletions(-)
create mode 100644 lib/librte_eal/arm/rte_power_intrinsics.c
create mode 100644 lib/librte_eal/ppc/rte_power_intrinsics.c
create mode 100644 lib/librte_eal/x86/rte_power_intrinsics.c
create mode 100644 lib/librte_power/rte_power_pmd_mgmt.c
create mode 100644 lib/librte_power/rte_power_pmd_mgmt.h
--
2.25.1
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v17 01/11] eal: uninline power intrinsics
2021-01-14 14:46 2% ` [dpdk-dev] [PATCH v17 " Anatoly Burakov
@ 2021-01-14 14:46 2% ` Anatoly Burakov
2021-01-14 14:46 7% ` [dpdk-dev] [PATCH v17 06/11] ethdev: add simple power management API Anatoly Burakov
2021-01-18 15:24 0% ` [dpdk-dev] [PATCH v17 00/11] Add PMD power management David Marchand
2 siblings, 0 replies; 200+ results
From: Anatoly Burakov @ 2021-01-14 14:46 UTC (permalink / raw)
To: dev
Cc: Jerin Jacob, Ruifeng Wang, Jan Viktorin, David Christensen,
Ray Kinsella, Neil Horman, Bruce Richardson, Konstantin Ananyev,
thomas, timothy.mcdaniel, david.hunt, chris.macnamara
Currently, power intrinsics are inline functions. Make them part of the
ABI so that we can have various internal data associated with them
without exposing said data to the outside world.
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
---
Notes:
v14:
- Fix compile issues on ARM and PPC64 by moving implementations to .c files
.../arm/include/rte_power_intrinsics.h | 40 ------
lib/librte_eal/arm/meson.build | 1 +
lib/librte_eal/arm/rte_power_intrinsics.c | 45 +++++++
.../include/generic/rte_power_intrinsics.h | 6 +-
.../ppc/include/rte_power_intrinsics.h | 40 ------
lib/librte_eal/ppc/meson.build | 1 +
lib/librte_eal/ppc/rte_power_intrinsics.c | 45 +++++++
lib/librte_eal/version.map | 3 +
.../x86/include/rte_power_intrinsics.h | 115 -----------------
lib/librte_eal/x86/meson.build | 1 +
lib/librte_eal/x86/rte_power_intrinsics.c | 120 ++++++++++++++++++
11 files changed, 219 insertions(+), 198 deletions(-)
create mode 100644 lib/librte_eal/arm/rte_power_intrinsics.c
create mode 100644 lib/librte_eal/ppc/rte_power_intrinsics.c
create mode 100644 lib/librte_eal/x86/rte_power_intrinsics.c
diff --git a/lib/librte_eal/arm/include/rte_power_intrinsics.h b/lib/librte_eal/arm/include/rte_power_intrinsics.h
index a4a1bc1159..9e498e9ebf 100644
--- a/lib/librte_eal/arm/include/rte_power_intrinsics.h
+++ b/lib/librte_eal/arm/include/rte_power_intrinsics.h
@@ -13,46 +13,6 @@ extern "C" {
#include "generic/rte_power_intrinsics.h"
-/**
- * This function is not supported on ARM.
- */
-static inline void
-rte_power_monitor(const volatile void *p, const uint64_t expected_value,
- const uint64_t value_mask, const uint64_t tsc_timestamp,
- const uint8_t data_sz)
-{
- RTE_SET_USED(p);
- RTE_SET_USED(expected_value);
- RTE_SET_USED(value_mask);
- RTE_SET_USED(tsc_timestamp);
- RTE_SET_USED(data_sz);
-}
-
-/**
- * This function is not supported on ARM.
- */
-static inline void
-rte_power_monitor_sync(const volatile void *p, const uint64_t expected_value,
- const uint64_t value_mask, const uint64_t tsc_timestamp,
- const uint8_t data_sz, rte_spinlock_t *lck)
-{
- RTE_SET_USED(p);
- RTE_SET_USED(expected_value);
- RTE_SET_USED(value_mask);
- RTE_SET_USED(tsc_timestamp);
- RTE_SET_USED(lck);
- RTE_SET_USED(data_sz);
-}
-
-/**
- * This function is not supported on ARM.
- */
-static inline void
-rte_power_pause(const uint64_t tsc_timestamp)
-{
- RTE_SET_USED(tsc_timestamp);
-}
-
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_eal/arm/meson.build b/lib/librte_eal/arm/meson.build
index d62875ebae..6ec53ea03a 100644
--- a/lib/librte_eal/arm/meson.build
+++ b/lib/librte_eal/arm/meson.build
@@ -7,4 +7,5 @@ sources += files(
'rte_cpuflags.c',
'rte_cycles.c',
'rte_hypervisor.c',
+ 'rte_power_intrinsics.c',
)
diff --git a/lib/librte_eal/arm/rte_power_intrinsics.c b/lib/librte_eal/arm/rte_power_intrinsics.c
new file mode 100644
index 0000000000..ab1f44f611
--- /dev/null
+++ b/lib/librte_eal/arm/rte_power_intrinsics.c
@@ -0,0 +1,45 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2021 Intel Corporation
+ */
+
+#include "rte_power_intrinsics.h"
+
+/**
+ * This function is not supported on ARM.
+ */
+void
+rte_power_monitor(const volatile void *p, const uint64_t expected_value,
+ const uint64_t value_mask, const uint64_t tsc_timestamp,
+ const uint8_t data_sz)
+{
+ RTE_SET_USED(p);
+ RTE_SET_USED(expected_value);
+ RTE_SET_USED(value_mask);
+ RTE_SET_USED(tsc_timestamp);
+ RTE_SET_USED(data_sz);
+}
+
+/**
+ * This function is not supported on ARM.
+ */
+void
+rte_power_monitor_sync(const volatile void *p, const uint64_t expected_value,
+ const uint64_t value_mask, const uint64_t tsc_timestamp,
+ const uint8_t data_sz, rte_spinlock_t *lck)
+{
+ RTE_SET_USED(p);
+ RTE_SET_USED(expected_value);
+ RTE_SET_USED(value_mask);
+ RTE_SET_USED(tsc_timestamp);
+ RTE_SET_USED(lck);
+ RTE_SET_USED(data_sz);
+}
+
+/**
+ * This function is not supported on ARM.
+ */
+void
+rte_power_pause(const uint64_t tsc_timestamp)
+{
+ RTE_SET_USED(tsc_timestamp);
+}
diff --git a/lib/librte_eal/include/generic/rte_power_intrinsics.h b/lib/librte_eal/include/generic/rte_power_intrinsics.h
index dd520d90fa..67977bd511 100644
--- a/lib/librte_eal/include/generic/rte_power_intrinsics.h
+++ b/lib/librte_eal/include/generic/rte_power_intrinsics.h
@@ -52,7 +52,7 @@
* to undefined result.
*/
__rte_experimental
-static inline void rte_power_monitor(const volatile void *p,
+void rte_power_monitor(const volatile void *p,
const uint64_t expected_value, const uint64_t value_mask,
const uint64_t tsc_timestamp, const uint8_t data_sz);
@@ -97,7 +97,7 @@ static inline void rte_power_monitor(const volatile void *p,
* wakes up.
*/
__rte_experimental
-static inline void rte_power_monitor_sync(const volatile void *p,
+void rte_power_monitor_sync(const volatile void *p,
const uint64_t expected_value, const uint64_t value_mask,
const uint64_t tsc_timestamp, const uint8_t data_sz,
rte_spinlock_t *lck);
@@ -118,6 +118,6 @@ static inline void rte_power_monitor_sync(const volatile void *p,
* architecture-dependent.
*/
__rte_experimental
-static inline void rte_power_pause(const uint64_t tsc_timestamp);
+void rte_power_pause(const uint64_t tsc_timestamp);
#endif /* _RTE_POWER_INTRINSIC_H_ */
diff --git a/lib/librte_eal/ppc/include/rte_power_intrinsics.h b/lib/librte_eal/ppc/include/rte_power_intrinsics.h
index 4ed03d521f..c0e9ac279f 100644
--- a/lib/librte_eal/ppc/include/rte_power_intrinsics.h
+++ b/lib/librte_eal/ppc/include/rte_power_intrinsics.h
@@ -13,46 +13,6 @@ extern "C" {
#include "generic/rte_power_intrinsics.h"
-/**
- * This function is not supported on PPC64.
- */
-static inline void
-rte_power_monitor(const volatile void *p, const uint64_t expected_value,
- const uint64_t value_mask, const uint64_t tsc_timestamp,
- const uint8_t data_sz)
-{
- RTE_SET_USED(p);
- RTE_SET_USED(expected_value);
- RTE_SET_USED(value_mask);
- RTE_SET_USED(tsc_timestamp);
- RTE_SET_USED(data_sz);
-}
-
-/**
- * This function is not supported on PPC64.
- */
-static inline void
-rte_power_monitor_sync(const volatile void *p, const uint64_t expected_value,
- const uint64_t value_mask, const uint64_t tsc_timestamp,
- const uint8_t data_sz, rte_spinlock_t *lck)
-{
- RTE_SET_USED(p);
- RTE_SET_USED(expected_value);
- RTE_SET_USED(value_mask);
- RTE_SET_USED(tsc_timestamp);
- RTE_SET_USED(lck);
- RTE_SET_USED(data_sz);
-}
-
-/**
- * This function is not supported on PPC64.
- */
-static inline void
-rte_power_pause(const uint64_t tsc_timestamp)
-{
- RTE_SET_USED(tsc_timestamp);
-}
-
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_eal/ppc/meson.build b/lib/librte_eal/ppc/meson.build
index f4b6d95c42..43c46542fb 100644
--- a/lib/librte_eal/ppc/meson.build
+++ b/lib/librte_eal/ppc/meson.build
@@ -7,4 +7,5 @@ sources += files(
'rte_cpuflags.c',
'rte_cycles.c',
'rte_hypervisor.c',
+ 'rte_power_intrinsics.c',
)
diff --git a/lib/librte_eal/ppc/rte_power_intrinsics.c b/lib/librte_eal/ppc/rte_power_intrinsics.c
new file mode 100644
index 0000000000..84340ca2a4
--- /dev/null
+++ b/lib/librte_eal/ppc/rte_power_intrinsics.c
@@ -0,0 +1,45 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2021 Intel Corporation
+ */
+
+#include "rte_power_intrinsics.h"
+
+/**
+ * This function is not supported on PPC64.
+ */
+void
+rte_power_monitor(const volatile void *p, const uint64_t expected_value,
+ const uint64_t value_mask, const uint64_t tsc_timestamp,
+ const uint8_t data_sz)
+{
+ RTE_SET_USED(p);
+ RTE_SET_USED(expected_value);
+ RTE_SET_USED(value_mask);
+ RTE_SET_USED(tsc_timestamp);
+ RTE_SET_USED(data_sz);
+}
+
+/**
+ * This function is not supported on PPC64.
+ */
+void
+rte_power_monitor_sync(const volatile void *p, const uint64_t expected_value,
+ const uint64_t value_mask, const uint64_t tsc_timestamp,
+ const uint8_t data_sz, rte_spinlock_t *lck)
+{
+ RTE_SET_USED(p);
+ RTE_SET_USED(expected_value);
+ RTE_SET_USED(value_mask);
+ RTE_SET_USED(tsc_timestamp);
+ RTE_SET_USED(lck);
+ RTE_SET_USED(data_sz);
+}
+
+/**
+ * This function is not supported on PPC64.
+ */
+void
+rte_power_pause(const uint64_t tsc_timestamp)
+{
+ RTE_SET_USED(tsc_timestamp);
+}
diff --git a/lib/librte_eal/version.map b/lib/librte_eal/version.map
index b1db7ec795..32eceb8869 100644
--- a/lib/librte_eal/version.map
+++ b/lib/librte_eal/version.map
@@ -405,6 +405,9 @@ EXPERIMENTAL {
rte_vect_set_max_simd_bitwidth;
# added in 21.02
+ rte_power_monitor;
+ rte_power_monitor_sync;
+ rte_power_pause;
rte_thread_tls_key_create;
rte_thread_tls_key_delete;
rte_thread_tls_value_get;
diff --git a/lib/librte_eal/x86/include/rte_power_intrinsics.h b/lib/librte_eal/x86/include/rte_power_intrinsics.h
index c7d790c854..e4c2b87f73 100644
--- a/lib/librte_eal/x86/include/rte_power_intrinsics.h
+++ b/lib/librte_eal/x86/include/rte_power_intrinsics.h
@@ -13,121 +13,6 @@ extern "C" {
#include "generic/rte_power_intrinsics.h"
-static inline uint64_t
-__rte_power_get_umwait_val(const volatile void *p, const uint8_t sz)
-{
- switch (sz) {
- case sizeof(uint8_t):
- return *(const volatile uint8_t *)p;
- case sizeof(uint16_t):
- return *(const volatile uint16_t *)p;
- case sizeof(uint32_t):
- return *(const volatile uint32_t *)p;
- case sizeof(uint64_t):
- return *(const volatile uint64_t *)p;
- default:
- /* this is an intrinsic, so we can't have any error handling */
- RTE_ASSERT(0);
- return 0;
- }
-}
-
-/**
- * This function uses UMONITOR/UMWAIT instructions and will enter C0.2 state.
- * For more information about usage of these instructions, please refer to
- * Intel(R) 64 and IA-32 Architectures Software Developer's Manual.
- */
-static inline void
-rte_power_monitor(const volatile void *p, const uint64_t expected_value,
- const uint64_t value_mask, const uint64_t tsc_timestamp,
- const uint8_t data_sz)
-{
- const uint32_t tsc_l = (uint32_t)tsc_timestamp;
- const uint32_t tsc_h = (uint32_t)(tsc_timestamp >> 32);
- /*
- * we're using raw byte codes for now as only the newest compiler
- * versions support this instruction natively.
- */
-
- /* set address for UMONITOR */
- asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
- :
- : "D"(p));
-
- if (value_mask) {
- const uint64_t cur_value = __rte_power_get_umwait_val(p, data_sz);
- const uint64_t masked = cur_value & value_mask;
-
- /* if the masked value is already matching, abort */
- if (masked == expected_value)
- return;
- }
- /* execute UMWAIT */
- asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
- : /* ignore rflags */
- : "D"(0), /* enter C0.2 */
- "a"(tsc_l), "d"(tsc_h));
-}
-
-/**
- * This function uses UMONITOR/UMWAIT instructions and will enter C0.2 state.
- * For more information about usage of these instructions, please refer to
- * Intel(R) 64 and IA-32 Architectures Software Developer's Manual.
- */
-static inline void
-rte_power_monitor_sync(const volatile void *p, const uint64_t expected_value,
- const uint64_t value_mask, const uint64_t tsc_timestamp,
- const uint8_t data_sz, rte_spinlock_t *lck)
-{
- const uint32_t tsc_l = (uint32_t)tsc_timestamp;
- const uint32_t tsc_h = (uint32_t)(tsc_timestamp >> 32);
- /*
- * we're using raw byte codes for now as only the newest compiler
- * versions support this instruction natively.
- */
-
- /* set address for UMONITOR */
- asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
- :
- : "D"(p));
-
- if (value_mask) {
- const uint64_t cur_value = __rte_power_get_umwait_val(p, data_sz);
- const uint64_t masked = cur_value & value_mask;
-
- /* if the masked value is already matching, abort */
- if (masked == expected_value)
- return;
- }
- rte_spinlock_unlock(lck);
-
- /* execute UMWAIT */
- asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
- : /* ignore rflags */
- : "D"(0), /* enter C0.2 */
- "a"(tsc_l), "d"(tsc_h));
-
- rte_spinlock_lock(lck);
-}
-
-/**
- * This function uses TPAUSE instruction and will enter C0.2 state. For more
- * information about usage of this instruction, please refer to Intel(R) 64 and
- * IA-32 Architectures Software Developer's Manual.
- */
-static inline void
-rte_power_pause(const uint64_t tsc_timestamp)
-{
- const uint32_t tsc_l = (uint32_t)tsc_timestamp;
- const uint32_t tsc_h = (uint32_t)(tsc_timestamp >> 32);
-
- /* execute TPAUSE */
- asm volatile(".byte 0x66, 0x0f, 0xae, 0xf7;"
- : /* ignore rflags */
- : "D"(0), /* enter C0.2 */
- "a"(tsc_l), "d"(tsc_h));
-}
-
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_eal/x86/meson.build b/lib/librte_eal/x86/meson.build
index e78f29002e..dfd42dee0c 100644
--- a/lib/librte_eal/x86/meson.build
+++ b/lib/librte_eal/x86/meson.build
@@ -8,4 +8,5 @@ sources += files(
'rte_cycles.c',
'rte_hypervisor.c',
'rte_spinlock.c',
+ 'rte_power_intrinsics.c',
)
diff --git a/lib/librte_eal/x86/rte_power_intrinsics.c b/lib/librte_eal/x86/rte_power_intrinsics.c
new file mode 100644
index 0000000000..34c5fd9c3e
--- /dev/null
+++ b/lib/librte_eal/x86/rte_power_intrinsics.c
@@ -0,0 +1,120 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2020 Intel Corporation
+ */
+
+#include "rte_power_intrinsics.h"
+
+static inline uint64_t
+__get_umwait_val(const volatile void *p, const uint8_t sz)
+{
+ switch (sz) {
+ case sizeof(uint8_t):
+ return *(const volatile uint8_t *)p;
+ case sizeof(uint16_t):
+ return *(const volatile uint16_t *)p;
+ case sizeof(uint32_t):
+ return *(const volatile uint32_t *)p;
+ case sizeof(uint64_t):
+ return *(const volatile uint64_t *)p;
+ default:
+ /* this is an intrinsic, so we can't have any error handling */
+ RTE_ASSERT(0);
+ return 0;
+ }
+}
+
+/**
+ * This function uses UMONITOR/UMWAIT instructions and will enter C0.2 state.
+ * For more information about usage of these instructions, please refer to
+ * Intel(R) 64 and IA-32 Architectures Software Developer's Manual.
+ */
+void
+rte_power_monitor(const volatile void *p, const uint64_t expected_value,
+ const uint64_t value_mask, const uint64_t tsc_timestamp,
+ const uint8_t data_sz)
+{
+ const uint32_t tsc_l = (uint32_t)tsc_timestamp;
+ const uint32_t tsc_h = (uint32_t)(tsc_timestamp >> 32);
+ /*
+ * we're using raw byte codes for now as only the newest compiler
+ * versions support this instruction natively.
+ */
+
+ /* set address for UMONITOR */
+ asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
+ :
+ : "D"(p));
+
+ if (value_mask) {
+ const uint64_t cur_value = __get_umwait_val(p, data_sz);
+ const uint64_t masked = cur_value & value_mask;
+
+ /* if the masked value is already matching, abort */
+ if (masked == expected_value)
+ return;
+ }
+ /* execute UMWAIT */
+ asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
+ : /* ignore rflags */
+ : "D"(0), /* enter C0.2 */
+ "a"(tsc_l), "d"(tsc_h));
+}
+
+/**
+ * This function uses UMONITOR/UMWAIT instructions and will enter C0.2 state.
+ * For more information about usage of these instructions, please refer to
+ * Intel(R) 64 and IA-32 Architectures Software Developer's Manual.
+ */
+void
+rte_power_monitor_sync(const volatile void *p, const uint64_t expected_value,
+ const uint64_t value_mask, const uint64_t tsc_timestamp,
+ const uint8_t data_sz, rte_spinlock_t *lck)
+{
+ const uint32_t tsc_l = (uint32_t)tsc_timestamp;
+ const uint32_t tsc_h = (uint32_t)(tsc_timestamp >> 32);
+ /*
+ * we're using raw byte codes for now as only the newest compiler
+ * versions support this instruction natively.
+ */
+
+ /* set address for UMONITOR */
+ asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
+ :
+ : "D"(p));
+
+ if (value_mask) {
+ const uint64_t cur_value = __get_umwait_val(p, data_sz);
+ const uint64_t masked = cur_value & value_mask;
+
+ /* if the masked value is already matching, abort */
+ if (masked == expected_value)
+ return;
+ }
+ rte_spinlock_unlock(lck);
+
+ /* execute UMWAIT */
+ asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
+ : /* ignore rflags */
+ : "D"(0), /* enter C0.2 */
+ "a"(tsc_l), "d"(tsc_h));
+
+ rte_spinlock_lock(lck);
+}
+
+/**
+ * This function uses TPAUSE instruction and will enter C0.2 state. For more
+ * information about usage of this instruction, please refer to Intel(R) 64 and
+ * IA-32 Architectures Software Developer's Manual.
+ */
+void
+rte_power_pause(const uint64_t tsc_timestamp)
+{
+ const uint32_t tsc_l = (uint32_t)tsc_timestamp;
+ const uint32_t tsc_h = (uint32_t)(tsc_timestamp >> 32);
+
+ /* execute TPAUSE */
+ asm volatile(".byte 0x66, 0x0f, 0xae, 0xf7;"
+ : /* ignore rflags */
+ : "D"(0), /* enter C0.2 */
+ "a"(tsc_l), "d"(tsc_h));
+}
--
2.25.1
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v17 06/11] ethdev: add simple power management API
2021-01-14 14:46 2% ` [dpdk-dev] [PATCH v17 " Anatoly Burakov
2021-01-14 14:46 2% ` [dpdk-dev] [PATCH v17 01/11] eal: uninline power intrinsics Anatoly Burakov
@ 2021-01-14 14:46 7% ` Anatoly Burakov
2021-01-18 15:24 0% ` [dpdk-dev] [PATCH v17 00/11] Add PMD power management David Marchand
2 siblings, 0 replies; 200+ results
From: Anatoly Burakov @ 2021-01-14 14:46 UTC (permalink / raw)
To: dev
Cc: Liang Ma, Ray Kinsella, Neil Horman, Thomas Monjalon,
Ferruh Yigit, Andrew Rybchenko, konstantin.ananyev,
timothy.mcdaniel, david.hunt, bruce.richardson, chris.macnamara
From: Liang Ma <liang.j.ma@intel.com>
Add a simple API to allow getting the monitor conditions for
power-optimized monitoring of the Rx queues from the PMD, as well as
release notes information.
Signed-off-by: Liang Ma <liang.j.ma@intel.com>
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
Notes:
v17:
- Added libabigail ignore for driver-only ABI in ethdev as suggested by David
v13:
- Fix typos and issues raised by Andrew
devtools/libabigail.abignore | 3 +++
doc/guides/rel_notes/release_21_02.rst | 5 +++++
lib/librte_ethdev/rte_ethdev.c | 28 ++++++++++++++++++++++++++
lib/librte_ethdev/rte_ethdev.h | 25 +++++++++++++++++++++++
lib/librte_ethdev/rte_ethdev_driver.h | 22 ++++++++++++++++++++
lib/librte_ethdev/version.map | 3 +++
6 files changed, 86 insertions(+)
diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 025f2c01bc..1c16114dce 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -7,3 +7,6 @@
symbol_version = INTERNAL
[suppress_variable]
symbol_version = INTERNAL
+; Explicit ignore for driver-only ABI
+[suppress_type]
+ name = eth_dev_ops
diff --git a/doc/guides/rel_notes/release_21_02.rst b/doc/guides/rel_notes/release_21_02.rst
index 706cbf8f0c..ec9958a141 100644
--- a/doc/guides/rel_notes/release_21_02.rst
+++ b/doc/guides/rel_notes/release_21_02.rst
@@ -55,6 +55,11 @@ New Features
Also, make sure to start the actual text at the margin.
=======================================================
+* **ethdev: added new API for PMD power management**
+
+ * ``rte_eth_get_monitor_addr()``, to be used in conjunction with
+ ``rte_power_monitor()`` to enable automatic power management for PMD's.
+
Removed Items
-------------
diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 17ddacc78d..e19dbd838b 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -5115,6 +5115,34 @@ rte_eth_tx_burst_mode_get(uint16_t port_id, uint16_t queue_id,
dev->dev_ops->tx_burst_mode_get(dev, queue_id, mode));
}
+int
+rte_eth_get_monitor_addr(uint16_t port_id, uint16_t queue_id,
+ struct rte_power_monitor_cond *pmc)
+{
+ struct rte_eth_dev *dev;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+
+ dev = &rte_eth_devices[port_id];
+
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->get_monitor_addr, -ENOTSUP);
+
+ if (queue_id >= dev->data->nb_rx_queues) {
+ RTE_ETHDEV_LOG(ERR, "Invalid Rx queue_id=%u\n", queue_id);
+ return -EINVAL;
+ }
+
+ if (pmc == NULL) {
+ RTE_ETHDEV_LOG(ERR, "Invalid power monitor condition=%p\n",
+ pmc);
+ return -EINVAL;
+ }
+
+ return eth_err(port_id,
+ dev->dev_ops->get_monitor_addr(dev->data->rx_queues[queue_id],
+ pmc));
+}
+
int
rte_eth_dev_set_mc_addr_list(uint16_t port_id,
struct rte_ether_addr *mc_addr_set,
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index f5f8919186..ca0f91312e 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -157,6 +157,7 @@ extern "C" {
#include <rte_common.h>
#include <rte_config.h>
#include <rte_ether.h>
+#include <rte_power_intrinsics.h>
#include "rte_ethdev_trace_fp.h"
#include "rte_dev_info.h"
@@ -4334,6 +4335,30 @@ __rte_experimental
int rte_eth_tx_burst_mode_get(uint16_t port_id, uint16_t queue_id,
struct rte_eth_burst_mode *mode);
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
+ *
+ * Retrieve the monitor condition for a given receive queue.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param queue_id
+ * The Rx queue on the Ethernet device for which information
+ * will be retrieved.
+ * @param pmc
+ * The pointer point to power-optimized monitoring condition structure.
+ *
+ * @return
+ * - 0: Success.
+ * -ENOTSUP: Operation not supported.
+ * -EINVAL: Invalid parameters.
+ * -ENODEV: Invalid port ID.
+ */
+__rte_experimental
+int rte_eth_get_monitor_addr(uint16_t port_id, uint16_t queue_id,
+ struct rte_power_monitor_cond *pmc);
+
/**
* Retrieve device registers and register attributes (number of registers and
* register size)
diff --git a/lib/librte_ethdev/rte_ethdev_driver.h b/lib/librte_ethdev/rte_ethdev_driver.h
index 0eacfd8425..3b3b0ec1a0 100644
--- a/lib/librte_ethdev/rte_ethdev_driver.h
+++ b/lib/librte_ethdev/rte_ethdev_driver.h
@@ -763,6 +763,26 @@ typedef int (*eth_hairpin_queue_peer_unbind_t)
(struct rte_eth_dev *dev, uint16_t cur_queue, uint32_t direction);
/**< @internal Unbind peer queue from the current queue. */
+/**
+ * @internal
+ * Get address of memory location whose contents will change whenever there is
+ * new data to be received on an Rx queue.
+ *
+ * @param rxq
+ * Ethdev queue pointer.
+ * @param pmc
+ * The pointer to power-optimized monitoring condition structure.
+ * @return
+ * Negative errno value on error, 0 on success.
+ *
+ * @retval 0
+ * Success
+ * @retval -EINVAL
+ * Invalid parameters
+ */
+typedef int (*eth_get_monitor_addr_t)(void *rxq,
+ struct rte_power_monitor_cond *pmc);
+
/**
* @internal A structure containing the functions exported by an Ethernet driver.
*/
@@ -917,6 +937,8 @@ struct eth_dev_ops {
/**< Set up the connection between the pair of hairpin queues. */
eth_hairpin_queue_peer_unbind_t hairpin_queue_peer_unbind;
/**< Disconnect the hairpin queues of a pair from each other. */
+ eth_get_monitor_addr_t get_monitor_addr;
+ /**< Get power monitoring condition for Rx queue. */
};
/**
diff --git a/lib/librte_ethdev/version.map b/lib/librte_ethdev/version.map
index d3f5410806..a124e1e370 100644
--- a/lib/librte_ethdev/version.map
+++ b/lib/librte_ethdev/version.map
@@ -240,6 +240,9 @@ EXPERIMENTAL {
rte_flow_get_restore_info;
rte_flow_tunnel_action_decap_release;
rte_flow_tunnel_item_release;
+
+ # added in 21.02
+ rte_eth_get_monitor_addr;
};
INTERNAL {
--
2.25.1
^ permalink raw reply [relevance 7%]
* [dpdk-dev] [PATCH v2] eal/rwlock: add note about writer starvation
2021-01-12 1:04 3% ` [dpdk-dev] [PATCH] eal/rwlock: add note about writer starvation Stephen Hemminger
@ 2021-01-14 16:55 3% ` Stephen Hemminger
2021-02-11 22:51 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2021-01-14 16:55 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
The implementation of reader/writer locks in DPDK (from first release)
is simple and fast. But it can lead to writer starvation issues.
It is not easy to fix this without changing ABI and potentially
breaking customer applications that are expect the unfair behavior.
The wikipedia page on reader-writer problem has a similar example
which summarizes the problem pretty well.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
v2 - fix wording and spelling
lib/librte_eal/include/generic/rte_rwlock.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/lib/librte_eal/include/generic/rte_rwlock.h b/lib/librte_eal/include/generic/rte_rwlock.h
index da9bc3e9c0e2..15980e2d93e5 100644
--- a/lib/librte_eal/include/generic/rte_rwlock.h
+++ b/lib/librte_eal/include/generic/rte_rwlock.h
@@ -15,6 +15,12 @@
* one writer. All readers are blocked until the writer is finished
* writing.
*
+ * Note: This version of reader/writer locks is not fair because
+ * readers do not block for pending writers. A stream of readers can
+ * subsequently lock out all potential writers and starve them.
+ * This is because after the first reader locks the resource,
+ * no writer can lock it. The writer will only be able to get the lock
+ * when it will only be released by the last reader.
*/
#ifdef __cplusplus
--
2.29.2
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v3 01/22] ethdev: fix MTU size exceeds max rx packet length
@ 2021-01-14 20:44 3% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2021-01-14 20:44 UTC (permalink / raw)
To: Andrew Boyer
Cc: Steve Yang, dev, thomas, andrew.rybchenko, oulijun, Konstantin Ananyev
On 1/14/2021 5:29 PM, Andrew Boyer wrote:
>
>
>> On Jan 14, 2021, at 12:13 PM, Ferruh Yigit <ferruh.yigit@intel.com
>> <mailto:ferruh.yigit@intel.com>> wrote:
>>
>> On 1/14/2021 4:36 PM, Ferruh Yigit wrote:
>>> On 1/14/2021 9:45 AM, Steve Yang wrote:
>>>> Ethdev is using default Ethernet overhead to decide if provided
>>>> 'max_rx_pkt_len' value is bigger than max (non jumbo) MTU value,
>>>> and limits it to MAX if it is.
>>>>
>>>> Since the application/driver used Ethernet overhead is different than
>>>> the ethdev one, check result is wrong.
>>>>
>>>> If the driver is using Ethernet overhead bigger than the default one,
>>>> the provided 'max_rx_pkt_len' is trimmed down, and in the driver when
>>>> correct Ethernet overhead is used to convert back, the resulting MTU is
>>>> less than the intended one, causing some packets to be dropped.
>>>>
>>>> Like,
>>>> app -> max_rx_pkt_len = 1500/*mtu*/ + 22/*overhead*/ = 1522
>>>> ethdev -> 1522 > 1518/*MAX*/; max_rx_pkt_len = 1518
>>>> driver -> MTU = 1518 - 22 = 1496
>>>> Packets with size 1497-1500 are dropped although intention is to be able
>>>> to send/receive them.
>>>>
>>>> The fix is to make ethdev use the correct Ethernet overhead for port,
>>>> instead of default one.
>>>>
>>>> Fixes: 59d0ecdbf0e1 ("ethdev: MTU accessors")
>>>>
>>>> Signed-off-by: Steve Yang <stevex.yang@intel.com <mailto:stevex.yang@intel.com>>
>>> <...>
>>>> @@ -1410,11 +1422,18 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t
>>>> nb_rx_q, uint16_t nb_tx_q,
>>>> goto rollback;
>>>> }
>>>> } else {
>>>> - if (dev_conf->rxmode.max_rx_pkt_len < RTE_ETHER_MIN_LEN ||
>>>> - dev_conf->rxmode.max_rx_pkt_len > RTE_ETHER_MAX_LEN)
>>>> + uint16_t pktlen = dev_conf->rxmode.max_rx_pkt_len;
>>>> + if (pktlen < RTE_ETHER_MIN_MTU + overhead_len ||
>>>> + pktlen > RTE_ETHER_MTU + overhead_len)
>>>> /* Use default value */
>>>> dev->data->dev_conf.rxmode.max_rx_pkt_len =
>>>> - RTE_ETHER_MAX_LEN;
>>>> + RTE_ETHER_MTU + overhead_len;
>>> What do you think removing the above check, the else block, completely?
>>> Since the 'max_rx_pkt_len' should not be used when jumbo frame is not set.
>>
>> As I tested removing this check is causing problem because some PMDs are using
>> the 'max_rx_pkt_len' even jumbo frame is not set.
>>
>> Perhaps better to keep it, and make a separate patch later to remove this
>> check, after PMDs fixed.
>
> Hello Ferruh -
> Working on fixing our PMD here. Do you want PMDs to update the JUMBO_FRAME flag
> based on the mtu value in dev_set_mtu(), or do you want the application to be
> solely responsible for it?
>
Hi Andrew,
Technically JUMBO_FRAME flag is an user config and application should set it. It
is application's responsibility to check the capability and set the flag when
necessary.
But, after above said, many PMDs set it based on provided MTU value, if the
explicitly requested MTU is bigger than the RTE_ETHER_MTU, this means user
implied the JUMBO_FRAME support, for this case PMDs set the flag implicitly
instead of failing.
In another thread Andrew R. & Konstantin suggested to remove the JUMBO_FRAME
flag, since it is redundant and causing this kind of confusion, instead driver
can decide based on requested MTU value, and driver reported 'max_mtu' value can
be used by application to detect the capability. We will probably do this
change, but it can be done only in the ABI break release, v21.11.
For now, PMD can set the flag itself if requested MTU > RTE_ETHER_MTU and driver
supports jumbo frames.
> Thanks,
> Andrew
>
>>>> + }
>>>> +
>>>> + /* Scale the MTU size to adapt max_rx_pkt_len */
>>>> + if (dev_conf->rxmode.offloads & DEV_RX_OFFLOAD_JUMBO_FRAME) {
>>>> + dev->data->mtu = dev->data->dev_conf.rxmode.max_rx_pkt_len -
>>>> + overhead_len;
>>>> }
>>> Above if block has exact same check, why not move it above block?
>>
>> Can you still send a new version for above change please?
>
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [dpdk-dev v3 1/2] ethdev: add new tunnel type for ecpri
@ 2021-01-15 2:42 11% ` Jeff Guo
0 siblings, 0 replies; 200+ results
From: Jeff Guo @ 2021-01-15 2:42 UTC (permalink / raw)
To: qi.z.zhang, thomas, ferruh.yigit, andrew.rybchenko,
bernard.iremonger, wenzhuo.lu, beilei.xing
Cc: jingjing.wu, qiming.yang, haiyue.wang, dev, jia.guo, simei.su,
orika, getelson, maxime.coquelin, jerinj, ajit.khaparde, bingz,
ray.kinsella, dodji, david.marchand
Add type of RTE_TUNNEL_TYPE_ECPRI into the enum of ethdev tunnel type.
Signed-off-by: Jeff Guo <jia.guo@intel.com>
Reviewed-by: Qi Zhang <qi.z.zhang@intel.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
doc/guides/rel_notes/release_21_02.rst | 3 ++-
lib/librte_ethdev/rte_ethdev.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/doc/guides/rel_notes/release_21_02.rst b/doc/guides/rel_notes/release_21_02.rst
index b1bb2d8679..e5168d1312 100644
--- a/doc/guides/rel_notes/release_21_02.rst
+++ b/doc/guides/rel_notes/release_21_02.rst
@@ -110,7 +110,8 @@ ABI Changes
Also, make sure to start the actual text at the margin.
=======================================================
-* No ABI change that would break compatibility with 20.11.
+* ethdev: the structure ``rte_eth_tunnel_type`` has added one parameter
+ ``RTE_TUNNEL_TYPE_ECPRI`` for ecpri UDP port configuration.
Known Issues
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index f5f8919186..2cbce958cf 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
RTE_TUNNEL_TYPE_IP_IN_GRE,
RTE_L2_TUNNEL_TYPE_E_TAG,
RTE_TUNNEL_TYPE_VXLAN_GPE,
+ RTE_TUNNEL_TYPE_ECPRI,
RTE_TUNNEL_TYPE_MAX,
};
--
2.20.1
^ permalink raw reply [relevance 11%]
* [dpdk-dev] [dpdk-dev v4 1/2] ethdev: add new tunnel type for eCPRI
@ 2021-01-15 4:35 11% ` Jeff Guo
0 siblings, 0 replies; 200+ results
From: Jeff Guo @ 2021-01-15 4:35 UTC (permalink / raw)
To: qi.z.zhang, thomas, ferruh.yigit, andrew.rybchenko,
bernard.iremonger, wenzhuo.lu, beilei.xing
Cc: jingjing.wu, qiming.yang, haiyue.wang, dev, jia.guo, simei.su,
orika, getelson, maxime.coquelin, jerinj, ajit.khaparde, bingz,
ray.kinsella, dodji, david.marchand
Add type of RTE_TUNNEL_TYPE_ECPRI into the enum of ethdev tunnel type.
Signed-off-by: Jeff Guo <jia.guo@intel.com>
Reviewed-by: Qi Zhang <qi.z.zhang@intel.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
doc/guides/rel_notes/release_21_02.rst | 15 ++++++++++++++-
lib/librte_ethdev/rte_ethdev.h | 1 +
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/doc/guides/rel_notes/release_21_02.rst b/doc/guides/rel_notes/release_21_02.rst
index b1bb2d8679..2de6afdb85 100644
--- a/doc/guides/rel_notes/release_21_02.rst
+++ b/doc/guides/rel_notes/release_21_02.rst
@@ -61,6 +61,18 @@ New Features
* Added support for Stingray2 device.
+* **Updated the Intel ice driver.**
+
+ Updated the Intel ice driver with new features and improvements, including:
+
+ * Added support for UDP dynamic port assignment for eCPRI protocol configure feature.
+
+* **Updated Intel iavf driver.**
+
+ Updated iavf PMD with new features and improvements, including:
+
+ * Added support for FDIR/RSS packet steering for flow type eCPRI protocol features.
+
Removed Items
-------------
@@ -110,7 +122,8 @@ ABI Changes
Also, make sure to start the actual text at the margin.
=======================================================
-* No ABI change that would break compatibility with 20.11.
+* ethdev: the structure ``rte_eth_tunnel_type`` has added one parameter
+ ``RTE_TUNNEL_TYPE_ECPRI`` for eCPRI UDP port configuration.
Known Issues
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index f5f8919186..2cbce958cf 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
RTE_TUNNEL_TYPE_IP_IN_GRE,
RTE_L2_TUNNEL_TYPE_E_TAG,
RTE_TUNNEL_TYPE_VXLAN_GPE,
+ RTE_TUNNEL_TYPE_ECPRI,
RTE_TUNNEL_TYPE_MAX,
};
--
2.20.1
^ permalink raw reply [relevance 11%]
* [dpdk-dev] [dpdk-dev v5 1/2] ethdev: add new tunnel type for eCPRI
@ 2021-01-15 5:15 11% ` Jeff Guo
2021-01-15 12:23 3% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Jeff Guo @ 2021-01-15 5:15 UTC (permalink / raw)
To: qi.z.zhang, thomas, ferruh.yigit, andrew.rybchenko,
bernard.iremonger, wenzhuo.lu, beilei.xing
Cc: jingjing.wu, qiming.yang, haiyue.wang, dev, jia.guo, simei.su,
orika, getelson, maxime.coquelin, jerinj, ajit.khaparde, bingz,
ray.kinsella, dodji, david.marchand
Add type of RTE_TUNNEL_TYPE_ECPRI into the enum of ethdev tunnel type.
Signed-off-by: Jeff Guo <jia.guo@intel.com>
Reviewed-by: Qi Zhang <qi.z.zhang@intel.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
doc/guides/rel_notes/release_21_02.rst | 15 ++++++++++++++-
lib/librte_ethdev/rte_ethdev.h | 1 +
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/doc/guides/rel_notes/release_21_02.rst b/doc/guides/rel_notes/release_21_02.rst
index b1bb2d8679..80f71be8e6 100644
--- a/doc/guides/rel_notes/release_21_02.rst
+++ b/doc/guides/rel_notes/release_21_02.rst
@@ -61,6 +61,18 @@ New Features
* Added support for Stingray2 device.
+* **Updated the Intel ice driver.**
+
+ Updated the Intel ice driver with new features and improvements, including:
+
+ * Added support for UDP dynamic port assignment for eCPRI protocol configure feature.
+
+* **Updated Intel iavf driver.**
+
+ Updated iavf PMD with new features and improvements, including:
+
+ * Added support for FDIR/RSS packet steering for flow type eCPRI protocol features.
+
Removed Items
-------------
@@ -110,7 +122,8 @@ ABI Changes
Also, make sure to start the actual text at the margin.
=======================================================
-* No ABI change that would break compatibility with 20.11.
+* ethdev: the structure ``rte_eth_tunnel_type`` has added one parameter
+ ``RTE_TUNNEL_TYPE_ECPRI`` for eCPRI UDP port configuration.
Known Issues
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index f5f8919186..2cbce958cf 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
RTE_TUNNEL_TYPE_IP_IN_GRE,
RTE_L2_TUNNEL_TYPE_E_TAG,
RTE_TUNNEL_TYPE_VXLAN_GPE,
+ RTE_TUNNEL_TYPE_ECPRI,
RTE_TUNNEL_TYPE_MAX,
};
--
2.20.1
^ permalink raw reply [relevance 11%]
* Re: [dpdk-dev] [PATCH v3] pci/windows: fix build with SDK >= 10.0.20253
@ 2021-01-15 5:34 3% ` Tyler Retzlaff
0 siblings, 0 replies; 200+ results
From: Tyler Retzlaff @ 2021-01-15 5:34 UTC (permalink / raw)
To: Ranjit Menon; +Cc: dev
On Thu, Jan 14, 2021 at 02:59:44PM -0800, Ranjit Menon wrote:
> Quick q: Do you know when this new SDK will be available publicly?
there are periodic release of the sdk [2] that match the versions of windows
available through the windows insider program [1].
i can see the latest available appears to be 20279 (so later) than the
kit i referenced in the change. so to answer your question a newer kit
is available now. just remember preview kits do not provide a compatibility
guarantee i.e. api and abi may change
[1] https://insider.windows.com/en-us/
[2] https://www.microsoft.com/en-us/software-download/windowsinsiderpreviewSDK
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [dpdk-dev v5 1/2] ethdev: add new tunnel type for eCPRI
2021-01-15 5:15 11% ` [dpdk-dev] [dpdk-dev v5 1/2] ethdev: add new tunnel type " Jeff Guo
@ 2021-01-15 12:23 3% ` Ferruh Yigit
2021-01-18 2:40 0% ` Guo, Jia
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2021-01-15 12:23 UTC (permalink / raw)
To: Jeff Guo, qi.z.zhang, thomas, andrew.rybchenko,
bernard.iremonger, wenzhuo.lu, beilei.xing
Cc: jingjing.wu, qiming.yang, haiyue.wang, dev, simei.su, orika,
getelson, maxime.coquelin, jerinj, ajit.khaparde, bingz,
ray.kinsella, dodji, david.marchand
On 1/15/2021 5:15 AM, Jeff Guo wrote:
> Add type of RTE_TUNNEL_TYPE_ECPRI into the enum of ethdev tunnel type.
>
> Signed-off-by: Jeff Guo <jia.guo@intel.com>
> Reviewed-by: Qi Zhang <qi.z.zhang@intel.com>
> Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
> ---
> doc/guides/rel_notes/release_21_02.rst | 15 ++++++++++++++-
> lib/librte_ethdev/rte_ethdev.h | 1 +
> 2 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/doc/guides/rel_notes/release_21_02.rst b/doc/guides/rel_notes/release_21_02.rst
> index b1bb2d8679..80f71be8e6 100644
> --- a/doc/guides/rel_notes/release_21_02.rst
> +++ b/doc/guides/rel_notes/release_21_02.rst
> @@ -61,6 +61,18 @@ New Features
>
> * Added support for Stingray2 device.
>
> +* **Updated the Intel ice driver.**
> +
> + Updated the Intel ice driver with new features and improvements, including:
> +
> + * Added support for UDP dynamic port assignment for eCPRI protocol configure feature.
> +
> +* **Updated Intel iavf driver.**
> +
> + Updated iavf PMD with new features and improvements, including:
> +
> + * Added support for FDIR/RSS packet steering for flow type eCPRI protocol features.
> +
These are not related to the patch, so dropping from the patch.
>
> Removed Items
> -------------
> @@ -110,7 +122,8 @@ ABI Changes
> Also, make sure to start the actual text at the margin.
> =======================================================
>
> -* No ABI change that would break compatibility with 20.11.
> +* ethdev: the structure ``rte_eth_tunnel_type`` has added one parameter
> + ``RTE_TUNNEL_TYPE_ECPRI`` for eCPRI UDP port configuration.
>
This is not an ABI break, so should not be in this section, also not an API
cange, we can't put there too.
And this change is not big enough to add the new features, perhaps better to
remove this and add the PMD feature updates as you did above for the relevant
sets, so I am dropping this as well.
>
> Known Issues
> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
> index f5f8919186..2cbce958cf 100644
> --- a/lib/librte_ethdev/rte_ethdev.h
> +++ b/lib/librte_ethdev/rte_ethdev.h
> @@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
> RTE_TUNNEL_TYPE_IP_IN_GRE,
> RTE_L2_TUNNEL_TYPE_E_TAG,
> RTE_TUNNEL_TYPE_VXLAN_GPE,
> + RTE_TUNNEL_TYPE_ECPRI,
> RTE_TUNNEL_TYPE_MAX,
> };
>
>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2 1/1] devtools: avoid installing static binaries
2021-01-13 22:01 0% ` Thomas Monjalon
@ 2021-01-15 15:24 3% ` David Marchand
2021-01-15 16:02 4% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2021-01-15 15:24 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Bruce Richardson
On Wed, Jan 13, 2021 at 11:01 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 13/01/2021 20:05, Thomas Monjalon:
> > When testing compilation and checking ABI compatibility,
> > there is no real need of static binaries eating disks.
> >
> > The static linkage of applications was already well tested,
> > though the static examples tested with meson were limited to "l3fwd" only.
> > The static build test with make is limited to "helloworld" example.
> >
> > The ABI compatibility is checked on shared libraries,
> > and there is no need to test again on similar builds.
> > A new parameter is added to the function "build",
> > so the ABI check is enabled only for native gcc and clang shared builds,
> > 32-bit, generic armv8 and ppc cross compilations.
> > In other words, it is disabled for some static builds and some Arm ones.
> >
> > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> > ---
> > v2:
> > - separate ABI check enablement from default library
> > - disable ABI check in specific Arm builds
> > ---
> [...]
> > -build build-x86-default cc -Dlibdir=lib -Dmachine=$default_machine $use_shared
> > +build build-x86-default cc ABI \
> > + -Dlibdir=lib -Dmachine=$default_machine $use_shared
>
> After a second thought, I think this one should be "skipABI".
No opinion on this one.
The title might need some tweak, since you also disabled the ABI check
on some ARM targets.
The rest lgtm.
Acked-by: David Marchand <david.marchand@redhat.com>
--
David Marchand
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2 1/1] devtools: avoid installing static binaries
2021-01-15 15:24 3% ` David Marchand
@ 2021-01-15 16:02 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2021-01-15 16:02 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Bruce Richardson
15/01/2021 16:24, David Marchand:
> On Wed, Jan 13, 2021 at 11:01 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> > 13/01/2021 20:05, Thomas Monjalon:
> > > When testing compilation and checking ABI compatibility,
> > > there is no real need of static binaries eating disks.
> > >
> > > The static linkage of applications was already well tested,
> > > though the static examples tested with meson were limited to "l3fwd" only.
> > > The static build test with make is limited to "helloworld" example.
> > >
> > > The ABI compatibility is checked on shared libraries,
> > > and there is no need to test again on similar builds.
> > > A new parameter is added to the function "build",
> > > so the ABI check is enabled only for native gcc and clang shared builds,
> > > 32-bit, generic armv8 and ppc cross compilations.
> > > In other words, it is disabled for some static builds and some Arm ones.
> > >
> > > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> > > ---
> > > v2:
> > > - separate ABI check enablement from default library
> > > - disable ABI check in specific Arm builds
> > > ---
> > [...]
> > > -build build-x86-default cc -Dlibdir=lib -Dmachine=$default_machine $use_shared
> > > +build build-x86-default cc ABI \
> > > + -Dlibdir=lib -Dmachine=$default_machine $use_shared
> >
> > After a second thought, I think this one should be "skipABI".
>
> No opinion on this one.
>
> The title might need some tweak, since you also disabled the ABI check
> on some ARM targets.
Yes, you're right.
Disabling some ABI checks is a way to reduce the number
of static binaries, but it should be visible in the title.
> The rest lgtm.
>
> Acked-by: David Marchand <david.marchand@redhat.com>
Applied with title "devtools: reduce ABI checks and static binaries"
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] eal/headers: explicitly cast void * to type *
@ 2021-01-17 17:13 3% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2021-01-17 17:13 UTC (permalink / raw)
To: Tyler Retzlaff; +Cc: Bruce Richardson, Dmitry Kozlyuk, dev, navasile, stable
15/01/2021 20:21, Tyler Retzlaff:
> would you also like a patch submitted that stops installing the header. the
> change will be breaking if any other consumers have made the same mistake as
> we did. i'm not sure what dpdk's stance is on pulling headers back out of
> public space.
That's a good question.
If it is described enough that it is not part of the API,
I think we can stop installing the header.
Anyway, our only commitment is on ABI compatibility, so it should be OK.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [dpdk-dev v5 1/2] ethdev: add new tunnel type for eCPRI
2021-01-15 12:23 3% ` Ferruh Yigit
@ 2021-01-18 2:40 0% ` Guo, Jia
0 siblings, 0 replies; 200+ results
From: Guo, Jia @ 2021-01-18 2:40 UTC (permalink / raw)
To: Yigit, Ferruh, Zhang, Qi Z, thomas, andrew.rybchenko, Iremonger,
Bernard, Lu, Wenzhuo, Xing, Beilei
Cc: Wu, Jingjing, Yang, Qiming, Wang, Haiyue, dev, Su, Simei, orika,
getelson, maxime.coquelin, jerinj, ajit.khaparde, bingz,
Kinsella, Ray, dodji, david.marchand
> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> Sent: Friday, January 15, 2021 8:23 PM
> To: Guo, Jia <jia.guo@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>;
> thomas@monjalon.net; andrew.rybchenko@oktetlabs.ru; Iremonger,
> Bernard <bernard.iremonger@intel.com>; Lu, Wenzhuo
> <wenzhuo.lu@intel.com>; Xing, Beilei <beilei.xing@intel.com>
> Cc: Wu, Jingjing <jingjing.wu@intel.com>; Yang, Qiming
> <qiming.yang@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>;
> dev@dpdk.org; Su, Simei <simei.su@intel.com>; orika@nvidia.com;
> getelson@nvidia.com; maxime.coquelin@redhat.com; jerinj@marvell.com;
> ajit.khaparde@broadcom.com; bingz@nvidia.com; Kinsella, Ray
> <ray.kinsella@intel.com>; dodji@redhat.com; david.marchand@redhat.com
> Subject: Re: [dpdk-dev v5 1/2] ethdev: add new tunnel type for eCPRI
>
> On 1/15/2021 5:15 AM, Jeff Guo wrote:
> > Add type of RTE_TUNNEL_TYPE_ECPRI into the enum of ethdev tunnel
> type.
> >
> > Signed-off-by: Jeff Guo <jia.guo@intel.com>
> > Reviewed-by: Qi Zhang <qi.z.zhang@intel.com>
> > Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
> > ---
> > doc/guides/rel_notes/release_21_02.rst | 15 ++++++++++++++-
> > lib/librte_ethdev/rte_ethdev.h | 1 +
> > 2 files changed, 15 insertions(+), 1 deletion(-)
> >
> > diff --git a/doc/guides/rel_notes/release_21_02.rst
> > b/doc/guides/rel_notes/release_21_02.rst
> > index b1bb2d8679..80f71be8e6 100644
> > --- a/doc/guides/rel_notes/release_21_02.rst
> > +++ b/doc/guides/rel_notes/release_21_02.rst
> > @@ -61,6 +61,18 @@ New Features
> >
> > * Added support for Stingray2 device.
> >
> > +* **Updated the Intel ice driver.**
> > +
> > + Updated the Intel ice driver with new features and improvements,
> including:
> > +
> > + * Added support for UDP dynamic port assignment for eCPRI protocol
> configure feature.
> > +
> > +* **Updated Intel iavf driver.**
> > +
> > + Updated iavf PMD with new features and improvements, including:
> > +
> > + * Added support for FDIR/RSS packet steering for flow type eCPRI
> protocol features.
> > +
>
> These are not related to the patch, so dropping from the patch.
>
Ok.
> >
> > Removed Items
> > -------------
> > @@ -110,7 +122,8 @@ ABI Changes
> > Also, make sure to start the actual text at the margin.
> > =======================================================
> >
> > -* No ABI change that would break compatibility with 20.11.
> > +* ethdev: the structure ``rte_eth_tunnel_type`` has added one
> > +parameter
> > + ``RTE_TUNNEL_TYPE_ECPRI`` for eCPRI UDP port configuration.
> >
>
> This is not an ABI break, so should not be in this section, also not an API cange,
> we can't put there too.
> And this change is not big enough to add the new features, perhaps better to
> remove this and add the PMD feature updates as you did above for the
> relevant sets, so I am dropping this as well.
>
Ok, I will use another coming patch to update the doc. Thanks.
> >
> > Known Issues
> > diff --git a/lib/librte_ethdev/rte_ethdev.h
> > b/lib/librte_ethdev/rte_ethdev.h index f5f8919186..2cbce958cf 100644
> > --- a/lib/librte_ethdev/rte_ethdev.h
> > +++ b/lib/librte_ethdev/rte_ethdev.h
> > @@ -1219,6 +1219,7 @@ enum rte_eth_tunnel_type {
> > RTE_TUNNEL_TYPE_IP_IN_GRE,
> > RTE_L2_TUNNEL_TYPE_E_TAG,
> > RTE_TUNNEL_TYPE_VXLAN_GPE,
> > + RTE_TUNNEL_TYPE_ECPRI,
> > RTE_TUNNEL_TYPE_MAX,
> > };
> >
> >
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v17 00/11] Add PMD power management
2021-01-14 14:46 2% ` [dpdk-dev] [PATCH v17 " Anatoly Burakov
2021-01-14 14:46 2% ` [dpdk-dev] [PATCH v17 01/11] eal: uninline power intrinsics Anatoly Burakov
2021-01-14 14:46 7% ` [dpdk-dev] [PATCH v17 06/11] ethdev: add simple power management API Anatoly Burakov
@ 2021-01-18 15:24 0% ` David Marchand
2021-01-18 15:45 0% ` Burakov, Anatoly
2 siblings, 1 reply; 200+ results
From: David Marchand @ 2021-01-18 15:24 UTC (permalink / raw)
To: Anatoly Burakov
Cc: dev, Thomas Monjalon, Ananyev, Konstantin, Timothy McDaniel,
David Hunt, Bruce Richardson, chris.macnamara
On Thu, Jan 14, 2021 at 3:46 PM Anatoly Burakov
<anatoly.burakov@intel.com> wrote:
>
> This patchset proposes a simple API for Ethernet drivers to cause the
> CPU to enter a power-optimized state while waiting for packets to
> arrive. There are multiple proposed mechanisms to achieve said power
> savings: simple frequency scaling, idle loop, and monitoring the Rx
> queue for incoming packages. The latter is achieved through cooperation
> with the NIC driver that will allow us to know address of wake up event,
> and wait for writes on that address.
>
> On IA, this is achieved through using UMONITOR/UMWAIT instructions. They
> are used in their raw opcode form because there is no widespread
> compiler support for them yet. Still, the API is made generic enough to
> hopefully support other architectures, if they happen to implement
> similar instructions.
>
> To achieve power savings, there is a very simple mechanism used: we're
> counting empty polls, and if a certain threshold is reached, we employ
> one of the suggested power management schemes automatically, from within
> a Rx callback inside the PMD. Once there's traffic again, the empty poll
> counter is reset.
>
> This patchset also introduces a few changes into existing power
> management-related intrinsics, namely to provide a native way of waking
> up a sleeping core without application being responsible for it, as well
> as general robustness improvements. There's quite a bit of locking going
> on, but these locks are per-thread and very little (if any) contention
> is expected, so the performance impact shouldn't be that bad (and in any
> case the locking happens when we're about to sleep anyway).
>
> Why are we putting it into ethdev as opposed to leaving this up to the
> application? Our customers specifically requested a way to do it with
> minimal changes to the application code. The current approach allows to
> just flip a switch and automatically have power savings.
>
> Things of note:
>
> - Only 1:1 core to queue mapping is supported, meaning that each lcore
> must at most handle RX on a single queue
> - Support 3 type policies. Monitor/Pause/Frequency Scaling
> - Power management is enabled per-queue
> - The API doesn't extend to other device types
>
> v17:
> - Added exception for ethdev driver-only ABI
> - Added memory barriers for monitor/wakeup (Konstantin)
> - Fixed compiled issues on non-x86 platforms (hopefully!)
SPDK build is still broken.
http://mails.dpdk.org/archives/test-report/2021-January/174840.html
==== 20 line log output for Ubuntu 18.04 (dpdk_compile_spdk): ====
rte_power_pmd_mgmt.c:(.text.experimental+0x1cc): undefined reference
to `rte_eth_add_rx_callback'
rte_power_pmd_mgmt.c:(.text.experimental+0x1f8): undefined reference
to `rte_eth_get_monitor_addr'
rte_power_pmd_mgmt.c:(.text.experimental+0x37f): undefined reference
to `rte_eth_dev_logtype'
/dpdk/build/lib/librte_power.a(librte_power_rte_power_pmd_mgmt.c.o):
In function `rte_power_pmd_mgmt_queue_disable':
rte_power_pmd_mgmt.c:(.text.experimental+0x42a): undefined reference
to `rte_eth_dev_is_valid_port'
rte_power_pmd_mgmt.c:(.text.experimental+0x4e7): undefined reference
to `rte_eth_remove_rx_callback'
rte_power_pmd_mgmt.c:(.text.experimental+0x536): undefined reference
to `rte_eth_remove_rx_callback'
rte_power_pmd_mgmt.c:(.text.experimental+0x54d): undefined reference
to `rte_eth_dev_logtype'
collect2: error: ld returned 1 exit status
/spdk/mk/spdk.app.mk:65: recipe for target 'iscsi_fuzz' failed
/spdk/mk/spdk.subdirs.mk:44: recipe for target 'iscsi_fuzz' failed
/spdk/mk/spdk.subdirs.mk:44: recipe for target 'fuzz' failed
make[4]: *** [iscsi_fuzz] Error 1
make[3]: *** [iscsi_fuzz] Error 2
make[2]: *** [fuzz] Error 2
/spdk/mk/spdk.subdirs.mk:44: recipe for target 'app' failed
make[1]: *** [app] Error 2
/spdk/mk/spdk.subdirs.mk:44: recipe for target 'test' failed
make: *** [test] Error 2
[2] Error running command.
I guess this is because of the added dependency of rte_ethdev to rte_power.
Afaics, SPDK does not use pkg-config:
https://github.com/spdk/spdk/blob/master/lib/env_dpdk/env.mk#L53
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v17 00/11] Add PMD power management
2021-01-18 15:24 0% ` [dpdk-dev] [PATCH v17 00/11] Add PMD power management David Marchand
@ 2021-01-18 15:45 0% ` Burakov, Anatoly
2021-01-18 16:06 3% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Burakov, Anatoly @ 2021-01-18 15:45 UTC (permalink / raw)
To: David Marchand
Cc: dev, Thomas Monjalon, Ananyev, Konstantin, Timothy McDaniel,
David Hunt, Bruce Richardson, chris.macnamara
On 18-Jan-21 3:24 PM, David Marchand wrote:
> On Thu, Jan 14, 2021 at 3:46 PM Anatoly Burakov
> <anatoly.burakov@intel.com> wrote:
>>
>> This patchset proposes a simple API for Ethernet drivers to cause the
>> CPU to enter a power-optimized state while waiting for packets to
>> arrive. There are multiple proposed mechanisms to achieve said power
>> savings: simple frequency scaling, idle loop, and monitoring the Rx
>> queue for incoming packages. The latter is achieved through cooperation
>> with the NIC driver that will allow us to know address of wake up event,
>> and wait for writes on that address.
>>
>> On IA, this is achieved through using UMONITOR/UMWAIT instructions. They
>> are used in their raw opcode form because there is no widespread
>> compiler support for them yet. Still, the API is made generic enough to
>> hopefully support other architectures, if they happen to implement
>> similar instructions.
>>
>> To achieve power savings, there is a very simple mechanism used: we're
>> counting empty polls, and if a certain threshold is reached, we employ
>> one of the suggested power management schemes automatically, from within
>> a Rx callback inside the PMD. Once there's traffic again, the empty poll
>> counter is reset.
>>
>> This patchset also introduces a few changes into existing power
>> management-related intrinsics, namely to provide a native way of waking
>> up a sleeping core without application being responsible for it, as well
>> as general robustness improvements. There's quite a bit of locking going
>> on, but these locks are per-thread and very little (if any) contention
>> is expected, so the performance impact shouldn't be that bad (and in any
>> case the locking happens when we're about to sleep anyway).
>>
>> Why are we putting it into ethdev as opposed to leaving this up to the
>> application? Our customers specifically requested a way to do it with
>> minimal changes to the application code. The current approach allows to
>> just flip a switch and automatically have power savings.
>>
>> Things of note:
>>
>> - Only 1:1 core to queue mapping is supported, meaning that each lcore
>> must at most handle RX on a single queue
>> - Support 3 type policies. Monitor/Pause/Frequency Scaling
>> - Power management is enabled per-queue
>> - The API doesn't extend to other device types
>>
>> v17:
>> - Added exception for ethdev driver-only ABI
>> - Added memory barriers for monitor/wakeup (Konstantin)
>> - Fixed compiled issues on non-x86 platforms (hopefully!)
>
> SPDK build is still broken.
> http://mails.dpdk.org/archives/test-report/2021-January/174840.html
>
> ==== 20 line log output for Ubuntu 18.04 (dpdk_compile_spdk): ====
> rte_power_pmd_mgmt.c:(.text.experimental+0x1cc): undefined reference
> to `rte_eth_add_rx_callback'
> rte_power_pmd_mgmt.c:(.text.experimental+0x1f8): undefined reference
> to `rte_eth_get_monitor_addr'
> rte_power_pmd_mgmt.c:(.text.experimental+0x37f): undefined reference
> to `rte_eth_dev_logtype'
> /dpdk/build/lib/librte_power.a(librte_power_rte_power_pmd_mgmt.c.o):
> In function `rte_power_pmd_mgmt_queue_disable':
> rte_power_pmd_mgmt.c:(.text.experimental+0x42a): undefined reference
> to `rte_eth_dev_is_valid_port'
> rte_power_pmd_mgmt.c:(.text.experimental+0x4e7): undefined reference
> to `rte_eth_remove_rx_callback'
> rte_power_pmd_mgmt.c:(.text.experimental+0x536): undefined reference
> to `rte_eth_remove_rx_callback'
> rte_power_pmd_mgmt.c:(.text.experimental+0x54d): undefined reference
> to `rte_eth_dev_logtype'
> collect2: error: ld returned 1 exit status
> /spdk/mk/spdk.app.mk:65: recipe for target 'iscsi_fuzz' failed
> /spdk/mk/spdk.subdirs.mk:44: recipe for target 'iscsi_fuzz' failed
> /spdk/mk/spdk.subdirs.mk:44: recipe for target 'fuzz' failed
> make[4]: *** [iscsi_fuzz] Error 1
> make[3]: *** [iscsi_fuzz] Error 2
> make[2]: *** [fuzz] Error 2
> /spdk/mk/spdk.subdirs.mk:44: recipe for target 'app' failed
> make[1]: *** [app] Error 2
> /spdk/mk/spdk.subdirs.mk:44: recipe for target 'test' failed
> make: *** [test] Error 2
> [2] Error running command.
>
>
> I guess this is because of the added dependency of rte_ethdev to rte_power.
> Afaics, SPDK does not use pkg-config:
> https://github.com/spdk/spdk/blob/master/lib/env_dpdk/env.mk#L53
>
>
Sooo... this is an SPDK issue then? Because i can't see any way of
fixing the issue on DPDK side.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v17 00/11] Add PMD power management
2021-01-18 15:45 0% ` Burakov, Anatoly
@ 2021-01-18 16:06 3% ` Thomas Monjalon
2021-01-18 17:02 3% ` Burakov, Anatoly
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2021-01-18 16:06 UTC (permalink / raw)
To: David Marchand, Burakov, Anatoly, David Hunt, chris.macnamara
Cc: dev, Ananyev, Konstantin, Timothy McDaniel, Bruce Richardson,
andrew.rybchenko, ferruh.yigit, ajit.khaparde, jerinj
18/01/2021 16:45, Burakov, Anatoly:
> On 18-Jan-21 3:24 PM, David Marchand wrote:
> > On Thu, Jan 14, 2021 at 3:46 PM Anatoly Burakov
> > <anatoly.burakov@intel.com> wrote:
> >>
> >> This patchset proposes a simple API for Ethernet drivers to cause the
> >> CPU to enter a power-optimized state while waiting for packets to
> >> arrive. There are multiple proposed mechanisms to achieve said power
> >> savings: simple frequency scaling, idle loop, and monitoring the Rx
> >> queue for incoming packages. The latter is achieved through cooperation
> >> with the NIC driver that will allow us to know address of wake up event,
> >> and wait for writes on that address.
[...]
> >> Why are we putting it into ethdev as opposed to leaving this up to the
> >> application? Our customers specifically requested a way to do it with
> >> minimal changes to the application code. The current approach allows to
> >> just flip a switch and automatically have power savings.
The customer laziness is usually a bad justification :)
I think we could achieve the same with not too much code
on application side.
And I'm not sure hiding queue management is sane.
Remember this rule: application must remain in control.
[...]
> > SPDK build is still broken.
> > http://mails.dpdk.org/archives/test-report/2021-January/174840.html
[...]
> > I guess this is because of the added dependency of rte_ethdev to rte_power.
> > Afaics, SPDK does not use pkg-config:
> > https://github.com/spdk/spdk/blob/master/lib/env_dpdk/env.mk#L53
>
> Sooo... this is an SPDK issue then? Because i can't see any way of
> fixing the issue on DPDK side.
Yes SPDK should not skip pkg-config.
But it raises 2 question:
- are we breaking ABI compatibility?
- is ethdev management expected for librte_power?
It makes me wonder whether we should host the few functions mixing
librte_ethdev and librte_power somewhere else.
The question is where?
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v17 00/11] Add PMD power management
2021-01-18 16:06 3% ` Thomas Monjalon
@ 2021-01-18 17:02 3% ` Burakov, Anatoly
2021-01-18 17:54 3% ` David Marchand
0 siblings, 1 reply; 200+ results
From: Burakov, Anatoly @ 2021-01-18 17:02 UTC (permalink / raw)
To: Thomas Monjalon, David Marchand, David Hunt, chris.macnamara
Cc: dev, Ananyev, Konstantin, Timothy McDaniel, Bruce Richardson,
andrew.rybchenko, ferruh.yigit, ajit.khaparde, jerinj
On 18-Jan-21 4:06 PM, Thomas Monjalon wrote:
> 18/01/2021 16:45, Burakov, Anatoly:
>> On 18-Jan-21 3:24 PM, David Marchand wrote:
>>> On Thu, Jan 14, 2021 at 3:46 PM Anatoly Burakov
>>> <anatoly.burakov@intel.com> wrote:
>>>>
>>>> This patchset proposes a simple API for Ethernet drivers to cause the
>>>> CPU to enter a power-optimized state while waiting for packets to
>>>> arrive. There are multiple proposed mechanisms to achieve said power
>>>> savings: simple frequency scaling, idle loop, and monitoring the Rx
>>>> queue for incoming packages. The latter is achieved through cooperation
>>>> with the NIC driver that will allow us to know address of wake up event,
>>>> and wait for writes on that address.
> [...]
>>>> Why are we putting it into ethdev as opposed to leaving this up to the
>>>> application? Our customers specifically requested a way to do it with
>>>> minimal changes to the application code. The current approach allows to
>>>> just flip a switch and automatically have power savings.
>
> The customer laziness is usually a bad justification :)
> I think we could achieve the same with not too much code
> on application side.
Yes, we could. Customers could basically take this patch and reimplement
it inside their application, and get the same benefits (with also added
benefit of having knowledge about their queue/core mapping, and so being
able to use the PAUSE or SCALE schemes for more than one queue).
However, i still think it's a valid use case - if we can do it that way
and have a ready-made power management story, why not?
> And I'm not sure hiding queue management is sane.
> Remember this rule: application must remain in control.
>
The application can still be in control by just not using the API and
implementing things manually instead. Nothing is being taken away from
the ability of application to be in control.
> [...]
>>> SPDK build is still broken.
>>> http://mails.dpdk.org/archives/test-report/2021-January/174840.html
> [...]
>>> I guess this is because of the added dependency of rte_ethdev to rte_power.
>>> Afaics, SPDK does not use pkg-config:
>>> https://github.com/spdk/spdk/blob/master/lib/env_dpdk/env.mk#L53
>>
>> Sooo... this is an SPDK issue then? Because i can't see any way of
>> fixing the issue on DPDK side.
>
> Yes SPDK should not skip pkg-config.
> But it raises 2 question:
> - are we breaking ABI compatibility?
Good question. Does including an extra intra-DPDK dependency count as
ABI break? I was under impression that we didn't want DPDK to be
distributed as individual libraries but rather would like it to be used
as a whole, so if internal dependencies between components change, it's
not a big deal (unless a third-party build system is used that
explicitly specifies dependencies rather than using pkg-config).
> - is ethdev management expected for librte_power?
>
> It makes me wonder whether we should host the few functions mixing
> librte_ethdev and librte_power somewhere else.
> The question is where?
>
That could be another possibility. We could put this into a separate
library, but IMO it would serve no purpose other than avoiding adding a
dependency on *internal* component to librte_power. I'm not sure it's a
worthy trade off.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v17 00/11] Add PMD power management
2021-01-18 17:02 3% ` Burakov, Anatoly
@ 2021-01-18 17:54 3% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2021-01-18 17:54 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: Thomas Monjalon, David Hunt, chris.macnamara, dev, Ananyev,
Konstantin, Timothy McDaniel, Bruce Richardson, Andrew Rybchenko,
Yigit, Ferruh, Ajit Khaparde, Jerin Jacob Kollanukkaran
On Mon, Jan 18, 2021 at 6:02 PM Burakov, Anatoly
<anatoly.burakov@intel.com> wrote:
> >>> SPDK build is still broken.
> >>> http://mails.dpdk.org/archives/test-report/2021-January/174840.html
> > [...]
> >>> I guess this is because of the added dependency of rte_ethdev to rte_power.
> >>> Afaics, SPDK does not use pkg-config:
> >>> https://github.com/spdk/spdk/blob/master/lib/env_dpdk/env.mk#L53
> >>
> >> Sooo... this is an SPDK issue then? Because i can't see any way of
> >> fixing the issue on DPDK side.
> >
> > Yes SPDK should not skip pkg-config.
> > But it raises 2 question:
> > - are we breaking ABI compatibility?
>
> Good question. Does including an extra intra-DPDK dependency count as
> ABI break? I was under impression that we didn't want DPDK to be
> distributed as individual libraries but rather would like it to be used
> as a whole, so if internal dependencies between components change, it's
> not a big deal (unless a third-party build system is used that
> explicitly specifies dependencies rather than using pkg-config).
I don't get where an ABI breakage would be.
What I reported is an issue with static link.
For shared link, I would expect librte_power would expose its
dependency on rte_ethdev via a DT_NEEDED entry.
The final binary does not have to be aware of it.
--
David Marchand
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v18 0/2] Add PMD power management
@ 2021-01-19 16:45 3% ` Anatoly Burakov
2021-01-20 11:50 3% ` [dpdk-dev] [PATCH v19 0/4] " Anatoly Burakov
0 siblings, 1 reply; 200+ results
From: Anatoly Burakov @ 2021-01-19 16:45 UTC (permalink / raw)
To: dev; +Cc: thomas
This patchset proposes a simple API for Ethernet drivers to cause the
CPU to enter a power-optimized state while waiting for packets to
arrive. There are multiple proposed mechanisms to achieve said power
savings: simple frequency scaling, idle loop, and monitoring the Rx
queue for incoming packages. The latter is achieved through cooperation
with the NIC driver that will allow us to know address of wake up event,
and wait for writes on that address.
To achieve power savings, there is a very simple mechanism used: we're
counting empty polls, and if a certain threshold is reached, we employ
one of the suggested power management schemes automatically, from within
a Rx callback inside the PMD. Once there's traffic again, the empty poll
counter is reset.
Why are we putting it into ethdev as opposed to leaving this up to the
application? Our customers specifically requested a way to do it with
minimal changes to the application code. The current approach allows to
just flip a switch and automatically have power savings.
Things of note:
- Only 1:1 core to queue mapping is supported, meaning that each lcore
must at most handle RX on a single queue
- Support 3 type policies. Monitor/Pause/Frequency Scaling
- Power management is enabled per-queue
- The API doesn't extend to other device types
v18:
- Rebase on top of latest main
- Address review comments by Thomas
v17:
- Added exception for ethdev driver-only ABI
- Added memory barriers for monitor/wakeup (Konstantin)
- Fixed compiled issues on non-x86 platforms (hopefully!)
v16:
- Implemented Konstantin's suggestions and comments
- Added return values to the API
v15:
- Fixed incorrect check in UMWAIT callback
- Fixed accidental whitespace changes
v14:
- Fixed ARM/PPC builds
- Addressed various review comments
v13:
- Reworked the librte_power code to require less locking and handle invalid
parameters better
- Fix numerous rebase errors present in v12
v12:
- Rebase on top of 21.02
- Rework of power intrinsics code
Liang Ma (2):
power: add PMD power management API and callback
examples/l3fwd-power: enable PMD power mgmt
doc/guides/prog_guide/power_man.rst | 41 ++
doc/guides/rel_notes/release_21_02.rst | 10 +
.../sample_app_ug/l3_forward_power_man.rst | 35 ++
examples/l3fwd-power/main.c | 90 ++++-
lib/librte_power/meson.build | 5 +-
lib/librte_power/rte_power_pmd_mgmt.c | 365 ++++++++++++++++++
lib/librte_power/rte_power_pmd_mgmt.h | 91 +++++
lib/librte_power/version.map | 5 +
8 files changed, 638 insertions(+), 4 deletions(-)
create mode 100644 lib/librte_power/rte_power_pmd_mgmt.c
create mode 100644 lib/librte_power/rte_power_pmd_mgmt.h
--
2.25.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v7 1/2] cryptodev: support enqueue and dequeue callback functions
@ 2021-01-19 18:31 8% ` Thomas Monjalon
2021-01-20 13:01 3% ` Kinsella, Ray
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2021-01-19 18:31 UTC (permalink / raw)
To: Abhinandan Gujjar
Cc: dev, konstantin.ananyev, Akhil Goyal, ray.kinsella, aconole,
david.marchand
15/01/2021 17:01, Akhil Goyal:
> > This patch adds APIs to add/remove callback functions on crypto
> > enqueue/dequeue burst. The callback function will be called for
> > each burst of crypto ops received/sent on a given crypto device
> > queue pair.
> >
> > Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > ---
> Series applied to dpdk-next-crypto
It is missing a rule to ignore the false positive ABI break:
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -11,3 +11,8 @@
; Explicit ignore for driver-only ABI
[suppress_type]
name = eth_dev_ops
+
+; Ignore fields inserted in cacheline boundary of rte_cryptodev
+[suppress_type]
+ name = rte_cryptodev
+ has_data_member_inserted_between = {0, 1023}
I'll add this change while pulling in the main tree.
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [PATCH v8 2/3] build: use Python pmdinfogen
@ 2021-01-20 0:05 3% ` Thomas Monjalon
2021-01-20 7:23 0% ` Dmitry Kozlyuk
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2021-01-20 0:05 UTC (permalink / raw)
To: Dmitry Kozlyuk
Cc: dev, ci, Stephen Hemminger, David Marchand, Maxime Coquelin,
Aaron Conole, Bruce Richardson, ferruh.yigit
This is now the right timeframe to introduce this change
with the new Python module dependency.
Unfortunately, the ABI check is returning an issue:
'const char mlx5_common_pci_pmd_info[62]' was changed
to 'const char mlx5_common_pci_pmd_info[60]' at rte_common_mlx5.pmd.c
Few more comments below:
20/10/2020 19:44, Dmitry Kozlyuk:
> --- a/buildtools/meson.build
> +++ b/buildtools/meson.build
> +if host_machine.system() != 'windows'
You can use "is_windows".
> --- a/doc/guides/linux_gsg/sys_reqs.rst
> +++ b/doc/guides/linux_gsg/sys_reqs.rst
> +* ``pyelftools`` (version 0.22+)
This requirement is missing in doc/guides/freebsd_gsg/build_dpdk.rst
> --- a/meson.build
> +++ b/meson.build
> -subdir('buildtools/pmdinfogen')
This could be in patch 3 (removing the code).
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v8 2/3] build: use Python pmdinfogen
2021-01-20 0:05 3% ` Thomas Monjalon
@ 2021-01-20 7:23 0% ` Dmitry Kozlyuk
2021-01-20 10:24 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Dmitry Kozlyuk @ 2021-01-20 7:23 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev, ci, Stephen Hemminger, David Marchand, Maxime Coquelin,
Aaron Conole, Bruce Richardson, ferruh.yigit
On Wed, 20 Jan 2021 01:05:59 +0100, Thomas Monjalon wrote:
> This is now the right timeframe to introduce this change
> with the new Python module dependency.
> Unfortunately, the ABI check is returning an issue:
>
> 'const char mlx5_common_pci_pmd_info[62]' was changed
> to 'const char mlx5_common_pci_pmd_info[60]' at rte_common_mlx5.pmd.c
Will investigate and fix ASAP.
> Few more comments below:
>
> 20/10/2020 19:44, Dmitry Kozlyuk:
> > --- a/buildtools/meson.build
> > +++ b/buildtools/meson.build
> > +if host_machine.system() != 'windows'
>
> You can use "is_windows".
It's defined by config/meson.build, which is processed after
buidtools/meson.build, because of the dependency, if swapped:
config/x86/meson.build:6:1: ERROR: Unknown variable
"binutils_avx512_check".
> > --- a/doc/guides/linux_gsg/sys_reqs.rst
> > +++ b/doc/guides/linux_gsg/sys_reqs.rst
> > +* ``pyelftools`` (version 0.22+)
>
> This requirement is missing in doc/guides/freebsd_gsg/build_dpdk.rst
OK.
> > --- a/meson.build
> > +++ b/meson.build
> > -subdir('buildtools/pmdinfogen')
>
> This could be in patch 3 (removing the code).
It would redefine "pmdinfogen" variable to old pmdinfogen.
Besides, why build what's not used at this patch already?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v8 2/3] build: use Python pmdinfogen
2021-01-20 7:23 0% ` Dmitry Kozlyuk
@ 2021-01-20 10:24 0% ` Thomas Monjalon
2021-01-22 20:31 4% ` Dmitry Kozlyuk
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2021-01-20 10:24 UTC (permalink / raw)
To: Dmitry Kozlyuk
Cc: dev, Stephen Hemminger, David Marchand, Maxime Coquelin,
Aaron Conole, Bruce Richardson, ferruh.yigit
20/01/2021 08:23, Dmitry Kozlyuk:
> On Wed, 20 Jan 2021 01:05:59 +0100, Thomas Monjalon wrote:
> > This is now the right timeframe to introduce this change
> > with the new Python module dependency.
> > Unfortunately, the ABI check is returning an issue:
> >
> > 'const char mlx5_common_pci_pmd_info[62]' was changed
> > to 'const char mlx5_common_pci_pmd_info[60]' at rte_common_mlx5.pmd.c
>
> Will investigate and fix ASAP.
>
> > Few more comments below:
> >
> > 20/10/2020 19:44, Dmitry Kozlyuk:
> > > --- a/buildtools/meson.build
> > > +++ b/buildtools/meson.build
> > > +if host_machine.system() != 'windows'
> >
> > You can use "is_windows".
>
> It's defined by config/meson.build, which is processed after
> buidtools/meson.build, because of the dependency, if swapped:
>
> config/x86/meson.build:6:1: ERROR: Unknown variable
> "binutils_avx512_check".
OK
> > > --- a/doc/guides/linux_gsg/sys_reqs.rst
> > > +++ b/doc/guides/linux_gsg/sys_reqs.rst
> > > +* ``pyelftools`` (version 0.22+)
> >
> > This requirement is missing in doc/guides/freebsd_gsg/build_dpdk.rst
>
> OK.
>
> > > --- a/meson.build
> > > +++ b/meson.build
> > > -subdir('buildtools/pmdinfogen')
> >
> > This could be in patch 3 (removing the code).
>
> It would redefine "pmdinfogen" variable to old pmdinfogen.
> Besides, why build what's not used at this patch already?
Just trying to find the best patch split.
If needed, OK to keep as is.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v19 0/4] Add PMD power management
2021-01-19 16:45 3% ` [dpdk-dev] [PATCH v18 0/2] Add PMD power management Anatoly Burakov
@ 2021-01-20 11:50 3% ` Anatoly Burakov
2021-01-22 17:12 3% ` [dpdk-dev] [PATCH v20 " Anatoly Burakov
0 siblings, 1 reply; 200+ results
From: Anatoly Burakov @ 2021-01-20 11:50 UTC (permalink / raw)
To: dev; +Cc: thomas
This patchset proposes a simple API for Ethernet drivers to cause the
CPU to enter a power-optimized state while waiting for packets to
arrive. There are multiple proposed mechanisms to achieve said power
savings: simple frequency scaling, idle loop, and monitoring the Rx
queue for incoming packages. The latter is achieved through cooperation
with the NIC driver that will allow us to know address of wake up event,
and wait for writes on that address.
To achieve power savings, there is a very simple mechanism used: we're
counting empty polls, and if a certain threshold is reached, we employ
one of the suggested power management schemes automatically, from within
a Rx callback inside the PMD. Once there's traffic again, the empty poll
counter is reset.
Why are we putting it into ethdev as opposed to leaving this up to the
application? Our customers specifically requested a way to do it with
minimal changes to the application code. The current approach allows to
just flip a switch and automatically have power savings.
Things of note:
- Only 1:1 core to queue mapping is supported, meaning that each lcore
must at most handle RX on a single queue
- Support 3 type policies. Monitor/Pause/Frequency Scaling
- Power management is enabled per-queue
- The API doesn't extend to other device types
v19:
- Renamed "data_sz" to "size" and clarified struct comments
- Clarified documentation around rte_power_monitor/pause API
v18:
- Rebase on top of latest main
- Address review comments by Thomas
v17:
- Added exception for ethdev driver-only ABI
- Added memory barriers for monitor/wakeup (Konstantin)
- Fixed compiled issues on non-x86 platforms (hopefully!)
v16:
- Implemented Konstantin's suggestions and comments
- Added return values to the API
v15:
- Fixed incorrect check in UMWAIT callback
- Fixed accidental whitespace changes
v14:
- Fixed ARM/PPC builds
- Addressed various review comments
v13:
- Reworked the librte_power code to require less locking and handle invalid
parameters better
- Fix numerous rebase errors present in v12
v12:
- Rebase on top of 21.02
- Rework of power intrinsics code
Anatoly Burakov (2):
eal: rename power monitor condition member
eal: improve comments around power monitoring API
Liang Ma (2):
power: add PMD power management API and callback
examples/l3fwd-power: enable PMD power mgmt
doc/guides/prog_guide/power_man.rst | 41 ++
doc/guides/rel_notes/release_21_02.rst | 10 +
.../sample_app_ug/l3_forward_power_man.rst | 35 ++
drivers/event/dlb/dlb.c | 2 +-
drivers/event/dlb2/dlb2.c | 2 +-
drivers/net/i40e/i40e_rxtx.c | 2 +-
drivers/net/ice/ice_rxtx.c | 2 +-
drivers/net/ixgbe/ixgbe_rxtx.c | 2 +-
examples/l3fwd-power/main.c | 90 ++++-
.../include/generic/rte_power_intrinsics.h | 39 +-
lib/librte_eal/x86/rte_power_intrinsics.c | 4 +-
lib/librte_power/meson.build | 5 +-
lib/librte_power/rte_power_pmd_mgmt.c | 365 ++++++++++++++++++
lib/librte_power/rte_power_pmd_mgmt.h | 91 +++++
lib/librte_power/version.map | 5 +
15 files changed, 669 insertions(+), 26 deletions(-)
create mode 100644 lib/librte_power/rte_power_pmd_mgmt.c
create mode 100644 lib/librte_power/rte_power_pmd_mgmt.h
--
2.25.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v7 1/2] cryptodev: support enqueue and dequeue callback functions
2021-01-20 13:01 3% ` Kinsella, Ray
@ 2021-01-20 13:12 0% ` David Marchand
2021-01-20 13:15 0% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: David Marchand @ 2021-01-20 13:12 UTC (permalink / raw)
To: Kinsella, Ray
Cc: Thomas Monjalon, Gujjar, Abhinandan S, dev, Ananyev, Konstantin,
Akhil Goyal, aconole
On Wed, Jan 20, 2021 at 2:01 PM Kinsella, Ray <ray.kinsella@intel.com> wrote:
> > --- a/devtools/libabigail.abignore
> > +++ b/devtools/libabigail.abignore
> > @@ -11,3 +11,8 @@
> > ; Explicit ignore for driver-only ABI
> > [suppress_type]
> > name = eth_dev_ops
> > +
> > +; Ignore fields inserted in cacheline boundary of rte_cryptodev
> > +[suppress_type]
> > + name = rte_cryptodev
> > + has_data_member_inserted_between = {0, 1023}
> >
>
> This is a bit of a blunt instrument as the range quiet large?
> {offset_after(attached), end} instead works better - I will send a patch.
This is what I suggested to Thomas offlist.
A drawback I see is that we are now blind for any later changes
occurring in this range.
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 1/2] cryptodev: support enqueue and dequeue callback functions
2021-01-20 13:01 3% ` Kinsella, Ray
2021-01-20 13:12 0% ` David Marchand
@ 2021-01-20 13:15 0% ` Thomas Monjalon
2021-01-20 14:09 0% ` Kinsella, Ray
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2021-01-20 13:15 UTC (permalink / raw)
To: Gujjar, Abhinandan S, Kinsella, Ray, mdr
Cc: dev, Ananyev, Konstantin, Akhil Goyal, aconole, david.marchand
20/01/2021 14:01, Kinsella, Ray:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 15/01/2021 17:01, Akhil Goyal:
> > > > This patch adds APIs to add/remove callback functions on crypto
> > > > enqueue/dequeue burst. The callback function will be called for
> > each
> > > > burst of crypto ops received/sent on a given crypto device queue
> > > > pair.
> > > >
> > > > Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> > > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > > > ---
> > > Series applied to dpdk-next-crypto
> >
> >
> > It is missing a rule to ignore the false positive ABI break:
> >
> > --- a/devtools/libabigail.abignore
> > +++ b/devtools/libabigail.abignore
> > @@ -11,3 +11,8 @@
> > ; Explicit ignore for driver-only ABI
> > [suppress_type]
> > name = eth_dev_ops
> > +
> > +; Ignore fields inserted in cacheline boundary of rte_cryptodev
> > +[suppress_type]
> > + name = rte_cryptodev
> > + has_data_member_inserted_between = {0, 1023}
> >
>
> This is a bit of a blunt instrument as the range quiet large?
The range is in bits. It matches the actual size of the struct
for 64B cacheline.
> {offset_after(attached), end} instead works better - I will send a patch.
Yes that's exactly what David told me earlier today.
> > I'll add this change while pulling in the main tree.
Yes please.
Note: we missed requiring this exception rule in the original patch.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v1] devtools: update abi ignore for cryptodev
@ 2021-01-20 14:25 4% Ray Kinsella
2021-01-20 15:41 7% ` Thomas Monjalon
2021-01-26 11:55 8% ` Thomas Monjalon
0 siblings, 2 replies; 200+ results
From: Ray Kinsella @ 2021-01-20 14:25 UTC (permalink / raw)
To: Ray Kinsella, Neil Horman, Akhil Goyal, Konstantin Ananyev,
Abhinandan Gujjar
Cc: thomas, david.marchand, dev
Update the ignore entry for crytodev to use named fields instead of
bit positions.
Fixes: 1c3ffb9559
Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
---
devtools/libabigail.abignore | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 1dc84fa74b..1f17fbed58 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -15,4 +15,4 @@
; Ignore fields inserted in cacheline boundary of rte_cryptodev
[suppress_type]
name = rte_cryptodev
- has_data_member_inserted_between = {0, 1023}
+ has_data_member_inserted_between = {offset_after(attached), end}
\ No newline at end of file
--
2.26.2
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v2 02/44] bus/vdev: add driver IOVA VA mode requirement
@ 2021-01-20 15:32 8% ` David Marchand
2021-01-20 17:47 0% ` Maxime Coquelin
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2021-01-20 15:32 UTC (permalink / raw)
To: Maxime Coquelin, Ray Kinsella
Cc: dev, Xia, Chenbo, Olivier Matz, Adrian Moreno Zapata, Thomas Monjalon
On Tue, Jan 19, 2021 at 10:25 PM Maxime Coquelin
<maxime.coquelin@redhat.com> wrote:
>
> This patch adds driver flag in vdev bus driver so that
> vdev drivers can require VA IOVA mode to be used, which
> for example the case of Virtio-user PMD.
>
> The patch implements the .get_iommu_class() callback, that
> is called before devices probing to determine the IOVA mode
> to be used.
>
> It also adds a check right before the device is probed to
> ensure compatible IOVa mode has been selected.
>
> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
> ---
> drivers/bus/vdev/rte_bus_vdev.h | 4 ++++
> drivers/bus/vdev/vdev.c | 31 +++++++++++++++++++++++++++++++
> 2 files changed, 35 insertions(+)
>
> diff --git a/drivers/bus/vdev/rte_bus_vdev.h b/drivers/bus/vdev/rte_bus_vdev.h
> index f99a41f825..c8b41e649c 100644
> --- a/drivers/bus/vdev/rte_bus_vdev.h
> +++ b/drivers/bus/vdev/rte_bus_vdev.h
> @@ -113,8 +113,12 @@ struct rte_vdev_driver {
> rte_vdev_remove_t *remove; /**< Virtual device remove function. */
> rte_vdev_dma_map_t *dma_map; /**< Virtual device DMA map function. */
> rte_vdev_dma_unmap_t *dma_unmap; /**< Virtual device DMA unmap function. */
> + uint32_t drv_flags; /**< Flags RTE_VDEV_DRV_*. */
This will probably get broken in the future, but for now, can you
indent the comment in the same way as earlier lines?
The ABI check will complain about this change so we need an exception.
rte_vdev_driver is exposed only through driver API.
We could flag the whole structure like we did for ethdev.
But there is also the alternative of just flagging the required
symbols so that we won't miss later the inclusion of this structure in
an API used by final users.
How about:
diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 1dc84fa74b..435913d908 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -11,6 +11,8 @@
; Explicit ignore for driver-only ABI
[suppress_type]
name = eth_dev_ops
+[suppress_function]
+ name_regexp = rte_vdev_(|un)register
; Ignore fields inserted in cacheline boundary of rte_cryptodev
[suppress_type]
> };
>
> +/** Device driver needs IOVA as VA and cannot work with IOVA as PA */
> +#define RTE_VDEV_DRV_NEED_IOVA_AS_VA 0x0001
> +
> /**
> * Register a virtual device driver.
> *
> diff --git a/drivers/bus/vdev/vdev.c b/drivers/bus/vdev/vdev.c
> index acfd78828f..56f15e8201 100644
> --- a/drivers/bus/vdev/vdev.c
> +++ b/drivers/bus/vdev/vdev.c
> @@ -189,6 +189,7 @@ vdev_probe_all_drivers(struct rte_vdev_device *dev)
> {
> const char *name;
> struct rte_vdev_driver *driver;
> + enum rte_iova_mode iova_mode;
> int ret;
>
> if (rte_dev_is_probed(&dev->device))
> @@ -199,6 +200,14 @@ vdev_probe_all_drivers(struct rte_vdev_device *dev)
>
> if (vdev_parse(name, &driver))
> return -1;
> +
> + iova_mode = rte_eal_iova_mode();
> + if ((driver->drv_flags & RTE_VDEV_DRV_NEED_IOVA_AS_VA) && (iova_mode == RTE_IOVA_PA)) {
> + VDEV_LOG(ERR, "%s requires VA IOVA mode but current mode is PA, not initializing",
> + name);
> + return -1;
> + }
> +
> ret = driver->probe(dev);
> if (ret == 0)
> dev->device.driver = &driver->driver;
> @@ -594,6 +603,27 @@ vdev_unplug(struct rte_device *dev)
> return rte_vdev_uninit(dev->name);
> }
>
> +static enum rte_iova_mode
> +vdev_get_iommu_class(void)
> +{
> + const char *name;
> + struct rte_vdev_device *dev;
> + struct rte_vdev_driver *driver;
> +
> + TAILQ_FOREACH(dev, &vdev_device_list, next) {
> + name = rte_vdev_device_name(dev);
> + if (!name)
> + continue;
Afaics, a device in vdev_device_list always has a name.
> + if (vdev_parse(name, &driver))
> + continue;
> +
> + if (driver->drv_flags & RTE_VDEV_DRV_NEED_IOVA_AS_VA)
> + return RTE_IOVA_VA;
> + }
> +
> + return RTE_IOVA_DC;
> +}
> +
> static struct rte_bus rte_vdev_bus = {
> .scan = vdev_scan,
> .probe = vdev_probe,
> @@ -603,6 +633,7 @@ static struct rte_bus rte_vdev_bus = {
> .parse = vdev_parse,
> .dma_map = vdev_dma_map,
> .dma_unmap = vdev_dma_unmap,
> + .get_iommu_class = vdev_get_iommu_class,
> .dev_iterate = rte_vdev_dev_iterate,
> };
>
> --
> 2.29.2
>
--
David Marchand
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [PATCH v1] devtools: update abi ignore for cryptodev
2021-01-20 14:25 4% [dpdk-dev] [PATCH v1] devtools: update abi ignore for cryptodev Ray Kinsella
@ 2021-01-20 15:41 7% ` Thomas Monjalon
2021-01-21 15:15 4% ` Dodji Seketeli
2021-01-26 11:55 8% ` Thomas Monjalon
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2021-01-20 15:41 UTC (permalink / raw)
To: dodji
Cc: Ray Kinsella, Neil Horman, Akhil Goyal, Konstantin Ananyev,
Abhinandan Gujjar, dev, david.marchand
Question to an expert, Dodji,
We have this structure:
struct rte_cryptodev {
lot of fields...
uint8_t attached : 1;
} __rte_cache_aligned;
Because of the cache alignment, there is enough padding in the struct
(no matter the size of the cache line) for adding two more pointers:
struct rte_cryptodev {
lot of fields...
uint8_t attached : 1;
struct rte_cryptodev_cb_rcu *enq_cbs;
struct rte_cryptodev_cb_rcu *deq_cbs;
} __rte_cache_aligned;
We checked manually that the ABI is still compatible.
Then I've added (quickly) a libabigail exception rule:
[suppress_type]
name = rte_cryptodev
has_data_member_inserted_between = {0, 1023}
Now we want to improve this rule to restrict the offsets
to the padding at the end of the struct only,
so we keep forbidding changes in existing fields,
and forbidding additions further the current struct size.
Is this new rule good?
has_data_member_inserted_between = {offset_after(attached), end}
Do you confirm that the keyword "end" means the old reference size?
What else do we need to check for adding a new field in a padding?
Thank you
20/01/2021 15:25, Ray Kinsella:
> Update the ignore entry for crytodev to use named fields instead of
> bit positions.
>
> Fixes: 1c3ffb9559
>
> Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
> ---
> devtools/libabigail.abignore | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
> index 1dc84fa74b..1f17fbed58 100644
> --- a/devtools/libabigail.abignore
> +++ b/devtools/libabigail.abignore
> @@ -15,4 +15,4 @@
> ; Ignore fields inserted in cacheline boundary of rte_cryptodev
> [suppress_type]
> name = rte_cryptodev
> - has_data_member_inserted_between = {0, 1023}
> + has_data_member_inserted_between = {offset_after(attached), end}
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [PATCH v2 02/44] bus/vdev: add driver IOVA VA mode requirement
2021-01-20 15:32 8% ` David Marchand
@ 2021-01-20 17:47 0% ` Maxime Coquelin
0 siblings, 0 replies; 200+ results
From: Maxime Coquelin @ 2021-01-20 17:47 UTC (permalink / raw)
To: David Marchand, Ray Kinsella
Cc: dev, Xia, Chenbo, Olivier Matz, Adrian Moreno Zapata, Thomas Monjalon
On 1/20/21 4:32 PM, David Marchand wrote:
> On Tue, Jan 19, 2021 at 10:25 PM Maxime Coquelin
> <maxime.coquelin@redhat.com> wrote:
>>
>> This patch adds driver flag in vdev bus driver so that
>> vdev drivers can require VA IOVA mode to be used, which
>> for example the case of Virtio-user PMD.
>>
>> The patch implements the .get_iommu_class() callback, that
>> is called before devices probing to determine the IOVA mode
>> to be used.
>>
>> It also adds a check right before the device is probed to
>> ensure compatible IOVa mode has been selected.
>>
>> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
>> ---
>> drivers/bus/vdev/rte_bus_vdev.h | 4 ++++
>> drivers/bus/vdev/vdev.c | 31 +++++++++++++++++++++++++++++++
>> 2 files changed, 35 insertions(+)
>>
>> diff --git a/drivers/bus/vdev/rte_bus_vdev.h b/drivers/bus/vdev/rte_bus_vdev.h
>> index f99a41f825..c8b41e649c 100644
>> --- a/drivers/bus/vdev/rte_bus_vdev.h
>> +++ b/drivers/bus/vdev/rte_bus_vdev.h
>> @@ -113,8 +113,12 @@ struct rte_vdev_driver {
>> rte_vdev_remove_t *remove; /**< Virtual device remove function. */
>> rte_vdev_dma_map_t *dma_map; /**< Virtual device DMA map function. */
>> rte_vdev_dma_unmap_t *dma_unmap; /**< Virtual device DMA unmap function. */
>> + uint32_t drv_flags; /**< Flags RTE_VDEV_DRV_*. */
>
> This will probably get broken in the future, but for now, can you
> indent the comment in the same way as earlier lines?
>
>
> The ABI check will complain about this change so we need an exception.
>
> rte_vdev_driver is exposed only through driver API.
> We could flag the whole structure like we did for ethdev.
> But there is also the alternative of just flagging the required
> symbols so that we won't miss later the inclusion of this structure in
> an API used by final users.
> How about:
>
> diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
> index 1dc84fa74b..435913d908 100644
> --- a/devtools/libabigail.abignore
> +++ b/devtools/libabigail.abignore
> @@ -11,6 +11,8 @@
> ; Explicit ignore for driver-only ABI
> [suppress_type]
> name = eth_dev_ops
> +[suppress_function]
> + name_regexp = rte_vdev_(|un)register
>
> ; Ignore fields inserted in cacheline boundary of rte_cryptodev
> [suppress_type]
>
>
This is fine by me.
>> };
>>
>> +/** Device driver needs IOVA as VA and cannot work with IOVA as PA */
>> +#define RTE_VDEV_DRV_NEED_IOVA_AS_VA 0x0001
>> +
>> /**
>> * Register a virtual device driver.
>> *
>> diff --git a/drivers/bus/vdev/vdev.c b/drivers/bus/vdev/vdev.c
>> index acfd78828f..56f15e8201 100644
>> --- a/drivers/bus/vdev/vdev.c
>> +++ b/drivers/bus/vdev/vdev.c
>> @@ -189,6 +189,7 @@ vdev_probe_all_drivers(struct rte_vdev_device *dev)
>> {
>> const char *name;
>> struct rte_vdev_driver *driver;
>> + enum rte_iova_mode iova_mode;
>> int ret;
>>
>> if (rte_dev_is_probed(&dev->device))
>> @@ -199,6 +200,14 @@ vdev_probe_all_drivers(struct rte_vdev_device *dev)
>>
>> if (vdev_parse(name, &driver))
>> return -1;
>> +
>> + iova_mode = rte_eal_iova_mode();
>> + if ((driver->drv_flags & RTE_VDEV_DRV_NEED_IOVA_AS_VA) && (iova_mode == RTE_IOVA_PA)) {
>> + VDEV_LOG(ERR, "%s requires VA IOVA mode but current mode is PA, not initializing",
>> + name);
>> + return -1;
>> + }
>> +
>> ret = driver->probe(dev);
>> if (ret == 0)
>> dev->device.driver = &driver->driver;
>> @@ -594,6 +603,27 @@ vdev_unplug(struct rte_device *dev)
>> return rte_vdev_uninit(dev->name);
>> }
>>
>> +static enum rte_iova_mode
>> +vdev_get_iommu_class(void)
>> +{
>> + const char *name;
>> + struct rte_vdev_device *dev;
>> + struct rte_vdev_driver *driver;
>> +
>> + TAILQ_FOREACH(dev, &vdev_device_list, next) {
>> + name = rte_vdev_device_name(dev);
>> + if (!name)
>> + continue;
>
> Afaics, a device in vdev_device_list always has a name.
Indeed, I will remove the check in next revision.
Thanks,
Maxime
>
>> + if (vdev_parse(name, &driver))
>> + continue;
>> +
>> + if (driver->drv_flags & RTE_VDEV_DRV_NEED_IOVA_AS_VA)
>> + return RTE_IOVA_VA;
>> + }
>> +
>> + return RTE_IOVA_DC;
>> +}
>> +
>> static struct rte_bus rte_vdev_bus = {
>> .scan = vdev_scan,
>> .probe = vdev_probe,
>> @@ -603,6 +633,7 @@ static struct rte_bus rte_vdev_bus = {
>> .parse = vdev_parse,
>> .dma_map = vdev_dma_map,
>> .dma_unmap = vdev_dma_unmap,
>> + .get_iommu_class = vdev_get_iommu_class,
>> .dev_iterate = rte_vdev_dev_iterate,
>> };
>>
>> --
>> 2.29.2
>>
>
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 1/2] cryptodev: support enqueue and dequeue callback functions
2021-01-19 18:31 8% ` Thomas Monjalon
@ 2021-01-20 13:01 3% ` Kinsella, Ray
2021-01-20 13:12 0% ` David Marchand
2021-01-20 13:15 0% ` Thomas Monjalon
0 siblings, 2 replies; 200+ results
From: Kinsella, Ray @ 2021-01-20 13:01 UTC (permalink / raw)
To: Thomas Monjalon, Gujjar, Abhinandan S
Cc: dev, Ananyev, Konstantin, Akhil Goyal, aconole, david.marchand
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Tuesday 19 January 2021 18:32
> To: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>
> Cc: dev@dpdk.org; Ananyev, Konstantin <konstantin.ananyev@intel.com>;
> Akhil Goyal <akhil.goyal@nxp.com>; Kinsella, Ray
> <ray.kinsella@intel.com>; aconole@redhat.com; david.marchand@redhat.com
> Subject: Re: [dpdk-dev] [PATCH v7 1/2] cryptodev: support enqueue and
> dequeue callback functions
>
> 15/01/2021 17:01, Akhil Goyal:
> > > This patch adds APIs to add/remove callback functions on crypto
> > > enqueue/dequeue burst. The callback function will be called for
> each
> > > burst of crypto ops received/sent on a given crypto device queue
> > > pair.
> > >
> > > Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > > ---
> > Series applied to dpdk-next-crypto
>
>
> It is missing a rule to ignore the false positive ABI break:
>
> --- a/devtools/libabigail.abignore
> +++ b/devtools/libabigail.abignore
> @@ -11,3 +11,8 @@
> ; Explicit ignore for driver-only ABI
> [suppress_type]
> name = eth_dev_ops
> +
> +; Ignore fields inserted in cacheline boundary of rte_cryptodev
> +[suppress_type]
> + name = rte_cryptodev
> + has_data_member_inserted_between = {0, 1023}
>
This is a bit of a blunt instrument as the range quiet large?
{offset_after(attached), end} instead works better - I will send a patch.
> I'll add this change while pulling in the main tree.
>
BTW - can people use ashroe.eu, not intel.com for ABI stuff.
Ray K
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v7 1/2] cryptodev: support enqueue and dequeue callback functions
2021-01-20 13:15 0% ` Thomas Monjalon
@ 2021-01-20 14:09 0% ` Kinsella, Ray
0 siblings, 0 replies; 200+ results
From: Kinsella, Ray @ 2021-01-20 14:09 UTC (permalink / raw)
To: Thomas Monjalon, Gujjar, Abhinandan S, mdr
Cc: dev, Ananyev, Konstantin, Akhil Goyal, aconole, david.marchand
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Wednesday 20 January 2021 13:16
> To: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>; Kinsella, Ray
> <ray.kinsella@intel.com>; mdr@ashroe.eu
> Cc: dev@dpdk.org; Ananyev, Konstantin <konstantin.ananyev@intel.com>;
> Akhil Goyal <akhil.goyal@nxp.com>; aconole@redhat.com;
> david.marchand@redhat.com
> Subject: Re: [dpdk-dev] [PATCH v7 1/2] cryptodev: support enqueue and
> dequeue callback functions
>
> 20/01/2021 14:01, Kinsella, Ray:
> > From: Thomas Monjalon <thomas@monjalon.net>
> > > 15/01/2021 17:01, Akhil Goyal:
> > > > > This patch adds APIs to add/remove callback functions on crypto
> > > > > enqueue/dequeue burst. The callback function will be called for
> > > each
> > > > > burst of crypto ops received/sent on a given crypto device
> queue
> > > > > pair.
> > > > >
> > > > > Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> > > > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > > > > ---
> > > > Series applied to dpdk-next-crypto
> > >
> > >
> > > It is missing a rule to ignore the false positive ABI break:
> > >
> > > --- a/devtools/libabigail.abignore
> > > +++ b/devtools/libabigail.abignore
> > > @@ -11,3 +11,8 @@
> > > ; Explicit ignore for driver-only ABI [suppress_type]
> > > name = eth_dev_ops
> > > +
> > > +; Ignore fields inserted in cacheline boundary of rte_cryptodev
> > > +[suppress_type]
> > > + name = rte_cryptodev
> > > + has_data_member_inserted_between = {0, 1023}
> > >
> >
> > This is a bit of a blunt instrument as the range quiet large?
>
> The range is in bits. It matches the actual size of the struct for 64B
> cacheline.
Ok
>
> > {offset_after(attached), end} instead works better - I will send a
> patch.
>
> Yes that's exactly what David told me earlier today.
Makes sense, I think.
>
> > > I'll add this change while pulling in the main tree.
>
> Yes please.
> Note: we missed requiring this exception rule in the original patch.
Ok, in the next 20 minutes or so.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] DPDK Release Status Meeting 21/01/2021
@ 2021-01-21 12:04 4% Ferruh Yigit
2021-01-22 6:38 0% ` Ruifeng Wang
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2021-01-21 12:04 UTC (permalink / raw)
To: dev; +Cc: Thomas Monjalon
Meeting minutes of 21 January 2021
----------------------------------
Agenda:
* Release Dates
* Highlights
* -rc1 status
* Subtrees
* LTS
* Opens
Participants:
* Arm
* Broadcom
* Debian/Microsoft
* Intel
* Nvidia
* NXP
* Red Hat
Release Dates
-------------
* v21.02 dates
* -rc1 is released on Tuesday, 19 January 2021
* http://inbox.dpdk.org/dev/4846307.Pfn0FrbqUJ@thomas/
* -rc2 Friday, 29 January 2021
* -rc3 Friday, 5 February 2021
* Release pushed to *Wednesday, 17 February 2021*
* Release date may conflict with Chinese New Year, we need to discuss and
define the release date offline in the mail list, please comment.
Highlights
----------
* Need to finalize the 21.02 release date on the mail list.
* pmdinfogen will be switched to python implementation, CI / testing
infrastructures should prepare themselves for the 'pyelftools' dependency.
The patchset to verify the infrastructure in advance:
* https://patches.dpdk.org/project/dpdk/list/?series=13153
-rc1 status
-----------
* No testing result received yet.
* Two build errors detected, virtio for Arm and mingw cross build.
Subtrees
--------
* main
* There are built errors with -rc1
* Arm virtio build error, asked for help
* Mingw cross builds, with older versions of compiler
* Build related updates can continue for -rc2
* Applied changes were mostly for Arm
* New build options can be added
* pmdinfogen python rewrite not merged for -rc1, but planned for -rc2
* This may break the CI / test infrastructures because of 'pyelftools'
dependency
* This has been called out many times, will merge at this point
* Intel power management series
* Partially merged, ethdev & eal part merged, power library part is
remaining
* power library get a new version
* Thomas has concern about the power library design, it looks like
designed for a specific case and not generic
* Currently there is not better suggestion, will proceed if no
there is no objection
* Header check patchset merged partially
* ABI checks, some exceptions added
* Exceptions should be reviewed carefully
* We lost Travis automated ABI checks
* There is github actions checks but it is not sending reports back to
patchwork
* There is a work going on for reporting
* Authors either check ABI themselves or explicitly check the github
actions test results for it
* Can check automated test from:
https://github.com/ovsrobot/dpdk/actions
* Is ring library refactoring work stalled? Arm will check.
* https://patches.dpdk.org/project/dpdk/list/?series=14405
* next-net
* Following ehtdev patches not able to make the -rc1 and postponed to next
release:
* ethdev: introduce representor type
* last version sent late for -rc1
* add apistats function
* Not clear if this is right approach, more comments required
* Also there are some ethdev patches from previous releases, they need to be
cleaned up, most probably will be done in next release.
* For -rc2, there are
* octeon_tx endpoint driver
* ionic set
* various driver and testpmd fixes
* patchsets that first version sent after -rc1 will get less priority
* next-crypto
* There is new compressdev PMD for the -rc2
* Also an ABI break discussion is going on
* next-eventdev
* no update
* next-virtio
* The big refactor set work is going on
* Plan is to merge it for -rc2 if it is ready
* Intel vhost example review is going on, planned for -rc2
* There are some concerns on Alibaba's PIO mapping patch
* Not able to test but there is potential issues
* Struct packing series has less priority against the refactoring sets,
and can wait the refactoring sets to be merged first.
* next-net-mlx
* -rc1 looks OK
* A couple of patches already merged for the -rc2
* A few more is expected
* next-net-brcm
* A few fixes in the backlog
* next-net-intel
* Progressing
* next-net-mrvl
* mvpp2 is expected for the -rc2
LTS
---
* v18.11.11 is released
* http://inbox.dpdk.org/dev/20210120155818.388598-1-ktraynor@redhat.com
* This is the last release of the 18.11 LTS, thanks to all contributors
* v19.11.7
* Luca will start working on patches
* v20.11.x
* Kevin will step down from the 20.11 LTS maintainership, volunteers are
welcome.
Opens
-----
* Coverity scans are automated but not able to assign defects
* Milestone doc is still pending
* https://patches.dpdk.org/patch/86455/
DPDK Release Status Meetings
============================
The DPDK Release Status Meeting is intended for DPDK Committers to discuss the
status of the master tree and sub-trees, and for project managers to track
progress or milestone dates.
The meeting occurs on every Thursdays at 8:30 UTC. on https://meet.jit.si/DPDK
If you wish to attend just send an email to
"John McNamara <john.mcnamara@intel.com>" for the invite.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v1] devtools: update abi ignore for cryptodev
2021-01-20 15:41 7% ` Thomas Monjalon
@ 2021-01-21 15:15 4% ` Dodji Seketeli
2021-01-21 15:58 4% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Dodji Seketeli @ 2021-01-21 15:15 UTC (permalink / raw)
To: Thomas Monjalon
Cc: Ray Kinsella, Neil Horman, Akhil Goyal, Konstantin Ananyev,
Abhinandan Gujjar, dev, david.marchand
Hello Thomas and others,
Thomas Monjalon <thomas@monjalon.net> writes:
> Question to an expert, Dodji,
Thanks for the kind words, but I am not an expert in anything, sadly. I
am just trying to keep learning about these things ;-)
> We have this structure:
>
> struct rte_cryptodev {
> lot of fields...
> uint8_t attached : 1;
> } __rte_cache_aligned;
>
> Because of the cache alignment, there is enough padding in the struct
> (no matter the size of the cache line) for adding two more pointers:
>
> struct rte_cryptodev {
> lot of fields...
> uint8_t attached : 1;
> struct rte_cryptodev_cb_rcu *enq_cbs;
> struct rte_cryptodev_cb_rcu *deq_cbs;
> } __rte_cache_aligned;
>
> We checked manually that the ABI is still compatible.
Right.
I am curious, but normally, libabigail should raise the addition of
structures, but then it'll tell you that there was no size or offset
change between the two structures. If it doesn't, then that's a bug. I
hope it does :-)
> Then I've added (quickly) a libabigail exception rule:
>
> [suppress_type]
> name = rte_cryptodev
> has_data_member_inserted_between = {0, 1023}
>
> Now we want to improve this rule to restrict the offsets
> to the padding at the end of the struct only,
> so we keep forbidding changes in existing fields,
> and forbidding additions further the current struct size.
> Is this new rule good?
>
> has_data_member_inserted_between = {offset_after(attached), end}
Yes, this rule should do what you think it says.
> Do you confirm that the keyword "end" means the old reference size?
Yes I do.
> What else do we need to check for adding a new field in a padding?
Actually, that rule will work independantly of it there is enough
padding or not. It'll shut down the change report, even if the added
data exceeds the padding.
You just made me think of an idea of a new feature there.
Maybe we'd need a new property for the [suppress_type] directive that
would suppress changes only if said changes don't modify the size of the
type or any offset of any member of the type?
Maybe something like:
[suppress_type]
; lots of properties can go here.
; ...
; If the type has any size or offset change
; then this suppression directive will fail
; and the change report will be emitted
has_no_size_or_offset_change
Would that be useful to you in this case,
Cheers,
--
Dodji
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v1] devtools: update abi ignore for cryptodev
2021-01-21 15:15 4% ` Dodji Seketeli
@ 2021-01-21 15:58 4% ` Thomas Monjalon
2021-01-22 12:11 4% ` Kinsella, Ray
2021-01-22 13:09 4% ` Dodji Seketeli
0 siblings, 2 replies; 200+ results
From: Thomas Monjalon @ 2021-01-21 15:58 UTC (permalink / raw)
To: Dodji Seketeli
Cc: Ray Kinsella, Neil Horman, Akhil Goyal, Konstantin Ananyev,
Abhinandan Gujjar, dev, david.marchand
21/01/2021 16:15, Dodji Seketeli:
> Hello Thomas and others,
>
> Thomas Monjalon <thomas@monjalon.net> writes:
>
> > Question to an expert, Dodji,
>
> Thanks for the kind words, but I am not an expert in anything, sadly. I
> am just trying to keep learning about these things ;-)
>
> > We have this structure:
> >
> > struct rte_cryptodev {
> > lot of fields...
> > uint8_t attached : 1;
> > } __rte_cache_aligned;
> >
> > Because of the cache alignment, there is enough padding in the struct
> > (no matter the size of the cache line) for adding two more pointers:
> >
> > struct rte_cryptodev {
> > lot of fields...
> > uint8_t attached : 1;
> > struct rte_cryptodev_cb_rcu *enq_cbs;
> > struct rte_cryptodev_cb_rcu *deq_cbs;
> > } __rte_cache_aligned;
> >
> > We checked manually that the ABI is still compatible.
>
> Right.
>
> I am curious, but normally, libabigail should raise the addition of
> structures, but then it'll tell you that there was no size or offset
> change between the two structures. If it doesn't, then that's a bug. I
> hope it does :-)
Yes it was raising a problem, that's why we are adding a rule.
> > Then I've added (quickly) a libabigail exception rule:
> >
> > [suppress_type]
> > name = rte_cryptodev
> > has_data_member_inserted_between = {0, 1023}
> >
> > Now we want to improve this rule to restrict the offsets
> > to the padding at the end of the struct only,
> > so we keep forbidding changes in existing fields,
> > and forbidding additions further the current struct size.
> > Is this new rule good?
> >
> > has_data_member_inserted_between = {offset_after(attached), end}
>
>
> Yes, this rule should do what you think it says.
>
> > Do you confirm that the keyword "end" means the old reference size?
>
> Yes I do.
>
>
> > What else do we need to check for adding a new field in a padding?
>
> Actually, that rule will work independantly of it there is enough
> padding or not. It'll shut down the change report, even if the added
> data exceeds the padding.
I don't understand why.
If "end" means the old reference size, then addition after the old size
should be reported, isn't it?
> You just made me think of an idea of a new feature there.
>
> Maybe we'd need a new property for the [suppress_type] directive that
> would suppress changes only if said changes don't modify the size of the
> type or any offset of any member of the type?
>
> Maybe something like:
>
> [suppress_type]
> ; lots of properties can go here.
>
> ; ...
>
> ; If the type has any size or offset change
> ; then this suppression directive will fail
> ; and the change report will be emitted
> has_no_size_or_offset_change
>
> Would that be useful to you in this case,
>
> Cheers,
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v11 3/4] raw/ifpga: add OPAE API for OpenStack Cyborg
@ 2021-01-21 16:30 3% ` Ferruh Yigit
2021-01-22 3:16 3% ` Huang, Wei
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2021-01-21 16:30 UTC (permalink / raw)
To: Wei Huang, dev, rosen.xu, qi.z.zhang; +Cc: stable, tianfei.zhang, Ray Kinsella
On 1/21/2021 6:03 AM, Wei Huang wrote:
> Cyborg is an OpenStack project that aims to provide a general purpose
> management framework for acceleration resources (i.e. various types
> of accelerators such as GPU, FPGA, NP, ODP, DPDK/SPDK and so on).
> It needs some OPAE type APIs to manage PACs (Programmable Acceleration
> Card) with Intel FPGA. Below major functions are added to meets
> Cyborg requirements.
> 1. opae_init() set up OPAE environment.
> 2. opae_cleanup() clean up OPAE environment.
> 3. opae_enumerate() searches PAC with specific FPGA.
> 4. opae_get_property() gets properties of FPGA.
> 5. opae_partial_reconfigure() perform partial configuration on FPGA.
> 6. opae_get_image_info() gets information of image file.
> 7. opae_update_flash() updates FPGA flash with specific image file.
> 8. opae_cancel_flash_update() cancel process of FPGA flash update.
> 9. opae_probe_device() manually probe specific FPGA with ifpga driver.
> 10. opae_remove_device() manually remove specific FPGA from ifpga driver.
> 11. opae_bind_driver() binds specific FPGA with specified kernel driver.
> 12. opae_unbind_driver() unbinds specific FPGA from kernel driver.
> 13. opae_reboot_device() reboots specific FPGA (do reconfiguration).
>
Hi Wei,
As far as I understand you are adding above public functions which are on top of
raw/ifpga driver functions, so they are like PMD specific APIs, I think there
are a few problems with it:
1) Do we really need/want this much PMD specific API? Can't we have them through
the rawdev abstraction layer?
2) DPDK public APIs are part of API/ABI policy, so there are a few rules they
have to follow, like:
- They should start with 'rte_' prefix, and the PMD specific APIs should start
with 'rte_pmd_' prefix
- They should be in the .map file
- They should be experimental at least one release
- They should be fully documented in a doxygen format
- Header file should be added to index file for API documentation
Please don't update above before 1) is clearified and we are sure new APIs are
required.
<...>
> @@ -13,8 +13,10 @@ objs = [base_objs]
> deps += ['ethdev', 'rawdev', 'pci', 'bus_pci', 'kvargs',
> 'bus_vdev', 'bus_ifpga', 'net', 'net_i40e', 'net_ipn3ke']
>
> -sources = files('ifpga_rawdev.c')
> +sources = files('ifpga_rawdev.c', 'ifpga_opae_api.c')
>
> includes += include_directories('base')
> includes += include_directories('../../net/ipn3ke')
> includes += include_directories('../../net/i40e')
> +
> +install_headers('ifpga_opae_api.h')
>
There is a 'headers' helper that you can use for meson. Also the header file
name should start with 'rte_pmd_'.
Even before this patch, isn't application has to include the rawdev PMD header?
Why that header was not installed?
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v11 3/4] raw/ifpga: add OPAE API for OpenStack Cyborg
2021-01-21 16:30 3% ` Ferruh Yigit
@ 2021-01-22 3:16 3% ` Huang, Wei
0 siblings, 0 replies; 200+ results
From: Huang, Wei @ 2021-01-22 3:16 UTC (permalink / raw)
To: Yigit, Ferruh, dev, Xu, Rosen, Zhang, Qi Z
Cc: stable, Zhang, Tianfei, Ray Kinsella
Hi Ferruh,
That's a good question.
The answer is YES, we do need all these functions. We have complete the integrated test with Cyborg, there is no redundant function. Let me show you a use case in Cyborg.
Cyborg will update FPGA flash and reboot it to make it effective, so they will call functions like below.
1. opae_enumerate() to find the target FPGA
2. opae_get_property() to check FPGA version
3. opae_get_image_info() to check the update image
4. opae_update_flash() to update FPGA flash
5. opae_reboot_device() to reboot FPGA
6. After reboot, FPGA kernel driver will not be vfio-pci by default, opae_bind_driver() is used to bind vfio-pci kernel driver.
7. opae_probe_device() to attach ifpga PMD to FPGA, then this FPGA can be managed by Cyborg again.
These functions will be wrapped in Python package. Cyborg require this Python package can be downloaded from PyPI and compiled without DPDK installed.
So there is an independent project which will create a static library file from target DPDK. This library is part of Python package and will be used when compiling Python module. That's why I didn't export these function in map file.
BTW, the header file ifpga_opae_api.h is also integrated into Python package from target DPDK.
Thanks,
Wei
-----Original Message-----
From: Ferruh Yigit <ferruh.yigit@intel.com>
Sent: Friday, January 22, 2021 00:30
To: Huang, Wei <wei.huang@intel.com>; dev@dpdk.org; Xu, Rosen <rosen.xu@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>
Cc: stable@dpdk.org; Zhang, Tianfei <tianfei.zhang@intel.com>; Ray Kinsella <mdr@ashroe.eu>
Subject: Re: [dpdk-dev] [PATCH v11 3/4] raw/ifpga: add OPAE API for OpenStack Cyborg
On 1/21/2021 6:03 AM, Wei Huang wrote:
> Cyborg is an OpenStack project that aims to provide a general purpose
> management framework for acceleration resources (i.e. various types of
> accelerators such as GPU, FPGA, NP, ODP, DPDK/SPDK and so on).
> It needs some OPAE type APIs to manage PACs (Programmable Acceleration
> Card) with Intel FPGA. Below major functions are added to meets Cyborg
> requirements.
> 1. opae_init() set up OPAE environment.
> 2. opae_cleanup() clean up OPAE environment.
> 3. opae_enumerate() searches PAC with specific FPGA.
> 4. opae_get_property() gets properties of FPGA.
> 5. opae_partial_reconfigure() perform partial configuration on FPGA.
> 6. opae_get_image_info() gets information of image file.
> 7. opae_update_flash() updates FPGA flash with specific image file.
> 8. opae_cancel_flash_update() cancel process of FPGA flash update.
> 9. opae_probe_device() manually probe specific FPGA with ifpga driver.
> 10. opae_remove_device() manually remove specific FPGA from ifpga driver.
> 11. opae_bind_driver() binds specific FPGA with specified kernel driver.
> 12. opae_unbind_driver() unbinds specific FPGA from kernel driver.
> 13. opae_reboot_device() reboots specific FPGA (do reconfiguration).
>
Hi Wei,
As far as I understand you are adding above public functions which are on top of raw/ifpga driver functions, so they are like PMD specific APIs, I think there are a few problems with it:
1) Do we really need/want this much PMD specific API? Can't we have them through the rawdev abstraction layer?
2) DPDK public APIs are part of API/ABI policy, so there are a few rules they have to follow, like:
- They should start with 'rte_' prefix, and the PMD specific APIs should start with 'rte_pmd_' prefix
- They should be in the .map file
- They should be experimental at least one release
- They should be fully documented in a doxygen format
- Header file should be added to index file for API documentation
Please don't update above before 1) is clearified and we are sure new APIs are required.
<...>
> @@ -13,8 +13,10 @@ objs = [base_objs]
> deps += ['ethdev', 'rawdev', 'pci', 'bus_pci', 'kvargs',
> 'bus_vdev', 'bus_ifpga', 'net', 'net_i40e', 'net_ipn3ke']
>
> -sources = files('ifpga_rawdev.c')
> +sources = files('ifpga_rawdev.c', 'ifpga_opae_api.c')
>
> includes += include_directories('base')
> includes += include_directories('../../net/ipn3ke')
> includes += include_directories('../../net/i40e')
> +
> +install_headers('ifpga_opae_api.h')
>
There is a 'headers' helper that you can use for meson. Also the header file name should start with 'rte_pmd_'.
Even before this patch, isn't application has to include the rawdev PMD header?
Why that header was not installed?
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] DPDK Release Status Meeting 21/01/2021
2021-01-21 12:04 4% [dpdk-dev] DPDK Release Status Meeting 21/01/2021 Ferruh Yigit
@ 2021-01-22 6:38 0% ` Ruifeng Wang
0 siblings, 0 replies; 200+ results
From: Ruifeng Wang @ 2021-01-22 6:38 UTC (permalink / raw)
To: dev, David Marchand
Cc: thomas, Ferruh Yigit, Honnappa Nagarahalli, Konstantin Ananyev, nd, nd
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Ferruh Yigit
> Sent: Thursday, January 21, 2021 8:04 PM
> To: dev@dpdk.org
> Cc: thomas@monjalon.net
> Subject: [dpdk-dev] DPDK Release Status Meeting 21/01/2021
>
> Meeting minutes of 21 January 2021
> ----------------------------------
>
> Agenda:
> * Release Dates
> * Highlights
> * -rc1 status
> * Subtrees
> * LTS
> * Opens
>
> Participants:
> * Arm
> * Broadcom
> * Debian/Microsoft
> * Intel
> * Nvidia
> * NXP
> * Red Hat
>
>
> Release Dates
> -------------
>
> * v21.02 dates
> * -rc1 is released on Tuesday, 19 January 2021
> * http://inbox.dpdk.org/dev/4846307.Pfn0FrbqUJ@thomas/
> * -rc2 Friday, 29 January 2021
> * -rc3 Friday, 5 February 2021
> * Release pushed to *Wednesday, 17 February 2021*
>
> * Release date may conflict with Chinese New Year, we need to discuss and
> define the release date offline in the mail list, please comment.
>
>
> Highlights
> ----------
>
> * Need to finalize the 21.02 release date on the mail list.
>
> * pmdinfogen will be switched to python implementation, CI / testing
> infrastructures should prepare themselves for the 'pyelftools' dependency.
> The patchset to verify the infrastructure in advance:
> * https://patches.dpdk.org/project/dpdk/list/?series=13153
>
>
> -rc1 status
> -----------
>
> * No testing result received yet.
>
> * Two build errors detected, virtio for Arm and mingw cross build.
>
>
> Subtrees
> --------
>
> * main
> * There are built errors with -rc1
> * Arm virtio build error, asked for help
> * Mingw cross builds, with older versions of compiler
> * Build related updates can continue for -rc2
> * Applied changes were mostly for Arm
> * New build options can be added
> * pmdinfogen python rewrite not merged for -rc1, but planned for -rc2
> * This may break the CI / test infrastructures because of 'pyelftools'
> dependency
> * This has been called out many times, will merge at this point
> * Intel power management series
> * Partially merged, ethdev & eal part merged, power library part is
> remaining
> * power library get a new version
> * Thomas has concern about the power library design, it looks like
> designed for a specific case and not generic
> * Currently there is not better suggestion, will proceed if no
> there is no objection
> * Header check patchset merged partially
> * ABI checks, some exceptions added
> * Exceptions should be reviewed carefully
> * We lost Travis automated ABI checks
> * There is github actions checks but it is not sending reports back to
> patchwork
> * There is a work going on for reporting
> * Authors either check ABI themselves or explicitly check the github
> actions test results for it
> * Can check automated test from:
> https://github.com/ovsrobot/dpdk/actions
> * Is ring library refactoring work stalled? Arm will check.
> * https://patches.dpdk.org/project/dpdk/list/?series=14405
IMO, this series is in good shape.
There is no comments from community on this series.
But this work is based on discussion between ring library maintainers (Honnappa, Konstantin):
https://mails.dpdk.org/archives/dev/2020-May/166803.html
Honnappa has already reviewed this series. It will be good if Konstantin can also review and add a tag.
So I think this series can be queued for merge.
PS: The ring test comment mentioned in the meeting is about another patch series:
http://patches.dpdk.org/patch/85641/
>
> * next-net
> * Following ehtdev patches not able to make the -rc1 and postponed to
> next
> release:
> * ethdev: introduce representor type
> * last version sent late for -rc1
> * add apistats function
> * Not clear if this is right approach, more comments required
> * Also there are some ethdev patches from previous releases, they need
> to be
> cleaned up, most probably will be done in next release.
> * For -rc2, there are
> * octeon_tx endpoint driver
> * ionic set
> * various driver and testpmd fixes
> * patchsets that first version sent after -rc1 will get less priority
>
> * next-crypto
> * There is new compressdev PMD for the -rc2
> * Also an ABI break discussion is going on
>
> * next-eventdev
> * no update
>
> * next-virtio
> * The big refactor set work is going on
> * Plan is to merge it for -rc2 if it is ready
> * Intel vhost example review is going on, planned for -rc2
> * There are some concerns on Alibaba's PIO mapping patch
> * Not able to test but there is potential issues
> * Struct packing series has less priority against the refactoring sets,
> and can wait the refactoring sets to be merged first.
>
> * next-net-mlx
> * -rc1 looks OK
> * A couple of patches already merged for the -rc2
> * A few more is expected
>
> * next-net-brcm
> * A few fixes in the backlog
>
> * next-net-intel
> * Progressing
>
> * next-net-mrvl
> * mvpp2 is expected for the -rc2
>
>
> LTS
> ---
>
> * v18.11.11 is released
> * http://inbox.dpdk.org/dev/20210120155818.388598-1-
> ktraynor@redhat.com
> * This is the last release of the 18.11 LTS, thanks to all contributors
>
> * v19.11.7
> * Luca will start working on patches
>
> * v20.11.x
> * Kevin will step down from the 20.11 LTS maintainership, volunteers are
> welcome.
>
>
> Opens
> -----
>
> * Coverity scans are automated but not able to assign defects
>
> * Milestone doc is still pending
> * https://patches.dpdk.org/patch/86455/
>
>
>
> DPDK Release Status Meetings
> ============================
>
> The DPDK Release Status Meeting is intended for DPDK Committers to
> discuss the status of the master tree and sub-trees, and for project
> managers to track progress or milestone dates.
>
> The meeting occurs on every Thursdays at 8:30 UTC. on
> https://meet.jit.si/DPDK
>
> If you wish to attend just send an email to "John McNamara
> <john.mcnamara@intel.com>" for the invite.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v1] devtools: update abi ignore for cryptodev
2021-01-21 15:58 4% ` Thomas Monjalon
@ 2021-01-22 12:11 4% ` Kinsella, Ray
2021-01-22 13:09 4% ` Dodji Seketeli
1 sibling, 0 replies; 200+ results
From: Kinsella, Ray @ 2021-01-22 12:11 UTC (permalink / raw)
To: Thomas Monjalon, Dodji Seketeli
Cc: Neil Horman, Akhil Goyal, Konstantin Ananyev, Abhinandan Gujjar,
dev, david.marchand
On 21/01/2021 15:58, Thomas Monjalon wrote:
> 21/01/2021 16:15, Dodji Seketeli:
>> Hello Thomas and others,
>>
>> Thomas Monjalon <thomas@monjalon.net> writes:
>>
>>> Question to an expert, Dodji,
>>
>> Thanks for the kind words, but I am not an expert in anything, sadly. I
>> am just trying to keep learning about these things ;-)
>>
>>> We have this structure:
>>>
>>> struct rte_cryptodev {
>>> lot of fields...
>>> uint8_t attached : 1;
>>> } __rte_cache_aligned;
>>>
>>> Because of the cache alignment, there is enough padding in the struct
>>> (no matter the size of the cache line) for adding two more pointers:
>>>
>>> struct rte_cryptodev {
>>> lot of fields...
>>> uint8_t attached : 1;
>>> struct rte_cryptodev_cb_rcu *enq_cbs;
>>> struct rte_cryptodev_cb_rcu *deq_cbs;
>>> } __rte_cache_aligned;
>>>
>>> We checked manually that the ABI is still compatible.
>>
>> Right.
>>
>> I am curious, but normally, libabigail should raise the addition of
>> structures, but then it'll tell you that there was no size or offset
>> change between the two structures. If it doesn't, then that's a bug. I
>> hope it does :-)
>
> Yes it was raising a problem, that's why we are adding a rule.
>
>
>>> Then I've added (quickly) a libabigail exception rule:
>>>
>>> [suppress_type]
>>> name = rte_cryptodev
>>> has_data_member_inserted_between = {0, 1023}
>>>
>>> Now we want to improve this rule to restrict the offsets
>>> to the padding at the end of the struct only,
>>> so we keep forbidding changes in existing fields,
>>> and forbidding additions further the current struct size.
>>> Is this new rule good?
>>>
>>> has_data_member_inserted_between = {offset_after(attached), end}
>>
>>
>> Yes, this rule should do what you think it says.
>>
>>> Do you confirm that the keyword "end" means the old reference size?
>>
>> Yes I do.
>>
>>
>>> What else do we need to check for adding a new field in a padding?
>>
>> Actually, that rule will work independantly of it there is enough
>> padding or not. It'll shut down the change report, even if the added
>> data exceeds the padding.
>
> I don't understand why.
> If "end" means the old reference size, then addition after the old size
> should be reported, isn't it?
yes - this comment confuses me also.
If "end" refers to the size original data-structure (position of the end),
which in this case had some padding. If the additions fall fully within the
padding I would expect this rule to work - as long as the data-structure size
is still the same.
However if the additions fall beyond the size of the original data-structure,
the data-structure's size will have changed, I would not expect this rule to
condone a change in the size of the data-structure.
>
>
>> You just made me think of an idea of a new feature there.
>>
>> Maybe we'd need a new property for the [suppress_type] directive that
>> would suppress changes only if said changes don't modify the size of the
>> type or any offset of any member of the type?
>>
>> Maybe something like:
>>
>> [suppress_type]
>> ; lots of properties can go here.
>>
>> ; ...
>>
>> ; If the type has any size or offset change
>> ; then this suppression directive will fail
>> ; and the change report will be emitted
>> has_no_size_or_offset_change
>>
>> Would that be useful to you in this case,
>>
>> Cheers,
>
>
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v1] devtools: update abi ignore for cryptodev
2021-01-21 15:58 4% ` Thomas Monjalon
2021-01-22 12:11 4% ` Kinsella, Ray
@ 2021-01-22 13:09 4% ` Dodji Seketeli
2021-01-22 13:12 4% ` Kinsella, Ray
1 sibling, 1 reply; 200+ results
From: Dodji Seketeli @ 2021-01-22 13:09 UTC (permalink / raw)
To: Thomas Monjalon
Cc: Ray Kinsella, Neil Horman, Akhil Goyal, Konstantin Ananyev,
Abhinandan Gujjar, dev, david.marchand
Thomas Monjalon <thomas@monjalon.net> writes:
[...]
>> > Then I've added (quickly) a libabigail exception rule:
>> >
>> > [suppress_type]
>> > name = rte_cryptodev
>> > has_data_member_inserted_between = {0, 1023}
>> >
>> > Now we want to improve this rule to restrict the offsets
>> > to the padding at the end of the struct only,
>> > so we keep forbidding changes in existing fields,
>> > and forbidding additions further the current struct size.
>> > Is this new rule good?
>> >
>> > has_data_member_inserted_between = {offset_after(attached), end}
>>
>>
>> Yes, this rule should do what you think it says.
>>
>> > Do you confirm that the keyword "end" means the old reference size?
>>
>> Yes I do.
>>
>>
>> > What else do we need to check for adding a new field in a padding?
>>
>> Actually, that rule will work independantly of it there is enough
>> padding or not. It'll shut down the change report, even if the added
>> data exceeds the padding.
>
> I don't understand why.
> If "end" means the old reference size, then addition after the old size
> should be reported, isn't it?
Yes, you are right.
What I meant is that even if (in an hypothetical case, not yours) the
padding was so "small" that it wasn't going up to the 'end' of the
struct, that rule would have still shut down the change report.
[...]
Cheers,
--
Dodji
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v1] devtools: update abi ignore for cryptodev
2021-01-22 13:09 4% ` Dodji Seketeli
@ 2021-01-22 13:12 4% ` Kinsella, Ray
2021-01-24 11:58 4% ` Dodji Seketeli
0 siblings, 1 reply; 200+ results
From: Kinsella, Ray @ 2021-01-22 13:12 UTC (permalink / raw)
To: Dodji Seketeli, Thomas Monjalon
Cc: Neil Horman, Akhil Goyal, Konstantin Ananyev, Abhinandan Gujjar,
dev, david.marchand
On 22/01/2021 13:09, Dodji Seketeli wrote:
> Thomas Monjalon <thomas@monjalon.net> writes:
>
> [...]
>
>>>> Then I've added (quickly) a libabigail exception rule:
>>>>
>>>> [suppress_type]
>>>> name = rte_cryptodev
>>>> has_data_member_inserted_between = {0, 1023}
>>>>
>>>> Now we want to improve this rule to restrict the offsets
>>>> to the padding at the end of the struct only,
>>>> so we keep forbidding changes in existing fields,
>>>> and forbidding additions further the current struct size.
>>>> Is this new rule good?
>>>>
>>>> has_data_member_inserted_between = {offset_after(attached), end}
>>>
>>>
>>> Yes, this rule should do what you think it says.
>>>
>>>> Do you confirm that the keyword "end" means the old reference size?
>>>
>>> Yes I do.
>>>
>>>
>>>> What else do we need to check for adding a new field in a padding?
>>>
>>> Actually, that rule will work independantly of it there is enough
>>> padding or not. It'll shut down the change report, even if the added
>>> data exceeds the padding.
>>
>> I don't understand why.
>> If "end" means the old reference size, then addition after the old size
>> should be reported, isn't it?
>
> Yes, you are right.
>
> What I meant is that even if (in an hypothetical case, not yours) the
> padding was so "small" that it wasn't going up to the 'end' of the
> struct, that rule would have still shut down the change report.
Understood - you are talking about padding between members.
>
> [...]
>
> Cheers,
>
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v20 0/4] Add PMD power management
2021-01-20 11:50 3% ` [dpdk-dev] [PATCH v19 0/4] " Anatoly Burakov
@ 2021-01-22 17:12 3% ` Anatoly Burakov
0 siblings, 0 replies; 200+ results
From: Anatoly Burakov @ 2021-01-22 17:12 UTC (permalink / raw)
To: dev; +Cc: thomas
This patchset proposes a simple API for Ethernet drivers to cause the
CPU to enter a power-optimized state while waiting for packets to
arrive. There are multiple proposed mechanisms to achieve said power
savings: simple frequency scaling, idle loop, and monitoring the Rx
queue for incoming packages. The latter is achieved through cooperation
with the NIC driver that will allow us to know address of wake up event,
and wait for writes on that address.
To achieve power savings, there is a very simple mechanism used: we're
counting empty polls, and if a certain threshold is reached, we employ
one of the suggested power management schemes automatically, from within
a Rx callback inside the PMD. Once there's traffic again, the empty poll
counter is reset.
Why are we putting it into ethdev as opposed to leaving this up to the
application? Our customers specifically requested a way to do it with
minimal changes to the application code. The current approach allows to
just flip a switch and automatically have power savings.
Things of note:
- Only 1:1 core to queue mapping is supported, meaning that each lcore
must at most handle RX on a single queue
- Support 3 type policies. Monitor/Pause/Frequency Scaling
- Power management is enabled per-queue
- The API doesn't extend to other device types
v20:
- Moved callback removal before port close
v19:
- Renamed "data_sz" to "size" and clarified struct comments
- Clarified documentation around rte_power_monitor/pause API
v18:
- Rebase on top of latest main
- Address review comments by Thomas
v17:
- Added exception for ethdev driver-only ABI
- Added memory barriers for monitor/wakeup (Konstantin)
- Fixed compiled issues on non-x86 platforms (hopefully!)
v16:
- Implemented Konstantin's suggestions and comments
- Added return values to the API
v15:
- Fixed incorrect check in UMWAIT callback
- Fixed accidental whitespace changes
v14:
- Fixed ARM/PPC builds
- Addressed various review comments
v13:
- Reworked the librte_power code to require less locking and handle invalid
parameters better
- Fix numerous rebase errors present in v12
v12:
- Rebase on top of 21.02
- Rework of power intrinsics code
Anatoly Burakov (2):
eal: rename power monitor condition member
eal: improve comments around power monitoring API
Liang Ma (2):
power: add PMD power management API and callback
examples/l3fwd-power: enable PMD power mgmt
doc/guides/prog_guide/power_man.rst | 41 ++
doc/guides/rel_notes/release_21_02.rst | 10 +
.../sample_app_ug/l3_forward_power_man.rst | 35 ++
drivers/event/dlb/dlb.c | 2 +-
drivers/event/dlb2/dlb2.c | 2 +-
drivers/net/i40e/i40e_rxtx.c | 2 +-
drivers/net/ice/ice_rxtx.c | 2 +-
drivers/net/ixgbe/ixgbe_rxtx.c | 2 +-
examples/l3fwd-power/main.c | 90 ++++-
.../include/generic/rte_power_intrinsics.h | 39 +-
lib/librte_eal/x86/rte_power_intrinsics.c | 4 +-
lib/librte_power/meson.build | 5 +-
lib/librte_power/rte_power_pmd_mgmt.c | 365 ++++++++++++++++++
lib/librte_power/rte_power_pmd_mgmt.h | 91 +++++
lib/librte_power/version.map | 5 +
15 files changed, 669 insertions(+), 26 deletions(-)
create mode 100644 lib/librte_power/rte_power_pmd_mgmt.c
create mode 100644 lib/librte_power/rte_power_pmd_mgmt.h
--
2.25.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v8 2/3] build: use Python pmdinfogen
2021-01-20 10:24 0% ` Thomas Monjalon
@ 2021-01-22 20:31 4% ` Dmitry Kozlyuk
2021-01-22 20:57 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Dmitry Kozlyuk @ 2021-01-22 20:31 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev, Stephen Hemminger, David Marchand, Maxime Coquelin,
Aaron Conole, Bruce Richardson, ferruh.yigit
On Wed, 20 Jan 2021 11:24:21 +0100, Thomas Monjalon wrote:
> 20/01/2021 08:23, Dmitry Kozlyuk:
> > On Wed, 20 Jan 2021 01:05:59 +0100, Thomas Monjalon wrote:
> > > This is now the right timeframe to introduce this change
> > > with the new Python module dependency.
> > > Unfortunately, the ABI check is returning an issue:
> > >
> > > 'const char mlx5_common_pci_pmd_info[62]' was changed
> > > to 'const char mlx5_common_pci_pmd_info[60]' at rte_common_mlx5.pmd.c
> >
> > Will investigate and fix ASAP.
Now that I think of it: strings like this change every time new PCI IDs are
added to a PMD, but AFAIK adding PCI IDs is not considered an ABI breakage,
is it? One example is 28c9a7d7b48e ("net/mlx5: add ConnectX-6 Lx device ID")
added 2020-07-08, i.e. clearly outside of ABI change window.
"xxx_pmd_info" changes are due to JSON formatting (new is more canonical),
which can be worked around easily, if the above is wrong.
> > > > --- a/meson.build
> > > > +++ b/meson.build
> > > > -subdir('buildtools/pmdinfogen')
> > >
> > > This could be in patch 3 (removing the code).
> >
> > It would redefine "pmdinfogen" variable to old pmdinfogen.
> > Besides, why build what's not used at this patch already?
>
> Just trying to find the best patch split.
> If needed, OK to keep as is.
I even don't mind squashing all three commits into one.
The split is done to ease the review.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v8 2/3] build: use Python pmdinfogen
2021-01-22 20:31 4% ` Dmitry Kozlyuk
@ 2021-01-22 20:57 0% ` Thomas Monjalon
2021-01-22 22:24 3% ` Dmitry Kozlyuk
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2021-01-22 20:57 UTC (permalink / raw)
To: Dmitry Kozlyuk
Cc: dev, Stephen Hemminger, David Marchand, Maxime Coquelin,
Aaron Conole, Bruce Richardson, ferruh.yigit, ray.kinsella
22/01/2021 21:31, Dmitry Kozlyuk:
> On Wed, 20 Jan 2021 11:24:21 +0100, Thomas Monjalon wrote:
> > 20/01/2021 08:23, Dmitry Kozlyuk:
> > > On Wed, 20 Jan 2021 01:05:59 +0100, Thomas Monjalon wrote:
> > > > This is now the right timeframe to introduce this change
> > > > with the new Python module dependency.
> > > > Unfortunately, the ABI check is returning an issue:
> > > >
> > > > 'const char mlx5_common_pci_pmd_info[62]' was changed
> > > > to 'const char mlx5_common_pci_pmd_info[60]' at rte_common_mlx5.pmd.c
> > >
> > > Will investigate and fix ASAP.
>
> Now that I think of it: strings like this change every time new PCI IDs are
> added to a PMD, but AFAIK adding PCI IDs is not considered an ABI breakage,
> is it? One example is 28c9a7d7b48e ("net/mlx5: add ConnectX-6 Lx device ID")
> added 2020-07-08, i.e. clearly outside of ABI change window.
You're right.
> "xxx_pmd_info" changes are due to JSON formatting (new is more canonical),
> which can be worked around easily, if the above is wrong.
If the new format is better, please keep it.
What we need is an exception for the pmdinfo symbols
in the file devtools/libabigail.abignore.
You can probably use a regex for these symbols.
> > > > > --- a/meson.build
> > > > > +++ b/meson.build
> > > > > -subdir('buildtools/pmdinfogen')
> > > >
> > > > This could be in patch 3 (removing the code).
> > >
> > > It would redefine "pmdinfogen" variable to old pmdinfogen.
> > > Besides, why build what's not used at this patch already?
> >
> > Just trying to find the best patch split.
> > If needed, OK to keep as is.
>
> I even don't mind squashing all three commits into one.
> The split is done to ease the review.
I think the split is good as is.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v8 2/3] build: use Python pmdinfogen
2021-01-22 20:57 0% ` Thomas Monjalon
@ 2021-01-22 22:24 3% ` Dmitry Kozlyuk
2021-01-23 11:38 4% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Dmitry Kozlyuk @ 2021-01-22 22:24 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev, Stephen Hemminger, David Marchand, Maxime Coquelin,
Aaron Conole, Bruce Richardson, ferruh.yigit, ray.kinsella
On Fri, 22 Jan 2021 21:57:15 +0100, Thomas Monjalon wrote:
> 22/01/2021 21:31, Dmitry Kozlyuk:
> > On Wed, 20 Jan 2021 11:24:21 +0100, Thomas Monjalon wrote:
> > > 20/01/2021 08:23, Dmitry Kozlyuk:
> > > > On Wed, 20 Jan 2021 01:05:59 +0100, Thomas Monjalon wrote:
> > > > > This is now the right timeframe to introduce this change
> > > > > with the new Python module dependency.
> > > > > Unfortunately, the ABI check is returning an issue:
> > > > >
> > > > > 'const char mlx5_common_pci_pmd_info[62]' was changed
> > > > > to 'const char mlx5_common_pci_pmd_info[60]' at rte_common_mlx5.pmd.c
> > > >
> > > > Will investigate and fix ASAP.
> >
> > Now that I think of it: strings like this change every time new PCI IDs are
> > added to a PMD, but AFAIK adding PCI IDs is not considered an ABI breakage,
> > is it? One example is 28c9a7d7b48e ("net/mlx5: add ConnectX-6 Lx device ID")
> > added 2020-07-08, i.e. clearly outside of ABI change window.
>
> You're right.
>
> > "xxx_pmd_info" changes are due to JSON formatting (new is more canonical),
> > which can be worked around easily, if the above is wrong.
>
> If the new format is better, please keep it.
> What we need is an exception for the pmdinfo symbols
> in the file devtools/libabigail.abignore.
> You can probably use a regex for these symbols.
This would allow real breakages to pass ABI check, abidiff doesn't analyze
variable content and it's not easy to compare. Maybe later a script can be
added that checks lines with RTE_DEVICE_IN in patches. There are at most 32 of
5494 relevant commits between 19.11 and 20.11, though.
To verify there are no meaningful changes I ensured empty diff between
results of the following command for "main" and the branch:
find build/drivers -name '*.so' -exec usertools/dpdk-pmdinfo.py
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v9 0/3] pmdinfogen: rewrite in Python
@ 2021-01-22 22:43 3% ` Dmitry Kozlyuk
2021-01-24 20:51 3% ` [dpdk-dev] [PATCH v10 " Dmitry Kozlyuk
1 sibling, 1 reply; 200+ results
From: Dmitry Kozlyuk @ 2021-01-22 22:43 UTC (permalink / raw)
To: dev
Cc: Maxime Coquelin, Bruce Richardson, Thomas Monjalon,
Dmitry Kozlyuk, Neil Horman, Jie Zhou
This patchset implements existing pmdinfogen logic in Python, replaces
and removes the old code. The goals of rewriting are:
* easier maintenance by using a more high-level language,
* simpler build process without host application and libelf,
* foundation for adding Windows support.
Canonical JSON formatting of generated strings raises ABI warnings.
There are no meaningful changes, which can be checked by comparing
output of pmdinfo before and after the patch:
find build/drivers -name '*.so' -exec usertools/dpdk-pmdinfo.py
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Tested-by: Jie Zhou <jizh@linux.microsoft.com>
---
Changes in v9:
* Document pyelftools requirement for FreeBSD (Thomas).
* Add pyelftools to GitHub workflow.
Dmitry Kozlyuk (3):
pmdinfogen: add Python implementation
build: use Python pmdinfogen
pmdinfogen: remove C implementation
.github/workflows/build.yml | 4 +-
.travis.yml | 2 +-
MAINTAINERS | 3 +-
buildtools/gen-pmdinfo-cfile.sh | 6 +-
buildtools/meson.build | 15 +
buildtools/pmdinfogen.py | 189 +++++++++++
buildtools/pmdinfogen/meson.build | 14 -
buildtools/pmdinfogen/pmdinfogen.c | 456 --------------------------
buildtools/pmdinfogen/pmdinfogen.h | 119 -------
doc/guides/freebsd_gsg/build_dpdk.rst | 3 +-
doc/guides/linux_gsg/sys_reqs.rst | 6 +
drivers/meson.build | 2 +-
meson.build | 1 -
13 files changed, 221 insertions(+), 599 deletions(-)
create mode 100755 buildtools/pmdinfogen.py
delete mode 100644 buildtools/pmdinfogen/meson.build
delete mode 100644 buildtools/pmdinfogen/pmdinfogen.c
delete mode 100644 buildtools/pmdinfogen/pmdinfogen.h
--
2.29.2
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v8 2/3] build: use Python pmdinfogen
2021-01-22 22:24 3% ` Dmitry Kozlyuk
@ 2021-01-23 11:38 4% ` Thomas Monjalon
2021-01-24 20:52 3% ` Dmitry Kozlyuk
2021-01-25 9:25 3% ` Kinsella, Ray
0 siblings, 2 replies; 200+ results
From: Thomas Monjalon @ 2021-01-23 11:38 UTC (permalink / raw)
To: Dmitry Kozlyuk
Cc: dev, Stephen Hemminger, David Marchand, Maxime Coquelin,
Aaron Conole, Bruce Richardson, ferruh.yigit, ray.kinsella, mdr
22/01/2021 23:24, Dmitry Kozlyuk:
> On Fri, 22 Jan 2021 21:57:15 +0100, Thomas Monjalon wrote:
> > 22/01/2021 21:31, Dmitry Kozlyuk:
> > > On Wed, 20 Jan 2021 11:24:21 +0100, Thomas Monjalon wrote:
> > > > 20/01/2021 08:23, Dmitry Kozlyuk:
> > > > > On Wed, 20 Jan 2021 01:05:59 +0100, Thomas Monjalon wrote:
> > > > > > This is now the right timeframe to introduce this change
> > > > > > with the new Python module dependency.
> > > > > > Unfortunately, the ABI check is returning an issue:
> > > > > >
> > > > > > 'const char mlx5_common_pci_pmd_info[62]' was changed
> > > > > > to 'const char mlx5_common_pci_pmd_info[60]' at rte_common_mlx5.pmd.c
> > > > >
> > > > > Will investigate and fix ASAP.
> > >
> > > Now that I think of it: strings like this change every time new PCI IDs are
> > > added to a PMD, but AFAIK adding PCI IDs is not considered an ABI breakage,
> > > is it? One example is 28c9a7d7b48e ("net/mlx5: add ConnectX-6 Lx device ID")
> > > added 2020-07-08, i.e. clearly outside of ABI change window.
> >
> > You're right.
> >
> > > "xxx_pmd_info" changes are due to JSON formatting (new is more canonical),
> > > which can be worked around easily, if the above is wrong.
> >
> > If the new format is better, please keep it.
> > What we need is an exception for the pmdinfo symbols
> > in the file devtools/libabigail.abignore.
> > You can probably use a regex for these symbols.
>
> This would allow real breakages to pass ABI check, abidiff doesn't analyze
> variable content and it's not easy to compare. Maybe later a script can be
> added that checks lines with RTE_DEVICE_IN in patches. There are at most 32 of
> 5494 relevant commits between 19.11 and 20.11, though.
>
> To verify there are no meaningful changes I ensured empty diff between
> results of the following command for "main" and the branch:
>
> find build/drivers -name '*.so' -exec usertools/dpdk-pmdinfo.py
For now we cannot do such check as part of the ABI checker.
And we cannot merge this patch if the ABI check fails.
I think the only solution is to allow any change in the pmdinfo variables.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v1] devtools: update abi ignore for cryptodev
2021-01-22 13:12 4% ` Kinsella, Ray
@ 2021-01-24 11:58 4% ` Dodji Seketeli
0 siblings, 0 replies; 200+ results
From: Dodji Seketeli @ 2021-01-24 11:58 UTC (permalink / raw)
To: Kinsella, Ray
Cc: Dodji Seketeli, Thomas Monjalon, Neil Horman, Akhil Goyal,
Konstantin Ananyev, Abhinandan Gujjar, dev, david.marchand
"Kinsella, Ray" <mdr@ashroe.eu> writes:
> On 22/01/2021 13:09, Dodji Seketeli wrote:
>> Thomas Monjalon <thomas@monjalon.net> writes:
>>
>> [...]
>>
>>>>> Then I've added (quickly) a libabigail exception rule:
>>>>>
>>>>> [suppress_type]
>>>>> name = rte_cryptodev
>>>>> has_data_member_inserted_between = {0, 1023}
>>>>>
>>>>> Now we want to improve this rule to restrict the offsets
>>>>> to the padding at the end of the struct only,
>>>>> so we keep forbidding changes in existing fields,
>>>>> and forbidding additions further the current struct size.
>>>>> Is this new rule good?
>>>>>
>>>>> has_data_member_inserted_between = {offset_after(attached), end}
>>>>
>>>>
>>>> Yes, this rule should do what you think it says.
>>>>
>>>>> Do you confirm that the keyword "end" means the old reference size?
>>>>
>>>> Yes I do.
>>>>
>>>>
>>>>> What else do we need to check for adding a new field in a padding?
>>>>
>>>> Actually, that rule will work independantly of it there is enough
>>>> padding or not. It'll shut down the change report, even if the added
>>>> data exceeds the padding.
>>>
>>> I don't understand why.
>>> If "end" means the old reference size, then addition after the old size
>>> should be reported, isn't it?
>>
>> Yes, you are right.
>>
>> What I meant is that even if (in an hypothetical case, not yours) the
>> padding was so "small" that it wasn't going up to the 'end' of the
>> struct, that rule would have still shut down the change report.
>
> Understood - you are talking about padding between members.
Exactly.
Cheers,
--
Dodji
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v10 0/3] pmdinfogen: rewrite in Python
2021-01-22 22:43 3% ` [dpdk-dev] [PATCH v9 0/3] pmdinfogen: rewrite in Python Dmitry Kozlyuk
@ 2021-01-24 20:51 3% ` Dmitry Kozlyuk
2021-01-24 20:51 2% ` [dpdk-dev] [PATCH v10 2/3] build: use Python pmdinfogen Dmitry Kozlyuk
0 siblings, 1 reply; 200+ results
From: Dmitry Kozlyuk @ 2021-01-24 20:51 UTC (permalink / raw)
To: dev
Cc: Maxime Coquelin, Bruce Richardson, Thomas Monjalon,
Dmitry Kozlyuk, Neil Horman, Jie Zhou
This patchset implements existing pmdinfogen logic in Python, replaces
and removes the old code. The goals of rewriting are:
* easier maintenance by using a more high-level language,
* simpler build process without host application and libelf,
* foundation for adding Windows support.
Identity of generated PMD information is checked by comparing
output of pmdinfo before and after the patch:
find build/drivers -name '*.so' -exec usertools/dpdk-pmdinfo.py
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Tested-by: Jie Zhou <jizh@linux.microsoft.com>
---
Changes in v10:
* Suppress ABI warnings for generated strings (Thomas).
Dmitry Kozlyuk (3):
pmdinfogen: add Python implementation
build: use Python pmdinfogen
pmdinfogen: remove C implementation
.github/workflows/build.yml | 4 +-
.travis.yml | 2 +-
MAINTAINERS | 3 +-
buildtools/gen-pmdinfo-cfile.sh | 6 +-
buildtools/meson.build | 15 +
buildtools/pmdinfogen.py | 189 +++++++++++
buildtools/pmdinfogen/meson.build | 14 -
buildtools/pmdinfogen/pmdinfogen.c | 456 --------------------------
buildtools/pmdinfogen/pmdinfogen.h | 119 -------
devtools/libabigail.abignore | 4 +
doc/guides/freebsd_gsg/build_dpdk.rst | 3 +-
doc/guides/linux_gsg/sys_reqs.rst | 6 +
drivers/meson.build | 2 +-
meson.build | 1 -
14 files changed, 225 insertions(+), 599 deletions(-)
create mode 100755 buildtools/pmdinfogen.py
delete mode 100644 buildtools/pmdinfogen/meson.build
delete mode 100644 buildtools/pmdinfogen/pmdinfogen.c
delete mode 100644 buildtools/pmdinfogen/pmdinfogen.h
--
2.29.2
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v10 2/3] build: use Python pmdinfogen
2021-01-24 20:51 3% ` [dpdk-dev] [PATCH v10 " Dmitry Kozlyuk
@ 2021-01-24 20:51 2% ` Dmitry Kozlyuk
0 siblings, 0 replies; 200+ results
From: Dmitry Kozlyuk @ 2021-01-24 20:51 UTC (permalink / raw)
To: dev
Cc: Maxime Coquelin, Bruce Richardson, Thomas Monjalon,
Dmitry Kozlyuk, Aaron Conole, Michael Santana, Ray Kinsella,
Neil Horman
Use the same interpreter to run pmdinfogen as for other build scripts.
Adjust wrapper script accordingly and also don't suppress stderr from ar
and pmdinfogen. Add configure-time check for elftools Python module for
Unix hosts.
Add pyelftools to CI configuration and build requirements for Linux and
FreeBSD. Windows targets are not currently using pmdinfogen.
Suppress ABI warnings about generated PMD information strings.
Signed-off-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
---
.github/workflows/build.yml | 4 ++--
.travis.yml | 2 +-
buildtools/gen-pmdinfo-cfile.sh | 6 +++---
buildtools/meson.build | 15 +++++++++++++++
devtools/libabigail.abignore | 4 ++++
doc/guides/freebsd_gsg/build_dpdk.rst | 3 ++-
doc/guides/linux_gsg/sys_reqs.rst | 6 ++++++
drivers/meson.build | 2 +-
meson.build | 1 -
9 files changed, 34 insertions(+), 9 deletions(-)
diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
index 0b72df0eb..a5b579add 100644
--- a/.github/workflows/build.yml
+++ b/.github/workflows/build.yml
@@ -91,8 +91,8 @@ jobs:
run: sudo apt update
- name: Install packages
run: sudo apt install -y ccache libnuma-dev python3-setuptools
- python3-wheel python3-pip ninja-build libbsd-dev libpcap-dev
- libibverbs-dev libcrypto++-dev libfdt-dev libjansson-dev
+ python3-wheel python3-pip python3-pyelftools ninja-build libbsd-dev
+ libpcap-dev libibverbs-dev libcrypto++-dev libfdt-dev libjansson-dev
- name: Install libabigail build dependencies if no cache is available
if: env.ABI_CHECKS == 'true' && steps.libabigail-cache.outputs.cache-hit != 'true'
run: sudo apt install -y autoconf automake libtool pkg-config libxml2-dev
diff --git a/.travis.yml b/.travis.yml
index 5aa7ad49f..4391af1d5 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -14,7 +14,7 @@ addons:
apt:
update: true
packages: &required_packages
- - [libnuma-dev, python3-setuptools, python3-wheel, python3-pip, ninja-build]
+ - [libnuma-dev, python3-setuptools, python3-wheel, python3-pip, python3-pyelftools, ninja-build]
- [libbsd-dev, libpcap-dev, libibverbs-dev, libcrypto++-dev, libfdt-dev, libjansson-dev]
_aarch64_packages: &aarch64_packages
diff --git a/buildtools/gen-pmdinfo-cfile.sh b/buildtools/gen-pmdinfo-cfile.sh
index 43059cf36..109ee461e 100755
--- a/buildtools/gen-pmdinfo-cfile.sh
+++ b/buildtools/gen-pmdinfo-cfile.sh
@@ -4,11 +4,11 @@
arfile=$1
output=$2
-pmdinfogen=$3
+shift 2
+pmdinfogen=$*
# The generated file must not be empty if compiled in pedantic mode
echo 'static __attribute__((unused)) const char *generator = "'$0'";' > $output
for ofile in `ar t $arfile` ; do
- ar p $arfile $ofile | $pmdinfogen - - >> $output 2> /dev/null
+ ar p $arfile $ofile | $pmdinfogen - - >> $output
done
-exit 0
diff --git a/buildtools/meson.build b/buildtools/meson.build
index 04808dabc..dd4c0f640 100644
--- a/buildtools/meson.build
+++ b/buildtools/meson.build
@@ -17,3 +17,18 @@ else
endif
map_to_win_cmd = py3 + files('map_to_win.py')
sphinx_wrapper = py3 + files('call-sphinx-build.py')
+pmdinfogen = py3 + files('pmdinfogen.py')
+
+# TODO: starting from Meson 0.51.0 use
+# python3 = import('python').find_installation('python',
+# modules : python3_required_modules)
+python3_required_modules = []
+if host_machine.system() != 'windows'
+ python3_required_modules = ['elftools']
+endif
+foreach module : python3_required_modules
+ script = 'import importlib.util; import sys; exit(importlib.util.find_spec("@0@") is None)'
+ if run_command(py3, '-c', script.format(module)).returncode() != 0
+ error('missing python module: @0@'.format(module))
+ endif
+endforeach
diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 1dc84fa74..05afccc1a 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -16,3 +16,7 @@
[suppress_type]
name = rte_cryptodev
has_data_member_inserted_between = {0, 1023}
+
+; Ignore all changes in generated PMD information strings.
+[suppress_variable]
+ name_regex = _pmd_info$
diff --git a/doc/guides/freebsd_gsg/build_dpdk.rst b/doc/guides/freebsd_gsg/build_dpdk.rst
index e3005a7f3..bed353473 100644
--- a/doc/guides/freebsd_gsg/build_dpdk.rst
+++ b/doc/guides/freebsd_gsg/build_dpdk.rst
@@ -14,10 +14,11 @@ The following FreeBSD packages are required to build DPDK:
* meson
* ninja
* pkgconf
+* py37-pyelftools
These can be installed using (as root)::
- pkg install meson pkgconf
+ pkg install meson pkgconf py37-pyelftools
To compile the required kernel modules for memory management and working
with physical NIC devices, the kernel sources for FreeBSD also
diff --git a/doc/guides/linux_gsg/sys_reqs.rst b/doc/guides/linux_gsg/sys_reqs.rst
index be714adf2..a05b5bd81 100644
--- a/doc/guides/linux_gsg/sys_reqs.rst
+++ b/doc/guides/linux_gsg/sys_reqs.rst
@@ -52,6 +52,12 @@ Compilation of the DPDK
* If the packaged version is below the minimum version, the latest versions
can be installed from Python's "pip" repository: ``pip3 install meson ninja``
+* ``pyelftools`` (version 0.22+)
+
+ * For RHEL/Fedora systems it can be installed using ``dnf install python-pyelftools``
+
+ * For Ubuntu/Debian it can be installed using ``apt install python3-pyelftools``
+
* Library for handling NUMA (Non Uniform Memory Access).
* ``numactl-devel`` in RHEL/Fedora;
diff --git a/drivers/meson.build b/drivers/meson.build
index 77f65fa90..ff5cdb952 100644
--- a/drivers/meson.build
+++ b/drivers/meson.build
@@ -132,7 +132,7 @@ foreach subpath:subdirs
command: [pmdinfo, tmp_lib.full_path(),
'@OUTPUT@', pmdinfogen],
output: out_filename,
- depends: [pmdinfogen, tmp_lib])
+ depends: [tmp_lib])
endif
# now build the static driver
diff --git a/meson.build b/meson.build
index 45d974cd2..2b9c37eb4 100644
--- a/meson.build
+++ b/meson.build
@@ -45,7 +45,6 @@ subdir('buildtools')
subdir('config')
# build libs and drivers
-subdir('buildtools/pmdinfogen')
subdir('lib')
subdir('drivers')
--
2.29.2
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [PATCH v8 2/3] build: use Python pmdinfogen
2021-01-23 11:38 4% ` Thomas Monjalon
@ 2021-01-24 20:52 3% ` Dmitry Kozlyuk
2021-01-25 9:25 3% ` Kinsella, Ray
1 sibling, 0 replies; 200+ results
From: Dmitry Kozlyuk @ 2021-01-24 20:52 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev, Stephen Hemminger, David Marchand, Maxime Coquelin,
Aaron Conole, Bruce Richardson, ferruh.yigit, ray.kinsella, mdr
On Sat, 23 Jan 2021 12:38:45 +0100, Thomas Monjalon wrote:
> 22/01/2021 23:24, Dmitry Kozlyuk:
> > On Fri, 22 Jan 2021 21:57:15 +0100, Thomas Monjalon wrote:
> > > 22/01/2021 21:31, Dmitry Kozlyuk:
> > > > On Wed, 20 Jan 2021 11:24:21 +0100, Thomas Monjalon wrote:
> > > > > 20/01/2021 08:23, Dmitry Kozlyuk:
> > > > > > On Wed, 20 Jan 2021 01:05:59 +0100, Thomas Monjalon wrote:
> > > > > > > This is now the right timeframe to introduce this change
> > > > > > > with the new Python module dependency.
> > > > > > > Unfortunately, the ABI check is returning an issue:
> > > > > > >
> > > > > > > 'const char mlx5_common_pci_pmd_info[62]' was changed
> > > > > > > to 'const char mlx5_common_pci_pmd_info[60]' at rte_common_mlx5.pmd.c
> > > > > >
> > > > > > Will investigate and fix ASAP.
> > > >
> > > > Now that I think of it: strings like this change every time new PCI IDs are
> > > > added to a PMD, but AFAIK adding PCI IDs is not considered an ABI breakage,
> > > > is it? One example is 28c9a7d7b48e ("net/mlx5: add ConnectX-6 Lx device ID")
> > > > added 2020-07-08, i.e. clearly outside of ABI change window.
> > >
> > > You're right.
> > >
> > > > "xxx_pmd_info" changes are due to JSON formatting (new is more canonical),
> > > > which can be worked around easily, if the above is wrong.
> > >
> > > If the new format is better, please keep it.
> > > What we need is an exception for the pmdinfo symbols
> > > in the file devtools/libabigail.abignore.
> > > You can probably use a regex for these symbols.
> >
> > This would allow real breakages to pass ABI check, abidiff doesn't analyze
> > variable content and it's not easy to compare. Maybe later a script can be
> > added that checks lines with RTE_DEVICE_IN in patches. There are at most 32 of
> > 5494 relevant commits between 19.11 and 20.11, though.
> >
> > To verify there are no meaningful changes I ensured empty diff between
> > results of the following command for "main" and the branch:
> >
> > find build/drivers -name '*.so' -exec usertools/dpdk-pmdinfo.py
>
> For now we cannot do such check as part of the ABI checker.
> And we cannot merge this patch if the ABI check fails.
> I think the only solution is to allow any change in the pmdinfo variables.
Send v10 with suppression.
Such check, however, *can* be implemented: at ABI check stage we have two
install directories that dpdk-pmdinfo.py can inspect. Then a script can check
that diff contains only additions, i.e. no device support being removed.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v8 2/3] build: use Python pmdinfogen
2021-01-23 11:38 4% ` Thomas Monjalon
2021-01-24 20:52 3% ` Dmitry Kozlyuk
@ 2021-01-25 9:25 3% ` Kinsella, Ray
2021-01-25 10:01 0% ` Kinsella, Ray
2021-01-25 10:05 0% ` Dmitry Kozlyuk
1 sibling, 2 replies; 200+ results
From: Kinsella, Ray @ 2021-01-25 9:25 UTC (permalink / raw)
To: Thomas Monjalon, Dmitry Kozlyuk
Cc: dev, Stephen Hemminger, David Marchand, Maxime Coquelin,
Aaron Conole, Bruce Richardson, ferruh.yigit, ray.kinsella
On 23/01/2021 11:38, Thomas Monjalon wrote:
> 22/01/2021 23:24, Dmitry Kozlyuk:
>> On Fri, 22 Jan 2021 21:57:15 +0100, Thomas Monjalon wrote:
>>> 22/01/2021 21:31, Dmitry Kozlyuk:
>>>> On Wed, 20 Jan 2021 11:24:21 +0100, Thomas Monjalon wrote:
>>>>> 20/01/2021 08:23, Dmitry Kozlyuk:
>>>>>> On Wed, 20 Jan 2021 01:05:59 +0100, Thomas Monjalon wrote:
>>>>>>> This is now the right timeframe to introduce this change
>>>>>>> with the new Python module dependency.
>>>>>>> Unfortunately, the ABI check is returning an issue:
>>>>>>>
>>>>>>> 'const char mlx5_common_pci_pmd_info[62]' was changed
>>>>>>> to 'const char mlx5_common_pci_pmd_info[60]' at rte_common_mlx5.pmd.c
>>>>>>
>>>>>> Will investigate and fix ASAP.
>>>>
>>>> Now that I think of it: strings like this change every time new PCI IDs are
>>>> added to a PMD, but AFAIK adding PCI IDs is not considered an ABI breakage,
>>>> is it? One example is 28c9a7d7b48e ("net/mlx5: add ConnectX-6 Lx device ID")
>>>> added 2020-07-08, i.e. clearly outside of ABI change window.
>>>
>>> You're right.
>>>
>>>> "xxx_pmd_info" changes are due to JSON formatting (new is more canonical),
>>>> which can be worked around easily, if the above is wrong.
>>>
>>> If the new format is better, please keep it.
>>> What we need is an exception for the pmdinfo symbols
>>> in the file devtools/libabigail.abignore.
>>> You can probably use a regex for these symbols.
>>
>> This would allow real breakages to pass ABI check, abidiff doesn't analyze
>> variable content and it's not easy to compare. Maybe later a script can be
>> added that checks lines with RTE_DEVICE_IN in patches. There are at most 32 of
>> 5494 relevant commits between 19.11 and 20.11, though.
>>
>> To verify there are no meaningful changes I ensured empty diff between
>> results of the following command for "main" and the branch:
>>
>> find build/drivers -name '*.so' -exec usertools/dpdk-pmdinfo.py
>
> For now we cannot do such check as part of the ABI checker.
> And we cannot merge this patch if the ABI check fails.
> I think the only solution is to allow any change in the pmdinfo variables.
>
So my 2c on this is that this is an acceptable work-around for the v21 (DPDK v20.11) ABI.
However we are going to end up carrying this rule in libabigail.ignore indefinitely.
Would it make sense to just fix the size of _pmd_info to some reasonably large value -
say 128 bytes, to allow us to drop the rule in the DPDK 21.11 v22 release?
Ray K
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v8 2/3] build: use Python pmdinfogen
2021-01-25 9:25 3% ` Kinsella, Ray
@ 2021-01-25 10:01 0% ` Kinsella, Ray
2021-01-25 10:29 3% ` David Marchand
2021-01-25 10:05 0% ` Dmitry Kozlyuk
1 sibling, 1 reply; 200+ results
From: Kinsella, Ray @ 2021-01-25 10:01 UTC (permalink / raw)
To: dev
On 25/01/2021 09:25, Kinsella, Ray wrote:
>
>
> On 23/01/2021 11:38, Thomas Monjalon wrote:
>> 22/01/2021 23:24, Dmitry Kozlyuk:
>>> On Fri, 22 Jan 2021 21:57:15 +0100, Thomas Monjalon wrote:
>>>> 22/01/2021 21:31, Dmitry Kozlyuk:
>>>>> On Wed, 20 Jan 2021 11:24:21 +0100, Thomas Monjalon wrote:
>>>>>> 20/01/2021 08:23, Dmitry Kozlyuk:
>>>>>>> On Wed, 20 Jan 2021 01:05:59 +0100, Thomas Monjalon wrote:
>>>>>>>> This is now the right timeframe to introduce this change
>>>>>>>> with the new Python module dependency.
>>>>>>>> Unfortunately, the ABI check is returning an issue:
>>>>>>>>
>>>>>>>> 'const char mlx5_common_pci_pmd_info[62]' was changed
>>>>>>>> to 'const char mlx5_common_pci_pmd_info[60]' at rte_common_mlx5.pmd.c
>>>>>>>
>>>>>>> Will investigate and fix ASAP.
>>>>>
>>>>> Now that I think of it: strings like this change every time new PCI IDs are
>>>>> added to a PMD, but AFAIK adding PCI IDs is not considered an ABI breakage,
>>>>> is it? One example is 28c9a7d7b48e ("net/mlx5: add ConnectX-6 Lx device ID")
>>>>> added 2020-07-08, i.e. clearly outside of ABI change window.
>>>>
>>>> You're right.
>>>>
>>>>> "xxx_pmd_info" changes are due to JSON formatting (new is more canonical),
>>>>> which can be worked around easily, if the above is wrong.
>>>>
>>>> If the new format is better, please keep it.
>>>> What we need is an exception for the pmdinfo symbols
>>>> in the file devtools/libabigail.abignore.
>>>> You can probably use a regex for these symbols.
>>>
>>> This would allow real breakages to pass ABI check, abidiff doesn't analyze
>>> variable content and it's not easy to compare. Maybe later a script can be
>>> added that checks lines with RTE_DEVICE_IN in patches. There are at most 32 of
>>> 5494 relevant commits between 19.11 and 20.11, though.
>>>
>>> To verify there are no meaningful changes I ensured empty diff between
>>> results of the following command for "main" and the branch:
>>>
>>> find build/drivers -name '*.so' -exec usertools/dpdk-pmdinfo.py
>>
>> For now we cannot do such check as part of the ABI checker.
>> And we cannot merge this patch if the ABI check fails.
>> I think the only solution is to allow any change in the pmdinfo variables.
>>
>
> So my 2c on this is that this is an acceptable work-around for the v21 (DPDK v20.11) ABI.
> However we are going to end up carrying this rule in libabigail.ignore indefinitely.
>
> Would it make sense to just fix the size of _pmd_info to some reasonably large value -
> say 128 bytes, to allow us to drop the rule in the DPDK 21.11 v22 release?
>
> Ray K
Another point is - shouldn't _pmd_info probably live in "INTERNAL" is anycase?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v8 2/3] build: use Python pmdinfogen
2021-01-25 9:25 3% ` Kinsella, Ray
2021-01-25 10:01 0% ` Kinsella, Ray
@ 2021-01-25 10:05 0% ` Dmitry Kozlyuk
2021-01-25 10:11 4% ` Kinsella, Ray
1 sibling, 1 reply; 200+ results
From: Dmitry Kozlyuk @ 2021-01-25 10:05 UTC (permalink / raw)
To: Kinsella, Ray
Cc: Thomas Monjalon, dev, Stephen Hemminger, David Marchand,
Maxime Coquelin, Aaron Conole, Bruce Richardson, ferruh.yigit,
ray.kinsella
On Mon, 25 Jan 2021 09:25:51 +0000, Kinsella, Ray wrote:
> On 23/01/2021 11:38, Thomas Monjalon wrote:
> > 22/01/2021 23:24, Dmitry Kozlyuk:
> >> On Fri, 22 Jan 2021 21:57:15 +0100, Thomas Monjalon wrote:
> >>> 22/01/2021 21:31, Dmitry Kozlyuk:
> >>>> On Wed, 20 Jan 2021 11:24:21 +0100, Thomas Monjalon wrote:
> >>>>> 20/01/2021 08:23, Dmitry Kozlyuk:
> >>>>>> On Wed, 20 Jan 2021 01:05:59 +0100, Thomas Monjalon wrote:
> >>>>>>> This is now the right timeframe to introduce this change
> >>>>>>> with the new Python module dependency.
> >>>>>>> Unfortunately, the ABI check is returning an issue:
> >>>>>>>
> >>>>>>> 'const char mlx5_common_pci_pmd_info[62]' was changed
> >>>>>>> to 'const char mlx5_common_pci_pmd_info[60]' at rte_common_mlx5.pmd.c
> >>>>>>
> >>>>>> Will investigate and fix ASAP.
> >>>>
> >>>> Now that I think of it: strings like this change every time new PCI IDs are
> >>>> added to a PMD, but AFAIK adding PCI IDs is not considered an ABI breakage,
> >>>> is it? One example is 28c9a7d7b48e ("net/mlx5: add ConnectX-6 Lx device ID")
> >>>> added 2020-07-08, i.e. clearly outside of ABI change window.
> >>>
> >>> You're right.
> >>>
> >>>> "xxx_pmd_info" changes are due to JSON formatting (new is more canonical),
> >>>> which can be worked around easily, if the above is wrong.
> >>>
> >>> If the new format is better, please keep it.
> >>> What we need is an exception for the pmdinfo symbols
> >>> in the file devtools/libabigail.abignore.
> >>> You can probably use a regex for these symbols.
> >>
> >> This would allow real breakages to pass ABI check, abidiff doesn't analyze
> >> variable content and it's not easy to compare. Maybe later a script can be
> >> added that checks lines with RTE_DEVICE_IN in patches. There are at most 32 of
> >> 5494 relevant commits between 19.11 and 20.11, though.
> >>
> >> To verify there are no meaningful changes I ensured empty diff between
> >> results of the following command for "main" and the branch:
> >>
> >> find build/drivers -name '*.so' -exec usertools/dpdk-pmdinfo.py
> >
> > For now we cannot do such check as part of the ABI checker.
> > And we cannot merge this patch if the ABI check fails.
> > I think the only solution is to allow any change in the pmdinfo variables.
> >
>
> So my 2c on this is that this is an acceptable work-around for the v21 (DPDK v20.11) ABI.
> However we are going to end up carrying this rule in libabigail.ignore indefinitely.
>
> Would it make sense to just fix the size of _pmd_info to some reasonably large value -
> say 128 bytes, to allow us to drop the rule in the DPDK 21.11 v22 release?
I don't think so. This is a JSON *string to be parsed;* considering its size
as part of application *binary* interface is wrong in the first place. As for
content, checking that no PCI IDs are removed is out of scope for libabigail
anyway. Technically we could fix _pmd_info size, but this still allows
breaking changes to pass the check with no benefit.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v8 2/3] build: use Python pmdinfogen
2021-01-25 10:05 0% ` Dmitry Kozlyuk
@ 2021-01-25 10:11 4% ` Kinsella, Ray
2021-01-25 10:31 0% ` Dmitry Kozlyuk
0 siblings, 1 reply; 200+ results
From: Kinsella, Ray @ 2021-01-25 10:11 UTC (permalink / raw)
To: Dmitry Kozlyuk
Cc: Thomas Monjalon, dev, Stephen Hemminger, David Marchand,
Maxime Coquelin, Aaron Conole, Bruce Richardson, ferruh.yigit,
ray.kinsella
On 25/01/2021 10:05, Dmitry Kozlyuk wrote:
> On Mon, 25 Jan 2021 09:25:51 +0000, Kinsella, Ray wrote:
>> On 23/01/2021 11:38, Thomas Monjalon wrote:
>>> 22/01/2021 23:24, Dmitry Kozlyuk:
>>>> On Fri, 22 Jan 2021 21:57:15 +0100, Thomas Monjalon wrote:
>>>>> 22/01/2021 21:31, Dmitry Kozlyuk:
>>>>>> On Wed, 20 Jan 2021 11:24:21 +0100, Thomas Monjalon wrote:
>>>>>>> 20/01/2021 08:23, Dmitry Kozlyuk:
>>>>>>>> On Wed, 20 Jan 2021 01:05:59 +0100, Thomas Monjalon wrote:
>>>>>>>>> This is now the right timeframe to introduce this change
>>>>>>>>> with the new Python module dependency.
>>>>>>>>> Unfortunately, the ABI check is returning an issue:
>>>>>>>>>
>>>>>>>>> 'const char mlx5_common_pci_pmd_info[62]' was changed
>>>>>>>>> to 'const char mlx5_common_pci_pmd_info[60]' at rte_common_mlx5.pmd.c
>>>>>>>>
>>>>>>>> Will investigate and fix ASAP.
>>>>>>
>>>>>> Now that I think of it: strings like this change every time new PCI IDs are
>>>>>> added to a PMD, but AFAIK adding PCI IDs is not considered an ABI breakage,
>>>>>> is it? One example is 28c9a7d7b48e ("net/mlx5: add ConnectX-6 Lx device ID")
>>>>>> added 2020-07-08, i.e. clearly outside of ABI change window.
>>>>>
>>>>> You're right.
>>>>>
>>>>>> "xxx_pmd_info" changes are due to JSON formatting (new is more canonical),
>>>>>> which can be worked around easily, if the above is wrong.
>>>>>
>>>>> If the new format is better, please keep it.
>>>>> What we need is an exception for the pmdinfo symbols
>>>>> in the file devtools/libabigail.abignore.
>>>>> You can probably use a regex for these symbols.
>>>>
>>>> This would allow real breakages to pass ABI check, abidiff doesn't analyze
>>>> variable content and it's not easy to compare. Maybe later a script can be
>>>> added that checks lines with RTE_DEVICE_IN in patches. There are at most 32 of
>>>> 5494 relevant commits between 19.11 and 20.11, though.
>>>>
>>>> To verify there are no meaningful changes I ensured empty diff between
>>>> results of the following command for "main" and the branch:
>>>>
>>>> find build/drivers -name '*.so' -exec usertools/dpdk-pmdinfo.py
>>>
>>> For now we cannot do such check as part of the ABI checker.
>>> And we cannot merge this patch if the ABI check fails.
>>> I think the only solution is to allow any change in the pmdinfo variables.
>>>
>>
>> So my 2c on this is that this is an acceptable work-around for the v21 (DPDK v20.11) ABI.
>> However we are going to end up carrying this rule in libabigail.ignore indefinitely.
>>
>> Would it make sense to just fix the size of _pmd_info to some reasonably large value -
>> say 128 bytes, to allow us to drop the rule in the DPDK 21.11 v22 release?
>
> I don't think so. This is a JSON *string to be parsed;* considering its size
> as part of application *binary* interface is wrong in the first place.
Right - then is belongs in INTERNAL, I would say.
> As for
> content, checking that no PCI IDs are removed is out of scope for libabigail
> anyway.
Lets be clear PCI IDs - are _nothing_ to do with ABI.
> Technically we could fix _pmd_info size, but this still allows
> breaking changes to pass the check with no benefit.
ABI changes or other, please explain?
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v8 2/3] build: use Python pmdinfogen
2021-01-25 10:01 0% ` Kinsella, Ray
@ 2021-01-25 10:29 3% ` David Marchand
2021-01-25 10:46 0% ` Kinsella, Ray
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2021-01-25 10:29 UTC (permalink / raw)
To: Kinsella, Ray; +Cc: dev, Thomas Monjalon, Dmitry Kozlyuk
On Mon, Jan 25, 2021 at 11:01 AM Kinsella, Ray <mdr@ashroe.eu> wrote:
>
>
>
> On 25/01/2021 09:25, Kinsella, Ray wrote:
> >
> >
> > On 23/01/2021 11:38, Thomas Monjalon wrote:
> >> 22/01/2021 23:24, Dmitry Kozlyuk:
> >>> On Fri, 22 Jan 2021 21:57:15 +0100, Thomas Monjalon wrote:
> >>>> 22/01/2021 21:31, Dmitry Kozlyuk:
> >>>>> On Wed, 20 Jan 2021 11:24:21 +0100, Thomas Monjalon wrote:
> >>>>>> 20/01/2021 08:23, Dmitry Kozlyuk:
> >>>>>>> On Wed, 20 Jan 2021 01:05:59 +0100, Thomas Monjalon wrote:
> >>>>>>>> This is now the right timeframe to introduce this change
> >>>>>>>> with the new Python module dependency.
> >>>>>>>> Unfortunately, the ABI check is returning an issue:
> >>>>>>>>
> >>>>>>>> 'const char mlx5_common_pci_pmd_info[62]' was changed
> >>>>>>>> to 'const char mlx5_common_pci_pmd_info[60]' at rte_common_mlx5.pmd.c
> >>>>>>>
> >>>>>>> Will investigate and fix ASAP.
> >>>>>
> >>>>> Now that I think of it: strings like this change every time new PCI IDs are
> >>>>> added to a PMD, but AFAIK adding PCI IDs is not considered an ABI breakage,
> >>>>> is it? One example is 28c9a7d7b48e ("net/mlx5: add ConnectX-6 Lx device ID")
> >>>>> added 2020-07-08, i.e. clearly outside of ABI change window.
> >>>>
> >>>> You're right.
> >>>>
> >>>>> "xxx_pmd_info" changes are due to JSON formatting (new is more canonical),
> >>>>> which can be worked around easily, if the above is wrong.
> >>>>
> >>>> If the new format is better, please keep it.
> >>>> What we need is an exception for the pmdinfo symbols
> >>>> in the file devtools/libabigail.abignore.
> >>>> You can probably use a regex for these symbols.
> >>>
> >>> This would allow real breakages to pass ABI check, abidiff doesn't analyze
> >>> variable content and it's not easy to compare. Maybe later a script can be
> >>> added that checks lines with RTE_DEVICE_IN in patches. There are at most 32 of
> >>> 5494 relevant commits between 19.11 and 20.11, though.
> >>>
> >>> To verify there are no meaningful changes I ensured empty diff between
> >>> results of the following command for "main" and the branch:
> >>>
> >>> find build/drivers -name '*.so' -exec usertools/dpdk-pmdinfo.py
> >>
> >> For now we cannot do such check as part of the ABI checker.
> >> And we cannot merge this patch if the ABI check fails.
> >> I think the only solution is to allow any change in the pmdinfo variables.
> >>
> >
> > So my 2c on this is that this is an acceptable work-around for the v21 (DPDK v20.11) ABI.
> > However we are going to end up carrying this rule in libabigail.ignore indefinitely.
> >
> > Would it make sense to just fix the size of _pmd_info to some reasonably large value -
> > say 128 bytes, to allow us to drop the rule in the DPDK 21.11 v22 release?
> >
> > Ray K
>
>
> Another point is - shouldn't _pmd_info probably live in "INTERNAL" is anycase?
The symbol itself can be hidden from the ABeyes.
It is only a placeholder for the PMD_INFO_STRING= string used by
usertools/dpdk-pmdinfo.py and maybe some other parsing tool.
I guess a static symbol would be enough:
diff --git a/buildtools/pmdinfogen/pmdinfogen.c
b/buildtools/pmdinfogen/pmdinfogen.c
index a68d1ea999..14bf7d9f42 100644
--- a/buildtools/pmdinfogen/pmdinfogen.c
+++ b/buildtools/pmdinfogen/pmdinfogen.c
@@ -393,7 +393,7 @@ static void output_pmd_info_string(struct elf_info
*info, char *outfile)
drv = info->drivers;
while (drv) {
- fprintf(ofd, "const char %s_pmd_info[] __attribute__((used)) = "
+ fprintf(ofd, "static const char %s_pmd_info[]
__attribute__((used)) = "
"\"PMD_INFO_STRING= {",
drv->name);
fprintf(ofd, "\\\"name\\\" : \\\"%s\\\", ", drv->name);
We will need an exception for the v21 ABI though.
--
David Marchand
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v8 2/3] build: use Python pmdinfogen
2021-01-25 10:11 4% ` Kinsella, Ray
@ 2021-01-25 10:31 0% ` Dmitry Kozlyuk
0 siblings, 0 replies; 200+ results
From: Dmitry Kozlyuk @ 2021-01-25 10:31 UTC (permalink / raw)
To: Kinsella, Ray
Cc: Thomas Monjalon, dev, Stephen Hemminger, David Marchand,
Maxime Coquelin, Aaron Conole, Bruce Richardson, ferruh.yigit,
ray.kinsella
On Mon, 25 Jan 2021 10:11:07 +0000, Kinsella, Ray wrote:
> On 25/01/2021 10:05, Dmitry Kozlyuk wrote:
> > On Mon, 25 Jan 2021 09:25:51 +0000, Kinsella, Ray wrote:
> >> On 23/01/2021 11:38, Thomas Monjalon wrote:
> >>> 22/01/2021 23:24, Dmitry Kozlyuk:
> >>>> On Fri, 22 Jan 2021 21:57:15 +0100, Thomas Monjalon wrote:
> >>>>> 22/01/2021 21:31, Dmitry Kozlyuk:
> >>>>>> On Wed, 20 Jan 2021 11:24:21 +0100, Thomas Monjalon wrote:
> >>>>>>> 20/01/2021 08:23, Dmitry Kozlyuk:
> >>>>>>>> On Wed, 20 Jan 2021 01:05:59 +0100, Thomas Monjalon wrote:
> >>>>>>>>> This is now the right timeframe to introduce this change
> >>>>>>>>> with the new Python module dependency.
> >>>>>>>>> Unfortunately, the ABI check is returning an issue:
> >>>>>>>>>
> >>>>>>>>> 'const char mlx5_common_pci_pmd_info[62]' was changed
> >>>>>>>>> to 'const char mlx5_common_pci_pmd_info[60]' at rte_common_mlx5.pmd.c
> >>>>>>>>
> >>>>>>>> Will investigate and fix ASAP.
> >>>>>>
> >>>>>> Now that I think of it: strings like this change every time new PCI IDs are
> >>>>>> added to a PMD, but AFAIK adding PCI IDs is not considered an ABI breakage,
> >>>>>> is it? One example is 28c9a7d7b48e ("net/mlx5: add ConnectX-6 Lx device ID")
> >>>>>> added 2020-07-08, i.e. clearly outside of ABI change window.
> >>>>>
> >>>>> You're right.
> >>>>>
> >>>>>> "xxx_pmd_info" changes are due to JSON formatting (new is more canonical),
> >>>>>> which can be worked around easily, if the above is wrong.
> >>>>>
> >>>>> If the new format is better, please keep it.
> >>>>> What we need is an exception for the pmdinfo symbols
> >>>>> in the file devtools/libabigail.abignore.
> >>>>> You can probably use a regex for these symbols.
> >>>>
> >>>> This would allow real breakages to pass ABI check, abidiff doesn't analyze
> >>>> variable content and it's not easy to compare. Maybe later a script can be
> >>>> added that checks lines with RTE_DEVICE_IN in patches. There are at most 32 of
> >>>> 5494 relevant commits between 19.11 and 20.11, though.
> >>>>
> >>>> To verify there are no meaningful changes I ensured empty diff between
> >>>> results of the following command for "main" and the branch:
> >>>>
> >>>> find build/drivers -name '*.so' -exec usertools/dpdk-pmdinfo.py
> >>>
> >>> For now we cannot do such check as part of the ABI checker.
> >>> And we cannot merge this patch if the ABI check fails.
> >>> I think the only solution is to allow any change in the pmdinfo variables.
> >>>
> >>
> >> So my 2c on this is that this is an acceptable work-around for the v21 (DPDK v20.11) ABI.
> >> However we are going to end up carrying this rule in libabigail.ignore indefinitely.
> >>
> >> Would it make sense to just fix the size of _pmd_info to some reasonably large value -
> >> say 128 bytes, to allow us to drop the rule in the DPDK 21.11 v22 release?
> >
> > I don't think so. This is a JSON *string to be parsed;* considering its size
> > as part of application *binary* interface is wrong in the first place.
>
> Right - then is belongs in INTERNAL, I would say.
>
> > As for
> > content, checking that no PCI IDs are removed is out of scope for libabigail
> > anyway.
>
> Lets be clear PCI IDs - are _nothing_ to do with ABI.
Technically, yes, but they're referred to in abi_policy.rst, because DPDK
behavior depends on them. Same issue as with as return values: no formats
change, yet compatibility is broken.
> > Technically we could fix _pmd_info size, but this still allows
> > breaking changes to pass the check with no benefit.
>
> ABI changes or other, please explain?
Behavioral changes via PCI ID removal, see above.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v8 2/3] build: use Python pmdinfogen
2021-01-25 10:29 3% ` David Marchand
@ 2021-01-25 10:46 0% ` Kinsella, Ray
2021-01-25 11:03 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Kinsella, Ray @ 2021-01-25 10:46 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Thomas Monjalon, Dmitry Kozlyuk
On 25/01/2021 10:29, David Marchand wrote:
> On Mon, Jan 25, 2021 at 11:01 AM Kinsella, Ray <mdr@ashroe.eu> wrote:
>>
>>
>>
>> On 25/01/2021 09:25, Kinsella, Ray wrote:
>>>
>>>
>>> On 23/01/2021 11:38, Thomas Monjalon wrote:
>>>> 22/01/2021 23:24, Dmitry Kozlyuk:
>>>>> On Fri, 22 Jan 2021 21:57:15 +0100, Thomas Monjalon wrote:
>>>>>> 22/01/2021 21:31, Dmitry Kozlyuk:
>>>>>>> On Wed, 20 Jan 2021 11:24:21 +0100, Thomas Monjalon wrote:
>>>>>>>> 20/01/2021 08:23, Dmitry Kozlyuk:
>>>>>>>>> On Wed, 20 Jan 2021 01:05:59 +0100, Thomas Monjalon wrote:
>>>>>>>>>> This is now the right timeframe to introduce this change
>>>>>>>>>> with the new Python module dependency.
>>>>>>>>>> Unfortunately, the ABI check is returning an issue:
>>>>>>>>>>
>>>>>>>>>> 'const char mlx5_common_pci_pmd_info[62]' was changed
>>>>>>>>>> to 'const char mlx5_common_pci_pmd_info[60]' at rte_common_mlx5.pmd.c
>>>>>>>>>
>>>>>>>>> Will investigate and fix ASAP.
>>>>>>>
>>>>>>> Now that I think of it: strings like this change every time new PCI IDs are
>>>>>>> added to a PMD, but AFAIK adding PCI IDs is not considered an ABI breakage,
>>>>>>> is it? One example is 28c9a7d7b48e ("net/mlx5: add ConnectX-6 Lx device ID")
>>>>>>> added 2020-07-08, i.e. clearly outside of ABI change window.
>>>>>>
>>>>>> You're right.
>>>>>>
>>>>>>> "xxx_pmd_info" changes are due to JSON formatting (new is more canonical),
>>>>>>> which can be worked around easily, if the above is wrong.
>>>>>>
>>>>>> If the new format is better, please keep it.
>>>>>> What we need is an exception for the pmdinfo symbols
>>>>>> in the file devtools/libabigail.abignore.
>>>>>> You can probably use a regex for these symbols.
>>>>>
>>>>> This would allow real breakages to pass ABI check, abidiff doesn't analyze
>>>>> variable content and it's not easy to compare. Maybe later a script can be
>>>>> added that checks lines with RTE_DEVICE_IN in patches. There are at most 32 of
>>>>> 5494 relevant commits between 19.11 and 20.11, though.
>>>>>
>>>>> To verify there are no meaningful changes I ensured empty diff between
>>>>> results of the following command for "main" and the branch:
>>>>>
>>>>> find build/drivers -name '*.so' -exec usertools/dpdk-pmdinfo.py
>>>>
>>>> For now we cannot do such check as part of the ABI checker.
>>>> And we cannot merge this patch if the ABI check fails.
>>>> I think the only solution is to allow any change in the pmdinfo variables.
>>>>
>>>
>>> So my 2c on this is that this is an acceptable work-around for the v21 (DPDK v20.11) ABI.
>>> However we are going to end up carrying this rule in libabigail.ignore indefinitely.
>>>
>>> Would it make sense to just fix the size of _pmd_info to some reasonably large value -
>>> say 128 bytes, to allow us to drop the rule in the DPDK 21.11 v22 release?
>>>
>>> Ray K
>>
>>
>> Another point is - shouldn't _pmd_info probably live in "INTERNAL" is anycase?
>
> The symbol itself can be hidden from the ABeyes.
> It is only a placeholder for the PMD_INFO_STRING= string used by
> usertools/dpdk-pmdinfo.py and maybe some other parsing tool.
>
> I guess a static symbol would be enough:
>
> diff --git a/buildtools/pmdinfogen/pmdinfogen.c
> b/buildtools/pmdinfogen/pmdinfogen.c
> index a68d1ea999..14bf7d9f42 100644
> --- a/buildtools/pmdinfogen/pmdinfogen.c
> +++ b/buildtools/pmdinfogen/pmdinfogen.c
> @@ -393,7 +393,7 @@ static void output_pmd_info_string(struct elf_info
> *info, char *outfile)
> drv = info->drivers;
>
> while (drv) {
> - fprintf(ofd, "const char %s_pmd_info[] __attribute__((used)) = "
> + fprintf(ofd, "static const char %s_pmd_info[]
> __attribute__((used)) = "
> "\"PMD_INFO_STRING= {",
> drv->name);
> fprintf(ofd, "\\\"name\\\" : \\\"%s\\\", ", drv->name);
>
>
> We will need an exception for the v21 ABI though.
>
Good suggestion +1
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v8 2/3] build: use Python pmdinfogen
2021-01-25 10:46 0% ` Kinsella, Ray
@ 2021-01-25 11:03 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2021-01-25 11:03 UTC (permalink / raw)
To: David Marchand; +Cc: Kinsella, Ray, dev, Dmitry Kozlyuk
25/01/2021 11:46, Kinsella, Ray:
> On 25/01/2021 10:29, David Marchand wrote:
> > The symbol itself can be hidden from the ABeyes.
> > It is only a placeholder for the PMD_INFO_STRING= string used by
> > usertools/dpdk-pmdinfo.py and maybe some other parsing tool.
> >
> > I guess a static symbol would be enough:
> >
> > diff --git a/buildtools/pmdinfogen/pmdinfogen.c
> > b/buildtools/pmdinfogen/pmdinfogen.c
> > index a68d1ea999..14bf7d9f42 100644
> > --- a/buildtools/pmdinfogen/pmdinfogen.c
> > +++ b/buildtools/pmdinfogen/pmdinfogen.c
> > @@ -393,7 +393,7 @@ static void output_pmd_info_string(struct elf_info
> > *info, char *outfile)
> > drv = info->drivers;
> >
> > while (drv) {
> > - fprintf(ofd, "const char %s_pmd_info[] __attribute__((used)) = "
> > + fprintf(ofd, "static const char %s_pmd_info[]
> > __attribute__((used)) = "
> > "\"PMD_INFO_STRING= {",
> > drv->name);
> > fprintf(ofd, "\\\"name\\\" : \\\"%s\\\", ", drv->name);
> >
> >
> > We will need an exception for the v21 ABI though.
> >
>
> Good suggestion +1
Yes +1 for adding static on *_pmd_info
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3 0/4] add checking of header includes
@ 2021-01-25 15:51 2% ` David Marchand
2021-01-25 18:17 0% ` Bruce Richardson
2021-01-26 11:15 4% ` Bruce Richardson
0 siblings, 2 replies; 200+ results
From: David Marchand @ 2021-01-25 15:51 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev, Thomas Monjalon
On Mon, Jan 25, 2021 at 3:11 PM Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> As a general principle, each header file should include any other
> headers it needs to provide data type definitions or macros. For
> example, any header using the uintX_t types in structures or function
> prototypes should include "stdint.h" to provide those type definitions.
>
> In practice, while many, but not all, headers in DPDK did include all
> necessary headers, it was never actually checked that each header could
> be included in a C file and compiled without having any compiler errors
> about missing definitions. The script "check-includes.sh" could be used
> for this job, but it was not called out in the documentation, so many
> contributors may not have been aware of it's existance. It also was
> difficult to run from a source-code directory, as the script did not
> automatically allow finding of headers from one DPDK library directory
> to another [this was probably based on running it on a build created by
> the "make" build system, where all headers were in a single directory].
> To attempt to have a build-system integrated replacement, this patchset
> adds a "chkincs" app in the buildtools directory to verify this on an
> ongoing basis.
>
> This chkincs app does nothing when run, and is not installed as part of
> a DPDK "ninja install", it's for build-time checking only. Its source
> code consists of one C file per public DPDK header, where that C file
> contains nothing except an include for that header. Therefore, if any
> header is added to the lib folder which fails to compile when included
> alone, the build of chkincs will fail with a suitable error message.
> Since this compile checking is not needed on most builds of DPDK, the
> building of chkincs is disabled by default, but can be enabled by the
> "test_includes" meson option. To catch errors with patch submissions,
> the final patch of this series enables it for a single build in
> test-meson-builds script.
>
> Future work could involve doing similar checks on headers for C++
> compatibility, which was something done by the check-includes.sh script
> but which is missing here..
>
> V3:
> * Shrunk patchset as most header fixes already applied
> * Moved chkincs from "apps" to the "buildtools" directory, which is a
> better location for something not for installation for end-user use.
> * Added patch to drop check-includes script.
>
> V2:
> * Add maintainers file entry for new app
> * Drop patch for c11 ring header
> * Use build variable "headers_no_chkincs" for tracking exceptions
>
> Bruce Richardson (4):
> eal: add missing include to mcslock
> build: separate out headers for include checking
> buildtools/chkincs: add app to verify header includes
> devtools: remove check-includes script
>
> MAINTAINERS | 5 +-
> buildtools/chkincs/gen_c_file_for_header.py | 12 +
> buildtools/chkincs/main.c | 4 +
> buildtools/chkincs/meson.build | 40 +++
> devtools/check-includes.sh | 259 -------------------
> devtools/test-meson-builds.sh | 2 +-
> doc/guides/contributing/coding_style.rst | 12 +
> lib/librte_eal/include/generic/rte_mcslock.h | 1 +
> lib/librte_eal/include/meson.build | 2 +-
> lib/librte_eal/x86/include/meson.build | 14 +-
> lib/librte_ethdev/meson.build | 4 +-
> lib/librte_hash/meson.build | 4 +-
> lib/librte_ipsec/meson.build | 3 +-
> lib/librte_lpm/meson.build | 2 +-
> lib/librte_regexdev/meson.build | 2 +-
> lib/librte_ring/meson.build | 4 +-
> lib/librte_stack/meson.build | 4 +-
> lib/librte_table/meson.build | 7 +-
> lib/meson.build | 3 +
> meson.build | 6 +
> meson_options.txt | 2 +
> 21 files changed, 112 insertions(+), 280 deletions(-)
> create mode 100755 buildtools/chkincs/gen_c_file_for_header.py
> create mode 100644 buildtools/chkincs/main.c
> create mode 100644 buildtools/chkincs/meson.build
> delete mode 100755 devtools/check-includes.sh
- clang is not happy when enabling the check:
$ meson configure $HOME/builds/build-clang-static -Dcheck_includes=true
$ devtools/test-meson-builds.sh
...
[362/464] Compiling C object
buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_vdev.c.o
FAILED: buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_vdev.c.o
clang -Ibuildtools/chkincs/chkincs.p -Ibuildtools/chkincs
-I../../dpdk/buildtools/chkincs -Idrivers/bus/pci
-I../../dpdk/drivers/bus/pci -Idrivers/bus/vdev
-I../../dpdk/drivers/bus/vdev -I. -I../../dpdk -Iconfig
-I../../dpdk/config -Ilib/librte_eal/include
-I../../dpdk/lib/librte_eal/include -Ilib/librte_eal/linux/include
-I../../dpdk/lib/librte_eal/linux/include -Ilib/librte_eal/x86/include
-I../../dpdk/lib/librte_eal/x86/include -Ilib/librte_kvargs
-I../../dpdk/lib/librte_kvargs -Ilib/librte_metrics
-I../../dpdk/lib/librte_metrics -Ilib/librte_telemetry
-I../../dpdk/lib/librte_telemetry -Ilib/librte_eal/common
-I../../dpdk/lib/librte_eal/common -Ilib/librte_eal
-I../../dpdk/lib/librte_eal -Ilib/librte_ring
-I../../dpdk/lib/librte_ring -Ilib/librte_rcu
-I../../dpdk/lib/librte_rcu -Ilib/librte_mempool
-I../../dpdk/lib/librte_mempool -Ilib/librte_mbuf
-I../../dpdk/lib/librte_mbuf -Ilib/librte_net
-I../../dpdk/lib/librte_net -Ilib/librte_meter
-I../../dpdk/lib/librte_meter -Ilib/librte_ethdev
-I../../dpdk/lib/librte_ethdev -Ilib/librte_pci
-I../../dpdk/lib/librte_pci -Ilib/librte_cmdline
-I../../dpdk/lib/librte_cmdline -Ilib/librte_hash
-I../../dpdk/lib/librte_hash -Ilib/librte_timer
-I../../dpdk/lib/librte_timer -Ilib/librte_acl
-I../../dpdk/lib/librte_acl -Ilib/librte_bbdev
-I../../dpdk/lib/librte_bbdev -Ilib/librte_bitratestats
-I../../dpdk/lib/librte_bitratestats -Ilib/librte_cfgfile
-I../../dpdk/lib/librte_cfgfile -Ilib/librte_compressdev
-I../../dpdk/lib/librte_compressdev -Ilib/librte_cryptodev
-I../../dpdk/lib/librte_cryptodev -Ilib/librte_distributor
-I../../dpdk/lib/librte_distributor -Ilib/librte_efd
-I../../dpdk/lib/librte_efd -Ilib/librte_eventdev
-I../../dpdk/lib/librte_eventdev -Ilib/librte_gro
-I../../dpdk/lib/librte_gro -Ilib/librte_gso
-I../../dpdk/lib/librte_gso -Ilib/librte_ip_frag
-I../../dpdk/lib/librte_ip_frag -Ilib/librte_jobstats
-I../../dpdk/lib/librte_jobstats -Ilib/librte_kni
-I../../dpdk/lib/librte_kni -Ilib/librte_latencystats
-I../../dpdk/lib/librte_latencystats -Ilib/librte_lpm
-I../../dpdk/lib/librte_lpm -Ilib/librte_member
-I../../dpdk/lib/librte_member -Ilib/librte_power
-I../../dpdk/lib/librte_power -Ilib/librte_pdump
-I../../dpdk/lib/librte_pdump -Ilib/librte_rawdev
-I../../dpdk/lib/librte_rawdev -Ilib/librte_regexdev
-I../../dpdk/lib/librte_regexdev -Ilib/librte_rib
-I../../dpdk/lib/librte_rib -Ilib/librte_reorder
-I../../dpdk/lib/librte_reorder -Ilib/librte_sched
-I../../dpdk/lib/librte_sched -Ilib/librte_security
-I../../dpdk/lib/librte_security -Ilib/librte_stack
-I../../dpdk/lib/librte_stack -Ilib/librte_vhost
-I../../dpdk/lib/librte_vhost -Ilib/librte_ipsec
-I../../dpdk/lib/librte_ipsec -Ilib/librte_fib
-I../../dpdk/lib/librte_fib -Ilib/librte_port
-I../../dpdk/lib/librte_port -Ilib/librte_table
-I../../dpdk/lib/librte_table -Ilib/librte_pipeline
-I../../dpdk/lib/librte_pipeline -Ilib/librte_flow_classify
-I../../dpdk/lib/librte_flow_classify -Ilib/librte_bpf
-I../../dpdk/lib/librte_bpf -Ilib/librte_graph
-I../../dpdk/lib/librte_graph -Ilib/librte_node
-I../../dpdk/lib/librte_node
-I/home/dmarchan/intel-ipsec-mb/install/include -Xclang
-fcolor-diagnostics -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
-Werror -O2 -g -include rte_config.h -Wextra -Wcast-qual -Wdeprecated
-Wformat -Wformat-nonliteral -Wformat-security -Wmissing-declarations
-Wmissing-prototypes -Wnested-externs -Wold-style-definition
-Wpointer-arith -Wsign-compare -Wstrict-prototypes -Wundef
-Wwrite-strings -Wno-address-of-packed-member
-Wno-missing-field-initializers -D_GNU_SOURCE -march=native
-Wno-unused-function -DALLOW_EXPERIMENTAL_API -MD -MQ
buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_vdev.c.o -MF
buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_vdev.c.o.d -o
buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_vdev.c.o -c
buildtools/chkincs/chkincs.p/rte_ethdev_vdev.c
In file included from buildtools/chkincs/chkincs.p/rte_ethdev_vdev.c:1:
In file included from
/home/dmarchan/dpdk/lib/librte_ethdev/rte_ethdev_vdev.h:12:
../../dpdk/lib/librte_ethdev/rte_ethdev_driver.h:964:1: error: unknown
attribute 'error' ignored [-Werror,-Wunknown-attributes]
__rte_internal
^
../../dpdk/lib/librte_eal/include/rte_compat.h:25:16: note: expanded
from macro '__rte_internal'
__attribute__((error("Symbol is not public ABI"), \
^
- Other issues with ARM builds (arch-specific headers probably the reason):
$ meson configure $HOME/builds/build-arm64-bluefield -Dcheck_includes=true
$ devtools/test-meson-builds.sh
...
In file included from buildtools/chkincs/chkincs.p/rte_rib6.c:1:
/home/dmarchan/dpdk/lib/librte_rib/rte_rib6.h: In function ‘get_msk_part’:
/home/dmarchan/dpdk/lib/librte_rib/rte_rib6.h:112:10: error: implicit
declaration of function ‘RTE_MIN’; did you mean ‘INT8_MIN’?
[-Werror=implicit-function-declaration]
depth = RTE_MIN(depth, 128);
^~~~~~~
INT8_MIN
/home/dmarchan/dpdk/lib/librte_rib/rte_rib6.h:112:10: error: nested
extern declaration of ‘RTE_MIN’ [-Werror=nested-externs]
/home/dmarchan/dpdk/lib/librte_rib/rte_rib6.h:113:9: error: implicit
declaration of function ‘RTE_MAX’; did you mean ‘INT8_MAX’?
[-Werror=implicit-function-declaration]
part = RTE_MAX((int16_t)depth - (byte * 8), 0);
^~~~~~~
INT8_MAX
/home/dmarchan/dpdk/lib/librte_rib/rte_rib6.h:113:9: error: nested
extern declaration of ‘RTE_MAX’ [-Werror=nested-externs]
cc1: all warnings being treated as errors
- This check should be enabled for x86 and aarch cross build in GHA.
--
David Marchand
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [PATCH v3 0/4] add checking of header includes
2021-01-25 15:51 2% ` David Marchand
@ 2021-01-25 18:17 0% ` Bruce Richardson
2021-01-26 11:15 4% ` Bruce Richardson
1 sibling, 0 replies; 200+ results
From: Bruce Richardson @ 2021-01-25 18:17 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Thomas Monjalon
On Mon, Jan 25, 2021 at 04:51:19PM +0100, David Marchand wrote:
> On Mon, Jan 25, 2021 at 3:11 PM Bruce Richardson
> <bruce.richardson@intel.com> wrote:
> >
> > As a general principle, each header file should include any other
> > headers it needs to provide data type definitions or macros. For
> > example, any header using the uintX_t types in structures or function
> > prototypes should include "stdint.h" to provide those type definitions.
> >
> > In practice, while many, but not all, headers in DPDK did include all
> > necessary headers, it was never actually checked that each header could
> > be included in a C file and compiled without having any compiler errors
> > about missing definitions. The script "check-includes.sh" could be used
> > for this job, but it was not called out in the documentation, so many
> > contributors may not have been aware of it's existance. It also was
> > difficult to run from a source-code directory, as the script did not
> > automatically allow finding of headers from one DPDK library directory
> > to another [this was probably based on running it on a build created by
> > the "make" build system, where all headers were in a single directory].
> > To attempt to have a build-system integrated replacement, this patchset
> > adds a "chkincs" app in the buildtools directory to verify this on an
> > ongoing basis.
> >
> > This chkincs app does nothing when run, and is not installed as part of
> > a DPDK "ninja install", it's for build-time checking only. Its source
> > code consists of one C file per public DPDK header, where that C file
> > contains nothing except an include for that header. Therefore, if any
> > header is added to the lib folder which fails to compile when included
> > alone, the build of chkincs will fail with a suitable error message.
> > Since this compile checking is not needed on most builds of DPDK, the
> > building of chkincs is disabled by default, but can be enabled by the
> > "test_includes" meson option. To catch errors with patch submissions,
> > the final patch of this series enables it for a single build in
> > test-meson-builds script.
> >
> > Future work could involve doing similar checks on headers for C++
> > compatibility, which was something done by the check-includes.sh script
> > but which is missing here..
> >
> > V3:
> > * Shrunk patchset as most header fixes already applied
> > * Moved chkincs from "apps" to the "buildtools" directory, which is a
> > better location for something not for installation for end-user use.
> > * Added patch to drop check-includes script.
> >
> > V2:
> > * Add maintainers file entry for new app
> > * Drop patch for c11 ring header
> > * Use build variable "headers_no_chkincs" for tracking exceptions
> >
> > Bruce Richardson (4):
> > eal: add missing include to mcslock
> > build: separate out headers for include checking
> > buildtools/chkincs: add app to verify header includes
> > devtools: remove check-includes script
> >
> > MAINTAINERS | 5 +-
> > buildtools/chkincs/gen_c_file_for_header.py | 12 +
> > buildtools/chkincs/main.c | 4 +
> > buildtools/chkincs/meson.build | 40 +++
> > devtools/check-includes.sh | 259 -------------------
> > devtools/test-meson-builds.sh | 2 +-
> > doc/guides/contributing/coding_style.rst | 12 +
> > lib/librte_eal/include/generic/rte_mcslock.h | 1 +
> > lib/librte_eal/include/meson.build | 2 +-
> > lib/librte_eal/x86/include/meson.build | 14 +-
> > lib/librte_ethdev/meson.build | 4 +-
> > lib/librte_hash/meson.build | 4 +-
> > lib/librte_ipsec/meson.build | 3 +-
> > lib/librte_lpm/meson.build | 2 +-
> > lib/librte_regexdev/meson.build | 2 +-
> > lib/librte_ring/meson.build | 4 +-
> > lib/librte_stack/meson.build | 4 +-
> > lib/librte_table/meson.build | 7 +-
> > lib/meson.build | 3 +
> > meson.build | 6 +
> > meson_options.txt | 2 +
> > 21 files changed, 112 insertions(+), 280 deletions(-)
> > create mode 100755 buildtools/chkincs/gen_c_file_for_header.py
> > create mode 100644 buildtools/chkincs/main.c
> > create mode 100644 buildtools/chkincs/meson.build
> > delete mode 100755 devtools/check-includes.sh
>
> - clang is not happy when enabling the check:
> $ meson configure $HOME/builds/build-clang-static -Dcheck_includes=true
> $ devtools/test-meson-builds.sh
> ...
> [362/464] Compiling C object
> buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_vdev.c.o
> FAILED: buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_vdev.c.o
> clang -Ibuildtools/chkincs/chkincs.p -Ibuildtools/chkincs
> -I../../dpdk/buildtools/chkincs -Idrivers/bus/pci
> -I../../dpdk/drivers/bus/pci -Idrivers/bus/vdev
> -I../../dpdk/drivers/bus/vdev -I. -I../../dpdk -Iconfig
> -I../../dpdk/config -Ilib/librte_eal/include
> -I../../dpdk/lib/librte_eal/include -Ilib/librte_eal/linux/include
> -I../../dpdk/lib/librte_eal/linux/include -Ilib/librte_eal/x86/include
> -I../../dpdk/lib/librte_eal/x86/include -Ilib/librte_kvargs
> -I../../dpdk/lib/librte_kvargs -Ilib/librte_metrics
> -I../../dpdk/lib/librte_metrics -Ilib/librte_telemetry
> -I../../dpdk/lib/librte_telemetry -Ilib/librte_eal/common
> -I../../dpdk/lib/librte_eal/common -Ilib/librte_eal
> -I../../dpdk/lib/librte_eal -Ilib/librte_ring
> -I../../dpdk/lib/librte_ring -Ilib/librte_rcu
> -I../../dpdk/lib/librte_rcu -Ilib/librte_mempool
> -I../../dpdk/lib/librte_mempool -Ilib/librte_mbuf
> -I../../dpdk/lib/librte_mbuf -Ilib/librte_net
> -I../../dpdk/lib/librte_net -Ilib/librte_meter
> -I../../dpdk/lib/librte_meter -Ilib/librte_ethdev
> -I../../dpdk/lib/librte_ethdev -Ilib/librte_pci
> -I../../dpdk/lib/librte_pci -Ilib/librte_cmdline
> -I../../dpdk/lib/librte_cmdline -Ilib/librte_hash
> -I../../dpdk/lib/librte_hash -Ilib/librte_timer
> -I../../dpdk/lib/librte_timer -Ilib/librte_acl
> -I../../dpdk/lib/librte_acl -Ilib/librte_bbdev
> -I../../dpdk/lib/librte_bbdev -Ilib/librte_bitratestats
> -I../../dpdk/lib/librte_bitratestats -Ilib/librte_cfgfile
> -I../../dpdk/lib/librte_cfgfile -Ilib/librte_compressdev
> -I../../dpdk/lib/librte_compressdev -Ilib/librte_cryptodev
> -I../../dpdk/lib/librte_cryptodev -Ilib/librte_distributor
> -I../../dpdk/lib/librte_distributor -Ilib/librte_efd
> -I../../dpdk/lib/librte_efd -Ilib/librte_eventdev
> -I../../dpdk/lib/librte_eventdev -Ilib/librte_gro
> -I../../dpdk/lib/librte_gro -Ilib/librte_gso
> -I../../dpdk/lib/librte_gso -Ilib/librte_ip_frag
> -I../../dpdk/lib/librte_ip_frag -Ilib/librte_jobstats
> -I../../dpdk/lib/librte_jobstats -Ilib/librte_kni
> -I../../dpdk/lib/librte_kni -Ilib/librte_latencystats
> -I../../dpdk/lib/librte_latencystats -Ilib/librte_lpm
> -I../../dpdk/lib/librte_lpm -Ilib/librte_member
> -I../../dpdk/lib/librte_member -Ilib/librte_power
> -I../../dpdk/lib/librte_power -Ilib/librte_pdump
> -I../../dpdk/lib/librte_pdump -Ilib/librte_rawdev
> -I../../dpdk/lib/librte_rawdev -Ilib/librte_regexdev
> -I../../dpdk/lib/librte_regexdev -Ilib/librte_rib
> -I../../dpdk/lib/librte_rib -Ilib/librte_reorder
> -I../../dpdk/lib/librte_reorder -Ilib/librte_sched
> -I../../dpdk/lib/librte_sched -Ilib/librte_security
> -I../../dpdk/lib/librte_security -Ilib/librte_stack
> -I../../dpdk/lib/librte_stack -Ilib/librte_vhost
> -I../../dpdk/lib/librte_vhost -Ilib/librte_ipsec
> -I../../dpdk/lib/librte_ipsec -Ilib/librte_fib
> -I../../dpdk/lib/librte_fib -Ilib/librte_port
> -I../../dpdk/lib/librte_port -Ilib/librte_table
> -I../../dpdk/lib/librte_table -Ilib/librte_pipeline
> -I../../dpdk/lib/librte_pipeline -Ilib/librte_flow_classify
> -I../../dpdk/lib/librte_flow_classify -Ilib/librte_bpf
> -I../../dpdk/lib/librte_bpf -Ilib/librte_graph
> -I../../dpdk/lib/librte_graph -Ilib/librte_node
> -I../../dpdk/lib/librte_node
> -I/home/dmarchan/intel-ipsec-mb/install/include -Xclang
> -fcolor-diagnostics -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
> -Werror -O2 -g -include rte_config.h -Wextra -Wcast-qual -Wdeprecated
> -Wformat -Wformat-nonliteral -Wformat-security -Wmissing-declarations
> -Wmissing-prototypes -Wnested-externs -Wold-style-definition
> -Wpointer-arith -Wsign-compare -Wstrict-prototypes -Wundef
> -Wwrite-strings -Wno-address-of-packed-member
> -Wno-missing-field-initializers -D_GNU_SOURCE -march=native
> -Wno-unused-function -DALLOW_EXPERIMENTAL_API -MD -MQ
> buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_vdev.c.o -MF
> buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_vdev.c.o.d -o
> buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_vdev.c.o -c
> buildtools/chkincs/chkincs.p/rte_ethdev_vdev.c
> In file included from buildtools/chkincs/chkincs.p/rte_ethdev_vdev.c:1:
> In file included from
> /home/dmarchan/dpdk/lib/librte_ethdev/rte_ethdev_vdev.h:12:
> ../../dpdk/lib/librte_ethdev/rte_ethdev_driver.h:964:1: error: unknown
> attribute 'error' ignored [-Werror,-Wunknown-attributes]
> __rte_internal
> ^
> ../../dpdk/lib/librte_eal/include/rte_compat.h:25:16: note: expanded
> from macro '__rte_internal'
> __attribute__((error("Symbol is not public ABI"), \
> ^
>
>
> - Other issues with ARM builds (arch-specific headers probably the reason):
> $ meson configure $HOME/builds/build-arm64-bluefield -Dcheck_includes=true
> $ devtools/test-meson-builds.sh
> ...
> In file included from buildtools/chkincs/chkincs.p/rte_rib6.c:1:
> /home/dmarchan/dpdk/lib/librte_rib/rte_rib6.h: In function ‘get_msk_part’:
> /home/dmarchan/dpdk/lib/librte_rib/rte_rib6.h:112:10: error: implicit
> declaration of function ‘RTE_MIN’; did you mean ‘INT8_MIN’?
> [-Werror=implicit-function-declaration]
> depth = RTE_MIN(depth, 128);
> ^~~~~~~
> INT8_MIN
> /home/dmarchan/dpdk/lib/librte_rib/rte_rib6.h:112:10: error: nested
> extern declaration of ‘RTE_MIN’ [-Werror=nested-externs]
> /home/dmarchan/dpdk/lib/librte_rib/rte_rib6.h:113:9: error: implicit
> declaration of function ‘RTE_MAX’; did you mean ‘INT8_MAX’?
> [-Werror=implicit-function-declaration]
> part = RTE_MAX((int16_t)depth - (byte * 8), 0);
> ^~~~~~~
> INT8_MAX
> /home/dmarchan/dpdk/lib/librte_rib/rte_rib6.h:113:9: error: nested
> extern declaration of ‘RTE_MAX’ [-Werror=nested-externs]
> cc1: all warnings being treated as errors
>
>
> - This check should be enabled for x86 and aarch cross build in GHA.
>
Sure, will look into all of these.
/Bruce
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] ethdev: add IPv6 DSCP option for modify field action
@ 2021-01-26 3:43 3% ` Stephen Hemminger
2021-01-26 5:21 3% ` Alexander Kozyrev
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2021-01-26 3:43 UTC (permalink / raw)
To: Alexander Kozyrev
Cc: dev, viacheslavo, orika, thomas, ferruh.yigit, andrew.rybchenko,
jerinjacobk, ajit.khaparde
On Tue, 26 Jan 2021 03:38:24 +0000
Alexander Kozyrev <akozyrev@nvidia.com> wrote:
> IPv6 DSCP field ID is missing from the original list of Field IDs
> for MODIFY_FIELD action. Add it to support IPv6 header fully.
>
> Fixes: 73b68f4c54a ("ethdev: introduce generic modify flow action")
>
> Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com>
> ---
> lib/librte_ethdev/rte_flow.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> index 46e8ee70ab..68c68cdd6c 100644
> --- a/lib/librte_ethdev/rte_flow.h
> +++ b/lib/librte_ethdev/rte_flow.h
> @@ -2842,6 +2842,7 @@ enum rte_flow_field_id {
> RTE_FLOW_FIELD_IPV4_TTL,
> RTE_FLOW_FIELD_IPV4_SRC,
> RTE_FLOW_FIELD_IPV4_DST,
> + RTE_FLOW_FIELD_IPV6_DSCP,
> RTE_FLOW_FIELD_IPV6_HOPLIMIT,
> RTE_FLOW_FIELD_IPV6_SRC,
> RTE_FLOW_FIELD_IPV6_DST,
Adding field in middle of enum will break ABI.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] ethdev: add IPv6 DSCP option for modify field action
2021-01-26 3:43 3% ` Stephen Hemminger
@ 2021-01-26 5:21 3% ` Alexander Kozyrev
2021-01-26 5:35 0% ` Ajit Khaparde
2021-01-26 5:44 0% ` Stephen Hemminger
0 siblings, 2 replies; 200+ results
From: Alexander Kozyrev @ 2021-01-26 5:21 UTC (permalink / raw)
To: Stephen Hemminger
Cc: dev, Slava Ovsiienko, Ori Kam, NBU-Contact-Thomas Monjalon,
ferruh.yigit, andrew.rybchenko, jerinjacobk, ajit.khaparde
> From: Stephen Hemminger <stephen@networkplumber.org> on Monday, January 25, 2021 22:44
>
> On Tue, 26 Jan 2021 03:38:24 +0000
> Alexander Kozyrev <akozyrev@nvidia.com> wrote:
>
> > IPv6 DSCP field ID is missing from the original list of Field IDs
> > for MODIFY_FIELD action. Add it to support IPv6 header fully.
> >
> > Fixes: 73b68f4c54a ("ethdev: introduce generic modify flow action")
> >
> > Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com>
> > ---
> > lib/librte_ethdev/rte_flow.h | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> > index 46e8ee70ab..68c68cdd6c 100644
> > --- a/lib/librte_ethdev/rte_flow.h
> > +++ b/lib/librte_ethdev/rte_flow.h
> > @@ -2842,6 +2842,7 @@ enum rte_flow_field_id {
> > RTE_FLOW_FIELD_IPV4_TTL,
> > RTE_FLOW_FIELD_IPV4_SRC,
> > RTE_FLOW_FIELD_IPV4_DST,
> > + RTE_FLOW_FIELD_IPV6_DSCP,
> > RTE_FLOW_FIELD_IPV6_HOPLIMIT,
> > RTE_FLOW_FIELD_IPV6_SRC,
> > RTE_FLOW_FIELD_IPV6_DST,
>
> Adding field in middle of enum will break ABI.
I added the rte_flow_field_id enum a week ago into 20.11-rc1.
I believe it is not too late to make it right without breaking ABI, don't you think so?
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] ethdev: add IPv6 DSCP option for modify field action
2021-01-26 5:21 3% ` Alexander Kozyrev
@ 2021-01-26 5:35 0% ` Ajit Khaparde
2021-01-26 5:44 0% ` Stephen Hemminger
1 sibling, 0 replies; 200+ results
From: Ajit Khaparde @ 2021-01-26 5:35 UTC (permalink / raw)
To: Alexander Kozyrev
Cc: Stephen Hemminger, dev, Slava Ovsiienko, Ori Kam,
NBU-Contact-Thomas Monjalon, ferruh.yigit, andrew.rybchenko,
jerinjacobk
[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]
On Mon, Jan 25, 2021 at 9:21 PM Alexander Kozyrev <akozyrev@nvidia.com> wrote:
>
> > From: Stephen Hemminger <stephen@networkplumber.org> on Monday, January 25, 2021 22:44
> >
> > On Tue, 26 Jan 2021 03:38:24 +0000
> > Alexander Kozyrev <akozyrev@nvidia.com> wrote:
> >
> > > IPv6 DSCP field ID is missing from the original list of Field IDs
> > > for MODIFY_FIELD action. Add it to support IPv6 header fully.
> > >
> > > Fixes: 73b68f4c54a ("ethdev: introduce generic modify flow action")
> > >
> > > Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com>
> > > ---
> > > lib/librte_ethdev/rte_flow.h | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> > > index 46e8ee70ab..68c68cdd6c 100644
> > > --- a/lib/librte_ethdev/rte_flow.h
> > > +++ b/lib/librte_ethdev/rte_flow.h
> > > @@ -2842,6 +2842,7 @@ enum rte_flow_field_id {
> > > RTE_FLOW_FIELD_IPV4_TTL,
> > > RTE_FLOW_FIELD_IPV4_SRC,
> > > RTE_FLOW_FIELD_IPV4_DST,
> > > + RTE_FLOW_FIELD_IPV6_DSCP,
> > > RTE_FLOW_FIELD_IPV6_HOPLIMIT,
> > > RTE_FLOW_FIELD_IPV6_SRC,
> > > RTE_FLOW_FIELD_IPV6_DST,
> >
> > Adding field in middle of enum will break ABI.
>
> I added the rte_flow_field_id enum a week ago into 20.11-rc1.
21.02-rc1
> I believe it is not too late to make it right without breaking ABI, don't you think so?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] ethdev: add IPv6 DSCP option for modify field action
2021-01-26 5:21 3% ` Alexander Kozyrev
2021-01-26 5:35 0% ` Ajit Khaparde
@ 2021-01-26 5:44 0% ` Stephen Hemminger
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2021-01-26 5:44 UTC (permalink / raw)
To: Alexander Kozyrev
Cc: dev, Slava Ovsiienko, Ori Kam, NBU-Contact-Thomas Monjalon,
ferruh.yigit, andrew.rybchenko, jerinjacobk, ajit.khaparde
On Tue, 26 Jan 2021 05:21:23 +0000
Alexander Kozyrev <akozyrev@nvidia.com> wrote:
> > From: Stephen Hemminger <stephen@networkplumber.org> on Monday, January 25, 2021 22:44
> >
> > On Tue, 26 Jan 2021 03:38:24 +0000
> > Alexander Kozyrev <akozyrev@nvidia.com> wrote:
> >
> > > IPv6 DSCP field ID is missing from the original list of Field IDs
> > > for MODIFY_FIELD action. Add it to support IPv6 header fully.
> > >
> > > Fixes: 73b68f4c54a ("ethdev: introduce generic modify flow action")
> > >
> > > Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com>
> > > ---
> > > lib/librte_ethdev/rte_flow.h | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> > > index 46e8ee70ab..68c68cdd6c 100644
> > > --- a/lib/librte_ethdev/rte_flow.h
> > > +++ b/lib/librte_ethdev/rte_flow.h
> > > @@ -2842,6 +2842,7 @@ enum rte_flow_field_id {
> > > RTE_FLOW_FIELD_IPV4_TTL,
> > > RTE_FLOW_FIELD_IPV4_SRC,
> > > RTE_FLOW_FIELD_IPV4_DST,
> > > + RTE_FLOW_FIELD_IPV6_DSCP,
> > > RTE_FLOW_FIELD_IPV6_HOPLIMIT,
> > > RTE_FLOW_FIELD_IPV6_SRC,
> > > RTE_FLOW_FIELD_IPV6_DST,
> >
> > Adding field in middle of enum will break ABI.
>
> I added the rte_flow_field_id enum a week ago into 20.11-rc1.
> I believe it is not too late to make it right without breaking ABI, don't you think so?
Ok if not in release yet
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v4 00/44] net/virtio: Virtio PMD rework
@ 2021-01-26 10:15 3% Maxime Coquelin
2021-01-26 10:15 7% ` [dpdk-dev] [PATCH v4 02/44] bus/vdev: add driver IOVA VA mode requirement Maxime Coquelin
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Maxime Coquelin @ 2021-01-26 10:15 UTC (permalink / raw)
To: dev, chenbo.xia, olivier.matz, amorenoz, david.marchand; +Cc: Maxime Coquelin
This V3 fixes comments from Chenbo on patch 44 and
implements the ABI exception in patch 2.
This series significantly rework Virtio PMD to improve
the Virtio-user PMD and its backends integration.
First part of the series removes the dependency of
Virtio-user ethdev on Virtio PCI, by creating generic
files, adding per-bus meta data, ...
Main (if not single) functionnal change of this first
part is to remove the hack for Virtio-user to work in
IOVA as PA mode, this hack being very fragile.
Second part of the series reworks Virtio-user internal,
by reworking the requests handling so that vDPA and Kernel
backends no more hack into being Vhost-user backend. It
implies implementing new ops for all the request types.
Also, all the backend specific actions are moved from the
virtio_user_dev.c and virtio_user_ethdev.c to their
backend files.
Only functionnal change in this second part is making the
Vhost-user server mode blocking at init time, as long as
a client is not connected. The goal of this change is to
make the Vhost-user support much more robust, as without
blocking, the driver has to assume features that are going
to be supported by the client, which is very fragile and
error prone. As a side-effect, it also simplifies the
logic nin several place of the virtio-user PMD.
Main changes in v4:
- Add ABI exception (David)
- Close FDs only up to max_queue_pairs
- virtio_user_dev_uninit_notify() to return void
Main changes in v3:
- Rename .intr_event to .intr_detect
- Rework last patch, properly clean allocated resources
on failure.
- Rebase on top of latest net-next/main
- Minor typo fixes in comments and log improvements
Main changes in v2:
===================
- Introduce vdev driver flag for drivers to require IOVA VA mode
- Rebase on top of -rc1 changes
- Fix regressions introduced in V1 (vhost-kernel broken, vhost-user reconnect...)
- Various minor issues & typos fixed
- Fix status feature issue introduced in v20.11, only reproduceable now that server
mode is made blocking
- Improve failure handling in Virtio-user
- Improve logging
Testing coverage (All passed)
=============================
- Virtio-pci PMD
* Virtio PMD in guest with Vhost-user backend in host
* Virtio PMD in guest with Vhost-kernel backend in host
- Virtio-user PMD with Vhost-user backend
* Vhost-user PMD server <-> Virtio-user client PMD IO loopback
* Vhost-user PMD client <-> Virtio-user server PMD IO loopback
* Vhost-user PMD client <-> Virtio-user server PMD reconnect
- Virtio-user PMD with Vhost-kernel backend
* iperf test case
* Txonly testpmd
- Virtio-user PMD with Vhost-vDPA backend
* vdpa-sim (IO loopback)
* CX-6 DX Kernel vDPA (Tx only)
Maxime Coquelin (44):
bus/vdev: add helper to get vdev from ethdev
bus/vdev: add driver IOVA VA mode requirement
net/virtio: fix getting old status on reconnect
net/virtio: introduce Virtio bus type
net/virtio: refactor virtio-user device
net/virtio: introduce PCI device metadata
net/virtio: move PCI device init in dedicated file
net/virtio: move PCI specific dev init to PCI ethdev init
net/virtio: move MSIX detection to PCI ethdev
net/virtio: force IOVA as VA mode for Virtio-user
net/virtio: store PCI type in Virtio device metadata
net/virtio: add callback for device closing
net/virtio: validate features at bus level
net/virtio: remove bus type enum
net/virtio: move PCI-specific fields to PCI device
net/virtio: pack virtio HW struct
net/virtio: move legacy IO to Virtio PCI
net/virtio: introduce generic virtio header
net/virtio: move features definition to generic header
net/virtio: move virtqueue defines in generic header
net/virtio: move config definitions to generic header
net/virtio: make interrupt handling more generic
net/virtio: move vring alignment to generic header
net/virtio: remove last PCI refs in non-PCI code
net/virtio: make Vhost-user request sender consistent
net/virtio: add Virtio-user ops to set owner
net/virtio: add Virtio-user features ops
net/virtio: add Virtio-user protocol features ops
net/virtio: add Virtio-user memory tables ops
net/virtio: add Virtio-user vring setting ops
net/virtio: add Virtio-user vring file ops
net/virtio: add Virtio-user vring address ops
net/virtio: add Virtio-user status ops
net/virtio: remove useless request ops
net/virtio: improve Virtio-user errors handling
net/virtio: move Vhost-user requests to Vhost-user backend
net/virtio: make server mode blocking
net/virtio: move protocol features to Vhost-user
net/virtio: introduce backend data
net/virtio: move Vhost-user specifics to its backend
net/virtio: move Vhost-kernel data to its backend
net/virtio: move Vhost-vDPA data to its backend
net/virtio: improve Vhost-user error logging
net/virtio: handle Virtio-user setup failure properly
devtools/libabigail.abignore | 2 +
drivers/bus/vdev/rte_bus_vdev.h | 6 +
drivers/bus/vdev/vdev.c | 29 +
drivers/net/virtio/meson.build | 6 +-
drivers/net/virtio/virtio.c | 71 ++
drivers/net/virtio/virtio.h | 246 +++++
drivers/net/virtio/virtio_ethdev.c | 457 +++------
drivers/net/virtio/virtio_ethdev.h | 6 +-
drivers/net/virtio/virtio_pci.c | 448 +++++----
drivers/net/virtio/virtio_pci.h | 286 +-----
drivers/net/virtio/virtio_pci_ethdev.c | 226 +++++
drivers/net/virtio/virtio_ring.h | 2 +-
drivers/net/virtio/virtio_rxtx.c | 90 +-
drivers/net/virtio/virtio_rxtx_packed.h | 10 +-
drivers/net/virtio/virtio_rxtx_packed_avx.h | 10 +-
drivers/net/virtio/virtio_rxtx_packed_neon.h | 10 +-
drivers/net/virtio/virtio_rxtx_simple.h | 3 +-
drivers/net/virtio/virtio_user/vhost.h | 79 +-
drivers/net/virtio/virtio_user/vhost_kernel.c | 461 ++++++---
.../net/virtio/virtio_user/vhost_kernel_tap.c | 25 +-
.../net/virtio/virtio_user/vhost_kernel_tap.h | 1 +
drivers/net/virtio/virtio_user/vhost_user.c | 898 ++++++++++++++----
drivers/net/virtio/virtio_user/vhost_vdpa.c | 323 +++++--
.../net/virtio/virtio_user/virtio_user_dev.c | 573 ++++++-----
.../net/virtio/virtio_user/virtio_user_dev.h | 21 +-
drivers/net/virtio/virtio_user_ethdev.c | 301 +-----
drivers/net/virtio/virtqueue.c | 6 +-
drivers/net/virtio/virtqueue.h | 45 +-
28 files changed, 2742 insertions(+), 1899 deletions(-)
create mode 100644 drivers/net/virtio/virtio.c
create mode 100644 drivers/net/virtio/virtio.h
create mode 100644 drivers/net/virtio/virtio_pci_ethdev.c
--
2.29.2
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v4 02/44] bus/vdev: add driver IOVA VA mode requirement
2021-01-26 10:15 3% [dpdk-dev] [PATCH v4 00/44] net/virtio: Virtio PMD rework Maxime Coquelin
@ 2021-01-26 10:15 7% ` Maxime Coquelin
2021-01-26 11:50 0% ` Xia, Chenbo
` (2 more replies)
2021-01-27 11:59 0% ` [dpdk-dev] [PATCH v4 00/44] net/virtio: Virtio PMD rework Maxime Coquelin
2021-02-01 8:44 0% ` Wang, Yinan
2 siblings, 3 replies; 200+ results
From: Maxime Coquelin @ 2021-01-26 10:15 UTC (permalink / raw)
To: dev, chenbo.xia, olivier.matz, amorenoz, david.marchand; +Cc: Maxime Coquelin
This patch adds driver flag in vdev bus driver so that
vdev drivers can require VA IOVA mode to be used, which
for example the case of Virtio-user PMD.
The patch implements the .get_iommu_class() callback, that
is called before devices probing to determine the IOVA mode
to be used, and adds a check right before the device is
probed to ensure compatible IOVA mode has been selected.
It also adds a ABI exception rule to accommodate with an
update on the driver registration API
Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
devtools/libabigail.abignore | 2 ++
drivers/bus/vdev/rte_bus_vdev.h | 4 ++++
drivers/bus/vdev/vdev.c | 29 +++++++++++++++++++++++++++++
3 files changed, 35 insertions(+)
diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 1dc84fa74b..170304c876 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -11,6 +11,8 @@
; Explicit ignore for driver-only ABI
[suppress_type]
name = eth_dev_ops
+[suppress_function]
+ name_regexp = rte_vdev_(|un)register
; Ignore fields inserted in cacheline boundary of rte_cryptodev
[suppress_type]
diff --git a/drivers/bus/vdev/rte_bus_vdev.h b/drivers/bus/vdev/rte_bus_vdev.h
index f99a41f825..fc315d10fa 100644
--- a/drivers/bus/vdev/rte_bus_vdev.h
+++ b/drivers/bus/vdev/rte_bus_vdev.h
@@ -113,8 +113,12 @@ struct rte_vdev_driver {
rte_vdev_remove_t *remove; /**< Virtual device remove function. */
rte_vdev_dma_map_t *dma_map; /**< Virtual device DMA map function. */
rte_vdev_dma_unmap_t *dma_unmap; /**< Virtual device DMA unmap function. */
+ uint32_t drv_flags; /**< Flags RTE_VDEV_DRV_*. */
};
+/** Device driver needs IOVA as VA and cannot work with IOVA as PA */
+#define RTE_VDEV_DRV_NEED_IOVA_AS_VA 0x0001
+
/**
* Register a virtual device driver.
*
diff --git a/drivers/bus/vdev/vdev.c b/drivers/bus/vdev/vdev.c
index acfd78828f..9a673347ae 100644
--- a/drivers/bus/vdev/vdev.c
+++ b/drivers/bus/vdev/vdev.c
@@ -189,6 +189,7 @@ vdev_probe_all_drivers(struct rte_vdev_device *dev)
{
const char *name;
struct rte_vdev_driver *driver;
+ enum rte_iova_mode iova_mode;
int ret;
if (rte_dev_is_probed(&dev->device))
@@ -199,6 +200,14 @@ vdev_probe_all_drivers(struct rte_vdev_device *dev)
if (vdev_parse(name, &driver))
return -1;
+
+ iova_mode = rte_eal_iova_mode();
+ if ((driver->drv_flags & RTE_VDEV_DRV_NEED_IOVA_AS_VA) && (iova_mode == RTE_IOVA_PA)) {
+ VDEV_LOG(ERR, "%s requires VA IOVA mode but current mode is PA, not initializing",
+ name);
+ return -1;
+ }
+
ret = driver->probe(dev);
if (ret == 0)
dev->device.driver = &driver->driver;
@@ -594,6 +603,25 @@ vdev_unplug(struct rte_device *dev)
return rte_vdev_uninit(dev->name);
}
+static enum rte_iova_mode
+vdev_get_iommu_class(void)
+{
+ const char *name;
+ struct rte_vdev_device *dev;
+ struct rte_vdev_driver *driver;
+
+ TAILQ_FOREACH(dev, &vdev_device_list, next) {
+ name = rte_vdev_device_name(dev);
+ if (vdev_parse(name, &driver))
+ continue;
+
+ if (driver->drv_flags & RTE_VDEV_DRV_NEED_IOVA_AS_VA)
+ return RTE_IOVA_VA;
+ }
+
+ return RTE_IOVA_DC;
+}
+
static struct rte_bus rte_vdev_bus = {
.scan = vdev_scan,
.probe = vdev_probe,
@@ -603,6 +631,7 @@ static struct rte_bus rte_vdev_bus = {
.parse = vdev_parse,
.dma_map = vdev_dma_map,
.dma_unmap = vdev_dma_unmap,
+ .get_iommu_class = vdev_get_iommu_class,
.dev_iterate = rte_vdev_dev_iterate,
};
--
2.29.2
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [PATCH v3 0/4] add checking of header includes
2021-01-25 15:51 2% ` David Marchand
2021-01-25 18:17 0% ` Bruce Richardson
@ 2021-01-26 11:15 4% ` Bruce Richardson
2021-01-26 14:04 3% ` David Marchand
1 sibling, 1 reply; 200+ results
From: Bruce Richardson @ 2021-01-26 11:15 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Thomas Monjalon
On Mon, Jan 25, 2021 at 04:51:19PM +0100, David Marchand wrote:
> On Mon, Jan 25, 2021 at 3:11 PM Bruce Richardson
> <bruce.richardson@intel.com> wrote:
> >
> > As a general principle, each header file should include any other
> > headers it needs to provide data type definitions or macros. For
> > example, any header using the uintX_t types in structures or function
> > prototypes should include "stdint.h" to provide those type definitions.
> >
> > In practice, while many, but not all, headers in DPDK did include all
> > necessary headers, it was never actually checked that each header could
> > be included in a C file and compiled without having any compiler errors
> > about missing definitions. The script "check-includes.sh" could be used
> > for this job, but it was not called out in the documentation, so many
> > contributors may not have been aware of it's existance. It also was
> > difficult to run from a source-code directory, as the script did not
> > automatically allow finding of headers from one DPDK library directory
> > to another [this was probably based on running it on a build created by
> > the "make" build system, where all headers were in a single directory].
> > To attempt to have a build-system integrated replacement, this patchset
> > adds a "chkincs" app in the buildtools directory to verify this on an
> > ongoing basis.
> >
> > This chkincs app does nothing when run, and is not installed as part of
> > a DPDK "ninja install", it's for build-time checking only. Its source
> > code consists of one C file per public DPDK header, where that C file
> > contains nothing except an include for that header. Therefore, if any
> > header is added to the lib folder which fails to compile when included
> > alone, the build of chkincs will fail with a suitable error message.
> > Since this compile checking is not needed on most builds of DPDK, the
> > building of chkincs is disabled by default, but can be enabled by the
> > "test_includes" meson option. To catch errors with patch submissions,
> > the final patch of this series enables it for a single build in
> > test-meson-builds script.
> >
> > Future work could involve doing similar checks on headers for C++
> > compatibility, which was something done by the check-includes.sh script
> > but which is missing here..
> >
> > V3:
> > * Shrunk patchset as most header fixes already applied
> > * Moved chkincs from "apps" to the "buildtools" directory, which is a
> > better location for something not for installation for end-user use.
> > * Added patch to drop check-includes script.
> >
> > V2:
> > * Add maintainers file entry for new app
> > * Drop patch for c11 ring header
> > * Use build variable "headers_no_chkincs" for tracking exceptions
> >
> > Bruce Richardson (4):
> > eal: add missing include to mcslock
> > build: separate out headers for include checking
> > buildtools/chkincs: add app to verify header includes
> > devtools: remove check-includes script
> >
> > MAINTAINERS | 5 +-
> > buildtools/chkincs/gen_c_file_for_header.py | 12 +
> > buildtools/chkincs/main.c | 4 +
> > buildtools/chkincs/meson.build | 40 +++
> > devtools/check-includes.sh | 259 -------------------
> > devtools/test-meson-builds.sh | 2 +-
> > doc/guides/contributing/coding_style.rst | 12 +
> > lib/librte_eal/include/generic/rte_mcslock.h | 1 +
> > lib/librte_eal/include/meson.build | 2 +-
> > lib/librte_eal/x86/include/meson.build | 14 +-
> > lib/librte_ethdev/meson.build | 4 +-
> > lib/librte_hash/meson.build | 4 +-
> > lib/librte_ipsec/meson.build | 3 +-
> > lib/librte_lpm/meson.build | 2 +-
> > lib/librte_regexdev/meson.build | 2 +-
> > lib/librte_ring/meson.build | 4 +-
> > lib/librte_stack/meson.build | 4 +-
> > lib/librte_table/meson.build | 7 +-
> > lib/meson.build | 3 +
> > meson.build | 6 +
> > meson_options.txt | 2 +
> > 21 files changed, 112 insertions(+), 280 deletions(-)
> > create mode 100755 buildtools/chkincs/gen_c_file_for_header.py
> > create mode 100644 buildtools/chkincs/main.c
> > create mode 100644 buildtools/chkincs/meson.build
> > delete mode 100755 devtools/check-includes.sh
>
> - clang is not happy when enabling the check:
> $ meson configure $HOME/builds/build-clang-static -Dcheck_includes=true
> $ devtools/test-meson-builds.sh
> ...
> [362/464] Compiling C object
> buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_vdev.c.o
> FAILED: buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_vdev.c.o
> clang -Ibuildtools/chkincs/chkincs.p -Ibuildtools/chkincs
> -I../../dpdk/buildtools/chkincs -Idrivers/bus/pci
> -I../../dpdk/drivers/bus/pci -Idrivers/bus/vdev
> -I../../dpdk/drivers/bus/vdev -I. -I../../dpdk -Iconfig
> -I../../dpdk/config -Ilib/librte_eal/include
> -I../../dpdk/lib/librte_eal/include -Ilib/librte_eal/linux/include
> -I../../dpdk/lib/librte_eal/linux/include -Ilib/librte_eal/x86/include
> -I../../dpdk/lib/librte_eal/x86/include -Ilib/librte_kvargs
> -I../../dpdk/lib/librte_kvargs -Ilib/librte_metrics
> -I../../dpdk/lib/librte_metrics -Ilib/librte_telemetry
> -I../../dpdk/lib/librte_telemetry -Ilib/librte_eal/common
> -I../../dpdk/lib/librte_eal/common -Ilib/librte_eal
> -I../../dpdk/lib/librte_eal -Ilib/librte_ring
> -I../../dpdk/lib/librte_ring -Ilib/librte_rcu
> -I../../dpdk/lib/librte_rcu -Ilib/librte_mempool
> -I../../dpdk/lib/librte_mempool -Ilib/librte_mbuf
> -I../../dpdk/lib/librte_mbuf -Ilib/librte_net
> -I../../dpdk/lib/librte_net -Ilib/librte_meter
> -I../../dpdk/lib/librte_meter -Ilib/librte_ethdev
> -I../../dpdk/lib/librte_ethdev -Ilib/librte_pci
> -I../../dpdk/lib/librte_pci -Ilib/librte_cmdline
> -I../../dpdk/lib/librte_cmdline -Ilib/librte_hash
> -I../../dpdk/lib/librte_hash -Ilib/librte_timer
> -I../../dpdk/lib/librte_timer -Ilib/librte_acl
> -I../../dpdk/lib/librte_acl -Ilib/librte_bbdev
> -I../../dpdk/lib/librte_bbdev -Ilib/librte_bitratestats
> -I../../dpdk/lib/librte_bitratestats -Ilib/librte_cfgfile
> -I../../dpdk/lib/librte_cfgfile -Ilib/librte_compressdev
> -I../../dpdk/lib/librte_compressdev -Ilib/librte_cryptodev
> -I../../dpdk/lib/librte_cryptodev -Ilib/librte_distributor
> -I../../dpdk/lib/librte_distributor -Ilib/librte_efd
> -I../../dpdk/lib/librte_efd -Ilib/librte_eventdev
> -I../../dpdk/lib/librte_eventdev -Ilib/librte_gro
> -I../../dpdk/lib/librte_gro -Ilib/librte_gso
> -I../../dpdk/lib/librte_gso -Ilib/librte_ip_frag
> -I../../dpdk/lib/librte_ip_frag -Ilib/librte_jobstats
> -I../../dpdk/lib/librte_jobstats -Ilib/librte_kni
> -I../../dpdk/lib/librte_kni -Ilib/librte_latencystats
> -I../../dpdk/lib/librte_latencystats -Ilib/librte_lpm
> -I../../dpdk/lib/librte_lpm -Ilib/librte_member
> -I../../dpdk/lib/librte_member -Ilib/librte_power
> -I../../dpdk/lib/librte_power -Ilib/librte_pdump
> -I../../dpdk/lib/librte_pdump -Ilib/librte_rawdev
> -I../../dpdk/lib/librte_rawdev -Ilib/librte_regexdev
> -I../../dpdk/lib/librte_regexdev -Ilib/librte_rib
> -I../../dpdk/lib/librte_rib -Ilib/librte_reorder
> -I../../dpdk/lib/librte_reorder -Ilib/librte_sched
> -I../../dpdk/lib/librte_sched -Ilib/librte_security
> -I../../dpdk/lib/librte_security -Ilib/librte_stack
> -I../../dpdk/lib/librte_stack -Ilib/librte_vhost
> -I../../dpdk/lib/librte_vhost -Ilib/librte_ipsec
> -I../../dpdk/lib/librte_ipsec -Ilib/librte_fib
> -I../../dpdk/lib/librte_fib -Ilib/librte_port
> -I../../dpdk/lib/librte_port -Ilib/librte_table
> -I../../dpdk/lib/librte_table -Ilib/librte_pipeline
> -I../../dpdk/lib/librte_pipeline -Ilib/librte_flow_classify
> -I../../dpdk/lib/librte_flow_classify -Ilib/librte_bpf
> -I../../dpdk/lib/librte_bpf -Ilib/librte_graph
> -I../../dpdk/lib/librte_graph -Ilib/librte_node
> -I../../dpdk/lib/librte_node
> -I/home/dmarchan/intel-ipsec-mb/install/include -Xclang
> -fcolor-diagnostics -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
> -Werror -O2 -g -include rte_config.h -Wextra -Wcast-qual -Wdeprecated
> -Wformat -Wformat-nonliteral -Wformat-security -Wmissing-declarations
> -Wmissing-prototypes -Wnested-externs -Wold-style-definition
> -Wpointer-arith -Wsign-compare -Wstrict-prototypes -Wundef
> -Wwrite-strings -Wno-address-of-packed-member
> -Wno-missing-field-initializers -D_GNU_SOURCE -march=native
> -Wno-unused-function -DALLOW_EXPERIMENTAL_API -MD -MQ
> buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_vdev.c.o -MF
> buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_vdev.c.o.d -o
> buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_vdev.c.o -c
> buildtools/chkincs/chkincs.p/rte_ethdev_vdev.c
> In file included from buildtools/chkincs/chkincs.p/rte_ethdev_vdev.c:1:
> In file included from
> /home/dmarchan/dpdk/lib/librte_ethdev/rte_ethdev_vdev.h:12:
> ../../dpdk/lib/librte_ethdev/rte_ethdev_driver.h:964:1: error: unknown
> attribute 'error' ignored [-Werror,-Wunknown-attributes]
> __rte_internal
> ^
> ../../dpdk/lib/librte_eal/include/rte_compat.h:25:16: note: expanded
> from macro '__rte_internal'
> __attribute__((error("Symbol is not public ABI"), \
> ^
>
This looks to be a real issue with our header file - clang does not have an
"error" attribute. The closest equivalent I can see is "diagnose_if".
Therefore, I'd suggest we need to change compat.h to be something like:
#if !defined ALLOW_INTERNAL_API && __has_attribute(error) /* For GCC */
#define __rte_internal \
__attribute__((error("Symbol is not public ABI"), \
section(".text.internal")))
#elif !defined ALLOW_INTERNAL_API && __has_attribute(diagnose_if) /* For clang */
#define __rte_internal \
__attribute__((diagnose_if(1, "Symbol is not public ABI", "error"), \
section(".text.internal")))
#else
#define __rte_internal \
__attribute__((section(".text.internal")))
#endif
Any thoughts or suggestions for better alternatives here?
/Bruce
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v4 02/44] bus/vdev: add driver IOVA VA mode requirement
2021-01-26 10:15 7% ` [dpdk-dev] [PATCH v4 02/44] bus/vdev: add driver IOVA VA mode requirement Maxime Coquelin
@ 2021-01-26 11:50 0% ` Xia, Chenbo
2021-01-26 12:50 0% ` David Marchand
2021-01-27 8:23 0% ` David Marchand
2 siblings, 0 replies; 200+ results
From: Xia, Chenbo @ 2021-01-26 11:50 UTC (permalink / raw)
To: Maxime Coquelin, dev, olivier.matz, amorenoz, david.marchand
> -----Original Message-----
> From: Maxime Coquelin <maxime.coquelin@redhat.com>
> Sent: Tuesday, January 26, 2021 6:16 PM
> To: dev@dpdk.org; Xia, Chenbo <chenbo.xia@intel.com>; olivier.matz@6wind.com;
> amorenoz@redhat.com; david.marchand@redhat.com
> Cc: Maxime Coquelin <maxime.coquelin@redhat.com>
> Subject: [PATCH v4 02/44] bus/vdev: add driver IOVA VA mode requirement
>
> This patch adds driver flag in vdev bus driver so that
> vdev drivers can require VA IOVA mode to be used, which
> for example the case of Virtio-user PMD.
>
> The patch implements the .get_iommu_class() callback, that
> is called before devices probing to determine the IOVA mode
> to be used, and adds a check right before the device is
> probed to ensure compatible IOVA mode has been selected.
>
> It also adds a ABI exception rule to accommodate with an
> update on the driver registration API
>
> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
> devtools/libabigail.abignore | 2 ++
> drivers/bus/vdev/rte_bus_vdev.h | 4 ++++
> drivers/bus/vdev/vdev.c | 29 +++++++++++++++++++++++++++++
> 3 files changed, 35 insertions(+)
>
> diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
> index 1dc84fa74b..170304c876 100644
> --- a/devtools/libabigail.abignore
> +++ b/devtools/libabigail.abignore
> @@ -11,6 +11,8 @@
> ; Explicit ignore for driver-only ABI
> [suppress_type]
> name = eth_dev_ops
> +[suppress_function]
> + name_regexp = rte_vdev_(|un)register
>
> ; Ignore fields inserted in cacheline boundary of rte_cryptodev
> [suppress_type]
> diff --git a/drivers/bus/vdev/rte_bus_vdev.h b/drivers/bus/vdev/rte_bus_vdev.h
> index f99a41f825..fc315d10fa 100644
> --- a/drivers/bus/vdev/rte_bus_vdev.h
> +++ b/drivers/bus/vdev/rte_bus_vdev.h
> @@ -113,8 +113,12 @@ struct rte_vdev_driver {
> rte_vdev_remove_t *remove; /**< Virtual device remove function. */
> rte_vdev_dma_map_t *dma_map; /**< Virtual device DMA map function.
> */
> rte_vdev_dma_unmap_t *dma_unmap; /**< Virtual device DMA unmap function.
> */
> + uint32_t drv_flags; /**< Flags RTE_VDEV_DRV_*. */
> };
>
> +/** Device driver needs IOVA as VA and cannot work with IOVA as PA */
> +#define RTE_VDEV_DRV_NEED_IOVA_AS_VA 0x0001
> +
> /**
> * Register a virtual device driver.
> *
> diff --git a/drivers/bus/vdev/vdev.c b/drivers/bus/vdev/vdev.c
> index acfd78828f..9a673347ae 100644
> --- a/drivers/bus/vdev/vdev.c
> +++ b/drivers/bus/vdev/vdev.c
> @@ -189,6 +189,7 @@ vdev_probe_all_drivers(struct rte_vdev_device *dev)
> {
> const char *name;
> struct rte_vdev_driver *driver;
> + enum rte_iova_mode iova_mode;
> int ret;
>
> if (rte_dev_is_probed(&dev->device))
> @@ -199,6 +200,14 @@ vdev_probe_all_drivers(struct rte_vdev_device *dev)
>
> if (vdev_parse(name, &driver))
> return -1;
> +
> + iova_mode = rte_eal_iova_mode();
> + if ((driver->drv_flags & RTE_VDEV_DRV_NEED_IOVA_AS_VA) && (iova_mode ==
> RTE_IOVA_PA)) {
> + VDEV_LOG(ERR, "%s requires VA IOVA mode but current mode is PA,
> not initializing",
> + name);
> + return -1;
> + }
> +
> ret = driver->probe(dev);
> if (ret == 0)
> dev->device.driver = &driver->driver;
> @@ -594,6 +603,25 @@ vdev_unplug(struct rte_device *dev)
> return rte_vdev_uninit(dev->name);
> }
>
> +static enum rte_iova_mode
> +vdev_get_iommu_class(void)
> +{
> + const char *name;
> + struct rte_vdev_device *dev;
> + struct rte_vdev_driver *driver;
> +
> + TAILQ_FOREACH(dev, &vdev_device_list, next) {
> + name = rte_vdev_device_name(dev);
> + if (vdev_parse(name, &driver))
> + continue;
> +
> + if (driver->drv_flags & RTE_VDEV_DRV_NEED_IOVA_AS_VA)
> + return RTE_IOVA_VA;
> + }
> +
> + return RTE_IOVA_DC;
> +}
> +
> static struct rte_bus rte_vdev_bus = {
> .scan = vdev_scan,
> .probe = vdev_probe,
> @@ -603,6 +631,7 @@ static struct rte_bus rte_vdev_bus = {
> .parse = vdev_parse,
> .dma_map = vdev_dma_map,
> .dma_unmap = vdev_dma_unmap,
> + .get_iommu_class = vdev_get_iommu_class,
> .dev_iterate = rte_vdev_dev_iterate,
> };
>
> --
> 2.29.2
Reviewed-by: Chenbo Xia <chenbo.xia@intel.com>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v1] devtools: update abi ignore for cryptodev
2021-01-20 14:25 4% [dpdk-dev] [PATCH v1] devtools: update abi ignore for cryptodev Ray Kinsella
2021-01-20 15:41 7% ` Thomas Monjalon
@ 2021-01-26 11:55 8% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Thomas Monjalon @ 2021-01-26 11:55 UTC (permalink / raw)
To: Ray Kinsella
Cc: Neil Horman, Akhil Goyal, Konstantin Ananyev, Abhinandan Gujjar,
dev, david.marchand
20/01/2021 15:25, Ray Kinsella:
> Update the ignore entry for crytodev to use named fields instead of
> bit positions.
>
> Fixes: 1c3ffb9559
>
> Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
> ---
> --- a/devtools/libabigail.abignore
> +++ b/devtools/libabigail.abignore
> @@ -15,4 +15,4 @@
> ; Ignore fields inserted in cacheline boundary of rte_cryptodev
> [suppress_type]
> name = rte_cryptodev
> - has_data_member_inserted_between = {0, 1023}
> + has_data_member_inserted_between = {offset_after(attached), end}
Adding a bit more explanations in the commit message:
It is allowing changes between the last field (attached) in ABI 21.0,
and the end of the padded struct in ABI 21.
Fixes: 1c3ffb95595e ("cryptodev: add enqueue and dequeue callbacks")
Acked-by: Thomas Monjalon <thomas@monjalon.net>
Applied, thanks.
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [PATCH v4 02/44] bus/vdev: add driver IOVA VA mode requirement
2021-01-26 10:15 7% ` [dpdk-dev] [PATCH v4 02/44] bus/vdev: add driver IOVA VA mode requirement Maxime Coquelin
2021-01-26 11:50 0% ` Xia, Chenbo
@ 2021-01-26 12:50 0% ` David Marchand
2021-01-26 13:23 0% ` Kinsella, Ray
2021-01-27 8:23 0% ` David Marchand
2 siblings, 1 reply; 200+ results
From: David Marchand @ 2021-01-26 12:50 UTC (permalink / raw)
To: Maxime Coquelin, Ray Kinsella
Cc: dev, Xia, Chenbo, Olivier Matz, Adrian Moreno Zapata
On Tue, Jan 26, 2021 at 11:16 AM Maxime Coquelin
<maxime.coquelin@redhat.com> wrote:
>
> This patch adds driver flag in vdev bus driver so that
> vdev drivers can require VA IOVA mode to be used, which
> for example the case of Virtio-user PMD.
>
> The patch implements the .get_iommu_class() callback, that
> is called before devices probing to determine the IOVA mode
> to be used, and adds a check right before the device is
> probed to ensure compatible IOVA mode has been selected.
>
> It also adds a ABI exception rule to accommodate with an
> update on the driver registration API
>
> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
> devtools/libabigail.abignore | 2 ++
> drivers/bus/vdev/rte_bus_vdev.h | 4 ++++
> drivers/bus/vdev/vdev.c | 29 +++++++++++++++++++++++++++++
> 3 files changed, 35 insertions(+)
>
> diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
> index 1dc84fa74b..170304c876 100644
> --- a/devtools/libabigail.abignore
> +++ b/devtools/libabigail.abignore
> @@ -11,6 +11,8 @@
> ; Explicit ignore for driver-only ABI
> [suppress_type]
> name = eth_dev_ops
> +[suppress_function]
> + name_regexp = rte_vdev_(|un)register
>
> ; Ignore fields inserted in cacheline boundary of rte_cryptodev
> [suppress_type]
Ray,
Are you okay with this exception?
Thanks.
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4 02/44] bus/vdev: add driver IOVA VA mode requirement
2021-01-26 12:50 0% ` David Marchand
@ 2021-01-26 13:23 0% ` Kinsella, Ray
2021-01-26 14:40 4% ` David Marchand
0 siblings, 1 reply; 200+ results
From: Kinsella, Ray @ 2021-01-26 13:23 UTC (permalink / raw)
To: David Marchand, Maxime Coquelin
Cc: dev, Xia, Chenbo, Olivier Matz, Adrian Moreno Zapata
On 26/01/2021 12:50, David Marchand wrote:
> On Tue, Jan 26, 2021 at 11:16 AM Maxime Coquelin
> <maxime.coquelin@redhat.com> wrote:
>>
>> This patch adds driver flag in vdev bus driver so that
>> vdev drivers can require VA IOVA mode to be used, which
>> for example the case of Virtio-user PMD.
>>
>> The patch implements the .get_iommu_class() callback, that
>> is called before devices probing to determine the IOVA mode
>> to be used, and adds a check right before the device is
>> probed to ensure compatible IOVA mode has been selected.
>>
>> It also adds a ABI exception rule to accommodate with an
>> update on the driver registration API
>>
>> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
>> Signed-off-by: David Marchand <david.marchand@redhat.com>
>> ---
>> devtools/libabigail.abignore | 2 ++
>> drivers/bus/vdev/rte_bus_vdev.h | 4 ++++
>> drivers/bus/vdev/vdev.c | 29 +++++++++++++++++++++++++++++
>> 3 files changed, 35 insertions(+)
>>
>> diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
>> index 1dc84fa74b..170304c876 100644
>> --- a/devtools/libabigail.abignore
>> +++ b/devtools/libabigail.abignore
>> @@ -11,6 +11,8 @@
>> ; Explicit ignore for driver-only ABI
>> [suppress_type]
>> name = eth_dev_ops
>> +[suppress_function]
>> + name_regexp = rte_vdev_(|un)register
>>
>> ; Ignore fields inserted in cacheline boundary of rte_cryptodev
>> [suppress_type]
>
> Ray,
> Are you okay with this exception?
Ask a perhaps silly question,
shouldn't rte_vdev_register & rte_vdev_unregister have been INTERNAL in any case?
> Thanks.
>
Ray K
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3 0/4] add checking of header includes
2021-01-26 11:15 4% ` Bruce Richardson
@ 2021-01-26 14:04 3% ` David Marchand
2021-01-26 14:24 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2021-01-26 14:04 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev, Thomas Monjalon
On Tue, Jan 26, 2021 at 12:15 PM Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> On Mon, Jan 25, 2021 at 04:51:19PM +0100, David Marchand wrote:
> > On Mon, Jan 25, 2021 at 3:11 PM Bruce Richardson
> > <bruce.richardson@intel.com> wrote:
> > >
> > > As a general principle, each header file should include any other
> > > headers it needs to provide data type definitions or macros. For
> > > example, any header using the uintX_t types in structures or function
> > > prototypes should include "stdint.h" to provide those type definitions.
> > >
> > > In practice, while many, but not all, headers in DPDK did include all
> > > necessary headers, it was never actually checked that each header could
> > > be included in a C file and compiled without having any compiler errors
> > > about missing definitions. The script "check-includes.sh" could be used
> > > for this job, but it was not called out in the documentation, so many
> > > contributors may not have been aware of it's existance. It also was
> > > difficult to run from a source-code directory, as the script did not
> > > automatically allow finding of headers from one DPDK library directory
> > > to another [this was probably based on running it on a build created by
> > > the "make" build system, where all headers were in a single directory].
> > > To attempt to have a build-system integrated replacement, this patchset
> > > adds a "chkincs" app in the buildtools directory to verify this on an
> > > ongoing basis.
> > >
> > > This chkincs app does nothing when run, and is not installed as part of
> > > a DPDK "ninja install", it's for build-time checking only. Its source
> > > code consists of one C file per public DPDK header, where that C file
> > > contains nothing except an include for that header. Therefore, if any
> > > header is added to the lib folder which fails to compile when included
> > > alone, the build of chkincs will fail with a suitable error message.
> > > Since this compile checking is not needed on most builds of DPDK, the
> > > building of chkincs is disabled by default, but can be enabled by the
> > > "test_includes" meson option. To catch errors with patch submissions,
> > > the final patch of this series enables it for a single build in
> > > test-meson-builds script.
> > >
> > > Future work could involve doing similar checks on headers for C++
> > > compatibility, which was something done by the check-includes.sh script
> > > but which is missing here..
> > >
> > > V3:
> > > * Shrunk patchset as most header fixes already applied
> > > * Moved chkincs from "apps" to the "buildtools" directory, which is a
> > > better location for something not for installation for end-user use.
> > > * Added patch to drop check-includes script.
> > >
> > > V2:
> > > * Add maintainers file entry for new app
> > > * Drop patch for c11 ring header
> > > * Use build variable "headers_no_chkincs" for tracking exceptions
> > >
> > > Bruce Richardson (4):
> > > eal: add missing include to mcslock
> > > build: separate out headers for include checking
> > > buildtools/chkincs: add app to verify header includes
> > > devtools: remove check-includes script
> > >
> > > MAINTAINERS | 5 +-
> > > buildtools/chkincs/gen_c_file_for_header.py | 12 +
> > > buildtools/chkincs/main.c | 4 +
> > > buildtools/chkincs/meson.build | 40 +++
> > > devtools/check-includes.sh | 259 -------------------
> > > devtools/test-meson-builds.sh | 2 +-
> > > doc/guides/contributing/coding_style.rst | 12 +
> > > lib/librte_eal/include/generic/rte_mcslock.h | 1 +
> > > lib/librte_eal/include/meson.build | 2 +-
> > > lib/librte_eal/x86/include/meson.build | 14 +-
> > > lib/librte_ethdev/meson.build | 4 +-
> > > lib/librte_hash/meson.build | 4 +-
> > > lib/librte_ipsec/meson.build | 3 +-
> > > lib/librte_lpm/meson.build | 2 +-
> > > lib/librte_regexdev/meson.build | 2 +-
> > > lib/librte_ring/meson.build | 4 +-
> > > lib/librte_stack/meson.build | 4 +-
> > > lib/librte_table/meson.build | 7 +-
> > > lib/meson.build | 3 +
> > > meson.build | 6 +
> > > meson_options.txt | 2 +
> > > 21 files changed, 112 insertions(+), 280 deletions(-)
> > > create mode 100755 buildtools/chkincs/gen_c_file_for_header.py
> > > create mode 100644 buildtools/chkincs/main.c
> > > create mode 100644 buildtools/chkincs/meson.build
> > > delete mode 100755 devtools/check-includes.sh
> >
> > - clang is not happy when enabling the check:
> > $ meson configure $HOME/builds/build-clang-static -Dcheck_includes=true
> > $ devtools/test-meson-builds.sh
> > ...
> > [362/464] Compiling C object
> > buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_vdev.c.o
> > FAILED: buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_vdev.c.o
> > clang -Ibuildtools/chkincs/chkincs.p -Ibuildtools/chkincs
> > -I../../dpdk/buildtools/chkincs -Idrivers/bus/pci
> > -I../../dpdk/drivers/bus/pci -Idrivers/bus/vdev
> > -I../../dpdk/drivers/bus/vdev -I. -I../../dpdk -Iconfig
> > -I../../dpdk/config -Ilib/librte_eal/include
> > -I../../dpdk/lib/librte_eal/include -Ilib/librte_eal/linux/include
> > -I../../dpdk/lib/librte_eal/linux/include -Ilib/librte_eal/x86/include
> > -I../../dpdk/lib/librte_eal/x86/include -Ilib/librte_kvargs
> > -I../../dpdk/lib/librte_kvargs -Ilib/librte_metrics
> > -I../../dpdk/lib/librte_metrics -Ilib/librte_telemetry
> > -I../../dpdk/lib/librte_telemetry -Ilib/librte_eal/common
> > -I../../dpdk/lib/librte_eal/common -Ilib/librte_eal
> > -I../../dpdk/lib/librte_eal -Ilib/librte_ring
> > -I../../dpdk/lib/librte_ring -Ilib/librte_rcu
> > -I../../dpdk/lib/librte_rcu -Ilib/librte_mempool
> > -I../../dpdk/lib/librte_mempool -Ilib/librte_mbuf
> > -I../../dpdk/lib/librte_mbuf -Ilib/librte_net
> > -I../../dpdk/lib/librte_net -Ilib/librte_meter
> > -I../../dpdk/lib/librte_meter -Ilib/librte_ethdev
> > -I../../dpdk/lib/librte_ethdev -Ilib/librte_pci
> > -I../../dpdk/lib/librte_pci -Ilib/librte_cmdline
> > -I../../dpdk/lib/librte_cmdline -Ilib/librte_hash
> > -I../../dpdk/lib/librte_hash -Ilib/librte_timer
> > -I../../dpdk/lib/librte_timer -Ilib/librte_acl
> > -I../../dpdk/lib/librte_acl -Ilib/librte_bbdev
> > -I../../dpdk/lib/librte_bbdev -Ilib/librte_bitratestats
> > -I../../dpdk/lib/librte_bitratestats -Ilib/librte_cfgfile
> > -I../../dpdk/lib/librte_cfgfile -Ilib/librte_compressdev
> > -I../../dpdk/lib/librte_compressdev -Ilib/librte_cryptodev
> > -I../../dpdk/lib/librte_cryptodev -Ilib/librte_distributor
> > -I../../dpdk/lib/librte_distributor -Ilib/librte_efd
> > -I../../dpdk/lib/librte_efd -Ilib/librte_eventdev
> > -I../../dpdk/lib/librte_eventdev -Ilib/librte_gro
> > -I../../dpdk/lib/librte_gro -Ilib/librte_gso
> > -I../../dpdk/lib/librte_gso -Ilib/librte_ip_frag
> > -I../../dpdk/lib/librte_ip_frag -Ilib/librte_jobstats
> > -I../../dpdk/lib/librte_jobstats -Ilib/librte_kni
> > -I../../dpdk/lib/librte_kni -Ilib/librte_latencystats
> > -I../../dpdk/lib/librte_latencystats -Ilib/librte_lpm
> > -I../../dpdk/lib/librte_lpm -Ilib/librte_member
> > -I../../dpdk/lib/librte_member -Ilib/librte_power
> > -I../../dpdk/lib/librte_power -Ilib/librte_pdump
> > -I../../dpdk/lib/librte_pdump -Ilib/librte_rawdev
> > -I../../dpdk/lib/librte_rawdev -Ilib/librte_regexdev
> > -I../../dpdk/lib/librte_regexdev -Ilib/librte_rib
> > -I../../dpdk/lib/librte_rib -Ilib/librte_reorder
> > -I../../dpdk/lib/librte_reorder -Ilib/librte_sched
> > -I../../dpdk/lib/librte_sched -Ilib/librte_security
> > -I../../dpdk/lib/librte_security -Ilib/librte_stack
> > -I../../dpdk/lib/librte_stack -Ilib/librte_vhost
> > -I../../dpdk/lib/librte_vhost -Ilib/librte_ipsec
> > -I../../dpdk/lib/librte_ipsec -Ilib/librte_fib
> > -I../../dpdk/lib/librte_fib -Ilib/librte_port
> > -I../../dpdk/lib/librte_port -Ilib/librte_table
> > -I../../dpdk/lib/librte_table -Ilib/librte_pipeline
> > -I../../dpdk/lib/librte_pipeline -Ilib/librte_flow_classify
> > -I../../dpdk/lib/librte_flow_classify -Ilib/librte_bpf
> > -I../../dpdk/lib/librte_bpf -Ilib/librte_graph
> > -I../../dpdk/lib/librte_graph -Ilib/librte_node
> > -I../../dpdk/lib/librte_node
> > -I/home/dmarchan/intel-ipsec-mb/install/include -Xclang
> > -fcolor-diagnostics -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
> > -Werror -O2 -g -include rte_config.h -Wextra -Wcast-qual -Wdeprecated
> > -Wformat -Wformat-nonliteral -Wformat-security -Wmissing-declarations
> > -Wmissing-prototypes -Wnested-externs -Wold-style-definition
> > -Wpointer-arith -Wsign-compare -Wstrict-prototypes -Wundef
> > -Wwrite-strings -Wno-address-of-packed-member
> > -Wno-missing-field-initializers -D_GNU_SOURCE -march=native
> > -Wno-unused-function -DALLOW_EXPERIMENTAL_API -MD -MQ
> > buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_vdev.c.o -MF
> > buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_vdev.c.o.d -o
> > buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_vdev.c.o -c
> > buildtools/chkincs/chkincs.p/rte_ethdev_vdev.c
> > In file included from buildtools/chkincs/chkincs.p/rte_ethdev_vdev.c:1:
> > In file included from
> > /home/dmarchan/dpdk/lib/librte_ethdev/rte_ethdev_vdev.h:12:
> > ../../dpdk/lib/librte_ethdev/rte_ethdev_driver.h:964:1: error: unknown
> > attribute 'error' ignored [-Werror,-Wunknown-attributes]
> > __rte_internal
> > ^
> > ../../dpdk/lib/librte_eal/include/rte_compat.h:25:16: note: expanded
> > from macro '__rte_internal'
> > __attribute__((error("Symbol is not public ABI"), \
> > ^
> >
>
> This looks to be a real issue with our header file - clang does not have an
> "error" attribute. The closest equivalent I can see is "diagnose_if".
Indeed, it does trigger a build error, so it works as expected ;-).
On the header check itself, even if we find a way to properly tag
those symbols with the macro in rte_compat.h, the next issue is that
clang complains about such marked symbols without the
ALLOW_INTERNAL_API build flag.
FAILED: buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_pci.c.o
clang -Ibuildtools/chkincs/chkincs.p -Ibuildtools/chkincs
-I../../dpdk/buildtools/chkincs -Idrivers/bus/pci
-I../../dpdk/drivers/bus/pci -Idrivers/bus/vdev
-I../../dpdk/drivers/bus/vdev -I. -I../../dpdk -Iconfig
-I../../dpdk/config -Ilib/librte_eal/include
-I../../dpdk/lib/librte_eal/include -Ilib/librte_eal/linux/include
-I../../dpdk/lib/librte_eal/linux/include -Ilib/librte_eal/x86/include
-I../../dpdk/lib/librte_eal/x86/include -Ilib/librte_kvargs
-I../../dpdk/lib/librte_kvargs -Ilib/librte_metrics
-I../../dpdk/lib/librte_metrics -Ilib/librte_telemetry
-I../../dpdk/lib/librte_telemetry -Ilib/librte_eal/common
-I../../dpdk/lib/librte_eal/common -Ilib/librte_eal
-I../../dpdk/lib/librte_eal -Ilib/librte_ring
-I../../dpdk/lib/librte_ring -Ilib/librte_rcu
-I../../dpdk/lib/librte_rcu -Ilib/librte_mempool
-I../../dpdk/lib/librte_mempool -Ilib/librte_mbuf
-I../../dpdk/lib/librte_mbuf -Ilib/librte_net
-I../../dpdk/lib/librte_net -Ilib/librte_meter
-I../../dpdk/lib/librte_meter -Ilib/librte_ethdev
-I../../dpdk/lib/librte_ethdev -Ilib/librte_pci
-I../../dpdk/lib/librte_pci -Ilib/librte_cmdline
-I../../dpdk/lib/librte_cmdline -Ilib/librte_hash
-I../../dpdk/lib/librte_hash -Ilib/librte_timer
-I../../dpdk/lib/librte_timer -Ilib/librte_acl
-I../../dpdk/lib/librte_acl -Ilib/librte_bbdev
-I../../dpdk/lib/librte_bbdev -Ilib/librte_bitratestats
-I../../dpdk/lib/librte_bitratestats -Ilib/librte_cfgfile
-I../../dpdk/lib/librte_cfgfile -Ilib/librte_compressdev
-I../../dpdk/lib/librte_compressdev -Ilib/librte_cryptodev
-I../../dpdk/lib/librte_cryptodev -Ilib/librte_distributor
-I../../dpdk/lib/librte_distributor -Ilib/librte_efd
-I../../dpdk/lib/librte_efd -Ilib/librte_eventdev
-I../../dpdk/lib/librte_eventdev -Ilib/librte_gro
-I../../dpdk/lib/librte_gro -Ilib/librte_gso
-I../../dpdk/lib/librte_gso -Ilib/librte_ip_frag
-I../../dpdk/lib/librte_ip_frag -Ilib/librte_jobstats
-I../../dpdk/lib/librte_jobstats -Ilib/librte_kni
-I../../dpdk/lib/librte_kni -Ilib/librte_latencystats
-I../../dpdk/lib/librte_latencystats -Ilib/librte_lpm
-I../../dpdk/lib/librte_lpm -Ilib/librte_member
-I../../dpdk/lib/librte_member -Ilib/librte_power
-I../../dpdk/lib/librte_power -Ilib/librte_pdump
-I../../dpdk/lib/librte_pdump -Ilib/librte_rawdev
-I../../dpdk/lib/librte_rawdev -Ilib/librte_regexdev
-I../../dpdk/lib/librte_regexdev -Ilib/librte_rib
-I../../dpdk/lib/librte_rib -Ilib/librte_reorder
-I../../dpdk/lib/librte_reorder -Ilib/librte_sched
-I../../dpdk/lib/librte_sched -Ilib/librte_security
-I../../dpdk/lib/librte_security -Ilib/librte_stack
-I../../dpdk/lib/librte_stack -Ilib/librte_vhost
-I../../dpdk/lib/librte_vhost -Ilib/librte_ipsec
-I../../dpdk/lib/librte_ipsec -Ilib/librte_fib
-I../../dpdk/lib/librte_fib -Ilib/librte_port
-I../../dpdk/lib/librte_port -Ilib/librte_table
-I../../dpdk/lib/librte_table -Ilib/librte_pipeline
-I../../dpdk/lib/librte_pipeline -Ilib/librte_flow_classify
-I../../dpdk/lib/librte_flow_classify -Ilib/librte_bpf
-I../../dpdk/lib/librte_bpf -Ilib/librte_graph
-I../../dpdk/lib/librte_graph -Ilib/librte_node
-I../../dpdk/lib/librte_node
-I/home/dmarchan/intel-ipsec-mb/install/include -Xclang
-fcolor-diagnostics -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
-Werror -O2 -g -include rte_config.h -Wextra -Wcast-qual -Wdeprecated
-Wformat -Wformat-nonliteral -Wformat-security -Wmissing-declarations
-Wmissing-prototypes -Wnested-externs -Wold-style-definition
-Wpointer-arith -Wsign-compare -Wstrict-prototypes -Wundef
-Wwrite-strings -Wno-address-of-packed-member
-Wno-missing-field-initializers -D_GNU_SOURCE -march=native
-Wno-unused-function -DALLOW_EXPERIMENTAL_API -MD -MQ
buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_pci.c.o -MF
buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_pci.c.o.d -o
buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_pci.c.o -c
buildtools/chkincs/chkincs.p/rte_ethdev_pci.c
In file included from buildtools/chkincs/chkincs.p/rte_ethdev_pci.c:1:
/home/dmarchan/dpdk/lib/librte_ethdev/rte_ethdev_pci.h:86:13: error:
Symbol is not public ABI
eth_dev = rte_eth_dev_allocate(name);
^
../../dpdk/lib/librte_ethdev/rte_ethdev_driver.h:1003:1: note: from
'diagnose_if' attribute on 'rte_eth_dev_allocate':
__rte_internal
^~~~~~~~~~~~~~
../../dpdk/lib/librte_eal/include/rte_compat.h:30:16: note: expanded
from macro '__rte_internal'
__attribute__((diagnose_if(1, "Symbol is not public ABI", "error"), \
^ ~
[...]
gcc seems more lenient about this.
> Therefore, I'd suggest we need to change compat.h to be something like:
>
> #if !defined ALLOW_INTERNAL_API && __has_attribute(error) /* For GCC */
>
> #define __rte_internal \
> __attribute__((error("Symbol is not public ABI"), \
> section(".text.internal")))
>
> #elif !defined ALLOW_INTERNAL_API && __has_attribute(diagnose_if) /* For clang */
>
> #define __rte_internal \
> __attribute__((diagnose_if(1, "Symbol is not public ABI", "error"), \
> section(".text.internal")))
>
> #else
>
> #define __rte_internal \
> __attribute__((section(".text.internal")))
>
> #endif
>
> Any thoughts or suggestions for better alternatives here?
I'd rather leave a build error on an unknown attribute than silence
this check (which happens in your snippet, where it falls back to the
#else part).
Did you consider the deprecated() like for the experimental tag?
--
David Marchand
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v4 2/7] eal: fix error attribute use for clang
@ 2021-01-26 14:18 13% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2021-01-26 14:18 UTC (permalink / raw)
To: dev
Cc: david.marchand, Bruce Richardson, haiyue.wang, Ray Kinsella, Neil Horman
Clang does not have an "error" attribute for functions, so for marking
internal functions we need to check for the error attribute, and provide
a fallback if it is not present. For clang, we can use "diagnose_if"
attribute, similarly checking for its presence before use.
Fixes: fba5af82adc8 ("eal: add internal ABI tag definition")
Cc: haiyue.wang@intel.com
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
lib/librte_eal/include/rte_compat.h | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/lib/librte_eal/include/rte_compat.h b/lib/librte_eal/include/rte_compat.h
index 4cd8f68d68..c30f072aa3 100644
--- a/lib/librte_eal/include/rte_compat.h
+++ b/lib/librte_eal/include/rte_compat.h
@@ -19,12 +19,18 @@ __attribute__((section(".text.experimental")))
#endif
-#ifndef ALLOW_INTERNAL_API
+#if !defined ALLOW_INTERNAL_API && __has_attribute(error) /* For GCC */
#define __rte_internal \
__attribute__((error("Symbol is not public ABI"), \
section(".text.internal")))
+#elif !defined ALLOW_INTERNAL_API && __has_attribute(diagnose_if) /* For clang */
+
+#define __rte_internal \
+__attribute__((diagnose_if(1, "Symbol is not public ABI", "error"), \
+section(".text.internal")))
+
#else
#define __rte_internal \
--
2.27.0
^ permalink raw reply [relevance 13%]
* Re: [dpdk-dev] [PATCH v3 0/4] add checking of header includes
2021-01-26 14:04 3% ` David Marchand
@ 2021-01-26 14:24 0% ` Bruce Richardson
2021-01-26 14:39 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2021-01-26 14:24 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Thomas Monjalon
On Tue, Jan 26, 2021 at 03:04:25PM +0100, David Marchand wrote:
> On Tue, Jan 26, 2021 at 12:15 PM Bruce Richardson
> <bruce.richardson@intel.com> wrote:
> >
> > On Mon, Jan 25, 2021 at 04:51:19PM +0100, David Marchand wrote:
> > > On Mon, Jan 25, 2021 at 3:11 PM Bruce Richardson
> > > <bruce.richardson@intel.com> wrote:
> > > >
> > > > As a general principle, each header file should include any other
> > > > headers it needs to provide data type definitions or macros. For
> > > > example, any header using the uintX_t types in structures or function
> > > > prototypes should include "stdint.h" to provide those type definitions.
> > > >
> > > > In practice, while many, but not all, headers in DPDK did include all
> > > > necessary headers, it was never actually checked that each header could
> > > > be included in a C file and compiled without having any compiler errors
> > > > about missing definitions. The script "check-includes.sh" could be used
> > > > for this job, but it was not called out in the documentation, so many
> > > > contributors may not have been aware of it's existance. It also was
> > > > difficult to run from a source-code directory, as the script did not
> > > > automatically allow finding of headers from one DPDK library directory
> > > > to another [this was probably based on running it on a build created by
> > > > the "make" build system, where all headers were in a single directory].
> > > > To attempt to have a build-system integrated replacement, this patchset
> > > > adds a "chkincs" app in the buildtools directory to verify this on an
> > > > ongoing basis.
> > > >
> > > > This chkincs app does nothing when run, and is not installed as part of
> > > > a DPDK "ninja install", it's for build-time checking only. Its source
> > > > code consists of one C file per public DPDK header, where that C file
> > > > contains nothing except an include for that header. Therefore, if any
> > > > header is added to the lib folder which fails to compile when included
> > > > alone, the build of chkincs will fail with a suitable error message.
> > > > Since this compile checking is not needed on most builds of DPDK, the
> > > > building of chkincs is disabled by default, but can be enabled by the
> > > > "test_includes" meson option. To catch errors with patch submissions,
> > > > the final patch of this series enables it for a single build in
> > > > test-meson-builds script.
> > > >
> > > > Future work could involve doing similar checks on headers for C++
> > > > compatibility, which was something done by the check-includes.sh script
> > > > but which is missing here..
> > > >
> > > > V3:
> > > > * Shrunk patchset as most header fixes already applied
> > > > * Moved chkincs from "apps" to the "buildtools" directory, which is a
> > > > better location for something not for installation for end-user use.
> > > > * Added patch to drop check-includes script.
> > > >
> > > > V2:
> > > > * Add maintainers file entry for new app
> > > > * Drop patch for c11 ring header
> > > > * Use build variable "headers_no_chkincs" for tracking exceptions
> > > >
> > > > Bruce Richardson (4):
> > > > eal: add missing include to mcslock
> > > > build: separate out headers for include checking
> > > > buildtools/chkincs: add app to verify header includes
> > > > devtools: remove check-includes script
> > > >
> > > > MAINTAINERS | 5 +-
> > > > buildtools/chkincs/gen_c_file_for_header.py | 12 +
> > > > buildtools/chkincs/main.c | 4 +
> > > > buildtools/chkincs/meson.build | 40 +++
> > > > devtools/check-includes.sh | 259 -------------------
> > > > devtools/test-meson-builds.sh | 2 +-
> > > > doc/guides/contributing/coding_style.rst | 12 +
> > > > lib/librte_eal/include/generic/rte_mcslock.h | 1 +
> > > > lib/librte_eal/include/meson.build | 2 +-
> > > > lib/librte_eal/x86/include/meson.build | 14 +-
> > > > lib/librte_ethdev/meson.build | 4 +-
> > > > lib/librte_hash/meson.build | 4 +-
> > > > lib/librte_ipsec/meson.build | 3 +-
> > > > lib/librte_lpm/meson.build | 2 +-
> > > > lib/librte_regexdev/meson.build | 2 +-
> > > > lib/librte_ring/meson.build | 4 +-
> > > > lib/librte_stack/meson.build | 4 +-
> > > > lib/librte_table/meson.build | 7 +-
> > > > lib/meson.build | 3 +
> > > > meson.build | 6 +
> > > > meson_options.txt | 2 +
> > > > 21 files changed, 112 insertions(+), 280 deletions(-)
> > > > create mode 100755 buildtools/chkincs/gen_c_file_for_header.py
> > > > create mode 100644 buildtools/chkincs/main.c
> > > > create mode 100644 buildtools/chkincs/meson.build
> > > > delete mode 100755 devtools/check-includes.sh
> > >
> > > - clang is not happy when enabling the check:
> > > $ meson configure $HOME/builds/build-clang-static -Dcheck_includes=true
> > > $ devtools/test-meson-builds.sh
> > > ...
> > > [362/464] Compiling C object
> > > buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_vdev.c.o
> > > FAILED: buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_vdev.c.o
> > > clang -Ibuildtools/chkincs/chkincs.p -Ibuildtools/chkincs
> > > -I../../dpdk/buildtools/chkincs -Idrivers/bus/pci
> > > -I../../dpdk/drivers/bus/pci -Idrivers/bus/vdev
> > > -I../../dpdk/drivers/bus/vdev -I. -I../../dpdk -Iconfig
> > > -I../../dpdk/config -Ilib/librte_eal/include
> > > -I../../dpdk/lib/librte_eal/include -Ilib/librte_eal/linux/include
> > > -I../../dpdk/lib/librte_eal/linux/include -Ilib/librte_eal/x86/include
> > > -I../../dpdk/lib/librte_eal/x86/include -Ilib/librte_kvargs
> > > -I../../dpdk/lib/librte_kvargs -Ilib/librte_metrics
> > > -I../../dpdk/lib/librte_metrics -Ilib/librte_telemetry
> > > -I../../dpdk/lib/librte_telemetry -Ilib/librte_eal/common
> > > -I../../dpdk/lib/librte_eal/common -Ilib/librte_eal
> > > -I../../dpdk/lib/librte_eal -Ilib/librte_ring
> > > -I../../dpdk/lib/librte_ring -Ilib/librte_rcu
> > > -I../../dpdk/lib/librte_rcu -Ilib/librte_mempool
> > > -I../../dpdk/lib/librte_mempool -Ilib/librte_mbuf
> > > -I../../dpdk/lib/librte_mbuf -Ilib/librte_net
> > > -I../../dpdk/lib/librte_net -Ilib/librte_meter
> > > -I../../dpdk/lib/librte_meter -Ilib/librte_ethdev
> > > -I../../dpdk/lib/librte_ethdev -Ilib/librte_pci
> > > -I../../dpdk/lib/librte_pci -Ilib/librte_cmdline
> > > -I../../dpdk/lib/librte_cmdline -Ilib/librte_hash
> > > -I../../dpdk/lib/librte_hash -Ilib/librte_timer
> > > -I../../dpdk/lib/librte_timer -Ilib/librte_acl
> > > -I../../dpdk/lib/librte_acl -Ilib/librte_bbdev
> > > -I../../dpdk/lib/librte_bbdev -Ilib/librte_bitratestats
> > > -I../../dpdk/lib/librte_bitratestats -Ilib/librte_cfgfile
> > > -I../../dpdk/lib/librte_cfgfile -Ilib/librte_compressdev
> > > -I../../dpdk/lib/librte_compressdev -Ilib/librte_cryptodev
> > > -I../../dpdk/lib/librte_cryptodev -Ilib/librte_distributor
> > > -I../../dpdk/lib/librte_distributor -Ilib/librte_efd
> > > -I../../dpdk/lib/librte_efd -Ilib/librte_eventdev
> > > -I../../dpdk/lib/librte_eventdev -Ilib/librte_gro
> > > -I../../dpdk/lib/librte_gro -Ilib/librte_gso
> > > -I../../dpdk/lib/librte_gso -Ilib/librte_ip_frag
> > > -I../../dpdk/lib/librte_ip_frag -Ilib/librte_jobstats
> > > -I../../dpdk/lib/librte_jobstats -Ilib/librte_kni
> > > -I../../dpdk/lib/librte_kni -Ilib/librte_latencystats
> > > -I../../dpdk/lib/librte_latencystats -Ilib/librte_lpm
> > > -I../../dpdk/lib/librte_lpm -Ilib/librte_member
> > > -I../../dpdk/lib/librte_member -Ilib/librte_power
> > > -I../../dpdk/lib/librte_power -Ilib/librte_pdump
> > > -I../../dpdk/lib/librte_pdump -Ilib/librte_rawdev
> > > -I../../dpdk/lib/librte_rawdev -Ilib/librte_regexdev
> > > -I../../dpdk/lib/librte_regexdev -Ilib/librte_rib
> > > -I../../dpdk/lib/librte_rib -Ilib/librte_reorder
> > > -I../../dpdk/lib/librte_reorder -Ilib/librte_sched
> > > -I../../dpdk/lib/librte_sched -Ilib/librte_security
> > > -I../../dpdk/lib/librte_security -Ilib/librte_stack
> > > -I../../dpdk/lib/librte_stack -Ilib/librte_vhost
> > > -I../../dpdk/lib/librte_vhost -Ilib/librte_ipsec
> > > -I../../dpdk/lib/librte_ipsec -Ilib/librte_fib
> > > -I../../dpdk/lib/librte_fib -Ilib/librte_port
> > > -I../../dpdk/lib/librte_port -Ilib/librte_table
> > > -I../../dpdk/lib/librte_table -Ilib/librte_pipeline
> > > -I../../dpdk/lib/librte_pipeline -Ilib/librte_flow_classify
> > > -I../../dpdk/lib/librte_flow_classify -Ilib/librte_bpf
> > > -I../../dpdk/lib/librte_bpf -Ilib/librte_graph
> > > -I../../dpdk/lib/librte_graph -Ilib/librte_node
> > > -I../../dpdk/lib/librte_node
> > > -I/home/dmarchan/intel-ipsec-mb/install/include -Xclang
> > > -fcolor-diagnostics -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
> > > -Werror -O2 -g -include rte_config.h -Wextra -Wcast-qual -Wdeprecated
> > > -Wformat -Wformat-nonliteral -Wformat-security -Wmissing-declarations
> > > -Wmissing-prototypes -Wnested-externs -Wold-style-definition
> > > -Wpointer-arith -Wsign-compare -Wstrict-prototypes -Wundef
> > > -Wwrite-strings -Wno-address-of-packed-member
> > > -Wno-missing-field-initializers -D_GNU_SOURCE -march=native
> > > -Wno-unused-function -DALLOW_EXPERIMENTAL_API -MD -MQ
> > > buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_vdev.c.o -MF
> > > buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_vdev.c.o.d -o
> > > buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_vdev.c.o -c
> > > buildtools/chkincs/chkincs.p/rte_ethdev_vdev.c
> > > In file included from buildtools/chkincs/chkincs.p/rte_ethdev_vdev.c:1:
> > > In file included from
> > > /home/dmarchan/dpdk/lib/librte_ethdev/rte_ethdev_vdev.h:12:
> > > ../../dpdk/lib/librte_ethdev/rte_ethdev_driver.h:964:1: error: unknown
> > > attribute 'error' ignored [-Werror,-Wunknown-attributes]
> > > __rte_internal
> > > ^
> > > ../../dpdk/lib/librte_eal/include/rte_compat.h:25:16: note: expanded
> > > from macro '__rte_internal'
> > > __attribute__((error("Symbol is not public ABI"), \
> > > ^
> > >
> >
> > This looks to be a real issue with our header file - clang does not have an
> > "error" attribute. The closest equivalent I can see is "diagnose_if".
>
> Indeed, it does trigger a build error, so it works as expected ;-).
>
>
> On the header check itself, even if we find a way to properly tag
> those symbols with the macro in rte_compat.h, the next issue is that
> clang complains about such marked symbols without the
> ALLOW_INTERNAL_API build flag.
>
> FAILED: buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_pci.c.o
> clang -Ibuildtools/chkincs/chkincs.p -Ibuildtools/chkincs
> -I../../dpdk/buildtools/chkincs -Idrivers/bus/pci
> -I../../dpdk/drivers/bus/pci -Idrivers/bus/vdev
> -I../../dpdk/drivers/bus/vdev -I. -I../../dpdk -Iconfig
> -I../../dpdk/config -Ilib/librte_eal/include
> -I../../dpdk/lib/librte_eal/include -Ilib/librte_eal/linux/include
> -I../../dpdk/lib/librte_eal/linux/include -Ilib/librte_eal/x86/include
> -I../../dpdk/lib/librte_eal/x86/include -Ilib/librte_kvargs
> -I../../dpdk/lib/librte_kvargs -Ilib/librte_metrics
> -I../../dpdk/lib/librte_metrics -Ilib/librte_telemetry
> -I../../dpdk/lib/librte_telemetry -Ilib/librte_eal/common
> -I../../dpdk/lib/librte_eal/common -Ilib/librte_eal
> -I../../dpdk/lib/librte_eal -Ilib/librte_ring
> -I../../dpdk/lib/librte_ring -Ilib/librte_rcu
> -I../../dpdk/lib/librte_rcu -Ilib/librte_mempool
> -I../../dpdk/lib/librte_mempool -Ilib/librte_mbuf
> -I../../dpdk/lib/librte_mbuf -Ilib/librte_net
> -I../../dpdk/lib/librte_net -Ilib/librte_meter
> -I../../dpdk/lib/librte_meter -Ilib/librte_ethdev
> -I../../dpdk/lib/librte_ethdev -Ilib/librte_pci
> -I../../dpdk/lib/librte_pci -Ilib/librte_cmdline
> -I../../dpdk/lib/librte_cmdline -Ilib/librte_hash
> -I../../dpdk/lib/librte_hash -Ilib/librte_timer
> -I../../dpdk/lib/librte_timer -Ilib/librte_acl
> -I../../dpdk/lib/librte_acl -Ilib/librte_bbdev
> -I../../dpdk/lib/librte_bbdev -Ilib/librte_bitratestats
> -I../../dpdk/lib/librte_bitratestats -Ilib/librte_cfgfile
> -I../../dpdk/lib/librte_cfgfile -Ilib/librte_compressdev
> -I../../dpdk/lib/librte_compressdev -Ilib/librte_cryptodev
> -I../../dpdk/lib/librte_cryptodev -Ilib/librte_distributor
> -I../../dpdk/lib/librte_distributor -Ilib/librte_efd
> -I../../dpdk/lib/librte_efd -Ilib/librte_eventdev
> -I../../dpdk/lib/librte_eventdev -Ilib/librte_gro
> -I../../dpdk/lib/librte_gro -Ilib/librte_gso
> -I../../dpdk/lib/librte_gso -Ilib/librte_ip_frag
> -I../../dpdk/lib/librte_ip_frag -Ilib/librte_jobstats
> -I../../dpdk/lib/librte_jobstats -Ilib/librte_kni
> -I../../dpdk/lib/librte_kni -Ilib/librte_latencystats
> -I../../dpdk/lib/librte_latencystats -Ilib/librte_lpm
> -I../../dpdk/lib/librte_lpm -Ilib/librte_member
> -I../../dpdk/lib/librte_member -Ilib/librte_power
> -I../../dpdk/lib/librte_power -Ilib/librte_pdump
> -I../../dpdk/lib/librte_pdump -Ilib/librte_rawdev
> -I../../dpdk/lib/librte_rawdev -Ilib/librte_regexdev
> -I../../dpdk/lib/librte_regexdev -Ilib/librte_rib
> -I../../dpdk/lib/librte_rib -Ilib/librte_reorder
> -I../../dpdk/lib/librte_reorder -Ilib/librte_sched
> -I../../dpdk/lib/librte_sched -Ilib/librte_security
> -I../../dpdk/lib/librte_security -Ilib/librte_stack
> -I../../dpdk/lib/librte_stack -Ilib/librte_vhost
> -I../../dpdk/lib/librte_vhost -Ilib/librte_ipsec
> -I../../dpdk/lib/librte_ipsec -Ilib/librte_fib
> -I../../dpdk/lib/librte_fib -Ilib/librte_port
> -I../../dpdk/lib/librte_port -Ilib/librte_table
> -I../../dpdk/lib/librte_table -Ilib/librte_pipeline
> -I../../dpdk/lib/librte_pipeline -Ilib/librte_flow_classify
> -I../../dpdk/lib/librte_flow_classify -Ilib/librte_bpf
> -I../../dpdk/lib/librte_bpf -Ilib/librte_graph
> -I../../dpdk/lib/librte_graph -Ilib/librte_node
> -I../../dpdk/lib/librte_node
> -I/home/dmarchan/intel-ipsec-mb/install/include -Xclang
> -fcolor-diagnostics -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
> -Werror -O2 -g -include rte_config.h -Wextra -Wcast-qual -Wdeprecated
> -Wformat -Wformat-nonliteral -Wformat-security -Wmissing-declarations
> -Wmissing-prototypes -Wnested-externs -Wold-style-definition
> -Wpointer-arith -Wsign-compare -Wstrict-prototypes -Wundef
> -Wwrite-strings -Wno-address-of-packed-member
> -Wno-missing-field-initializers -D_GNU_SOURCE -march=native
> -Wno-unused-function -DALLOW_EXPERIMENTAL_API -MD -MQ
> buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_pci.c.o -MF
> buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_pci.c.o.d -o
> buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_pci.c.o -c
> buildtools/chkincs/chkincs.p/rte_ethdev_pci.c
> In file included from buildtools/chkincs/chkincs.p/rte_ethdev_pci.c:1:
> /home/dmarchan/dpdk/lib/librte_ethdev/rte_ethdev_pci.h:86:13: error:
> Symbol is not public ABI
> eth_dev = rte_eth_dev_allocate(name);
> ^
> ../../dpdk/lib/librte_ethdev/rte_ethdev_driver.h:1003:1: note: from
> 'diagnose_if' attribute on 'rte_eth_dev_allocate':
> __rte_internal
> ^~~~~~~~~~~~~~
> ../../dpdk/lib/librte_eal/include/rte_compat.h:30:16: note: expanded
> from macro '__rte_internal'
> __attribute__((diagnose_if(1, "Symbol is not public ABI", "error"), \
> ^ ~
> [...]
>
>
> gcc seems more lenient about this.
>
>
>
> > Therefore, I'd suggest we need to change compat.h to be something like:
> >
> > #if !defined ALLOW_INTERNAL_API && __has_attribute(error) /* For GCC */
> >
> > #define __rte_internal \
> > __attribute__((error("Symbol is not public ABI"), \
> > section(".text.internal")))
> >
> > #elif !defined ALLOW_INTERNAL_API && __has_attribute(diagnose_if) /* For clang */
> >
> > #define __rte_internal \
> > __attribute__((diagnose_if(1, "Symbol is not public ABI", "error"), \
> > section(".text.internal")))
> >
> > #else
> >
> > #define __rte_internal \
> > __attribute__((section(".text.internal")))
> >
> > #endif
> >
> > Any thoughts or suggestions for better alternatives here?
>
> I'd rather leave a build error on an unknown attribute than silence
> this check (which happens in your snippet, where it falls back to the
> #else part).
>
> Did you consider the deprecated() like for the experimental tag?
>
I've added the ALLOW_INTERNAL_API define to the build of these headers in
v4.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3 0/4] add checking of header includes
2021-01-26 14:24 0% ` Bruce Richardson
@ 2021-01-26 14:39 0% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2021-01-26 14:39 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Thomas Monjalon, ferruh.yigit
On Tue, Jan 26, 2021 at 02:24:02PM +0000, Bruce Richardson wrote:
> On Tue, Jan 26, 2021 at 03:04:25PM +0100, David Marchand wrote:
> > On Tue, Jan 26, 2021 at 12:15 PM Bruce Richardson
> > <bruce.richardson@intel.com> wrote:
> > >
> > > On Mon, Jan 25, 2021 at 04:51:19PM +0100, David Marchand wrote:
> > > > On Mon, Jan 25, 2021 at 3:11 PM Bruce Richardson
> > > > <bruce.richardson@intel.com> wrote:
> > > > >
> > > > > As a general principle, each header file should include any other
> > > > > headers it needs to provide data type definitions or macros. For
> > > > > example, any header using the uintX_t types in structures or function
> > > > > prototypes should include "stdint.h" to provide those type definitions.
> > > > >
> > > > > In practice, while many, but not all, headers in DPDK did include all
> > > > > necessary headers, it was never actually checked that each header could
> > > > > be included in a C file and compiled without having any compiler errors
> > > > > about missing definitions. The script "check-includes.sh" could be used
> > > > > for this job, but it was not called out in the documentation, so many
> > > > > contributors may not have been aware of it's existance. It also was
> > > > > difficult to run from a source-code directory, as the script did not
> > > > > automatically allow finding of headers from one DPDK library directory
> > > > > to another [this was probably based on running it on a build created by
> > > > > the "make" build system, where all headers were in a single directory].
> > > > > To attempt to have a build-system integrated replacement, this patchset
> > > > > adds a "chkincs" app in the buildtools directory to verify this on an
> > > > > ongoing basis.
> > > > >
> > > > > This chkincs app does nothing when run, and is not installed as part of
> > > > > a DPDK "ninja install", it's for build-time checking only. Its source
> > > > > code consists of one C file per public DPDK header, where that C file
> > > > > contains nothing except an include for that header. Therefore, if any
> > > > > header is added to the lib folder which fails to compile when included
> > > > > alone, the build of chkincs will fail with a suitable error message.
> > > > > Since this compile checking is not needed on most builds of DPDK, the
> > > > > building of chkincs is disabled by default, but can be enabled by the
> > > > > "test_includes" meson option. To catch errors with patch submissions,
> > > > > the final patch of this series enables it for a single build in
> > > > > test-meson-builds script.
> > > > >
> > > > > Future work could involve doing similar checks on headers for C++
> > > > > compatibility, which was something done by the check-includes.sh script
> > > > > but which is missing here..
> > > > >
> > > > > V3:
> > > > > * Shrunk patchset as most header fixes already applied
> > > > > * Moved chkincs from "apps" to the "buildtools" directory, which is a
> > > > > better location for something not for installation for end-user use.
> > > > > * Added patch to drop check-includes script.
> > > > >
> > > > > V2:
> > > > > * Add maintainers file entry for new app
> > > > > * Drop patch for c11 ring header
> > > > > * Use build variable "headers_no_chkincs" for tracking exceptions
> > > > >
> > > > > Bruce Richardson (4):
> > > > > eal: add missing include to mcslock
> > > > > build: separate out headers for include checking
> > > > > buildtools/chkincs: add app to verify header includes
> > > > > devtools: remove check-includes script
> > > > >
> > > > > MAINTAINERS | 5 +-
> > > > > buildtools/chkincs/gen_c_file_for_header.py | 12 +
> > > > > buildtools/chkincs/main.c | 4 +
> > > > > buildtools/chkincs/meson.build | 40 +++
> > > > > devtools/check-includes.sh | 259 -------------------
> > > > > devtools/test-meson-builds.sh | 2 +-
> > > > > doc/guides/contributing/coding_style.rst | 12 +
> > > > > lib/librte_eal/include/generic/rte_mcslock.h | 1 +
> > > > > lib/librte_eal/include/meson.build | 2 +-
> > > > > lib/librte_eal/x86/include/meson.build | 14 +-
> > > > > lib/librte_ethdev/meson.build | 4 +-
> > > > > lib/librte_hash/meson.build | 4 +-
> > > > > lib/librte_ipsec/meson.build | 3 +-
> > > > > lib/librte_lpm/meson.build | 2 +-
> > > > > lib/librte_regexdev/meson.build | 2 +-
> > > > > lib/librte_ring/meson.build | 4 +-
> > > > > lib/librte_stack/meson.build | 4 +-
> > > > > lib/librte_table/meson.build | 7 +-
> > > > > lib/meson.build | 3 +
> > > > > meson.build | 6 +
> > > > > meson_options.txt | 2 +
> > > > > 21 files changed, 112 insertions(+), 280 deletions(-)
> > > > > create mode 100755 buildtools/chkincs/gen_c_file_for_header.py
> > > > > create mode 100644 buildtools/chkincs/main.c
> > > > > create mode 100644 buildtools/chkincs/meson.build
> > > > > delete mode 100755 devtools/check-includes.sh
> > > >
> > > > - clang is not happy when enabling the check:
> > > > $ meson configure $HOME/builds/build-clang-static -Dcheck_includes=true
> > > > $ devtools/test-meson-builds.sh
> > > > ...
> > > > [362/464] Compiling C object
> > > > buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_vdev.c.o
> > > > FAILED: buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_vdev.c.o
> > > > clang -Ibuildtools/chkincs/chkincs.p -Ibuildtools/chkincs
> > > > -I../../dpdk/buildtools/chkincs -Idrivers/bus/pci
> > > > -I../../dpdk/drivers/bus/pci -Idrivers/bus/vdev
> > > > -I../../dpdk/drivers/bus/vdev -I. -I../../dpdk -Iconfig
> > > > -I../../dpdk/config -Ilib/librte_eal/include
> > > > -I../../dpdk/lib/librte_eal/include -Ilib/librte_eal/linux/include
> > > > -I../../dpdk/lib/librte_eal/linux/include -Ilib/librte_eal/x86/include
> > > > -I../../dpdk/lib/librte_eal/x86/include -Ilib/librte_kvargs
> > > > -I../../dpdk/lib/librte_kvargs -Ilib/librte_metrics
> > > > -I../../dpdk/lib/librte_metrics -Ilib/librte_telemetry
> > > > -I../../dpdk/lib/librte_telemetry -Ilib/librte_eal/common
> > > > -I../../dpdk/lib/librte_eal/common -Ilib/librte_eal
> > > > -I../../dpdk/lib/librte_eal -Ilib/librte_ring
> > > > -I../../dpdk/lib/librte_ring -Ilib/librte_rcu
> > > > -I../../dpdk/lib/librte_rcu -Ilib/librte_mempool
> > > > -I../../dpdk/lib/librte_mempool -Ilib/librte_mbuf
> > > > -I../../dpdk/lib/librte_mbuf -Ilib/librte_net
> > > > -I../../dpdk/lib/librte_net -Ilib/librte_meter
> > > > -I../../dpdk/lib/librte_meter -Ilib/librte_ethdev
> > > > -I../../dpdk/lib/librte_ethdev -Ilib/librte_pci
> > > > -I../../dpdk/lib/librte_pci -Ilib/librte_cmdline
> > > > -I../../dpdk/lib/librte_cmdline -Ilib/librte_hash
> > > > -I../../dpdk/lib/librte_hash -Ilib/librte_timer
> > > > -I../../dpdk/lib/librte_timer -Ilib/librte_acl
> > > > -I../../dpdk/lib/librte_acl -Ilib/librte_bbdev
> > > > -I../../dpdk/lib/librte_bbdev -Ilib/librte_bitratestats
> > > > -I../../dpdk/lib/librte_bitratestats -Ilib/librte_cfgfile
> > > > -I../../dpdk/lib/librte_cfgfile -Ilib/librte_compressdev
> > > > -I../../dpdk/lib/librte_compressdev -Ilib/librte_cryptodev
> > > > -I../../dpdk/lib/librte_cryptodev -Ilib/librte_distributor
> > > > -I../../dpdk/lib/librte_distributor -Ilib/librte_efd
> > > > -I../../dpdk/lib/librte_efd -Ilib/librte_eventdev
> > > > -I../../dpdk/lib/librte_eventdev -Ilib/librte_gro
> > > > -I../../dpdk/lib/librte_gro -Ilib/librte_gso
> > > > -I../../dpdk/lib/librte_gso -Ilib/librte_ip_frag
> > > > -I../../dpdk/lib/librte_ip_frag -Ilib/librte_jobstats
> > > > -I../../dpdk/lib/librte_jobstats -Ilib/librte_kni
> > > > -I../../dpdk/lib/librte_kni -Ilib/librte_latencystats
> > > > -I../../dpdk/lib/librte_latencystats -Ilib/librte_lpm
> > > > -I../../dpdk/lib/librte_lpm -Ilib/librte_member
> > > > -I../../dpdk/lib/librte_member -Ilib/librte_power
> > > > -I../../dpdk/lib/librte_power -Ilib/librte_pdump
> > > > -I../../dpdk/lib/librte_pdump -Ilib/librte_rawdev
> > > > -I../../dpdk/lib/librte_rawdev -Ilib/librte_regexdev
> > > > -I../../dpdk/lib/librte_regexdev -Ilib/librte_rib
> > > > -I../../dpdk/lib/librte_rib -Ilib/librte_reorder
> > > > -I../../dpdk/lib/librte_reorder -Ilib/librte_sched
> > > > -I../../dpdk/lib/librte_sched -Ilib/librte_security
> > > > -I../../dpdk/lib/librte_security -Ilib/librte_stack
> > > > -I../../dpdk/lib/librte_stack -Ilib/librte_vhost
> > > > -I../../dpdk/lib/librte_vhost -Ilib/librte_ipsec
> > > > -I../../dpdk/lib/librte_ipsec -Ilib/librte_fib
> > > > -I../../dpdk/lib/librte_fib -Ilib/librte_port
> > > > -I../../dpdk/lib/librte_port -Ilib/librte_table
> > > > -I../../dpdk/lib/librte_table -Ilib/librte_pipeline
> > > > -I../../dpdk/lib/librte_pipeline -Ilib/librte_flow_classify
> > > > -I../../dpdk/lib/librte_flow_classify -Ilib/librte_bpf
> > > > -I../../dpdk/lib/librte_bpf -Ilib/librte_graph
> > > > -I../../dpdk/lib/librte_graph -Ilib/librte_node
> > > > -I../../dpdk/lib/librte_node
> > > > -I/home/dmarchan/intel-ipsec-mb/install/include -Xclang
> > > > -fcolor-diagnostics -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
> > > > -Werror -O2 -g -include rte_config.h -Wextra -Wcast-qual -Wdeprecated
> > > > -Wformat -Wformat-nonliteral -Wformat-security -Wmissing-declarations
> > > > -Wmissing-prototypes -Wnested-externs -Wold-style-definition
> > > > -Wpointer-arith -Wsign-compare -Wstrict-prototypes -Wundef
> > > > -Wwrite-strings -Wno-address-of-packed-member
> > > > -Wno-missing-field-initializers -D_GNU_SOURCE -march=native
> > > > -Wno-unused-function -DALLOW_EXPERIMENTAL_API -MD -MQ
> > > > buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_vdev.c.o -MF
> > > > buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_vdev.c.o.d -o
> > > > buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_vdev.c.o -c
> > > > buildtools/chkincs/chkincs.p/rte_ethdev_vdev.c
> > > > In file included from buildtools/chkincs/chkincs.p/rte_ethdev_vdev.c:1:
> > > > In file included from
> > > > /home/dmarchan/dpdk/lib/librte_ethdev/rte_ethdev_vdev.h:12:
> > > > ../../dpdk/lib/librte_ethdev/rte_ethdev_driver.h:964:1: error: unknown
> > > > attribute 'error' ignored [-Werror,-Wunknown-attributes]
> > > > __rte_internal
> > > > ^
> > > > ../../dpdk/lib/librte_eal/include/rte_compat.h:25:16: note: expanded
> > > > from macro '__rte_internal'
> > > > __attribute__((error("Symbol is not public ABI"), \
> > > > ^
> > > >
> > >
> > > This looks to be a real issue with our header file - clang does not have an
> > > "error" attribute. The closest equivalent I can see is "diagnose_if".
> >
> > Indeed, it does trigger a build error, so it works as expected ;-).
> >
> >
> > On the header check itself, even if we find a way to properly tag
> > those symbols with the macro in rte_compat.h, the next issue is that
> > clang complains about such marked symbols without the
> > ALLOW_INTERNAL_API build flag.
> >
> > FAILED: buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_pci.c.o
> > clang -Ibuildtools/chkincs/chkincs.p -Ibuildtools/chkincs
> > -I../../dpdk/buildtools/chkincs -Idrivers/bus/pci
> > -I../../dpdk/drivers/bus/pci -Idrivers/bus/vdev
> > -I../../dpdk/drivers/bus/vdev -I. -I../../dpdk -Iconfig
> > -I../../dpdk/config -Ilib/librte_eal/include
> > -I../../dpdk/lib/librte_eal/include -Ilib/librte_eal/linux/include
> > -I../../dpdk/lib/librte_eal/linux/include -Ilib/librte_eal/x86/include
> > -I../../dpdk/lib/librte_eal/x86/include -Ilib/librte_kvargs
> > -I../../dpdk/lib/librte_kvargs -Ilib/librte_metrics
> > -I../../dpdk/lib/librte_metrics -Ilib/librte_telemetry
> > -I../../dpdk/lib/librte_telemetry -Ilib/librte_eal/common
> > -I../../dpdk/lib/librte_eal/common -Ilib/librte_eal
> > -I../../dpdk/lib/librte_eal -Ilib/librte_ring
> > -I../../dpdk/lib/librte_ring -Ilib/librte_rcu
> > -I../../dpdk/lib/librte_rcu -Ilib/librte_mempool
> > -I../../dpdk/lib/librte_mempool -Ilib/librte_mbuf
> > -I../../dpdk/lib/librte_mbuf -Ilib/librte_net
> > -I../../dpdk/lib/librte_net -Ilib/librte_meter
> > -I../../dpdk/lib/librte_meter -Ilib/librte_ethdev
> > -I../../dpdk/lib/librte_ethdev -Ilib/librte_pci
> > -I../../dpdk/lib/librte_pci -Ilib/librte_cmdline
> > -I../../dpdk/lib/librte_cmdline -Ilib/librte_hash
> > -I../../dpdk/lib/librte_hash -Ilib/librte_timer
> > -I../../dpdk/lib/librte_timer -Ilib/librte_acl
> > -I../../dpdk/lib/librte_acl -Ilib/librte_bbdev
> > -I../../dpdk/lib/librte_bbdev -Ilib/librte_bitratestats
> > -I../../dpdk/lib/librte_bitratestats -Ilib/librte_cfgfile
> > -I../../dpdk/lib/librte_cfgfile -Ilib/librte_compressdev
> > -I../../dpdk/lib/librte_compressdev -Ilib/librte_cryptodev
> > -I../../dpdk/lib/librte_cryptodev -Ilib/librte_distributor
> > -I../../dpdk/lib/librte_distributor -Ilib/librte_efd
> > -I../../dpdk/lib/librte_efd -Ilib/librte_eventdev
> > -I../../dpdk/lib/librte_eventdev -Ilib/librte_gro
> > -I../../dpdk/lib/librte_gro -Ilib/librte_gso
> > -I../../dpdk/lib/librte_gso -Ilib/librte_ip_frag
> > -I../../dpdk/lib/librte_ip_frag -Ilib/librte_jobstats
> > -I../../dpdk/lib/librte_jobstats -Ilib/librte_kni
> > -I../../dpdk/lib/librte_kni -Ilib/librte_latencystats
> > -I../../dpdk/lib/librte_latencystats -Ilib/librte_lpm
> > -I../../dpdk/lib/librte_lpm -Ilib/librte_member
> > -I../../dpdk/lib/librte_member -Ilib/librte_power
> > -I../../dpdk/lib/librte_power -Ilib/librte_pdump
> > -I../../dpdk/lib/librte_pdump -Ilib/librte_rawdev
> > -I../../dpdk/lib/librte_rawdev -Ilib/librte_regexdev
> > -I../../dpdk/lib/librte_regexdev -Ilib/librte_rib
> > -I../../dpdk/lib/librte_rib -Ilib/librte_reorder
> > -I../../dpdk/lib/librte_reorder -Ilib/librte_sched
> > -I../../dpdk/lib/librte_sched -Ilib/librte_security
> > -I../../dpdk/lib/librte_security -Ilib/librte_stack
> > -I../../dpdk/lib/librte_stack -Ilib/librte_vhost
> > -I../../dpdk/lib/librte_vhost -Ilib/librte_ipsec
> > -I../../dpdk/lib/librte_ipsec -Ilib/librte_fib
> > -I../../dpdk/lib/librte_fib -Ilib/librte_port
> > -I../../dpdk/lib/librte_port -Ilib/librte_table
> > -I../../dpdk/lib/librte_table -Ilib/librte_pipeline
> > -I../../dpdk/lib/librte_pipeline -Ilib/librte_flow_classify
> > -I../../dpdk/lib/librte_flow_classify -Ilib/librte_bpf
> > -I../../dpdk/lib/librte_bpf -Ilib/librte_graph
> > -I../../dpdk/lib/librte_graph -Ilib/librte_node
> > -I../../dpdk/lib/librte_node
> > -I/home/dmarchan/intel-ipsec-mb/install/include -Xclang
> > -fcolor-diagnostics -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
> > -Werror -O2 -g -include rte_config.h -Wextra -Wcast-qual -Wdeprecated
> > -Wformat -Wformat-nonliteral -Wformat-security -Wmissing-declarations
> > -Wmissing-prototypes -Wnested-externs -Wold-style-definition
> > -Wpointer-arith -Wsign-compare -Wstrict-prototypes -Wundef
> > -Wwrite-strings -Wno-address-of-packed-member
> > -Wno-missing-field-initializers -D_GNU_SOURCE -march=native
> > -Wno-unused-function -DALLOW_EXPERIMENTAL_API -MD -MQ
> > buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_pci.c.o -MF
> > buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_pci.c.o.d -o
> > buildtools/chkincs/chkincs.p/meson-generated_rte_ethdev_pci.c.o -c
> > buildtools/chkincs/chkincs.p/rte_ethdev_pci.c
> > In file included from buildtools/chkincs/chkincs.p/rte_ethdev_pci.c:1:
> > /home/dmarchan/dpdk/lib/librte_ethdev/rte_ethdev_pci.h:86:13: error:
> > Symbol is not public ABI
> > eth_dev = rte_eth_dev_allocate(name);
> > ^
> > ../../dpdk/lib/librte_ethdev/rte_ethdev_driver.h:1003:1: note: from
> > 'diagnose_if' attribute on 'rte_eth_dev_allocate':
> > __rte_internal
> > ^~~~~~~~~~~~~~
> > ../../dpdk/lib/librte_eal/include/rte_compat.h:30:16: note: expanded
> > from macro '__rte_internal'
> > __attribute__((diagnose_if(1, "Symbol is not public ABI", "error"), \
> > ^ ~
> > [...]
> >
> >
> > gcc seems more lenient about this.
> >
> >
> >
> > > Therefore, I'd suggest we need to change compat.h to be something like:
> > >
> > > #if !defined ALLOW_INTERNAL_API && __has_attribute(error) /* For GCC */
> > >
> > > #define __rte_internal \
> > > __attribute__((error("Symbol is not public ABI"), \
> > > section(".text.internal")))
> > >
> > > #elif !defined ALLOW_INTERNAL_API && __has_attribute(diagnose_if) /* For clang */
> > >
> > > #define __rte_internal \
> > > __attribute__((diagnose_if(1, "Symbol is not public ABI", "error"), \
> > > section(".text.internal")))
> > >
> > > #else
> > >
> > > #define __rte_internal \
> > > __attribute__((section(".text.internal")))
> > >
> > > #endif
> > >
> > > Any thoughts or suggestions for better alternatives here?
> >
> > I'd rather leave a build error on an unknown attribute than silence
> > this check (which happens in your snippet, where it falls back to the
> > #else part).
> >
> > Did you consider the deprecated() like for the experimental tag?
> >
>
> I've added the ALLOW_INTERNAL_API define to the build of these headers in
> v4.
+Ferruh, Thomas
Removing the ALLOW_INTERNAL_API is probably a good idea, but it does indeed
throw up the errors with clang - but not gcc, which is strange. The
offending headers seem to be (initially):
* rte_ethdev_vdev.h
* rte_ethdev_pci.h
Are these public header files, or should they skip header checking - and
installation - as internal-only?
/Bruce
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4 02/44] bus/vdev: add driver IOVA VA mode requirement
2021-01-26 13:23 0% ` Kinsella, Ray
@ 2021-01-26 14:40 4% ` David Marchand
2021-01-26 15:28 0% ` Kinsella, Ray
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2021-01-26 14:40 UTC (permalink / raw)
To: Kinsella, Ray
Cc: Maxime Coquelin, dev, Xia, Chenbo, Olivier Matz, Adrian Moreno Zapata
On Tue, Jan 26, 2021 at 2:23 PM Kinsella, Ray <mdr@ashroe.eu> wrote:
> >> diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
> >> index 1dc84fa74b..170304c876 100644
> >> --- a/devtools/libabigail.abignore
> >> +++ b/devtools/libabigail.abignore
> >> @@ -11,6 +11,8 @@
> >> ; Explicit ignore for driver-only ABI
> >> [suppress_type]
> >> name = eth_dev_ops
> >> +[suppress_function]
> >> + name_regexp = rte_vdev_(|un)register
> >>
> >> ; Ignore fields inserted in cacheline boundary of rte_cryptodev
> >> [suppress_type]
> >
> > Ray,
> > Are you okay with this exception?
>
> Ask a perhaps silly question,
> shouldn't rte_vdev_register & rte_vdev_unregister have been INTERNAL in any case?
I discussed with Thomas earlier.
The INTERNAL exception rule we have suppresses changes on symbols
already versioned INTERNAL.
If we mark these two symbols INTERNAL now, they are part of the stable
v21 ABI in any case.
libabigail will still complain about them disappearing.
$ abidiff --suppr
/home/dmarchan/dpdk/devtools/../devtools/libabigail.abignore
--no-added-syms --headers-dir1
/home/dmarchan/abi/v20.11/build-gcc-shared/usr/local/include
--headers-dir2 /home/dmarchan/builds/build-gcc-shared/install/usr/local/include
/home/dmarchan/abi/v20.11/build-gcc-shared/dump/librte_bus_vdev.dump
/home/dmarchan/builds/build-gcc-shared/install/dump/librte_bus_vdev.dump
Functions changes summary: 2 Removed, 0 Changed, 0 Added functions
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
2 Removed functions:
[D] 'function void rte_vdev_register(rte_vdev_driver*)'
{rte_vdev_register@@DPDK_21}
[D] 'function void rte_vdev_unregister(rte_vdev_driver*)'
{rte_vdev_unregister@@DPDK_21}
We will need an exception in any case for them.
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v4 02/44] bus/vdev: add driver IOVA VA mode requirement
2021-01-26 14:40 4% ` David Marchand
@ 2021-01-26 15:28 0% ` Kinsella, Ray
0 siblings, 0 replies; 200+ results
From: Kinsella, Ray @ 2021-01-26 15:28 UTC (permalink / raw)
To: David Marchand
Cc: Maxime Coquelin, dev, Xia, Chenbo, Olivier Matz, Adrian Moreno Zapata
On 26/01/2021 14:40, David Marchand wrote:
> On Tue, Jan 26, 2021 at 2:23 PM Kinsella, Ray <mdr@ashroe.eu> wrote:
>>>> diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
>>>> index 1dc84fa74b..170304c876 100644
>>>> --- a/devtools/libabigail.abignore
>>>> +++ b/devtools/libabigail.abignore
>>>> @@ -11,6 +11,8 @@
>>>> ; Explicit ignore for driver-only ABI
>>>> [suppress_type]
>>>> name = eth_dev_ops
>>>> +[suppress_function]
>>>> + name_regexp = rte_vdev_(|un)register
>>>>
>>>> ; Ignore fields inserted in cacheline boundary of rte_cryptodev
>>>> [suppress_type]
>>>
>>> Ray,
>>> Are you okay with this exception?
>>
>> Ask a perhaps silly question,
>> shouldn't rte_vdev_register & rte_vdev_unregister have been INTERNAL in any case?
>
> I discussed with Thomas earlier.
>
> The INTERNAL exception rule we have suppresses changes on symbols
> already versioned INTERNAL.
> If we mark these two symbols INTERNAL now, they are part of the stable
> v21 ABI in any case.
> libabigail will still complain about them disappearing.
>
> $ abidiff --suppr
> /home/dmarchan/dpdk/devtools/../devtools/libabigail.abignore
> --no-added-syms --headers-dir1
> /home/dmarchan/abi/v20.11/build-gcc-shared/usr/local/include
> --headers-dir2 /home/dmarchan/builds/build-gcc-shared/install/usr/local/include
> /home/dmarchan/abi/v20.11/build-gcc-shared/dump/librte_bus_vdev.dump
> /home/dmarchan/builds/build-gcc-shared/install/dump/librte_bus_vdev.dump
> Functions changes summary: 2 Removed, 0 Changed, 0 Added functions
> Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
>
> 2 Removed functions:
>
> [D] 'function void rte_vdev_register(rte_vdev_driver*)'
> {rte_vdev_register@@DPDK_21}
> [D] 'function void rte_vdev_unregister(rte_vdev_driver*)'
> {rte_vdev_unregister@@DPDK_21}
>
> We will need an exception in any case for them.
>
Agreed, I didn't miss that are still going to need the exception.
If we agree that everything that is in rte_vdev_bus should be internal.
We can also fix that, while we are aware of it.
The rule above gets my +1 and I will fix rte_vdev_bus.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v5 2/8] eal: fix error attribute use for clang
@ 2021-01-26 21:38 13% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2021-01-26 21:38 UTC (permalink / raw)
To: dev
Cc: david.marchand, Bruce Richardson, haiyue.wang, Ray Kinsella, Neil Horman
Clang does not have an "error" attribute for functions, so for marking
internal functions we need to check for the error attribute, and provide
a fallback if it is not present. For clang, we can use "diagnose_if"
attribute, similarly checking for its presence before use.
Fixes: fba5af82adc8 ("eal: add internal ABI tag definition")
Cc: haiyue.wang@intel.com
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
lib/librte_eal/include/rte_compat.h | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/lib/librte_eal/include/rte_compat.h b/lib/librte_eal/include/rte_compat.h
index 4cd8f68d68..c30f072aa3 100644
--- a/lib/librte_eal/include/rte_compat.h
+++ b/lib/librte_eal/include/rte_compat.h
@@ -19,12 +19,18 @@ __attribute__((section(".text.experimental")))
#endif
-#ifndef ALLOW_INTERNAL_API
+#if !defined ALLOW_INTERNAL_API && __has_attribute(error) /* For GCC */
#define __rte_internal \
__attribute__((error("Symbol is not public ABI"), \
section(".text.internal")))
+#elif !defined ALLOW_INTERNAL_API && __has_attribute(diagnose_if) /* For clang */
+
+#define __rte_internal \
+__attribute__((diagnose_if(1, "Symbol is not public ABI", "error"), \
+section(".text.internal")))
+
#else
#define __rte_internal \
--
2.27.0
^ permalink raw reply [relevance 13%]
* Re: [dpdk-dev] [PATCH v4 02/44] bus/vdev: add driver IOVA VA mode requirement
2021-01-26 10:15 7% ` [dpdk-dev] [PATCH v4 02/44] bus/vdev: add driver IOVA VA mode requirement Maxime Coquelin
2021-01-26 11:50 0% ` Xia, Chenbo
2021-01-26 12:50 0% ` David Marchand
@ 2021-01-27 8:23 0% ` David Marchand
2021-01-27 8:25 0% ` Maxime Coquelin
2 siblings, 1 reply; 200+ results
From: David Marchand @ 2021-01-27 8:23 UTC (permalink / raw)
To: Maxime Coquelin
Cc: dev, Xia, Chenbo, Olivier Matz, Adrian Moreno Zapata, Ray Kinsella
On Tue, Jan 26, 2021 at 11:16 AM Maxime Coquelin
<maxime.coquelin@redhat.com> wrote:
>
> This patch adds driver flag in vdev bus driver so that
> vdev drivers can require VA IOVA mode to be used, which
> for example the case of Virtio-user PMD.
>
> The patch implements the .get_iommu_class() callback, that
> is called before devices probing to determine the IOVA mode
> to be used, and adds a check right before the device is
> probed to ensure compatible IOVA mode has been selected.
>
> It also adds a ABI exception rule to accommodate with an
> update on the driver registration API
>
> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
I only suggested some changes.
This patch looks good to me.
Can you change this Sob as a Acked-by?
Thanks Maxime.
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4 02/44] bus/vdev: add driver IOVA VA mode requirement
2021-01-27 8:23 0% ` David Marchand
@ 2021-01-27 8:25 0% ` Maxime Coquelin
0 siblings, 0 replies; 200+ results
From: Maxime Coquelin @ 2021-01-27 8:25 UTC (permalink / raw)
To: David Marchand
Cc: dev, Xia, Chenbo, Olivier Matz, Adrian Moreno Zapata, Ray Kinsella
On 1/27/21 9:23 AM, David Marchand wrote:
> On Tue, Jan 26, 2021 at 11:16 AM Maxime Coquelin
> <maxime.coquelin@redhat.com> wrote:
>>
>> This patch adds driver flag in vdev bus driver so that
>> vdev drivers can require VA IOVA mode to be used, which
>> for example the case of Virtio-user PMD.
>>
>> The patch implements the .get_iommu_class() callback, that
>> is called before devices probing to determine the IOVA mode
>> to be used, and adds a check right before the device is
>> probed to ensure compatible IOVA mode has been selected.
>>
>> It also adds a ABI exception rule to accommodate with an
>> update on the driver registration API
>>
>> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
>> Signed-off-by: David Marchand <david.marchand@redhat.com>
>
> I only suggested some changes.
> This patch looks good to me.
> Can you change this Sob as a Acked-by?
Sure, I can do that.
Thanks!
Maxime
> Thanks Maxime.
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4 00/44] net/virtio: Virtio PMD rework
2021-01-26 10:15 3% [dpdk-dev] [PATCH v4 00/44] net/virtio: Virtio PMD rework Maxime Coquelin
2021-01-26 10:15 7% ` [dpdk-dev] [PATCH v4 02/44] bus/vdev: add driver IOVA VA mode requirement Maxime Coquelin
@ 2021-01-27 11:59 0% ` Maxime Coquelin
2021-02-01 8:44 0% ` Wang, Yinan
2 siblings, 0 replies; 200+ results
From: Maxime Coquelin @ 2021-01-27 11:59 UTC (permalink / raw)
To: dev, chenbo.xia, olivier.matz, amorenoz, david.marchand
On 1/26/21 11:15 AM, Maxime Coquelin wrote:
> This V3 fixes comments from Chenbo on patch 44 and
> implements the ABI exception in patch 2.
>
> This series significantly rework Virtio PMD to improve
> the Virtio-user PMD and its backends integration.
>
> First part of the series removes the dependency of
> Virtio-user ethdev on Virtio PCI, by creating generic
> files, adding per-bus meta data, ...
>
> Main (if not single) functionnal change of this first
> part is to remove the hack for Virtio-user to work in
> IOVA as PA mode, this hack being very fragile.
>
> Second part of the series reworks Virtio-user internal,
> by reworking the requests handling so that vDPA and Kernel
> backends no more hack into being Vhost-user backend. It
> implies implementing new ops for all the request types.
> Also, all the backend specific actions are moved from the
> virtio_user_dev.c and virtio_user_ethdev.c to their
> backend files.
>
> Only functionnal change in this second part is making the
> Vhost-user server mode blocking at init time, as long as
> a client is not connected. The goal of this change is to
> make the Vhost-user support much more robust, as without
> blocking, the driver has to assume features that are going
> to be supported by the client, which is very fragile and
> error prone. As a side-effect, it also simplifies the
> logic nin several place of the virtio-user PMD.
>
> Main changes in v4:
> - Add ABI exception (David)
> - Close FDs only up to max_queue_pairs
> - virtio_user_dev_uninit_notify() to return void
>
> Main changes in v3:
> - Rename .intr_event to .intr_detect
> - Rework last patch, properly clean allocated resources
> on failure.
> - Rebase on top of latest net-next/main
> - Minor typo fixes in comments and log improvements
>
> Main changes in v2:
> ===================
> - Introduce vdev driver flag for drivers to require IOVA VA mode
> - Rebase on top of -rc1 changes
> - Fix regressions introduced in V1 (vhost-kernel broken, vhost-user reconnect...)
> - Various minor issues & typos fixed
> - Fix status feature issue introduced in v20.11, only reproduceable now that server
> mode is made blocking
> - Improve failure handling in Virtio-user
> - Improve logging
>
> Testing coverage (All passed)
> =============================
> - Virtio-pci PMD
> * Virtio PMD in guest with Vhost-user backend in host
> * Virtio PMD in guest with Vhost-kernel backend in host
> - Virtio-user PMD with Vhost-user backend
> * Vhost-user PMD server <-> Virtio-user client PMD IO loopback
> * Vhost-user PMD client <-> Virtio-user server PMD IO loopback
> * Vhost-user PMD client <-> Virtio-user server PMD reconnect
> - Virtio-user PMD with Vhost-kernel backend
> * iperf test case
> * Txonly testpmd
> - Virtio-user PMD with Vhost-vDPA backend
> * vdpa-sim (IO loopback)
> * CX-6 DX Kernel vDPA (Tx only)
>
> Maxime Coquelin (44):
> bus/vdev: add helper to get vdev from ethdev
> bus/vdev: add driver IOVA VA mode requirement
> net/virtio: fix getting old status on reconnect
> net/virtio: introduce Virtio bus type
> net/virtio: refactor virtio-user device
> net/virtio: introduce PCI device metadata
> net/virtio: move PCI device init in dedicated file
> net/virtio: move PCI specific dev init to PCI ethdev init
> net/virtio: move MSIX detection to PCI ethdev
> net/virtio: force IOVA as VA mode for Virtio-user
> net/virtio: store PCI type in Virtio device metadata
> net/virtio: add callback for device closing
> net/virtio: validate features at bus level
> net/virtio: remove bus type enum
> net/virtio: move PCI-specific fields to PCI device
> net/virtio: pack virtio HW struct
> net/virtio: move legacy IO to Virtio PCI
> net/virtio: introduce generic virtio header
> net/virtio: move features definition to generic header
> net/virtio: move virtqueue defines in generic header
> net/virtio: move config definitions to generic header
> net/virtio: make interrupt handling more generic
> net/virtio: move vring alignment to generic header
> net/virtio: remove last PCI refs in non-PCI code
> net/virtio: make Vhost-user request sender consistent
> net/virtio: add Virtio-user ops to set owner
> net/virtio: add Virtio-user features ops
> net/virtio: add Virtio-user protocol features ops
> net/virtio: add Virtio-user memory tables ops
> net/virtio: add Virtio-user vring setting ops
> net/virtio: add Virtio-user vring file ops
> net/virtio: add Virtio-user vring address ops
> net/virtio: add Virtio-user status ops
> net/virtio: remove useless request ops
> net/virtio: improve Virtio-user errors handling
> net/virtio: move Vhost-user requests to Vhost-user backend
> net/virtio: make server mode blocking
> net/virtio: move protocol features to Vhost-user
> net/virtio: introduce backend data
> net/virtio: move Vhost-user specifics to its backend
> net/virtio: move Vhost-kernel data to its backend
> net/virtio: move Vhost-vDPA data to its backend
> net/virtio: improve Vhost-user error logging
> net/virtio: handle Virtio-user setup failure properly
>
> devtools/libabigail.abignore | 2 +
> drivers/bus/vdev/rte_bus_vdev.h | 6 +
> drivers/bus/vdev/vdev.c | 29 +
> drivers/net/virtio/meson.build | 6 +-
> drivers/net/virtio/virtio.c | 71 ++
> drivers/net/virtio/virtio.h | 246 +++++
> drivers/net/virtio/virtio_ethdev.c | 457 +++------
> drivers/net/virtio/virtio_ethdev.h | 6 +-
> drivers/net/virtio/virtio_pci.c | 448 +++++----
> drivers/net/virtio/virtio_pci.h | 286 +-----
> drivers/net/virtio/virtio_pci_ethdev.c | 226 +++++
> drivers/net/virtio/virtio_ring.h | 2 +-
> drivers/net/virtio/virtio_rxtx.c | 90 +-
> drivers/net/virtio/virtio_rxtx_packed.h | 10 +-
> drivers/net/virtio/virtio_rxtx_packed_avx.h | 10 +-
> drivers/net/virtio/virtio_rxtx_packed_neon.h | 10 +-
> drivers/net/virtio/virtio_rxtx_simple.h | 3 +-
> drivers/net/virtio/virtio_user/vhost.h | 79 +-
> drivers/net/virtio/virtio_user/vhost_kernel.c | 461 ++++++---
> .../net/virtio/virtio_user/vhost_kernel_tap.c | 25 +-
> .../net/virtio/virtio_user/vhost_kernel_tap.h | 1 +
> drivers/net/virtio/virtio_user/vhost_user.c | 898 ++++++++++++++----
> drivers/net/virtio/virtio_user/vhost_vdpa.c | 323 +++++--
> .../net/virtio/virtio_user/virtio_user_dev.c | 573 ++++++-----
> .../net/virtio/virtio_user/virtio_user_dev.h | 21 +-
> drivers/net/virtio/virtio_user_ethdev.c | 301 +-----
> drivers/net/virtio/virtqueue.c | 6 +-
> drivers/net/virtio/virtqueue.h | 45 +-
> 28 files changed, 2742 insertions(+), 1899 deletions(-)
> create mode 100644 drivers/net/virtio/virtio.c
> create mode 100644 drivers/net/virtio/virtio.h
> create mode 100644 drivers/net/virtio/virtio_pci_ethdev.c
>
Applied to dpdk-next-virtio/main.
Thanks,
Maxime
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v6 2/8] eal: fix error attribute use for clang
@ 2021-01-27 17:33 13% ` Bruce Richardson
2021-01-28 11:00 4% ` David Marchand
2021-01-28 10:55 3% ` [dpdk-dev] [PATCH v6 0/8] add checking of header includes David Marchand
1 sibling, 1 reply; 200+ results
From: Bruce Richardson @ 2021-01-27 17:33 UTC (permalink / raw)
To: dev
Cc: david.marchand, Bruce Richardson, haiyue.wang, Ray Kinsella, Neil Horman
Clang does not have an "error" attribute for functions, so for marking
internal functions we need to check for the error attribute, and provide
a fallback if it is not present. For clang, we can use "diagnose_if"
attribute, similarly checking for its presence before use.
Fixes: fba5af82adc8 ("eal: add internal ABI tag definition")
Cc: haiyue.wang@intel.com
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
lib/librte_eal/include/rte_compat.h | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/lib/librte_eal/include/rte_compat.h b/lib/librte_eal/include/rte_compat.h
index 4cd8f68d68..c30f072aa3 100644
--- a/lib/librte_eal/include/rte_compat.h
+++ b/lib/librte_eal/include/rte_compat.h
@@ -19,12 +19,18 @@ __attribute__((section(".text.experimental")))
#endif
-#ifndef ALLOW_INTERNAL_API
+#if !defined ALLOW_INTERNAL_API && __has_attribute(error) /* For GCC */
#define __rte_internal \
__attribute__((error("Symbol is not public ABI"), \
section(".text.internal")))
+#elif !defined ALLOW_INTERNAL_API && __has_attribute(diagnose_if) /* For clang */
+
+#define __rte_internal \
+__attribute__((diagnose_if(1, "Symbol is not public ABI", "error"), \
+section(".text.internal")))
+
#else
#define __rte_internal \
--
2.27.0
^ permalink raw reply [relevance 13%]
* Re: [dpdk-dev] [PATCH v3 1/5] lpm: add sve support for lookup on Arm platform
@ 2021-01-27 21:03 4% ` Honnappa Nagarahalli
2021-01-28 8:03 0% ` David Marchand
0 siblings, 1 reply; 200+ results
From: Honnappa Nagarahalli @ 2021-01-27 21:03 UTC (permalink / raw)
To: David Marchand, Ruifeng Wang
Cc: jerinj, Jan Viktorin, Bruce Richardson, Vladimir Medvedkin, dev,
Pavan Nikhilesh, hemant.agrawal, nd, Honnappa Nagarahalli, nd
<snip>
>
> On Tue, Jan 12, 2021 at 3:57 AM Ruifeng Wang <ruifeng.wang@arm.com>
> wrote:
> > diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h index
> > 1afe55cdc..28b57683b 100644
> > --- a/lib/librte_lpm/rte_lpm.h
> > +++ b/lib/librte_lpm/rte_lpm.h
> > @@ -402,7 +402,11 @@ rte_lpm_lookupx4(const struct rte_lpm *lpm,
> xmm_t ip, uint32_t hop[4],
> > uint32_t defv);
> >
> > #if defined(RTE_ARCH_ARM)
> > +#ifdef __ARM_FEATURE_SVE
> > +#include "rte_lpm_sve.h"
> > +#else
> > #include "rte_lpm_neon.h"
> > +#endif
> > #elif defined(RTE_ARCH_PPC_64)
> > #include "rte_lpm_altivec.h"
> > #else
> > diff --git a/lib/librte_lpm/rte_lpm_sve.h
> > b/lib/librte_lpm/rte_lpm_sve.h new file mode 100644 index
> > 000000000..2e319373e
> > --- /dev/null
> > +++ b/lib/librte_lpm/rte_lpm_sve.h
> > @@ -0,0 +1,83 @@
> > +/* SPDX-License-Identifier: BSD-3-Clause
> > + * Copyright(c) 2020 Arm Limited
> > + */
> > +
> > +#ifndef _RTE_LPM_SVE_H_
> > +#define _RTE_LPM_SVE_H_
> > +
> > +#include <rte_vect.h>
> > +
> > +#ifdef __cplusplus
> > +extern "C" {
> > +#endif
> > +
> > +__rte_internal
> > +static void
>
> I was looking into use of the __rte_internal tag in the tree.
>
> This helper is called from a inlined API used by applications, so out of the
> DPDK build.
> It looks like the compiler is not complaining when compiling examples (I
> hacked my env to cross compile with gcc 10 + SVE enabled) but this seems
> incorrect to me.
>
> Is there really a need for this helper?
> It is only used below afaics.
I do not think it is required.
At the same time the commit log when '__rte_internal' was introduced is confusing.
It says "Introduce the __rte_internal tag to mark internal ABI function which is used only by the drivers or other libraries". Why would an internal function have an ABI?
>
>
> > +__rte_lpm_lookup_vec(const struct rte_lpm *lpm, const uint32_t *ips,
> > + uint32_t *__rte_restrict next_hops, const uint32_t n)
> > +{
>
> [snip]
>
>
> > +}
> > +
> > +static inline void
> > +rte_lpm_lookupx4(const struct rte_lpm *lpm, xmm_t ip, uint32_t hop[4],
> > + uint32_t defv)
> > +{
> > + uint32_t i, ips[4];
> > +
> > + vst1q_s32((int32_t *)ips, ip);
> > + for (i = 0; i < 4; i++)
> > + hop[i] = defv;
> > +
> > + __rte_lpm_lookup_vec(lpm, ips, hop, 4); }
>
>
> --
> David Marchand
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v3 1/5] lpm: add sve support for lookup on Arm platform
2021-01-27 21:03 4% ` Honnappa Nagarahalli
@ 2021-01-28 8:03 0% ` David Marchand
2021-01-28 12:24 3% ` Honnappa Nagarahalli
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2021-01-28 8:03 UTC (permalink / raw)
To: Honnappa Nagarahalli
Cc: Ruifeng Wang, jerinj, Jan Viktorin, Bruce Richardson,
Vladimir Medvedkin, dev, Pavan Nikhilesh, hemant.agrawal, nd
On Wed, Jan 27, 2021 at 10:03 PM Honnappa Nagarahalli
<Honnappa.Nagarahalli@arm.com> wrote:
>
> <snip>
>
> >
> > On Tue, Jan 12, 2021 at 3:57 AM Ruifeng Wang <ruifeng.wang@arm.com>
> > wrote:
> > > diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h index
> > > 1afe55cdc..28b57683b 100644
> > > --- a/lib/librte_lpm/rte_lpm.h
> > > +++ b/lib/librte_lpm/rte_lpm.h
> > > @@ -402,7 +402,11 @@ rte_lpm_lookupx4(const struct rte_lpm *lpm,
> > xmm_t ip, uint32_t hop[4],
> > > uint32_t defv);
> > >
> > > #if defined(RTE_ARCH_ARM)
> > > +#ifdef __ARM_FEATURE_SVE
> > > +#include "rte_lpm_sve.h"
> > > +#else
> > > #include "rte_lpm_neon.h"
> > > +#endif
> > > #elif defined(RTE_ARCH_PPC_64)
> > > #include "rte_lpm_altivec.h"
> > > #else
> > > diff --git a/lib/librte_lpm/rte_lpm_sve.h
> > > b/lib/librte_lpm/rte_lpm_sve.h new file mode 100644 index
> > > 000000000..2e319373e
> > > --- /dev/null
> > > +++ b/lib/librte_lpm/rte_lpm_sve.h
> > > @@ -0,0 +1,83 @@
> > > +/* SPDX-License-Identifier: BSD-3-Clause
> > > + * Copyright(c) 2020 Arm Limited
> > > + */
> > > +
> > > +#ifndef _RTE_LPM_SVE_H_
> > > +#define _RTE_LPM_SVE_H_
> > > +
> > > +#include <rte_vect.h>
> > > +
> > > +#ifdef __cplusplus
> > > +extern "C" {
> > > +#endif
> > > +
> > > +__rte_internal
> > > +static void
> >
> > I was looking into use of the __rte_internal tag in the tree.
> >
> > This helper is called from a inlined API used by applications, so out of the
> > DPDK build.
> > It looks like the compiler is not complaining when compiling examples (I
> > hacked my env to cross compile with gcc 10 + SVE enabled) but this seems
> > incorrect to me.
> >
> > Is there really a need for this helper?
> > It is only used below afaics.
> I do not think it is required.
>
> At the same time the commit log when '__rte_internal' was introduced is confusing.
> It says "Introduce the __rte_internal tag to mark internal ABI function which is used only by the drivers or other libraries". Why would an internal function have an ABI?
It happens that drivers/libraries in DPDK offer some interface for
other parts of the DPDK to use.
But we might want them to keep them hidden to final applications,
because this is purely internal and/or we don't want to guarantee
compatibility in later versions.
For such cases, a function can be marked __rte_internal.
This tag has two impacts:
- a marked symbol is versionned as INTERNAL when exported (so this
does not apply to inlines),
- if an application tries to use a marked API, an error is triggered
at build time to prevent use of such API,
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v6 0/8] add checking of header includes
2021-01-27 17:33 13% ` [dpdk-dev] [PATCH v6 2/8] eal: fix error attribute use for clang Bruce Richardson
@ 2021-01-28 10:55 3% ` David Marchand
2021-01-28 11:47 0% ` Bruce Richardson
1 sibling, 1 reply; 200+ results
From: David Marchand @ 2021-01-28 10:55 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev, Thomas Monjalon, Ray Kinsella
On Wed, Jan 27, 2021 at 6:33 PM Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> As a general principle, each header file should include any other
> headers it needs to provide data type definitions or macros. For
> example, any header using the uintX_t types in structures or function
> prototypes should include "stdint.h" to provide those type definitions.
>
> In practice, while many, but not all, headers in DPDK did include all
> necessary headers, it was never actually checked that each header could
> be included in a C file and compiled without having any compiler errors
> about missing definitions. The script "check-includes.sh" could be used
> for this job, but it was not called out in the documentation, so many
> contributors may not have been aware of it's existance. It also was
> difficult to run from a source-code directory, as the script did not
> automatically allow finding of headers from one DPDK library directory
> to another [this was probably based on running it on a build created by
> the "make" build system, where all headers were in a single directory].
> To attempt to have a build-system integrated replacement, this patchset
> adds a "chkincs" app in the buildtools directory to verify this on an
> ongoing basis.
>
> This chkincs app does nothing when run, and is not installed as part of
> a DPDK "ninja install", it's for build-time checking only. Its source
> code consists of one C file per public DPDK header, where that C file
> contains nothing except an include for that header. Therefore, if any
> header is added to the lib folder which fails to compile when included
> alone, the build of chkincs will fail with a suitable error message.
> Since this compile checking is not needed on most builds of DPDK, the
> building of chkincs is disabled by default, but can be enabled by the
> "test_includes" meson option. To catch errors with patch submissions,
> the final patch of this series enables it for a single build in
> test-meson-builds script.
>
> Future work could involve doing similar checks on headers for C++
> compatibility, which was something done by the check-includes.sh script
> but which is missing here.
>
> V6:
> * Added release notes updates for:
> - renamed, no-longer-installed header files
> - new "check_includes" build option
> - removal of old check_includes script
> * Included acks from previous versions
I have some comments, see replies on patches.
I can address them if you are ok, and I would take this series for
-rc2 without needing a respin.
Sidenote: I like how we are hiding API by simply not exporting headers.
We need more cleanups like this.
Ethdev has been cleaned; this will probably remove the need for the
ABI exception on eth_dev_ops.
Eventdev, other driver classes and bus drivers will probably be the
next to look at.
--
David Marchand
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v6 2/8] eal: fix error attribute use for clang
2021-01-27 17:33 13% ` [dpdk-dev] [PATCH v6 2/8] eal: fix error attribute use for clang Bruce Richardson
@ 2021-01-28 11:00 4% ` David Marchand
2021-01-28 11:20 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2021-01-28 11:00 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev, Wang, Haiyue, Ray Kinsella, Neil Horman
On Wed, Jan 27, 2021 at 6:33 PM Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> Clang does not have an "error" attribute for functions, so for marking
> internal functions we need to check for the error attribute, and provide
> a fallback if it is not present. For clang, we can use "diagnose_if"
> attribute, similarly checking for its presence before use.
>
> Fixes: fba5af82adc8 ("eal: add internal ABI tag definition")
> Cc: haiyue.wang@intel.com
Cc: stable@dpdk.org
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
> lib/librte_eal/include/rte_compat.h | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/lib/librte_eal/include/rte_compat.h b/lib/librte_eal/include/rte_compat.h
> index 4cd8f68d68..c30f072aa3 100644
> --- a/lib/librte_eal/include/rte_compat.h
> +++ b/lib/librte_eal/include/rte_compat.h
> @@ -19,12 +19,18 @@ __attribute__((section(".text.experimental")))
>
> #endif
>
> -#ifndef ALLOW_INTERNAL_API
> +#if !defined ALLOW_INTERNAL_API && __has_attribute(error) /* For GCC */
>
> #define __rte_internal \
> __attribute__((error("Symbol is not public ABI"), \
> section(".text.internal")))
>
> +#elif !defined ALLOW_INTERNAL_API && __has_attribute(diagnose_if) /* For clang */
> +
> +#define __rte_internal \
> +__attribute__((diagnose_if(1, "Symbol is not public ABI", "error"), \
> +section(".text.internal")))
> +
If the compiler has neither error or diagnose_if support, an internal
API can be called without ALLOW_INTERNAL_API.
I prefer a build error complaining on an unknown attribute rather than
silence a check.
I.e.
#ifndef ALLOW_INTERNAL_API
#if __has_attribute(diagnose_if) /* For clang */
#define __rte_internal \
__attribute__((diagnose_if(1, "Symbol is not public ABI", "error"), \
section(".text.internal")))
#else
#define __rte_internal \
__attribute__((error("Symbol is not public ABI"), \
section(".text.internal")))
#endif
#else /* ALLOW_INTERNAL_API */
#define __rte_internal \
section(".text.internal")))
#endif
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v6 2/8] eal: fix error attribute use for clang
2021-01-28 11:00 4% ` David Marchand
@ 2021-01-28 11:20 0% ` Bruce Richardson
2021-01-28 13:36 0% ` David Marchand
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2021-01-28 11:20 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Wang, Haiyue, Ray Kinsella, Neil Horman
On Thu, Jan 28, 2021 at 12:00:46PM +0100, David Marchand wrote:
> On Wed, Jan 27, 2021 at 6:33 PM Bruce Richardson
> <bruce.richardson@intel.com> wrote:
> >
> > Clang does not have an "error" attribute for functions, so for marking
> > internal functions we need to check for the error attribute, and provide
> > a fallback if it is not present. For clang, we can use "diagnose_if"
> > attribute, similarly checking for its presence before use.
> >
> > Fixes: fba5af82adc8 ("eal: add internal ABI tag definition")
> > Cc: haiyue.wang@intel.com
>
> Cc: stable@dpdk.org
>
> >
> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > ---
> > lib/librte_eal/include/rte_compat.h | 8 +++++++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/librte_eal/include/rte_compat.h b/lib/librte_eal/include/rte_compat.h
> > index 4cd8f68d68..c30f072aa3 100644
> > --- a/lib/librte_eal/include/rte_compat.h
> > +++ b/lib/librte_eal/include/rte_compat.h
> > @@ -19,12 +19,18 @@ __attribute__((section(".text.experimental")))
> >
> > #endif
> >
> > -#ifndef ALLOW_INTERNAL_API
> > +#if !defined ALLOW_INTERNAL_API && __has_attribute(error) /* For GCC */
> >
> > #define __rte_internal \
> > __attribute__((error("Symbol is not public ABI"), \
> > section(".text.internal")))
> >
> > +#elif !defined ALLOW_INTERNAL_API && __has_attribute(diagnose_if) /* For clang */
> > +
> > +#define __rte_internal \
> > +__attribute__((diagnose_if(1, "Symbol is not public ABI", "error"), \
> > +section(".text.internal")))
> > +
>
> If the compiler has neither error or diagnose_if support, an internal
> API can be called without ALLOW_INTERNAL_API.
> I prefer a build error complaining on an unknown attribute rather than
> silence a check.
>
> I.e.
>
> #ifndef ALLOW_INTERNAL_API
>
> #if __has_attribute(diagnose_if) /* For clang */
> #define __rte_internal \
> __attribute__((diagnose_if(1, "Symbol is not public ABI", "error"), \
> section(".text.internal")))
>
> #else
> #define __rte_internal \
> __attribute__((error("Symbol is not public ABI"), \
> section(".text.internal")))
>
> #endif
>
> #else /* ALLOW_INTERNAL_API */
>
> #define __rte_internal \
> section(".text.internal")))
>
> #endif
>
Would this not mean that if someone was using a compiler that supported
neither that they could never include any header file which contained any
internal functions? I'd rather err on the side of allowing this, on the
basis that the symbol should be already documented as internal and this is
only an additional sanity check.
/Bruce
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v6 0/8] add checking of header includes
2021-01-28 10:55 3% ` [dpdk-dev] [PATCH v6 0/8] add checking of header includes David Marchand
@ 2021-01-28 11:47 0% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2021-01-28 11:47 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Thomas Monjalon, Ray Kinsella
On Thu, Jan 28, 2021 at 11:55:34AM +0100, David Marchand wrote:
> On Wed, Jan 27, 2021 at 6:33 PM Bruce Richardson
> <bruce.richardson@intel.com> wrote:
> >
> > As a general principle, each header file should include any other
> > headers it needs to provide data type definitions or macros. For
> > example, any header using the uintX_t types in structures or function
> > prototypes should include "stdint.h" to provide those type definitions.
> >
> > In practice, while many, but not all, headers in DPDK did include all
> > necessary headers, it was never actually checked that each header could
> > be included in a C file and compiled without having any compiler errors
> > about missing definitions. The script "check-includes.sh" could be used
> > for this job, but it was not called out in the documentation, so many
> > contributors may not have been aware of it's existance. It also was
> > difficult to run from a source-code directory, as the script did not
> > automatically allow finding of headers from one DPDK library directory
> > to another [this was probably based on running it on a build created by
> > the "make" build system, where all headers were in a single directory].
> > To attempt to have a build-system integrated replacement, this patchset
> > adds a "chkincs" app in the buildtools directory to verify this on an
> > ongoing basis.
> >
> > This chkincs app does nothing when run, and is not installed as part of
> > a DPDK "ninja install", it's for build-time checking only. Its source
> > code consists of one C file per public DPDK header, where that C file
> > contains nothing except an include for that header. Therefore, if any
> > header is added to the lib folder which fails to compile when included
> > alone, the build of chkincs will fail with a suitable error message.
> > Since this compile checking is not needed on most builds of DPDK, the
> > building of chkincs is disabled by default, but can be enabled by the
> > "test_includes" meson option. To catch errors with patch submissions,
> > the final patch of this series enables it for a single build in
> > test-meson-builds script.
> >
> > Future work could involve doing similar checks on headers for C++
> > compatibility, which was something done by the check-includes.sh script
> > but which is missing here.
> >
> > V6:
> > * Added release notes updates for:
> > - renamed, no-longer-installed header files
> > - new "check_includes" build option
> > - removal of old check_includes script
> > * Included acks from previous versions
>
> I have some comments, see replies on patches.
> I can address them if you are ok, and I would take this series for
> -rc2 without needing a respin.
>
Thomas has some feedback too now, and I think there are one or two patches
where we might want to wait for consensus. However, if you are happy to
take these as they are and do any fixups yourself feel free.
> Sidenote: I like how we are hiding API by simply not exporting headers.
> We need more cleanups like this.
> Ethdev has been cleaned; this will probably remove the need for the
> ABI exception on eth_dev_ops.
> Eventdev, other driver classes and bus drivers will probably be the
> next to look at.
>
Yes, there is plenty more cleanup work still needed.
* The chkincs support added here integrates nicely into the build but does
not fully support everything that the old script did, so investigation is
needed especially for c++ checking support.
* Beyond that we should also look to do cleanup based on IWYU to remove excess
headers. This work gives us a nice safety-net for that as it should flag to
us if we every remove too much from a public header.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3 1/5] lpm: add sve support for lookup on Arm platform
2021-01-28 8:03 0% ` David Marchand
@ 2021-01-28 12:24 3% ` Honnappa Nagarahalli
0 siblings, 0 replies; 200+ results
From: Honnappa Nagarahalli @ 2021-01-28 12:24 UTC (permalink / raw)
To: David Marchand
Cc: Ruifeng Wang, jerinj, Jan Viktorin, Bruce Richardson,
Vladimir Medvedkin, dev, Pavan Nikhilesh, hemant.agrawal, nd,
Honnappa Nagarahalli, nd
<snip>
>
> On Wed, Jan 27, 2021 at 10:03 PM Honnappa Nagarahalli
> <Honnappa.Nagarahalli@arm.com> wrote:
> >
> > <snip>
> >
> > >
> > > On Tue, Jan 12, 2021 at 3:57 AM Ruifeng Wang <ruifeng.wang@arm.com>
> > > wrote:
> > > > diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h
> > > > index 1afe55cdc..28b57683b 100644
> > > > --- a/lib/librte_lpm/rte_lpm.h
> > > > +++ b/lib/librte_lpm/rte_lpm.h
> > > > @@ -402,7 +402,11 @@ rte_lpm_lookupx4(const struct rte_lpm *lpm,
> > > xmm_t ip, uint32_t hop[4],
> > > > uint32_t defv);
> > > >
> > > > #if defined(RTE_ARCH_ARM)
> > > > +#ifdef __ARM_FEATURE_SVE
> > > > +#include "rte_lpm_sve.h"
> > > > +#else
> > > > #include "rte_lpm_neon.h"
> > > > +#endif
> > > > #elif defined(RTE_ARCH_PPC_64)
> > > > #include "rte_lpm_altivec.h"
> > > > #else
> > > > diff --git a/lib/librte_lpm/rte_lpm_sve.h
> > > > b/lib/librte_lpm/rte_lpm_sve.h new file mode 100644 index
> > > > 000000000..2e319373e
> > > > --- /dev/null
> > > > +++ b/lib/librte_lpm/rte_lpm_sve.h
> > > > @@ -0,0 +1,83 @@
> > > > +/* SPDX-License-Identifier: BSD-3-Clause
> > > > + * Copyright(c) 2020 Arm Limited
> > > > + */
> > > > +
> > > > +#ifndef _RTE_LPM_SVE_H_
> > > > +#define _RTE_LPM_SVE_H_
> > > > +
> > > > +#include <rte_vect.h>
> > > > +
> > > > +#ifdef __cplusplus
> > > > +extern "C" {
> > > > +#endif
> > > > +
> > > > +__rte_internal
> > > > +static void
> > >
> > > I was looking into use of the __rte_internal tag in the tree.
> > >
> > > This helper is called from a inlined API used by applications, so
> > > out of the DPDK build.
> > > It looks like the compiler is not complaining when compiling
> > > examples (I hacked my env to cross compile with gcc 10 + SVE
> > > enabled) but this seems incorrect to me.
> > >
> > > Is there really a need for this helper?
> > > It is only used below afaics.
> > I do not think it is required.
> >
> > At the same time the commit log when '__rte_internal' was introduced is
> confusing.
> > It says "Introduce the __rte_internal tag to mark internal ABI function which is
> used only by the drivers or other libraries". Why would an internal function have
> an ABI?
>
> It happens that drivers/libraries in DPDK offer some interface for other parts of
> the DPDK to use.
> But we might want them to keep them hidden to final applications, because this
> is purely internal and/or we don't want to guarantee compatibility in later
> versions.
> For such cases, a function can be marked __rte_internal.
>
>
> This tag has two impacts:
> - a marked symbol is versionned as INTERNAL when exported (so this does not
> apply to inlines),
> - if an application tries to use a marked API, an error is triggered at build time to
> prevent use of such API,
Thanks David, it makes sense now. The word 'internal ABI' in the commit log caused the confusion.
Is this required because all the header files (header files meant for the application and the DPDK internal header files) are in the same directory?
From the above definition, we do not need the internal tag for this function as it is very much internal to LPM library.
>
>
> --
> David Marchand
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v6 2/8] eal: fix error attribute use for clang
2021-01-28 11:20 0% ` Bruce Richardson
@ 2021-01-28 13:36 0% ` David Marchand
2021-01-28 14:16 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2021-01-28 13:36 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev, Wang, Haiyue, Ray Kinsella, Neil Horman
On Thu, Jan 28, 2021 at 12:20 PM Bruce Richardson
<bruce.richardson@intel.com> wrote:
> > If the compiler has neither error or diagnose_if support, an internal
> > API can be called without ALLOW_INTERNAL_API.
> > I prefer a build error complaining on an unknown attribute rather than
> > silence a check.
> >
> > I.e.
> >
> > #ifndef ALLOW_INTERNAL_API
> >
> > #if __has_attribute(diagnose_if) /* For clang */
> > #define __rte_internal \
> > __attribute__((diagnose_if(1, "Symbol is not public ABI", "error"), \
> > section(".text.internal")))
> >
> > #else
> > #define __rte_internal \
> > __attribute__((error("Symbol is not public ABI"), \
> > section(".text.internal")))
> >
> > #endif
> >
> > #else /* ALLOW_INTERNAL_API */
> >
> > #define __rte_internal \
> > section(".text.internal")))
> >
> > #endif
> >
>
> Would this not mean that if someone was using a compiler that supported
> neither that they could never include any header file which contained any
> internal functions? I'd rather err on the side of allowing this, on the
> basis that the symbol should be already documented as internal and this is
> only an additional sanity check.
- Still not a fan.
We will never know about those compilers behavior, like how we caught
the clang issue and found an alternative.
- I just caught a build error with RHEL7 gcc:
[1/2127] Compiling C object
lib/librte_eal.a.p/librte_eal_common_eal_common_config.c.o
FAILED: lib/librte_eal.a.p/librte_eal_common_eal_common_config.c.o
ccache cc -Ilib/librte_eal.a.p -Ilib -I../lib -I. -I.. -Iconfig
-I../config -Ilib/librte_eal/include -I../lib/librte_eal/include
-Ilib/librte_eal/linux/include -I../lib/librte_eal/linux/include
-Ilib/librte_eal/x86/include -I../lib/librte_eal/x86/include
-Ilib/librte_eal/common -I../lib/librte_eal/common -Ilib/librte_eal
-I../lib/librte_eal -Ilib/librte_kvargs -I../lib/librte_kvargs
-Ilib/librte_metrics -I../lib/librte_metrics -Ilib/librte_telemetry
-I../lib/librte_telemetry -pipe -D_FILE_OFFSET_BITS=64 -Wall
-Winvalid-pch -O3 -include rte_config.h -Wextra -Wcast-qual
-Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security
-Wmissing-declarations -Wmissing-prototypes -Wnested-externs
-Wold-style-definition -Wpointer-arith -Wsign-compare
-Wstrict-prototypes -Wundef -Wwrite-strings
-Wno-missing-field-initializers -D_GNU_SOURCE -fPIC -march=native
-DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API '-DABI_VERSION="21.1"'
-MD -MQ lib/librte_eal.a.p/librte_eal_common_eal_common_config.c.o -MF
lib/librte_eal.a.p/librte_eal_common_eal_common_config.c.o.d -o
lib/librte_eal.a.p/librte_eal_common_eal_common_config.c.o -c
../lib/librte_eal/common/eal_common_config.c
In file included from ../lib/librte_eal/include/rte_dev.h:24:0,
from ../lib/librte_eal/common/eal_private.h:12,
from ../lib/librte_eal/common/eal_common_config.c:9:
../lib/librte_eal/include/rte_compat.h:22:51: error: missing binary
operator before token "("
#if !defined ALLOW_INTERNAL_API && __has_attribute(error) /* For GCC */
^
../lib/librte_eal/include/rte_compat.h:28:53: error: missing binary
operator before token "("
#elif !defined ALLOW_INTERNAL_API && __has_attribute(diagnose_if) /*
For clang */
^
I can see that gcc doc recommends checking for __has_attribute availability.
Pasting from google cache, since the gcc.gnu.org doc website seems unavailable.
"""
4.2.6 __has_attribute
The special operator __has_attribute (operand) may be used in ‘#if’
and ‘#elif’ expressions to test whether the attribute referenced by
its operand is recognized by GCC. Using the operator in other contexts
is not valid. In C code, if compiling for strict conformance to
standards before C2x, operand must be a valid identifier. Otherwise,
operand may be optionally introduced by the attribute-scope:: prefix.
The attribute-scope prefix identifies the “namespace” within which the
attribute is recognized. The scope of GCC attributes is ‘gnu’ or
‘__gnu__’. The __has_attribute operator by itself, without any operand
or parentheses, acts as a predefined macro so that support for it can
be tested in portable code. Thus, the recommended use of the operator
is as follows:
#if defined __has_attribute
# if __has_attribute (nonnull)
# define ATTR_NONNULL __attribute__ ((nonnull))
# endif
#endif
The first ‘#if’ test succeeds only when the operator is supported by
the version of GCC (or another compiler) being used. Only when that
test succeeds is it valid to use __has_attribute as a preprocessor
operator. As a result, combining the two tests into a single
expression as shown below would only be valid with a compiler that
supports the operator but not with others that don’t.
#if defined __has_attribute && __has_attribute (nonnull) /* not portable */
…
#endif
"""
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v6 2/8] eal: fix error attribute use for clang
2021-01-28 13:36 0% ` David Marchand
@ 2021-01-28 14:16 0% ` Bruce Richardson
2021-01-28 15:16 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2021-01-28 14:16 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Wang, Haiyue, Ray Kinsella, Neil Horman
On Thu, Jan 28, 2021 at 02:36:25PM +0100, David Marchand wrote:
> On Thu, Jan 28, 2021 at 12:20 PM Bruce Richardson
> <bruce.richardson@intel.com> wrote:
> > > If the compiler has neither error or diagnose_if support, an internal
> > > API can be called without ALLOW_INTERNAL_API.
> > > I prefer a build error complaining on an unknown attribute rather than
> > > silence a check.
> > >
> > > I.e.
> > >
> > > #ifndef ALLOW_INTERNAL_API
> > >
> > > #if __has_attribute(diagnose_if) /* For clang */
> > > #define __rte_internal \
> > > __attribute__((diagnose_if(1, "Symbol is not public ABI", "error"), \
> > > section(".text.internal")))
> > >
> > > #else
> > > #define __rte_internal \
> > > __attribute__((error("Symbol is not public ABI"), \
> > > section(".text.internal")))
> > >
> > > #endif
> > >
> > > #else /* ALLOW_INTERNAL_API */
> > >
> > > #define __rte_internal \
> > > section(".text.internal")))
> > >
> > > #endif
> > >
> >
> > Would this not mean that if someone was using a compiler that supported
> > neither that they could never include any header file which contained any
> > internal functions? I'd rather err on the side of allowing this, on the
> > basis that the symbol should be already documented as internal and this is
> > only an additional sanity check.
>
> - Still not a fan.
> We will never know about those compilers behavior, like how we caught
> the clang issue and found an alternative.
>
So I understand, but I'm still concerned about breaking something that was
previously working. It's one thing a DPDK developer catching issues with
clang, quite another a user catching it when trying to build their own
application.
We probably need some other opinions on this one.
>
> - I just caught a build error with RHEL7 gcc:
>
> [1/2127] Compiling C object
> lib/librte_eal.a.p/librte_eal_common_eal_common_config.c.o
> FAILED: lib/librte_eal.a.p/librte_eal_common_eal_common_config.c.o
> ccache cc -Ilib/librte_eal.a.p -Ilib -I../lib -I. -I.. -Iconfig
> -I../config -Ilib/librte_eal/include -I../lib/librte_eal/include
> -Ilib/librte_eal/linux/include -I../lib/librte_eal/linux/include
> -Ilib/librte_eal/x86/include -I../lib/librte_eal/x86/include
> -Ilib/librte_eal/common -I../lib/librte_eal/common -Ilib/librte_eal
> -I../lib/librte_eal -Ilib/librte_kvargs -I../lib/librte_kvargs
> -Ilib/librte_metrics -I../lib/librte_metrics -Ilib/librte_telemetry
> -I../lib/librte_telemetry -pipe -D_FILE_OFFSET_BITS=64 -Wall
> -Winvalid-pch -O3 -include rte_config.h -Wextra -Wcast-qual
> -Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security
> -Wmissing-declarations -Wmissing-prototypes -Wnested-externs
> -Wold-style-definition -Wpointer-arith -Wsign-compare
> -Wstrict-prototypes -Wundef -Wwrite-strings
> -Wno-missing-field-initializers -D_GNU_SOURCE -fPIC -march=native
> -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API '-DABI_VERSION="21.1"'
> -MD -MQ lib/librte_eal.a.p/librte_eal_common_eal_common_config.c.o -MF
> lib/librte_eal.a.p/librte_eal_common_eal_common_config.c.o.d -o
> lib/librte_eal.a.p/librte_eal_common_eal_common_config.c.o -c
> ../lib/librte_eal/common/eal_common_config.c
> In file included from ../lib/librte_eal/include/rte_dev.h:24:0,
> from ../lib/librte_eal/common/eal_private.h:12,
> from ../lib/librte_eal/common/eal_common_config.c:9:
> ../lib/librte_eal/include/rte_compat.h:22:51: error: missing binary
> operator before token "("
> #if !defined ALLOW_INTERNAL_API && __has_attribute(error) /* For GCC */
> ^
> ../lib/librte_eal/include/rte_compat.h:28:53: error: missing binary
> operator before token "("
> #elif !defined ALLOW_INTERNAL_API && __has_attribute(diagnose_if) /*
> For clang */
> ^
>
> I can see that gcc doc recommends checking for __has_attribute availability.
> Pasting from google cache, since the gcc.gnu.org doc website seems unavailable.
>
> """
> 4.2.6 __has_attribute
>
> The special operator __has_attribute (operand) may be used in ‘#if’
> and ‘#elif’ expressions to test whether the attribute referenced by
> its operand is recognized by GCC. Using the operator in other contexts
> is not valid. In C code, if compiling for strict conformance to
> standards before C2x, operand must be a valid identifier. Otherwise,
> operand may be optionally introduced by the attribute-scope:: prefix.
> The attribute-scope prefix identifies the “namespace” within which the
> attribute is recognized. The scope of GCC attributes is ‘gnu’ or
> ‘__gnu__’. The __has_attribute operator by itself, without any operand
> or parentheses, acts as a predefined macro so that support for it can
> be tested in portable code. Thus, the recommended use of the operator
> is as follows:
>
> #if defined __has_attribute
> # if __has_attribute (nonnull)
> # define ATTR_NONNULL __attribute__ ((nonnull))
> # endif
> #endif
>
> The first ‘#if’ test succeeds only when the operator is supported by
> the version of GCC (or another compiler) being used. Only when that
> test succeeds is it valid to use __has_attribute as a preprocessor
> operator. As a result, combining the two tests into a single
> expression as shown below would only be valid with a compiler that
> supports the operator but not with others that don’t.
>
> #if defined __has_attribute && __has_attribute (nonnull) /* not portable */
> …
> #endif
> """
>
I really wish other tools would do like meson and document per-feature the
version in which it was introduced! Anyway, this is something I'll fix in
next version, though again we need to decide in the case of __has_attribute
not being supported do we fall to erroring out? Again that runs the risk of
users not being able to include a header which has an internal function, so
I'd prefer us to ignore errors if the appropriate macros are unsupported.
Again, other opinions probably needed.
/Bruce
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v6 2/8] eal: fix error attribute use for clang
2021-01-28 14:16 0% ` Bruce Richardson
@ 2021-01-28 15:16 0% ` Bruce Richardson
2021-01-28 16:46 0% ` [dpdk-dev] [dpdk-techboard] " Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2021-01-28 15:16 UTC (permalink / raw)
To: David Marchand, techboard; +Cc: dev
On Thu, Jan 28, 2021 at 02:16:10PM +0000, Bruce Richardson wrote:
> On Thu, Jan 28, 2021 at 02:36:25PM +0100, David Marchand wrote:
> > On Thu, Jan 28, 2021 at 12:20 PM Bruce Richardson
> > <bruce.richardson@intel.com> wrote:
> > > > If the compiler has neither error or diagnose_if support, an internal
> > > > API can be called without ALLOW_INTERNAL_API.
> > > > I prefer a build error complaining on an unknown attribute rather than
> > > > silence a check.
> > > >
> > > > I.e.
> > > >
> > > > #ifndef ALLOW_INTERNAL_API
> > > >
> > > > #if __has_attribute(diagnose_if) /* For clang */
> > > > #define __rte_internal \
> > > > __attribute__((diagnose_if(1, "Symbol is not public ABI", "error"), \
> > > > section(".text.internal")))
> > > >
> > > > #else
> > > > #define __rte_internal \
> > > > __attribute__((error("Symbol is not public ABI"), \
> > > > section(".text.internal")))
> > > >
> > > > #endif
> > > >
> > > > #else /* ALLOW_INTERNAL_API */
> > > >
> > > > #define __rte_internal \
> > > > section(".text.internal")))
> > > >
> > > > #endif
> > > >
> > >
> > > Would this not mean that if someone was using a compiler that supported
> > > neither that they could never include any header file which contained any
> > > internal functions? I'd rather err on the side of allowing this, on the
> > > basis that the symbol should be already documented as internal and this is
> > > only an additional sanity check.
> >
> > - Still not a fan.
> > We will never know about those compilers behavior, like how we caught
> > the clang issue and found an alternative.
> >
>
> So I understand, but I'm still concerned about breaking something that was
> previously working. It's one thing a DPDK developer catching issues with
> clang, quite another a user catching it when trying to build their own
> application.
>
> We probably need some other opinions on this one.
>
Adding Tech-board to see if we can get some more thoughts on this before I do
another revision of this set.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [dpdk-techboard] [PATCH v6 2/8] eal: fix error attribute use for clang
2021-01-28 15:16 0% ` Bruce Richardson
@ 2021-01-28 16:46 0% ` Thomas Monjalon
2021-01-28 17:36 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2021-01-28 16:46 UTC (permalink / raw)
To: David Marchand, Bruce Richardson; +Cc: techboard, dev
28/01/2021 16:16, Bruce Richardson:
> On Thu, Jan 28, 2021 at 02:16:10PM +0000, Bruce Richardson wrote:
> > On Thu, Jan 28, 2021 at 02:36:25PM +0100, David Marchand wrote:
> > > On Thu, Jan 28, 2021 at 12:20 PM Bruce Richardson
> > > <bruce.richardson@intel.com> wrote:
> > > > > If the compiler has neither error or diagnose_if support, an internal
> > > > > API can be called without ALLOW_INTERNAL_API.
> > > > > I prefer a build error complaining on an unknown attribute rather than
> > > > > silence a check.
> > > > >
> > > > > I.e.
> > > > >
> > > > > #ifndef ALLOW_INTERNAL_API
> > > > >
> > > > > #if __has_attribute(diagnose_if) /* For clang */
> > > > > #define __rte_internal \
> > > > > __attribute__((diagnose_if(1, "Symbol is not public ABI", "error"), \
> > > > > section(".text.internal")))
> > > > >
> > > > > #else
> > > > > #define __rte_internal \
> > > > > __attribute__((error("Symbol is not public ABI"), \
> > > > > section(".text.internal")))
> > > > >
> > > > > #endif
> > > > >
> > > > > #else /* ALLOW_INTERNAL_API */
> > > > >
> > > > > #define __rte_internal \
> > > > > section(".text.internal")))
> > > > >
> > > > > #endif
> > > > >
> > > >
> > > > Would this not mean that if someone was using a compiler that supported
> > > > neither that they could never include any header file which contained any
> > > > internal functions? I'd rather err on the side of allowing this, on the
> > > > basis that the symbol should be already documented as internal and this is
> > > > only an additional sanity check.
> > >
> > > - Still not a fan.
> > > We will never know about those compilers behavior, like how we caught
> > > the clang issue and found an alternative.
> > >
> >
> > So I understand, but I'm still concerned about breaking something that was
> > previously working. It's one thing a DPDK developer catching issues with
> > clang, quite another a user catching it when trying to build their own
> > application.
> >
> > We probably need some other opinions on this one.
> >
> Adding Tech-board to see if we can get some more thoughts on this before I do
> another revision of this set.
What are the alternatives?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [dpdk-techboard] [PATCH v6 2/8] eal: fix error attribute use for clang
2021-01-28 16:46 0% ` [dpdk-dev] [dpdk-techboard] " Thomas Monjalon
@ 2021-01-28 17:36 0% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2021-01-28 17:36 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: David Marchand, techboard, dev
On Thu, Jan 28, 2021 at 05:46:16PM +0100, Thomas Monjalon wrote:
> 28/01/2021 16:16, Bruce Richardson:
> > On Thu, Jan 28, 2021 at 02:16:10PM +0000, Bruce Richardson wrote:
> > > On Thu, Jan 28, 2021 at 02:36:25PM +0100, David Marchand wrote:
> > > > On Thu, Jan 28, 2021 at 12:20 PM Bruce Richardson
> > > > <bruce.richardson@intel.com> wrote:
> > > > > > If the compiler has neither error or diagnose_if support, an internal
> > > > > > API can be called without ALLOW_INTERNAL_API.
> > > > > > I prefer a build error complaining on an unknown attribute rather than
> > > > > > silence a check.
> > > > > >
> > > > > > I.e.
> > > > > >
> > > > > > #ifndef ALLOW_INTERNAL_API
> > > > > >
> > > > > > #if __has_attribute(diagnose_if) /* For clang */
> > > > > > #define __rte_internal \
> > > > > > __attribute__((diagnose_if(1, "Symbol is not public ABI", "error"), \
> > > > > > section(".text.internal")))
> > > > > >
> > > > > > #else
> > > > > > #define __rte_internal \
> > > > > > __attribute__((error("Symbol is not public ABI"), \
> > > > > > section(".text.internal")))
> > > > > >
> > > > > > #endif
> > > > > >
> > > > > > #else /* ALLOW_INTERNAL_API */
> > > > > >
> > > > > > #define __rte_internal \
> > > > > > section(".text.internal")))
> > > > > >
> > > > > > #endif
> > > > > >
> > > > >
> > > > > Would this not mean that if someone was using a compiler that supported
> > > > > neither that they could never include any header file which contained any
> > > > > internal functions? I'd rather err on the side of allowing this, on the
> > > > > basis that the symbol should be already documented as internal and this is
> > > > > only an additional sanity check.
> > > >
> > > > - Still not a fan.
> > > > We will never know about those compilers behavior, like how we caught
> > > > the clang issue and found an alternative.
> > > >
> > >
> > > So I understand, but I'm still concerned about breaking something that was
> > > previously working. It's one thing a DPDK developer catching issues with
> > > clang, quite another a user catching it when trying to build their own
> > > application.
> > >
> > > We probably need some other opinions on this one.
> > >
> > Adding Tech-board to see if we can get some more thoughts on this before I do
> > another revision of this set.
>
> What are the alternatives?
>
The basic problem is what to do when a compiler is used which does not support
the required macros to flag an error for use of an internal-only function.
For example, we discovered this because clang does not support the #error
macro.
In those cases, as I see it, we really have two choices:
1 ignore flagging the error and silently allow possible use of the internal
function.
2 have the compiler flag an error for an unknown macro
The problem that I have with #2 is that without knowing the macro, the
compiler will likely error out any time a user app includes any header with
an internal function, even if the function is unused.
On the other hand, the likelihood of impact if we choose #2 and do error out is
quite small, since modern clang versions will support the modern macro
checks we need, and just about any gcc versions we care about are going to
support #error.
For #1, the downside is that we will miss error checks on some older
versions of gcc e.g. RHEL 7, and the user may inadvertently use an internal
function without knowing it.
David, anything else to add here?
/Bruce
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v7 02/10] eal: fix error attribute use for clang
@ 2021-01-29 16:48 13% ` Bruce Richardson
1 sibling, 0 replies; 200+ results
From: Bruce Richardson @ 2021-01-29 16:48 UTC (permalink / raw)
To: dev
Cc: david.marchand, Bruce Richardson, stable, Ray Kinsella,
Neil Horman, Haiyue Wang
Clang does not have an "error" attribute for functions, so for marking
internal functions we need to check for the error attribute, and provide
a fallback if it is not present. For clang, we can use "diagnose_if"
attribute, similarly checking for its presence before use.
Fixes: fba5af82adc8 ("eal: add internal ABI tag definition")
Cc: stable@dpdk.org
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
lib/librte_eal/include/rte_compat.h | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/lib/librte_eal/include/rte_compat.h b/lib/librte_eal/include/rte_compat.h
index 4cd8f68d68..2718612cce 100644
--- a/lib/librte_eal/include/rte_compat.h
+++ b/lib/librte_eal/include/rte_compat.h
@@ -19,12 +19,23 @@ __attribute__((section(".text.experimental")))
#endif
-#ifndef ALLOW_INTERNAL_API
+#ifndef __has_attribute
+/* if no has_attribute assume no support for attribute too */
+#define __has_attribute(x) 0
+#endif
+
+#if !defined ALLOW_INTERNAL_API && __has_attribute(error) /* For GCC */
#define __rte_internal \
__attribute__((error("Symbol is not public ABI"), \
section(".text.internal")))
+#elif !defined ALLOW_INTERNAL_API && __has_attribute(diagnose_if) /* For clang */
+
+#define __rte_internal \
+__attribute__((diagnose_if(1, "Symbol is not public ABI", "error"), \
+section(".text.internal")))
+
#else
#define __rte_internal \
--
2.27.0
^ permalink raw reply [relevance 13%]
* Re: [dpdk-dev] [PATCH v4 00/44] net/virtio: Virtio PMD rework
2021-01-26 10:15 3% [dpdk-dev] [PATCH v4 00/44] net/virtio: Virtio PMD rework Maxime Coquelin
2021-01-26 10:15 7% ` [dpdk-dev] [PATCH v4 02/44] bus/vdev: add driver IOVA VA mode requirement Maxime Coquelin
2021-01-27 11:59 0% ` [dpdk-dev] [PATCH v4 00/44] net/virtio: Virtio PMD rework Maxime Coquelin
@ 2021-02-01 8:44 0% ` Wang, Yinan
2021-02-01 8:49 0% ` Maxime Coquelin
2 siblings, 1 reply; 200+ results
From: Wang, Yinan @ 2021-02-01 8:44 UTC (permalink / raw)
To: Maxime Coquelin, dev, Xia, Chenbo, olivier.matz, amorenoz,
david.marchand
Cc: Ling, WeiX, Jiang, YuX
Hi Maxime.
We found three virtio issues and bad commit is this patch set. Could you help to take a look?
https://bugs.dpdk.org/show_bug.cgi?id=631
Issue1: vdev_primary_secondary/Virtio_primary_and_secondary_process: start dpdk-symmetric_mp occur core dumped in vm
Issue2: start testpmd occur core dumped in vm when use more than 1 virtio-pmd.
https://bugs.dpdk.org/show_bug.cgi?id=630
issue3: hotplug_mp/attach_detach_virtio_user: The host display is abnormal after dpdk-hotplug_mp exits
BR,
Yinan
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Maxime Coquelin
> Sent: 2021?1?26? 18:16
> To: dev@dpdk.org; Xia, Chenbo <chenbo.xia@intel.com>;
> olivier.matz@6wind.com; amorenoz@redhat.com;
> david.marchand@redhat.com
> Cc: Maxime Coquelin <maxime.coquelin@redhat.com>
> Subject: [dpdk-dev] [PATCH v4 00/44] net/virtio: Virtio PMD rework
>
> This V3 fixes comments from Chenbo on patch 44 and
> implements the ABI exception in patch 2.
>
> This series significantly rework Virtio PMD to improve
> the Virtio-user PMD and its backends integration.
>
> First part of the series removes the dependency of
> Virtio-user ethdev on Virtio PCI, by creating generic
> files, adding per-bus meta data, ...
>
> Main (if not single) functionnal change of this first
> part is to remove the hack for Virtio-user to work in
> IOVA as PA mode, this hack being very fragile.
>
> Second part of the series reworks Virtio-user internal,
> by reworking the requests handling so that vDPA and Kernel
> backends no more hack into being Vhost-user backend. It
> implies implementing new ops for all the request types.
> Also, all the backend specific actions are moved from the
> virtio_user_dev.c and virtio_user_ethdev.c to their
> backend files.
>
> Only functionnal change in this second part is making the
> Vhost-user server mode blocking at init time, as long as
> a client is not connected. The goal of this change is to
> make the Vhost-user support much more robust, as without
> blocking, the driver has to assume features that are going
> to be supported by the client, which is very fragile and
> error prone. As a side-effect, it also simplifies the
> logic nin several place of the virtio-user PMD.
>
> Main changes in v4:
> - Add ABI exception (David)
> - Close FDs only up to max_queue_pairs
> - virtio_user_dev_uninit_notify() to return void
>
> Main changes in v3:
> - Rename .intr_event to .intr_detect
> - Rework last patch, properly clean allocated resources
> on failure.
> - Rebase on top of latest net-next/main
> - Minor typo fixes in comments and log improvements
>
> Main changes in v2:
> ===================
> - Introduce vdev driver flag for drivers to require IOVA VA mode
> - Rebase on top of -rc1 changes
> - Fix regressions introduced in V1 (vhost-kernel broken, vhost-user
> reconnect...)
> - Various minor issues & typos fixed
> - Fix status feature issue introduced in v20.11, only reproduceable now that
> server
> mode is made blocking
> - Improve failure handling in Virtio-user
> - Improve logging
>
> Testing coverage (All passed)
> =============================
> - Virtio-pci PMD
> * Virtio PMD in guest with Vhost-user backend in host
> * Virtio PMD in guest with Vhost-kernel backend in host
> - Virtio-user PMD with Vhost-user backend
> * Vhost-user PMD server <-> Virtio-user client PMD IO loopback
> * Vhost-user PMD client <-> Virtio-user server PMD IO loopback
> * Vhost-user PMD client <-> Virtio-user server PMD reconnect
> - Virtio-user PMD with Vhost-kernel backend
> * iperf test case
> * Txonly testpmd
> - Virtio-user PMD with Vhost-vDPA backend
> * vdpa-sim (IO loopback)
> * CX-6 DX Kernel vDPA (Tx only)
>
> Maxime Coquelin (44):
> bus/vdev: add helper to get vdev from ethdev
> bus/vdev: add driver IOVA VA mode requirement
> net/virtio: fix getting old status on reconnect
> net/virtio: introduce Virtio bus type
> net/virtio: refactor virtio-user device
> net/virtio: introduce PCI device metadata
> net/virtio: move PCI device init in dedicated file
> net/virtio: move PCI specific dev init to PCI ethdev init
> net/virtio: move MSIX detection to PCI ethdev
> net/virtio: force IOVA as VA mode for Virtio-user
> net/virtio: store PCI type in Virtio device metadata
> net/virtio: add callback for device closing
> net/virtio: validate features at bus level
> net/virtio: remove bus type enum
> net/virtio: move PCI-specific fields to PCI device
> net/virtio: pack virtio HW struct
> net/virtio: move legacy IO to Virtio PCI
> net/virtio: introduce generic virtio header
> net/virtio: move features definition to generic header
> net/virtio: move virtqueue defines in generic header
> net/virtio: move config definitions to generic header
> net/virtio: make interrupt handling more generic
> net/virtio: move vring alignment to generic header
> net/virtio: remove last PCI refs in non-PCI code
> net/virtio: make Vhost-user request sender consistent
> net/virtio: add Virtio-user ops to set owner
> net/virtio: add Virtio-user features ops
> net/virtio: add Virtio-user protocol features ops
> net/virtio: add Virtio-user memory tables ops
> net/virtio: add Virtio-user vring setting ops
> net/virtio: add Virtio-user vring file ops
> net/virtio: add Virtio-user vring address ops
> net/virtio: add Virtio-user status ops
> net/virtio: remove useless request ops
> net/virtio: improve Virtio-user errors handling
> net/virtio: move Vhost-user requests to Vhost-user backend
> net/virtio: make server mode blocking
> net/virtio: move protocol features to Vhost-user
> net/virtio: introduce backend data
> net/virtio: move Vhost-user specifics to its backend
> net/virtio: move Vhost-kernel data to its backend
> net/virtio: move Vhost-vDPA data to its backend
> net/virtio: improve Vhost-user error logging
> net/virtio: handle Virtio-user setup failure properly
>
> devtools/libabigail.abignore | 2 +
> drivers/bus/vdev/rte_bus_vdev.h | 6 +
> drivers/bus/vdev/vdev.c | 29 +
> drivers/net/virtio/meson.build | 6 +-
> drivers/net/virtio/virtio.c | 71 ++
> drivers/net/virtio/virtio.h | 246 +++++
> drivers/net/virtio/virtio_ethdev.c | 457 +++------
> drivers/net/virtio/virtio_ethdev.h | 6 +-
> drivers/net/virtio/virtio_pci.c | 448 +++++----
> drivers/net/virtio/virtio_pci.h | 286 +-----
> drivers/net/virtio/virtio_pci_ethdev.c | 226 +++++
> drivers/net/virtio/virtio_ring.h | 2 +-
> drivers/net/virtio/virtio_rxtx.c | 90 +-
> drivers/net/virtio/virtio_rxtx_packed.h | 10 +-
> drivers/net/virtio/virtio_rxtx_packed_avx.h | 10 +-
> drivers/net/virtio/virtio_rxtx_packed_neon.h | 10 +-
> drivers/net/virtio/virtio_rxtx_simple.h | 3 +-
> drivers/net/virtio/virtio_user/vhost.h | 79 +-
> drivers/net/virtio/virtio_user/vhost_kernel.c | 461 ++++++---
> .../net/virtio/virtio_user/vhost_kernel_tap.c | 25 +-
> .../net/virtio/virtio_user/vhost_kernel_tap.h | 1 +
> drivers/net/virtio/virtio_user/vhost_user.c | 898 ++++++++++++++----
> drivers/net/virtio/virtio_user/vhost_vdpa.c | 323 +++++--
> .../net/virtio/virtio_user/virtio_user_dev.c | 573 ++++++-----
> .../net/virtio/virtio_user/virtio_user_dev.h | 21 +-
> drivers/net/virtio/virtio_user_ethdev.c | 301 +-----
> drivers/net/virtio/virtqueue.c | 6 +-
> drivers/net/virtio/virtqueue.h | 45 +-
> 28 files changed, 2742 insertions(+), 1899 deletions(-)
> create mode 100644 drivers/net/virtio/virtio.c
> create mode 100644 drivers/net/virtio/virtio.h
> create mode 100644 drivers/net/virtio/virtio_pci_ethdev.c
>
> --
> 2.29.2
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4 00/44] net/virtio: Virtio PMD rework
2021-02-01 8:44 0% ` Wang, Yinan
@ 2021-02-01 8:49 0% ` Maxime Coquelin
0 siblings, 0 replies; 200+ results
From: Maxime Coquelin @ 2021-02-01 8:49 UTC (permalink / raw)
To: Wang, Yinan, dev, Xia, Chenbo, olivier.matz, amorenoz, david.marchand
Cc: Ling, WeiX, Jiang, YuX
Hi Yinan,
On 2/1/21 9:44 AM, Wang, Yinan wrote:
> Hi Maxime.
>
> We found three virtio issues and bad commit is this patch set. Could you help to take a look?
Thanks for the testing and reports.
I'm already working on Bz630, will keep you updated.
> https://bugs.dpdk.org/show_bug.cgi?id=631
> Issue1: vdev_primary_secondary/Virtio_primary_and_secondary_process: start dpdk-symmetric_mp occur core dumped in vm
>
> Issue2: start testpmd occur core dumped in vm when use more than 1 virtio-pmd.
>
> https://bugs.dpdk.org/show_bug.cgi?id=630
>
> issue3: hotplug_mp/attach_detach_virtio_user: The host display is abnormal after dpdk-hotplug_mp exits
>
Thanks,
Maxime
> BR,
> Yinan
>> -----Original Message-----
>> From: dev <dev-bounces@dpdk.org> On Behalf Of Maxime Coquelin
>> Sent: 2021?1?26? 18:16
>> To: dev@dpdk.org; Xia, Chenbo <chenbo.xia@intel.com>;
>> olivier.matz@6wind.com; amorenoz@redhat.com;
>> david.marchand@redhat.com
>> Cc: Maxime Coquelin <maxime.coquelin@redhat.com>
>> Subject: [dpdk-dev] [PATCH v4 00/44] net/virtio: Virtio PMD rework
>>
>> This V3 fixes comments from Chenbo on patch 44 and
>> implements the ABI exception in patch 2.
>>
>> This series significantly rework Virtio PMD to improve
>> the Virtio-user PMD and its backends integration.
>>
>> First part of the series removes the dependency of
>> Virtio-user ethdev on Virtio PCI, by creating generic
>> files, adding per-bus meta data, ...
>>
>> Main (if not single) functionnal change of this first
>> part is to remove the hack for Virtio-user to work in
>> IOVA as PA mode, this hack being very fragile.
>>
>> Second part of the series reworks Virtio-user internal,
>> by reworking the requests handling so that vDPA and Kernel
>> backends no more hack into being Vhost-user backend. It
>> implies implementing new ops for all the request types.
>> Also, all the backend specific actions are moved from the
>> virtio_user_dev.c and virtio_user_ethdev.c to their
>> backend files.
>>
>> Only functionnal change in this second part is making the
>> Vhost-user server mode blocking at init time, as long as
>> a client is not connected. The goal of this change is to
>> make the Vhost-user support much more robust, as without
>> blocking, the driver has to assume features that are going
>> to be supported by the client, which is very fragile and
>> error prone. As a side-effect, it also simplifies the
>> logic nin several place of the virtio-user PMD.
>>
>> Main changes in v4:
>> - Add ABI exception (David)
>> - Close FDs only up to max_queue_pairs
>> - virtio_user_dev_uninit_notify() to return void
>>
>> Main changes in v3:
>> - Rename .intr_event to .intr_detect
>> - Rework last patch, properly clean allocated resources
>> on failure.
>> - Rebase on top of latest net-next/main
>> - Minor typo fixes in comments and log improvements
>>
>> Main changes in v2:
>> ===================
>> - Introduce vdev driver flag for drivers to require IOVA VA mode
>> - Rebase on top of -rc1 changes
>> - Fix regressions introduced in V1 (vhost-kernel broken, vhost-user
>> reconnect...)
>> - Various minor issues & typos fixed
>> - Fix status feature issue introduced in v20.11, only reproduceable now that
>> server
>> mode is made blocking
>> - Improve failure handling in Virtio-user
>> - Improve logging
>>
>> Testing coverage (All passed)
>> =============================
>> - Virtio-pci PMD
>> * Virtio PMD in guest with Vhost-user backend in host
>> * Virtio PMD in guest with Vhost-kernel backend in host
>> - Virtio-user PMD with Vhost-user backend
>> * Vhost-user PMD server <-> Virtio-user client PMD IO loopback
>> * Vhost-user PMD client <-> Virtio-user server PMD IO loopback
>> * Vhost-user PMD client <-> Virtio-user server PMD reconnect
>> - Virtio-user PMD with Vhost-kernel backend
>> * iperf test case
>> * Txonly testpmd
>> - Virtio-user PMD with Vhost-vDPA backend
>> * vdpa-sim (IO loopback)
>> * CX-6 DX Kernel vDPA (Tx only)
>>
>> Maxime Coquelin (44):
>> bus/vdev: add helper to get vdev from ethdev
>> bus/vdev: add driver IOVA VA mode requirement
>> net/virtio: fix getting old status on reconnect
>> net/virtio: introduce Virtio bus type
>> net/virtio: refactor virtio-user device
>> net/virtio: introduce PCI device metadata
>> net/virtio: move PCI device init in dedicated file
>> net/virtio: move PCI specific dev init to PCI ethdev init
>> net/virtio: move MSIX detection to PCI ethdev
>> net/virtio: force IOVA as VA mode for Virtio-user
>> net/virtio: store PCI type in Virtio device metadata
>> net/virtio: add callback for device closing
>> net/virtio: validate features at bus level
>> net/virtio: remove bus type enum
>> net/virtio: move PCI-specific fields to PCI device
>> net/virtio: pack virtio HW struct
>> net/virtio: move legacy IO to Virtio PCI
>> net/virtio: introduce generic virtio header
>> net/virtio: move features definition to generic header
>> net/virtio: move virtqueue defines in generic header
>> net/virtio: move config definitions to generic header
>> net/virtio: make interrupt handling more generic
>> net/virtio: move vring alignment to generic header
>> net/virtio: remove last PCI refs in non-PCI code
>> net/virtio: make Vhost-user request sender consistent
>> net/virtio: add Virtio-user ops to set owner
>> net/virtio: add Virtio-user features ops
>> net/virtio: add Virtio-user protocol features ops
>> net/virtio: add Virtio-user memory tables ops
>> net/virtio: add Virtio-user vring setting ops
>> net/virtio: add Virtio-user vring file ops
>> net/virtio: add Virtio-user vring address ops
>> net/virtio: add Virtio-user status ops
>> net/virtio: remove useless request ops
>> net/virtio: improve Virtio-user errors handling
>> net/virtio: move Vhost-user requests to Vhost-user backend
>> net/virtio: make server mode blocking
>> net/virtio: move protocol features to Vhost-user
>> net/virtio: introduce backend data
>> net/virtio: move Vhost-user specifics to its backend
>> net/virtio: move Vhost-kernel data to its backend
>> net/virtio: move Vhost-vDPA data to its backend
>> net/virtio: improve Vhost-user error logging
>> net/virtio: handle Virtio-user setup failure properly
>>
>> devtools/libabigail.abignore | 2 +
>> drivers/bus/vdev/rte_bus_vdev.h | 6 +
>> drivers/bus/vdev/vdev.c | 29 +
>> drivers/net/virtio/meson.build | 6 +-
>> drivers/net/virtio/virtio.c | 71 ++
>> drivers/net/virtio/virtio.h | 246 +++++
>> drivers/net/virtio/virtio_ethdev.c | 457 +++------
>> drivers/net/virtio/virtio_ethdev.h | 6 +-
>> drivers/net/virtio/virtio_pci.c | 448 +++++----
>> drivers/net/virtio/virtio_pci.h | 286 +-----
>> drivers/net/virtio/virtio_pci_ethdev.c | 226 +++++
>> drivers/net/virtio/virtio_ring.h | 2 +-
>> drivers/net/virtio/virtio_rxtx.c | 90 +-
>> drivers/net/virtio/virtio_rxtx_packed.h | 10 +-
>> drivers/net/virtio/virtio_rxtx_packed_avx.h | 10 +-
>> drivers/net/virtio/virtio_rxtx_packed_neon.h | 10 +-
>> drivers/net/virtio/virtio_rxtx_simple.h | 3 +-
>> drivers/net/virtio/virtio_user/vhost.h | 79 +-
>> drivers/net/virtio/virtio_user/vhost_kernel.c | 461 ++++++---
>> .../net/virtio/virtio_user/vhost_kernel_tap.c | 25 +-
>> .../net/virtio/virtio_user/vhost_kernel_tap.h | 1 +
>> drivers/net/virtio/virtio_user/vhost_user.c | 898 ++++++++++++++----
>> drivers/net/virtio/virtio_user/vhost_vdpa.c | 323 +++++--
>> .../net/virtio/virtio_user/virtio_user_dev.c | 573 ++++++-----
>> .../net/virtio/virtio_user/virtio_user_dev.h | 21 +-
>> drivers/net/virtio/virtio_user_ethdev.c | 301 +-----
>> drivers/net/virtio/virtqueue.c | 6 +-
>> drivers/net/virtio/virtqueue.h | 45 +-
>> 28 files changed, 2742 insertions(+), 1899 deletions(-)
>> create mode 100644 drivers/net/virtio/virtio.c
>> create mode 100644 drivers/net/virtio/virtio.h
>> create mode 100644 drivers/net/virtio/virtio_pci_ethdev.c
>>
>> --
>> 2.29.2
>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH] ci: ignore APT update failure in GitHub Actions
@ 2021-02-01 14:30 4% David Marchand
2021-02-01 14:41 0% ` Ilya Maximets
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2021-02-01 14:30 UTC (permalink / raw)
To: dev; +Cc: aconole, i.maximets, Michael Santana
Ubuntu 18.04 GHA virtual machine images point at an invalid APT
repository.
We have no control over this, simply ignore the failure.
This was caught by Ilya for OVS and the robot just hit the same issue
for DPDK:
"""
Get:46 http://security.ubuntu.com/ubuntu bionic-security/restricted
Translation-en [29.9 kB]
Get:47 http://security.ubuntu.com/ubuntu bionic-security/universe amd64
Packages [1104 kB]
Get:48 http://security.ubuntu.com/ubuntu bionic-security/universe
Translation-en [247 kB]
Reading package lists...
E: The repository 'https://apt.postgresql.org/pub/repos/apt bionic-pgdg
Release' no longer has a Release file.
Error: Process completed with exit code 100.
"""
Fixes: 9d620630ea30 ("ci: fix package installation in GitHub Actions")
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
.github/workflows/build.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
index a5b579adda..2fd1dde86f 100644
--- a/.github/workflows/build.yml
+++ b/.github/workflows/build.yml
@@ -88,7 +88,7 @@ jobs:
path: reference
key: ${{ steps.get_ref_keys.outputs.abi }}
- name: Update APT cache
- run: sudo apt update
+ run: sudo apt update || true
- name: Install packages
run: sudo apt install -y ccache libnuma-dev python3-setuptools
python3-wheel python3-pip python3-pyelftools ninja-build libbsd-dev
--
2.23.0
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] ci: ignore APT update failure in GitHub Actions
2021-02-01 14:30 4% [dpdk-dev] [PATCH] ci: ignore APT update failure in GitHub Actions David Marchand
@ 2021-02-01 14:41 0% ` Ilya Maximets
0 siblings, 0 replies; 200+ results
From: Ilya Maximets @ 2021-02-01 14:41 UTC (permalink / raw)
To: David Marchand, dev; +Cc: aconole, i.maximets, Michael Santana
On 2/1/21 3:30 PM, David Marchand wrote:
> Ubuntu 18.04 GHA virtual machine images point at an invalid APT
> repository.
> We have no control over this, simply ignore the failure.
>
> This was caught by Ilya for OVS and the robot just hit the same issue
> for DPDK:
>
> """
> Get:46 http://security.ubuntu.com/ubuntu bionic-security/restricted
> Translation-en [29.9 kB]
> Get:47 http://security.ubuntu.com/ubuntu bionic-security/universe amd64
> Packages [1104 kB]
> Get:48 http://security.ubuntu.com/ubuntu bionic-security/universe
> Translation-en [247 kB]
> Reading package lists...
> E: The repository 'https://apt.postgresql.org/pub/repos/apt bionic-pgdg
> Release' no longer has a Release file.
> Error: Process completed with exit code 100.
> """
>
> Fixes: 9d620630ea30 ("ci: fix package installation in GitHub Actions")
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
> .github/workflows/build.yml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
> index a5b579adda..2fd1dde86f 100644
> --- a/.github/workflows/build.yml
> +++ b/.github/workflows/build.yml
> @@ -88,7 +88,7 @@ jobs:
> path: reference
> key: ${{ steps.get_ref_keys.outputs.abi }}
> - name: Update APT cache
> - run: sudo apt update
> + run: sudo apt update || true
> - name: Install packages
> run: sudo apt install -y ccache libnuma-dev python3-setuptools
> python3-wheel python3-pip python3-pyelftools ninja-build libbsd-dev
>
LGTM,
Acked-by: Ilya Maximets <i.maximets@ovn.org>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH] devtools: remove ethdev ABI exception
@ 2021-02-01 18:08 9% David Marchand
2021-02-01 19:03 4% ` Ferruh Yigit
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: David Marchand @ 2021-02-01 18:08 UTC (permalink / raw)
To: dev
Cc: ferruh.yigit, dodji, Ray Kinsella, Neil Horman, Maxime Coquelin,
Bruce Richardson, Steven Webster, Thomas Monjalon
Now that the ethernet driver dev_ops structure definition is not
exported anymore, there is no need for an exception.
abidiff will only consider structures defined in the installed headers
(passed with --headers-dirX options).
Fixes: df96fd0d7395 ("ethdev: make driver-only headers private")
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
devtools/libabigail.abignore | 2 --
1 file changed, 2 deletions(-)
diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index ab5db240e7..6c0b38984e 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -13,8 +13,6 @@
name_regexp = _pmd_info$
; Explicit ignore for driver-only ABI
-[suppress_type]
- name = eth_dev_ops
[suppress_function]
name_regexp = rte_vdev_(|un)register
--
2.23.0
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] [PATCH] devtools: remove ethdev ABI exception
2021-02-01 18:08 9% [dpdk-dev] [PATCH] devtools: remove ethdev ABI exception David Marchand
@ 2021-02-01 19:03 4% ` Ferruh Yigit
2021-02-05 16:48 4% ` Thomas Monjalon
2021-02-01 20:39 4% ` Maxime Coquelin
2021-02-02 8:49 4% ` Kinsella, Ray
2 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2021-02-01 19:03 UTC (permalink / raw)
To: David Marchand, dev
Cc: dodji, Ray Kinsella, Neil Horman, Maxime Coquelin,
Bruce Richardson, Steven Webster, Thomas Monjalon
On 2/1/2021 6:08 PM, David Marchand wrote:
> Now that the ethernet driver dev_ops structure definition is not
> exported anymore, there is no need for an exception.
> abidiff will only consider structures defined in the installed headers
> (passed with --headers-dirX options).
>
> Fixes: df96fd0d7395 ("ethdev: make driver-only headers private")
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] devtools: remove ethdev ABI exception
2021-02-01 18:08 9% [dpdk-dev] [PATCH] devtools: remove ethdev ABI exception David Marchand
2021-02-01 19:03 4% ` Ferruh Yigit
@ 2021-02-01 20:39 4% ` Maxime Coquelin
2021-02-02 8:49 4% ` Kinsella, Ray
2 siblings, 0 replies; 200+ results
From: Maxime Coquelin @ 2021-02-01 20:39 UTC (permalink / raw)
To: David Marchand, dev
Cc: ferruh.yigit, dodji, Ray Kinsella, Neil Horman, Bruce Richardson,
Steven Webster, Thomas Monjalon
On 2/1/21 7:08 PM, David Marchand wrote:
> Now that the ethernet driver dev_ops structure definition is not
> exported anymore, there is no need for an exception.
> abidiff will only consider structures defined in the installed headers
> (passed with --headers-dirX options).
>
> Fixes: df96fd0d7395 ("ethdev: make driver-only headers private")
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
> devtools/libabigail.abignore | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
> index ab5db240e7..6c0b38984e 100644
> --- a/devtools/libabigail.abignore
> +++ b/devtools/libabigail.abignore
> @@ -13,8 +13,6 @@
> name_regexp = _pmd_info$
>
> ; Explicit ignore for driver-only ABI
> -[suppress_type]
> - name = eth_dev_ops
> [suppress_function]
> name_regexp = rte_vdev_(|un)register
>
>
Acked-by: Maxime Coquelin <maxime.coquelin@redhat.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] devtools: remove ethdev ABI exception
2021-02-01 18:08 9% [dpdk-dev] [PATCH] devtools: remove ethdev ABI exception David Marchand
2021-02-01 19:03 4% ` Ferruh Yigit
2021-02-01 20:39 4% ` Maxime Coquelin
@ 2021-02-02 8:49 4% ` Kinsella, Ray
2 siblings, 0 replies; 200+ results
From: Kinsella, Ray @ 2021-02-02 8:49 UTC (permalink / raw)
To: David Marchand, dev
Cc: ferruh.yigit, dodji, Neil Horman, Maxime Coquelin,
Bruce Richardson, Steven Webster, Thomas Monjalon
On 01/02/2021 18:08, David Marchand wrote:
> Now that the ethernet driver dev_ops structure definition is not
> exported anymore, there is no need for an exception.
> abidiff will only consider structures defined in the installed headers
> (passed with --headers-dirX options).
>
> Fixes: df96fd0d7395 ("ethdev: make driver-only headers private")
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
> devtools/libabigail.abignore | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
> index ab5db240e7..6c0b38984e 100644
> --- a/devtools/libabigail.abignore
> +++ b/devtools/libabigail.abignore
> @@ -13,8 +13,6 @@
> name_regexp = _pmd_info$
>
> ; Explicit ignore for driver-only ABI
> -[suppress_type]
> - name = eth_dev_ops
> [suppress_function]
> name_regexp = rte_vdev_(|un)register
>
eth_dev_ops structure are not exported, so there is no symbol that is actually
changing here. The type definition _only_ will be in DPDK 20.11 public headers,
but is removed in DPDK 21.02.
I find it a little strange that libabigail is baulking when the type is changed
(see 1fe3eef5e9b) but not when it is entirely removed?
Ray K
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH] devtools: fix examples external compilation for x86-default
@ 2021-02-02 10:54 10% David Marchand
2021-02-02 22:54 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2021-02-02 10:54 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson, Thomas Monjalon
Since we don't check ABI on the x86-default target anymore, installation
of the target must always happen for examples external compilation check
to work.
Fixes: 6a426d733ec0 ("devtools: reduce ABI checks and static binaries")
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
devtools/test-meson-builds.sh | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index a99a177e0c..c11ae87e0d 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -276,10 +276,7 @@ done
load_env cc
build_path=$(readlink -f $builds_dir/build-x86-default)
export DESTDIR=$build_path/install
-# No need to reinstall if ABI checks are enabled
-if [ -z "$DPDK_ABI_REF_VERSION" ]; then
- install_target $build_path $DESTDIR
-fi
+install_target $build_path $DESTDIR
pc_file=$(find $DESTDIR -name libdpdk.pc)
export PKG_CONFIG_PATH=$(dirname $pc_file):$PKG_CONFIG_PATH
libdir=$(dirname $(find $DESTDIR -name librte_eal.so))
--
2.23.0
^ permalink raw reply [relevance 10%]
* Re: [dpdk-dev] [PATCH] devtools: fix examples external compilation for x86-default
2021-02-02 10:54 10% [dpdk-dev] [PATCH] devtools: fix examples external compilation for x86-default David Marchand
@ 2021-02-02 22:54 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2021-02-02 22:54 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Bruce Richardson
02/02/2021 11:54, David Marchand:
> Since we don't check ABI on the x86-default target anymore, installation
> of the target must always happen for examples external compilation check
> to work.
Otherwise the error is:
find: ‘build-x86-default/install’: No such file or directory
>
> Fixes: 6a426d733ec0 ("devtools: reduce ABI checks and static binaries")
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
Applied, thanks
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH] devtools: select targets in build test
@ 2021-02-04 13:34 5% David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2021-02-04 13:34 UTC (permalink / raw)
To: dev; +Cc: thomas, Bruce Richardson
When a target compilation is broken, one way to skip the target is to
uninstall the associated toolchain.
But it is not always possible and you end up with hacking the script to
avoid this target until a fix is ready.
It is also often quicker to check a fix on a failing target before
checking compilation on all targets.
Introduce a variable to select targets.
Example:
$ DPDK_BUILD_TEST_TARGETS=build-x86-mingw \
./devtools/test-meson-builds.sh
ninja: Entering directory `/home/dmarchan/builds/build-x86-mingw'
[...]
Found ninja-1.10.1 at /usr/bin/ninja
[19/19] Linking target examples/dpdk-helloworld.exe
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
devtools/test-meson-builds.sh | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index c11ae87e0d..3e88e8291e 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -92,6 +92,15 @@ load_env () # <target compiler>
command -v $targetcc >/dev/null 2>&1 || return 1
}
+target_is_selected()
+{
+ if [ -z "${DPDK_BUILD_TEST_TARGETS:-}" ]; then
+ return 0
+ fi
+ target_filter=" $DPDK_BUILD_TEST_TARGETS "
+ ! [ "${target_filter##* $1 }" = "${target_filter}" ]
+}
+
config () # <dir> <builddir> <meson options>
{
dir=$1
@@ -149,6 +158,7 @@ install_target () # <builddir> <installdir>
build () # <directory> <target cc | cross file> <ABI check> [meson options]
{
targetdir=$1
+ target_is_selected $targetdir || return 0
shift
crossfile=
[ -r $1 ] && crossfile=$1 || targetcc=$1
@@ -271,6 +281,8 @@ for f in $srcdir/config/ppc/ppc* ; do
build $targetdir $f ABI $use_shared
done
+target_is_selected build-x86-default || exit 0
+
# Test installation of the x86-default target, to be used for checking
# the sample apps build using the pkg-config file for cflags and libs
load_env cc
--
2.23.0
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH v5 0/9] ethdev: support SubFunction representor
@ 2021-02-04 14:15 3% ` Xueming(Steven) Li
2021-02-05 7:34 0% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Xueming(Steven) Li @ 2021-02-04 14:15 UTC (permalink / raw)
To: Andrew Rybchenko; +Cc: dev, Slava Ovsiienko, Asaf Penso, Thomas Monjalon
>-----Original Message-----
>From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>Sent: Monday, February 1, 2021 4:39 PM
>To: Xueming(Steven) Li <xuemingl@nvidia.com>
>Cc: dev@dpdk.org; Slava Ovsiienko <viacheslavo@nvidia.com>; Asaf Penso <asafp@nvidia.com>
>Subject: Re: [dpdk-dev] [PATCH v5 0/9] ethdev: support SubFunction representor
>
>On 1/28/21 5:31 PM, Xueming(Steven) Li wrote:
>> <snip>
>>>> The patch of device SF capability, but seems I misunderstood your suggestion.
>>>> Let me explain process to create a SF:
>>>> 1. SF can be created on the fly with scripts, unlike VF which is statically pre-created.
>>>
>>> Is there a maximum index and maximum total number of SF's created? How to find it?
>>
>> The maximum index is defined by firmware configuration, all SF's
>> information could be found from sysfs. To create a SF, both PCI and sfnum have to be specified.
>
>sysfs is obviously Linux specific. I think the information should be available via DPDK API.
Yes, the new api discussed below should resolve this issue.
>
>>>
>>>> 2. SF is created on a PF with a SF number. SF number is named per PF, different PF may have same SF number.
>>>> 3. For standalone PF, hot plug to DPDK using "PF#_BDF,representor=sf#", no need to use pf#sf# here.
>>>> 4. For bonding netdev, hot plug to DPDK using "PF0_BDF,representor=pf#sf#"
>>>> If using new api to return all representor IDs, need some way locate
>>>> the new created SF by PF and SF number, that's why "pf#sf#" is used in this patch set.
>>>
>>> I think the API should simply reserve/report space for maximum number
>>> of SFs. So, IDs are stable across restart/reboot in assumption that NIC is not reconfigured (changed maximum number of VF or
>maximum number of SFs of any PF).
>>
>> Yes, IDs should be stable as long as no NIC firmware configuration change.
>>
>> Just clarify, this api should be common enough to report all devices that a bus device supports:
>> 1. name, might contains controller and pf info, example: "eth:representor:c0pf1vf"
>> 2. ID range, example: 0-127
>> The api describes ID ranges for each sub device type, users have to query the api and choose representor ID to probe.
>>
>> Prototype:
>> struct rte_bus_device_range {
>> char name[64];
>> uint32_t base;
>> uint32_t number;
>> }
>> /* return number of ranges filled, or number of ranges if list is
>> NULL. */ int rte_bus_ dev_range_get(struct rte_bus_device_range *list,
>> int n);
>
>Hm, I thought about more port representor specific API.
>For me it is hard to tell if such generic naming is good or bad. I think it should be proven that such generic API makes sense. Any other
>potential users / use cases?
I was thinking about SF, but SF is PCI specific, not suitable for this api. So I'm fine to make it as ethdev api.
To append new api into eth_dev_ops, is there ABI concern?
>
>I've considered ethdev API which returns (in similar way as
>above) list of possible port representors which could be controlled by the device. Also I think it would be useful to include type
>information (enum with PF, VF, SF), controller ID.
Agree.
There is a new concern from orchestration side, currently, no interface in openstack and OVS to retrieve representor ID range info,
It will take time to adapt this solution. To probe a representor, orchestration need to know how to calculate representor ID,
and the ID might vary on different max SF number, i.e. VF4 on PP1 might got different ID. Representor ID change before that will
break the product.
Considering both orchestration and testpmd users, how about keeping both solution together? This will bring max flexibility IMHO.
In struct rte_eth_dev_data, reserved bits could be used to define controller and port, this will avoid bitmap. How do you think?
>
>There is one more bit which is not in the picture yet - switch_info.port_id. Should it be equal to representor ID? Or different and
>provided in the info structure?
Not exactly same AFAIK, the id used in e-switch.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 0/9] ethdev: support SubFunction representor
2021-02-04 14:15 3% ` Xueming(Steven) Li
@ 2021-02-05 7:34 0% ` Andrew Rybchenko
2021-02-05 9:13 3% ` Xueming(Steven) Li
0 siblings, 1 reply; 200+ results
From: Andrew Rybchenko @ 2021-02-05 7:34 UTC (permalink / raw)
To: Xueming(Steven) Li; +Cc: dev, Slava Ovsiienko, Asaf Penso, Thomas Monjalon
On 2/4/21 5:15 PM, Xueming(Steven) Li wrote:
>
>> -----Original Message-----
>> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>> Sent: Monday, February 1, 2021 4:39 PM
>> To: Xueming(Steven) Li <xuemingl@nvidia.com>
>> Cc: dev@dpdk.org; Slava Ovsiienko <viacheslavo@nvidia.com>; Asaf Penso <asafp@nvidia.com>
>> Subject: Re: [dpdk-dev] [PATCH v5 0/9] ethdev: support SubFunction representor
>>
>> On 1/28/21 5:31 PM, Xueming(Steven) Li wrote:
>>> <snip>
>>>>> The patch of device SF capability, but seems I misunderstood your suggestion.
>>>>> Let me explain process to create a SF:
>>>>> 1. SF can be created on the fly with scripts, unlike VF which is statically pre-created.
>>>>
>>>> Is there a maximum index and maximum total number of SF's created? How to find it?
>>>
>>> The maximum index is defined by firmware configuration, all SF's
>>> information could be found from sysfs. To create a SF, both PCI and sfnum have to be specified.
>>
>> sysfs is obviously Linux specific. I think the information should be available via DPDK API.
>
> Yes, the new api discussed below should resolve this issue.
>
>>
>>>>
>>>>> 2. SF is created on a PF with a SF number. SF number is named per PF, different PF may have same SF number.
>>>>> 3. For standalone PF, hot plug to DPDK using "PF#_BDF,representor=sf#", no need to use pf#sf# here.
>>>>> 4. For bonding netdev, hot plug to DPDK using "PF0_BDF,representor=pf#sf#"
>>>>> If using new api to return all representor IDs, need some way locate
>>>>> the new created SF by PF and SF number, that's why "pf#sf#" is used in this patch set.
>>>>
>>>> I think the API should simply reserve/report space for maximum number
>>>> of SFs. So, IDs are stable across restart/reboot in assumption that NIC is not reconfigured (changed maximum number of VF or
>> maximum number of SFs of any PF).
>>>
>>> Yes, IDs should be stable as long as no NIC firmware configuration change.
>>>
>>> Just clarify, this api should be common enough to report all devices that a bus device supports:
>>> 1. name, might contains controller and pf info, example: "eth:representor:c0pf1vf"
>>> 2. ID range, example: 0-127
>>> The api describes ID ranges for each sub device type, users have to query the api and choose representor ID to probe.
>>>
>>> Prototype:
>>> struct rte_bus_device_range {
>>> char name[64];
>>> uint32_t base;
>>> uint32_t number;
>>> }
>>> /* return number of ranges filled, or number of ranges if list is
>>> NULL. */ int rte_bus_ dev_range_get(struct rte_bus_device_range *list,
>>> int n);
>>
>> Hm, I thought about more port representor specific API.
>> For me it is hard to tell if such generic naming is good or bad. I think it should be proven that such generic API makes sense. Any other
>> potential users / use cases?
>
> I was thinking about SF, but SF is PCI specific, not suitable for this api. So I'm fine to make it as ethdev api.
> To append new api into eth_dev_ops, is there ABI concern?
No, eth_dev_ops are internal
>> I've considered ethdev API which returns (in similar way as
>> above) list of possible port representors which could be controlled by the device. Also I think it would be useful to include type
>> information (enum with PF, VF, SF), controller ID.
>
> Agree.
>
> There is a new concern from orchestration side, currently, no interface in openstack and OVS to retrieve representor ID range info,
> It will take time to adapt this solution. To probe a representor, orchestration need to know how to calculate representor ID,
> and the ID might vary on different max SF number, i.e. VF4 on PP1 might got different ID. Representor ID change before that will
> break the product.
I see.
> Considering both orchestration and testpmd users, how about keeping both solution together? This will bring max flexibility IMHO.
As I said before I don't mind and I really think it is a good
idea to add suggested interface to specify representor
(i.e. cXpfYvfZ), but the problem is making bitmap from
representor ID.
ethdev API should use new representor info API to
make a representor ID from controller/PF/{VF,SF}.
Or do you see any problems with such approach?
> In struct rte_eth_dev_data, reserved bits could be used to define controller and port, this will avoid bitmap. How do you think?
Could you add a bit more on it? Just a bit more details to
the idea since I don't understand what exactly you mean and
how it could help.
>>
>> There is one more bit which is not in the picture yet - switch_info.port_id. Should it be equal to representor ID? Or different and
>> provided in the info structure?
>
> Not exactly same AFAIK, the id used in e-switch.
>
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 0/9] ethdev: support SubFunction representor
2021-02-05 7:34 0% ` Andrew Rybchenko
@ 2021-02-05 9:13 3% ` Xueming(Steven) Li
2021-02-05 9:37 0% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Xueming(Steven) Li @ 2021-02-05 9:13 UTC (permalink / raw)
To: Andrew Rybchenko; +Cc: dev, Slava Ovsiienko, Asaf Penso, Thomas Monjalon
>-----Original Message-----
>From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>Sent: Friday, February 5, 2021 3:35 PM
>To: Xueming(Steven) Li <xuemingl@nvidia.com>
>Cc: dev@dpdk.org; Slava Ovsiienko <viacheslavo@nvidia.com>; Asaf Penso <asafp@nvidia.com>; Thomas Monjalon
><tmonjalon@nvidia.com>
>Subject: Re: [dpdk-dev] [PATCH v5 0/9] ethdev: support SubFunction representor
>
>On 2/4/21 5:15 PM, Xueming(Steven) Li wrote:
>>
>>> -----Original Message-----
>>> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>>> Sent: Monday, February 1, 2021 4:39 PM
>>> To: Xueming(Steven) Li <xuemingl@nvidia.com>
>>> Cc: dev@dpdk.org; Slava Ovsiienko <viacheslavo@nvidia.com>; Asaf
>>> Penso <asafp@nvidia.com>
>>> Subject: Re: [dpdk-dev] [PATCH v5 0/9] ethdev: support SubFunction
>>> representor
>>>
>>> On 1/28/21 5:31 PM, Xueming(Steven) Li wrote:
>>>> <snip>
>>>>>> The patch of device SF capability, but seems I misunderstood your suggestion.
>>>>>> Let me explain process to create a SF:
>>>>>> 1. SF can be created on the fly with scripts, unlike VF which is statically pre-created.
>>>>>
>>>>> Is there a maximum index and maximum total number of SF's created? How to find it?
>>>>
>>>> The maximum index is defined by firmware configuration, all SF's
>>>> information could be found from sysfs. To create a SF, both PCI and sfnum have to be specified.
>>>
>>> sysfs is obviously Linux specific. I think the information should be available via DPDK API.
>>
>> Yes, the new api discussed below should resolve this issue.
>>
>>>
>>>>>
>>>>>> 2. SF is created on a PF with a SF number. SF number is named per PF, different PF may have same SF number.
>>>>>> 3. For standalone PF, hot plug to DPDK using "PF#_BDF,representor=sf#", no need to use pf#sf# here.
>>>>>> 4. For bonding netdev, hot plug to DPDK using "PF0_BDF,representor=pf#sf#"
>>>>>> If using new api to return all representor IDs, need some way
>>>>>> locate the new created SF by PF and SF number, that's why "pf#sf#" is used in this patch set.
>>>>>
>>>>> I think the API should simply reserve/report space for maximum
>>>>> number of SFs. So, IDs are stable across restart/reboot in
>>>>> assumption that NIC is not reconfigured (changed maximum number of
>>>>> VF or
>>> maximum number of SFs of any PF).
>>>>
>>>> Yes, IDs should be stable as long as no NIC firmware configuration change.
>>>>
>>>> Just clarify, this api should be common enough to report all devices that a bus device supports:
>>>> 1. name, might contains controller and pf info, example: "eth:representor:c0pf1vf"
>>>> 2. ID range, example: 0-127
>>>> The api describes ID ranges for each sub device type, users have to query the api and choose representor ID to probe.
>>>>
>>>> Prototype:
>>>> struct rte_bus_device_range {
>>>> char name[64];
>>>> uint32_t base;
>>>> uint32_t number;
>>>> }
>>>> /* return number of ranges filled, or number of ranges if list is
>>>> NULL. */ int rte_bus_ dev_range_get(struct rte_bus_device_range
>>>> *list, int n);
>>>
>>> Hm, I thought about more port representor specific API.
>>> For me it is hard to tell if such generic naming is good or bad. I
>>> think it should be proven that such generic API makes sense. Any other potential users / use cases?
>>
>> I was thinking about SF, but SF is PCI specific, not suitable for this api. So I'm fine to make it as ethdev api.
>> To append new api into eth_dev_ops, is there ABI concern?
>
>No, eth_dev_ops are internal
>
>>> I've considered ethdev API which returns (in similar way as
>>> above) list of possible port representors which could be controlled
>>> by the device. Also I think it would be useful to include type information (enum with PF, VF, SF), controller ID.
>>
>> Agree.
>>
>> There is a new concern from orchestration side, currently, no
>> interface in openstack and OVS to retrieve representor ID range info,
>> It will take time to adapt this solution. To probe a representor,
>> orchestration need to know how to calculate representor ID, and the ID might vary on different max SF number, i.e. VF4 on PP1
>might got different ID. Representor ID change before that will break the product.
>
>I see.
>
>> Considering both orchestration and testpmd users, how about keeping both solution together? This will bring max flexibility IMHO.
>
>As I said before I don't mind and I really think it is a good idea to add suggested interface to specify representor (i.e. cXpfYvfZ), but the
>problem is making bitmap from representor ID.
>
>ethdev API should use new representor info API to make a representor ID from controller/PF/{VF,SF}.
>Or do you see any problems with such approach?
Sorry I thought the user to figure out representor ID from api.
This combination look good, thanks for clarification :)
So the new api looks like this:
struct rte_eth_representor_info {
Enum representor_type;
Uint16_t controller; // -1 for any
Uint16_t port; // -1 for any
Uint16_t representor_id;
Uint16_t count;
char name[N];
int rte_eth_representor_info_get(struct rte_eth_representor_info *infos);
- Return number of entries.
- NULL infos just return number of entries supported.
Sample outputs:
VF, -1, 0, 0, 128, "pf0vf"
SF, -1, 0, 128, 2048, "pf0sf"
PF, -1, 0, 32767, 1, "pf"
VF, -1, 1, 32768, 128, "pf1vf"
SF, -1, 0, (32768+128), 2048, "pf1sf"
PF, -1, 0, 65535, 1, "pf"
>
>> In struct rte_eth_dev_data, reserved bits could be used to define controller and port, this will avoid bitmap. How do you think?
>
>Could you add a bit more on it? Just a bit more details to the idea since I don't understand what exactly you mean and how it could
>help.
The idea is replacing reserved_64s and adding more device location info in rte_eth-dev_data like this:
Uint16_t representor_id;
Uint16_t port_id;
Uint16_t controller_id;
Enum representor_type;
Compare them all when matching a device, this will also avoid bitmap encoding.
Reserved_64s[] was added to mitigate ABI conflicts, IIRC.
But seems no need if making representor info API to make ID.
>
>>>
>>> There is one more bit which is not in the picture yet -
>>> switch_info.port_id. Should it be equal to representor ID? Or different and provided in the info structure?
>>
>> Not exactly same AFAIK, the id used in e-switch.
>>
>>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 0/9] ethdev: support SubFunction representor
2021-02-05 9:13 3% ` Xueming(Steven) Li
@ 2021-02-05 9:37 0% ` Andrew Rybchenko
0 siblings, 0 replies; 200+ results
From: Andrew Rybchenko @ 2021-02-05 9:37 UTC (permalink / raw)
To: Xueming(Steven) Li; +Cc: dev, Slava Ovsiienko, Asaf Penso, Thomas Monjalon
On 2/5/21 12:13 PM, Xueming(Steven) Li wrote:
>
>> -----Original Message-----
>> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>> Sent: Friday, February 5, 2021 3:35 PM
>> To: Xueming(Steven) Li <xuemingl@nvidia.com>
>> Cc: dev@dpdk.org; Slava Ovsiienko <viacheslavo@nvidia.com>; Asaf Penso <asafp@nvidia.com>; Thomas Monjalon
>> <tmonjalon@nvidia.com>
>> Subject: Re: [dpdk-dev] [PATCH v5 0/9] ethdev: support SubFunction representor
>>
>> On 2/4/21 5:15 PM, Xueming(Steven) Li wrote:
>>>
>>>> -----Original Message-----
>>>> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>>>> Sent: Monday, February 1, 2021 4:39 PM
>>>> To: Xueming(Steven) Li <xuemingl@nvidia.com>
>>>> Cc: dev@dpdk.org; Slava Ovsiienko <viacheslavo@nvidia.com>; Asaf
>>>> Penso <asafp@nvidia.com>
>>>> Subject: Re: [dpdk-dev] [PATCH v5 0/9] ethdev: support SubFunction
>>>> representor
>>>>
>>>> On 1/28/21 5:31 PM, Xueming(Steven) Li wrote:
>>>>> <snip>
>>>>>>> The patch of device SF capability, but seems I misunderstood your suggestion.
>>>>>>> Let me explain process to create a SF:
>>>>>>> 1. SF can be created on the fly with scripts, unlike VF which is statically pre-created.
>>>>>>
>>>>>> Is there a maximum index and maximum total number of SF's created? How to find it?
>>>>>
>>>>> The maximum index is defined by firmware configuration, all SF's
>>>>> information could be found from sysfs. To create a SF, both PCI and sfnum have to be specified.
>>>>
>>>> sysfs is obviously Linux specific. I think the information should be available via DPDK API.
>>>
>>> Yes, the new api discussed below should resolve this issue.
>>>
>>>>
>>>>>>
>>>>>>> 2. SF is created on a PF with a SF number. SF number is named per PF, different PF may have same SF number.
>>>>>>> 3. For standalone PF, hot plug to DPDK using "PF#_BDF,representor=sf#", no need to use pf#sf# here.
>>>>>>> 4. For bonding netdev, hot plug to DPDK using "PF0_BDF,representor=pf#sf#"
>>>>>>> If using new api to return all representor IDs, need some way
>>>>>>> locate the new created SF by PF and SF number, that's why "pf#sf#" is used in this patch set.
>>>>>>
>>>>>> I think the API should simply reserve/report space for maximum
>>>>>> number of SFs. So, IDs are stable across restart/reboot in
>>>>>> assumption that NIC is not reconfigured (changed maximum number of
>>>>>> VF or
>>>> maximum number of SFs of any PF).
>>>>>
>>>>> Yes, IDs should be stable as long as no NIC firmware configuration change.
>>>>>
>>>>> Just clarify, this api should be common enough to report all devices that a bus device supports:
>>>>> 1. name, might contains controller and pf info, example: "eth:representor:c0pf1vf"
>>>>> 2. ID range, example: 0-127
>>>>> The api describes ID ranges for each sub device type, users have to query the api and choose representor ID to probe.
>>>>>
>>>>> Prototype:
>>>>> struct rte_bus_device_range {
>>>>> char name[64];
>>>>> uint32_t base;
>>>>> uint32_t number;
>>>>> }
>>>>> /* return number of ranges filled, or number of ranges if list is
>>>>> NULL. */ int rte_bus_ dev_range_get(struct rte_bus_device_range
>>>>> *list, int n);
>>>>
>>>> Hm, I thought about more port representor specific API.
>>>> For me it is hard to tell if such generic naming is good or bad. I
>>>> think it should be proven that such generic API makes sense. Any other potential users / use cases?
>>>
>>> I was thinking about SF, but SF is PCI specific, not suitable for this api. So I'm fine to make it as ethdev api.
>>> To append new api into eth_dev_ops, is there ABI concern?
>>
>> No, eth_dev_ops are internal
>>
>>>> I've considered ethdev API which returns (in similar way as
>>>> above) list of possible port representors which could be controlled
>>>> by the device. Also I think it would be useful to include type information (enum with PF, VF, SF), controller ID.
>>>
>>> Agree.
>>>
>>> There is a new concern from orchestration side, currently, no
>>> interface in openstack and OVS to retrieve representor ID range info,
>>> It will take time to adapt this solution. To probe a representor,
>>> orchestration need to know how to calculate representor ID, and the ID might vary on different max SF number, i.e. VF4 on PP1
>> might got different ID. Representor ID change before that will break the product.
>>
>> I see.
>>
>>> Considering both orchestration and testpmd users, how about keeping both solution together? This will bring max flexibility IMHO.
>>
>> As I said before I don't mind and I really think it is a good idea to add suggested interface to specify representor (i.e. cXpfYvfZ), but the
>> problem is making bitmap from representor ID.
>>
>> ethdev API should use new representor info API to make a representor ID from controller/PF/{VF,SF}.
>> Or do you see any problems with such approach?
>
> Sorry I thought the user to figure out representor ID from api.
> This combination look good, thanks for clarification :)
>
> So the new api looks like this:
Roughly speaking - yes
> struct rte_eth_representor_info {
> Enum representor_type;
> Uint16_t controller; // -1 for any
I'm not sure that I understand what does "any" mean in this
case. I think it should be the zero in examples below.
I think that API should return caller controller ID and
PF ID. It would allow to interpret "vf5" correctly when
caller is not controller #0 and/or PF #0.
> Uint16_t port; // -1 for any
port sounds like physical port, but it should be PF
(pf, phys_fn or something like this). It could be many
PFs per physical network port.
> Uint16_t representor_id;
May be base_id? Or rep_base_id?
The question is what to do if range for VF or SF is
not contiguous. Should we have one more index after phys_fn
to represent it? E.g.
union {
uint16_t vf;
uint16_t sf;
};
> Uint16_t count;
May be id_range which should be 1 to show one function.
It could be convenient to treat 0 this way as well,
but I doubt that it is a good idea.
> char name[N];
>
> int rte_eth_representor_info_get(struct rte_eth_representor_info *infos);
> - Return number of entries.
> - NULL infos just return number of entries supported.
> Sample outputs:
> VF, -1, 0, 0, 128, "pf0vf"
> SF, -1, 0, 128, 2048, "pf0sf"
> PF, -1, 0, 32767, 1, "pf"
> VF, -1, 1, 32768, 128, "pf1vf"
> SF, -1, 0, (32768+128), 2048, "pf1sf"
> PF, -1, 0, 65535, 1, "pf"
>
>>
>>> In struct rte_eth_dev_data, reserved bits could be used to define controller and port, this will avoid bitmap. How do you think?
>>
>> Could you add a bit more on it? Just a bit more details to the idea since I don't understand what exactly you mean and how it could
>> help.
>
> The idea is replacing reserved_64s and adding more device location info in rte_eth-dev_data like this:
> Uint16_t representor_id;
> Uint16_t port_id;
> Uint16_t controller_id;
> Enum representor_type;
> Compare them all when matching a device, this will also avoid bitmap encoding.
> Reserved_64s[] was added to mitigate ABI conflicts, IIRC.
> But seems no need if making representor info API to make ID.
>
>>
>>>>
>>>> There is one more bit which is not in the picture yet -
>>>> switch_info.port_id. Should it be equal to representor ID? Or different and provided in the info structure?
>>>
>>> Not exactly same AFAIK, the id used in e-switch.
>>>
>>>
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC PATCH v4] build: kni cross-compilation support
@ 2021-02-05 15:27 3% ` Bruce Richardson
2021-02-08 10:17 0% ` Juraj Linkeš
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2021-02-05 15:27 UTC (permalink / raw)
To: Juraj Linkeš
Cc: thomas, Ruifeng.Wang, Honnappa.Nagarahalli, jerinjacobk,
hemant.agrawal, ferruh.yigit, aboyer, dev, david.marchand, bluca
On Fri, Feb 05, 2021 at 04:04:32PM +0100, Juraj Linkeš wrote:
> The kni linux module is using a custom target for building, which
> doesn't take into account any cross compilation arguments. The arguments
> in question are ARCH, CROSS_COMPILE (for gcc, clang) and CC, LD (for
> clang). Get those from the cross file and pass them to the custom
> target.
>
> The user supplied path may not contain the 'build' directory, such as
> when using cross-compiled headers, so only append that in the default
> case (when no path is supplied in native builds) and use the unmodified
> path from the user otherwise. Also modify the install path accordingly.
>
> Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
> ---
Thanks, this all looks ok to me now, bar one very minor nit below. Doing a
native build on my system with the running kernel also works fine.
However, the bigger question is one of compatibility for this change. The
current documentation for the kernel_dir option is:
option('kernel_dir', type: 'string', value: '',
description: 'Path to the kernel for building kernel modules. \
Headers must be in $kernel_dir/build. Modules will be installed \
in $DEST_DIR/$kernel_dir/extra/dpdk.')
Obviously the description now needs an update to reflect the new use, but
I'm not sure if changing the behaviour counts as an "ABI" change or not,
and whether it needs to wait for a new LTS release. Any scripts that were
compiling using e.g. kernel_dir='/lib/modules/<version>' need to be changed
to use kernel_dir='/lib/modules/<version>/build' instead.
/Bruce
> kernel/linux/kni/meson.build | 8 ++--
> kernel/linux/meson.build | 80 ++++++++++++++++++++++++++++++------
> 2 files changed, 71 insertions(+), 17 deletions(-)
>
> diff --git a/kernel/linux/kni/meson.build b/kernel/linux/kni/meson.build
> index 07e0c9dae7..46b71c7418 100644
> --- a/kernel/linux/kni/meson.build
> +++ b/kernel/linux/kni/meson.build
> @@ -13,7 +13,7 @@ kni_sources = files(
> custom_target('rte_kni',
> input: kni_sources,
> output: 'rte_kni.ko',
> - command: ['make', '-j4', '-C', kernel_dir + '/build',
> + command: ['make', '-j4', '-C', kernel_build_dir,
> 'M=' + meson.current_build_dir(),
> 'src=' + meson.current_source_dir(),
> 'MODULE_CFLAGS=-include ' + meson.source_root() + '/config/rte_config.h' +
> @@ -21,8 +21,8 @@ custom_target('rte_kni',
> ' -I' + meson.source_root() + '/lib/librte_kni' +
> ' -I' + meson.build_root() +
> ' -I' + meson.current_source_dir(),
> - 'modules'],
> + 'modules'] + cross_args,
> depends: kni_mkfile,
> - install: true,
> - install_dir: kernel_dir + '/extra/dpdk',
> + install: install,
> + install_dir: kernel_install_dir,
> build_by_default: get_option('enable_kmods'))
> diff --git a/kernel/linux/meson.build b/kernel/linux/meson.build
> index 5c864a4653..7acb52944f 100644
> --- a/kernel/linux/meson.build
> +++ b/kernel/linux/meson.build
> @@ -3,25 +3,79 @@
>
> subdirs = ['kni']
>
> -# if we are cross-compiling we need kernel_dir specified
> -if get_option('kernel_dir') == '' and meson.is_cross_build()
> - error('Need "kernel_dir" option for kmod compilation when cross-compiling')
> -endif
> +kernel_build_dir = get_option('kernel_dir')
> +install = not meson.is_cross_build()
> +cross_args = []
> +kernel_install_dir = ''
Minor nit, I'd have kernel_install_dir immediately after kernel_build_dir
in the list above.
>
> -kernel_dir = get_option('kernel_dir')
> -if kernel_dir == ''
> - # use default path for native builds
> +if not meson.is_cross_build()
> + # native build
> kernel_version = run_command('uname', '-r').stdout().strip()
> - kernel_dir = '/lib/modules/' + kernel_version
> + kernel_install_dir = '/lib/modules/' + kernel_version + '/extra/dpdk'
> + if kernel_build_dir == ''
> + # use default path for native builds
> + kernel_build_dir = '/lib/modules/' + kernel_version + '/build'
> + endif
> +
> + # test running make in kernel directory, using "make kernelversion"
> + make_returncode = run_command('make', '-sC', kernel_build_dir,
> + 'kernelversion').returncode()
> + if make_returncode != 0
> + error('Cannot compile kernel modules as requested - are kernel headers installed?')
> + endif
> +
> + # DO ACTUAL MODULE BUILDING
> + foreach d:subdirs
> + subdir(d)
> + endforeach
> +
> + subdir_done()
> endif
>
> -# test running make in kernel directory, using "make kernelversion"
> -make_returncode = run_command('make', '-sC', kernel_dir + '/build',
> - 'kernelversion').returncode()
> -if make_returncode != 0
> - error('Cannot compile kernel modules as requested - are kernel headers installed?')
> +# cross build
> +# if we are cross-compiling we need kernel_build_dir specified
> +if kernel_build_dir == ''
> + error('Need "kernel_dir" option for kmod compilation when cross-compiling')
> +endif
> +cross_compiler = find_program('c').path()
> +if cross_compiler.endswith('gcc')
> + cross_prefix = run_command([py3, '-c', 'print("' + cross_compiler + '"[:-3])']).stdout().strip()
> +elif cross_compiler.endswith('clang')
> + cross_prefix = ''
> + found_target = false
> + # search for '-target' and use the arg that follows
> + # (i.e. the value of '-target') as cross_prefix
> + foreach cross_c_arg : meson.get_cross_property('c_args')
> + if found_target and cross_prefix == ''
> + cross_prefix = cross_c_arg
> + endif
> + if cross_c_arg == '-target'
> + found_target = true
> + endif
> + endforeach
> + if cross_prefix == ''
> + error('Didn\'t find -target and its value in' +
> + ' c_args in input cross-file.')
> + endif
> + linker = 'lld'
> + foreach cross_c_link_arg : meson.get_cross_property('c_link_args')
> + if cross_c_link_arg.startswith('-fuse-ld')
> + linker = cross_c_link_arg.split('=')[1]
> + endif
> + endforeach
> + cross_args += ['CC=@0@'.format(cross_compiler), 'LD=ld.@0@'.format(linker)]
> +else
> + error('Unsupported cross compiler: @0@'.format(cross_compiler))
> endif
>
> +cross_arch = host_machine.cpu_family()
> +if host_machine.cpu_family() == 'aarch64'
> + cross_arch = 'arm64'
> +endif
> +
> +cross_args += ['ARCH=@0@'.format(cross_arch),
> + 'CROSS_COMPILE=@0@'.format(cross_prefix)]
> +
> # DO ACTUAL MODULE BUILDING
> foreach d:subdirs
> subdir(d)
> --
> 2.20.1
>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] devtools: remove ethdev ABI exception
2021-02-01 19:03 4% ` Ferruh Yigit
@ 2021-02-05 16:48 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2021-02-05 16:48 UTC (permalink / raw)
To: David Marchand
Cc: dev, dodji, Ray Kinsella, Neil Horman, Maxime Coquelin,
Bruce Richardson, Steven Webster, Ferruh Yigit
01/02/2021 20:03, Ferruh Yigit:
> On 2/1/2021 6:08 PM, David Marchand wrote:
> > Now that the ethernet driver dev_ops structure definition is not
> > exported anymore, there is no need for an exception.
> > abidiff will only consider structures defined in the installed headers
> > (passed with --headers-dirX options).
> >
> > Fixes: df96fd0d7395 ("ethdev: make driver-only headers private")
> >
> > Signed-off-by: David Marchand <david.marchand@redhat.com>
>
> Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
Applied, thanks
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH] telemetry: mark init function as internal-only
@ 2021-02-05 21:23 10% Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2021-02-05 21:23 UTC (permalink / raw)
To: dev; +Cc: thomas, Bruce Richardson, stable
The "rte_telemetry_init()" function is for use by "rte_eal_init()" and
should not be part of the public API. Mark it as internal only.
Fixes: 6dd571fd07c3 ("telemetry: introduce new functionality")
Cc: stable@dpdk.org
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
doc/guides/rel_notes/release_21_02.rst | 5 +++++
lib/librte_telemetry/rte_telemetry.h | 2 +-
lib/librte_telemetry/version.map | 5 ++++-
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/doc/guides/rel_notes/release_21_02.rst b/doc/guides/rel_notes/release_21_02.rst
index baf32151f..84b04a018 100644
--- a/doc/guides/rel_notes/release_21_02.rst
+++ b/doc/guides/rel_notes/release_21_02.rst
@@ -266,6 +266,11 @@ ABI Changes
* No ABI change that would break compatibility with 20.11.
+* The experimental function ``rte_telemetry_init`` has been removed from the
+ public API and is now an internal-only function. Where telemetry library is
+ available, it is called automatically from ``rte_eal_init()`` and so no end
+ application need use it.
+
Known Issues
------------
diff --git a/lib/librte_telemetry/rte_telemetry.h b/lib/librte_telemetry/rte_telemetry.h
index f6c3992a9..f7c8534b8 100644
--- a/lib/librte_telemetry/rte_telemetry.h
+++ b/lib/librte_telemetry/rte_telemetry.h
@@ -309,7 +309,7 @@ rte_telemetry_register_cmd(const char *cmd, telemetry_cb fn, const char *help);
* @return
* -1 on failure.
*/
-__rte_experimental
+__rte_internal
int
rte_telemetry_init(const char *runtime_dir, const char *rte_version, rte_cpuset_t *cpuset,
const char **err_str);
diff --git a/lib/librte_telemetry/version.map b/lib/librte_telemetry/version.map
index d1dbf8d58..ec0ebc1be 100644
--- a/lib/librte_telemetry/version.map
+++ b/lib/librte_telemetry/version.map
@@ -14,9 +14,12 @@ EXPERIMENTAL {
rte_tel_data_start_array;
rte_tel_data_start_dict;
rte_tel_data_string;
- rte_telemetry_init;
rte_telemetry_legacy_register;
rte_telemetry_register_cmd;
local: *;
};
+
+INTERNAL {
+ rte_telemetry_init;
+};
--
2.27.0
^ permalink raw reply [relevance 10%]
* Re: [dpdk-dev] [RFC PATCH v4] build: kni cross-compilation support
2021-02-05 15:27 3% ` Bruce Richardson
@ 2021-02-08 10:17 0% ` Juraj Linkeš
2021-02-08 10:26 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Juraj Linkeš @ 2021-02-08 10:17 UTC (permalink / raw)
To: Bruce Richardson
Cc: thomas, Ruifeng.Wang, Honnappa.Nagarahalli, jerinjacobk,
hemant.agrawal, ferruh.yigit, aboyer, dev, david.marchand, bluca
> -----Original Message-----
> From: Bruce Richardson <bruce.richardson@intel.com>
> Sent: Friday, February 5, 2021 4:27 PM
> To: Juraj Linkeš <juraj.linkes@pantheon.tech>
> Cc: thomas@monjalon.net; Ruifeng.Wang@arm.com;
> Honnappa.Nagarahalli@arm.com; jerinjacobk@gmail.com;
> hemant.agrawal@nxp.com; ferruh.yigit@intel.com; aboyer@pensando.io;
> dev@dpdk.org; david.marchand@redhat.com; bluca@debian.org
> Subject: Re: [RFC PATCH v4] build: kni cross-compilation support
>
> On Fri, Feb 05, 2021 at 04:04:32PM +0100, Juraj Linkeš wrote:
> > The kni linux module is using a custom target for building, which
> > doesn't take into account any cross compilation arguments. The
> > arguments in question are ARCH, CROSS_COMPILE (for gcc, clang) and CC,
> > LD (for clang). Get those from the cross file and pass them to the
> > custom target.
> >
> > The user supplied path may not contain the 'build' directory, such as
> > when using cross-compiled headers, so only append that in the default
> > case (when no path is supplied in native builds) and use the
> > unmodified path from the user otherwise. Also modify the install path
> accordingly.
> >
> > Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > ---
>
> Thanks, this all looks ok to me now, bar one very minor nit below. Doing a native
> build on my system with the running kernel also works fine.
>
> However, the bigger question is one of compatibility for this change. The current
> documentation for the kernel_dir option is:
> option('kernel_dir', type: 'string', value: '',
> description: 'Path to the kernel for building kernel modules. \
> Headers must be in $kernel_dir/build. Modules will be installed \
> in $DEST_DIR/$kernel_dir/extra/dpdk.')
>
> Obviously the description now needs an update to reflect the new use
I'll change the description. The current patch version is always installing the modules into '/lib/modules/' + kernel_version + '/extra/dpdk', though. I don't think we want to change the behavior this way, so I'll make the changes to preserve to original behavior ('/lib/modules/' + kernel_version + '/extra/dpdk' when kernel_dir is not supplied, kernel_dir + '/extra/dpdk' when it is).
> , but I'm
> not sure if changing the behaviour counts as an "ABI" change or not, and
> whether it needs to wait for a new LTS release. Any scripts that were compiling
> using e.g. kernel_dir='/lib/modules/<version>' need to be changed to use
> kernel_dir='/lib/modules/<version>/build' instead.
>
I'm not sure what to do with this. Should I make it backwards compatible by checking the build dir as well (i.e. trying make kernelversion in both $kernel_dir and $kernel_dir/build)?
> /Bruce
>
> > kernel/linux/kni/meson.build | 8 ++--
> > kernel/linux/meson.build | 80 ++++++++++++++++++++++++++++++------
> > 2 files changed, 71 insertions(+), 17 deletions(-)
> >
> > diff --git a/kernel/linux/kni/meson.build
> > b/kernel/linux/kni/meson.build index 07e0c9dae7..46b71c7418 100644
> > --- a/kernel/linux/kni/meson.build
> > +++ b/kernel/linux/kni/meson.build
> > @@ -13,7 +13,7 @@ kni_sources = files( custom_target('rte_kni',
> > input: kni_sources,
> > output: 'rte_kni.ko',
> > - command: ['make', '-j4', '-C', kernel_dir + '/build',
> > + command: ['make', '-j4', '-C', kernel_build_dir,
> > 'M=' + meson.current_build_dir(),
> > 'src=' + meson.current_source_dir(),
> > 'MODULE_CFLAGS=-include ' + meson.source_root() +
> > '/config/rte_config.h' + @@ -21,8 +21,8 @@ custom_target('rte_kni',
> > ' -I' + meson.source_root() + '/lib/librte_kni' +
> > ' -I' + meson.build_root() +
> > ' -I' + meson.current_source_dir(),
> > - 'modules'],
> > + 'modules'] + cross_args,
> > depends: kni_mkfile,
> > - install: true,
> > - install_dir: kernel_dir + '/extra/dpdk',
> > + install: install,
> > + install_dir: kernel_install_dir,
> > build_by_default: get_option('enable_kmods')) diff --git
> > a/kernel/linux/meson.build b/kernel/linux/meson.build index
> > 5c864a4653..7acb52944f 100644
> > --- a/kernel/linux/meson.build
> > +++ b/kernel/linux/meson.build
> > @@ -3,25 +3,79 @@
> >
> > subdirs = ['kni']
> >
> > -# if we are cross-compiling we need kernel_dir specified -if
> > get_option('kernel_dir') == '' and meson.is_cross_build()
> > - error('Need "kernel_dir" option for kmod compilation when cross-
> compiling')
> > -endif
> > +kernel_build_dir = get_option('kernel_dir') install = not
> > +meson.is_cross_build() cross_args = [] kernel_install_dir = ''
>
> Minor nit, I'd have kernel_install_dir immediately after kernel_build_dir in the list
> above.
>
Sure.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC PATCH v4] build: kni cross-compilation support
2021-02-08 10:17 0% ` Juraj Linkeš
@ 2021-02-08 10:26 0% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2021-02-08 10:26 UTC (permalink / raw)
To: Juraj Linkeš
Cc: thomas, Ruifeng.Wang, Honnappa.Nagarahalli, jerinjacobk,
hemant.agrawal, ferruh.yigit, aboyer, dev, david.marchand, bluca
On Mon, Feb 08, 2021 at 10:17:56AM +0000, Juraj Linkeš wrote:
>
>
> > -----Original Message-----
> > From: Bruce Richardson <bruce.richardson@intel.com>
> > Sent: Friday, February 5, 2021 4:27 PM
> > To: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > Cc: thomas@monjalon.net; Ruifeng.Wang@arm.com;
> > Honnappa.Nagarahalli@arm.com; jerinjacobk@gmail.com;
> > hemant.agrawal@nxp.com; ferruh.yigit@intel.com; aboyer@pensando.io;
> > dev@dpdk.org; david.marchand@redhat.com; bluca@debian.org
> > Subject: Re: [RFC PATCH v4] build: kni cross-compilation support
> >
> > On Fri, Feb 05, 2021 at 04:04:32PM +0100, Juraj Linkeš wrote:
> > > The kni linux module is using a custom target for building, which
> > > doesn't take into account any cross compilation arguments. The
> > > arguments in question are ARCH, CROSS_COMPILE (for gcc, clang) and CC,
> > > LD (for clang). Get those from the cross file and pass them to the
> > > custom target.
> > >
> > > The user supplied path may not contain the 'build' directory, such as
> > > when using cross-compiled headers, so only append that in the default
> > > case (when no path is supplied in native builds) and use the
> > > unmodified path from the user otherwise. Also modify the install path
> > accordingly.
> > >
> > > Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > > ---
> >
> > Thanks, this all looks ok to me now, bar one very minor nit below. Doing a native
> > build on my system with the running kernel also works fine.
> >
> > However, the bigger question is one of compatibility for this change. The current
> > documentation for the kernel_dir option is:
> > option('kernel_dir', type: 'string', value: '',
> > description: 'Path to the kernel for building kernel modules. \
> > Headers must be in $kernel_dir/build. Modules will be installed \
> > in $DEST_DIR/$kernel_dir/extra/dpdk.')
> >
> > Obviously the description now needs an update to reflect the new use
>
> I'll change the description. The current patch version is always installing the modules into '/lib/modules/' + kernel_version + '/extra/dpdk', though. I don't think we want to change the behavior this way, so I'll make the changes to preserve to original behavior ('/lib/modules/' + kernel_version + '/extra/dpdk' when kernel_dir is not supplied, kernel_dir + '/extra/dpdk' when it is).
>
In the absense of an explicit kernel_install_dir, I actually think the new
way is better. However, I'd be interested in other opinions on this.
> > , but I'm
> > not sure if changing the behaviour counts as an "ABI" change or not, and
> > whether it needs to wait for a new LTS release. Any scripts that were compiling
> > using e.g. kernel_dir='/lib/modules/<version>' need to be changed to use
> > kernel_dir='/lib/modules/<version>/build' instead.
> >
>
> I'm not sure what to do with this. Should I make it backwards compatible by checking the build dir as well (i.e. trying make kernelversion in both $kernel_dir and $kernel_dir/build)?
>
That's an interesting proposal. Might be worth doing to check both.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH] eal: fix detection of static or shared DPDK builds
@ 2021-02-08 16:33 4% Bruce Richardson
2021-02-09 12:49 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2021-02-08 16:33 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson, tredaelli, stable, Maxime Coquelin, David Marchand
When checking the loading of EAL shared lib to see if we have a shared
DPDK build, we only want to include part of the ABI version in the check
rather than the whole thing. For example, with ABI version 21.1 for DPDK
release 21.02, the linker links the binary against librte_eal.so.21,
without the ".1".
To avoid any further brittleness in this area, we can check for multiple
versions when doing the check, since just about any version of EAL implies
a shared build. Therefore we check for presence of librte_eal.so with full
ABI_VERSION extension, and then repeatedly remove the end part of the
filename after the last dot, checking each time. For example (debug log
output for static build):
EAL: Checking presence of .so 'librte_eal.so.21.1'
EAL: Checking presence of .so 'librte_eal.so.21'
EAL: Checking presence of .so 'librte_eal.so'
EAL: Detected static linkage of DPDK
Fixes: 7781950f4d38 ("eal: fix shared lib mode detection")
Cc: tredaelli@redhat.com
Cc: stable@dpdk.org
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
lib/librte_eal/common/eal_common_options.c | 35 +++++++++++++++++++++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/lib/librte_eal/common/eal_common_options.c b/lib/librte_eal/common/eal_common_options.c
index 6b3707725f..94029bf7f1 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -494,6 +494,39 @@ eal_dlopen(const char *pathname)
return retval;
}
+static int
+is_shared_build(void)
+{
+#define EAL_SO "librte_eal.so"
+ char soname[32];
+ size_t len, minlen = strlen(EAL_SO);
+
+ len = strlcpy(soname, EAL_SO"."ABI_VERSION, sizeof(soname));
+ if (len > sizeof(soname)) {
+ RTE_LOG(ERR, EAL, "Shared lib name too long in shared build check\n");
+ len = sizeof(soname) - 1;
+ }
+
+ while (len >= minlen) {
+ /* check if we have this .so loaded, if so - shared build */
+ RTE_LOG(DEBUG, EAL, "Checking presence of .so '%s'\n", soname);
+ if (dlopen(soname, RTLD_LAZY | RTLD_NOLOAD) != NULL) {
+ RTE_LOG(INFO, EAL, "Detected shared linkage of DPDK\n");
+ return 1;
+ }
+
+ /* remove any version numbers off the end to retry */
+ while (len-- > 0)
+ if (soname[len] == '.') {
+ soname[len] = '\0';
+ break;
+ }
+ }
+
+ RTE_LOG(INFO, EAL, "Detected static linkage of DPDK\n");
+ return 0;
+}
+
int
eal_plugins_init(void)
{
@@ -505,7 +538,7 @@ eal_plugins_init(void)
* (Using dlopen with NOLOAD flag on EAL, will return NULL if the EAL
* shared library is not already loaded i.e. it's statically linked.)
*/
- if (dlopen("librte_eal.so."ABI_VERSION, RTLD_LAZY | RTLD_NOLOAD) != NULL &&
+ if (is_shared_build() &&
*default_solib_dir != '\0' &&
stat(default_solib_dir, &sb) == 0 &&
S_ISDIR(sb.st_mode))
--
2.27.0
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] eal: fix detection of static or shared DPDK builds
2021-02-08 16:33 4% [dpdk-dev] [PATCH] eal: fix detection of static or shared DPDK builds Bruce Richardson
@ 2021-02-09 12:49 0% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2021-02-09 12:49 UTC (permalink / raw)
To: dev; +Cc: tredaelli, stable, Maxime Coquelin, David Marchand, bluca
On Mon, Feb 08, 2021 at 04:33:19PM +0000, Bruce Richardson wrote:
> When checking the loading of EAL shared lib to see if we have a shared
> DPDK build, we only want to include part of the ABI version in the check
> rather than the whole thing. For example, with ABI version 21.1 for DPDK
> release 21.02, the linker links the binary against librte_eal.so.21,
> without the ".1".
>
> To avoid any further brittleness in this area, we can check for multiple
> versions when doing the check, since just about any version of EAL implies
> a shared build. Therefore we check for presence of librte_eal.so with full
> ABI_VERSION extension, and then repeatedly remove the end part of the
> filename after the last dot, checking each time. For example (debug log
> output for static build):
>
> EAL: Checking presence of .so 'librte_eal.so.21.1'
> EAL: Checking presence of .so 'librte_eal.so.21'
> EAL: Checking presence of .so 'librte_eal.so'
> EAL: Detected static linkage of DPDK
>
> Fixes: 7781950f4d38 ("eal: fix shared lib mode detection")
> Cc: tredaelli@redhat.com
> Cc: stable@dpdk.org
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
I saw this issue with OVS, where I was getting weird failures about ports
not being bound (in case of physical ports) or not being created (in case
of virtio ports), when using a shared build. Since it's potentially
serious, I'd appreciate if someone can reproduce the issue and verify the
fix so we can consider it for 21.02 inclusion.
To demonstrate this with regular DPDK, do a usual build of DPDK and then do
"ninja install" to install system-wide. Then build an example app, e.g.
l2fwd, using "make" from the examples/l2fwd directory. Running the example
normally, e.g. ./build/l2fwd -c F00, leads to no drivers being loaded or
ports being found. Adding "-d /path/to/drivers" e.g.
"/usr/local/lib/x86_64-linux-gnu/dpdk/pmds-21.1" on my system works as
expected. This shows the driver loading is not correct.
After applying this patch and re-running "ninja install", l2fwd should run
the same with and without the "-d" flag.
/Bruce
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] eal/rwlock: add note about writer starvation
2021-01-14 16:55 3% ` [dpdk-dev] [PATCH v2] " Stephen Hemminger
@ 2021-02-11 22:51 0% ` Thomas Monjalon
2021-02-12 0:21 0% ` Honnappa Nagarahalli
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2021-02-11 22:51 UTC (permalink / raw)
To: Stephen Hemminger
Cc: dev, honnappa.nagarahalli, joyce.kong, konstantin.ananyev
14/01/2021 17:55, Stephen Hemminger:
> The implementation of reader/writer locks in DPDK (from first release)
> is simple and fast. But it can lead to writer starvation issues.
>
> It is not easy to fix this without changing ABI and potentially
> breaking customer applications that are expect the unfair behavior.
typo: "are expect"
> The wikipedia page on reader-writer problem has a similar example
> which summarizes the problem pretty well.
Maybe add the URL in the commit message?
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
> --- a/lib/librte_eal/include/generic/rte_rwlock.h
> +++ b/lib/librte_eal/include/generic/rte_rwlock.h
> + * Note: This version of reader/writer locks is not fair because
> + * readers do not block for pending writers. A stream of readers can
> + * subsequently lock out all potential writers and starve them.
> + * This is because after the first reader locks the resource,
> + * no writer can lock it. The writer will only be able to get the lock
> + * when it will only be released by the last reader.
You did not get review, probably because nobody was Cc'ed.
+Cc Honnappa, Joyce and Konstantin
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] eal/rwlock: add note about writer starvation
2021-02-11 22:51 0% ` Thomas Monjalon
@ 2021-02-12 0:21 0% ` Honnappa Nagarahalli
0 siblings, 0 replies; 200+ results
From: Honnappa Nagarahalli @ 2021-02-12 0:21 UTC (permalink / raw)
To: thomas, Stephen Hemminger
Cc: dev, Joyce Kong, konstantin.ananyev, nd, Honnappa Nagarahalli, nd
<snip>
>
> 14/01/2021 17:55, Stephen Hemminger:
> > The implementation of reader/writer locks in DPDK (from first release)
> > is simple and fast. But it can lead to writer starvation issues.
> >
> > It is not easy to fix this without changing ABI and potentially
> > breaking customer applications that are expect the unfair behavior.
>
> typo: "are expect"
>
> > The wikipedia page on reader-writer problem has a similar example
> > which summarizes the problem pretty well.
>
> Maybe add the URL in the commit message?
>
> >
> > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > ---
> > --- a/lib/librte_eal/include/generic/rte_rwlock.h
> > +++ b/lib/librte_eal/include/generic/rte_rwlock.h
> > + * Note: This version of reader/writer locks is not fair because
^^^^^^ may be "implementation" would be better?
> > + * readers do not block for pending writers. A stream of readers can
> > + * subsequently lock out all potential writers and starve them.
> > + * This is because after the first reader locks the resource,
> > + * no writer can lock it. The writer will only be able to get the
> > + lock
> > + * when it will only be released by the last reader.
This looks good. Though the writer starvation is prominent, the reader starvation is possible if there is a stream of writers when a writer holds the lock. Should we call this out too?
>
> You did not get review, probably because nobody was Cc'ed.
> +Cc Honnappa, Joyce and Konstantin
>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] officially support building driver plugins externally
@ 2021-02-12 19:09 3% Tyler Retzlaff
0 siblings, 0 replies; 200+ results
From: Tyler Retzlaff @ 2021-02-12 19:09 UTC (permalink / raw)
To: dev; +Cc: thomas
Hi,
Recently installation of driver headers and export of functions was pulled back from being public to private (commit df96fd0d73955bdc7ca3909e772ff2ad903249c6). From a discussion with Thomas Monjalon we understand that it was not the design intent to ever have these headers exposed publicly, but it was allowing us to maintain the drivers we do implement outside of the normal dpdk tree.
We would like to propose that building driver plugins external to the dpdk source tree be officially supported / restored and it is is our understanding there there are asks from other DPDK consumers for the same. We understand the main concern is that it might incorrectly convey that the API/ABI of the driver interface is stable or promised to be compatible when no such promise exists.
Can the broader community help us with an acceptable solution to building the drivers out of the tree? Aside from installing the needed headers what other mechanical things can we do to achieve this? We are happy to do the work/submit the required patches as necessary.
Thank you
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [dpdk-announce] DPDK 21.02 released
@ 2021-02-14 19:19 3% Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2021-02-14 19:19 UTC (permalink / raw)
To: announce
A new release is available:
https://fast.dpdk.org/rel/dpdk-21.02.tar.xz
It was a light period as February releases of the 2 previous years:
941 commits from 140 authors
1208 files changed, 53571 insertions(+), 21946 deletions(-)
It is not planned to start a maintenance branch for 21.02.
This version is ABI-compatible with 20.11.
Note 1: you may need pyelftools to compile DPDK drivers.
Note 2: a cleanup made out-of-tree drivers more difficult to compile.
Below are some new features, grouped by category.
* Networking
- power management for core polling single ethdev queue
- generic modify action in flow API
- GENEVE TLV option in flow API
- Marvell OCTEON TX EP net PMD
- Virtio PMD rework
- Windows support of i40e and mlx5
* Cryptography
- callback API for enqueue/dequeue
* Compression
- Mellanox compress PMD
* Others
- new pmdinfogen with Windows support
More details in the release notes:
https://doc.dpdk.org/guides/rel_notes/release_21_02.html
There are 34 new contributors (including authors, reviewers and testers).
Welcome to Andrew Boyer, Andrii Pypchenko, Ashish Sadanandan, Barry Cao,
Dana Vardi, Dapeng Yu, Fabio Pricoco, Fei Chen, Francis Kelly,
Fredrik A Lindgren, George Prekas, Jacek Bułatek, Jiawei Zhu, Kiran KN,
Lingyu Liu, Louis Peens, Mateusz Pacuszka, Meir Levi, Milena Olech,
Murphy Yang, Nalla Pradeep, Neel Patel, Odi Assli, Paolo Valerio,
Peng He, Samik Gupta, Simon Ellmann, Somalapuram Amaranath, Subhi Masri,
Szymon T Cudzilo, Tyler Retzlaff, Viacheslav Galaktionov, Wenjun Wu and
Yongxin Liu.
Below is the number of commits per employer (with authors count):
257 Intel (41)
228 Nvidia (19)
68 Red Hat (4)
65 Marvell (15)
51 Huawei (9)
44 Arm (4)
43 Broadcom (7)
36 Pensando (1)
33 Trustnet (1)
16 BIFIT (1)
14 PANTHEON.tech (1)
13 OKTET Labs (2)
13 Microsoft (4)
12 NXP (4)
6 Chelsio (1)
5 Amazon (4)
5 6WIND (1)
4 Netronome (1)
4 Cisco (2)
4 AMD (3)
3 MayaData (1)
3 Emumba (1)
Based on Reviewed-by and Acked-by tags, the top non-PMD reviewers are:
31 Ruifeng Wang <ruifeng.wang@arm.com>
29 Ferruh Yigit <ferruh.yigit@intel.com>
25 David Marchand <david.marchand@redhat.com>
23 Maxime Coquelin <maxime.coquelin@redhat.com>
17 Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
16 Ori Kam <orika@nvidia.com>
15 Jerin Jacob <jerinj@marvell.com>
13 Konstantin Ananyev <konstantin.ananyev@intel.com>
11 Viacheslav Ovsiienko <viacheslavo@nvidia.com>
The new features for 21.05 may be submitted until mid-March,
in order to be reviewed and integrated before mid-April.
DPDK 21.05 should be released at mid-May:
https://core.dpdk.org/roadmap#dates
Please share your features roadmap.
Thanks everyone, enjoy Spring Festival and Valentine's Day,
and let's share as much love as we can.
https://fast.dpdk.org/download/ilovefs.jpg
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH] version: 21.05-rc0
@ 2021-02-15 9:14 7% Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2021-02-15 9:14 UTC (permalink / raw)
To: dev
Start a new release cycle with empty release notes.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
ABI_VERSION | 2 +-
VERSION | 2 +-
doc/guides/rel_notes/index.rst | 1 +
doc/guides/rel_notes/release_21_05.rst | 138 +++++++++++++++++++++++++
4 files changed, 141 insertions(+), 2 deletions(-)
create mode 100644 doc/guides/rel_notes/release_21_05.rst
diff --git a/ABI_VERSION b/ABI_VERSION
index ea8c92af65..c598172d8d 100644
--- a/ABI_VERSION
+++ b/ABI_VERSION
@@ -1 +1 @@
-21.1
+21.2
diff --git a/VERSION b/VERSION
index 02e8cfea89..5a12c01a05 100644
--- a/VERSION
+++ b/VERSION
@@ -1 +1 @@
-21.02.0
+21.05.0-rc0
diff --git a/doc/guides/rel_notes/index.rst b/doc/guides/rel_notes/index.rst
index 3f485c2de2..4c423c8d9a 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_21_05
release_21_02
release_20_11
release_20_08
diff --git a/doc/guides/rel_notes/release_21_05.rst b/doc/guides/rel_notes/release_21_05.rst
new file mode 100644
index 0000000000..5aa9ed7db6
--- /dev/null
+++ b/doc/guides/rel_notes/release_21_05.rst
@@ -0,0 +1,138 @@
+.. SPDX-License-Identifier: BSD-3-Clause
+ Copyright 2021 The DPDK contributors
+
+.. include:: <isonum.txt>
+
+DPDK Release 21.05
+==================
+
+.. **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_21_05.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
+-----------
+
+.. This section should contain API changes. Sample format:
+
+ * sample: Add a short 1-2 sentence description of the API change
+ which was announced in the previous releases and made in this release.
+ Start with a scope label like "ethdev:".
+ Use fixed width quotes for ``function_names`` or ``struct_names``.
+ Use 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.
+ =======================================================
+
+
+ABI Changes
+-----------
+
+.. This section should contain ABI changes. Sample format:
+
+ * sample: Add a short 1-2 sentence description of the ABI change
+ which was announced in the previous releases and made in this release.
+ Start with a scope label like "ethdev:".
+ Use fixed width quotes for ``function_names`` or ``struct_names``.
+ Use 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.
+ =======================================================
+
+* No ABI change that would break compatibility with 20.11.
+
+
+Known Issues
+------------
+
+.. This section should contain new known issues in this release. Sample format:
+
+ * **Add title in present tense with full stop.**
+
+ Add a short 1-2 sentence description of the known issue
+ in the present tense. Add information on any known workarounds.
+
+ This section is a comment. Do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ =======================================================
+
+
+Tested Platforms
+----------------
+
+.. This section should contain a list of platforms that were tested
+ with this release.
+
+ The format is:
+
+ * <vendor> platform with <vendor> <type of devices> combinations
+
+ * List of CPU
+ * List of OS
+ * List of devices
+ * Other relevant details...
+
+ This section is a comment. Do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ =======================================================
--
2.30.0
^ permalink raw reply [relevance 7%]
* [dpdk-dev] Build errors due to duplicate version.map entries in librte_power
@ 2021-02-15 19:18 3% Aaron Conole
2021-02-22 10:31 0% ` Juraj Linkeš
0 siblings, 1 reply; 200+ results
From: Aaron Conole @ 2021-02-15 19:18 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson, David Hunt, Anatoly Burakov
Greetings,
During CI runs, I've noticed lots of failures from the Travis-CI side
all related to librte_power/version.map containing some duplicate
symbols. It seems commit 4d3892dcd77b ("power: make channel message
functions public") made the following hunk:
diff --git a/lib/librte_power/version.map b/lib/librte_power/version.map
index 69ca9af616..13f0af3b2d 100644
--- a/lib/librte_power/version.map
+++ b/lib/librte_power/version.map
@@ -34,4 +34,8 @@ EXPERIMENTAL {
rte_power_guest_channel_receive_msg;
rte_power_poll_stat_fetch;
rte_power_poll_stat_update;
+
+ # added in 21.02
+ rte_power_guest_channel_receive_msg;
+ rte_power_guest_channel_send_msg;
};
As can be seen, rte_power_guest_channel_receive_msg was added already
(it's present in the hunk itself). The rte_power_guest_channel_send_msg
function was added as part of 85ff364f3bd3 ("build: align symbols with
global ABI version").
I guess it may not be allowed to have duplicate symbols here, because in
travis, I see (only for some builds):
clang -o lib/librte_power.so.21.1 'lib/lib@@rte_power@sta/librte_power_rte_power.c.o' 'lib/lib@@rte_power@sta/librte_power_power_acpi_cpufreq.c.o' 'lib/lib@@rte_power@sta/librte_power_power_kvm_vm.c.o' 'lib/lib@@rte_power@sta/librte_power_guest_channel.c.o' 'lib/lib@@rte_power@sta/librte_power_rte_power_empty_poll.c.o' 'lib/lib@@rte_power@sta/librte_power_power_pstate_cpufreq.c.o' 'lib/lib@@rte_power@sta/librte_power_rte_power_pmd_mgmt.c.o' 'lib/lib@@rte_power@sta/librte_power_power_common.c.o' -Wl,--no-undefined -Wl,--as-needed -shared -fPIC -Wl,--start-group -Wl,-soname,librte_power.so.21 -Wl,--no-as-needed -pthread -lm -ldl lib/librte_eal.so.21.1 lib/librte_kvargs.so.21.1 lib/librte_telemetry.so.21.1 lib/librte_timer.so.21.1 lib/librte_ethdev.so.21.1 lib/librte_net.so.21.1 lib/librte_mbuf.so.21.1 lib/librte_mempool.so.21.1 lib/librte_ring.so.21.1 lib/librte_meter.so.21.1 -Wl,--end-group -Wl,--version-script=/home/travis/build/ovsrobot/dpdk/lib/librte_power/version.map '-Wl,-rpath,$ORIGIN/' -Wl,-rpath-link,/home/travis/build/ovsrobot/dpdk/build/lib -target aarch64-linux-gnu -fuse-ld=lld --gcc-toolchain=/usr
ld.lld: error: duplicate symbol 'rte_power_guest_channel_send_msg' in version script
Thoughts?
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v3] build: alias default build as generic
@ 2021-02-18 14:12 3% ` Juraj Linkeš
0 siblings, 0 replies; 200+ results
From: Juraj Linkeš @ 2021-02-18 14:12 UTC (permalink / raw)
To: bruce.richardson, thomas, Ruifeng.Wang, Honnappa.Nagarahalli,
jerinjacobk, ferruh.yigit
Cc: dev, Juraj Linkeš
The current machine='default' build name is not descriptive. The actual
default build is machine='native'. Add an alternative string which does
the same build and better describes what we're building:
machine='generic'. Leave machine='default' for backwards compatibility.
Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
---
config/arm/meson.build | 7 ++++---
config/meson.build | 13 +++++++------
devtools/test-meson-builds.sh | 14 +++++++-------
doc/guides/prog_guide/build-sdk-meson.rst | 4 ++--
meson_options.txt | 2 +-
5 files changed, 21 insertions(+), 19 deletions(-)
diff --git a/config/arm/meson.build b/config/arm/meson.build
index 00bc4610a3..aaed89bd5b 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017 Intel Corporation.
# Copyright(c) 2017 Cavium, Inc
+# Copyright(c) 2021 PANTHEON.tech s.r.o.
# common flags to all aarch64 builds, with lowest priority
flags_common = [
@@ -208,8 +209,8 @@ if dpdk_conf.get('RTE_ARCH_32')
else
# aarch64 build
if not meson.is_cross_build()
- if machine == 'default'
- # default build
+ if machine == 'generic'
+ # generic build
implementer_id = 'generic'
part_number = 'generic'
else
@@ -256,7 +257,7 @@ else
'(-Dmachine=generic) build.')
endif
- # use default flags with implementer flags
+ # use common flags with implementer flags
dpdk_flags = flags_common + implementer_config['flags'] + part_number_config.get('flags', [])
# apply supported machine args
diff --git a/config/meson.build b/config/meson.build
index 3cf560b8a3..ed4de62b37 100644
--- a/config/meson.build
+++ b/config/meson.build
@@ -70,21 +70,22 @@ else
machine = get_option('machine')
endif
-# machine type 'default' is special, it defaults to the per arch agreed common
-# minimal baseline needed for DPDK.
+# machine type 'generic' is special, it selects the per arch agreed common
+# minimal baseline needed for DPDK. Machine type 'default' is also supported
+# with the same meaning for backwards compatibility.
# That might not be the most optimized, but the most portable version while
# still being able to support the CPU features required for DPDK.
# This can be bumped up by the DPDK project, but it can never be an
# invariant like 'native'
-if machine == 'default'
+if machine == 'default' or machine == 'generic'
if host_machine.cpu_family().startswith('x86')
- # matches the old pre-meson build systems default
+ # matches the old pre-meson build systems generic machine
machine = 'corei7'
elif host_machine.cpu_family().startswith('arm')
machine = 'armv7-a'
elif host_machine.cpu_family().startswith('aarch')
- # arm64 manages defaults in config/arm/meson.build
- machine = 'default'
+ # arm64 manages generic config in config/arm/meson.build
+ machine = 'generic'
elif host_machine.cpu_family().startswith('ppc')
machine = 'power8'
endif
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index c11ae87e0d..daf817ac3e 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -223,12 +223,12 @@ done
# test compilation with minimal x86 instruction set
# Set the install path for libraries to "lib" explicitly to prevent problems
# with pkg-config prefixes if installed in "lib/x86_64-linux-gnu" later.
-default_machine='nehalem'
-if ! check_cc_flags "-march=$default_machine" ; then
- default_machine='corei7'
+generic_machine='nehalem'
+if ! check_cc_flags "-march=$generic_machine" ; then
+ generic_machine='corei7'
fi
-build build-x86-default cc skipABI -Dcheck_includes=true \
- -Dlibdir=lib -Dmachine=$default_machine $use_shared
+build build-x86-generic cc skipABI -Dcheck_includes=true \
+ -Dlibdir=lib -Dmachine=$generic_machine $use_shared
# 32-bit with default compiler
if check_cc_flags '-m32' ; then
@@ -271,10 +271,10 @@ for f in $srcdir/config/ppc/ppc* ; do
build $targetdir $f ABI $use_shared
done
-# Test installation of the x86-default target, to be used for checking
+# Test installation of the x86-generic target, to be used for checking
# the sample apps build using the pkg-config file for cflags and libs
load_env cc
-build_path=$(readlink -f $builds_dir/build-x86-default)
+build_path=$(readlink -f $builds_dir/build-x86-generic)
export DESTDIR=$build_path/install
install_target $build_path $DESTDIR
pc_file=$(find $DESTDIR -name libdpdk.pc)
diff --git a/doc/guides/prog_guide/build-sdk-meson.rst b/doc/guides/prog_guide/build-sdk-meson.rst
index 3429e26479..c7e12eedfb 100644
--- a/doc/guides/prog_guide/build-sdk-meson.rst
+++ b/doc/guides/prog_guide/build-sdk-meson.rst
@@ -85,7 +85,7 @@ Project-specific options are passed used -Doption=value::
meson -Denable_docs=true fullbuild # build and install docs
- meson -Dmachine=default # use builder-independent baseline -march
+ meson -Dmachine=generic # use builder-independent baseline -march
meson -Ddisable_drivers=event/*,net/tap # disable tap driver and all
# eventdev PMDs for a smaller build
@@ -114,7 +114,7 @@ Examples of setting some of the same options using meson configure::
re-scan from meson.
.. note::
- machine=default uses a config that works on all supported architectures
+ machine=generic uses a config that works on all supported architectures
regardless of the capabilities of the machine where the build is happening.
As well as those settings taken from ``meson configure``, other options
diff --git a/meson_options.txt b/meson_options.txt
index 6eff62e47d..2c7b46ef07 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -21,7 +21,7 @@ option('include_subdir_arch', type: 'string', value: '',
option('kernel_dir', type: 'string', value: '',
description: 'Path to the kernel for building kernel modules. Headers must be in $kernel_dir/build. Modules will be installed in $DEST_DIR/$kernel_dir/extra/dpdk.')
option('machine', type: 'string', value: 'native',
- description: 'set the target machine type')
+ description: 'set the target machine type or "generic", a build usable on all machines of the build machine architecture or "native", which lets the compiler pick the architecture of the build machine.')
option('max_ethports', type: 'integer', value: 32,
description: 'maximum number of Ethernet devices')
option('max_lcores', type: 'integer', value: 128,
--
2.20.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 1/3 v4] ethdev: add Rx offload to drop error packets
@ 2021-02-18 20:32 4% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2021-02-18 20:32 UTC (permalink / raw)
To: nipun.gupta, dev
Cc: thomas, arybchenko, hemant.agrawal, sachin.saxena, rohit.raj,
jerinjacobk, stephen, asafp
On 10/15/2020 2:23 PM, nipun.gupta@nxp.com wrote:
> From: Nipun Gupta <nipun.gupta@nxp.com>
>
> This change adds a Rx offload capability and configuration to
> enable hardware to drop the packets in case of any error in the
> packets such as L3 checksum error or L4 checksum.
>
> Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
> Signed-off-by: Rohit Raj <rohit.raj@nxp.com>
> Reviewed-by: Asaf Penso <asafp@nvidia.com>
> ---
>
> v4:
> - renamed 'rte_rx_err_pkt_drop_conf' to
> 'rte_eth_rx_err_pkt_drop_conf'
> - updated function 'port_offload_cap_display' to display newly
> added offloads
> - added placeholder for L1 FCS, L3 Checksum, L4 Checksum error
> packet drops
> - updated doc/guides/nics/features.rst
> - updated new added 'DEV_RX_OFFLOAD_*' to 'RTE_DEV_RX_OFFLOAD*'
> - updated RX to Rx
>
> v3:
> - Add additional rx_err_drop_offload_capa, which is specific
> capability flag for RX packets error drop offload. Currently
> only 'all' error packet drops are enabled, but can be extended
> to provide capability to drop any specific errors like L1 FCS,
> L3 Checksum etc.
> - Added separate config structure to enable the drop configuration.
> - Updated doc with the new updated option in testbbdev (patch 3/3)
>
> v2:
> - Add support in DPAA1 driver (patch 2/3)
> - Add support and config parameter in testpmd (patch 3/3)
>
> lib/librte_ethdev/rte_ethdev.c | 1 +
> lib/librte_ethdev/rte_ethdev.h | 39 +++++++++++++++++++++++++++++++++-
> 2 files changed, 39 insertions(+), 1 deletion(-)
>
> diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
This feature touches many main parts,
- new config item for 'rte_eth_dev_configure()'
- a new offload flag
- new capability reporting for 'rte_eth_dev_info_get()'
The feature doesn't look very mainstream to touch all these main parts and add
complexity to them, which will affect almost all users.
And has some inconsistencies, like configuration is done via config struct, but
capability is returned as bit-wise.
Or I think config option taken into account only if offload is requested has a
chance to confuse people in both app and driver end.
What do you think having two specific APIs to get_capabilities and set drop config?
The responsibility of those APIs will be clear and narrowed down, which makes it
harder to make it wrong.
Also it is an ABI break as it is and needs to wait 21.11, and even after that it
has a potential to cause more ABI breaks, like trying to add a new error type to
drop will need to wait 22.11 ..., but if we can have them as separate APIs we
can have them as experimental without waiting next LTS.
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v2] doc: update stable section
@ 2021-02-19 11:17 4% Kevin Traynor
0 siblings, 0 replies; 200+ results
From: Kevin Traynor @ 2021-02-19 11:17 UTC (permalink / raw)
To: dev; +Cc: stable, bluca, christian.ehrhardt, Kevin Traynor
Updating the docs to elaborate on the stable release
characteristics and better document the current practice
about new features in stable releases.
Signed-off-by: Kevin Traynor <ktraynor@redhat.com>
---
v2: Send to right dev list this time. Fix typo.
---
doc/guides/contributing/stable.rst | 33 ++++++++++++++++++++++++------
1 file changed, 27 insertions(+), 6 deletions(-)
diff --git a/doc/guides/contributing/stable.rst b/doc/guides/contributing/stable.rst
index 20b081670..7a0a505aa 100644
--- a/doc/guides/contributing/stable.rst
+++ b/doc/guides/contributing/stable.rst
@@ -19,4 +19,8 @@ consumers of DPDK with a stable target on which to base applications or
packages.
+The primary characteristics of stable releases is that they attempt to
+fix issues and not introduce any new regressions while keeping backwards
+compatibility with the initial release of the stable version.
+
The Long Term Support release (LTS) is a designation applied to a Stable
Release to indicate longer term support.
@@ -94,12 +98,29 @@ commit message body as follows::
Fixes not suitable for backport should not include the ``Cc: stable@dpdk.org`` tag.
-Features should not be backported to stable releases. It may be acceptable, in
-limited cases, to back port features for the LTS release where:
+To support the goal of stability and not introducing regressions, new code
+being introduced is limited to bug fixes. New features should not be backported
+to stable releases.
-* There is a justifiable use case (for example a new PMD).
-* The change is non-invasive.
-* The work of preparing the backport is done by the proposer.
-* There is support within the community.
+In some limited cases, it may be acceptable to backport a new feature
+to a stable release. Some of the factors which impact the decision by
+stable maintainers are as follows:
+* Does the feature break API/ABI?
+* Does the feature break backwards compatibility?
+* Is it for the latest LTS release (to avoid LTS upgrade issues)?
+* Is there a commitment from the proposer or affiliation to validate the feature and check for regressions in related functionality?
+* Is there a track record of the proposer or affiliation validating stable releases?
+* Is it obvious that the feature will not impact existing functionality?
+* How intrusive is the code change?
+* What is the scope of the code change?
+* Does it impact common components or vendor specific?
+* Is there a justifiable use case (a clear user need)?
+* Is there a community consensus about the backport?
+
+Performance improvements are generally not considered to be fixes, but may be considered
+in some cases where:
+
+* It is fixing a performance regression that occurred previously.
+* An existing feature in LTS is not usable as intended without it.
The Stable Mailing List
--
2.26.2
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH 0/7] Introduce event vectorization
@ 2021-02-20 22:09 3% pbhagavatula
2021-02-20 22:09 5% ` [dpdk-dev] [PATCH 7/7] eventdev: fix ABI breakage due to event vector pbhagavatula
0 siblings, 1 reply; 200+ results
From: pbhagavatula @ 2021-02-20 22:09 UTC (permalink / raw)
To: jerinj, jay.jayatheerthan, erik.g.carrillo, abhinandan.gujjar,
timothy.mcdaniel, hemant.agrawal, harry.van.haaren,
mattias.ronnblom, liang.j.ma
Cc: dev, Pavan Nikhilesh
From: Pavan Nikhilesh <pbhagavatula@marvell.com>
In traditional event programming model, events are identified by a
flow-id and a uintptr_t. The flow-id uniquely identifies a given event
and determines the order of scheduling based on schedule type, the
uintptr_t holds a single object.
Event devices also support burst mode with configurable dequeue depth,
i.e. each dequeue call would return multiple events and each event
might be at a different stage of the pipeline.
Having a burst of events belonging to different stages in a dequeue
burst is not only difficult to vectorize but also increases the scheduler
overhead and application overhead of pipelining events further.
Using event vectors we see a performance gain of ~150% as shown in [1].
By introducing event vectorization, each event will be capable of holding
multiple uintptr_t of the same flow thereby allowing applications
to vectorize their pipeline and reduce the complexity of pipelining
events across multiple stages. This also reduces the complexity of handling
enqueue and dequeue on an event device.
Since event devices are transparent to the events they are scheduling
so the event producers such as eth_rx_adapter, crypto_adapter , etc..
are responsible for vectorizing the buffers of the same flow into a single
event.
The series also breaks ABI in [2/7] patch which we fix in [7/7]. The patch
[7/7] can be changed in the next major release i.e. v21.11.
The dpdk-test-eventdev application has been updated with options to test
multiple vector sizes and timeouts.
[1]
As for performance improvement, with a ARM Cortex-A72 equivalent processer,
software event device (--vdev=event_sw0), single worker core, single stage
and using one service core for Rx adapter, Tx adapter, Scheduling.
Without event vectorization:
./build/app/dpdk-test-eventdev -l 7-23 -s 0x700 --vdev="event_sw0" --
--prod_type_ethdev --nb_pkts=0 --verbose 2 --test=pipeline_queue
--stlist=a --wlcores=20
Port[0] using Rx adapter[0] configured
Port[0] using Tx adapter[0] Configured
4.728 mpps avg 4.728 mpps
With event vectorization:
./build/app/dpdk-test-eventdev -l 7-23 -s 0x700 --vdev="event_sw0" --
--prod_type_ethdev --nb_pkts=0 --verbose 2 --test=pipeline_queue
--stlist=a --wlcores=20 --enable_vector --nb_eth_queues 1
--vector_size 256
Port[0] using Rx adapter[0] configured
Port[0] using Tx adapter[0] Configured
34.383 mpps avg 34.383 mpps
Having dedicated service cores for each Rx queues and tweaking the vector,
dequeue burst size would further improve performance.
API usage is shown below:
Configuration:
struct rte_event_eth_rx_adapter_event_vector_config vec_conf;
vector_pool = rte_event_vector_pool_create("vector_pool",
nb_elem, 0, vector_size, socket_id);
rte_event_eth_rx_adapter_create(id, event_id, &adptr_conf);
rte_event_eth_rx_adapter_queue_add(id, eth_id, -1, &queue_conf);
if (cap & RTE_EVENT_ETH_RX_ADAPTER_CAP_EVENT_VECTOR) {
vec_conf.vector_sz = vector_size;
vec_conf.vector_timeout_ns = vector_tmo_nsec;
vec_conf.vector_mp = vector_pool;
rte_event_eth_rx_adapter_queue_event_vector_config(id,
eth_id, -1, &vec_conf);
}
Fastpath:
num = rte_event_dequeue_burst(event_id, port_id, &ev, 1, 0);
if (!num)
continue;
if (ev.event_type & RTE_EVENT_TYPE_VECTOR) {
switch (ev.event_type) {
case RTE_EVENT_TYPE_ETHDEV_VECTOR:
case RTE_EVENT_TYPE_ETH_RX_ADAPTER_VECTOR:
struct rte_mbuf **mbufs;
mbufs = ev.vector_ev->mbufs;
for (i = 0; i < ev.vector_ev->nb_elem; i++)
//Process mbufs.
break;
case ...
}
}
...
Pavan Nikhilesh (7):
eventdev: introduce event vector capability
eventdev: introduce event vector Rx capability
eventdev: introduce event vector Tx capability
eventdev: add Rx adapter event vector support
eventdev: add Tx adapter event vector support
app/eventdev: add event vector mode in pipeline test
eventdev: fix ABI breakage due to event vector
app/test-eventdev/evt_common.h | 4 +
app/test-eventdev/evt_options.c | 52 +++
app/test-eventdev/evt_options.h | 4 +
app/test-eventdev/test_pipeline_atq.c | 310 +++++++++++++--
app/test-eventdev/test_pipeline_common.c | 77 +++-
app/test-eventdev/test_pipeline_common.h | 18 +
app/test-eventdev/test_pipeline_queue.c | 320 +++++++++++++--
.../prog_guide/event_ethernet_rx_adapter.rst | 38 ++
.../prog_guide/event_ethernet_tx_adapter.rst | 12 +
doc/guides/prog_guide/eventdev.rst | 36 +-
doc/guides/tools/testeventdev.rst | 28 ++
lib/librte_eventdev/eventdev_pmd.h | 60 ++-
.../rte_event_eth_rx_adapter.c | 367 +++++++++++++++++-
.../rte_event_eth_rx_adapter.h | 93 +++++
.../rte_event_eth_tx_adapter.c | 66 +++-
lib/librte_eventdev/rte_eventdev.c | 11 +-
lib/librte_eventdev/rte_eventdev.h | 145 ++++++-
lib/librte_eventdev/version.map | 5 +
18 files changed, 1560 insertions(+), 86 deletions(-)
--
2.17.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH 7/7] eventdev: fix ABI breakage due to event vector
2021-02-20 22:09 3% [dpdk-dev] [PATCH 0/7] Introduce event vectorization pbhagavatula
@ 2021-02-20 22:09 5% ` pbhagavatula
0 siblings, 0 replies; 200+ results
From: pbhagavatula @ 2021-02-20 22:09 UTC (permalink / raw)
To: jerinj, jay.jayatheerthan, erik.g.carrillo, abhinandan.gujjar,
timothy.mcdaniel, hemant.agrawal, harry.van.haaren,
mattias.ronnblom, liang.j.ma, Ray Kinsella, Neil Horman
Cc: dev, Pavan Nikhilesh
From: Pavan Nikhilesh <pbhagavatula@marvell.com>
Fix ABI breakage due to event vector configuration by moving
the vector configuration into a new structure and having a separate
function for enabling the vector config on a given ethernet device and
queue pair.
This vector config and function can be merged to queue config in
v21.11.
Fixes: 44c81670cf0a ("eventdev: introduce event vector Rx capability")
Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
---
app/test-eventdev/test_pipeline_common.c | 16 +-
lib/librte_eventdev/eventdev_pmd.h | 29 +++
.../rte_event_eth_rx_adapter.c | 168 ++++++++++++------
.../rte_event_eth_rx_adapter.h | 27 +++
lib/librte_eventdev/version.map | 1 +
5 files changed, 184 insertions(+), 57 deletions(-)
diff --git a/app/test-eventdev/test_pipeline_common.c b/app/test-eventdev/test_pipeline_common.c
index 89f73be86..9aeefdd5f 100644
--- a/app/test-eventdev/test_pipeline_common.c
+++ b/app/test-eventdev/test_pipeline_common.c
@@ -331,6 +331,7 @@ pipeline_event_rx_adapter_setup(struct evt_options *opt, uint8_t stride,
uint16_t prod;
struct rte_mempool *vector_pool = NULL;
struct rte_event_eth_rx_adapter_queue_conf queue_conf;
+ struct rte_event_eth_rx_adapter_event_vector_config vec_conf;
memset(&queue_conf, 0,
sizeof(struct rte_event_eth_rx_adapter_queue_conf));
@@ -360,12 +361,8 @@ pipeline_event_rx_adapter_setup(struct evt_options *opt, uint8_t stride,
}
if (opt->ena_vector) {
if (cap & RTE_EVENT_ETH_RX_ADAPTER_CAP_EVENT_VECTOR) {
- queue_conf.vector_sz = opt->vector_size;
- queue_conf.vector_timeout_ns =
- opt->vector_tmo_nsec;
queue_conf.rx_queue_flags |=
RTE_EVENT_ETH_RX_ADAPTER_QUEUE_EVENT_VECTOR;
- queue_conf.vector_mp = vector_pool;
} else {
evt_err("Rx adapter doesn't support event vector");
return -EINVAL;
@@ -385,6 +382,17 @@ pipeline_event_rx_adapter_setup(struct evt_options *opt, uint8_t stride,
return ret;
}
+ if (opt->ena_vector) {
+ vec_conf.vector_sz = opt->vector_size;
+ vec_conf.vector_timeout_ns = opt->vector_tmo_nsec;
+ vec_conf.vector_mp = vector_pool;
+ if (rte_event_eth_rx_adapter_queue_event_vector_config(
+ prod, prod, -1, &vec_conf) < 0) {
+ evt_err("Failed to configure event vectorization for Rx adapter");
+ return -EINVAL;
+ }
+ }
+
if (!(cap & RTE_EVENT_ETH_RX_ADAPTER_CAP_INTERNAL_PORT)) {
uint32_t service_id = -1U;
diff --git a/lib/librte_eventdev/eventdev_pmd.h b/lib/librte_eventdev/eventdev_pmd.h
index 60bfaebc0..d79dfd612 100644
--- a/lib/librte_eventdev/eventdev_pmd.h
+++ b/lib/librte_eventdev/eventdev_pmd.h
@@ -667,6 +667,32 @@ typedef int (*eventdev_eth_rx_adapter_vector_limits_get_t)(
const struct rte_eventdev *dev, const struct rte_eth_dev *eth_dev,
struct rte_event_eth_rx_adapter_vector_limits *limits);
+struct rte_event_eth_rx_adapter_event_vector_config;
+/**
+ * Enable event vector on an given Rx queue of a ethernet devices belonging to
+ * the Rx adapter.
+ *
+ * @param dev
+ * Event device pointer
+ *
+ * @param eth_dev
+ * Ethernet device pointer
+ *
+ * @param rx_queue_id
+ * The Rx queue identifier
+ *
+ * @param config
+ * Pointer to the event vector configuration structure.
+ *
+ * @return
+ * - 0: Success.
+ * - <0: Error code returned by the driver function.
+ */
+typedef int (*eventdev_eth_rx_adapter_event_vector_config_t)(
+ const struct rte_eventdev *dev, const struct rte_eth_dev *eth_dev,
+ int32_t rx_queue_id,
+ const struct rte_event_eth_rx_adapter_event_vector_config *config);
+
typedef uint32_t rte_event_pmd_selftest_seqn_t;
extern int rte_event_pmd_selftest_seqn_dynfield_offset;
@@ -1092,6 +1118,9 @@ struct rte_eventdev_ops {
eventdev_eth_rx_adapter_vector_limits_get_t
eth_rx_adapter_vector_limits_get;
/**< Get event vector limits for the Rx adapter */
+ eventdev_eth_rx_adapter_event_vector_config_t
+ eth_rx_adapter_event_vector_config;
+ /**< Configure Rx adapter with event vector */
eventdev_timer_adapter_caps_get_t timer_adapter_caps_get;
/**< Get timer adapter capabilities */
diff --git a/lib/librte_eventdev/rte_event_eth_rx_adapter.c b/lib/librte_eventdev/rte_event_eth_rx_adapter.c
index a1990637f..c71990078 100644
--- a/lib/librte_eventdev/rte_event_eth_rx_adapter.c
+++ b/lib/librte_eventdev/rte_event_eth_rx_adapter.c
@@ -1882,25 +1882,6 @@ rxa_add_queue(struct rte_event_eth_rx_adapter *rx_adapter,
} else
qi_ev->flow_id = 0;
- if (conf->rx_queue_flags &
- RTE_EVENT_ETH_RX_ADAPTER_QUEUE_EVENT_VECTOR) {
- queue_info->ena_vector = 1;
- qi_ev->event_type = RTE_EVENT_TYPE_ETH_RX_ADAPTER_VECTOR;
- rxa_set_vector_data(queue_info, conf->vector_sz,
- conf->vector_timeout_ns, conf->vector_mp,
- rx_queue_id, dev_info->dev->data->port_id);
- rx_adapter->ena_vector = 1;
- rx_adapter->vector_tmo_ticks =
- rx_adapter->vector_tmo_ticks
- ? RTE_MIN(queue_info->vector_data
- .vector_timeout_ticks,
- rx_adapter->vector_tmo_ticks)
- : queue_info->vector_data.vector_timeout_ticks;
- rx_adapter->vector_tmo_ticks <<= 1;
- TAILQ_INIT(&rx_adapter->vector_list);
- rx_adapter->prev_expiry_ts = 0;
- }
-
rxa_update_queue(rx_adapter, dev_info, rx_queue_id, 1);
if (rxa_polled_queue(dev_info, rx_queue_id)) {
rx_adapter->num_rx_polled += !pollq;
@@ -1926,6 +1907,44 @@ rxa_add_queue(struct rte_event_eth_rx_adapter *rx_adapter,
}
}
+static void
+rxa_sw_event_vector_configure(
+ struct rte_event_eth_rx_adapter *rx_adapter, uint16_t eth_dev_id,
+ int rx_queue_id,
+ const struct rte_event_eth_rx_adapter_event_vector_config *config)
+{
+ struct eth_device_info *dev_info = &rx_adapter->eth_devices[eth_dev_id];
+ struct eth_rx_queue_info *queue_info;
+ struct rte_event *qi_ev;
+
+ if (rx_queue_id == -1) {
+ uint16_t nb_rx_queues;
+ uint16_t i;
+
+ nb_rx_queues = dev_info->dev->data->nb_rx_queues;
+ for (i = 0; i < nb_rx_queues; i++)
+ rxa_sw_event_vector_configure(rx_adapter, eth_dev_id, i,
+ config);
+ return;
+ }
+
+ queue_info = &dev_info->rx_queue[rx_queue_id];
+ qi_ev = (struct rte_event *)&queue_info->event;
+ queue_info->ena_vector = 1;
+ qi_ev->event_type = RTE_EVENT_TYPE_ETH_RX_ADAPTER_VECTOR;
+ rxa_set_vector_data(queue_info, config->vector_sz,
+ config->vector_timeout_ns, config->vector_mp,
+ rx_queue_id, dev_info->dev->data->port_id);
+ rx_adapter->ena_vector = 1;
+ rx_adapter->vector_tmo_ticks =
+ rx_adapter->vector_tmo_ticks ?
+ RTE_MIN(config->vector_timeout_ns << 1,
+ rx_adapter->vector_tmo_ticks) :
+ config->vector_timeout_ns << 1;
+ rx_adapter->prev_expiry_ts = 0;
+ TAILQ_INIT(&rx_adapter->vector_list);
+}
+
static int rxa_sw_add(struct rte_event_eth_rx_adapter *rx_adapter,
uint16_t eth_dev_id,
int rx_queue_id,
@@ -2239,7 +2258,6 @@ rte_event_eth_rx_adapter_queue_add(uint8_t id,
struct rte_event_eth_rx_adapter *rx_adapter;
struct rte_eventdev *dev;
struct eth_device_info *dev_info;
- struct rte_event_eth_rx_adapter_vector_limits limits;
RTE_EVENT_ETH_RX_ADAPTER_ID_VALID_OR_ERR_RET(id, -EINVAL);
RTE_ETH_VALID_PORTID_OR_ERR_RET(eth_dev_id, -EINVAL);
@@ -2276,39 +2294,6 @@ rte_event_eth_rx_adapter_queue_add(uint8_t id,
return -EINVAL;
}
- if (queue_conf->rx_queue_flags &
- RTE_EVENT_ETH_RX_ADAPTER_QUEUE_EVENT_VECTOR) {
- ret = rte_event_eth_rx_adapter_vector_limits_get(
- rx_adapter->eventdev_id, eth_dev_id, &limits);
- if (ret < 0) {
- RTE_EDEV_LOG_ERR("Failed to get event device vector limits,"
- " eth port: %" PRIu16
- " adapter id: %" PRIu8,
- eth_dev_id, id);
- return -EINVAL;
- }
- if (queue_conf->vector_sz < limits.min_sz ||
- queue_conf->vector_sz > limits.max_sz ||
- queue_conf->vector_timeout_ns < limits.min_timeout_ns ||
- queue_conf->vector_timeout_ns > limits.max_timeout_ns ||
- queue_conf->vector_mp == NULL) {
- RTE_EDEV_LOG_ERR("Invalid event vector configuration,"
- " eth port: %" PRIu16
- " adapter id: %" PRIu8,
- eth_dev_id, id);
- return -EINVAL;
- }
- if (queue_conf->vector_mp->elt_size <
- (sizeof(struct rte_event_vector) +
- (sizeof(uintptr_t) * queue_conf->vector_sz))) {
- RTE_EDEV_LOG_ERR("Invalid event vector configuration,"
- " eth port: %" PRIu16
- " adapter id: %" PRIu8,
- eth_dev_id, id);
- return -EINVAL;
- }
- }
-
if ((cap & RTE_EVENT_ETH_RX_ADAPTER_CAP_MULTI_EVENTQ) == 0 &&
(rx_queue_id != -1)) {
RTE_EDEV_LOG_ERR("Rx queues can only be connected to single "
@@ -2502,6 +2487,83 @@ rte_event_eth_rx_adapter_queue_del(uint8_t id, uint16_t eth_dev_id,
return ret;
}
+int
+rte_event_eth_rx_adapter_queue_event_vector_config(
+ uint8_t id, uint16_t eth_dev_id, int32_t rx_queue_id,
+ struct rte_event_eth_rx_adapter_event_vector_config *config)
+{
+ struct rte_event_eth_rx_adapter_vector_limits limits;
+ struct rte_event_eth_rx_adapter *rx_adapter;
+ struct rte_eventdev *dev;
+ uint32_t cap;
+ int ret;
+
+ RTE_EVENT_ETH_RX_ADAPTER_ID_VALID_OR_ERR_RET(id, -EINVAL);
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(eth_dev_id, -EINVAL);
+
+ rx_adapter = rxa_id_to_adapter(id);
+ if ((rx_adapter == NULL) || (config == NULL))
+ return -EINVAL;
+
+ dev = &rte_eventdevs[rx_adapter->eventdev_id];
+ ret = rte_event_eth_rx_adapter_caps_get(rx_adapter->eventdev_id,
+ eth_dev_id, &cap);
+ if (ret) {
+ RTE_EDEV_LOG_ERR("Failed to get adapter caps edev %" PRIu8
+ "eth port %" PRIu16,
+ id, eth_dev_id);
+ return ret;
+ }
+
+ if (!(cap & RTE_EVENT_ETH_RX_ADAPTER_CAP_EVENT_VECTOR)) {
+ RTE_EDEV_LOG_ERR("Event vectorization is not supported,"
+ " eth port: %" PRIu16 " adapter id: %" PRIu8,
+ eth_dev_id, id);
+ return -EINVAL;
+ }
+
+ ret = rte_event_eth_rx_adapter_vector_limits_get(
+ rx_adapter->eventdev_id, eth_dev_id, &limits);
+ if (ret) {
+ RTE_EDEV_LOG_ERR("Failed to get vector limits edev %" PRIu8
+ "eth port %" PRIu16,
+ rx_adapter->eventdev_id, eth_dev_id);
+ return ret;
+ }
+
+ if (config->vector_sz < limits.min_sz ||
+ config->vector_sz > limits.max_sz ||
+ config->vector_timeout_ns < limits.min_timeout_ns ||
+ config->vector_timeout_ns > limits.max_timeout_ns ||
+ config->vector_mp == NULL) {
+ RTE_EDEV_LOG_ERR("Invalid event vector configuration,"
+ " eth port: %" PRIu16 " adapter id: %" PRIu8,
+ eth_dev_id, id);
+ return -EINVAL;
+ }
+ if (config->vector_mp->elt_size <
+ (sizeof(struct rte_event_vector) +
+ (sizeof(uintptr_t) * config->vector_sz))) {
+ RTE_EDEV_LOG_ERR("Invalid event vector configuration,"
+ " eth port: %" PRIu16 " adapter id: %" PRIu8,
+ eth_dev_id, id);
+ return -EINVAL;
+ }
+
+ if (cap & RTE_EVENT_ETH_RX_ADAPTER_CAP_INTERNAL_PORT) {
+ RTE_FUNC_PTR_OR_ERR_RET(
+ *dev->dev_ops->eth_rx_adapter_event_vector_config,
+ -ENOTSUP);
+ ret = dev->dev_ops->eth_rx_adapter_event_vector_config(
+ dev, &rte_eth_devices[eth_dev_id], rx_queue_id, config);
+ } else {
+ rxa_sw_event_vector_configure(rx_adapter, eth_dev_id,
+ rx_queue_id, config);
+ }
+
+ return ret;
+}
+
int
rte_event_eth_rx_adapter_vector_limits_get(
uint8_t dev_id, uint16_t eth_port_id,
diff --git a/lib/librte_eventdev/rte_event_eth_rx_adapter.h b/lib/librte_eventdev/rte_event_eth_rx_adapter.h
index 4bdb38f08..ceef6d565 100644
--- a/lib/librte_eventdev/rte_event_eth_rx_adapter.h
+++ b/lib/librte_eventdev/rte_event_eth_rx_adapter.h
@@ -171,6 +171,9 @@ struct rte_event_eth_rx_adapter_queue_conf {
* The event adapter sets ev.event_type to RTE_EVENT_TYPE_ETHDEV in the
* enqueued event.
*/
+};
+
+struct rte_event_eth_rx_adapter_event_vector_config {
uint16_t vector_sz;
/**<
* Indicates the maximum number for mbufs to combine and form a vector.
@@ -418,6 +421,30 @@ int rte_event_eth_rx_adapter_queue_add(uint8_t id,
int rte_event_eth_rx_adapter_queue_del(uint8_t id, uint16_t eth_dev_id,
int32_t rx_queue_id);
+/**
+ * Configure event vectorization for a given ethernet device queue, that has
+ * been added to a event eth Rx adapter.
+ *
+ * @param id
+ * The identifier of the ethernet Rx event adapter.
+ *
+ * @param eth_dev_id
+ * The identifier of the ethernet device.
+ *
+ * @param rx_queue_id
+ * Ethernet device receive queue index.
+ * If rx_queue_id is -1, then all Rx queues configured for the ethernet device
+ * are configured with event vectorization.
+ *
+ * @return
+ * - 0: Success, Receive queue configured correctly.
+ * - <0: Error code on failure.
+ */
+__rte_experimental
+int rte_event_eth_rx_adapter_queue_event_vector_config(
+ uint8_t id, uint16_t eth_dev_id, int32_t rx_queue_id,
+ struct rte_event_eth_rx_adapter_event_vector_config *config);
+
/**
* Start ethernet Rx event adapter
*
diff --git a/lib/librte_eventdev/version.map b/lib/librte_eventdev/version.map
index 34c1c830e..902df0ae3 100644
--- a/lib/librte_eventdev/version.map
+++ b/lib/librte_eventdev/version.map
@@ -142,6 +142,7 @@ EXPERIMENTAL {
#added in 21.05
rte_event_vector_pool_create;
rte_event_eth_rx_adapter_vector_limits_get;
+ rte_event_eth_rx_adapter_queue_event_vector_config;
};
INTERNAL {
--
2.17.1
^ permalink raw reply [relevance 5%]
* [dpdk-dev] [PATCH 7/7] eal/windows: do not expose POSIX symbols
@ 2021-02-20 23:29 3% ` Dmitry Kozlyuk
1 sibling, 0 replies; 200+ results
From: Dmitry Kozlyuk @ 2021-02-20 23:29 UTC (permalink / raw)
To: dev
Cc: Tyler Retzlaff, Nick Connolly, Dmitry Kozlyuk, Bruce Richardson,
Narcisa Ana Maria Vasile, Dmitry Malloy, Pallavi Kadam
Exposing POSIX symbols could break consumer POSIX compatibility code.
* Make renaming of close() and unlink() private to EAL.
* Remove renaming of strncasecmp(), strtok_r(), and sleep()
in favor of using EAL wrappers. Similarly remove PATH_MAX macro.
* Replace index(3p), which is not available on Windows, with strchr(3),
as recommended by POSIX.1-2008. strerror_r() is only used inside EAL,
rename it only where it's needed. Same for asprintf(), it has an
internal EAL wrapper and is removed from public API.
Signed-off-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
---
doc/guides/rel_notes/release_21_05.rst | 9 ++
lib/librte_eal/common/eal_common_errno.c | 4 +
lib/librte_eal/common/eal_common_options.c | 2 +-
lib/librte_eal/common/eal_private.h | 5 ++
lib/librte_eal/freebsd/include/rte_os.h | 4 +-
lib/librte_eal/linux/include/rte_os.h | 4 +-
lib/librte_eal/windows/include/rte_os.h | 99 ++--------------------
7 files changed, 29 insertions(+), 98 deletions(-)
diff --git a/doc/guides/rel_notes/release_21_05.rst b/doc/guides/rel_notes/release_21_05.rst
index 5aa9ed7db..6380dfa53 100644
--- a/doc/guides/rel_notes/release_21_05.rst
+++ b/doc/guides/rel_notes/release_21_05.rst
@@ -84,6 +84,15 @@ API Changes
Also, make sure to start the actual text at the margin.
=======================================================
+* eal/windows: Removed POSIX symbols from EAL headers. Exposing POSIX symbols
+ has been incorrect and could conflict with consumer POSIX implementations.
+ Wrappers are provided for
+ ``strtok_r(3p)`` (``rte_strtok``),
+ ``strncasecmp(3p)`` (``rte_strncasecmp``),
+ ``sleep(3p)`` (``rte_thread_sleep``),
+ ``PATH_MAX`` (``RTE_PATH_MAX``).
+ Removed are ``strerror_r(3p)`` and ``asprintf(3p)``.
+
ABI Changes
-----------
diff --git a/lib/librte_eal/common/eal_common_errno.c b/lib/librte_eal/common/eal_common_errno.c
index 2a10fb823..536eea0c3 100644
--- a/lib/librte_eal/common/eal_common_errno.c
+++ b/lib/librte_eal/common/eal_common_errno.c
@@ -15,6 +15,10 @@
#include <rte_errno.h>
#include <rte_string_fns.h>
+#ifdef RTE_EXEC_ENV_WINDOWS
+#define strerror_r(a, b, c) strerror_s(b, c, a)
+#endif
+
RTE_DEFINE_PER_LCORE(int, _rte_errno);
const char *
diff --git a/lib/librte_eal/common/eal_common_options.c b/lib/librte_eal/common/eal_common_options.c
index 275f879d7..fd3b22e8a 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -1936,7 +1936,7 @@ eal_check_common_options(struct internal_config *internal_cfg)
RTE_LOG(ERR, EAL, "Invalid length of --" OPT_MBUF_POOL_OPS_NAME" option\n");
return -1;
}
- if (index(eal_get_hugefile_prefix(), '%') != NULL) {
+ if (strchr(eal_get_hugefile_prefix(), '%') != NULL) {
RTE_LOG(ERR, EAL, "Invalid char, '%%', in --"OPT_FILE_PREFIX" "
"option\n");
return -1;
diff --git a/lib/librte_eal/common/eal_private.h b/lib/librte_eal/common/eal_private.h
index a5d9c5123..860551661 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -756,4 +756,9 @@ int eal_asprintf(char **buffer, const char *format, ...);
#define eal_asprintf asprintf
#endif
+#ifdef RTE_EXEC_ENV_WINDOWS
+#define close _close
+#define unlink _unlink
+#endif
+
#endif /* _EAL_PRIVATE_H_ */
diff --git a/lib/librte_eal/freebsd/include/rte_os.h b/lib/librte_eal/freebsd/include/rte_os.h
index b37d59b5e..a5bf10021 100644
--- a/lib/librte_eal/freebsd/include/rte_os.h
+++ b/lib/librte_eal/freebsd/include/rte_os.h
@@ -6,9 +6,9 @@
#define _RTE_OS_H_
/**
- * This is header should contain any function/macro definition
+ * This header should contain any function/macro definition
* which are not supported natively or named differently in the
- * freebsd OS. Functions will be added in future releases.
+ * freebsd OS. It must not define symbols without "rte_" prefix.
*/
#include <pthread_np.h>
diff --git a/lib/librte_eal/linux/include/rte_os.h b/lib/librte_eal/linux/include/rte_os.h
index af7d052d9..04f510eec 100644
--- a/lib/librte_eal/linux/include/rte_os.h
+++ b/lib/librte_eal/linux/include/rte_os.h
@@ -6,9 +6,9 @@
#define _RTE_OS_H_
/**
- * This is header should contain any function/macro definition
+ * This header should contain any function/macro definition
* which are not supported natively or named differently in the
- * linux OS. Functions will be added in future releases.
+ * linux OS. It must not define symbols without "rte_" prefix.
*/
#include <sched.h>
diff --git a/lib/librte_eal/windows/include/rte_os.h b/lib/librte_eal/windows/include/rte_os.h
index edca11bd2..9c9c31214 100644
--- a/lib/librte_eal/windows/include/rte_os.h
+++ b/lib/librte_eal/windows/include/rte_os.h
@@ -6,15 +6,11 @@
#define _RTE_OS_H_
/**
- * This is header should contain any function/macro definition
- * which are not supported natively or named differently in the
- * Windows OS. It must not include Windows-specific headers.
+ * This header should contain any function/macro definition
+ * which are not supported natively or named differently in Windows OS.
*/
-#include <stdarg.h>
-#include <stdio.h>
#include <stdlib.h>
-#include <string.h>
#ifdef __cplusplus
extern "C" {
@@ -22,101 +18,18 @@ extern "C" {
#define RTE_PATH_MAX _MAX_PATH
-/* limits.h replacement, value as in <windows.h> */
-#ifndef PATH_MAX
-#define PATH_MAX _MAX_PATH
-#endif
-
-#ifndef sleep
-#define sleep(x) Sleep(1000 * (x))
-#endif
-
-#ifndef strerror_r
-#define strerror_r(a, b, c) strerror_s(b, c, a)
-#endif
-
-#ifndef strdup
-/* strdup is deprecated in Microsoft libc and _strdup is preferred */
-#define strdup(str) _strdup(str)
-#endif
-
-#ifndef strtok_r
-#define strtok_r(str, delim, saveptr) strtok_s(str, delim, saveptr)
-#endif
-
-#ifndef index
-#define index(a, b) strchr(a, b)
-#endif
-
-#ifndef rindex
-#define rindex(a, b) strrchr(a, b)
-#endif
-
-#ifndef strncasecmp
-#define strncasecmp(s1, s2, count) _strnicmp(s1, s2, count)
-#endif
-
-#ifndef close
-#define close _close
-#endif
-
-#ifndef unlink
-#define unlink _unlink
-#endif
-
/* cpu_set macros implementation */
#define RTE_CPU_AND(dst, src1, src2) CPU_AND(dst, src1, src2)
#define RTE_CPU_OR(dst, src1, src2) CPU_OR(dst, src1, src2)
#define RTE_CPU_FILL(set) CPU_FILL(set)
#define RTE_CPU_NOT(dst, src) CPU_NOT(dst, src)
-/* as in <windows.h> */
+/* This is an exception without "rte_" prefix, because Windows does have
+ * ssize_t, but it's defined in <windows.h> which we avoid to expose.
+ * If ssize_t is defined in user code, it necessarily has the same type.
+ */
typedef long long ssize_t;
-#ifndef RTE_TOOLCHAIN_GCC
-
-static inline int
-asprintf(char **buffer, const char *format, ...)
-{
- int size, ret;
- va_list arg;
-
- va_start(arg, format);
- size = vsnprintf(NULL, 0, format, arg);
- va_end(arg);
- if (size < 0)
- return -1;
- size++;
-
- *buffer = (char *)malloc(size);
- if (*buffer == NULL)
- return -1;
-
- va_start(arg, format);
- ret = vsnprintf(*buffer, size, format, arg);
- va_end(arg);
- if (ret != size - 1) {
- free(*buffer);
- return -1;
- }
- return ret;
-}
-
-static inline const char *
-eal_strerror(int code)
-{
- static char buffer[128];
-
- strerror_s(buffer, sizeof(buffer), code);
- return buffer;
-}
-
-#ifndef strerror
-#define strerror eal_strerror
-#endif
-
-#endif /* RTE_TOOLCHAIN_GCC */
-
#ifdef __cplusplus
}
#endif
--
2.29.2
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v2 7/7] eal/windows: do not expose POSIX symbols
@ 2021-02-21 1:28 3% ` Dmitry Kozlyuk
1 sibling, 0 replies; 200+ results
From: Dmitry Kozlyuk @ 2021-02-21 1:28 UTC (permalink / raw)
To: dev
Cc: Tyler Retzlaff, Nick Connolly, Dmitry Kozlyuk, Bruce Richardson,
Narcisa Ana Maria Vasile, Dmitry Malloy, Pallavi Kadam
Exposing POSIX symbols could break consumer POSIX compatibility code.
* Make renaming of close() and unlink() private to EAL.
* Remove renaming of strncasecmp(), strtok_r(), and sleep()
in favor of using EAL wrappers. Similarly remove PATH_MAX macro.
* Replace index(3p), which is not available on Windows, with strchr(3),
as recommended by POSIX.1-2008. strerror_r() is only used inside EAL,
rename it only where it's needed. Same for asprintf(), it has an
internal EAL wrapper and is removed from public API.
Signed-off-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
---
doc/guides/rel_notes/release_21_05.rst | 9 ++
lib/librte_eal/common/eal_common_errno.c | 4 +
lib/librte_eal/common/eal_common_options.c | 2 +-
lib/librte_eal/common/eal_private.h | 5 ++
lib/librte_eal/freebsd/include/rte_os.h | 4 +-
lib/librte_eal/linux/include/rte_os.h | 4 +-
lib/librte_eal/windows/include/rte_os.h | 99 ++--------------------
7 files changed, 29 insertions(+), 98 deletions(-)
diff --git a/doc/guides/rel_notes/release_21_05.rst b/doc/guides/rel_notes/release_21_05.rst
index 5aa9ed7db..6380dfa53 100644
--- a/doc/guides/rel_notes/release_21_05.rst
+++ b/doc/guides/rel_notes/release_21_05.rst
@@ -84,6 +84,15 @@ API Changes
Also, make sure to start the actual text at the margin.
=======================================================
+* eal/windows: Removed POSIX symbols from EAL headers. Exposing POSIX symbols
+ has been incorrect and could conflict with consumer POSIX implementations.
+ Wrappers are provided for
+ ``strtok_r(3p)`` (``rte_strtok``),
+ ``strncasecmp(3p)`` (``rte_strncasecmp``),
+ ``sleep(3p)`` (``rte_thread_sleep``),
+ ``PATH_MAX`` (``RTE_PATH_MAX``).
+ Removed are ``strerror_r(3p)`` and ``asprintf(3p)``.
+
ABI Changes
-----------
diff --git a/lib/librte_eal/common/eal_common_errno.c b/lib/librte_eal/common/eal_common_errno.c
index 2a10fb823..536eea0c3 100644
--- a/lib/librte_eal/common/eal_common_errno.c
+++ b/lib/librte_eal/common/eal_common_errno.c
@@ -15,6 +15,10 @@
#include <rte_errno.h>
#include <rte_string_fns.h>
+#ifdef RTE_EXEC_ENV_WINDOWS
+#define strerror_r(a, b, c) strerror_s(b, c, a)
+#endif
+
RTE_DEFINE_PER_LCORE(int, _rte_errno);
const char *
diff --git a/lib/librte_eal/common/eal_common_options.c b/lib/librte_eal/common/eal_common_options.c
index 275f879d7..fd3b22e8a 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -1936,7 +1936,7 @@ eal_check_common_options(struct internal_config *internal_cfg)
RTE_LOG(ERR, EAL, "Invalid length of --" OPT_MBUF_POOL_OPS_NAME" option\n");
return -1;
}
- if (index(eal_get_hugefile_prefix(), '%') != NULL) {
+ if (strchr(eal_get_hugefile_prefix(), '%') != NULL) {
RTE_LOG(ERR, EAL, "Invalid char, '%%', in --"OPT_FILE_PREFIX" "
"option\n");
return -1;
diff --git a/lib/librte_eal/common/eal_private.h b/lib/librte_eal/common/eal_private.h
index a5d9c5123..860551661 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -756,4 +756,9 @@ int eal_asprintf(char **buffer, const char *format, ...);
#define eal_asprintf asprintf
#endif
+#ifdef RTE_EXEC_ENV_WINDOWS
+#define close _close
+#define unlink _unlink
+#endif
+
#endif /* _EAL_PRIVATE_H_ */
diff --git a/lib/librte_eal/freebsd/include/rte_os.h b/lib/librte_eal/freebsd/include/rte_os.h
index b37d59b5e..a5bf10021 100644
--- a/lib/librte_eal/freebsd/include/rte_os.h
+++ b/lib/librte_eal/freebsd/include/rte_os.h
@@ -6,9 +6,9 @@
#define _RTE_OS_H_
/**
- * This is header should contain any function/macro definition
+ * This header should contain any function/macro definition
* which are not supported natively or named differently in the
- * freebsd OS. Functions will be added in future releases.
+ * freebsd OS. It must not define symbols without "rte_" prefix.
*/
#include <pthread_np.h>
diff --git a/lib/librte_eal/linux/include/rte_os.h b/lib/librte_eal/linux/include/rte_os.h
index af7d052d9..04f510eec 100644
--- a/lib/librte_eal/linux/include/rte_os.h
+++ b/lib/librte_eal/linux/include/rte_os.h
@@ -6,9 +6,9 @@
#define _RTE_OS_H_
/**
- * This is header should contain any function/macro definition
+ * This header should contain any function/macro definition
* which are not supported natively or named differently in the
- * linux OS. Functions will be added in future releases.
+ * linux OS. It must not define symbols without "rte_" prefix.
*/
#include <sched.h>
diff --git a/lib/librte_eal/windows/include/rte_os.h b/lib/librte_eal/windows/include/rte_os.h
index edca11bd2..9c9c31214 100644
--- a/lib/librte_eal/windows/include/rte_os.h
+++ b/lib/librte_eal/windows/include/rte_os.h
@@ -6,15 +6,11 @@
#define _RTE_OS_H_
/**
- * This is header should contain any function/macro definition
- * which are not supported natively or named differently in the
- * Windows OS. It must not include Windows-specific headers.
+ * This header should contain any function/macro definition
+ * which are not supported natively or named differently in Windows OS.
*/
-#include <stdarg.h>
-#include <stdio.h>
#include <stdlib.h>
-#include <string.h>
#ifdef __cplusplus
extern "C" {
@@ -22,101 +18,18 @@ extern "C" {
#define RTE_PATH_MAX _MAX_PATH
-/* limits.h replacement, value as in <windows.h> */
-#ifndef PATH_MAX
-#define PATH_MAX _MAX_PATH
-#endif
-
-#ifndef sleep
-#define sleep(x) Sleep(1000 * (x))
-#endif
-
-#ifndef strerror_r
-#define strerror_r(a, b, c) strerror_s(b, c, a)
-#endif
-
-#ifndef strdup
-/* strdup is deprecated in Microsoft libc and _strdup is preferred */
-#define strdup(str) _strdup(str)
-#endif
-
-#ifndef strtok_r
-#define strtok_r(str, delim, saveptr) strtok_s(str, delim, saveptr)
-#endif
-
-#ifndef index
-#define index(a, b) strchr(a, b)
-#endif
-
-#ifndef rindex
-#define rindex(a, b) strrchr(a, b)
-#endif
-
-#ifndef strncasecmp
-#define strncasecmp(s1, s2, count) _strnicmp(s1, s2, count)
-#endif
-
-#ifndef close
-#define close _close
-#endif
-
-#ifndef unlink
-#define unlink _unlink
-#endif
-
/* cpu_set macros implementation */
#define RTE_CPU_AND(dst, src1, src2) CPU_AND(dst, src1, src2)
#define RTE_CPU_OR(dst, src1, src2) CPU_OR(dst, src1, src2)
#define RTE_CPU_FILL(set) CPU_FILL(set)
#define RTE_CPU_NOT(dst, src) CPU_NOT(dst, src)
-/* as in <windows.h> */
+/* This is an exception without "rte_" prefix, because Windows does have
+ * ssize_t, but it's defined in <windows.h> which we avoid to expose.
+ * If ssize_t is defined in user code, it necessarily has the same type.
+ */
typedef long long ssize_t;
-#ifndef RTE_TOOLCHAIN_GCC
-
-static inline int
-asprintf(char **buffer, const char *format, ...)
-{
- int size, ret;
- va_list arg;
-
- va_start(arg, format);
- size = vsnprintf(NULL, 0, format, arg);
- va_end(arg);
- if (size < 0)
- return -1;
- size++;
-
- *buffer = (char *)malloc(size);
- if (*buffer == NULL)
- return -1;
-
- va_start(arg, format);
- ret = vsnprintf(*buffer, size, format, arg);
- va_end(arg);
- if (ret != size - 1) {
- free(*buffer);
- return -1;
- }
- return ret;
-}
-
-static inline const char *
-eal_strerror(int code)
-{
- static char buffer[128];
-
- strerror_s(buffer, sizeof(buffer), code);
- return buffer;
-}
-
-#ifndef strerror
-#define strerror eal_strerror
-#endif
-
-#endif /* RTE_TOOLCHAIN_GCC */
-
#ifdef __cplusplus
}
#endif
--
2.29.2
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v3 7/7] eal/windows: do not expose POSIX symbols
@ 2021-02-21 14:28 3% ` Dmitry Kozlyuk
0 siblings, 0 replies; 200+ results
From: Dmitry Kozlyuk @ 2021-02-21 14:28 UTC (permalink / raw)
To: dev
Cc: Tal Shnaiderman, Dmitry Kozlyuk, Bruce Richardson,
Narcisa Ana Maria Vasile, Dmitry Malloy, Pallavi Kadam
Exposing POSIX symbols could break consumer POSIX compatibility code.
* Make renaming of close() and unlink() private to EAL.
* Remove renaming of strncasecmp(), strtok_r(), and sleep()
in favor of using EAL wrappers. Similarly remove PATH_MAX macro.
* Replace index(3p), which is not available on Windows, with strchr(3),
as recommended by POSIX.1-2008. strerror_r() is only used inside EAL,
rename it only where it's needed. Same for asprintf(), it has an
internal EAL wrapper and is removed from public API.
Signed-off-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
---
doc/guides/rel_notes/release_21_05.rst | 9 ++
lib/librte_eal/common/eal_common_errno.c | 4 +
lib/librte_eal/common/eal_common_options.c | 2 +-
lib/librte_eal/common/eal_private.h | 5 ++
lib/librte_eal/freebsd/include/rte_os.h | 4 +-
lib/librte_eal/linux/include/rte_os.h | 4 +-
lib/librte_eal/windows/include/rte_os.h | 99 ++--------------------
7 files changed, 29 insertions(+), 98 deletions(-)
diff --git a/doc/guides/rel_notes/release_21_05.rst b/doc/guides/rel_notes/release_21_05.rst
index 5aa9ed7db..6380dfa53 100644
--- a/doc/guides/rel_notes/release_21_05.rst
+++ b/doc/guides/rel_notes/release_21_05.rst
@@ -84,6 +84,15 @@ API Changes
Also, make sure to start the actual text at the margin.
=======================================================
+* eal/windows: Removed POSIX symbols from EAL headers. Exposing POSIX symbols
+ has been incorrect and could conflict with consumer POSIX implementations.
+ Wrappers are provided for
+ ``strtok_r(3p)`` (``rte_strtok``),
+ ``strncasecmp(3p)`` (``rte_strncasecmp``),
+ ``sleep(3p)`` (``rte_thread_sleep``),
+ ``PATH_MAX`` (``RTE_PATH_MAX``).
+ Removed are ``strerror_r(3p)`` and ``asprintf(3p)``.
+
ABI Changes
-----------
diff --git a/lib/librte_eal/common/eal_common_errno.c b/lib/librte_eal/common/eal_common_errno.c
index 2a10fb823..536eea0c3 100644
--- a/lib/librte_eal/common/eal_common_errno.c
+++ b/lib/librte_eal/common/eal_common_errno.c
@@ -15,6 +15,10 @@
#include <rte_errno.h>
#include <rte_string_fns.h>
+#ifdef RTE_EXEC_ENV_WINDOWS
+#define strerror_r(a, b, c) strerror_s(b, c, a)
+#endif
+
RTE_DEFINE_PER_LCORE(int, _rte_errno);
const char *
diff --git a/lib/librte_eal/common/eal_common_options.c b/lib/librte_eal/common/eal_common_options.c
index 275f879d7..fd3b22e8a 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -1936,7 +1936,7 @@ eal_check_common_options(struct internal_config *internal_cfg)
RTE_LOG(ERR, EAL, "Invalid length of --" OPT_MBUF_POOL_OPS_NAME" option\n");
return -1;
}
- if (index(eal_get_hugefile_prefix(), '%') != NULL) {
+ if (strchr(eal_get_hugefile_prefix(), '%') != NULL) {
RTE_LOG(ERR, EAL, "Invalid char, '%%', in --"OPT_FILE_PREFIX" "
"option\n");
return -1;
diff --git a/lib/librte_eal/common/eal_private.h b/lib/librte_eal/common/eal_private.h
index a5d9c5123..860551661 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -756,4 +756,9 @@ int eal_asprintf(char **buffer, const char *format, ...);
#define eal_asprintf asprintf
#endif
+#ifdef RTE_EXEC_ENV_WINDOWS
+#define close _close
+#define unlink _unlink
+#endif
+
#endif /* _EAL_PRIVATE_H_ */
diff --git a/lib/librte_eal/freebsd/include/rte_os.h b/lib/librte_eal/freebsd/include/rte_os.h
index b37d59b5e..a5bf10021 100644
--- a/lib/librte_eal/freebsd/include/rte_os.h
+++ b/lib/librte_eal/freebsd/include/rte_os.h
@@ -6,9 +6,9 @@
#define _RTE_OS_H_
/**
- * This is header should contain any function/macro definition
+ * This header should contain any function/macro definition
* which are not supported natively or named differently in the
- * freebsd OS. Functions will be added in future releases.
+ * freebsd OS. It must not define symbols without "rte_" prefix.
*/
#include <pthread_np.h>
diff --git a/lib/librte_eal/linux/include/rte_os.h b/lib/librte_eal/linux/include/rte_os.h
index af7d052d9..04f510eec 100644
--- a/lib/librte_eal/linux/include/rte_os.h
+++ b/lib/librte_eal/linux/include/rte_os.h
@@ -6,9 +6,9 @@
#define _RTE_OS_H_
/**
- * This is header should contain any function/macro definition
+ * This header should contain any function/macro definition
* which are not supported natively or named differently in the
- * linux OS. Functions will be added in future releases.
+ * linux OS. It must not define symbols without "rte_" prefix.
*/
#include <sched.h>
diff --git a/lib/librte_eal/windows/include/rte_os.h b/lib/librte_eal/windows/include/rte_os.h
index edca11bd2..9c9c31214 100644
--- a/lib/librte_eal/windows/include/rte_os.h
+++ b/lib/librte_eal/windows/include/rte_os.h
@@ -6,15 +6,11 @@
#define _RTE_OS_H_
/**
- * This is header should contain any function/macro definition
- * which are not supported natively or named differently in the
- * Windows OS. It must not include Windows-specific headers.
+ * This header should contain any function/macro definition
+ * which are not supported natively or named differently in Windows OS.
*/
-#include <stdarg.h>
-#include <stdio.h>
#include <stdlib.h>
-#include <string.h>
#ifdef __cplusplus
extern "C" {
@@ -22,101 +18,18 @@ extern "C" {
#define RTE_PATH_MAX _MAX_PATH
-/* limits.h replacement, value as in <windows.h> */
-#ifndef PATH_MAX
-#define PATH_MAX _MAX_PATH
-#endif
-
-#ifndef sleep
-#define sleep(x) Sleep(1000 * (x))
-#endif
-
-#ifndef strerror_r
-#define strerror_r(a, b, c) strerror_s(b, c, a)
-#endif
-
-#ifndef strdup
-/* strdup is deprecated in Microsoft libc and _strdup is preferred */
-#define strdup(str) _strdup(str)
-#endif
-
-#ifndef strtok_r
-#define strtok_r(str, delim, saveptr) strtok_s(str, delim, saveptr)
-#endif
-
-#ifndef index
-#define index(a, b) strchr(a, b)
-#endif
-
-#ifndef rindex
-#define rindex(a, b) strrchr(a, b)
-#endif
-
-#ifndef strncasecmp
-#define strncasecmp(s1, s2, count) _strnicmp(s1, s2, count)
-#endif
-
-#ifndef close
-#define close _close
-#endif
-
-#ifndef unlink
-#define unlink _unlink
-#endif
-
/* cpu_set macros implementation */
#define RTE_CPU_AND(dst, src1, src2) CPU_AND(dst, src1, src2)
#define RTE_CPU_OR(dst, src1, src2) CPU_OR(dst, src1, src2)
#define RTE_CPU_FILL(set) CPU_FILL(set)
#define RTE_CPU_NOT(dst, src) CPU_NOT(dst, src)
-/* as in <windows.h> */
+/* This is an exception without "rte_" prefix, because Windows does have
+ * ssize_t, but it's defined in <windows.h> which we avoid to expose.
+ * If ssize_t is defined in user code, it necessarily has the same type.
+ */
typedef long long ssize_t;
-#ifndef RTE_TOOLCHAIN_GCC
-
-static inline int
-asprintf(char **buffer, const char *format, ...)
-{
- int size, ret;
- va_list arg;
-
- va_start(arg, format);
- size = vsnprintf(NULL, 0, format, arg);
- va_end(arg);
- if (size < 0)
- return -1;
- size++;
-
- *buffer = (char *)malloc(size);
- if (*buffer == NULL)
- return -1;
-
- va_start(arg, format);
- ret = vsnprintf(*buffer, size, format, arg);
- va_end(arg);
- if (ret != size - 1) {
- free(*buffer);
- return -1;
- }
- return ret;
-}
-
-static inline const char *
-eal_strerror(int code)
-{
- static char buffer[128];
-
- strerror_s(buffer, sizeof(buffer), code);
- return buffer;
-}
-
-#ifndef strerror
-#define strerror eal_strerror
-#endif
-
-#endif /* RTE_TOOLCHAIN_GCC */
-
#ifdef __cplusplus
}
#endif
--
2.29.2
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] Build errors due to duplicate version.map entries in librte_power
2021-02-15 19:18 3% [dpdk-dev] Build errors due to duplicate version.map entries in librte_power Aaron Conole
@ 2021-02-22 10:31 0% ` Juraj Linkeš
2021-02-22 19:50 0% ` Aaron Conole
0 siblings, 1 reply; 200+ results
From: Juraj Linkeš @ 2021-02-22 10:31 UTC (permalink / raw)
To: Aaron Conole, dev; +Cc: Bruce Richardson, David Hunt, Anatoly Burakov
This seems to have gone unnoticed.
lib/librte_power/version.map specifies rte_power_guest_channel_send_msg both under DPDK_21 and EXPERIMENTAL.
This is causing the clang cross-compile job to always fail with the error Aaron provided:
ld.lld: error: duplicate symbol 'rte_power_guest_channel_send_msg' in version script
Only the clang cross compile jobs are failing. This could be due to them using the LLVM linker (ld.lld) and the other clang jobs using the default linker.
I have two questions about this:
1. Is this a real failure?
2. If this is a real failure, should we also use ld.lld in the other clang jobs?
Thanks,
Juraj
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Aaron Conole
> Sent: Monday, February 15, 2021 8:18 PM
> To: dev@dpdk.org
> Cc: Bruce Richardson <bruce.richardson@intel.com>; David Hunt
> <david.hunt@intel.com>; Anatoly Burakov <anatoly.burakov@intel.com>
> Subject: [dpdk-dev] Build errors due to duplicate version.map entries in
> librte_power
>
> Greetings,
>
> During CI runs, I've noticed lots of failures from the Travis-CI side all related to
> librte_power/version.map containing some duplicate symbols. It seems commit
> 4d3892dcd77b ("power: make channel message functions public") made the
> following hunk:
>
> diff --git a/lib/librte_power/version.map b/lib/librte_power/version.map index
> 69ca9af616..13f0af3b2d 100644
> --- a/lib/librte_power/version.map
> +++ b/lib/librte_power/version.map
> @@ -34,4 +34,8 @@ EXPERIMENTAL {
> rte_power_guest_channel_receive_msg;
> rte_power_poll_stat_fetch;
> rte_power_poll_stat_update;
> +
> + # added in 21.02
> + rte_power_guest_channel_receive_msg;
> + rte_power_guest_channel_send_msg;
> };
>
>
> As can be seen, rte_power_guest_channel_receive_msg was added already (it's
> present in the hunk itself). The rte_power_guest_channel_send_msg function
> was added as part of 85ff364f3bd3 ("build: align symbols with global ABI
> version").
>
> I guess it may not be allowed to have duplicate symbols here, because in travis, I
> see (only for some builds):
>
> clang -o lib/librte_power.so.21.1
> 'lib/lib@@rte_power@sta/librte_power_rte_power.c.o'
> 'lib/lib@@rte_power@sta/librte_power_power_acpi_cpufreq.c.o'
> 'lib/lib@@rte_power@sta/librte_power_power_kvm_vm.c.o'
> 'lib/lib@@rte_power@sta/librte_power_guest_channel.c.o'
> 'lib/lib@@rte_power@sta/librte_power_rte_power_empty_poll.c.o'
> 'lib/lib@@rte_power@sta/librte_power_power_pstate_cpufreq.c.o'
> 'lib/lib@@rte_power@sta/librte_power_rte_power_pmd_mgmt.c.o'
> 'lib/lib@@rte_power@sta/librte_power_power_common.c.o' -Wl,--no-
> undefined -Wl,--as-needed -shared -fPIC -Wl,--start-group -Wl,-
> soname,librte_power.so.21 -Wl,--no-as-needed -pthread -lm -ldl
> lib/librte_eal.so.21.1 lib/librte_kvargs.so.21.1 lib/librte_telemetry.so.21.1
> lib/librte_timer.so.21.1 lib/librte_ethdev.so.21.1 lib/librte_net.so.21.1
> lib/librte_mbuf.so.21.1 lib/librte_mempool.so.21.1 lib/librte_ring.so.21.1
> lib/librte_meter.so.21.1 -Wl,--end-group -Wl,--version-
> script=/home/travis/build/ovsrobot/dpdk/lib/librte_power/version.map '-Wl,-
> rpath,$ORIGIN/' -Wl,-rpath-link,/home/travis/build/ovsrobot/dpdk/build/lib -
> target aarch64-linux-gnu -fuse-ld=lld --gcc-toolchain=/usr
>
> ld.lld: error: duplicate symbol 'rte_power_guest_channel_send_msg' in version
> script
>
> Thoughts?
>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] 20.11.1 patches review and test
@ 2021-02-22 15:09 1% luca.boccassi
2021-02-25 9:43 0% ` Christian Ehrhardt
` (3 more replies)
0 siblings, 4 replies; 200+ results
From: luca.boccassi @ 2021-02-22 15:09 UTC (permalink / raw)
To: stable
Cc: dev, Abhishek Marathe, Akhil Goyal, Ali Alnubani,
benjamin.walker, David Christensen, hariprasad.govindharajan,
Hemant Agrawal, Ian Stokes, Jerin Jacob, John McNamara,
Ju-Hyoung Lee, Kevin Traynor, Luca Boccassi, Pei Zhang, pingx.yu,
qian.q.xu, Raslan Darawsheh, Thomas Monjalon, yuan.peng,
zhaoyan.chen
Hi all,
Here is a list of patches targeted for stable release 20.11.1.
The planned date for the final release is the 8th of March.
Please help with testing and validation of your use cases and report
any issues/results with reply-all to this mail. For the final release
the fixes and reported validations will be added to the release notes.
A release candidate tarball can be found at:
https://dpdk.org/browse/dpdk-stable/tag/?id=v20.11.1-rc1
These patches are located at branch 20.11 of dpdk-stable repo:
https://dpdk.org/browse/dpdk-stable/
Thanks.
Luca Boccassi
---
Ajit Khaparde (3):
net/bnxt: fix cleanup on mutex init failure
net/bnxt: fix format specifier for unsigned int
net/bnxt: fix freeing mbuf
Alexander Kozyrev (4):
net/mlx5: fix mbuf freeing in vectorized MPRQ
net/mlx5: fix flow tag decompression
net/mlx5: check FW miniCQE format capabilities
net/mlx5: fix miniCQE configuration for Verbs
Alvin Zhang (9):
net/ixgbe: detect failed VF MTU set
net/i40e: fix Rx bytes statistics
net/iavf: fix queue pairs configuration
doc: fix RSS flow description in i40e guide
net/i40e: fix returned code for RSS hardware failure
net/ice: fix RSS lookup table initialization
test: fix buffer overflow in Tx burst
net/ixgbe: fix configuration of max frame size
app/testpmd: fix key for RSS flow rule
Amit Bernstein (1):
net/ena: fix Tx doorbell statistics
Anatoly Burakov (1):
fbarray: fix overlap check
Andrew Boyer (5):
net/ionic: do minor logging fixups
net/ionic: fix link speed and autonegotiation
net/ionic: allow separate L3 and L4 checksum offload
net/ionic: fix up function attribute tags
net/ionic: fix address handling in Tx
Ankur Dwivedi (1):
test/event_crypto: set cipher operation in transform
Ashish Sadanandan (1):
mbuf: add C++ include guard for dynamic fields header
Balazs Nemeth (1):
net/qede: fix promiscuous enable
Beilei Xing (2):
net/i40e: fix global register recovery
net/i40e: fix flex payload rule conflict
Bernard Iremonger (1):
doc: fix QinQ flow rules in testpmd guide
Bruce Richardson (29):
ethdev: avoid blocking telemetry for link status
build: provide suitable error for "both" libraries option
eal: fix reciprocal header include
telemetry: fix missing header include
ethdev: fix missing header include
net: fix missing header include
mbuf: fix missing header include
bitrate: fix missing header include
rib: fix missing header includes
vhost: fix missing header includes
ipsec: fix missing header include
fib: fix missing header includes
table: fix missing header include
pipeline: fix missing header includes
metrics: fix variable declaration in header
node: fix missing header include
app: fix build with extra include paths
build: force pkg-config for dependency detection
power: create guest channel public header file
power: make channel message functions public
power: rename public structs
power: rename constants
power: export guest channel header file
power: clean up includes
eal: fix MCS lock header include
eal: fix internal ABI tag with clang
power: fix missing header includes
rib: fix missing header include
eal: fix automatic loading of drivers as shared libs
Chengchang Tang (7):
net/hns3: fix register length when dumping registers
net/hns3: fix data overwriting during register dump
net/hns3: fix dump register out of range
net/hns3: fix interrupt resources in Rx interrupt mode
net/hns3: fix firmware exceptions by concurrent commands
net/hns3: fix VF reset on mailbox failure
net/hns3: fix stats flip overflow
Chengwen Feng (3):
net/hns3: fix VF query link status in dev init
net/hns3: remove MPLS from supported flow items
net/hns3: fix flow director rule residue on malloc failure
Ciara Power (3):
app/crypto-perf: fix spelling in output
app/crypto-perf: fix latency CSV output
app/crypto-perf: fix CSV output format
Cristian Dumitrescu (1):
examples/pipeline: fix CLI parsing crash
Dapeng Yu (4):
net/ixgbe: fix flex bytes flow director rule
net/ice: check Rx queue number on RSS init
net/ixgbe: disable NFS filtering
app/testpmd: avoid exit without terminal restore
David Marchand (3):
net/hinic: restore vectorised code
examples/pipeline: fix VXLAN script permission
mbuf: remove unneeded atomic generic header include
Dekel Peled (8):
net/mlx5: fix shared age action validation
net/mlx5: fix hairpin flow split decision
net/mlx5: fix flow split combined with counter
net/mlx5: fix flow split combined with age action
net/mlx5: fix shared RSS translation and cleanup
app/testpmd: support shared age action query
net/mlx5: fix shared RSS capability check
net/mlx5: validate hash Rx queue pointer
Dmitry Kozlyuk (4):
eal/windows: fix build with MinGW-w64 8
bus/pci: fix build with MinGW-w64 8
bus/pci: fix hardware ID limit on Windows
build: fix linker flags on Windows
Eugeny Parshutin (1):
doc: add vtune profiling config to prog guide
Fan Zhang (1):
crypto/qat: fix digest in buffer
Fei Chen (1):
vhost: fix vid allocation race
Feifei Wang (7):
test/ring: reduce duration of performance tests
app/eventdev: adjust event count order for pipeline test
app/eventdev: remove redundant enqueue in burst Tx
examples/eventdev: check CPU core enabling
examples/eventdev: add info output for main core
examples/eventdev: move ethdev stop to the end
app/eventdev: fix SMP barrier in performance test
Ferruh Yigit (13):
app/procinfo: fix _filters stats reporting
app/procinfo: fix check on xstats-ids
app/procinfo: remove useless memset
app/procinfo: remove useless assignment
net/pcap: remove local variable shadowing outer one
net/bonding: remove local variable shadowing outer one
net/af_xdp: remove useless assignment
net/bnxt: remove redundant return
app/crypto-perf: remove always true condition
net/avp: remove always true condition
net/pcap: fix byte stats for drop Tx
net/pcap: fix infinite Rx with large files
app/testpmd: fix help of metering commands
Gaetan Rivet (2):
net/bonding: fix port id validity check on parsing
net/bonding: fix PCI address comparison on non-PCI ports
Gagandeep Singh (2):
test/ipsec: fix result code for not supported
crypto/dpaa2_sec: fix memory allocation check
George Prekas (1):
app/testpmd: fix IP checksum calculation
Gregory Etelson (5):
net/mlx5: fix Direct Verbs flow descriptor allocation
app/testpmd: release flows left before port stop
net/mlx5: fix tunnel rules validation on VF representor
net/mlx5: fix mark action in active tunnel offload
net/mlx5: fix drop action in tunnel offload mode
Guy Kaneti (1):
regex/octeontx2: fix PCI table overflow
Haiyue Wang (2):
net/ice: drain out DCF AdminQ command queue
net/ixgbe: fix UDP zero checksum on x86
Harman Kalra (1):
examples/l3fwd: remove limitation on Tx queue count
Harry van Haaren (1):
eventdev: fix a return value comment
Heinrich Kuhn (1):
net/nfp: read chip model from PluDevice register
Hemant Agrawal (1):
app/procinfo: fix security context info
Hongbo Zheng (1):
net/hns3: use new opcode for clearing hardware resource
Huisong Li (7):
app/testpmd: fix queue stats mapping configuration
net/hns3: fix xstats with id and names
net/hns3: fix error code in xstats
net/hns3: fix Rx/Tx errors stats
net/hns3: fix link status change from firmware
net/hns3: validate requested maximum Rx frame length
net/hns3: fix query order of link status and link info
Hyong Youb Kim (2):
net/enic: fix filter type used for flow API
net/enic: fix filter log message
Ido Segev (1):
net/ena: flush Rx buffers memory pool cache
Igor Chauskin (2):
net/ena: fix Tx SQ free space assessment
net/ena: prevent double doorbell
Igor Ryzhov (1):
net/i40e: fix stats counters
Ivan Malov (11):
common/sfc_efx/base: remove warnings about inline specifiers
common/sfc_efx/base: fix signed/unsigned mismatch warnings
common/sfc_efx/base: support alternative MAE match fields
common/sfc_efx/base: update MCDI headers for MAE privilege
common/sfc_efx/base: check for MAE privilege
common/sfc_efx/base: fix MPORT related byte order handling
common/sfc_efx/base: fix MAE match spec validation helper
common/sfc_efx/base: fix MAE match spec class comparison API
common/sfc_efx/base: enhance field ID check in field set API
common/sfc_efx/base: apply mask to value on match field set
net/sfc: fix TSO and checksum offloads for EF10
Jiawei Wang (4):
net/mlx5: fix unnecessary checking for RSS action
app/testpmd: fix packets dump overlapping
net/mlx5: fix count actions query in sample flow
net/mlx5: fix counter and age flow action validation
Jiawei Zhu (1):
net/virtio-user: fix run closing stdin and close callfd
Jingjing Wu (1):
net/iavf: fix vector mapping with queue
John McNamara (1):
license: add licenses for exception cases
Joyce Kong (1):
eal/arm: fix debug build with gcc for 128-bit atomics
Junfeng Guo (1):
net/iavf: fix GTPU UL and DL support for flow director
Kalesh AP (4):
net/bnxt: release HWRM lock in error
net/bnxt: propagate FW command failure to application
net/bnxt: fix VNIC RSS configure function
net/bnxt: fix FW version log
Karra Satwik (2):
net/cxgbe: accept VLAN flow items without ethertype
app/testpmd: fix start index for showing FEC array
Lance Richardson (10):
net/bnxt: disable end of packet padding for Rx
net/bnxt: limit Rx representor packets per poll
net/bnxt: fix doorbell write ordering
net/bnxt: fix outer UDP checksum Rx offload capability
net/bnxt: make offload flags mapping per-ring
net/bnxt: set correct checksum status in mbuf
net/bnxt: fix packet type index calculation
net/bnxt: fix null termination of Rx mbuf chain
net/bnxt: fix fallback mbuf allocation logic
net/bnxt: fix Rx completion ring size calculation
Leyi Rong (1):
net/ice: enlarge Rx queue rearm threshold to 64
Lijun Ou (6):
net/hns3: fix interception with flow director
net/hns3: fix memory leak on secondary process exit
net/hns3: adjust some comments
net/hns3: adjust format specifier for enum
doc: fix product link in hns3 guide
net/hns3: fix RSS indirection table size
Liron Himi (5):
net/octeontx2: fix PF flow action for Tx
net/mvpp2: remove debug log on fast-path
net/mvpp2: remove VLAN flush
net/mvpp2: remove CRC length from MRU validation
net/mvpp2: fix frame size checking
Long Li (1):
net/netvsc: ignore unsupported packet on sync command
Lukasz Wojciechowski (1):
test/distributor: fix return buffer queue overload
Marvin Liu (1):
vhost: fix packed ring dequeue offloading
Matan Azrad (1):
vdpa/mlx5: fix configuration mutex cleanup
Maxime Coquelin (3):
net/virtio: add missing backend features negotiation
net/virtio: fix memory init with vDPA backend
net/virtio: fix getting old status on reconnect
Michael Baum (7):
net/mlx5: fix leak on Rx queue creation failure
net/mlx5: fix leak on Tx queue creation failure
common/mlx5: fix completion queue entry size configuration
net/mlx5: remove CQE padding device argument
net/mlx5: fix leak on ASO SQ creation failure
net/mlx4: fix device detach
net/mlx4: fix handling of probing failure
Michal Krawczyk (1):
net/ena: validate Rx req ID upon acquiring descriptor
Min Hu (Connor) (3):
net/hns3: fix FEC state query
net/hns3: fix crash with multi-process
doc: add FEC to NIC features
Murphy Yang (6):
net/ice: fix outer UDP Tx checksum offload
net/i40e: fix L4 checksum flag
net/ice: fix outer checksum flags
net/iavf: fix conflicting RSS combination rules
net/ice: disable IPv4 checksum offload in vector Tx
net/i40e: add null input checks
Nick Connolly (2):
eal/windows: fix debug build with MinGW
eal/windows: fix vfprintf warning with clang
Olivier Matz (5):
build: fix plugin load on static build
net/virtio-user: fix protocol features advertising
service: propagate init error in EAL
test/mcslock: remove unneeded per lcore copy
mempool: fix panic on dump or audit
Ophir Munk (4):
net/mlx5: fix freeing packet pacing
net/mlx5: fix flow action destroy wrapper
net/mlx5: fix flow operation wrapper per OS
net/mlx5: unify operations for all OS
Ori Kam (3):
regex/mlx5: fix memory rule alignment
regex/mlx5: fix support for group id
regex/mlx5: fix number of supported queues
Qi Zhang (4):
doc: fix some statements for ice vector PMD
net/ice/base: fix tunnel destroy
net/ice/base: fix null pointer dereference
net/ice/base: fix memory handling
Ruifeng Wang (4):
lpm: fix vector IPv4 lookup
net/hns3: fix build with SVE
net/octeontx: fix build with SVE
common/octeontx2: fix build with SVE
Samik Gupta (2):
net/bnxt: fix Rx rings in RSS redirection table
net/bnxt: fix VNIC config on Rx queue stop
Shiri Kuzin (2):
net/mlx5: fix VXLAN decap on non-VXLAN flow
net/mlx5: refuse empty VLAN in flow pattern
Somnath Kotur (4):
net/bnxt: fix PF resource query
net/bnxt: fix lock init and destroy
net/bnxt: fix error handling in device start
net/bnxt: refactor init/uninit
Souvik Dey (2):
net/i40e: fix VLAN stripping in VF
common/mlx5: fix storing synced MAC to internal table
Sriharsha Basavapatna (1):
net/bnxt: fix max rings computation
Stephen Hemminger (2):
test/rwlock: fix spelling and missing whitespace
test: fix terminal settings on exit
Steve Yang (23):
ethdev: fix max Rx packet length check
app/testpmd: fix max Rx packet length for VLAN packets
net/dpaa: fix jumbo frame flag condition for MTU set
net/dpaa2: fix jumbo frame flag condition for MTU set
net/e1000: fix jumbo frame flag condition for MTU set
net/hns3: fix jumbo frame flag condition for MTU set
net/i40e: fix jumbo frame flag condition
net/iavf: fix jumbo frame flag condition
net/ice: fix jumbo frame flag condition
net/ipn3ke: fix jumbo frame flag condition for MTU set
net/octeontx: fix jumbo frame flag condition for MTU set
net/octeontx2: fix jumbo frame flag condition for MTU
net/qede: fix jumbo frame flag condition for MTU set
net/sfc: fix jumbo frame flag condition for MTU set
net/thunderx: fix jumbo frame flag condition for MTU set
net/ixgbe: fix jumbo frame flag condition
net/cxgbe: fix jumbo frame flag condition
net/axgbe: fix jumbo frame flag condition for MTU set
net/enetc: fix jumbo frame flag condition for MTU set
net/hinic: fix jumbo frame flag condition for MTU set
net/nfp: fix jumbo frame flag condition for MTU set
net/liquidio: fix jumbo frame flag condition for MTU set
app/testpmd: fix setting maximum packet length
Suanming Mou (5):
net/mlx5: fix shared RSS and mark actions combination
net/mlx5: fix multi-process port ID
net/mlx5: fix crash on secondary process port close
net/mlx5: fix port attach in secondary process
net/mlx4: fix port attach in secondary process
Sunil Kumar Kori (2):
net/octeontx2: fix corruption in segments list
net/octeontx: fix max Rx packet length
Tal Shnaiderman (5):
bus/pci: ignore missing NUMA node on Windows
net/mlx5: fix constant array size
net/mlx5: fix device name size on Windows
net/mlx5: fix comparison sign in flow engine
common/mlx5: fix pointer cast on Windows
Thomas Monjalon (3):
doc: fix figure numbering in graph guide
lib: fix doxygen for parameters of function pointers
ethdev: fix close failure handling
Timothy McDaniel (1):
event/dlb: fix accessing uninitialized variables
Ting Xu (1):
net/iavf: fix memory leak in large VF
Tyler Retzlaff (2):
bus/pci: fix build with Windows SDK >= 10.0.20253
eal/windows: fix C++ compatibility
Viacheslav Galaktionov (1):
net/sfc: fix generic byte statistics to exclude FCS bytes
Viacheslav Ovsiienko (8):
net/mlx5: fix Verbs memory allocation callback
net/mlx5: fix buffer split offload advertising
doc: update flow mark action in mlx5 guide
net/mlx5: fix wire vport hint
app/testpmd: fix queue reconfig request on Rx split update
doc: fix supported feature table in mlx5 guide
doc: fix mark action zero value in mlx5 guide
net/mlx5: fix Tx queue size created with DevX
Vladimir Medvedkin (2):
rib: fix insertion in some cases
crypto/qat: fix access to uninitialized variable
Weifeng Li (1):
net/i40e: fix X722 for 802.1ad frames ability
Wenjun Wu (1):
net/e1000: fix flow control mode setting
Wisam Jaddo (1):
app/flow-perf: simplify objects initialization
Xuan Ding (1):
net/iavf: fix symmetric flow rule creation
Yicai Lu (1):
ip_frag: remove padding length of fragment
Yongxin Liu (1):
usertools: fix binding built-in kernel driver
Yunjian Wang (3):
eal/linux: fix handling of error events from epoll
net/bnxt: fix memory leak when mapping fails
net/mvneta: check allocation in Rx queue flush
Yuri Chipchev (1):
net/mvpp2: fix stack corruption
^ permalink raw reply [relevance 1%]
* Re: [dpdk-dev] Build errors due to duplicate version.map entries in librte_power
2021-02-22 10:31 0% ` Juraj Linkeš
@ 2021-02-22 19:50 0% ` Aaron Conole
0 siblings, 0 replies; 200+ results
From: Aaron Conole @ 2021-02-22 19:50 UTC (permalink / raw)
To: Juraj Linkeš; +Cc: dev, Bruce Richardson, David Hunt, Anatoly Burakov
Juraj Linkeš <juraj.linkes@pantheon.tech> writes:
> This seems to have gone unnoticed.
>
> lib/librte_power/version.map specifies
> rte_power_guest_channel_send_msg both under DPDK_21 and EXPERIMENTAL.
>
> This is causing the clang cross-compile job to always fail with the error Aaron provided:
> ld.lld: error: duplicate symbol 'rte_power_guest_channel_send_msg' in version script
>
> Only the clang cross compile jobs are failing. This could be due to
> them using the LLVM linker (ld.lld) and the other clang jobs using the
> default linker.
The LLVM linker might not support all the same symbol versioning - but
ALSO I don't find what we're doing particularly correct - at least
according to:
https://www.akkadia.org/drepper/dsohowto.pdf
There doesn't seem to be any case where we would have the symbol appear
in multiple versions without using an alias in the code. And if the
symbol is changed in an incompatible way, then we've really done the
wrong thing.
> I have two questions about this:
> 1. Is this a real failure?
Maybe. I think we probably wrote a bad version.map, but I don't know
the history of these symbols. David? Anything?
> 2. If this is a real failure, should we also use ld.lld in the other clang jobs?
We need to know if this is also an area where the LLVM linker doesn't
support the same featureset as GNU.
> Thanks,
> Juraj
>
>> -----Original Message-----
>> From: dev <dev-bounces@dpdk.org> On Behalf Of Aaron Conole
>> Sent: Monday, February 15, 2021 8:18 PM
>> To: dev@dpdk.org
>> Cc: Bruce Richardson <bruce.richardson@intel.com>; David Hunt
>> <david.hunt@intel.com>; Anatoly Burakov <anatoly.burakov@intel.com>
>> Subject: [dpdk-dev] Build errors due to duplicate version.map entries in
>> librte_power
>>
>> Greetings,
>>
>> During CI runs, I've noticed lots of failures from the Travis-CI side all related to
>> librte_power/version.map containing some duplicate symbols. It seems commit
>> 4d3892dcd77b ("power: make channel message functions public") made the
>> following hunk:
>>
>> diff --git a/lib/librte_power/version.map b/lib/librte_power/version.map index
>> 69ca9af616..13f0af3b2d 100644
>> --- a/lib/librte_power/version.map
>> +++ b/lib/librte_power/version.map
>> @@ -34,4 +34,8 @@ EXPERIMENTAL {
>> rte_power_guest_channel_receive_msg;
>> rte_power_poll_stat_fetch;
>> rte_power_poll_stat_update;
>> +
>> + # added in 21.02
>> + rte_power_guest_channel_receive_msg;
>> + rte_power_guest_channel_send_msg;
>> };
>>
>>
>> As can be seen, rte_power_guest_channel_receive_msg was added already (it's
>> present in the hunk itself). The rte_power_guest_channel_send_msg function
>> was added as part of 85ff364f3bd3 ("build: align symbols with global ABI
>> version").
>>
>> I guess it may not be allowed to have duplicate symbols here, because in travis, I
>> see (only for some builds):
>>
>> clang -o lib/librte_power.so.21.1
>> 'lib/lib@@rte_power@sta/librte_power_rte_power.c.o'
>> 'lib/lib@@rte_power@sta/librte_power_power_acpi_cpufreq.c.o'
>> 'lib/lib@@rte_power@sta/librte_power_power_kvm_vm.c.o'
>> 'lib/lib@@rte_power@sta/librte_power_guest_channel.c.o'
>> 'lib/lib@@rte_power@sta/librte_power_rte_power_empty_poll.c.o'
>> 'lib/lib@@rte_power@sta/librte_power_power_pstate_cpufreq.c.o'
>> 'lib/lib@@rte_power@sta/librte_power_rte_power_pmd_mgmt.c.o'
>> 'lib/lib@@rte_power@sta/librte_power_power_common.c.o' -Wl,--no-
>> undefined -Wl,--as-needed -shared -fPIC -Wl,--start-group -Wl,-
>> soname,librte_power.so.21 -Wl,--no-as-needed -pthread -lm -ldl
>> lib/librte_eal.so.21.1 lib/librte_kvargs.so.21.1 lib/librte_telemetry.so.21.1
>> lib/librte_timer.so.21.1 lib/librte_ethdev.so.21.1 lib/librte_net.so.21.1
>> lib/librte_mbuf.so.21.1 lib/librte_mempool.so.21.1 lib/librte_ring.so.21.1
>> lib/librte_meter.so.21.1 -Wl,--end-group -Wl,--version-
>> script=/home/travis/build/ovsrobot/dpdk/lib/librte_power/version.map '-Wl,-
>> rpath,$ORIGIN/' -Wl,-rpath-link,/home/travis/build/ovsrobot/dpdk/build/lib -
>> target aarch64-linux-gnu -fuse-ld=lld --gcc-toolchain=/usr
>>
>> ld.lld: error: duplicate symbol 'rte_power_guest_channel_send_msg' in version
>> script
>>
>> Thoughts?
>>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 06/10] eventdev: make driver-only headers private
@ 2021-02-22 22:34 3% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2021-02-22 22:34 UTC (permalink / raw)
To: Bruce Richardson
Cc: dev, david.marchand, Timothy McDaniel, Hemant Agrawal,
Nipun Gupta, Mattias Rönnblom, Jerin Jacob, Pavan Nikhilesh,
Liang Ma, Peter Mccarthy, Harry van Haaren, Abhinandan Gujjar,
Jay Jayatheerthan, Erik Gabriel Carrillo
There are many vendors (including some internal Microsoft projects) with drivers
that are not in the DPDK tree. Breaking them is not something that should be
done, and certainly not in a release that claims API/ABI compatibility.
Although these fields should not have been exposed
to user in normal header files, you can't just remove them now.
Please revert this commit before 20.02 final release.
A better solution (like __rte_internal) can be added in the 21.11 release.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] 20.11.1 patches review and test
2021-02-22 15:09 1% [dpdk-dev] 20.11.1 patches review and test luca.boccassi
@ 2021-02-25 9:43 0% ` Christian Ehrhardt
2021-02-25 13:00 0% ` Pei Zhang
` (2 subsequent siblings)
3 siblings, 0 replies; 200+ results
From: Christian Ehrhardt @ 2021-02-25 9:43 UTC (permalink / raw)
To: Luca Boccassi
Cc: dpdk stable, dev, Abhishek Marathe, Akhil Goyal, Ali Alnubani,
benjamin.walker, David Christensen, hariprasad.govindharajan,
Hemant Agrawal, Ian Stokes, Jerin Jacob, John McNamara,
Ju-Hyoung Lee, Kevin Traynor, Luca Boccassi, Pei Zhang, pingx.yu,
qian.q.xu, Raslan Darawsheh, Thomas Monjalon, yuan.peng,
zhaoyan.chen
On Mon, Feb 22, 2021 at 4:09 PM <luca.boccassi@gmail.com> wrote:
>
> Hi all,
>
> Here is a list of patches targeted for stable release 20.11.1.
>
> The planned date for the final release is the 8th of March.
>
> Please help with testing and validation of your use cases and report
> any issues/results with reply-all to this mail. For the final release
> the fixes and reported validations will be added to the release notes.
>
> A release candidate tarball can be found at:
>
> https://dpdk.org/browse/dpdk-stable/tag/?id=v20.11.1-rc1
>
> These patches are located at branch 20.11 of dpdk-stable repo:
> https://dpdk.org/browse/dpdk-stable/
Hi Luca,
while my tests won't achieve the coverage of the bigger labs I still
wanted to mention
that I've built this for Ubuntu 21.04 and successfully ran some
OVS-DPDK based tests on it.
1.0.0 (07:05:12): phys (BM) tests
1.1.0 (07:05:12): initialize environment
1.1.1 (07:09:32): testpmd => Pass
1.1.2 (07:11:12): check testpmd output => Pass
2.0.0 (07:11:12): prep virtual test environment
1.0.0 (07:14:14): virt tests
1.1.0 (07:14:14): initialize environment
3.0.0 (07:15:30): performance tests
3.1.0 (07:15:30): prep benchmarks
3.2.0 (07:15:51): performance tests
3.2.1 (07:16:01): test guest-openvswitch for OVS-5CPU => Pass
3.2.2 (07:35:44): test guest-dpdk-vhost-user-client-multiq for
OVSDPDK-VUC => Pass
4.0.0 (07:57:11): VUC endurance checks
4.1.0 (07:57:11): prep VUC endurance tests
4.1.1 (08:12:38): start stop guests (client) => Pass
4.1.2 (09:25:59): add/remove ports (client) => Pass
4.2.0 (09:35:04): Final cleanup
P.S. 3.2.1 is actually not a DPDK case, but used for e.g speed comparisons
> Thanks.
>
> Luca Boccassi
>
> ---
> Ajit Khaparde (3):
> net/bnxt: fix cleanup on mutex init failure
> net/bnxt: fix format specifier for unsigned int
> net/bnxt: fix freeing mbuf
>
> Alexander Kozyrev (4):
> net/mlx5: fix mbuf freeing in vectorized MPRQ
> net/mlx5: fix flow tag decompression
> net/mlx5: check FW miniCQE format capabilities
> net/mlx5: fix miniCQE configuration for Verbs
>
> Alvin Zhang (9):
> net/ixgbe: detect failed VF MTU set
> net/i40e: fix Rx bytes statistics
> net/iavf: fix queue pairs configuration
> doc: fix RSS flow description in i40e guide
> net/i40e: fix returned code for RSS hardware failure
> net/ice: fix RSS lookup table initialization
> test: fix buffer overflow in Tx burst
> net/ixgbe: fix configuration of max frame size
> app/testpmd: fix key for RSS flow rule
>
> Amit Bernstein (1):
> net/ena: fix Tx doorbell statistics
>
> Anatoly Burakov (1):
> fbarray: fix overlap check
>
> Andrew Boyer (5):
> net/ionic: do minor logging fixups
> net/ionic: fix link speed and autonegotiation
> net/ionic: allow separate L3 and L4 checksum offload
> net/ionic: fix up function attribute tags
> net/ionic: fix address handling in Tx
>
> Ankur Dwivedi (1):
> test/event_crypto: set cipher operation in transform
>
> Ashish Sadanandan (1):
> mbuf: add C++ include guard for dynamic fields header
>
> Balazs Nemeth (1):
> net/qede: fix promiscuous enable
>
> Beilei Xing (2):
> net/i40e: fix global register recovery
> net/i40e: fix flex payload rule conflict
>
> Bernard Iremonger (1):
> doc: fix QinQ flow rules in testpmd guide
>
> Bruce Richardson (29):
> ethdev: avoid blocking telemetry for link status
> build: provide suitable error for "both" libraries option
> eal: fix reciprocal header include
> telemetry: fix missing header include
> ethdev: fix missing header include
> net: fix missing header include
> mbuf: fix missing header include
> bitrate: fix missing header include
> rib: fix missing header includes
> vhost: fix missing header includes
> ipsec: fix missing header include
> fib: fix missing header includes
> table: fix missing header include
> pipeline: fix missing header includes
> metrics: fix variable declaration in header
> node: fix missing header include
> app: fix build with extra include paths
> build: force pkg-config for dependency detection
> power: create guest channel public header file
> power: make channel message functions public
> power: rename public structs
> power: rename constants
> power: export guest channel header file
> power: clean up includes
> eal: fix MCS lock header include
> eal: fix internal ABI tag with clang
> power: fix missing header includes
> rib: fix missing header include
> eal: fix automatic loading of drivers as shared libs
>
> Chengchang Tang (7):
> net/hns3: fix register length when dumping registers
> net/hns3: fix data overwriting during register dump
> net/hns3: fix dump register out of range
> net/hns3: fix interrupt resources in Rx interrupt mode
> net/hns3: fix firmware exceptions by concurrent commands
> net/hns3: fix VF reset on mailbox failure
> net/hns3: fix stats flip overflow
>
> Chengwen Feng (3):
> net/hns3: fix VF query link status in dev init
> net/hns3: remove MPLS from supported flow items
> net/hns3: fix flow director rule residue on malloc failure
>
> Ciara Power (3):
> app/crypto-perf: fix spelling in output
> app/crypto-perf: fix latency CSV output
> app/crypto-perf: fix CSV output format
>
> Cristian Dumitrescu (1):
> examples/pipeline: fix CLI parsing crash
>
> Dapeng Yu (4):
> net/ixgbe: fix flex bytes flow director rule
> net/ice: check Rx queue number on RSS init
> net/ixgbe: disable NFS filtering
> app/testpmd: avoid exit without terminal restore
>
> David Marchand (3):
> net/hinic: restore vectorised code
> examples/pipeline: fix VXLAN script permission
> mbuf: remove unneeded atomic generic header include
>
> Dekel Peled (8):
> net/mlx5: fix shared age action validation
> net/mlx5: fix hairpin flow split decision
> net/mlx5: fix flow split combined with counter
> net/mlx5: fix flow split combined with age action
> net/mlx5: fix shared RSS translation and cleanup
> app/testpmd: support shared age action query
> net/mlx5: fix shared RSS capability check
> net/mlx5: validate hash Rx queue pointer
>
> Dmitry Kozlyuk (4):
> eal/windows: fix build with MinGW-w64 8
> bus/pci: fix build with MinGW-w64 8
> bus/pci: fix hardware ID limit on Windows
> build: fix linker flags on Windows
>
> Eugeny Parshutin (1):
> doc: add vtune profiling config to prog guide
>
> Fan Zhang (1):
> crypto/qat: fix digest in buffer
>
> Fei Chen (1):
> vhost: fix vid allocation race
>
> Feifei Wang (7):
> test/ring: reduce duration of performance tests
> app/eventdev: adjust event count order for pipeline test
> app/eventdev: remove redundant enqueue in burst Tx
> examples/eventdev: check CPU core enabling
> examples/eventdev: add info output for main core
> examples/eventdev: move ethdev stop to the end
> app/eventdev: fix SMP barrier in performance test
>
> Ferruh Yigit (13):
> app/procinfo: fix _filters stats reporting
> app/procinfo: fix check on xstats-ids
> app/procinfo: remove useless memset
> app/procinfo: remove useless assignment
> net/pcap: remove local variable shadowing outer one
> net/bonding: remove local variable shadowing outer one
> net/af_xdp: remove useless assignment
> net/bnxt: remove redundant return
> app/crypto-perf: remove always true condition
> net/avp: remove always true condition
> net/pcap: fix byte stats for drop Tx
> net/pcap: fix infinite Rx with large files
> app/testpmd: fix help of metering commands
>
> Gaetan Rivet (2):
> net/bonding: fix port id validity check on parsing
> net/bonding: fix PCI address comparison on non-PCI ports
>
> Gagandeep Singh (2):
> test/ipsec: fix result code for not supported
> crypto/dpaa2_sec: fix memory allocation check
>
> George Prekas (1):
> app/testpmd: fix IP checksum calculation
>
> Gregory Etelson (5):
> net/mlx5: fix Direct Verbs flow descriptor allocation
> app/testpmd: release flows left before port stop
> net/mlx5: fix tunnel rules validation on VF representor
> net/mlx5: fix mark action in active tunnel offload
> net/mlx5: fix drop action in tunnel offload mode
>
> Guy Kaneti (1):
> regex/octeontx2: fix PCI table overflow
>
> Haiyue Wang (2):
> net/ice: drain out DCF AdminQ command queue
> net/ixgbe: fix UDP zero checksum on x86
>
> Harman Kalra (1):
> examples/l3fwd: remove limitation on Tx queue count
>
> Harry van Haaren (1):
> eventdev: fix a return value comment
>
> Heinrich Kuhn (1):
> net/nfp: read chip model from PluDevice register
>
> Hemant Agrawal (1):
> app/procinfo: fix security context info
>
> Hongbo Zheng (1):
> net/hns3: use new opcode for clearing hardware resource
>
> Huisong Li (7):
> app/testpmd: fix queue stats mapping configuration
> net/hns3: fix xstats with id and names
> net/hns3: fix error code in xstats
> net/hns3: fix Rx/Tx errors stats
> net/hns3: fix link status change from firmware
> net/hns3: validate requested maximum Rx frame length
> net/hns3: fix query order of link status and link info
>
> Hyong Youb Kim (2):
> net/enic: fix filter type used for flow API
> net/enic: fix filter log message
>
> Ido Segev (1):
> net/ena: flush Rx buffers memory pool cache
>
> Igor Chauskin (2):
> net/ena: fix Tx SQ free space assessment
> net/ena: prevent double doorbell
>
> Igor Ryzhov (1):
> net/i40e: fix stats counters
>
> Ivan Malov (11):
> common/sfc_efx/base: remove warnings about inline specifiers
> common/sfc_efx/base: fix signed/unsigned mismatch warnings
> common/sfc_efx/base: support alternative MAE match fields
> common/sfc_efx/base: update MCDI headers for MAE privilege
> common/sfc_efx/base: check for MAE privilege
> common/sfc_efx/base: fix MPORT related byte order handling
> common/sfc_efx/base: fix MAE match spec validation helper
> common/sfc_efx/base: fix MAE match spec class comparison API
> common/sfc_efx/base: enhance field ID check in field set API
> common/sfc_efx/base: apply mask to value on match field set
> net/sfc: fix TSO and checksum offloads for EF10
>
> Jiawei Wang (4):
> net/mlx5: fix unnecessary checking for RSS action
> app/testpmd: fix packets dump overlapping
> net/mlx5: fix count actions query in sample flow
> net/mlx5: fix counter and age flow action validation
>
> Jiawei Zhu (1):
> net/virtio-user: fix run closing stdin and close callfd
>
> Jingjing Wu (1):
> net/iavf: fix vector mapping with queue
>
> John McNamara (1):
> license: add licenses for exception cases
>
> Joyce Kong (1):
> eal/arm: fix debug build with gcc for 128-bit atomics
>
> Junfeng Guo (1):
> net/iavf: fix GTPU UL and DL support for flow director
>
> Kalesh AP (4):
> net/bnxt: release HWRM lock in error
> net/bnxt: propagate FW command failure to application
> net/bnxt: fix VNIC RSS configure function
> net/bnxt: fix FW version log
>
> Karra Satwik (2):
> net/cxgbe: accept VLAN flow items without ethertype
> app/testpmd: fix start index for showing FEC array
>
> Lance Richardson (10):
> net/bnxt: disable end of packet padding for Rx
> net/bnxt: limit Rx representor packets per poll
> net/bnxt: fix doorbell write ordering
> net/bnxt: fix outer UDP checksum Rx offload capability
> net/bnxt: make offload flags mapping per-ring
> net/bnxt: set correct checksum status in mbuf
> net/bnxt: fix packet type index calculation
> net/bnxt: fix null termination of Rx mbuf chain
> net/bnxt: fix fallback mbuf allocation logic
> net/bnxt: fix Rx completion ring size calculation
>
> Leyi Rong (1):
> net/ice: enlarge Rx queue rearm threshold to 64
>
> Lijun Ou (6):
> net/hns3: fix interception with flow director
> net/hns3: fix memory leak on secondary process exit
> net/hns3: adjust some comments
> net/hns3: adjust format specifier for enum
> doc: fix product link in hns3 guide
> net/hns3: fix RSS indirection table size
>
> Liron Himi (5):
> net/octeontx2: fix PF flow action for Tx
> net/mvpp2: remove debug log on fast-path
> net/mvpp2: remove VLAN flush
> net/mvpp2: remove CRC length from MRU validation
> net/mvpp2: fix frame size checking
>
> Long Li (1):
> net/netvsc: ignore unsupported packet on sync command
>
> Lukasz Wojciechowski (1):
> test/distributor: fix return buffer queue overload
>
> Marvin Liu (1):
> vhost: fix packed ring dequeue offloading
>
> Matan Azrad (1):
> vdpa/mlx5: fix configuration mutex cleanup
>
> Maxime Coquelin (3):
> net/virtio: add missing backend features negotiation
> net/virtio: fix memory init with vDPA backend
> net/virtio: fix getting old status on reconnect
>
> Michael Baum (7):
> net/mlx5: fix leak on Rx queue creation failure
> net/mlx5: fix leak on Tx queue creation failure
> common/mlx5: fix completion queue entry size configuration
> net/mlx5: remove CQE padding device argument
> net/mlx5: fix leak on ASO SQ creation failure
> net/mlx4: fix device detach
> net/mlx4: fix handling of probing failure
>
> Michal Krawczyk (1):
> net/ena: validate Rx req ID upon acquiring descriptor
>
> Min Hu (Connor) (3):
> net/hns3: fix FEC state query
> net/hns3: fix crash with multi-process
> doc: add FEC to NIC features
>
> Murphy Yang (6):
> net/ice: fix outer UDP Tx checksum offload
> net/i40e: fix L4 checksum flag
> net/ice: fix outer checksum flags
> net/iavf: fix conflicting RSS combination rules
> net/ice: disable IPv4 checksum offload in vector Tx
> net/i40e: add null input checks
>
> Nick Connolly (2):
> eal/windows: fix debug build with MinGW
> eal/windows: fix vfprintf warning with clang
>
> Olivier Matz (5):
> build: fix plugin load on static build
> net/virtio-user: fix protocol features advertising
> service: propagate init error in EAL
> test/mcslock: remove unneeded per lcore copy
> mempool: fix panic on dump or audit
>
> Ophir Munk (4):
> net/mlx5: fix freeing packet pacing
> net/mlx5: fix flow action destroy wrapper
> net/mlx5: fix flow operation wrapper per OS
> net/mlx5: unify operations for all OS
>
> Ori Kam (3):
> regex/mlx5: fix memory rule alignment
> regex/mlx5: fix support for group id
> regex/mlx5: fix number of supported queues
>
> Qi Zhang (4):
> doc: fix some statements for ice vector PMD
> net/ice/base: fix tunnel destroy
> net/ice/base: fix null pointer dereference
> net/ice/base: fix memory handling
>
> Ruifeng Wang (4):
> lpm: fix vector IPv4 lookup
> net/hns3: fix build with SVE
> net/octeontx: fix build with SVE
> common/octeontx2: fix build with SVE
>
> Samik Gupta (2):
> net/bnxt: fix Rx rings in RSS redirection table
> net/bnxt: fix VNIC config on Rx queue stop
>
> Shiri Kuzin (2):
> net/mlx5: fix VXLAN decap on non-VXLAN flow
> net/mlx5: refuse empty VLAN in flow pattern
>
> Somnath Kotur (4):
> net/bnxt: fix PF resource query
> net/bnxt: fix lock init and destroy
> net/bnxt: fix error handling in device start
> net/bnxt: refactor init/uninit
>
> Souvik Dey (2):
> net/i40e: fix VLAN stripping in VF
> common/mlx5: fix storing synced MAC to internal table
>
> Sriharsha Basavapatna (1):
> net/bnxt: fix max rings computation
>
> Stephen Hemminger (2):
> test/rwlock: fix spelling and missing whitespace
> test: fix terminal settings on exit
>
> Steve Yang (23):
> ethdev: fix max Rx packet length check
> app/testpmd: fix max Rx packet length for VLAN packets
> net/dpaa: fix jumbo frame flag condition for MTU set
> net/dpaa2: fix jumbo frame flag condition for MTU set
> net/e1000: fix jumbo frame flag condition for MTU set
> net/hns3: fix jumbo frame flag condition for MTU set
> net/i40e: fix jumbo frame flag condition
> net/iavf: fix jumbo frame flag condition
> net/ice: fix jumbo frame flag condition
> net/ipn3ke: fix jumbo frame flag condition for MTU set
> net/octeontx: fix jumbo frame flag condition for MTU set
> net/octeontx2: fix jumbo frame flag condition for MTU
> net/qede: fix jumbo frame flag condition for MTU set
> net/sfc: fix jumbo frame flag condition for MTU set
> net/thunderx: fix jumbo frame flag condition for MTU set
> net/ixgbe: fix jumbo frame flag condition
> net/cxgbe: fix jumbo frame flag condition
> net/axgbe: fix jumbo frame flag condition for MTU set
> net/enetc: fix jumbo frame flag condition for MTU set
> net/hinic: fix jumbo frame flag condition for MTU set
> net/nfp: fix jumbo frame flag condition for MTU set
> net/liquidio: fix jumbo frame flag condition for MTU set
> app/testpmd: fix setting maximum packet length
>
> Suanming Mou (5):
> net/mlx5: fix shared RSS and mark actions combination
> net/mlx5: fix multi-process port ID
> net/mlx5: fix crash on secondary process port close
> net/mlx5: fix port attach in secondary process
> net/mlx4: fix port attach in secondary process
>
> Sunil Kumar Kori (2):
> net/octeontx2: fix corruption in segments list
> net/octeontx: fix max Rx packet length
>
> Tal Shnaiderman (5):
> bus/pci: ignore missing NUMA node on Windows
> net/mlx5: fix constant array size
> net/mlx5: fix device name size on Windows
> net/mlx5: fix comparison sign in flow engine
> common/mlx5: fix pointer cast on Windows
>
> Thomas Monjalon (3):
> doc: fix figure numbering in graph guide
> lib: fix doxygen for parameters of function pointers
> ethdev: fix close failure handling
>
> Timothy McDaniel (1):
> event/dlb: fix accessing uninitialized variables
>
> Ting Xu (1):
> net/iavf: fix memory leak in large VF
>
> Tyler Retzlaff (2):
> bus/pci: fix build with Windows SDK >= 10.0.20253
> eal/windows: fix C++ compatibility
>
> Viacheslav Galaktionov (1):
> net/sfc: fix generic byte statistics to exclude FCS bytes
>
> Viacheslav Ovsiienko (8):
> net/mlx5: fix Verbs memory allocation callback
> net/mlx5: fix buffer split offload advertising
> doc: update flow mark action in mlx5 guide
> net/mlx5: fix wire vport hint
> app/testpmd: fix queue reconfig request on Rx split update
> doc: fix supported feature table in mlx5 guide
> doc: fix mark action zero value in mlx5 guide
> net/mlx5: fix Tx queue size created with DevX
>
> Vladimir Medvedkin (2):
> rib: fix insertion in some cases
> crypto/qat: fix access to uninitialized variable
>
> Weifeng Li (1):
> net/i40e: fix X722 for 802.1ad frames ability
>
> Wenjun Wu (1):
> net/e1000: fix flow control mode setting
>
> Wisam Jaddo (1):
> app/flow-perf: simplify objects initialization
>
> Xuan Ding (1):
> net/iavf: fix symmetric flow rule creation
>
> Yicai Lu (1):
> ip_frag: remove padding length of fragment
>
> Yongxin Liu (1):
> usertools: fix binding built-in kernel driver
>
> Yunjian Wang (3):
> eal/linux: fix handling of error events from epoll
> net/bnxt: fix memory leak when mapping fails
> net/mvneta: check allocation in Rx queue flush
>
> Yuri Chipchev (1):
> net/mvpp2: fix stack corruption
--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] 20.11.1 patches review and test
2021-02-22 15:09 1% [dpdk-dev] 20.11.1 patches review and test luca.boccassi
2021-02-25 9:43 0% ` Christian Ehrhardt
@ 2021-02-25 13:00 0% ` Pei Zhang
2021-02-25 14:39 0% ` Luca Boccassi
2021-03-02 6:23 0% ` Kalesh Anakkur Purayil
2021-03-02 10:52 0% ` Chen, BoX C
3 siblings, 1 reply; 200+ results
From: Pei Zhang @ 2021-02-25 13:00 UTC (permalink / raw)
To: luca boccassi
Cc: stable, dev, Abhishek Marathe, Akhil Goyal, Ali Alnubani,
benjamin walker, David Christensen, hariprasad govindharajan,
Hemant Agrawal, Ian Stokes, Jerin Jacob, John McNamara,
Ju-Hyoung Lee, Kevin Traynor, Luca Boccassi, pingx yu, qian q xu,
Raslan Darawsheh, Thomas Monjalon, yuan peng, zhaoyan chen
Hello Luca,
The testing with dpdk 20.11.1-rc1 from Red Hat looks good. We tested below 17 scenarios and and all got PASS on RHEL8:
(1)Guest with device assignment(PF) throughput testing(1G hugepage size): PASS
(2)Guest with device assignment(PF) throughput testing(2M hugepage size) : PASS
(3)Guest with device assignment(VF) throughput testing: PASS
(4)PVP (host dpdk testpmd as vswitch) 1Q: throughput testing: PASS
(5)PVP vhost-user 2Q throughput testing: PASS
(6)PVP vhost-user 1Q - cross numa node throughput testing: PASS
(7)Guest with vhost-user 2 queues throughput testing: PASS
(8)vhost-user reconnect with dpdk-client, qemu-server: qemu reconnect: PASS
(9)vhost-user reconnect with dpdk-client, qemu-server: ovs reconnect: PASS
(10)PVP 1Q live migration testing: PASS
(11)PVP 1Q cross numa node live migration testing: PASS
(12)Guest with ovs+dpdk+vhost-user 1Q live migration testing: PASS
(13)Guest with ovs+dpdk+vhost-user 1Q live migration testing (2M): PASS
(14)Guest with ovs+dpdk+vhost-user 2Q live migration testing: PASS
(15)Guest with ovs+dpdk+vhost-user 4Q live migration testing: PASS
(16)Host PF + DPDK testing: PASS
(17)Host VF + DPDK testing: PASS
Versions:
kernel 4.18
qemu 5.2
dpdk: git://dpdk.org/dpdk-stable
# git log -1
commit fa27a3c11fba9ff30b2c4c4fcc862cea2b654803 (HEAD, tag: v20.11.1-rc1, origin/20.11)
Author: Luca Boccassi <luca.boccassi@microsoft.com>
Date: Mon Feb 22 14:59:17 2021 +0000
version: 20.11.1-rc1
Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com>
# git branch
remotes/origin/20.11
NICs: X540-AT2 NIC(ixgbe, 10G)
Best regards,
Pei
----- Original Message -----
> From: "luca boccassi" <luca.boccassi@gmail.com>
> To: stable@dpdk.org
> Cc: dev@dpdk.org, "Abhishek Marathe" <Abhishek.Marathe@microsoft.com>, "Akhil Goyal" <akhil.goyal@nxp.com>, "Ali
> Alnubani" <alialnu@nvidia.com>, "benjamin walker" <benjamin.walker@intel.com>, "David Christensen"
> <drc@linux.vnet.ibm.com>, "hariprasad govindharajan" <hariprasad.govindharajan@intel.com>, "Hemant Agrawal"
> <hemant.agrawal@nxp.com>, "Ian Stokes" <ian.stokes@intel.com>, "Jerin Jacob" <jerinj@marvell.com>, "John McNamara"
> <john.mcnamara@intel.com>, "Ju-Hyoung Lee" <juhlee@microsoft.com>, "Kevin Traynor" <ktraynor@redhat.com>, "Luca
> Boccassi" <bluca@debian.org>, "Pei Zhang" <pezhang@redhat.com>, "pingx yu" <pingx.yu@intel.com>, "qian q xu"
> <qian.q.xu@intel.com>, "Raslan Darawsheh" <rasland@nvidia.com>, "Thomas Monjalon" <thomas@monjalon.net>, "yuan peng"
> <yuan.peng@intel.com>, "zhaoyan chen" <zhaoyan.chen@intel.com>
> Sent: Monday, February 22, 2021 11:09:18 PM
> Subject: 20.11.1 patches review and test
>
> Hi all,
>
> Here is a list of patches targeted for stable release 20.11.1.
>
> The planned date for the final release is the 8th of March.
>
> Please help with testing and validation of your use cases and report
> any issues/results with reply-all to this mail. For the final release
> the fixes and reported validations will be added to the release notes.
>
> A release candidate tarball can be found at:
>
> https://dpdk.org/browse/dpdk-stable/tag/?id=v20.11.1-rc1
>
> These patches are located at branch 20.11 of dpdk-stable repo:
> https://dpdk.org/browse/dpdk-stable/
>
> Thanks.
>
> Luca Boccassi
>
> ---
> Ajit Khaparde (3):
> net/bnxt: fix cleanup on mutex init failure
> net/bnxt: fix format specifier for unsigned int
> net/bnxt: fix freeing mbuf
>
> Alexander Kozyrev (4):
> net/mlx5: fix mbuf freeing in vectorized MPRQ
> net/mlx5: fix flow tag decompression
> net/mlx5: check FW miniCQE format capabilities
> net/mlx5: fix miniCQE configuration for Verbs
>
> Alvin Zhang (9):
> net/ixgbe: detect failed VF MTU set
> net/i40e: fix Rx bytes statistics
> net/iavf: fix queue pairs configuration
> doc: fix RSS flow description in i40e guide
> net/i40e: fix returned code for RSS hardware failure
> net/ice: fix RSS lookup table initialization
> test: fix buffer overflow in Tx burst
> net/ixgbe: fix configuration of max frame size
> app/testpmd: fix key for RSS flow rule
>
> Amit Bernstein (1):
> net/ena: fix Tx doorbell statistics
>
> Anatoly Burakov (1):
> fbarray: fix overlap check
>
> Andrew Boyer (5):
> net/ionic: do minor logging fixups
> net/ionic: fix link speed and autonegotiation
> net/ionic: allow separate L3 and L4 checksum offload
> net/ionic: fix up function attribute tags
> net/ionic: fix address handling in Tx
>
> Ankur Dwivedi (1):
> test/event_crypto: set cipher operation in transform
>
> Ashish Sadanandan (1):
> mbuf: add C++ include guard for dynamic fields header
>
> Balazs Nemeth (1):
> net/qede: fix promiscuous enable
>
> Beilei Xing (2):
> net/i40e: fix global register recovery
> net/i40e: fix flex payload rule conflict
>
> Bernard Iremonger (1):
> doc: fix QinQ flow rules in testpmd guide
>
> Bruce Richardson (29):
> ethdev: avoid blocking telemetry for link status
> build: provide suitable error for "both" libraries option
> eal: fix reciprocal header include
> telemetry: fix missing header include
> ethdev: fix missing header include
> net: fix missing header include
> mbuf: fix missing header include
> bitrate: fix missing header include
> rib: fix missing header includes
> vhost: fix missing header includes
> ipsec: fix missing header include
> fib: fix missing header includes
> table: fix missing header include
> pipeline: fix missing header includes
> metrics: fix variable declaration in header
> node: fix missing header include
> app: fix build with extra include paths
> build: force pkg-config for dependency detection
> power: create guest channel public header file
> power: make channel message functions public
> power: rename public structs
> power: rename constants
> power: export guest channel header file
> power: clean up includes
> eal: fix MCS lock header include
> eal: fix internal ABI tag with clang
> power: fix missing header includes
> rib: fix missing header include
> eal: fix automatic loading of drivers as shared libs
>
> Chengchang Tang (7):
> net/hns3: fix register length when dumping registers
> net/hns3: fix data overwriting during register dump
> net/hns3: fix dump register out of range
> net/hns3: fix interrupt resources in Rx interrupt mode
> net/hns3: fix firmware exceptions by concurrent commands
> net/hns3: fix VF reset on mailbox failure
> net/hns3: fix stats flip overflow
>
> Chengwen Feng (3):
> net/hns3: fix VF query link status in dev init
> net/hns3: remove MPLS from supported flow items
> net/hns3: fix flow director rule residue on malloc failure
>
> Ciara Power (3):
> app/crypto-perf: fix spelling in output
> app/crypto-perf: fix latency CSV output
> app/crypto-perf: fix CSV output format
>
> Cristian Dumitrescu (1):
> examples/pipeline: fix CLI parsing crash
>
> Dapeng Yu (4):
> net/ixgbe: fix flex bytes flow director rule
> net/ice: check Rx queue number on RSS init
> net/ixgbe: disable NFS filtering
> app/testpmd: avoid exit without terminal restore
>
> David Marchand (3):
> net/hinic: restore vectorised code
> examples/pipeline: fix VXLAN script permission
> mbuf: remove unneeded atomic generic header include
>
> Dekel Peled (8):
> net/mlx5: fix shared age action validation
> net/mlx5: fix hairpin flow split decision
> net/mlx5: fix flow split combined with counter
> net/mlx5: fix flow split combined with age action
> net/mlx5: fix shared RSS translation and cleanup
> app/testpmd: support shared age action query
> net/mlx5: fix shared RSS capability check
> net/mlx5: validate hash Rx queue pointer
>
> Dmitry Kozlyuk (4):
> eal/windows: fix build with MinGW-w64 8
> bus/pci: fix build with MinGW-w64 8
> bus/pci: fix hardware ID limit on Windows
> build: fix linker flags on Windows
>
> Eugeny Parshutin (1):
> doc: add vtune profiling config to prog guide
>
> Fan Zhang (1):
> crypto/qat: fix digest in buffer
>
> Fei Chen (1):
> vhost: fix vid allocation race
>
> Feifei Wang (7):
> test/ring: reduce duration of performance tests
> app/eventdev: adjust event count order for pipeline test
> app/eventdev: remove redundant enqueue in burst Tx
> examples/eventdev: check CPU core enabling
> examples/eventdev: add info output for main core
> examples/eventdev: move ethdev stop to the end
> app/eventdev: fix SMP barrier in performance test
>
> Ferruh Yigit (13):
> app/procinfo: fix _filters stats reporting
> app/procinfo: fix check on xstats-ids
> app/procinfo: remove useless memset
> app/procinfo: remove useless assignment
> net/pcap: remove local variable shadowing outer one
> net/bonding: remove local variable shadowing outer one
> net/af_xdp: remove useless assignment
> net/bnxt: remove redundant return
> app/crypto-perf: remove always true condition
> net/avp: remove always true condition
> net/pcap: fix byte stats for drop Tx
> net/pcap: fix infinite Rx with large files
> app/testpmd: fix help of metering commands
>
> Gaetan Rivet (2):
> net/bonding: fix port id validity check on parsing
> net/bonding: fix PCI address comparison on non-PCI ports
>
> Gagandeep Singh (2):
> test/ipsec: fix result code for not supported
> crypto/dpaa2_sec: fix memory allocation check
>
> George Prekas (1):
> app/testpmd: fix IP checksum calculation
>
> Gregory Etelson (5):
> net/mlx5: fix Direct Verbs flow descriptor allocation
> app/testpmd: release flows left before port stop
> net/mlx5: fix tunnel rules validation on VF representor
> net/mlx5: fix mark action in active tunnel offload
> net/mlx5: fix drop action in tunnel offload mode
>
> Guy Kaneti (1):
> regex/octeontx2: fix PCI table overflow
>
> Haiyue Wang (2):
> net/ice: drain out DCF AdminQ command queue
> net/ixgbe: fix UDP zero checksum on x86
>
> Harman Kalra (1):
> examples/l3fwd: remove limitation on Tx queue count
>
> Harry van Haaren (1):
> eventdev: fix a return value comment
>
> Heinrich Kuhn (1):
> net/nfp: read chip model from PluDevice register
>
> Hemant Agrawal (1):
> app/procinfo: fix security context info
>
> Hongbo Zheng (1):
> net/hns3: use new opcode for clearing hardware resource
>
> Huisong Li (7):
> app/testpmd: fix queue stats mapping configuration
> net/hns3: fix xstats with id and names
> net/hns3: fix error code in xstats
> net/hns3: fix Rx/Tx errors stats
> net/hns3: fix link status change from firmware
> net/hns3: validate requested maximum Rx frame length
> net/hns3: fix query order of link status and link info
>
> Hyong Youb Kim (2):
> net/enic: fix filter type used for flow API
> net/enic: fix filter log message
>
> Ido Segev (1):
> net/ena: flush Rx buffers memory pool cache
>
> Igor Chauskin (2):
> net/ena: fix Tx SQ free space assessment
> net/ena: prevent double doorbell
>
> Igor Ryzhov (1):
> net/i40e: fix stats counters
>
> Ivan Malov (11):
> common/sfc_efx/base: remove warnings about inline specifiers
> common/sfc_efx/base: fix signed/unsigned mismatch warnings
> common/sfc_efx/base: support alternative MAE match fields
> common/sfc_efx/base: update MCDI headers for MAE privilege
> common/sfc_efx/base: check for MAE privilege
> common/sfc_efx/base: fix MPORT related byte order handling
> common/sfc_efx/base: fix MAE match spec validation helper
> common/sfc_efx/base: fix MAE match spec class comparison API
> common/sfc_efx/base: enhance field ID check in field set API
> common/sfc_efx/base: apply mask to value on match field set
> net/sfc: fix TSO and checksum offloads for EF10
>
> Jiawei Wang (4):
> net/mlx5: fix unnecessary checking for RSS action
> app/testpmd: fix packets dump overlapping
> net/mlx5: fix count actions query in sample flow
> net/mlx5: fix counter and age flow action validation
>
> Jiawei Zhu (1):
> net/virtio-user: fix run closing stdin and close callfd
>
> Jingjing Wu (1):
> net/iavf: fix vector mapping with queue
>
> John McNamara (1):
> license: add licenses for exception cases
>
> Joyce Kong (1):
> eal/arm: fix debug build with gcc for 128-bit atomics
>
> Junfeng Guo (1):
> net/iavf: fix GTPU UL and DL support for flow director
>
> Kalesh AP (4):
> net/bnxt: release HWRM lock in error
> net/bnxt: propagate FW command failure to application
> net/bnxt: fix VNIC RSS configure function
> net/bnxt: fix FW version log
>
> Karra Satwik (2):
> net/cxgbe: accept VLAN flow items without ethertype
> app/testpmd: fix start index for showing FEC array
>
> Lance Richardson (10):
> net/bnxt: disable end of packet padding for Rx
> net/bnxt: limit Rx representor packets per poll
> net/bnxt: fix doorbell write ordering
> net/bnxt: fix outer UDP checksum Rx offload capability
> net/bnxt: make offload flags mapping per-ring
> net/bnxt: set correct checksum status in mbuf
> net/bnxt: fix packet type index calculation
> net/bnxt: fix null termination of Rx mbuf chain
> net/bnxt: fix fallback mbuf allocation logic
> net/bnxt: fix Rx completion ring size calculation
>
> Leyi Rong (1):
> net/ice: enlarge Rx queue rearm threshold to 64
>
> Lijun Ou (6):
> net/hns3: fix interception with flow director
> net/hns3: fix memory leak on secondary process exit
> net/hns3: adjust some comments
> net/hns3: adjust format specifier for enum
> doc: fix product link in hns3 guide
> net/hns3: fix RSS indirection table size
>
> Liron Himi (5):
> net/octeontx2: fix PF flow action for Tx
> net/mvpp2: remove debug log on fast-path
> net/mvpp2: remove VLAN flush
> net/mvpp2: remove CRC length from MRU validation
> net/mvpp2: fix frame size checking
>
> Long Li (1):
> net/netvsc: ignore unsupported packet on sync command
>
> Lukasz Wojciechowski (1):
> test/distributor: fix return buffer queue overload
>
> Marvin Liu (1):
> vhost: fix packed ring dequeue offloading
>
> Matan Azrad (1):
> vdpa/mlx5: fix configuration mutex cleanup
>
> Maxime Coquelin (3):
> net/virtio: add missing backend features negotiation
> net/virtio: fix memory init with vDPA backend
> net/virtio: fix getting old status on reconnect
>
> Michael Baum (7):
> net/mlx5: fix leak on Rx queue creation failure
> net/mlx5: fix leak on Tx queue creation failure
> common/mlx5: fix completion queue entry size configuration
> net/mlx5: remove CQE padding device argument
> net/mlx5: fix leak on ASO SQ creation failure
> net/mlx4: fix device detach
> net/mlx4: fix handling of probing failure
>
> Michal Krawczyk (1):
> net/ena: validate Rx req ID upon acquiring descriptor
>
> Min Hu (Connor) (3):
> net/hns3: fix FEC state query
> net/hns3: fix crash with multi-process
> doc: add FEC to NIC features
>
> Murphy Yang (6):
> net/ice: fix outer UDP Tx checksum offload
> net/i40e: fix L4 checksum flag
> net/ice: fix outer checksum flags
> net/iavf: fix conflicting RSS combination rules
> net/ice: disable IPv4 checksum offload in vector Tx
> net/i40e: add null input checks
>
> Nick Connolly (2):
> eal/windows: fix debug build with MinGW
> eal/windows: fix vfprintf warning with clang
>
> Olivier Matz (5):
> build: fix plugin load on static build
> net/virtio-user: fix protocol features advertising
> service: propagate init error in EAL
> test/mcslock: remove unneeded per lcore copy
> mempool: fix panic on dump or audit
>
> Ophir Munk (4):
> net/mlx5: fix freeing packet pacing
> net/mlx5: fix flow action destroy wrapper
> net/mlx5: fix flow operation wrapper per OS
> net/mlx5: unify operations for all OS
>
> Ori Kam (3):
> regex/mlx5: fix memory rule alignment
> regex/mlx5: fix support for group id
> regex/mlx5: fix number of supported queues
>
> Qi Zhang (4):
> doc: fix some statements for ice vector PMD
> net/ice/base: fix tunnel destroy
> net/ice/base: fix null pointer dereference
> net/ice/base: fix memory handling
>
> Ruifeng Wang (4):
> lpm: fix vector IPv4 lookup
> net/hns3: fix build with SVE
> net/octeontx: fix build with SVE
> common/octeontx2: fix build with SVE
>
> Samik Gupta (2):
> net/bnxt: fix Rx rings in RSS redirection table
> net/bnxt: fix VNIC config on Rx queue stop
>
> Shiri Kuzin (2):
> net/mlx5: fix VXLAN decap on non-VXLAN flow
> net/mlx5: refuse empty VLAN in flow pattern
>
> Somnath Kotur (4):
> net/bnxt: fix PF resource query
> net/bnxt: fix lock init and destroy
> net/bnxt: fix error handling in device start
> net/bnxt: refactor init/uninit
>
> Souvik Dey (2):
> net/i40e: fix VLAN stripping in VF
> common/mlx5: fix storing synced MAC to internal table
>
> Sriharsha Basavapatna (1):
> net/bnxt: fix max rings computation
>
> Stephen Hemminger (2):
> test/rwlock: fix spelling and missing whitespace
> test: fix terminal settings on exit
>
> Steve Yang (23):
> ethdev: fix max Rx packet length check
> app/testpmd: fix max Rx packet length for VLAN packets
> net/dpaa: fix jumbo frame flag condition for MTU set
> net/dpaa2: fix jumbo frame flag condition for MTU set
> net/e1000: fix jumbo frame flag condition for MTU set
> net/hns3: fix jumbo frame flag condition for MTU set
> net/i40e: fix jumbo frame flag condition
> net/iavf: fix jumbo frame flag condition
> net/ice: fix jumbo frame flag condition
> net/ipn3ke: fix jumbo frame flag condition for MTU set
> net/octeontx: fix jumbo frame flag condition for MTU set
> net/octeontx2: fix jumbo frame flag condition for MTU
> net/qede: fix jumbo frame flag condition for MTU set
> net/sfc: fix jumbo frame flag condition for MTU set
> net/thunderx: fix jumbo frame flag condition for MTU set
> net/ixgbe: fix jumbo frame flag condition
> net/cxgbe: fix jumbo frame flag condition
> net/axgbe: fix jumbo frame flag condition for MTU set
> net/enetc: fix jumbo frame flag condition for MTU set
> net/hinic: fix jumbo frame flag condition for MTU set
> net/nfp: fix jumbo frame flag condition for MTU set
> net/liquidio: fix jumbo frame flag condition for MTU set
> app/testpmd: fix setting maximum packet length
>
> Suanming Mou (5):
> net/mlx5: fix shared RSS and mark actions combination
> net/mlx5: fix multi-process port ID
> net/mlx5: fix crash on secondary process port close
> net/mlx5: fix port attach in secondary process
> net/mlx4: fix port attach in secondary process
>
> Sunil Kumar Kori (2):
> net/octeontx2: fix corruption in segments list
> net/octeontx: fix max Rx packet length
>
> Tal Shnaiderman (5):
> bus/pci: ignore missing NUMA node on Windows
> net/mlx5: fix constant array size
> net/mlx5: fix device name size on Windows
> net/mlx5: fix comparison sign in flow engine
> common/mlx5: fix pointer cast on Windows
>
> Thomas Monjalon (3):
> doc: fix figure numbering in graph guide
> lib: fix doxygen for parameters of function pointers
> ethdev: fix close failure handling
>
> Timothy McDaniel (1):
> event/dlb: fix accessing uninitialized variables
>
> Ting Xu (1):
> net/iavf: fix memory leak in large VF
>
> Tyler Retzlaff (2):
> bus/pci: fix build with Windows SDK >= 10.0.20253
> eal/windows: fix C++ compatibility
>
> Viacheslav Galaktionov (1):
> net/sfc: fix generic byte statistics to exclude FCS bytes
>
> Viacheslav Ovsiienko (8):
> net/mlx5: fix Verbs memory allocation callback
> net/mlx5: fix buffer split offload advertising
> doc: update flow mark action in mlx5 guide
> net/mlx5: fix wire vport hint
> app/testpmd: fix queue reconfig request on Rx split update
> doc: fix supported feature table in mlx5 guide
> doc: fix mark action zero value in mlx5 guide
> net/mlx5: fix Tx queue size created with DevX
>
> Vladimir Medvedkin (2):
> rib: fix insertion in some cases
> crypto/qat: fix access to uninitialized variable
>
> Weifeng Li (1):
> net/i40e: fix X722 for 802.1ad frames ability
>
> Wenjun Wu (1):
> net/e1000: fix flow control mode setting
>
> Wisam Jaddo (1):
> app/flow-perf: simplify objects initialization
>
> Xuan Ding (1):
> net/iavf: fix symmetric flow rule creation
>
> Yicai Lu (1):
> ip_frag: remove padding length of fragment
>
> Yongxin Liu (1):
> usertools: fix binding built-in kernel driver
>
> Yunjian Wang (3):
> eal/linux: fix handling of error events from epoll
> net/bnxt: fix memory leak when mapping fails
> net/mvneta: check allocation in Rx queue flush
>
> Yuri Chipchev (1):
> net/mvpp2: fix stack corruption
>
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] 20.11.1 patches review and test
2021-02-25 13:00 0% ` Pei Zhang
@ 2021-02-25 14:39 0% ` Luca Boccassi
0 siblings, 0 replies; 200+ results
From: Luca Boccassi @ 2021-02-25 14:39 UTC (permalink / raw)
To: Pei Zhang
Cc: stable, dev, Abhishek Marathe, Akhil Goyal, Ali Alnubani,
benjamin walker, David Christensen, hariprasad govindharajan,
Hemant Agrawal, Ian Stokes, Jerin Jacob, John McNamara,
Ju-Hyoung Lee, Kevin Traynor, pingx yu, qian q xu,
Raslan Darawsheh, Thomas Monjalon, yuan peng, zhaoyan chen
On Thu, 2021-02-25 at 08:00 -0500, Pei Zhang wrote:
> Hello Luca,
>
> The testing with dpdk 20.11.1-rc1 from Red Hat looks good. We tested below 17 scenarios and and all got PASS on RHEL8:
>
> (1)Guest with device assignment(PF) throughput testing(1G hugepage size): PASS
> (2)Guest with device assignment(PF) throughput testing(2M hugepage size) : PASS
> (3)Guest with device assignment(VF) throughput testing: PASS
> (4)PVP (host dpdk testpmd as vswitch) 1Q: throughput testing: PASS
> (5)PVP vhost-user 2Q throughput testing: PASS
> (6)PVP vhost-user 1Q - cross numa node throughput testing: PASS
> (7)Guest with vhost-user 2 queues throughput testing: PASS
> (8)vhost-user reconnect with dpdk-client, qemu-server: qemu reconnect: PASS
> (9)vhost-user reconnect with dpdk-client, qemu-server: ovs reconnect: PASS
> (10)PVP 1Q live migration testing: PASS
> (11)PVP 1Q cross numa node live migration testing: PASS
> (12)Guest with ovs+dpdk+vhost-user 1Q live migration testing: PASS
> (13)Guest with ovs+dpdk+vhost-user 1Q live migration testing (2M): PASS
> (14)Guest with ovs+dpdk+vhost-user 2Q live migration testing: PASS
> (15)Guest with ovs+dpdk+vhost-user 4Q live migration testing: PASS
> (16)Host PF + DPDK testing: PASS
> (17)Host VF + DPDK testing: PASS
>
> Versions:
>
> kernel 4.18
> qemu 5.2
>
> dpdk: git://dpdk.org/dpdk-stable
> # git log -1
> commit fa27a3c11fba9ff30b2c4c4fcc862cea2b654803 (HEAD, tag: v20.11.1-rc1, origin/20.11)
> Author: Luca Boccassi <luca.boccassi@microsoft.com>
> Date: Mon Feb 22 14:59:17 2021 +0000
>
> version: 20.11.1-rc1
>
> Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com>
>
>
> # git branch
> remotes/origin/20.11
>
> NICs: X540-AT2 NIC(ixgbe, 10G)
>
> Best regards,
>
> Pei
Thank you!
>
> ----- Original Message -----
> > From: "luca boccassi" <luca.boccassi@gmail.com>
> > To: stable@dpdk.org
> > Cc: dev@dpdk.org, "Abhishek Marathe" <Abhishek.Marathe@microsoft.com>, "Akhil Goyal" <akhil.goyal@nxp.com>, "Ali
> > Alnubani" <alialnu@nvidia.com>, "benjamin walker" <benjamin.walker@intel.com>, "David Christensen"
> > <drc@linux.vnet.ibm.com>, "hariprasad govindharajan" <hariprasad.govindharajan@intel.com>, "Hemant Agrawal"
> > <hemant.agrawal@nxp.com>, "Ian Stokes" <ian.stokes@intel.com>, "Jerin Jacob" <jerinj@marvell.com>, "John McNamara"
> > <john.mcnamara@intel.com>, "Ju-Hyoung Lee" <juhlee@microsoft.com>, "Kevin Traynor" <ktraynor@redhat.com>, "Luca
> > Boccassi" <bluca@debian.org>, "Pei Zhang" <pezhang@redhat.com>, "pingx yu" <pingx.yu@intel.com>, "qian q xu"
> > <qian.q.xu@intel.com>, "Raslan Darawsheh" <rasland@nvidia.com>, "Thomas Monjalon" <thomas@monjalon.net>, "yuan peng"
> > <yuan.peng@intel.com>, "zhaoyan chen" <zhaoyan.chen@intel.com>
> > Sent: Monday, February 22, 2021 11:09:18 PM
> > Subject: 20.11.1 patches review and test
> >
> > Hi all,
> >
> > Here is a list of patches targeted for stable release 20.11.1.
> >
> > The planned date for the final release is the 8th of March.
> >
> > Please help with testing and validation of your use cases and report
> > any issues/results with reply-all to this mail. For the final release
> > the fixes and reported validations will be added to the release notes.
> >
> > A release candidate tarball can be found at:
> >
> > https://dpdk.org/browse/dpdk-stable/tag/?id=v20.11.1-rc1
> >
> > These patches are located at branch 20.11 of dpdk-stable repo:
> > https://dpdk.org/browse/dpdk-stable/
> >
> > Thanks.
> >
> > Luca Boccassi
> >
> > ---
> > Ajit Khaparde (3):
> > net/bnxt: fix cleanup on mutex init failure
> > net/bnxt: fix format specifier for unsigned int
> > net/bnxt: fix freeing mbuf
> >
> > Alexander Kozyrev (4):
> > net/mlx5: fix mbuf freeing in vectorized MPRQ
> > net/mlx5: fix flow tag decompression
> > net/mlx5: check FW miniCQE format capabilities
> > net/mlx5: fix miniCQE configuration for Verbs
> >
> > Alvin Zhang (9):
> > net/ixgbe: detect failed VF MTU set
> > net/i40e: fix Rx bytes statistics
> > net/iavf: fix queue pairs configuration
> > doc: fix RSS flow description in i40e guide
> > net/i40e: fix returned code for RSS hardware failure
> > net/ice: fix RSS lookup table initialization
> > test: fix buffer overflow in Tx burst
> > net/ixgbe: fix configuration of max frame size
> > app/testpmd: fix key for RSS flow rule
> >
> > Amit Bernstein (1):
> > net/ena: fix Tx doorbell statistics
> >
> > Anatoly Burakov (1):
> > fbarray: fix overlap check
> >
> > Andrew Boyer (5):
> > net/ionic: do minor logging fixups
> > net/ionic: fix link speed and autonegotiation
> > net/ionic: allow separate L3 and L4 checksum offload
> > net/ionic: fix up function attribute tags
> > net/ionic: fix address handling in Tx
> >
> > Ankur Dwivedi (1):
> > test/event_crypto: set cipher operation in transform
> >
> > Ashish Sadanandan (1):
> > mbuf: add C++ include guard for dynamic fields header
> >
> > Balazs Nemeth (1):
> > net/qede: fix promiscuous enable
> >
> > Beilei Xing (2):
> > net/i40e: fix global register recovery
> > net/i40e: fix flex payload rule conflict
> >
> > Bernard Iremonger (1):
> > doc: fix QinQ flow rules in testpmd guide
> >
> > Bruce Richardson (29):
> > ethdev: avoid blocking telemetry for link status
> > build: provide suitable error for "both" libraries option
> > eal: fix reciprocal header include
> > telemetry: fix missing header include
> > ethdev: fix missing header include
> > net: fix missing header include
> > mbuf: fix missing header include
> > bitrate: fix missing header include
> > rib: fix missing header includes
> > vhost: fix missing header includes
> > ipsec: fix missing header include
> > fib: fix missing header includes
> > table: fix missing header include
> > pipeline: fix missing header includes
> > metrics: fix variable declaration in header
> > node: fix missing header include
> > app: fix build with extra include paths
> > build: force pkg-config for dependency detection
> > power: create guest channel public header file
> > power: make channel message functions public
> > power: rename public structs
> > power: rename constants
> > power: export guest channel header file
> > power: clean up includes
> > eal: fix MCS lock header include
> > eal: fix internal ABI tag with clang
> > power: fix missing header includes
> > rib: fix missing header include
> > eal: fix automatic loading of drivers as shared libs
> >
> > Chengchang Tang (7):
> > net/hns3: fix register length when dumping registers
> > net/hns3: fix data overwriting during register dump
> > net/hns3: fix dump register out of range
> > net/hns3: fix interrupt resources in Rx interrupt mode
> > net/hns3: fix firmware exceptions by concurrent commands
> > net/hns3: fix VF reset on mailbox failure
> > net/hns3: fix stats flip overflow
> >
> > Chengwen Feng (3):
> > net/hns3: fix VF query link status in dev init
> > net/hns3: remove MPLS from supported flow items
> > net/hns3: fix flow director rule residue on malloc failure
> >
> > Ciara Power (3):
> > app/crypto-perf: fix spelling in output
> > app/crypto-perf: fix latency CSV output
> > app/crypto-perf: fix CSV output format
> >
> > Cristian Dumitrescu (1):
> > examples/pipeline: fix CLI parsing crash
> >
> > Dapeng Yu (4):
> > net/ixgbe: fix flex bytes flow director rule
> > net/ice: check Rx queue number on RSS init
> > net/ixgbe: disable NFS filtering
> > app/testpmd: avoid exit without terminal restore
> >
> > David Marchand (3):
> > net/hinic: restore vectorised code
> > examples/pipeline: fix VXLAN script permission
> > mbuf: remove unneeded atomic generic header include
> >
> > Dekel Peled (8):
> > net/mlx5: fix shared age action validation
> > net/mlx5: fix hairpin flow split decision
> > net/mlx5: fix flow split combined with counter
> > net/mlx5: fix flow split combined with age action
> > net/mlx5: fix shared RSS translation and cleanup
> > app/testpmd: support shared age action query
> > net/mlx5: fix shared RSS capability check
> > net/mlx5: validate hash Rx queue pointer
> >
> > Dmitry Kozlyuk (4):
> > eal/windows: fix build with MinGW-w64 8
> > bus/pci: fix build with MinGW-w64 8
> > bus/pci: fix hardware ID limit on Windows
> > build: fix linker flags on Windows
> >
> > Eugeny Parshutin (1):
> > doc: add vtune profiling config to prog guide
> >
> > Fan Zhang (1):
> > crypto/qat: fix digest in buffer
> >
> > Fei Chen (1):
> > vhost: fix vid allocation race
> >
> > Feifei Wang (7):
> > test/ring: reduce duration of performance tests
> > app/eventdev: adjust event count order for pipeline test
> > app/eventdev: remove redundant enqueue in burst Tx
> > examples/eventdev: check CPU core enabling
> > examples/eventdev: add info output for main core
> > examples/eventdev: move ethdev stop to the end
> > app/eventdev: fix SMP barrier in performance test
> >
> > Ferruh Yigit (13):
> > app/procinfo: fix _filters stats reporting
> > app/procinfo: fix check on xstats-ids
> > app/procinfo: remove useless memset
> > app/procinfo: remove useless assignment
> > net/pcap: remove local variable shadowing outer one
> > net/bonding: remove local variable shadowing outer one
> > net/af_xdp: remove useless assignment
> > net/bnxt: remove redundant return
> > app/crypto-perf: remove always true condition
> > net/avp: remove always true condition
> > net/pcap: fix byte stats for drop Tx
> > net/pcap: fix infinite Rx with large files
> > app/testpmd: fix help of metering commands
> >
> > Gaetan Rivet (2):
> > net/bonding: fix port id validity check on parsing
> > net/bonding: fix PCI address comparison on non-PCI ports
> >
> > Gagandeep Singh (2):
> > test/ipsec: fix result code for not supported
> > crypto/dpaa2_sec: fix memory allocation check
> >
> > George Prekas (1):
> > app/testpmd: fix IP checksum calculation
> >
> > Gregory Etelson (5):
> > net/mlx5: fix Direct Verbs flow descriptor allocation
> > app/testpmd: release flows left before port stop
> > net/mlx5: fix tunnel rules validation on VF representor
> > net/mlx5: fix mark action in active tunnel offload
> > net/mlx5: fix drop action in tunnel offload mode
> >
> > Guy Kaneti (1):
> > regex/octeontx2: fix PCI table overflow
> >
> > Haiyue Wang (2):
> > net/ice: drain out DCF AdminQ command queue
> > net/ixgbe: fix UDP zero checksum on x86
> >
> > Harman Kalra (1):
> > examples/l3fwd: remove limitation on Tx queue count
> >
> > Harry van Haaren (1):
> > eventdev: fix a return value comment
> >
> > Heinrich Kuhn (1):
> > net/nfp: read chip model from PluDevice register
> >
> > Hemant Agrawal (1):
> > app/procinfo: fix security context info
> >
> > Hongbo Zheng (1):
> > net/hns3: use new opcode for clearing hardware resource
> >
> > Huisong Li (7):
> > app/testpmd: fix queue stats mapping configuration
> > net/hns3: fix xstats with id and names
> > net/hns3: fix error code in xstats
> > net/hns3: fix Rx/Tx errors stats
> > net/hns3: fix link status change from firmware
> > net/hns3: validate requested maximum Rx frame length
> > net/hns3: fix query order of link status and link info
> >
> > Hyong Youb Kim (2):
> > net/enic: fix filter type used for flow API
> > net/enic: fix filter log message
> >
> > Ido Segev (1):
> > net/ena: flush Rx buffers memory pool cache
> >
> > Igor Chauskin (2):
> > net/ena: fix Tx SQ free space assessment
> > net/ena: prevent double doorbell
> >
> > Igor Ryzhov (1):
> > net/i40e: fix stats counters
> >
> > Ivan Malov (11):
> > common/sfc_efx/base: remove warnings about inline specifiers
> > common/sfc_efx/base: fix signed/unsigned mismatch warnings
> > common/sfc_efx/base: support alternative MAE match fields
> > common/sfc_efx/base: update MCDI headers for MAE privilege
> > common/sfc_efx/base: check for MAE privilege
> > common/sfc_efx/base: fix MPORT related byte order handling
> > common/sfc_efx/base: fix MAE match spec validation helper
> > common/sfc_efx/base: fix MAE match spec class comparison API
> > common/sfc_efx/base: enhance field ID check in field set API
> > common/sfc_efx/base: apply mask to value on match field set
> > net/sfc: fix TSO and checksum offloads for EF10
> >
> > Jiawei Wang (4):
> > net/mlx5: fix unnecessary checking for RSS action
> > app/testpmd: fix packets dump overlapping
> > net/mlx5: fix count actions query in sample flow
> > net/mlx5: fix counter and age flow action validation
> >
> > Jiawei Zhu (1):
> > net/virtio-user: fix run closing stdin and close callfd
> >
> > Jingjing Wu (1):
> > net/iavf: fix vector mapping with queue
> >
> > John McNamara (1):
> > license: add licenses for exception cases
> >
> > Joyce Kong (1):
> > eal/arm: fix debug build with gcc for 128-bit atomics
> >
> > Junfeng Guo (1):
> > net/iavf: fix GTPU UL and DL support for flow director
> >
> > Kalesh AP (4):
> > net/bnxt: release HWRM lock in error
> > net/bnxt: propagate FW command failure to application
> > net/bnxt: fix VNIC RSS configure function
> > net/bnxt: fix FW version log
> >
> > Karra Satwik (2):
> > net/cxgbe: accept VLAN flow items without ethertype
> > app/testpmd: fix start index for showing FEC array
> >
> > Lance Richardson (10):
> > net/bnxt: disable end of packet padding for Rx
> > net/bnxt: limit Rx representor packets per poll
> > net/bnxt: fix doorbell write ordering
> > net/bnxt: fix outer UDP checksum Rx offload capability
> > net/bnxt: make offload flags mapping per-ring
> > net/bnxt: set correct checksum status in mbuf
> > net/bnxt: fix packet type index calculation
> > net/bnxt: fix null termination of Rx mbuf chain
> > net/bnxt: fix fallback mbuf allocation logic
> > net/bnxt: fix Rx completion ring size calculation
> >
> > Leyi Rong (1):
> > net/ice: enlarge Rx queue rearm threshold to 64
> >
> > Lijun Ou (6):
> > net/hns3: fix interception with flow director
> > net/hns3: fix memory leak on secondary process exit
> > net/hns3: adjust some comments
> > net/hns3: adjust format specifier for enum
> > doc: fix product link in hns3 guide
> > net/hns3: fix RSS indirection table size
> >
> > Liron Himi (5):
> > net/octeontx2: fix PF flow action for Tx
> > net/mvpp2: remove debug log on fast-path
> > net/mvpp2: remove VLAN flush
> > net/mvpp2: remove CRC length from MRU validation
> > net/mvpp2: fix frame size checking
> >
> > Long Li (1):
> > net/netvsc: ignore unsupported packet on sync command
> >
> > Lukasz Wojciechowski (1):
> > test/distributor: fix return buffer queue overload
> >
> > Marvin Liu (1):
> > vhost: fix packed ring dequeue offloading
> >
> > Matan Azrad (1):
> > vdpa/mlx5: fix configuration mutex cleanup
> >
> > Maxime Coquelin (3):
> > net/virtio: add missing backend features negotiation
> > net/virtio: fix memory init with vDPA backend
> > net/virtio: fix getting old status on reconnect
> >
> > Michael Baum (7):
> > net/mlx5: fix leak on Rx queue creation failure
> > net/mlx5: fix leak on Tx queue creation failure
> > common/mlx5: fix completion queue entry size configuration
> > net/mlx5: remove CQE padding device argument
> > net/mlx5: fix leak on ASO SQ creation failure
> > net/mlx4: fix device detach
> > net/mlx4: fix handling of probing failure
> >
> > Michal Krawczyk (1):
> > net/ena: validate Rx req ID upon acquiring descriptor
> >
> > Min Hu (Connor) (3):
> > net/hns3: fix FEC state query
> > net/hns3: fix crash with multi-process
> > doc: add FEC to NIC features
> >
> > Murphy Yang (6):
> > net/ice: fix outer UDP Tx checksum offload
> > net/i40e: fix L4 checksum flag
> > net/ice: fix outer checksum flags
> > net/iavf: fix conflicting RSS combination rules
> > net/ice: disable IPv4 checksum offload in vector Tx
> > net/i40e: add null input checks
> >
> > Nick Connolly (2):
> > eal/windows: fix debug build with MinGW
> > eal/windows: fix vfprintf warning with clang
> >
> > Olivier Matz (5):
> > build: fix plugin load on static build
> > net/virtio-user: fix protocol features advertising
> > service: propagate init error in EAL
> > test/mcslock: remove unneeded per lcore copy
> > mempool: fix panic on dump or audit
> >
> > Ophir Munk (4):
> > net/mlx5: fix freeing packet pacing
> > net/mlx5: fix flow action destroy wrapper
> > net/mlx5: fix flow operation wrapper per OS
> > net/mlx5: unify operations for all OS
> >
> > Ori Kam (3):
> > regex/mlx5: fix memory rule alignment
> > regex/mlx5: fix support for group id
> > regex/mlx5: fix number of supported queues
> >
> > Qi Zhang (4):
> > doc: fix some statements for ice vector PMD
> > net/ice/base: fix tunnel destroy
> > net/ice/base: fix null pointer dereference
> > net/ice/base: fix memory handling
> >
> > Ruifeng Wang (4):
> > lpm: fix vector IPv4 lookup
> > net/hns3: fix build with SVE
> > net/octeontx: fix build with SVE
> > common/octeontx2: fix build with SVE
> >
> > Samik Gupta (2):
> > net/bnxt: fix Rx rings in RSS redirection table
> > net/bnxt: fix VNIC config on Rx queue stop
> >
> > Shiri Kuzin (2):
> > net/mlx5: fix VXLAN decap on non-VXLAN flow
> > net/mlx5: refuse empty VLAN in flow pattern
> >
> > Somnath Kotur (4):
> > net/bnxt: fix PF resource query
> > net/bnxt: fix lock init and destroy
> > net/bnxt: fix error handling in device start
> > net/bnxt: refactor init/uninit
> >
> > Souvik Dey (2):
> > net/i40e: fix VLAN stripping in VF
> > common/mlx5: fix storing synced MAC to internal table
> >
> > Sriharsha Basavapatna (1):
> > net/bnxt: fix max rings computation
> >
> > Stephen Hemminger (2):
> > test/rwlock: fix spelling and missing whitespace
> > test: fix terminal settings on exit
> >
> > Steve Yang (23):
> > ethdev: fix max Rx packet length check
> > app/testpmd: fix max Rx packet length for VLAN packets
> > net/dpaa: fix jumbo frame flag condition for MTU set
> > net/dpaa2: fix jumbo frame flag condition for MTU set
> > net/e1000: fix jumbo frame flag condition for MTU set
> > net/hns3: fix jumbo frame flag condition for MTU set
> > net/i40e: fix jumbo frame flag condition
> > net/iavf: fix jumbo frame flag condition
> > net/ice: fix jumbo frame flag condition
> > net/ipn3ke: fix jumbo frame flag condition for MTU set
> > net/octeontx: fix jumbo frame flag condition for MTU set
> > net/octeontx2: fix jumbo frame flag condition for MTU
> > net/qede: fix jumbo frame flag condition for MTU set
> > net/sfc: fix jumbo frame flag condition for MTU set
> > net/thunderx: fix jumbo frame flag condition for MTU set
> > net/ixgbe: fix jumbo frame flag condition
> > net/cxgbe: fix jumbo frame flag condition
> > net/axgbe: fix jumbo frame flag condition for MTU set
> > net/enetc: fix jumbo frame flag condition for MTU set
> > net/hinic: fix jumbo frame flag condition for MTU set
> > net/nfp: fix jumbo frame flag condition for MTU set
> > net/liquidio: fix jumbo frame flag condition for MTU set
> > app/testpmd: fix setting maximum packet length
> >
> > Suanming Mou (5):
> > net/mlx5: fix shared RSS and mark actions combination
> > net/mlx5: fix multi-process port ID
> > net/mlx5: fix crash on secondary process port close
> > net/mlx5: fix port attach in secondary process
> > net/mlx4: fix port attach in secondary process
> >
> > Sunil Kumar Kori (2):
> > net/octeontx2: fix corruption in segments list
> > net/octeontx: fix max Rx packet length
> >
> > Tal Shnaiderman (5):
> > bus/pci: ignore missing NUMA node on Windows
> > net/mlx5: fix constant array size
> > net/mlx5: fix device name size on Windows
> > net/mlx5: fix comparison sign in flow engine
> > common/mlx5: fix pointer cast on Windows
> >
> > Thomas Monjalon (3):
> > doc: fix figure numbering in graph guide
> > lib: fix doxygen for parameters of function pointers
> > ethdev: fix close failure handling
> >
> > Timothy McDaniel (1):
> > event/dlb: fix accessing uninitialized variables
> >
> > Ting Xu (1):
> > net/iavf: fix memory leak in large VF
> >
> > Tyler Retzlaff (2):
> > bus/pci: fix build with Windows SDK >= 10.0.20253
> > eal/windows: fix C++ compatibility
> >
> > Viacheslav Galaktionov (1):
> > net/sfc: fix generic byte statistics to exclude FCS bytes
> >
> > Viacheslav Ovsiienko (8):
> > net/mlx5: fix Verbs memory allocation callback
> > net/mlx5: fix buffer split offload advertising
> > doc: update flow mark action in mlx5 guide
> > net/mlx5: fix wire vport hint
> > app/testpmd: fix queue reconfig request on Rx split update
> > doc: fix supported feature table in mlx5 guide
> > doc: fix mark action zero value in mlx5 guide
> > net/mlx5: fix Tx queue size created with DevX
> >
> > Vladimir Medvedkin (2):
> > rib: fix insertion in some cases
> > crypto/qat: fix access to uninitialized variable
> >
> > Weifeng Li (1):
> > net/i40e: fix X722 for 802.1ad frames ability
> >
> > Wenjun Wu (1):
> > net/e1000: fix flow control mode setting
> >
> > Wisam Jaddo (1):
> > app/flow-perf: simplify objects initialization
> >
> > Xuan Ding (1):
> > net/iavf: fix symmetric flow rule creation
> >
> > Yicai Lu (1):
> > ip_frag: remove padding length of fragment
> >
> > Yongxin Liu (1):
> > usertools: fix binding built-in kernel driver
> >
> > Yunjian Wang (3):
> > eal/linux: fix handling of error events from epoll
> > net/bnxt: fix memory leak when mapping fails
> > net/mvneta: check allocation in Rx queue flush
> >
> > Yuri Chipchev (1):
> > net/mvpp2: fix stack corruption
> >
> >
--
Kind regards,
Luca Boccassi
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 4/6] net/pcap: add libpcap wrappers
@ 2021-02-25 23:10 3% ` Dmitry Kozlyuk
0 siblings, 0 replies; 200+ results
From: Dmitry Kozlyuk @ 2021-02-25 23:10 UTC (permalink / raw)
To: Nick Connolly
Cc: Ferruh Yigit, dev, Tyler Retzlaff, Mike Wells,
Narcisa Ana Maria Vasile, Dmitry Malloy, Pallavi Kadam, Jie Zhou
2021-02-25 20:31, Nick Connolly:
> > Your comment made me revise Windows EAL networking shims. Surprisingly, if
> > changed to expose Windows networking headers (specifically, <ws2tcpip.h>) with
> > some additions (but no hacks), they create no issues to any existing code.
> >
> > The only workaround remaining is `#undef s_addr` in <rte_ether.h>.
> >
> > So maybe this commit can be dropped, if Windows EAL networking headers be
> > reworked in the following way:
> >
> > #if defined min
> > #define USER_EXPLICITLY_WANTS_WINDOWS_H
> > #endif
> >
> > #include <ws2tcpip.h>
> >
> > /* hide definitions that break portable code,
> > * e.g. it had to be done once already for i40e
> > */
> > #ifndef USER_EXPLICITLY_WANTS_WINDOWS_H
> > #undef min, max, ...
> > #endif
> >
> > #define what's missing from Windows headers, e.g. IPPROTO_SCTP
> >
> > + Windows maintainers, Nick Connolly, and Jie Zhou to discuss.
> In my opinion, there are long term maintenance issues either way round.
>
> Wrapping the system headers hides the details and keeps the code 'clean',
> but has to work with multiple compiler environments and versions of the
> headers - not always straightforward.
You're probably right.
We had an exchange with Tyler, let me quote:
[DmitryK]
> I'm pretty sure no DPDK header really needs anything beyond standard C,
> but one exception: intrinsic functions for vector instructions.
> Struct in_addr? An oversight, there's rte_ether_addr, should be rte_ip_addr.
Here's a complete list of offending files included from public headers,
with comments on usage:
POSIX
netinet/in.h
netinet/ip6.h
netinet/ip.h
cmdline: struct in_addr, struct in6_addr, 6 constants
net: ditto
security: ditto
pthread.h
eal: not used
ethdev: pthread_mutex_t flow_ops_mutex;
sched.h
eal: cpu_set_t
telemetry: rte_cpuset_t (not used?)
sys/types.h
ehtdev: not needed (FILE?)
net: not needed
mbuf: ditto
pci: ditto
security: ditto
sched: ditto
Unix
sys/queue.h
(acl, eal, hash, lpm, mempool, pci, ring, table,
bus/{fslmc,pci,vdev,vmbus}, net/{memif,tap})
multiprocessing
Thread-related stuff will go away as rte_thread.h expands.
Network headers are not much needed, as you can see above.
Other headers mostly not needed or can be replaced with standard ones.
Replacing `in_addr` with and `rte_ip_addr` will break API, but not ABI,
because it's essentially the same thing. We can define new types
conditionally, as it was done for struct cmdline, if need be.
Complete removal of non-standard dependencies in headers is within a grasp.
Then we can remove shims and include whatever needed.
Thoughts?
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] 20.11.1 patches review and test
2021-02-22 15:09 1% [dpdk-dev] 20.11.1 patches review and test luca.boccassi
2021-02-25 9:43 0% ` Christian Ehrhardt
2021-02-25 13:00 0% ` Pei Zhang
@ 2021-03-02 6:23 0% ` Kalesh Anakkur Purayil
2021-03-02 10:29 0% ` Luca Boccassi
2021-03-02 10:52 0% ` Chen, BoX C
3 siblings, 1 reply; 200+ results
From: Kalesh Anakkur Purayil @ 2021-03-02 6:23 UTC (permalink / raw)
To: Luca Boccassi
Cc: dpdk stable, dpdk-dev, Abhishek Marathe, Akhil Goyal,
Ali Alnubani, benjamin.walker, David Christensen,
Hariprasad Govindharajan, Hemant Agrawal, Ian Stokes,
Jerin Jacob, John McNamara, Ju-Hyoung Lee, Kevin Traynor,
Luca Boccassi, Pei Zhang, pingx.yu, qian.q.xu, Raslan Darawsheh,
Thomas Monjalon, yuan.peng, zhaoyan.chen
[-- Attachment #1: Type: text/plain, Size: 19690 bytes --]
Hi Luca,
Testing with dpdk v20.11.1 from Broadcom looks good.
- Basic functionality:
Send and receive multiple types of traffic.
- Changing/checking link status through testpmd.
- RSS tests.
- TSO tests
- VLAN filtering tests.
- MAC filtering test
- statistics tests
- Checksum offload tests
- MTU tests
- Promiscuous tests
NIC: BCM57414 NetXtreme-E 10Gb/25Gb Ethernet Controller, Firmware:
218.1.186.0
NIC: BCM57508 NetXtreme-E 10Gb/25Gb/40Gb/50Gb/100Gb/200Gb Ethernet,
Firmware : 219.0.0.74
Regards,
Kalesh
On Mon, Feb 22, 2021 at 8:39 PM <luca.boccassi@gmail.com> wrote:
> Hi all,
>
> Here is a list of patches targeted for stable release 20.11.1.
>
> The planned date for the final release is the 8th of March.
>
> Please help with testing and validation of your use cases and report
> any issues/results with reply-all to this mail. For the final release
> the fixes and reported validations will be added to the release notes.
>
> A release candidate tarball can be found at:
>
> https://dpdk.org/browse/dpdk-stable/tag/?id=v20.11.1-rc1
>
> These patches are located at branch 20.11 of dpdk-stable repo:
> https://dpdk.org/browse/dpdk-stable/
>
> Thanks.
>
> Luca Boccassi
>
> ---
> Ajit Khaparde (3):
> net/bnxt: fix cleanup on mutex init failure
> net/bnxt: fix format specifier for unsigned int
> net/bnxt: fix freeing mbuf
>
> Alexander Kozyrev (4):
> net/mlx5: fix mbuf freeing in vectorized MPRQ
> net/mlx5: fix flow tag decompression
> net/mlx5: check FW miniCQE format capabilities
> net/mlx5: fix miniCQE configuration for Verbs
>
> Alvin Zhang (9):
> net/ixgbe: detect failed VF MTU set
> net/i40e: fix Rx bytes statistics
> net/iavf: fix queue pairs configuration
> doc: fix RSS flow description in i40e guide
> net/i40e: fix returned code for RSS hardware failure
> net/ice: fix RSS lookup table initialization
> test: fix buffer overflow in Tx burst
> net/ixgbe: fix configuration of max frame size
> app/testpmd: fix key for RSS flow rule
>
> Amit Bernstein (1):
> net/ena: fix Tx doorbell statistics
>
> Anatoly Burakov (1):
> fbarray: fix overlap check
>
> Andrew Boyer (5):
> net/ionic: do minor logging fixups
> net/ionic: fix link speed and autonegotiation
> net/ionic: allow separate L3 and L4 checksum offload
> net/ionic: fix up function attribute tags
> net/ionic: fix address handling in Tx
>
> Ankur Dwivedi (1):
> test/event_crypto: set cipher operation in transform
>
> Ashish Sadanandan (1):
> mbuf: add C++ include guard for dynamic fields header
>
> Balazs Nemeth (1):
> net/qede: fix promiscuous enable
>
> Beilei Xing (2):
> net/i40e: fix global register recovery
> net/i40e: fix flex payload rule conflict
>
> Bernard Iremonger (1):
> doc: fix QinQ flow rules in testpmd guide
>
> Bruce Richardson (29):
> ethdev: avoid blocking telemetry for link status
> build: provide suitable error for "both" libraries option
> eal: fix reciprocal header include
> telemetry: fix missing header include
> ethdev: fix missing header include
> net: fix missing header include
> mbuf: fix missing header include
> bitrate: fix missing header include
> rib: fix missing header includes
> vhost: fix missing header includes
> ipsec: fix missing header include
> fib: fix missing header includes
> table: fix missing header include
> pipeline: fix missing header includes
> metrics: fix variable declaration in header
> node: fix missing header include
> app: fix build with extra include paths
> build: force pkg-config for dependency detection
> power: create guest channel public header file
> power: make channel message functions public
> power: rename public structs
> power: rename constants
> power: export guest channel header file
> power: clean up includes
> eal: fix MCS lock header include
> eal: fix internal ABI tag with clang
> power: fix missing header includes
> rib: fix missing header include
> eal: fix automatic loading of drivers as shared libs
>
> Chengchang Tang (7):
> net/hns3: fix register length when dumping registers
> net/hns3: fix data overwriting during register dump
> net/hns3: fix dump register out of range
> net/hns3: fix interrupt resources in Rx interrupt mode
> net/hns3: fix firmware exceptions by concurrent commands
> net/hns3: fix VF reset on mailbox failure
> net/hns3: fix stats flip overflow
>
> Chengwen Feng (3):
> net/hns3: fix VF query link status in dev init
> net/hns3: remove MPLS from supported flow items
> net/hns3: fix flow director rule residue on malloc failure
>
> Ciara Power (3):
> app/crypto-perf: fix spelling in output
> app/crypto-perf: fix latency CSV output
> app/crypto-perf: fix CSV output format
>
> Cristian Dumitrescu (1):
> examples/pipeline: fix CLI parsing crash
>
> Dapeng Yu (4):
> net/ixgbe: fix flex bytes flow director rule
> net/ice: check Rx queue number on RSS init
> net/ixgbe: disable NFS filtering
> app/testpmd: avoid exit without terminal restore
>
> David Marchand (3):
> net/hinic: restore vectorised code
> examples/pipeline: fix VXLAN script permission
> mbuf: remove unneeded atomic generic header include
>
> Dekel Peled (8):
> net/mlx5: fix shared age action validation
> net/mlx5: fix hairpin flow split decision
> net/mlx5: fix flow split combined with counter
> net/mlx5: fix flow split combined with age action
> net/mlx5: fix shared RSS translation and cleanup
> app/testpmd: support shared age action query
> net/mlx5: fix shared RSS capability check
> net/mlx5: validate hash Rx queue pointer
>
> Dmitry Kozlyuk (4):
> eal/windows: fix build with MinGW-w64 8
> bus/pci: fix build with MinGW-w64 8
> bus/pci: fix hardware ID limit on Windows
> build: fix linker flags on Windows
>
> Eugeny Parshutin (1):
> doc: add vtune profiling config to prog guide
>
> Fan Zhang (1):
> crypto/qat: fix digest in buffer
>
> Fei Chen (1):
> vhost: fix vid allocation race
>
> Feifei Wang (7):
> test/ring: reduce duration of performance tests
> app/eventdev: adjust event count order for pipeline test
> app/eventdev: remove redundant enqueue in burst Tx
> examples/eventdev: check CPU core enabling
> examples/eventdev: add info output for main core
> examples/eventdev: move ethdev stop to the end
> app/eventdev: fix SMP barrier in performance test
>
> Ferruh Yigit (13):
> app/procinfo: fix _filters stats reporting
> app/procinfo: fix check on xstats-ids
> app/procinfo: remove useless memset
> app/procinfo: remove useless assignment
> net/pcap: remove local variable shadowing outer one
> net/bonding: remove local variable shadowing outer one
> net/af_xdp: remove useless assignment
> net/bnxt: remove redundant return
> app/crypto-perf: remove always true condition
> net/avp: remove always true condition
> net/pcap: fix byte stats for drop Tx
> net/pcap: fix infinite Rx with large files
> app/testpmd: fix help of metering commands
>
> Gaetan Rivet (2):
> net/bonding: fix port id validity check on parsing
> net/bonding: fix PCI address comparison on non-PCI ports
>
> Gagandeep Singh (2):
> test/ipsec: fix result code for not supported
> crypto/dpaa2_sec: fix memory allocation check
>
> George Prekas (1):
> app/testpmd: fix IP checksum calculation
>
> Gregory Etelson (5):
> net/mlx5: fix Direct Verbs flow descriptor allocation
> app/testpmd: release flows left before port stop
> net/mlx5: fix tunnel rules validation on VF representor
> net/mlx5: fix mark action in active tunnel offload
> net/mlx5: fix drop action in tunnel offload mode
>
> Guy Kaneti (1):
> regex/octeontx2: fix PCI table overflow
>
> Haiyue Wang (2):
> net/ice: drain out DCF AdminQ command queue
> net/ixgbe: fix UDP zero checksum on x86
>
> Harman Kalra (1):
> examples/l3fwd: remove limitation on Tx queue count
>
> Harry van Haaren (1):
> eventdev: fix a return value comment
>
> Heinrich Kuhn (1):
> net/nfp: read chip model from PluDevice register
>
> Hemant Agrawal (1):
> app/procinfo: fix security context info
>
> Hongbo Zheng (1):
> net/hns3: use new opcode for clearing hardware resource
>
> Huisong Li (7):
> app/testpmd: fix queue stats mapping configuration
> net/hns3: fix xstats with id and names
> net/hns3: fix error code in xstats
> net/hns3: fix Rx/Tx errors stats
> net/hns3: fix link status change from firmware
> net/hns3: validate requested maximum Rx frame length
> net/hns3: fix query order of link status and link info
>
> Hyong Youb Kim (2):
> net/enic: fix filter type used for flow API
> net/enic: fix filter log message
>
> Ido Segev (1):
> net/ena: flush Rx buffers memory pool cache
>
> Igor Chauskin (2):
> net/ena: fix Tx SQ free space assessment
> net/ena: prevent double doorbell
>
> Igor Ryzhov (1):
> net/i40e: fix stats counters
>
> Ivan Malov (11):
> common/sfc_efx/base: remove warnings about inline specifiers
> common/sfc_efx/base: fix signed/unsigned mismatch warnings
> common/sfc_efx/base: support alternative MAE match fields
> common/sfc_efx/base: update MCDI headers for MAE privilege
> common/sfc_efx/base: check for MAE privilege
> common/sfc_efx/base: fix MPORT related byte order handling
> common/sfc_efx/base: fix MAE match spec validation helper
> common/sfc_efx/base: fix MAE match spec class comparison API
> common/sfc_efx/base: enhance field ID check in field set API
> common/sfc_efx/base: apply mask to value on match field set
> net/sfc: fix TSO and checksum offloads for EF10
>
> Jiawei Wang (4):
> net/mlx5: fix unnecessary checking for RSS action
> app/testpmd: fix packets dump overlapping
> net/mlx5: fix count actions query in sample flow
> net/mlx5: fix counter and age flow action validation
>
> Jiawei Zhu (1):
> net/virtio-user: fix run closing stdin and close callfd
>
> Jingjing Wu (1):
> net/iavf: fix vector mapping with queue
>
> John McNamara (1):
> license: add licenses for exception cases
>
> Joyce Kong (1):
> eal/arm: fix debug build with gcc for 128-bit atomics
>
> Junfeng Guo (1):
> net/iavf: fix GTPU UL and DL support for flow director
>
> Kalesh AP (4):
> net/bnxt: release HWRM lock in error
> net/bnxt: propagate FW command failure to application
> net/bnxt: fix VNIC RSS configure function
> net/bnxt: fix FW version log
>
> Karra Satwik (2):
> net/cxgbe: accept VLAN flow items without ethertype
> app/testpmd: fix start index for showing FEC array
>
> Lance Richardson (10):
> net/bnxt: disable end of packet padding for Rx
> net/bnxt: limit Rx representor packets per poll
> net/bnxt: fix doorbell write ordering
> net/bnxt: fix outer UDP checksum Rx offload capability
> net/bnxt: make offload flags mapping per-ring
> net/bnxt: set correct checksum status in mbuf
> net/bnxt: fix packet type index calculation
> net/bnxt: fix null termination of Rx mbuf chain
> net/bnxt: fix fallback mbuf allocation logic
> net/bnxt: fix Rx completion ring size calculation
>
> Leyi Rong (1):
> net/ice: enlarge Rx queue rearm threshold to 64
>
> Lijun Ou (6):
> net/hns3: fix interception with flow director
> net/hns3: fix memory leak on secondary process exit
> net/hns3: adjust some comments
> net/hns3: adjust format specifier for enum
> doc: fix product link in hns3 guide
> net/hns3: fix RSS indirection table size
>
> Liron Himi (5):
> net/octeontx2: fix PF flow action for Tx
> net/mvpp2: remove debug log on fast-path
> net/mvpp2: remove VLAN flush
> net/mvpp2: remove CRC length from MRU validation
> net/mvpp2: fix frame size checking
>
> Long Li (1):
> net/netvsc: ignore unsupported packet on sync command
>
> Lukasz Wojciechowski (1):
> test/distributor: fix return buffer queue overload
>
> Marvin Liu (1):
> vhost: fix packed ring dequeue offloading
>
> Matan Azrad (1):
> vdpa/mlx5: fix configuration mutex cleanup
>
> Maxime Coquelin (3):
> net/virtio: add missing backend features negotiation
> net/virtio: fix memory init with vDPA backend
> net/virtio: fix getting old status on reconnect
>
> Michael Baum (7):
> net/mlx5: fix leak on Rx queue creation failure
> net/mlx5: fix leak on Tx queue creation failure
> common/mlx5: fix completion queue entry size configuration
> net/mlx5: remove CQE padding device argument
> net/mlx5: fix leak on ASO SQ creation failure
> net/mlx4: fix device detach
> net/mlx4: fix handling of probing failure
>
> Michal Krawczyk (1):
> net/ena: validate Rx req ID upon acquiring descriptor
>
> Min Hu (Connor) (3):
> net/hns3: fix FEC state query
> net/hns3: fix crash with multi-process
> doc: add FEC to NIC features
>
> Murphy Yang (6):
> net/ice: fix outer UDP Tx checksum offload
> net/i40e: fix L4 checksum flag
> net/ice: fix outer checksum flags
> net/iavf: fix conflicting RSS combination rules
> net/ice: disable IPv4 checksum offload in vector Tx
> net/i40e: add null input checks
>
> Nick Connolly (2):
> eal/windows: fix debug build with MinGW
> eal/windows: fix vfprintf warning with clang
>
> Olivier Matz (5):
> build: fix plugin load on static build
> net/virtio-user: fix protocol features advertising
> service: propagate init error in EAL
> test/mcslock: remove unneeded per lcore copy
> mempool: fix panic on dump or audit
>
> Ophir Munk (4):
> net/mlx5: fix freeing packet pacing
> net/mlx5: fix flow action destroy wrapper
> net/mlx5: fix flow operation wrapper per OS
> net/mlx5: unify operations for all OS
>
> Ori Kam (3):
> regex/mlx5: fix memory rule alignment
> regex/mlx5: fix support for group id
> regex/mlx5: fix number of supported queues
>
> Qi Zhang (4):
> doc: fix some statements for ice vector PMD
> net/ice/base: fix tunnel destroy
> net/ice/base: fix null pointer dereference
> net/ice/base: fix memory handling
>
> Ruifeng Wang (4):
> lpm: fix vector IPv4 lookup
> net/hns3: fix build with SVE
> net/octeontx: fix build with SVE
> common/octeontx2: fix build with SVE
>
> Samik Gupta (2):
> net/bnxt: fix Rx rings in RSS redirection table
> net/bnxt: fix VNIC config on Rx queue stop
>
> Shiri Kuzin (2):
> net/mlx5: fix VXLAN decap on non-VXLAN flow
> net/mlx5: refuse empty VLAN in flow pattern
>
> Somnath Kotur (4):
> net/bnxt: fix PF resource query
> net/bnxt: fix lock init and destroy
> net/bnxt: fix error handling in device start
> net/bnxt: refactor init/uninit
>
> Souvik Dey (2):
> net/i40e: fix VLAN stripping in VF
> common/mlx5: fix storing synced MAC to internal table
>
> Sriharsha Basavapatna (1):
> net/bnxt: fix max rings computation
>
> Stephen Hemminger (2):
> test/rwlock: fix spelling and missing whitespace
> test: fix terminal settings on exit
>
> Steve Yang (23):
> ethdev: fix max Rx packet length check
> app/testpmd: fix max Rx packet length for VLAN packets
> net/dpaa: fix jumbo frame flag condition for MTU set
> net/dpaa2: fix jumbo frame flag condition for MTU set
> net/e1000: fix jumbo frame flag condition for MTU set
> net/hns3: fix jumbo frame flag condition for MTU set
> net/i40e: fix jumbo frame flag condition
> net/iavf: fix jumbo frame flag condition
> net/ice: fix jumbo frame flag condition
> net/ipn3ke: fix jumbo frame flag condition for MTU set
> net/octeontx: fix jumbo frame flag condition for MTU set
> net/octeontx2: fix jumbo frame flag condition for MTU
> net/qede: fix jumbo frame flag condition for MTU set
> net/sfc: fix jumbo frame flag condition for MTU set
> net/thunderx: fix jumbo frame flag condition for MTU set
> net/ixgbe: fix jumbo frame flag condition
> net/cxgbe: fix jumbo frame flag condition
> net/axgbe: fix jumbo frame flag condition for MTU set
> net/enetc: fix jumbo frame flag condition for MTU set
> net/hinic: fix jumbo frame flag condition for MTU set
> net/nfp: fix jumbo frame flag condition for MTU set
> net/liquidio: fix jumbo frame flag condition for MTU set
> app/testpmd: fix setting maximum packet length
>
> Suanming Mou (5):
> net/mlx5: fix shared RSS and mark actions combination
> net/mlx5: fix multi-process port ID
> net/mlx5: fix crash on secondary process port close
> net/mlx5: fix port attach in secondary process
> net/mlx4: fix port attach in secondary process
>
> Sunil Kumar Kori (2):
> net/octeontx2: fix corruption in segments list
> net/octeontx: fix max Rx packet length
>
> Tal Shnaiderman (5):
> bus/pci: ignore missing NUMA node on Windows
> net/mlx5: fix constant array size
> net/mlx5: fix device name size on Windows
> net/mlx5: fix comparison sign in flow engine
> common/mlx5: fix pointer cast on Windows
>
> Thomas Monjalon (3):
> doc: fix figure numbering in graph guide
> lib: fix doxygen for parameters of function pointers
> ethdev: fix close failure handling
>
> Timothy McDaniel (1):
> event/dlb: fix accessing uninitialized variables
>
> Ting Xu (1):
> net/iavf: fix memory leak in large VF
>
> Tyler Retzlaff (2):
> bus/pci: fix build with Windows SDK >= 10.0.20253
> eal/windows: fix C++ compatibility
>
> Viacheslav Galaktionov (1):
> net/sfc: fix generic byte statistics to exclude FCS bytes
>
> Viacheslav Ovsiienko (8):
> net/mlx5: fix Verbs memory allocation callback
> net/mlx5: fix buffer split offload advertising
> doc: update flow mark action in mlx5 guide
> net/mlx5: fix wire vport hint
> app/testpmd: fix queue reconfig request on Rx split update
> doc: fix supported feature table in mlx5 guide
> doc: fix mark action zero value in mlx5 guide
> net/mlx5: fix Tx queue size created with DevX
>
> Vladimir Medvedkin (2):
> rib: fix insertion in some cases
> crypto/qat: fix access to uninitialized variable
>
> Weifeng Li (1):
> net/i40e: fix X722 for 802.1ad frames ability
>
> Wenjun Wu (1):
> net/e1000: fix flow control mode setting
>
> Wisam Jaddo (1):
> app/flow-perf: simplify objects initialization
>
> Xuan Ding (1):
> net/iavf: fix symmetric flow rule creation
>
> Yicai Lu (1):
> ip_frag: remove padding length of fragment
>
> Yongxin Liu (1):
> usertools: fix binding built-in kernel driver
>
> Yunjian Wang (3):
> eal/linux: fix handling of error events from epoll
> net/bnxt: fix memory leak when mapping fails
> net/mvneta: check allocation in Rx queue flush
>
> Yuri Chipchev (1):
> net/mvpp2: fix stack corruption
>
--
Regards,
Kalesh A P
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile
@ 2021-03-02 7:02 4% ` Matan Azrad
2021-03-02 12:29 3% ` Dumitrescu, Cristian
0 siblings, 1 reply; 200+ results
From: Matan Azrad @ 2021-03-02 7:02 UTC (permalink / raw)
To: Dumitrescu, Cristian, Li Zhang, Dekel Peled, Ori Kam, Slava Ovsiienko
Cc: dev, NBU-Contact-Thomas Monjalon, Raslan Darawsheh, mb,
ajit.khaparde, Yigit, Ferruh, Singh, Jasvinder
Hi Cristian
Thank you for review, please see inline.
From: Dumitrescu, Cristian
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Li Zhang
<snip>
> We had this same problem earlier for the rte_tm.h API, where people asked to
> add support for WRED and shaper rates specified in packets to the existing byte
> rate support. I am more than happy to support adding the same here, but
> please let's adopt the same solution here rather than invent a different
> approach.
>
> Please refer to struct rte_tm_wred_params and struct rte_tm_shaper_params
> from rte_tm.h: the packets vs. bytes mode is explicitly specified through the use
> of a flag called packet_mode that is added to the WRED and shaper profile.
> When packet_mode is 0, the profile rates and bucket sizes are specified in
> bytes per second and bytes, respectively; when packet_mode is not 0, the
> profile rates and bucket sizes are specified in packets and packets per second,
> respectively. The same profile parameters are used, no need to invent
> additional algorithms (such as srTCM - packet mode) or profile data structures.
> Can we do the same here, please?
This flag approach is very intuitive suggestion and it has advantages.
The main problem with the flag approach is that it breaks ABI and API.
The profile structure size is changed due to a new field - ABI breakage.
The user must initialize the flag with zero to get old behavior - API breakage.
I don't see issues with Li suggestion, Do you think Li suggestion has critical issues?
> This is a quick summary of the required API changes to add support for the
> packet mode, they are minimal:
> a) Introduce the packet_mode flag in the profile parameters data structure.
> b) Change the description (comment) of the rate and bucket size parameters in
> the meter profile parameters data structures to reflect that their values
> represents either bytes or packets, depending on the value of the new flag
> packet_mode from the same structure.
> c) Add the relevant capabilities: just search for "packet" in the rte_tm.h
> capabilities data structures and apply the same to the rte_mtr.h capabilities,
> when applicable.
> Regards,
> Cristian
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] 20.11.1 patches review and test
2021-03-02 6:23 0% ` Kalesh Anakkur Purayil
@ 2021-03-02 10:29 0% ` Luca Boccassi
0 siblings, 0 replies; 200+ results
From: Luca Boccassi @ 2021-03-02 10:29 UTC (permalink / raw)
To: Kalesh Anakkur Purayil
Cc: dpdk stable, dpdk-dev, Abhishek Marathe, Akhil Goyal,
Ali Alnubani, benjamin.walker, David Christensen,
Hariprasad Govindharajan, Hemant Agrawal, Ian Stokes,
Jerin Jacob, John McNamara, Ju-Hyoung Lee, Kevin Traynor,
Pei Zhang, pingx.yu, qian.q.xu, Raslan Darawsheh,
Thomas Monjalon, yuan.peng, zhaoyan.chen
On Tue, 2021-03-02 at 11:53 +0530, Kalesh Anakkur Purayil wrote:
> Hi Luca,
>
> Testing with dpdk v20.11.1 from Broadcom looks good.
>
> - Basic functionality:
> Send and receive multiple types of traffic.
> - Changing/checking link status through testpmd.
> - RSS tests.
> - TSO tests
> - VLAN filtering tests.
> - MAC filtering test
> - statistics tests
> - Checksum offload tests
> - MTU tests
> - Promiscuous tests
>
> NIC: BCM57414 NetXtreme-E 10Gb/25Gb Ethernet Controller, Firmware: 218.1.186.0
> NIC: BCM57508 NetXtreme-E 10Gb/25Gb/40Gb/50Gb/100Gb/200Gb Ethernet, Firmware : 219.0.0.74
>
> Regards,
> Kalesh
Thank you!
> On Mon, Feb 22, 2021 at 8:39 PM <luca.boccassi@gmail.com> wrote:
> > Hi all,
> >
> > Here is a list of patches targeted for stable release 20.11.1.
> >
> > The planned date for the final release is the 8th of March.
> >
> > Please help with testing and validation of your use cases and report
> > any issues/results with reply-all to this mail. For the final release
> > the fixes and reported validations will be added to the release notes.
> >
> > A release candidate tarball can be found at:
> >
> > https://dpdk.org/browse/dpdk-stable/tag/?id=v20.11.1-rc1
> >
> > These patches are located at branch 20.11 of dpdk-stable repo:
> > https://dpdk.org/browse/dpdk-stable/
> >
> > Thanks.
> >
> > Luca Boccassi
> >
> > ---
> > Ajit Khaparde (3):
> > net/bnxt: fix cleanup on mutex init failure
> > net/bnxt: fix format specifier for unsigned int
> > net/bnxt: fix freeing mbuf
> >
> > Alexander Kozyrev (4):
> > net/mlx5: fix mbuf freeing in vectorized MPRQ
> > net/mlx5: fix flow tag decompression
> > net/mlx5: check FW miniCQE format capabilities
> > net/mlx5: fix miniCQE configuration for Verbs
> >
> > Alvin Zhang (9):
> > net/ixgbe: detect failed VF MTU set
> > net/i40e: fix Rx bytes statistics
> > net/iavf: fix queue pairs configuration
> > doc: fix RSS flow description in i40e guide
> > net/i40e: fix returned code for RSS hardware failure
> > net/ice: fix RSS lookup table initialization
> > test: fix buffer overflow in Tx burst
> > net/ixgbe: fix configuration of max frame size
> > app/testpmd: fix key for RSS flow rule
> >
> > Amit Bernstein (1):
> > net/ena: fix Tx doorbell statistics
> >
> > Anatoly Burakov (1):
> > fbarray: fix overlap check
> >
> > Andrew Boyer (5):
> > net/ionic: do minor logging fixups
> > net/ionic: fix link speed and autonegotiation
> > net/ionic: allow separate L3 and L4 checksum offload
> > net/ionic: fix up function attribute tags
> > net/ionic: fix address handling in Tx
> >
> > Ankur Dwivedi (1):
> > test/event_crypto: set cipher operation in transform
> >
> > Ashish Sadanandan (1):
> > mbuf: add C++ include guard for dynamic fields header
> >
> > Balazs Nemeth (1):
> > net/qede: fix promiscuous enable
> >
> > Beilei Xing (2):
> > net/i40e: fix global register recovery
> > net/i40e: fix flex payload rule conflict
> >
> > Bernard Iremonger (1):
> > doc: fix QinQ flow rules in testpmd guide
> >
> > Bruce Richardson (29):
> > ethdev: avoid blocking telemetry for link status
> > build: provide suitable error for "both" libraries option
> > eal: fix reciprocal header include
> > telemetry: fix missing header include
> > ethdev: fix missing header include
> > net: fix missing header include
> > mbuf: fix missing header include
> > bitrate: fix missing header include
> > rib: fix missing header includes
> > vhost: fix missing header includes
> > ipsec: fix missing header include
> > fib: fix missing header includes
> > table: fix missing header include
> > pipeline: fix missing header includes
> > metrics: fix variable declaration in header
> > node: fix missing header include
> > app: fix build with extra include paths
> > build: force pkg-config for dependency detection
> > power: create guest channel public header file
> > power: make channel message functions public
> > power: rename public structs
> > power: rename constants
> > power: export guest channel header file
> > power: clean up includes
> > eal: fix MCS lock header include
> > eal: fix internal ABI tag with clang
> > power: fix missing header includes
> > rib: fix missing header include
> > eal: fix automatic loading of drivers as shared libs
> >
> > Chengchang Tang (7):
> > net/hns3: fix register length when dumping registers
> > net/hns3: fix data overwriting during register dump
> > net/hns3: fix dump register out of range
> > net/hns3: fix interrupt resources in Rx interrupt mode
> > net/hns3: fix firmware exceptions by concurrent commands
> > net/hns3: fix VF reset on mailbox failure
> > net/hns3: fix stats flip overflow
> >
> > Chengwen Feng (3):
> > net/hns3: fix VF query link status in dev init
> > net/hns3: remove MPLS from supported flow items
> > net/hns3: fix flow director rule residue on malloc failure
> >
> > Ciara Power (3):
> > app/crypto-perf: fix spelling in output
> > app/crypto-perf: fix latency CSV output
> > app/crypto-perf: fix CSV output format
> >
> > Cristian Dumitrescu (1):
> > examples/pipeline: fix CLI parsing crash
> >
> > Dapeng Yu (4):
> > net/ixgbe: fix flex bytes flow director rule
> > net/ice: check Rx queue number on RSS init
> > net/ixgbe: disable NFS filtering
> > app/testpmd: avoid exit without terminal restore
> >
> > David Marchand (3):
> > net/hinic: restore vectorised code
> > examples/pipeline: fix VXLAN script permission
> > mbuf: remove unneeded atomic generic header include
> >
> > Dekel Peled (8):
> > net/mlx5: fix shared age action validation
> > net/mlx5: fix hairpin flow split decision
> > net/mlx5: fix flow split combined with counter
> > net/mlx5: fix flow split combined with age action
> > net/mlx5: fix shared RSS translation and cleanup
> > app/testpmd: support shared age action query
> > net/mlx5: fix shared RSS capability check
> > net/mlx5: validate hash Rx queue pointer
> >
> > Dmitry Kozlyuk (4):
> > eal/windows: fix build with MinGW-w64 8
> > bus/pci: fix build with MinGW-w64 8
> > bus/pci: fix hardware ID limit on Windows
> > build: fix linker flags on Windows
> >
> > Eugeny Parshutin (1):
> > doc: add vtune profiling config to prog guide
> >
> > Fan Zhang (1):
> > crypto/qat: fix digest in buffer
> >
> > Fei Chen (1):
> > vhost: fix vid allocation race
> >
> > Feifei Wang (7):
> > test/ring: reduce duration of performance tests
> > app/eventdev: adjust event count order for pipeline test
> > app/eventdev: remove redundant enqueue in burst Tx
> > examples/eventdev: check CPU core enabling
> > examples/eventdev: add info output for main core
> > examples/eventdev: move ethdev stop to the end
> > app/eventdev: fix SMP barrier in performance test
> >
> > Ferruh Yigit (13):
> > app/procinfo: fix _filters stats reporting
> > app/procinfo: fix check on xstats-ids
> > app/procinfo: remove useless memset
> > app/procinfo: remove useless assignment
> > net/pcap: remove local variable shadowing outer one
> > net/bonding: remove local variable shadowing outer one
> > net/af_xdp: remove useless assignment
> > net/bnxt: remove redundant return
> > app/crypto-perf: remove always true condition
> > net/avp: remove always true condition
> > net/pcap: fix byte stats for drop Tx
> > net/pcap: fix infinite Rx with large files
> > app/testpmd: fix help of metering commands
> >
> > Gaetan Rivet (2):
> > net/bonding: fix port id validity check on parsing
> > net/bonding: fix PCI address comparison on non-PCI ports
> >
> > Gagandeep Singh (2):
> > test/ipsec: fix result code for not supported
> > crypto/dpaa2_sec: fix memory allocation check
> >
> > George Prekas (1):
> > app/testpmd: fix IP checksum calculation
> >
> > Gregory Etelson (5):
> > net/mlx5: fix Direct Verbs flow descriptor allocation
> > app/testpmd: release flows left before port stop
> > net/mlx5: fix tunnel rules validation on VF representor
> > net/mlx5: fix mark action in active tunnel offload
> > net/mlx5: fix drop action in tunnel offload mode
> >
> > Guy Kaneti (1):
> > regex/octeontx2: fix PCI table overflow
> >
> > Haiyue Wang (2):
> > net/ice: drain out DCF AdminQ command queue
> > net/ixgbe: fix UDP zero checksum on x86
> >
> > Harman Kalra (1):
> > examples/l3fwd: remove limitation on Tx queue count
> >
> > Harry van Haaren (1):
> > eventdev: fix a return value comment
> >
> > Heinrich Kuhn (1):
> > net/nfp: read chip model from PluDevice register
> >
> > Hemant Agrawal (1):
> > app/procinfo: fix security context info
> >
> > Hongbo Zheng (1):
> > net/hns3: use new opcode for clearing hardware resource
> >
> > Huisong Li (7):
> > app/testpmd: fix queue stats mapping configuration
> > net/hns3: fix xstats with id and names
> > net/hns3: fix error code in xstats
> > net/hns3: fix Rx/Tx errors stats
> > net/hns3: fix link status change from firmware
> > net/hns3: validate requested maximum Rx frame length
> > net/hns3: fix query order of link status and link info
> >
> > Hyong Youb Kim (2):
> > net/enic: fix filter type used for flow API
> > net/enic: fix filter log message
> >
> > Ido Segev (1):
> > net/ena: flush Rx buffers memory pool cache
> >
> > Igor Chauskin (2):
> > net/ena: fix Tx SQ free space assessment
> > net/ena: prevent double doorbell
> >
> > Igor Ryzhov (1):
> > net/i40e: fix stats counters
> >
> > Ivan Malov (11):
> > common/sfc_efx/base: remove warnings about inline specifiers
> > common/sfc_efx/base: fix signed/unsigned mismatch warnings
> > common/sfc_efx/base: support alternative MAE match fields
> > common/sfc_efx/base: update MCDI headers for MAE privilege
> > common/sfc_efx/base: check for MAE privilege
> > common/sfc_efx/base: fix MPORT related byte order handling
> > common/sfc_efx/base: fix MAE match spec validation helper
> > common/sfc_efx/base: fix MAE match spec class comparison API
> > common/sfc_efx/base: enhance field ID check in field set API
> > common/sfc_efx/base: apply mask to value on match field set
> > net/sfc: fix TSO and checksum offloads for EF10
> >
> > Jiawei Wang (4):
> > net/mlx5: fix unnecessary checking for RSS action
> > app/testpmd: fix packets dump overlapping
> > net/mlx5: fix count actions query in sample flow
> > net/mlx5: fix counter and age flow action validation
> >
> > Jiawei Zhu (1):
> > net/virtio-user: fix run closing stdin and close callfd
> >
> > Jingjing Wu (1):
> > net/iavf: fix vector mapping with queue
> >
> > John McNamara (1):
> > license: add licenses for exception cases
> >
> > Joyce Kong (1):
> > eal/arm: fix debug build with gcc for 128-bit atomics
> >
> > Junfeng Guo (1):
> > net/iavf: fix GTPU UL and DL support for flow director
> >
> > Kalesh AP (4):
> > net/bnxt: release HWRM lock in error
> > net/bnxt: propagate FW command failure to application
> > net/bnxt: fix VNIC RSS configure function
> > net/bnxt: fix FW version log
> >
> > Karra Satwik (2):
> > net/cxgbe: accept VLAN flow items without ethertype
> > app/testpmd: fix start index for showing FEC array
> >
> > Lance Richardson (10):
> > net/bnxt: disable end of packet padding for Rx
> > net/bnxt: limit Rx representor packets per poll
> > net/bnxt: fix doorbell write ordering
> > net/bnxt: fix outer UDP checksum Rx offload capability
> > net/bnxt: make offload flags mapping per-ring
> > net/bnxt: set correct checksum status in mbuf
> > net/bnxt: fix packet type index calculation
> > net/bnxt: fix null termination of Rx mbuf chain
> > net/bnxt: fix fallback mbuf allocation logic
> > net/bnxt: fix Rx completion ring size calculation
> >
> > Leyi Rong (1):
> > net/ice: enlarge Rx queue rearm threshold to 64
> >
> > Lijun Ou (6):
> > net/hns3: fix interception with flow director
> > net/hns3: fix memory leak on secondary process exit
> > net/hns3: adjust some comments
> > net/hns3: adjust format specifier for enum
> > doc: fix product link in hns3 guide
> > net/hns3: fix RSS indirection table size
> >
> > Liron Himi (5):
> > net/octeontx2: fix PF flow action for Tx
> > net/mvpp2: remove debug log on fast-path
> > net/mvpp2: remove VLAN flush
> > net/mvpp2: remove CRC length from MRU validation
> > net/mvpp2: fix frame size checking
> >
> > Long Li (1):
> > net/netvsc: ignore unsupported packet on sync command
> >
> > Lukasz Wojciechowski (1):
> > test/distributor: fix return buffer queue overload
> >
> > Marvin Liu (1):
> > vhost: fix packed ring dequeue offloading
> >
> > Matan Azrad (1):
> > vdpa/mlx5: fix configuration mutex cleanup
> >
> > Maxime Coquelin (3):
> > net/virtio: add missing backend features negotiation
> > net/virtio: fix memory init with vDPA backend
> > net/virtio: fix getting old status on reconnect
> >
> > Michael Baum (7):
> > net/mlx5: fix leak on Rx queue creation failure
> > net/mlx5: fix leak on Tx queue creation failure
> > common/mlx5: fix completion queue entry size configuration
> > net/mlx5: remove CQE padding device argument
> > net/mlx5: fix leak on ASO SQ creation failure
> > net/mlx4: fix device detach
> > net/mlx4: fix handling of probing failure
> >
> > Michal Krawczyk (1):
> > net/ena: validate Rx req ID upon acquiring descriptor
> >
> > Min Hu (Connor) (3):
> > net/hns3: fix FEC state query
> > net/hns3: fix crash with multi-process
> > doc: add FEC to NIC features
> >
> > Murphy Yang (6):
> > net/ice: fix outer UDP Tx checksum offload
> > net/i40e: fix L4 checksum flag
> > net/ice: fix outer checksum flags
> > net/iavf: fix conflicting RSS combination rules
> > net/ice: disable IPv4 checksum offload in vector Tx
> > net/i40e: add null input checks
> >
> > Nick Connolly (2):
> > eal/windows: fix debug build with MinGW
> > eal/windows: fix vfprintf warning with clang
> >
> > Olivier Matz (5):
> > build: fix plugin load on static build
> > net/virtio-user: fix protocol features advertising
> > service: propagate init error in EAL
> > test/mcslock: remove unneeded per lcore copy
> > mempool: fix panic on dump or audit
> >
> > Ophir Munk (4):
> > net/mlx5: fix freeing packet pacing
> > net/mlx5: fix flow action destroy wrapper
> > net/mlx5: fix flow operation wrapper per OS
> > net/mlx5: unify operations for all OS
> >
> > Ori Kam (3):
> > regex/mlx5: fix memory rule alignment
> > regex/mlx5: fix support for group id
> > regex/mlx5: fix number of supported queues
> >
> > Qi Zhang (4):
> > doc: fix some statements for ice vector PMD
> > net/ice/base: fix tunnel destroy
> > net/ice/base: fix null pointer dereference
> > net/ice/base: fix memory handling
> >
> > Ruifeng Wang (4):
> > lpm: fix vector IPv4 lookup
> > net/hns3: fix build with SVE
> > net/octeontx: fix build with SVE
> > common/octeontx2: fix build with SVE
> >
> > Samik Gupta (2):
> > net/bnxt: fix Rx rings in RSS redirection table
> > net/bnxt: fix VNIC config on Rx queue stop
> >
> > Shiri Kuzin (2):
> > net/mlx5: fix VXLAN decap on non-VXLAN flow
> > net/mlx5: refuse empty VLAN in flow pattern
> >
> > Somnath Kotur (4):
> > net/bnxt: fix PF resource query
> > net/bnxt: fix lock init and destroy
> > net/bnxt: fix error handling in device start
> > net/bnxt: refactor init/uninit
> >
> > Souvik Dey (2):
> > net/i40e: fix VLAN stripping in VF
> > common/mlx5: fix storing synced MAC to internal table
> >
> > Sriharsha Basavapatna (1):
> > net/bnxt: fix max rings computation
> >
> > Stephen Hemminger (2):
> > test/rwlock: fix spelling and missing whitespace
> > test: fix terminal settings on exit
> >
> > Steve Yang (23):
> > ethdev: fix max Rx packet length check
> > app/testpmd: fix max Rx packet length for VLAN packets
> > net/dpaa: fix jumbo frame flag condition for MTU set
> > net/dpaa2: fix jumbo frame flag condition for MTU set
> > net/e1000: fix jumbo frame flag condition for MTU set
> > net/hns3: fix jumbo frame flag condition for MTU set
> > net/i40e: fix jumbo frame flag condition
> > net/iavf: fix jumbo frame flag condition
> > net/ice: fix jumbo frame flag condition
> > net/ipn3ke: fix jumbo frame flag condition for MTU set
> > net/octeontx: fix jumbo frame flag condition for MTU set
> > net/octeontx2: fix jumbo frame flag condition for MTU
> > net/qede: fix jumbo frame flag condition for MTU set
> > net/sfc: fix jumbo frame flag condition for MTU set
> > net/thunderx: fix jumbo frame flag condition for MTU set
> > net/ixgbe: fix jumbo frame flag condition
> > net/cxgbe: fix jumbo frame flag condition
> > net/axgbe: fix jumbo frame flag condition for MTU set
> > net/enetc: fix jumbo frame flag condition for MTU set
> > net/hinic: fix jumbo frame flag condition for MTU set
> > net/nfp: fix jumbo frame flag condition for MTU set
> > net/liquidio: fix jumbo frame flag condition for MTU set
> > app/testpmd: fix setting maximum packet length
> >
> > Suanming Mou (5):
> > net/mlx5: fix shared RSS and mark actions combination
> > net/mlx5: fix multi-process port ID
> > net/mlx5: fix crash on secondary process port close
> > net/mlx5: fix port attach in secondary process
> > net/mlx4: fix port attach in secondary process
> >
> > Sunil Kumar Kori (2):
> > net/octeontx2: fix corruption in segments list
> > net/octeontx: fix max Rx packet length
> >
> > Tal Shnaiderman (5):
> > bus/pci: ignore missing NUMA node on Windows
> > net/mlx5: fix constant array size
> > net/mlx5: fix device name size on Windows
> > net/mlx5: fix comparison sign in flow engine
> > common/mlx5: fix pointer cast on Windows
> >
> > Thomas Monjalon (3):
> > doc: fix figure numbering in graph guide
> > lib: fix doxygen for parameters of function pointers
> > ethdev: fix close failure handling
> >
> > Timothy McDaniel (1):
> > event/dlb: fix accessing uninitialized variables
> >
> > Ting Xu (1):
> > net/iavf: fix memory leak in large VF
> >
> > Tyler Retzlaff (2):
> > bus/pci: fix build with Windows SDK >= 10.0.20253
> > eal/windows: fix C++ compatibility
> >
> > Viacheslav Galaktionov (1):
> > net/sfc: fix generic byte statistics to exclude FCS bytes
> >
> > Viacheslav Ovsiienko (8):
> > net/mlx5: fix Verbs memory allocation callback
> > net/mlx5: fix buffer split offload advertising
> > doc: update flow mark action in mlx5 guide
> > net/mlx5: fix wire vport hint
> > app/testpmd: fix queue reconfig request on Rx split update
> > doc: fix supported feature table in mlx5 guide
> > doc: fix mark action zero value in mlx5 guide
> > net/mlx5: fix Tx queue size created with DevX
> >
> > Vladimir Medvedkin (2):
> > rib: fix insertion in some cases
> > crypto/qat: fix access to uninitialized variable
> >
> > Weifeng Li (1):
> > net/i40e: fix X722 for 802.1ad frames ability
> >
> > Wenjun Wu (1):
> > net/e1000: fix flow control mode setting
> >
> > Wisam Jaddo (1):
> > app/flow-perf: simplify objects initialization
> >
> > Xuan Ding (1):
> > net/iavf: fix symmetric flow rule creation
> >
> > Yicai Lu (1):
> > ip_frag: remove padding length of fragment
> >
> > Yongxin Liu (1):
> > usertools: fix binding built-in kernel driver
> >
> > Yunjian Wang (3):
> > eal/linux: fix handling of error events from epoll
> > net/bnxt: fix memory leak when mapping fails
> > net/mvneta: check allocation in Rx queue flush
> >
> > Yuri Chipchev (1):
> > net/mvpp2: fix stack corruption
>
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] 20.11.1 patches review and test
2021-02-22 15:09 1% [dpdk-dev] 20.11.1 patches review and test luca.boccassi
` (2 preceding siblings ...)
2021-03-02 6:23 0% ` Kalesh Anakkur Purayil
@ 2021-03-02 10:52 0% ` Chen, BoX C
2021-03-02 11:27 0% ` Luca Boccassi
3 siblings, 1 reply; 200+ results
From: Chen, BoX C @ 2021-03-02 10:52 UTC (permalink / raw)
To: luca.boccassi, stable
Cc: dev, Abhishek Marathe, Akhil Goyal, Ali Alnubani, Walker,
Benjamin, David Christensen, Govindharajan, Hariprasad,
Hemant Agrawal, Stokes, Ian, Jerin Jacob, Mcnamara, John,
Ju-Hyoung Lee, Kevin Traynor, Luca Boccassi, Pei Zhang, Yu,
PingX, Xu, Qian Q, Raslan Darawsheh, Thomas Monjalon, Peng, Yuan,
Chen, Zhaoyan
Hi Luca,
Testing with dpdk v20.11.1 from Intel looks good.
# Basic Intel(R) NIC testing
*PF(i40e, ixgbe)： test scenarios including rte_flow/TSO/Jumboframe/checksum offload/Tunnel, etc. Listed but not all.
- No new issue are found.
*VF(i40e,ixgbe): test scenarios including vf-rte_flow/TSO/Jumboframe/checksum offload/Tunnel, Listed but not all.
- No new issues are found.
*PF/VF(ice): test scenarios including Switch features/Flow Director/Advanced RSS/ACL/DCF/Flexible Descriptor and so on, Listed but not all.
- No new issues are found. one known issue: can't create 512 acl rules after creating a full mask switch rule. This issue is also occurred in dpdk 20.11 and no fix patch.
* Build or compile:
* Build: cover the build test combination with latest GCC/Clang/ICC version and the popular OS revision such as Ubuntu20.04, CentOS 8.3 and so on. Listed but not all.
- All passed.
* Compile: cover the CFLAGES(O0/O1/O2/O3) with popular OS such as Ubuntu20.04 and CentOS 8.3.
- All passed.
* Intel NIC single core/NIC performance: test scenarios including PF/VF single core performance test(AVX2+AVX512)，RFC2544 Zero packet loss performance test and so on. Listed but not all.
- All passed. No big data drop.
* Power and IPsec: test scenarios including Telemetry/Empty Poll Lib/Priority Base Frequency and so on.
- All passed.
# Basic cryptodev and virtio testing
* Virtio: both function and performance test are covered. Such as PVP/Virtio_loopback/virtio-user loopback/virtio-net VM2VM perf testing/VMAWARE ESXI 7.0u1, etc.. Listed but not all.
- No new issues are found. two known issues:(1)The UDP fragmentation offload feature of Virtio-net device can’t be turned on in the VM, bugzilla has been submited:https://bugzilla.kernel.org/show_bug.cgi?id=207075
(2)vm2vm virtio-net cbdma enable test scp file between two vm random fail due to lost connection after vhost reconnect. This issue is also occurred in dpdk 20.11 and no fix patch.
* Cryptodev:
- Function test: test scenarios including Cryptodev API testing/CompressDev ISA-L/QAT/ZLIB PMD Testing/FIPS, etc. Listed but not all.
- All passed.
- Performance test: test scenarios including Thoughput Performance /Cryptodev Latency, etc. Listed but not all.
- No big data drop.
Regards,
Chen Bo
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of luca.boccassi@gmail.com
> Sent: February 22, 2021 23:09
> To: stable@dpdk.org
> Cc: dev@dpdk.org; Abhishek Marathe <Abhishek.Marathe@microsoft.com>;
> Akhil Goyal <akhil.goyal@nxp.com>; Ali Alnubani <alialnu@nvidia.com>;
> Walker, Benjamin <benjamin.walker@intel.com>; David Christensen
> <drc@linux.vnet.ibm.com>; Govindharajan, Hariprasad
> <hariprasad.govindharajan@intel.com>; Hemant Agrawal
> <hemant.agrawal@nxp.com>; Stokes, Ian <ian.stokes@intel.com>; Jerin
> Jacob <jerinj@marvell.com>; Mcnamara, John <john.mcnamara@intel.com>;
> Ju-Hyoung Lee <juhlee@microsoft.com>; Kevin Traynor
> <ktraynor@redhat.com>; Luca Boccassi <bluca@debian.org>; Pei Zhang
> <pezhang@redhat.com>; Yu, PingX <pingx.yu@intel.com>; Xu, Qian Q
> <qian.q.xu@intel.com>; Raslan Darawsheh <rasland@nvidia.com>; Thomas
> Monjalon <thomas@monjalon.net>; Peng, Yuan <yuan.peng@intel.com>;
> Chen, Zhaoyan <zhaoyan.chen@intel.com>
> Subject: [dpdk-dev] 20.11.1 patches review and test
>
> Hi all,
>
> Here is a list of patches targeted for stable release 20.11.1.
>
> The planned date for the final release is the 8th of March.
>
> Please help with testing and validation of your use cases and report any
> issues/results with reply-all to this mail. For the final release the fixes and
> reported validations will be added to the release notes.
>
> A release candidate tarball can be found at:
>
> https://dpdk.org/browse/dpdk-stable/tag/?id=v20.11.1-rc1
>
> These patches are located at branch 20.11 of dpdk-stable repo:
> https://dpdk.org/browse/dpdk-stable/
>
> Thanks.
>
> Luca Boccassi
>
> ---
> Ajit Khaparde (3):
> net/bnxt: fix cleanup on mutex init failure
> net/bnxt: fix format specifier for unsigned int
> net/bnxt: fix freeing mbuf
>
> Alexander Kozyrev (4):
> net/mlx5: fix mbuf freeing in vectorized MPRQ
> net/mlx5: fix flow tag decompression
> net/mlx5: check FW miniCQE format capabilities
> net/mlx5: fix miniCQE configuration for Verbs
>
> Alvin Zhang (9):
> net/ixgbe: detect failed VF MTU set
> net/i40e: fix Rx bytes statistics
> net/iavf: fix queue pairs configuration
> doc: fix RSS flow description in i40e guide
> net/i40e: fix returned code for RSS hardware failure
> net/ice: fix RSS lookup table initialization
> test: fix buffer overflow in Tx burst
> net/ixgbe: fix configuration of max frame size
> app/testpmd: fix key for RSS flow rule
>
> Amit Bernstein (1):
> net/ena: fix Tx doorbell statistics
>
> Anatoly Burakov (1):
> fbarray: fix overlap check
>
> Andrew Boyer (5):
> net/ionic: do minor logging fixups
> net/ionic: fix link speed and autonegotiation
> net/ionic: allow separate L3 and L4 checksum offload
> net/ionic: fix up function attribute tags
> net/ionic: fix address handling in Tx
>
> Ankur Dwivedi (1):
> test/event_crypto: set cipher operation in transform
>
> Ashish Sadanandan (1):
> mbuf: add C++ include guard for dynamic fields header
>
> Balazs Nemeth (1):
> net/qede: fix promiscuous enable
>
> Beilei Xing (2):
> net/i40e: fix global register recovery
> net/i40e: fix flex payload rule conflict
>
> Bernard Iremonger (1):
> doc: fix QinQ flow rules in testpmd guide
>
> Bruce Richardson (29):
> ethdev: avoid blocking telemetry for link status
> build: provide suitable error for "both" libraries option
> eal: fix reciprocal header include
> telemetry: fix missing header include
> ethdev: fix missing header include
> net: fix missing header include
> mbuf: fix missing header include
> bitrate: fix missing header include
> rib: fix missing header includes
> vhost: fix missing header includes
> ipsec: fix missing header include
> fib: fix missing header includes
> table: fix missing header include
> pipeline: fix missing header includes
> metrics: fix variable declaration in header
> node: fix missing header include
> app: fix build with extra include paths
> build: force pkg-config for dependency detection
> power: create guest channel public header file
> power: make channel message functions public
> power: rename public structs
> power: rename constants
> power: export guest channel header file
> power: clean up includes
> eal: fix MCS lock header include
> eal: fix internal ABI tag with clang
> power: fix missing header includes
> rib: fix missing header include
> eal: fix automatic loading of drivers as shared libs
>
> Chengchang Tang (7):
> net/hns3: fix register length when dumping registers
> net/hns3: fix data overwriting during register dump
> net/hns3: fix dump register out of range
> net/hns3: fix interrupt resources in Rx interrupt mode
> net/hns3: fix firmware exceptions by concurrent commands
> net/hns3: fix VF reset on mailbox failure
> net/hns3: fix stats flip overflow
>
> Chengwen Feng (3):
> net/hns3: fix VF query link status in dev init
> net/hns3: remove MPLS from supported flow items
> net/hns3: fix flow director rule residue on malloc failure
>
> Ciara Power (3):
> app/crypto-perf: fix spelling in output
> app/crypto-perf: fix latency CSV output
> app/crypto-perf: fix CSV output format
>
> Cristian Dumitrescu (1):
> examples/pipeline: fix CLI parsing crash
>
> Dapeng Yu (4):
> net/ixgbe: fix flex bytes flow director rule
> net/ice: check Rx queue number on RSS init
> net/ixgbe: disable NFS filtering
> app/testpmd: avoid exit without terminal restore
>
> David Marchand (3):
> net/hinic: restore vectorised code
> examples/pipeline: fix VXLAN script permission
> mbuf: remove unneeded atomic generic header include
>
> Dekel Peled (8):
> net/mlx5: fix shared age action validation
> net/mlx5: fix hairpin flow split decision
> net/mlx5: fix flow split combined with counter
> net/mlx5: fix flow split combined with age action
> net/mlx5: fix shared RSS translation and cleanup
> app/testpmd: support shared age action query
> net/mlx5: fix shared RSS capability check
> net/mlx5: validate hash Rx queue pointer
>
> Dmitry Kozlyuk (4):
> eal/windows: fix build with MinGW-w64 8
> bus/pci: fix build with MinGW-w64 8
> bus/pci: fix hardware ID limit on Windows
> build: fix linker flags on Windows
>
> Eugeny Parshutin (1):
> doc: add vtune profiling config to prog guide
>
> Fan Zhang (1):
> crypto/qat: fix digest in buffer
>
> Fei Chen (1):
> vhost: fix vid allocation race
>
> Feifei Wang (7):
> test/ring: reduce duration of performance tests
> app/eventdev: adjust event count order for pipeline test
> app/eventdev: remove redundant enqueue in burst Tx
> examples/eventdev: check CPU core enabling
> examples/eventdev: add info output for main core
> examples/eventdev: move ethdev stop to the end
> app/eventdev: fix SMP barrier in performance test
>
> Ferruh Yigit (13):
> app/procinfo: fix _filters stats reporting
> app/procinfo: fix check on xstats-ids
> app/procinfo: remove useless memset
> app/procinfo: remove useless assignment
> net/pcap: remove local variable shadowing outer one
> net/bonding: remove local variable shadowing outer one
> net/af_xdp: remove useless assignment
> net/bnxt: remove redundant return
> app/crypto-perf: remove always true condition
> net/avp: remove always true condition
> net/pcap: fix byte stats for drop Tx
> net/pcap: fix infinite Rx with large files
> app/testpmd: fix help of metering commands
>
> Gaetan Rivet (2):
> net/bonding: fix port id validity check on parsing
> net/bonding: fix PCI address comparison on non-PCI ports
>
> Gagandeep Singh (2):
> test/ipsec: fix result code for not supported
> crypto/dpaa2_sec: fix memory allocation check
>
> George Prekas (1):
> app/testpmd: fix IP checksum calculation
>
> Gregory Etelson (5):
> net/mlx5: fix Direct Verbs flow descriptor allocation
> app/testpmd: release flows left before port stop
> net/mlx5: fix tunnel rules validation on VF representor
> net/mlx5: fix mark action in active tunnel offload
> net/mlx5: fix drop action in tunnel offload mode
>
> Guy Kaneti (1):
> regex/octeontx2: fix PCI table overflow
>
> Haiyue Wang (2):
> net/ice: drain out DCF AdminQ command queue
> net/ixgbe: fix UDP zero checksum on x86
>
> Harman Kalra (1):
> examples/l3fwd: remove limitation on Tx queue count
>
> Harry van Haaren (1):
> eventdev: fix a return value comment
>
> Heinrich Kuhn (1):
> net/nfp: read chip model from PluDevice register
>
> Hemant Agrawal (1):
> app/procinfo: fix security context info
>
> Hongbo Zheng (1):
> net/hns3: use new opcode for clearing hardware resource
>
> Huisong Li (7):
> app/testpmd: fix queue stats mapping configuration
> net/hns3: fix xstats with id and names
> net/hns3: fix error code in xstats
> net/hns3: fix Rx/Tx errors stats
> net/hns3: fix link status change from firmware
> net/hns3: validate requested maximum Rx frame length
> net/hns3: fix query order of link status and link info
>
> Hyong Youb Kim (2):
> net/enic: fix filter type used for flow API
> net/enic: fix filter log message
>
> Ido Segev (1):
> net/ena: flush Rx buffers memory pool cache
>
> Igor Chauskin (2):
> net/ena: fix Tx SQ free space assessment
> net/ena: prevent double doorbell
>
> Igor Ryzhov (1):
> net/i40e: fix stats counters
>
> Ivan Malov (11):
> common/sfc_efx/base: remove warnings about inline specifiers
> common/sfc_efx/base: fix signed/unsigned mismatch warnings
> common/sfc_efx/base: support alternative MAE match fields
> common/sfc_efx/base: update MCDI headers for MAE privilege
> common/sfc_efx/base: check for MAE privilege
> common/sfc_efx/base: fix MPORT related byte order handling
> common/sfc_efx/base: fix MAE match spec validation helper
> common/sfc_efx/base: fix MAE match spec class comparison API
> common/sfc_efx/base: enhance field ID check in field set API
> common/sfc_efx/base: apply mask to value on match field set
> net/sfc: fix TSO and checksum offloads for EF10
>
> Jiawei Wang (4):
> net/mlx5: fix unnecessary checking for RSS action
> app/testpmd: fix packets dump overlapping
> net/mlx5: fix count actions query in sample flow
> net/mlx5: fix counter and age flow action validation
>
> Jiawei Zhu (1):
> net/virtio-user: fix run closing stdin and close callfd
>
> Jingjing Wu (1):
> net/iavf: fix vector mapping with queue
>
> John McNamara (1):
> license: add licenses for exception cases
>
> Joyce Kong (1):
> eal/arm: fix debug build with gcc for 128-bit atomics
>
> Junfeng Guo (1):
> net/iavf: fix GTPU UL and DL support for flow director
>
> Kalesh AP (4):
> net/bnxt: release HWRM lock in error
> net/bnxt: propagate FW command failure to application
> net/bnxt: fix VNIC RSS configure function
> net/bnxt: fix FW version log
>
> Karra Satwik (2):
> net/cxgbe: accept VLAN flow items without ethertype
> app/testpmd: fix start index for showing FEC array
>
> Lance Richardson (10):
> net/bnxt: disable end of packet padding for Rx
> net/bnxt: limit Rx representor packets per poll
> net/bnxt: fix doorbell write ordering
> net/bnxt: fix outer UDP checksum Rx offload capability
> net/bnxt: make offload flags mapping per-ring
> net/bnxt: set correct checksum status in mbuf
> net/bnxt: fix packet type index calculation
> net/bnxt: fix null termination of Rx mbuf chain
> net/bnxt: fix fallback mbuf allocation logic
> net/bnxt: fix Rx completion ring size calculation
>
> Leyi Rong (1):
> net/ice: enlarge Rx queue rearm threshold to 64
>
> Lijun Ou (6):
> net/hns3: fix interception with flow director
> net/hns3: fix memory leak on secondary process exit
> net/hns3: adjust some comments
> net/hns3: adjust format specifier for enum
> doc: fix product link in hns3 guide
> net/hns3: fix RSS indirection table size
>
> Liron Himi (5):
> net/octeontx2: fix PF flow action for Tx
> net/mvpp2: remove debug log on fast-path
> net/mvpp2: remove VLAN flush
> net/mvpp2: remove CRC length from MRU validation
> net/mvpp2: fix frame size checking
>
> Long Li (1):
> net/netvsc: ignore unsupported packet on sync command
>
> Lukasz Wojciechowski (1):
> test/distributor: fix return buffer queue overload
>
> Marvin Liu (1):
> vhost: fix packed ring dequeue offloading
>
> Matan Azrad (1):
> vdpa/mlx5: fix configuration mutex cleanup
>
> Maxime Coquelin (3):
> net/virtio: add missing backend features negotiation
> net/virtio: fix memory init with vDPA backend
> net/virtio: fix getting old status on reconnect
>
> Michael Baum (7):
> net/mlx5: fix leak on Rx queue creation failure
> net/mlx5: fix leak on Tx queue creation failure
> common/mlx5: fix completion queue entry size configuration
> net/mlx5: remove CQE padding device argument
> net/mlx5: fix leak on ASO SQ creation failure
> net/mlx4: fix device detach
> net/mlx4: fix handling of probing failure
>
> Michal Krawczyk (1):
> net/ena: validate Rx req ID upon acquiring descriptor
>
> Min Hu (Connor) (3):
> net/hns3: fix FEC state query
> net/hns3: fix crash with multi-process
> doc: add FEC to NIC features
>
> Murphy Yang (6):
> net/ice: fix outer UDP Tx checksum offload
> net/i40e: fix L4 checksum flag
> net/ice: fix outer checksum flags
> net/iavf: fix conflicting RSS combination rules
> net/ice: disable IPv4 checksum offload in vector Tx
> net/i40e: add null input checks
>
> Nick Connolly (2):
> eal/windows: fix debug build with MinGW
> eal/windows: fix vfprintf warning with clang
>
> Olivier Matz (5):
> build: fix plugin load on static build
> net/virtio-user: fix protocol features advertising
> service: propagate init error in EAL
> test/mcslock: remove unneeded per lcore copy
> mempool: fix panic on dump or audit
>
> Ophir Munk (4):
> net/mlx5: fix freeing packet pacing
> net/mlx5: fix flow action destroy wrapper
> net/mlx5: fix flow operation wrapper per OS
> net/mlx5: unify operations for all OS
>
> Ori Kam (3):
> regex/mlx5: fix memory rule alignment
> regex/mlx5: fix support for group id
> regex/mlx5: fix number of supported queues
>
> Qi Zhang (4):
> doc: fix some statements for ice vector PMD
> net/ice/base: fix tunnel destroy
> net/ice/base: fix null pointer dereference
> net/ice/base: fix memory handling
>
> Ruifeng Wang (4):
> lpm: fix vector IPv4 lookup
> net/hns3: fix build with SVE
> net/octeontx: fix build with SVE
> common/octeontx2: fix build with SVE
>
> Samik Gupta (2):
> net/bnxt: fix Rx rings in RSS redirection table
> net/bnxt: fix VNIC config on Rx queue stop
>
> Shiri Kuzin (2):
> net/mlx5: fix VXLAN decap on non-VXLAN flow
> net/mlx5: refuse empty VLAN in flow pattern
>
> Somnath Kotur (4):
> net/bnxt: fix PF resource query
> net/bnxt: fix lock init and destroy
> net/bnxt: fix error handling in device start
> net/bnxt: refactor init/uninit
>
> Souvik Dey (2):
> net/i40e: fix VLAN stripping in VF
> common/mlx5: fix storing synced MAC to internal table
>
> Sriharsha Basavapatna (1):
> net/bnxt: fix max rings computation
>
> Stephen Hemminger (2):
> test/rwlock: fix spelling and missing whitespace
> test: fix terminal settings on exit
>
> Steve Yang (23):
> ethdev: fix max Rx packet length check
> app/testpmd: fix max Rx packet length for VLAN packets
> net/dpaa: fix jumbo frame flag condition for MTU set
> net/dpaa2: fix jumbo frame flag condition for MTU set
> net/e1000: fix jumbo frame flag condition for MTU set
> net/hns3: fix jumbo frame flag condition for MTU set
> net/i40e: fix jumbo frame flag condition
> net/iavf: fix jumbo frame flag condition
> net/ice: fix jumbo frame flag condition
> net/ipn3ke: fix jumbo frame flag condition for MTU set
> net/octeontx: fix jumbo frame flag condition for MTU set
> net/octeontx2: fix jumbo frame flag condition for MTU
> net/qede: fix jumbo frame flag condition for MTU set
> net/sfc: fix jumbo frame flag condition for MTU set
> net/thunderx: fix jumbo frame flag condition for MTU set
> net/ixgbe: fix jumbo frame flag condition
> net/cxgbe: fix jumbo frame flag condition
> net/axgbe: fix jumbo frame flag condition for MTU set
> net/enetc: fix jumbo frame flag condition for MTU set
> net/hinic: fix jumbo frame flag condition for MTU set
> net/nfp: fix jumbo frame flag condition for MTU set
> net/liquidio: fix jumbo frame flag condition for MTU set
> app/testpmd: fix setting maximum packet length
>
> Suanming Mou (5):
> net/mlx5: fix shared RSS and mark actions combination
> net/mlx5: fix multi-process port ID
> net/mlx5: fix crash on secondary process port close
> net/mlx5: fix port attach in secondary process
> net/mlx4: fix port attach in secondary process
>
> Sunil Kumar Kori (2):
> net/octeontx2: fix corruption in segments list
> net/octeontx: fix max Rx packet length
>
> Tal Shnaiderman (5):
> bus/pci: ignore missing NUMA node on Windows
> net/mlx5: fix constant array size
> net/mlx5: fix device name size on Windows
> net/mlx5: fix comparison sign in flow engine
> common/mlx5: fix pointer cast on Windows
>
> Thomas Monjalon (3):
> doc: fix figure numbering in graph guide
> lib: fix doxygen for parameters of function pointers
> ethdev: fix close failure handling
>
> Timothy McDaniel (1):
> event/dlb: fix accessing uninitialized variables
>
> Ting Xu (1):
> net/iavf: fix memory leak in large VF
>
> Tyler Retzlaff (2):
> bus/pci: fix build with Windows SDK >= 10.0.20253
> eal/windows: fix C++ compatibility
>
> Viacheslav Galaktionov (1):
> net/sfc: fix generic byte statistics to exclude FCS bytes
>
> Viacheslav Ovsiienko (8):
> net/mlx5: fix Verbs memory allocation callback
> net/mlx5: fix buffer split offload advertising
> doc: update flow mark action in mlx5 guide
> net/mlx5: fix wire vport hint
> app/testpmd: fix queue reconfig request on Rx split update
> doc: fix supported feature table in mlx5 guide
> doc: fix mark action zero value in mlx5 guide
> net/mlx5: fix Tx queue size created with DevX
>
> Vladimir Medvedkin (2):
> rib: fix insertion in some cases
> crypto/qat: fix access to uninitialized variable
>
> Weifeng Li (1):
> net/i40e: fix X722 for 802.1ad frames ability
>
> Wenjun Wu (1):
> net/e1000: fix flow control mode setting
>
> Wisam Jaddo (1):
> app/flow-perf: simplify objects initialization
>
> Xuan Ding (1):
> net/iavf: fix symmetric flow rule creation
>
> Yicai Lu (1):
> ip_frag: remove padding length of fragment
>
> Yongxin Liu (1):
> usertools: fix binding built-in kernel driver
>
> Yunjian Wang (3):
> eal/linux: fix handling of error events from epoll
> net/bnxt: fix memory leak when mapping fails
> net/mvneta: check allocation in Rx queue flush
>
> Yuri Chipchev (1):
> net/mvpp2: fix stack corruption
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] 20.11.1 patches review and test
2021-03-02 10:52 0% ` Chen, BoX C
@ 2021-03-02 11:27 0% ` Luca Boccassi
0 siblings, 0 replies; 200+ results
From: Luca Boccassi @ 2021-03-02 11:27 UTC (permalink / raw)
To: Chen, BoX C, stable
Cc: dev, Walker, Benjamin, Govindharajan, Hariprasad, Mcnamara, John,
Yu, PingX, Pei Zhang, Peng, Yuan, Chen, Zhaoyan
On Tue, 2021-03-02 at 10:52 +0000, Chen, BoX C wrote:
> Hi Luca,
>
> Testing with dpdk v20.11.1 from Intel looks good.
>
> # Basic Intel(R) NIC testing
> *PF(i40e, ixgbe)： test scenarios including rte_flow/TSO/Jumboframe/checksum offload/Tunnel, etc. Listed but not all.
> - No new issue are found.
>
> *VF(i40e,ixgbe): test scenarios including vf-rte_flow/TSO/Jumboframe/checksum offload/Tunnel, Listed but not all.
> - No new issues are found.
>
> *PF/VF(ice): test scenarios including Switch features/Flow Director/Advanced RSS/ACL/DCF/Flexible Descriptor and so on, Listed but not all.
> - No new issues are found. one known issue: can't create 512 acl rules after creating a full mask switch rule. This issue is also occurred in dpdk 20.11 and no fix patch.
>
> * Build or compile:
> * Build: cover the build test combination with latest GCC/Clang/ICC version and the popular OS revision such as Ubuntu20.04, CentOS 8.3 and so on. Listed but not all.
> - All passed.
>
> * Compile: cover the CFLAGES(O0/O1/O2/O3) with popular OS such as Ubuntu20.04 and CentOS 8.3.
> - All passed.
>
> * Intel NIC single core/NIC performance: test scenarios including PF/VF single core performance test(AVX2+AVX512)，RFC2544 Zero packet loss performance test and so on. Listed but not all.
> - All passed. No big data drop.
>
> * Power and IPsec: test scenarios including Telemetry/Empty Poll Lib/Priority Base Frequency and so on.
> - All passed.
>
>
> # Basic cryptodev and virtio testing
> * Virtio: both function and performance test are covered. Such as PVP/Virtio_loopback/virtio-user loopback/virtio-net VM2VM perf testing/VMAWARE ESXI 7.0u1, etc.. Listed but not all.
> - No new issues are found. two known issues:(1)The UDP fragmentation offload feature of Virtio-net device can’t be turned on in the VM, bugzilla has been submited:https://bugzilla.kernel.org/show_bug.cgi?id=207075
> (2)vm2vm virtio-net cbdma enable test scp file between two vm random fail due to lost connection after vhost reconnect. This issue is also occurred in dpdk 20.11 and no fix patch.
>
> * Cryptodev:
> - Function test: test scenarios including Cryptodev API testing/CompressDev ISA-L/QAT/ZLIB PMD Testing/FIPS, etc. Listed but not all.
> - All passed.
> - Performance test: test scenarios including Thoughput Performance /Cryptodev Latency, etc. Listed but not all.
> - No big data drop.
>
> Regards,
> Chen Bo
Thank you!
Are there bugzilla tickets for the ICE and vm2vm issues?
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of luca.boccassi@gmail.com
> > Sent: February 22, 2021 23:09
> > To: stable@dpdk.org
> > Cc: dev@dpdk.org; Abhishek Marathe <Abhishek.Marathe@microsoft.com>;
> > Akhil Goyal <akhil.goyal@nxp.com>; Ali Alnubani <alialnu@nvidia.com>;
> > Walker, Benjamin <benjamin.walker@intel.com>; David Christensen
> > <drc@linux.vnet.ibm.com>; Govindharajan, Hariprasad
> > <hariprasad.govindharajan@intel.com>; Hemant Agrawal
> > <hemant.agrawal@nxp.com>; Stokes, Ian <ian.stokes@intel.com>; Jerin
> > Jacob <jerinj@marvell.com>; Mcnamara, John <john.mcnamara@intel.com>;
> > Ju-Hyoung Lee <juhlee@microsoft.com>; Kevin Traynor
> > <ktraynor@redhat.com>; Luca Boccassi <bluca@debian.org>; Pei Zhang
> > <pezhang@redhat.com>; Yu, PingX <pingx.yu@intel.com>; Xu, Qian Q
> > <qian.q.xu@intel.com>; Raslan Darawsheh <rasland@nvidia.com>; Thomas
> > Monjalon <thomas@monjalon.net>; Peng, Yuan <yuan.peng@intel.com>;
> > Chen, Zhaoyan <zhaoyan.chen@intel.com>
> > Subject: [dpdk-dev] 20.11.1 patches review and test
> >
> > Hi all,
> >
> > Here is a list of patches targeted for stable release 20.11.1.
> >
> > The planned date for the final release is the 8th of March.
> >
> > Please help with testing and validation of your use cases and report any
> > issues/results with reply-all to this mail. For the final release the fixes and
> > reported validations will be added to the release notes.
> >
> > A release candidate tarball can be found at:
> >
> > https://dpdk.org/browse/dpdk-stable/tag/?id=v20.11.1-rc1
> >
> > These patches are located at branch 20.11 of dpdk-stable repo:
> > https://dpdk.org/browse/dpdk-stable/
> >
> > Thanks.
> >
> > Luca Boccassi
> >
> > ---
> > Ajit Khaparde (3):
> > net/bnxt: fix cleanup on mutex init failure
> > net/bnxt: fix format specifier for unsigned int
> > net/bnxt: fix freeing mbuf
> >
> > Alexander Kozyrev (4):
> > net/mlx5: fix mbuf freeing in vectorized MPRQ
> > net/mlx5: fix flow tag decompression
> > net/mlx5: check FW miniCQE format capabilities
> > net/mlx5: fix miniCQE configuration for Verbs
> >
> > Alvin Zhang (9):
> > net/ixgbe: detect failed VF MTU set
> > net/i40e: fix Rx bytes statistics
> > net/iavf: fix queue pairs configuration
> > doc: fix RSS flow description in i40e guide
> > net/i40e: fix returned code for RSS hardware failure
> > net/ice: fix RSS lookup table initialization
> > test: fix buffer overflow in Tx burst
> > net/ixgbe: fix configuration of max frame size
> > app/testpmd: fix key for RSS flow rule
> >
> > Amit Bernstein (1):
> > net/ena: fix Tx doorbell statistics
> >
> > Anatoly Burakov (1):
> > fbarray: fix overlap check
> >
> > Andrew Boyer (5):
> > net/ionic: do minor logging fixups
> > net/ionic: fix link speed and autonegotiation
> > net/ionic: allow separate L3 and L4 checksum offload
> > net/ionic: fix up function attribute tags
> > net/ionic: fix address handling in Tx
> >
> > Ankur Dwivedi (1):
> > test/event_crypto: set cipher operation in transform
> >
> > Ashish Sadanandan (1):
> > mbuf: add C++ include guard for dynamic fields header
> >
> > Balazs Nemeth (1):
> > net/qede: fix promiscuous enable
> >
> > Beilei Xing (2):
> > net/i40e: fix global register recovery
> > net/i40e: fix flex payload rule conflict
> >
> > Bernard Iremonger (1):
> > doc: fix QinQ flow rules in testpmd guide
> >
> > Bruce Richardson (29):
> > ethdev: avoid blocking telemetry for link status
> > build: provide suitable error for "both" libraries option
> > eal: fix reciprocal header include
> > telemetry: fix missing header include
> > ethdev: fix missing header include
> > net: fix missing header include
> > mbuf: fix missing header include
> > bitrate: fix missing header include
> > rib: fix missing header includes
> > vhost: fix missing header includes
> > ipsec: fix missing header include
> > fib: fix missing header includes
> > table: fix missing header include
> > pipeline: fix missing header includes
> > metrics: fix variable declaration in header
> > node: fix missing header include
> > app: fix build with extra include paths
> > build: force pkg-config for dependency detection
> > power: create guest channel public header file
> > power: make channel message functions public
> > power: rename public structs
> > power: rename constants
> > power: export guest channel header file
> > power: clean up includes
> > eal: fix MCS lock header include
> > eal: fix internal ABI tag with clang
> > power: fix missing header includes
> > rib: fix missing header include
> > eal: fix automatic loading of drivers as shared libs
> >
> > Chengchang Tang (7):
> > net/hns3: fix register length when dumping registers
> > net/hns3: fix data overwriting during register dump
> > net/hns3: fix dump register out of range
> > net/hns3: fix interrupt resources in Rx interrupt mode
> > net/hns3: fix firmware exceptions by concurrent commands
> > net/hns3: fix VF reset on mailbox failure
> > net/hns3: fix stats flip overflow
> >
> > Chengwen Feng (3):
> > net/hns3: fix VF query link status in dev init
> > net/hns3: remove MPLS from supported flow items
> > net/hns3: fix flow director rule residue on malloc failure
> >
> > Ciara Power (3):
> > app/crypto-perf: fix spelling in output
> > app/crypto-perf: fix latency CSV output
> > app/crypto-perf: fix CSV output format
> >
> > Cristian Dumitrescu (1):
> > examples/pipeline: fix CLI parsing crash
> >
> > Dapeng Yu (4):
> > net/ixgbe: fix flex bytes flow director rule
> > net/ice: check Rx queue number on RSS init
> > net/ixgbe: disable NFS filtering
> > app/testpmd: avoid exit without terminal restore
> >
> > David Marchand (3):
> > net/hinic: restore vectorised code
> > examples/pipeline: fix VXLAN script permission
> > mbuf: remove unneeded atomic generic header include
> >
> > Dekel Peled (8):
> > net/mlx5: fix shared age action validation
> > net/mlx5: fix hairpin flow split decision
> > net/mlx5: fix flow split combined with counter
> > net/mlx5: fix flow split combined with age action
> > net/mlx5: fix shared RSS translation and cleanup
> > app/testpmd: support shared age action query
> > net/mlx5: fix shared RSS capability check
> > net/mlx5: validate hash Rx queue pointer
> >
> > Dmitry Kozlyuk (4):
> > eal/windows: fix build with MinGW-w64 8
> > bus/pci: fix build with MinGW-w64 8
> > bus/pci: fix hardware ID limit on Windows
> > build: fix linker flags on Windows
> >
> > Eugeny Parshutin (1):
> > doc: add vtune profiling config to prog guide
> >
> > Fan Zhang (1):
> > crypto/qat: fix digest in buffer
> >
> > Fei Chen (1):
> > vhost: fix vid allocation race
> >
> > Feifei Wang (7):
> > test/ring: reduce duration of performance tests
> > app/eventdev: adjust event count order for pipeline test
> > app/eventdev: remove redundant enqueue in burst Tx
> > examples/eventdev: check CPU core enabling
> > examples/eventdev: add info output for main core
> > examples/eventdev: move ethdev stop to the end
> > app/eventdev: fix SMP barrier in performance test
> >
> > Ferruh Yigit (13):
> > app/procinfo: fix _filters stats reporting
> > app/procinfo: fix check on xstats-ids
> > app/procinfo: remove useless memset
> > app/procinfo: remove useless assignment
> > net/pcap: remove local variable shadowing outer one
> > net/bonding: remove local variable shadowing outer one
> > net/af_xdp: remove useless assignment
> > net/bnxt: remove redundant return
> > app/crypto-perf: remove always true condition
> > net/avp: remove always true condition
> > net/pcap: fix byte stats for drop Tx
> > net/pcap: fix infinite Rx with large files
> > app/testpmd: fix help of metering commands
> >
> > Gaetan Rivet (2):
> > net/bonding: fix port id validity check on parsing
> > net/bonding: fix PCI address comparison on non-PCI ports
> >
> > Gagandeep Singh (2):
> > test/ipsec: fix result code for not supported
> > crypto/dpaa2_sec: fix memory allocation check
> >
> > George Prekas (1):
> > app/testpmd: fix IP checksum calculation
> >
> > Gregory Etelson (5):
> > net/mlx5: fix Direct Verbs flow descriptor allocation
> > app/testpmd: release flows left before port stop
> > net/mlx5: fix tunnel rules validation on VF representor
> > net/mlx5: fix mark action in active tunnel offload
> > net/mlx5: fix drop action in tunnel offload mode
> >
> > Guy Kaneti (1):
> > regex/octeontx2: fix PCI table overflow
> >
> > Haiyue Wang (2):
> > net/ice: drain out DCF AdminQ command queue
> > net/ixgbe: fix UDP zero checksum on x86
> >
> > Harman Kalra (1):
> > examples/l3fwd: remove limitation on Tx queue count
> >
> > Harry van Haaren (1):
> > eventdev: fix a return value comment
> >
> > Heinrich Kuhn (1):
> > net/nfp: read chip model from PluDevice register
> >
> > Hemant Agrawal (1):
> > app/procinfo: fix security context info
> >
> > Hongbo Zheng (1):
> > net/hns3: use new opcode for clearing hardware resource
> >
> > Huisong Li (7):
> > app/testpmd: fix queue stats mapping configuration
> > net/hns3: fix xstats with id and names
> > net/hns3: fix error code in xstats
> > net/hns3: fix Rx/Tx errors stats
> > net/hns3: fix link status change from firmware
> > net/hns3: validate requested maximum Rx frame length
> > net/hns3: fix query order of link status and link info
> >
> > Hyong Youb Kim (2):
> > net/enic: fix filter type used for flow API
> > net/enic: fix filter log message
> >
> > Ido Segev (1):
> > net/ena: flush Rx buffers memory pool cache
> >
> > Igor Chauskin (2):
> > net/ena: fix Tx SQ free space assessment
> > net/ena: prevent double doorbell
> >
> > Igor Ryzhov (1):
> > net/i40e: fix stats counters
> >
> > Ivan Malov (11):
> > common/sfc_efx/base: remove warnings about inline specifiers
> > common/sfc_efx/base: fix signed/unsigned mismatch warnings
> > common/sfc_efx/base: support alternative MAE match fields
> > common/sfc_efx/base: update MCDI headers for MAE privilege
> > common/sfc_efx/base: check for MAE privilege
> > common/sfc_efx/base: fix MPORT related byte order handling
> > common/sfc_efx/base: fix MAE match spec validation helper
> > common/sfc_efx/base: fix MAE match spec class comparison API
> > common/sfc_efx/base: enhance field ID check in field set API
> > common/sfc_efx/base: apply mask to value on match field set
> > net/sfc: fix TSO and checksum offloads for EF10
> >
> > Jiawei Wang (4):
> > net/mlx5: fix unnecessary checking for RSS action
> > app/testpmd: fix packets dump overlapping
> > net/mlx5: fix count actions query in sample flow
> > net/mlx5: fix counter and age flow action validation
> >
> > Jiawei Zhu (1):
> > net/virtio-user: fix run closing stdin and close callfd
> >
> > Jingjing Wu (1):
> > net/iavf: fix vector mapping with queue
> >
> > John McNamara (1):
> > license: add licenses for exception cases
> >
> > Joyce Kong (1):
> > eal/arm: fix debug build with gcc for 128-bit atomics
> >
> > Junfeng Guo (1):
> > net/iavf: fix GTPU UL and DL support for flow director
> >
> > Kalesh AP (4):
> > net/bnxt: release HWRM lock in error
> > net/bnxt: propagate FW command failure to application
> > net/bnxt: fix VNIC RSS configure function
> > net/bnxt: fix FW version log
> >
> > Karra Satwik (2):
> > net/cxgbe: accept VLAN flow items without ethertype
> > app/testpmd: fix start index for showing FEC array
> >
> > Lance Richardson (10):
> > net/bnxt: disable end of packet padding for Rx
> > net/bnxt: limit Rx representor packets per poll
> > net/bnxt: fix doorbell write ordering
> > net/bnxt: fix outer UDP checksum Rx offload capability
> > net/bnxt: make offload flags mapping per-ring
> > net/bnxt: set correct checksum status in mbuf
> > net/bnxt: fix packet type index calculation
> > net/bnxt: fix null termination of Rx mbuf chain
> > net/bnxt: fix fallback mbuf allocation logic
> > net/bnxt: fix Rx completion ring size calculation
> >
> > Leyi Rong (1):
> > net/ice: enlarge Rx queue rearm threshold to 64
> >
> > Lijun Ou (6):
> > net/hns3: fix interception with flow director
> > net/hns3: fix memory leak on secondary process exit
> > net/hns3: adjust some comments
> > net/hns3: adjust format specifier for enum
> > doc: fix product link in hns3 guide
> > net/hns3: fix RSS indirection table size
> >
> > Liron Himi (5):
> > net/octeontx2: fix PF flow action for Tx
> > net/mvpp2: remove debug log on fast-path
> > net/mvpp2: remove VLAN flush
> > net/mvpp2: remove CRC length from MRU validation
> > net/mvpp2: fix frame size checking
> >
> > Long Li (1):
> > net/netvsc: ignore unsupported packet on sync command
> >
> > Lukasz Wojciechowski (1):
> > test/distributor: fix return buffer queue overload
> >
> > Marvin Liu (1):
> > vhost: fix packed ring dequeue offloading
> >
> > Matan Azrad (1):
> > vdpa/mlx5: fix configuration mutex cleanup
> >
> > Maxime Coquelin (3):
> > net/virtio: add missing backend features negotiation
> > net/virtio: fix memory init with vDPA backend
> > net/virtio: fix getting old status on reconnect
> >
> > Michael Baum (7):
> > net/mlx5: fix leak on Rx queue creation failure
> > net/mlx5: fix leak on Tx queue creation failure
> > common/mlx5: fix completion queue entry size configuration
> > net/mlx5: remove CQE padding device argument
> > net/mlx5: fix leak on ASO SQ creation failure
> > net/mlx4: fix device detach
> > net/mlx4: fix handling of probing failure
> >
> > Michal Krawczyk (1):
> > net/ena: validate Rx req ID upon acquiring descriptor
> >
> > Min Hu (Connor) (3):
> > net/hns3: fix FEC state query
> > net/hns3: fix crash with multi-process
> > doc: add FEC to NIC features
> >
> > Murphy Yang (6):
> > net/ice: fix outer UDP Tx checksum offload
> > net/i40e: fix L4 checksum flag
> > net/ice: fix outer checksum flags
> > net/iavf: fix conflicting RSS combination rules
> > net/ice: disable IPv4 checksum offload in vector Tx
> > net/i40e: add null input checks
> >
> > Nick Connolly (2):
> > eal/windows: fix debug build with MinGW
> > eal/windows: fix vfprintf warning with clang
> >
> > Olivier Matz (5):
> > build: fix plugin load on static build
> > net/virtio-user: fix protocol features advertising
> > service: propagate init error in EAL
> > test/mcslock: remove unneeded per lcore copy
> > mempool: fix panic on dump or audit
> >
> > Ophir Munk (4):
> > net/mlx5: fix freeing packet pacing
> > net/mlx5: fix flow action destroy wrapper
> > net/mlx5: fix flow operation wrapper per OS
> > net/mlx5: unify operations for all OS
> >
> > Ori Kam (3):
> > regex/mlx5: fix memory rule alignment
> > regex/mlx5: fix support for group id
> > regex/mlx5: fix number of supported queues
> >
> > Qi Zhang (4):
> > doc: fix some statements for ice vector PMD
> > net/ice/base: fix tunnel destroy
> > net/ice/base: fix null pointer dereference
> > net/ice/base: fix memory handling
> >
> > Ruifeng Wang (4):
> > lpm: fix vector IPv4 lookup
> > net/hns3: fix build with SVE
> > net/octeontx: fix build with SVE
> > common/octeontx2: fix build with SVE
> >
> > Samik Gupta (2):
> > net/bnxt: fix Rx rings in RSS redirection table
> > net/bnxt: fix VNIC config on Rx queue stop
> >
> > Shiri Kuzin (2):
> > net/mlx5: fix VXLAN decap on non-VXLAN flow
> > net/mlx5: refuse empty VLAN in flow pattern
> >
> > Somnath Kotur (4):
> > net/bnxt: fix PF resource query
> > net/bnxt: fix lock init and destroy
> > net/bnxt: fix error handling in device start
> > net/bnxt: refactor init/uninit
> >
> > Souvik Dey (2):
> > net/i40e: fix VLAN stripping in VF
> > common/mlx5: fix storing synced MAC to internal table
> >
> > Sriharsha Basavapatna (1):
> > net/bnxt: fix max rings computation
> >
> > Stephen Hemminger (2):
> > test/rwlock: fix spelling and missing whitespace
> > test: fix terminal settings on exit
> >
> > Steve Yang (23):
> > ethdev: fix max Rx packet length check
> > app/testpmd: fix max Rx packet length for VLAN packets
> > net/dpaa: fix jumbo frame flag condition for MTU set
> > net/dpaa2: fix jumbo frame flag condition for MTU set
> > net/e1000: fix jumbo frame flag condition for MTU set
> > net/hns3: fix jumbo frame flag condition for MTU set
> > net/i40e: fix jumbo frame flag condition
> > net/iavf: fix jumbo frame flag condition
> > net/ice: fix jumbo frame flag condition
> > net/ipn3ke: fix jumbo frame flag condition for MTU set
> > net/octeontx: fix jumbo frame flag condition for MTU set
> > net/octeontx2: fix jumbo frame flag condition for MTU
> > net/qede: fix jumbo frame flag condition for MTU set
> > net/sfc: fix jumbo frame flag condition for MTU set
> > net/thunderx: fix jumbo frame flag condition for MTU set
> > net/ixgbe: fix jumbo frame flag condition
> > net/cxgbe: fix jumbo frame flag condition
> > net/axgbe: fix jumbo frame flag condition for MTU set
> > net/enetc: fix jumbo frame flag condition for MTU set
> > net/hinic: fix jumbo frame flag condition for MTU set
> > net/nfp: fix jumbo frame flag condition for MTU set
> > net/liquidio: fix jumbo frame flag condition for MTU set
> > app/testpmd: fix setting maximum packet length
> >
> > Suanming Mou (5):
> > net/mlx5: fix shared RSS and mark actions combination
> > net/mlx5: fix multi-process port ID
> > net/mlx5: fix crash on secondary process port close
> > net/mlx5: fix port attach in secondary process
> > net/mlx4: fix port attach in secondary process
> >
> > Sunil Kumar Kori (2):
> > net/octeontx2: fix corruption in segments list
> > net/octeontx: fix max Rx packet length
> >
> > Tal Shnaiderman (5):
> > bus/pci: ignore missing NUMA node on Windows
> > net/mlx5: fix constant array size
> > net/mlx5: fix device name size on Windows
> > net/mlx5: fix comparison sign in flow engine
> > common/mlx5: fix pointer cast on Windows
> >
> > Thomas Monjalon (3):
> > doc: fix figure numbering in graph guide
> > lib: fix doxygen for parameters of function pointers
> > ethdev: fix close failure handling
> >
> > Timothy McDaniel (1):
> > event/dlb: fix accessing uninitialized variables
> >
> > Ting Xu (1):
> > net/iavf: fix memory leak in large VF
> >
> > Tyler Retzlaff (2):
> > bus/pci: fix build with Windows SDK >= 10.0.20253
> > eal/windows: fix C++ compatibility
> >
> > Viacheslav Galaktionov (1):
> > net/sfc: fix generic byte statistics to exclude FCS bytes
> >
> > Viacheslav Ovsiienko (8):
> > net/mlx5: fix Verbs memory allocation callback
> > net/mlx5: fix buffer split offload advertising
> > doc: update flow mark action in mlx5 guide
> > net/mlx5: fix wire vport hint
> > app/testpmd: fix queue reconfig request on Rx split update
> > doc: fix supported feature table in mlx5 guide
> > doc: fix mark action zero value in mlx5 guide
> > net/mlx5: fix Tx queue size created with DevX
> >
> > Vladimir Medvedkin (2):
> > rib: fix insertion in some cases
> > crypto/qat: fix access to uninitialized variable
> >
> > Weifeng Li (1):
> > net/i40e: fix X722 for 802.1ad frames ability
> >
> > Wenjun Wu (1):
> > net/e1000: fix flow control mode setting
> >
> > Wisam Jaddo (1):
> > app/flow-perf: simplify objects initialization
> >
> > Xuan Ding (1):
> > net/iavf: fix symmetric flow rule creation
> >
> > Yicai Lu (1):
> > ip_frag: remove padding length of fragment
> >
> > Yongxin Liu (1):
> > usertools: fix binding built-in kernel driver
> >
> > Yunjian Wang (3):
> > eal/linux: fix handling of error events from epoll
> > net/bnxt: fix memory leak when mapping fails
> > net/mvneta: check allocation in Rx queue flush
> >
> > Yuri Chipchev (1):
> > net/mvpp2: fix stack corruption
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile
2021-03-02 7:02 4% ` Matan Azrad
@ 2021-03-02 12:29 3% ` Dumitrescu, Cristian
0 siblings, 0 replies; 200+ results
From: Dumitrescu, Cristian @ 2021-03-02 12:29 UTC (permalink / raw)
To: Matan Azrad, Li Zhang, Dekel Peled, Ori Kam, Slava Ovsiienko
Cc: dev, NBU-Contact-Thomas Monjalon, Raslan Darawsheh, mb,
ajit.khaparde, Yigit, Ferruh, Singh, Jasvinder
Hi Matan,
> -----Original Message-----
> From: Matan Azrad <matan@nvidia.com>
> Sent: Tuesday, March 2, 2021 7:02 AM
> To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Li Zhang
> <lizh@nvidia.com>; Dekel Peled <dekelp@nvidia.com>; Ori Kam
> <orika@nvidia.com>; Slava Ovsiienko <viacheslavo@nvidia.com>
> Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon
> <thomas@monjalon.net>; Raslan Darawsheh <rasland@nvidia.com>;
> mb@smartsharesystems.com; ajit.khaparde@broadcom.com; Yigit, Ferruh
> <ferruh.yigit@intel.com>; Singh, Jasvinder <jasvinder.singh@intel.com>
> Subject: RE: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile
>
>
>
> Hi Cristian
>
> Thank you for review, please see inline.
>
> From: Dumitrescu, Cristian
> > > From: dev <dev-bounces@dpdk.org> On Behalf Of Li Zhang
> <snip>
> > We had this same problem earlier for the rte_tm.h API, where people
> asked to
> > add support for WRED and shaper rates specified in packets to the existing
> byte
> > rate support. I am more than happy to support adding the same here, but
> > please let's adopt the same solution here rather than invent a different
> > approach.
> >
> > Please refer to struct rte_tm_wred_params and struct
> rte_tm_shaper_params
> > from rte_tm.h: the packets vs. bytes mode is explicitly specified through
> the use
> > of a flag called packet_mode that is added to the WRED and shaper profile.
> > When packet_mode is 0, the profile rates and bucket sizes are specified in
> > bytes per second and bytes, respectively; when packet_mode is not 0, the
> > profile rates and bucket sizes are specified in packets and packets per
> second,
> > respectively. The same profile parameters are used, no need to invent
> > additional algorithms (such as srTCM - packet mode) or profile data
> structures.
> > Can we do the same here, please?
>
> This flag approach is very intuitive suggestion and it has advantages.
>
> The main problem with the flag approach is that it breaks ABI and API.
> The profile structure size is changed due to a new field - ABI breakage.
> The user must initialize the flag with zero to get old behavior - API breakage.
>
The rte_mtr API is experimental, all the API functions are correctly marked with __rte_experimental in rte_mtr.h file, so we can safely change the API and the ABI breakage is not applicable here. Therefore, this problem does not exist, correct?
> I don't see issues with Li suggestion, Do you think Li suggestion has critical
> issues?
It is probably better to keep the rte_mtr and the rte_tm APIs aligned, it simplifies the code maintenance and improves the user experience, which always pays off in the long run. Both APIs configure token buckets in either packet mode or byte mode, and it is desirable to have them work in the same way. Also, I think we should avoid duplicating configuration data structures for to support essentially the same algorithms (such as srTCM or trTCM) if we can.
The flag proposal is actually reducing the amount of work that you guys need to do to implement your proposal. There is no negative impact to your proposal and no big change, right?
>
> > This is a quick summary of the required API changes to add support for the
> > packet mode, they are minimal:
> > a) Introduce the packet_mode flag in the profile parameters data
> structure.
> > b) Change the description (comment) of the rate and bucket size
> parameters in
> > the meter profile parameters data structures to reflect that their values
> > represents either bytes or packets, depending on the value of the new flag
> > packet_mode from the same structure.
> > c) Add the relevant capabilities: just search for "packet" in the rte_tm.h
> > capabilities data structures and apply the same to the rte_mtr.h
> capabilities,
> > when applicable.
>
> > Regards,
> > Cristian
Regards,
Cristian
^ permalink raw reply [relevance 3%]
Results 9401-9600 of ~18000 next (newer) | prev (older) | reverse | sort options + mbox downloads above
-- links below jump to the message on this page --
2020-08-31 7:53 [dpdk-dev] [PATCH] ethdev: add rx offload to drop error packets Nipun Gupta
2020-10-15 13:23 ` [dpdk-dev] [PATCH 1/3 v4] ethdev: add Rx " nipun.gupta
2021-02-18 20:32 4% ` Ferruh Yigit
2020-10-14 18:31 [dpdk-dev] [PATCH v7 0/3] pmdinfogen: rewrite in Python Dmitry Kozlyuk
2020-10-20 17:44 ` [dpdk-dev] [PATCH v8 " Dmitry Kozlyuk
2020-10-20 17:44 ` [dpdk-dev] [PATCH v8 2/3] build: use Python pmdinfogen Dmitry Kozlyuk
2021-01-20 0:05 3% ` Thomas Monjalon
2021-01-20 7:23 0% ` Dmitry Kozlyuk
2021-01-20 10:24 0% ` Thomas Monjalon
2021-01-22 20:31 4% ` Dmitry Kozlyuk
2021-01-22 20:57 0% ` Thomas Monjalon
2021-01-22 22:24 3% ` Dmitry Kozlyuk
2021-01-23 11:38 4% ` Thomas Monjalon
2021-01-24 20:52 3% ` Dmitry Kozlyuk
2021-01-25 9:25 3% ` Kinsella, Ray
2021-01-25 10:01 0% ` Kinsella, Ray
2021-01-25 10:29 3% ` David Marchand
2021-01-25 10:46 0% ` Kinsella, Ray
2021-01-25 11:03 0% ` Thomas Monjalon
2021-01-25 10:05 0% ` Dmitry Kozlyuk
2021-01-25 10:11 4% ` Kinsella, Ray
2021-01-25 10:31 0% ` Dmitry Kozlyuk
2021-01-22 22:43 3% ` [dpdk-dev] [PATCH v9 0/3] pmdinfogen: rewrite in Python Dmitry Kozlyuk
2021-01-24 20:51 3% ` [dpdk-dev] [PATCH v10 " Dmitry Kozlyuk
2021-01-24 20:51 2% ` [dpdk-dev] [PATCH v10 2/3] build: use Python pmdinfogen Dmitry Kozlyuk
2020-11-02 11:09 [dpdk-dev] [PATCH v11 0/6] Add PMD power mgmt Liang Ma
2020-12-17 14:05 ` [dpdk-dev] [PATCH v12 00/11] Add PMD power management Anatoly Burakov
2020-12-17 14:05 ` [dpdk-dev] [PATCH v12 06/11] ethdev: add simple power management API Anatoly Burakov
2021-01-12 20:32 ` Lance Richardson
2021-01-13 13:04 ` Burakov, Anatoly
2021-01-13 13:25 3% ` Ananyev, Konstantin
2020-12-17 16:12 ` [dpdk-dev] [PATCH v12 00/11] Add PMD power management David Marchand
2021-01-08 16:42 0% ` Burakov, Anatoly
2021-01-11 8:44 0% ` David Marchand
2021-01-08 17:42 ` [dpdk-dev] [PATCH v13 " Anatoly Burakov
2021-01-08 17:42 2% ` [dpdk-dev] [PATCH v13 01/11] eal: uninline power intrinsics Anatoly Burakov
2021-01-12 15:54 0% ` Ananyev, Konstantin
2021-01-11 14:35 ` [dpdk-dev] [PATCH v14 00/11] Add PMD power management Anatoly Burakov
2021-01-11 14:35 2% ` [dpdk-dev] [PATCH v14 01/11] eal: uninline power intrinsics Anatoly Burakov
2021-01-11 14:58 ` [dpdk-dev] [PATCH v15 00/11] Add PMD power management Anatoly Burakov
2021-01-11 14:58 2% ` [dpdk-dev] [PATCH v15 01/11] eal: uninline power intrinsics Anatoly Burakov
2021-01-12 17:37 ` [dpdk-dev] [PATCH v16 00/11] Add PMD power management Anatoly Burakov
2021-01-12 17:37 2% ` [dpdk-dev] [PATCH v16 01/11] eal: uninline power intrinsics Anatoly Burakov
2021-01-14 9:36 9% ` [dpdk-dev] [PATCH v16 00/11] Add PMD power management David Marchand
2021-01-14 10:25 0% ` Burakov, Anatoly
2021-01-14 14:46 2% ` [dpdk-dev] [PATCH v17 " Anatoly Burakov
2021-01-14 14:46 2% ` [dpdk-dev] [PATCH v17 01/11] eal: uninline power intrinsics Anatoly Burakov
2021-01-14 14:46 7% ` [dpdk-dev] [PATCH v17 06/11] ethdev: add simple power management API Anatoly Burakov
2021-01-18 15:24 0% ` [dpdk-dev] [PATCH v17 00/11] Add PMD power management David Marchand
2021-01-18 15:45 0% ` Burakov, Anatoly
2021-01-18 16:06 3% ` Thomas Monjalon
2021-01-18 17:02 3% ` Burakov, Anatoly
2021-01-18 17:54 3% ` David Marchand
2020-11-24 7:52 [dpdk-dev] [PATCH v2] build: alias default build as generic Juraj Linkeš
2021-02-18 14:12 3% ` [dpdk-dev] [PATCH v3] " Juraj Linkeš
2020-12-07 17:32 [dpdk-dev] [PATCH 1/1] devtools: adjust verbosity of ABI check Thomas Monjalon
2020-12-17 9:05 ` [dpdk-dev] [PATCH v2 " Thomas Monjalon
2021-01-13 9:21 4% ` Thomas Monjalon
2020-12-07 17:33 [dpdk-dev] [PATCH 1/1] devtools: avoid installing static binaries Thomas Monjalon
2021-01-13 19:05 13% ` [dpdk-dev] [PATCH v2 " Thomas Monjalon
2021-01-13 22:01 0% ` Thomas Monjalon
2021-01-15 15:24 3% ` David Marchand
2021-01-15 16:02 4% ` Thomas Monjalon
2020-12-16 8:58 [dpdk-dev] [dpdk-dev 21.02 0/5] enable UDP ecpri configure in dcf Jeff Guo
2020-12-24 6:59 ` [dpdk-dev] [dpdk-dev v2 0/2] add new UDP tunnel port for ecpri Jeff Guo
2020-12-24 6:59 ` [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type " Jeff Guo
2021-01-06 22:12 3% ` Thomas Monjalon
2021-01-07 9:32 3% ` Guo, Jia
2021-01-07 10:11 0% ` Thomas Monjalon
2021-01-07 12:47 4% ` Zhang, Qi Z
2021-01-07 13:33 0% ` Thomas Monjalon
2021-01-07 13:45 0% ` David Marchand
2021-01-07 14:27 3% ` Dodji Seketeli
2021-01-07 15:24 0% ` Zhang, Qi Z
2021-01-08 9:22 0% ` Ferruh Yigit
2021-01-08 10:23 3% ` Thomas Monjalon
2021-01-08 10:43 3% ` Ferruh Yigit
2021-01-08 14:06 3% ` Thomas Monjalon
2021-01-08 14:07 0% ` Kinsella, Ray
2021-01-08 14:10 0% ` Thomas Monjalon
2021-01-08 12:38 0% ` Kinsella, Ray
2021-01-08 14:27 0% ` Ferruh Yigit
2021-01-08 14:31 0% ` Kinsella, Ray
2021-01-08 17:34 0% ` Kinsella, Ray
2021-01-15 2:42 ` [dpdk-dev] [dpdk-dev v3 0/2] add new UDP tunnel port " Jeff Guo
2021-01-15 2:42 11% ` [dpdk-dev] [dpdk-dev v3 1/2] ethdev: add new tunnel type " Jeff Guo
2021-01-15 4:35 ` [dpdk-dev] [dpdk-dev v4 0/2] add new UDP tunnel port configure for eCPRI Jeff Guo
2021-01-15 4:35 11% ` [dpdk-dev] [dpdk-dev v4 1/2] ethdev: add new tunnel type " Jeff Guo
2021-01-15 5:15 ` [dpdk-dev] [dpdk-dev v5 0/2] add new UDP tunnel port configure " Jeff Guo
2021-01-15 5:15 11% ` [dpdk-dev] [dpdk-dev v5 1/2] ethdev: add new tunnel type " Jeff Guo
2021-01-15 12:23 3% ` Ferruh Yigit
2021-01-18 2:40 0% ` Guo, Jia
2020-12-17 9:22 [dpdk-dev] [PATCH v2 00/22] fix rx packets dropped issue Steve Yang
2021-01-14 9:45 ` [dpdk-dev] [PATCH v3 01/22] ethdev: fix MTU size exceeds max rx packet length Steve Yang
2021-01-14 16:36 ` Ferruh Yigit
2021-01-14 17:13 ` Ferruh Yigit
2021-01-14 17:29 ` Andrew Boyer
2021-01-14 20:44 3% ` Ferruh Yigit
2020-12-17 11:36 [dpdk-dev] [PATCH v1] power: fix make build for power apps David Hunt
2021-01-08 14:30 ` [dpdk-dev] [PATCH 0/6] " David Hunt
2021-01-13 11:08 ` Burakov, Anatoly
2021-01-13 11:14 ` David Hunt
2021-01-13 11:18 ` Burakov, Anatoly
2021-01-13 13:25 ` David Hunt
2021-01-13 17:30 3% ` Burakov, Anatoly
2020-12-18 10:12 [dpdk-dev] [RFC PATCH] lpm: add sve support for lookup on Arm platform Ruifeng Wang
2021-01-12 2:57 ` [dpdk-dev] [PATCH v3 0/5] lpm lookup with sve support Ruifeng Wang
2021-01-12 2:57 ` [dpdk-dev] [PATCH v3 1/5] lpm: add sve support for lookup on Arm platform Ruifeng Wang
2021-01-27 13:04 ` David Marchand
2021-01-27 21:03 4% ` Honnappa Nagarahalli
2021-01-28 8:03 0% ` David Marchand
2021-01-28 12:24 3% ` Honnappa Nagarahalli
2020-12-18 14:55 [dpdk-dev] [RFC 0/7] support SubFunction representor Xueming Li
2020-12-18 14:55 ` [dpdk-dev] [RFC 3/7] devarg: change reprsentor ID to bitmap Xueming Li
2020-12-28 13:36 ` Andrew Rybchenko
2021-01-05 6:19 3% ` Xueming(Steven) Li
2020-12-18 14:55 [dpdk-dev] [RFC 1/7] ethdev: support sub function representor Xueming Li
2021-01-19 7:13 ` [dpdk-dev] [PATCH v5 0/9] ethdev: support SubFunction representor Xueming Li
2021-01-19 8:40 ` Andrew Rybchenko
2021-01-19 14:24 ` Xueming(Steven) Li
2021-01-22 8:21 ` Andrew Rybchenko
2021-01-27 3:04 ` Xueming(Steven) Li
2021-01-27 12:10 ` Andrew Rybchenko
2021-01-28 14:31 ` Xueming(Steven) Li
2021-02-01 8:39 ` Andrew Rybchenko
2021-02-04 14:15 3% ` Xueming(Steven) Li
2021-02-05 7:34 0% ` Andrew Rybchenko
2021-02-05 9:13 3% ` Xueming(Steven) Li
2021-02-05 9:37 0% ` Andrew Rybchenko
2020-12-18 19:21 [dpdk-dev] [RFC] mem_debug add more log Peng Zhihong
2020-12-18 18:54 ` Stephen Hemminger
2020-12-21 7:35 ` Peng, ZhihongX
2020-12-21 18:44 3% ` Stephen Hemminger
2020-12-25 7:20 3% ` Peng, ZhihongX
2020-12-19 8:26 4% [dpdk-dev] [PATCH] ci: fix package installation in GitHub Actions David Marchand
2020-12-20 21:13 2% [dpdk-dev] [PATCH 00/40] net/virtio: Virtio PMD rework Maxime Coquelin
2020-12-20 21:13 ` [dpdk-dev] [PATCH 08/40] net/virtio: force IOVA as VA mode for Virtio-user Maxime Coquelin
2021-01-06 9:06 4% ` David Marchand
2021-01-06 9:11 3% ` Thomas Monjalon
2021-01-06 9:22 0% ` Maxime Coquelin
2021-01-06 16:37 0% ` Kinsella, Ray
2021-01-06 9:14 0% ` Maxime Coquelin
2020-12-21 10:58 0% ` [dpdk-dev] [PATCH 00/40] net/virtio: Virtio PMD rework Maxime Coquelin
2020-12-22 14:42 [dpdk-dev] [PATCH v7 0/2] support enqueue & dequeue callbacks on cryptodev Abhinandan Gujjar
2020-12-22 14:42 2% ` [dpdk-dev] [PATCH v7 1/2] cryptodev: support enqueue and dequeue callback functions Abhinandan Gujjar
2021-01-04 6:59 0% ` Gujjar, Abhinandan S
2021-01-15 16:01 ` Akhil Goyal
2021-01-19 18:31 8% ` Thomas Monjalon
2021-01-20 13:01 3% ` Kinsella, Ray
2021-01-20 13:12 0% ` David Marchand
2021-01-20 13:15 0% ` Thomas Monjalon
2021-01-20 14:09 0% ` Kinsella, Ray
2021-01-05 12:16 5% [dpdk-dev] [PATCH] ci: fix default ccache in GitHub Actions David Marchand
2021-01-05 14:09 0% ` Aaron Conole
2021-01-08 19:13 4% [dpdk-dev] Reader-Writer lock starvation issues Stephen Hemminger
2021-01-08 21:27 0% ` Honnappa Nagarahalli
2021-01-11 11:52 0% ` Ferruh Yigit
2021-01-11 13:05 0% ` Honnappa Nagarahalli
2021-01-12 1:04 3% ` [dpdk-dev] [PATCH] eal/rwlock: add note about writer starvation Stephen Hemminger
2021-01-14 16:55 3% ` [dpdk-dev] [PATCH v2] " Stephen Hemminger
2021-02-11 22:51 0% ` Thomas Monjalon
2021-02-12 0:21 0% ` Honnappa Nagarahalli
2021-01-12 1:18 [dpdk-dev] [PATCH] eal/headers: explicitly cast void * to type * Tyler Retzlaff
2021-01-14 10:55 ` Bruce Richardson
2021-01-15 19:21 ` Tyler Retzlaff
2021-01-17 17:13 3% ` Thomas Monjalon
2021-01-12 22:41 [dpdk-dev] [PATCH v2] bus/pci/windows: guard against sdk/dpdk guid collision Tyler Retzlaff
2021-01-14 21:22 ` [dpdk-dev] [PATCH v3] pci/windows: fix build with SDK >= 10.0.20253 Tyler Retzlaff
2021-01-14 22:59 ` Ranjit Menon
2021-01-15 5:34 3% ` Tyler Retzlaff
2021-01-13 9:03 5% [dpdk-dev] [PATCH] doc: recommend GitHub Actions for CI David Marchand
2021-01-14 11:05 [dpdk-dev] [PATCH 00/20] ensure headers have correct includes Bruce Richardson
2021-01-25 14:11 ` [dpdk-dev] [PATCH v3 0/4] add checking of header includes Bruce Richardson
2021-01-25 15:51 2% ` David Marchand
2021-01-25 18:17 0% ` Bruce Richardson
2021-01-26 11:15 4% ` Bruce Richardson
2021-01-26 14:04 3% ` David Marchand
2021-01-26 14:24 0% ` Bruce Richardson
2021-01-26 14:39 0% ` Bruce Richardson
2021-01-26 14:18 ` [dpdk-dev] [PATCH v4 0/7] " Bruce Richardson
2021-01-26 14:18 13% ` [dpdk-dev] [PATCH v4 2/7] eal: fix error attribute use for clang Bruce Richardson
2021-01-26 21:38 ` [dpdk-dev] [PATCH v5 0/8] add checking of header includes Bruce Richardson
2021-01-26 21:38 13% ` [dpdk-dev] [PATCH v5 2/8] eal: fix error attribute use for clang Bruce Richardson
2021-01-27 17:33 ` [dpdk-dev] [PATCH v6 0/8] add checking of header includes Bruce Richardson
2021-01-27 17:33 13% ` [dpdk-dev] [PATCH v6 2/8] eal: fix error attribute use for clang Bruce Richardson
2021-01-28 11:00 4% ` David Marchand
2021-01-28 11:20 0% ` Bruce Richardson
2021-01-28 13:36 0% ` David Marchand
2021-01-28 14:16 0% ` Bruce Richardson
2021-01-28 15:16 0% ` Bruce Richardson
2021-01-28 16:46 0% ` [dpdk-dev] [dpdk-techboard] " Thomas Monjalon
2021-01-28 17:36 0% ` Bruce Richardson
2021-01-28 10:55 3% ` [dpdk-dev] [PATCH v6 0/8] add checking of header includes David Marchand
2021-01-28 11:47 0% ` Bruce Richardson
2021-01-29 16:48 ` [dpdk-dev] [PATCH v7 00/10] " Bruce Richardson
2021-01-29 16:48 13% ` [dpdk-dev] [PATCH v7 02/10] eal: fix error attribute use for clang Bruce Richardson
2021-01-29 16:48 ` [dpdk-dev] [PATCH v7 06/10] eventdev: make driver-only headers private Bruce Richardson
2021-02-22 22:34 3% ` Stephen Hemminger
2021-01-18 12:41 [dpdk-dev] [PATCH v17 07/11] power: add PMD power management API and callback David Hunt
2021-01-19 16:45 3% ` [dpdk-dev] [PATCH v18 0/2] Add PMD power management Anatoly Burakov
2021-01-20 11:50 3% ` [dpdk-dev] [PATCH v19 0/4] " Anatoly Burakov
2021-01-22 17:12 3% ` [dpdk-dev] [PATCH v20 " Anatoly Burakov
2021-01-19 21:24 [dpdk-dev] [PATCH v2 00/44] net/virtio: Virtio PMD rework Maxime Coquelin
2021-01-19 21:24 ` [dpdk-dev] [PATCH v2 02/44] bus/vdev: add driver IOVA VA mode requirement Maxime Coquelin
2021-01-20 15:32 8% ` David Marchand
2021-01-20 17:47 0% ` Maxime Coquelin
2021-01-20 14:25 4% [dpdk-dev] [PATCH v1] devtools: update abi ignore for cryptodev Ray Kinsella
2021-01-20 15:41 7% ` Thomas Monjalon
2021-01-21 15:15 4% ` Dodji Seketeli
2021-01-21 15:58 4% ` Thomas Monjalon
2021-01-22 12:11 4% ` Kinsella, Ray
2021-01-22 13:09 4% ` Dodji Seketeli
2021-01-22 13:12 4% ` Kinsella, Ray
2021-01-24 11:58 4% ` Dodji Seketeli
2021-01-26 11:55 8% ` Thomas Monjalon
2021-01-21 6:03 [dpdk-dev] [PATCH v11 0/4] raw/ifpga: add extra OPAE APIs Wei Huang
2021-01-21 6:03 ` [dpdk-dev] [PATCH v11 3/4] raw/ifpga: add OPAE API for OpenStack Cyborg Wei Huang
2021-01-21 16:30 3% ` Ferruh Yigit
2021-01-22 3:16 3% ` Huang, Wei
2021-01-21 12:04 4% [dpdk-dev] DPDK Release Status Meeting 21/01/2021 Ferruh Yigit
2021-01-22 6:38 0% ` Ruifeng Wang
2021-01-25 1:02 [dpdk-dev] [RFC 0/1] lib/librte_ethdev: Meter algorithms support packet per second Li Zhang
2021-03-01 10:35 ` [dpdk-dev] [RFC v4 0/4] adds support PPS(packet per second) on meter Li Zhang
2021-03-01 10:35 ` [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile Li Zhang
2021-03-01 13:20 ` Dumitrescu, Cristian
2021-03-02 7:02 4% ` Matan Azrad
2021-03-02 12:29 3% ` Dumitrescu, Cristian
2021-01-26 3:38 [dpdk-dev] [PATCH] ethdev: add IPv6 DSCP option for modify field action Alexander Kozyrev
2021-01-26 3:43 3% ` Stephen Hemminger
2021-01-26 5:21 3% ` Alexander Kozyrev
2021-01-26 5:35 0% ` Ajit Khaparde
2021-01-26 5:44 0% ` Stephen Hemminger
2021-01-26 10:15 3% [dpdk-dev] [PATCH v4 00/44] net/virtio: Virtio PMD rework Maxime Coquelin
2021-01-26 10:15 7% ` [dpdk-dev] [PATCH v4 02/44] bus/vdev: add driver IOVA VA mode requirement Maxime Coquelin
2021-01-26 11:50 0% ` Xia, Chenbo
2021-01-26 12:50 0% ` David Marchand
2021-01-26 13:23 0% ` Kinsella, Ray
2021-01-26 14:40 4% ` David Marchand
2021-01-26 15:28 0% ` Kinsella, Ray
2021-01-27 8:23 0% ` David Marchand
2021-01-27 8:25 0% ` Maxime Coquelin
2021-01-27 11:59 0% ` [dpdk-dev] [PATCH v4 00/44] net/virtio: Virtio PMD rework Maxime Coquelin
2021-02-01 8:44 0% ` Wang, Yinan
2021-02-01 8:49 0% ` Maxime Coquelin
2021-02-01 14:30 4% [dpdk-dev] [PATCH] ci: ignore APT update failure in GitHub Actions David Marchand
2021-02-01 14:41 0% ` Ilya Maximets
2021-02-01 18:08 9% [dpdk-dev] [PATCH] devtools: remove ethdev ABI exception David Marchand
2021-02-01 19:03 4% ` Ferruh Yigit
2021-02-05 16:48 4% ` Thomas Monjalon
2021-02-01 20:39 4% ` Maxime Coquelin
2021-02-02 8:49 4% ` Kinsella, Ray
2021-02-02 10:54 10% [dpdk-dev] [PATCH] devtools: fix examples external compilation for x86-default David Marchand
2021-02-02 22:54 0% ` Thomas Monjalon
2021-02-04 13:34 5% [dpdk-dev] [PATCH] devtools: select targets in build test David Marchand
2021-02-05 14:46 [dpdk-dev] [RFC PATCH v3] build: kni cross-compilation support Juraj Linkeš
2021-02-05 15:04 ` [dpdk-dev] [RFC PATCH v4] " Juraj Linkeš
2021-02-05 15:27 3% ` Bruce Richardson
2021-02-08 10:17 0% ` Juraj Linkeš
2021-02-08 10:26 0% ` Bruce Richardson
2021-02-05 21:23 10% [dpdk-dev] [PATCH] telemetry: mark init function as internal-only Bruce Richardson
2021-02-08 16:33 4% [dpdk-dev] [PATCH] eal: fix detection of static or shared DPDK builds Bruce Richardson
2021-02-09 12:49 0% ` Bruce Richardson
2021-02-12 19:09 3% [dpdk-dev] officially support building driver plugins externally Tyler Retzlaff
2021-02-14 1:20 [dpdk-dev] [PATCH 0/6] net/pcap: build on Windows Dmitry Kozlyuk
2021-02-14 2:16 ` [dpdk-dev] [PATCH v2 " Dmitry Kozlyuk
2021-02-14 2:16 ` [dpdk-dev] [PATCH v2 4/6] net/pcap: add libpcap wrappers Dmitry Kozlyuk
2021-02-25 14:59 ` Ferruh Yigit
2021-02-25 19:04 ` Dmitry Kozlyuk
2021-02-25 20:31 ` Nick Connolly
2021-02-25 23:10 3% ` Dmitry Kozlyuk
2021-02-14 19:19 3% [dpdk-dev] [dpdk-announce] DPDK 21.02 released Thomas Monjalon
2021-02-15 9:14 7% [dpdk-dev] [PATCH] version: 21.05-rc0 Thomas Monjalon
2021-02-15 19:18 3% [dpdk-dev] Build errors due to duplicate version.map entries in librte_power Aaron Conole
2021-02-22 10:31 0% ` Juraj Linkeš
2021-02-22 19:50 0% ` Aaron Conole
2021-02-19 11:17 4% [dpdk-dev] [PATCH v2] doc: update stable section Kevin Traynor
2021-02-20 22:09 3% [dpdk-dev] [PATCH 0/7] Introduce event vectorization pbhagavatula
2021-02-20 22:09 5% ` [dpdk-dev] [PATCH 7/7] eventdev: fix ABI breakage due to event vector pbhagavatula
2021-02-20 23:29 [dpdk-dev] [PATCH 0/7] eal/windows: do not expose POSIX symbols Dmitry Kozlyuk
2021-02-20 23:29 3% ` [dpdk-dev] [PATCH 7/7] " Dmitry Kozlyuk
2021-02-21 1:28 ` [dpdk-dev] [PATCH v2 0/7] " Dmitry Kozlyuk
2021-02-21 1:28 3% ` [dpdk-dev] [PATCH v2 7/7] " Dmitry Kozlyuk
2021-02-21 14:28 ` [dpdk-dev] [PATCH v3 0/7] " Dmitry Kozlyuk
2021-02-21 14:28 3% ` [dpdk-dev] [PATCH v3 7/7] " Dmitry Kozlyuk
2021-02-22 15:09 1% [dpdk-dev] 20.11.1 patches review and test luca.boccassi
2021-02-25 9:43 0% ` Christian Ehrhardt
2021-02-25 13:00 0% ` Pei Zhang
2021-02-25 14:39 0% ` Luca Boccassi
2021-03-02 6:23 0% ` Kalesh Anakkur Purayil
2021-03-02 10:29 0% ` Luca Boccassi
2021-03-02 10:52 0% ` Chen, BoX C
2021-03-02 11:27 0% ` Luca Boccassi
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).