* 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
1 sibling, 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
1 sibling, 0 replies; 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%]
* [dpdk-dev] [PATCH] devtools: remove ethdev ABI exception
@ 2021-02-01 18:08 9% David Marchand
2021-02-01 19:03 4% ` Ferruh Yigit
2021-02-01 20:39 4% ` Maxime Coquelin
0 siblings, 2 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] 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] 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 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%]
* 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%]
* [dpdk-dev] [PATCH v7 02/10] eal: fix error attribute use for clang
@ 2021-01-29 16:48 13% ` Bruce Richardson
0 siblings, 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] [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%]
* 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] [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] [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 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 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 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 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 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 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 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 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%]
* [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 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%]
* 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 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%]
* [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 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%]
* 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 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 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%]
* [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 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%]
* 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 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 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-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 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%]
* [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%]
* [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%]
* 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%]
* 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 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 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 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 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 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 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: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: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: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 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 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-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-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%]
* [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%]
* [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%]
* 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%]
* 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%]
* [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 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%]
* 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-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%]
* [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 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%]
* 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-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] 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 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] [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 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 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%]
* [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 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%]
* 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 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 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, 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%]
* [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 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%]
* 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%]
* [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 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%]
* 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 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 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%]
* [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 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%]
* 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 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 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-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] [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] 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] [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 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] [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 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%]
* [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%]
* [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 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%]
* 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] [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
0 siblings, 0 replies; 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%]
* [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 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 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%]
* 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%]
* 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 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%]
* [dpdk-dev] [PATCH v2 1/1] devtools: avoid installing static binaries
2020-12-07 17:33 10% [dpdk-dev] [PATCH 1/1] devtools: avoid installing static binaries Thomas Monjalon
2020-12-07 17:47 3% ` Bruce Richardson
2020-12-08 15:37 4% ` David Marchand
@ 2021-01-13 19:05 13% ` Thomas Monjalon
2021-01-13 22:01 0% ` Thomas Monjalon
2 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 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%]
* 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 v2 1/1] devtools: adjust verbosity of ABI check
2020-12-17 9:05 36% ` [dpdk-dev] [PATCH v2 " Thomas Monjalon
@ 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%]
* [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%]
* [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%]
* 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] 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%]
* [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 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%]
* 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%]
* 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] [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: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 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] 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] [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 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%]
* [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%]
* [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%]
* Re: [dpdk-dev] [PATCH v12 00/11] Add PMD power management
2020-12-17 16:12 3% ` [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
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%]
* 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] [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 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 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 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-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-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: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 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 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 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 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-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-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] [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] [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: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: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
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] 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%]
* [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] [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%]
* 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] 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%]
* [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, 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%]
* 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%]
* [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%]
* [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%]
* Re: [dpdk-dev] [PATCH v12 00/11] Add PMD power management
@ 2020-12-17 16:12 3% ` David Marchand
2021-01-08 16:42 0% ` Burakov, Anatoly
3 siblings, 1 reply; 200+ results
From: David Marchand @ 2020-12-17 16:12 UTC (permalink / raw)
To: Anatoly Burakov
Cc: dev, Thomas Monjalon, Ananyev, Konstantin, Gage Eads,
Timothy McDaniel, David Hunt, Bruce Richardson, chris.macnamara,
Ray Kinsella, Yigit, Ferruh
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.
--
David Marchand
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v12 01/11] eal: uninline power intrinsics
@ 2020-12-17 14:05 2% ` Anatoly Burakov
0 siblings, 0 replies; 200+ results
From: Anatoly Burakov @ 2020-12-17 14:05 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.17.1
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v2 1/1] devtools: adjust verbosity of ABI check
2020-12-07 17:32 36% [dpdk-dev] [PATCH 1/1] devtools: adjust verbosity of ABI check Thomas Monjalon
2020-12-08 15:22 9% ` Kinsella, Ray
2020-12-08 15:31 4% ` David Marchand
@ 2020-12-17 9:05 36% ` Thomas Monjalon
2021-01-13 9:21 4% ` Thomas Monjalon
2 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2020-12-17 9:05 UTC (permalink / raw)
To: dev; +Cc: david.marchand, bruce.richardson, Ray Kinsella, Neil Horman
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)
---
devtools/check-abi.sh | 20 ++++++++++----------
devtools/gen-abi.sh | 4 ++--
devtools/test-meson-builds.sh | 9 +++++++--
3 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/devtools/check-abi.sh b/devtools/check-abi.sh
index ab6748cfbc..9835e346da 100755
--- a/devtools/check-abi.sh
+++ b/devtools/check-abi.sh
@@ -3,7 +3,7 @@
# Copyright (c) 2019 Red Hat, Inc.
if [ $# != 2 ] && [ $# != 3 ]; then
- echo "Usage: $0 refdir newdir [warnonly]"
+ echo "Usage: $0 refdir newdir [warnonly]" >&2
exit 1
fi
@@ -13,23 +13,23 @@ warnonly=${3:-}
ABIDIFF_OPTIONS="--suppr $(dirname $0)/libabigail.abignore --no-added-syms"
if [ ! -d $refdir ]; then
- echo "Error: reference directory '$refdir' does not exist."
+ echo "Error: reference directory '$refdir' does not exist." >&2
exit 1
fi
incdir=$(find $refdir -type d -a -name include)
if [ -z "$incdir" ] || [ ! -e "$incdir" ]; then
- echo "WARNING: could not identify a include directory for $refdir, expect false positives..."
+ echo "WARNING: could not identify an include directory for $refdir, expect false positives..." >&2
else
ABIDIFF_OPTIONS="$ABIDIFF_OPTIONS --headers-dir1 $incdir"
fi
if [ ! -d $newdir ]; then
- echo "Error: directory to check '$newdir' does not exist."
+ echo "Error: directory to check '$newdir' does not exist." >&2
exit 1
fi
incdir2=$(find $newdir -type d -a -name include)
if [ -z "$incdir2" ] || [ ! -e "$incdir2" ]; then
- echo "WARNING: could not identify a include directory for $newdir, expect false positives..."
+ echo "WARNING: could not identify an include directory for $newdir, expect false positives..." >&2
else
ABIDIFF_OPTIONS="$ABIDIFF_OPTIONS --headers-dir2 $incdir2"
fi
@@ -46,23 +46,23 @@ for dump in $(find $refdir -name "*.dump"); do
fi
dump2=$(find $newdir -name $name)
if [ -z "$dump2" ] || [ ! -e "$dump2" ]; then
- echo "Error: can't find $name in $newdir"
+ echo "Error: cannot find $name in $newdir" >&2
error=1
continue
fi
abidiff $ABIDIFF_OPTIONS $dump $dump2 || {
abiret=$?
- echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $dump $dump2'"
+ echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $dump $dump2'" >&2
error=1
echo
if [ $(($abiret & 3)) -ne 0 ]; then
- echo "ABIDIFF_ERROR|ABIDIFF_USAGE_ERROR, this could be a script or environment issue."
+ echo "ABIDIFF_ERROR|ABIDIFF_USAGE_ERROR, this could be a script or environment issue." >&2
fi
if [ $(($abiret & 4)) -ne 0 ]; then
- echo "ABIDIFF_ABI_CHANGE, this change requires a review (abidiff flagged this as a potential issue)."
+ echo "ABIDIFF_ABI_CHANGE, this change requires a review (abidiff flagged this as a potential issue)." >&2
fi
if [ $(($abiret & 8)) -ne 0 ]; then
- echo "ABIDIFF_ABI_INCOMPATIBLE_CHANGE, this change breaks the ABI."
+ echo "ABIDIFF_ABI_INCOMPATIBLE_CHANGE, this change breaks the ABI." >&2
fi
echo
}
diff --git a/devtools/gen-abi.sh b/devtools/gen-abi.sh
index c44b0e228a..f15a3b9aaf 100755
--- a/devtools/gen-abi.sh
+++ b/devtools/gen-abi.sh
@@ -3,13 +3,13 @@
# Copyright (c) 2019 Red Hat, Inc.
if [ $# != 1 ]; then
- echo "Usage: $0 installdir"
+ echo "Usage: $0 installdir" >&2
exit 1
fi
installdir=$1
if [ ! -d $installdir ]; then
- echo "Error: install directory '$installdir' does not exist."
+ echo "Error: install directory '$installdir' does not exist." >&2
exit 1
fi
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index ed44d4ffb1..16a81b6241 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -194,10 +194,15 @@ build () # <directory> <target compiler | cross file> <meson options>
install_target $builds_dir/$targetdir \
$(readlink -f $builds_dir/$targetdir/install)
+ echo "Checking ABI compatibility of $targetdir" >&$verbose
+ echo $srcdir/devtools/gen-abi.sh \
+ $(readlink -f $builds_dir/$targetdir/install) >&$veryverbose
$srcdir/devtools/gen-abi.sh \
- $(readlink -f $builds_dir/$targetdir/install)
+ $(readlink -f $builds_dir/$targetdir/install) >&$veryverbose
+ echo $srcdir/devtools/check-abi.sh $abirefdir/$targetdir \
+ $(readlink -f $builds_dir/$targetdir/install) >&$veryverbose
$srcdir/devtools/check-abi.sh $abirefdir/$targetdir \
- $(readlink -f $builds_dir/$targetdir/install)
+ $(readlink -f $builds_dir/$targetdir/install) >&$verbose
fi
}
--
2.29.2
^ permalink raw reply [relevance 36%]
* Re: [dpdk-dev] [PATCH v2 2/2] ci: enable v21 ABI checks
2020-12-04 17:36 20% ` [dpdk-dev] [PATCH v2 2/2] ci: enable v21 ABI checks David Marchand
@ 2020-12-14 14:13 4% ` Aaron Conole
0 siblings, 0 replies; 200+ results
From: Aaron Conole @ 2020-12-14 14:13 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Michael Santana
David Marchand <david.marchand@redhat.com> writes:
> v21 ABI will be maintained until v21.11.
>
> Let's use the latest released libabigail 1.8.
>
> In GitHub Actions, libabigail binaries and the ABI reference are stored
> in two shared caches as all branches can use the same.
>
> While at it, we can reproduce changes from the commit 0b8086ce3fe7
> ("devtools: remove useless files from ABI reference").
> This will save some space in the CI caches.
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
Acked-by: Aaron Conole <aconole@redhat.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v2 1/2] ci: hook to GitHub Actions
2020-12-04 17:36 4% ` [dpdk-dev] [PATCH v2 1/2] ci: hook to GitHub Actions David Marchand
2020-12-04 17:36 20% ` [dpdk-dev] [PATCH v2 2/2] ci: enable v21 ABI checks David Marchand
2020-12-11 20:07 3% ` [dpdk-dev] [PATCH v2 1/2] ci: hook to GitHub Actions Ferruh Yigit
@ 2020-12-14 14:12 0% ` Aaron Conole
2 siblings, 0 replies; 200+ results
From: Aaron Conole @ 2020-12-14 14:12 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Michael Santana, Thomas Monjalon
David Marchand <david.marchand@redhat.com> writes:
> With the recent changes in terms of free access to the Travis CI, let's
> offer an alternative with GitHub Actions.
> Running jobs on ARM is not supported unless using external runners, so
> this commit only adds builds for x86_64 and cross compiling for i386 and
> aarch64.
>
> Differences with the Travis CI integration:
> - Error logs are not dumped to the console when something goes wrong.
> Instead, they are gathered in a "catch-all" step and attached as
> artifacts.
> - A cache entry is stored once and for all, but if no cache is found you
> can inherit from the default branch cache. The cache is 5GB large, for
> the whole git repository.
> - The maximum retention of logs and artifacts is 3 months.
> - /home/runner is world writable, so a workaround has been added for
> starting dpdk processes.
> - Ilya, working on OVS GHA support, noticed that jobs can run with
> processors that don't have the same capabilities. For DPDK, this
> impacts the ccache content since everything was built with
> -march=native so far, and we will end up with binaries that can't run
> in a later build. The problem has not been seen in Travis CI (?) but
> it is safer to use a fixed "-Dmachine=default" in any case.
That's because the build machine and test machine are the same, but I
think GHA uses a different model, and will spawn a new environment for
the steps. I'm not 100% sure, because it's all supposed to be a
black-box.
> - Scheduling jobs is part of the configuration and takes the form of a
> crontab. A build is scheduled every Monday at 0:00 (UTC) to provide a
> default ccache for the week (useful for the ovsrobot).
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
Acked-by: Aaron Conole <aconole@redhat.com>
> Changelog since v1:
> - changed shell variables value in CI scripts and Travis configuration
> (s/=[^\$]*1/=\1true), this makes it easier for GHA,
> - forced compilation as 'default' to avoid random unit tests issues in
> GHA,
> - scheduled a run per week on Monday at 0:00 UTC,
> - updated the ccache key:
> - no need to depend on the default-library parameter since this
> parameter only impacts the linking of dpdk binaries,
> - the week when the cache is generated is added so that jobs in
> other branches can benefit from a recent cache (mimicking what we had
> for the robot in Travis),
> - realigned documentation generation with what is done in Travis:
> generating the doc in all jobs was a waste of resources,
>
> ---
> .ci/linux-build.sh | 17 +++---
> .github/workflows/build.yml | 100 ++++++++++++++++++++++++++++++++++++
> .travis.yml | 24 ++++-----
> MAINTAINERS | 1 +
> 4 files changed, 123 insertions(+), 19 deletions(-)
> create mode 100644 .github/workflows/build.yml
>
> diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
> index d079801d78..ee8d07f865 100755
> --- a/.ci/linux-build.sh
> +++ b/.ci/linux-build.sh
> @@ -12,7 +12,9 @@ on_error() {
> fi
> done
> }
> -trap on_error EXIT
> +# We capture the error logs as artifacts in Github Actions, no need to dump
> +# them via a EXIT handler.
> +[ -n "$GITHUB_WORKFLOW" ] || trap on_error EXIT
>
> install_libabigail() {
> version=$1
> @@ -28,16 +30,16 @@ install_libabigail() {
> rm ${version}.tar.gz
> }
>
> -if [ "$AARCH64" = "1" ]; then
> +if [ "$AARCH64" = "true" ]; then
> # convert the arch specifier
> OPTS="$OPTS --cross-file config/arm/arm64_armv8_linux_gcc"
> fi
>
> -if [ "$BUILD_DOCS" = "1" ]; then
> +if [ "$BUILD_DOCS" = "true" ]; then
> OPTS="$OPTS -Denable_docs=true"
> fi
>
> -if [ "$BUILD_32BIT" = "1" ]; then
> +if [ "$BUILD_32BIT" = "true" ]; then
> OPTS="$OPTS -Dc_args=-m32 -Dc_link_args=-m32"
> export PKG_CONFIG_LIBDIR="/usr/lib32/pkgconfig"
> fi
> @@ -48,16 +50,17 @@ else
> OPTS="$OPTS -Dexamples=all"
> fi
>
> +OPTS="$OPTS -Dmachine=default"
> OPTS="$OPTS --default-library=$DEF_LIB"
> OPTS="$OPTS --buildtype=debugoptimized"
> meson build --werror $OPTS
> ninja -C build
>
> -if [ "$AARCH64" != "1" ]; then
> +if [ "$AARCH64" != "true" ]; then
> devtools/test-null.sh
> fi
>
> -if [ "$ABI_CHECKS" = "1" ]; then
> +if [ "$ABI_CHECKS" = "true" ]; then
> LIBABIGAIL_VERSION=${LIBABIGAIL_VERSION:-libabigail-1.6}
>
> if [ "$(cat libabigail/VERSION 2>/dev/null)" != "$LIBABIGAIL_VERSION" ]; then
> @@ -95,6 +98,6 @@ if [ "$ABI_CHECKS" = "1" ]; then
> devtools/check-abi.sh reference install ${ABI_CHECKS_WARN_ONLY:-}
> fi
>
> -if [ "$RUN_TESTS" = "1" ]; then
> +if [ "$RUN_TESTS" = "true" ]; then
> sudo meson test -C build --suite fast-tests -t 3
> fi
> diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
> new file mode 100644
> index 0000000000..bef6e52372
> --- /dev/null
> +++ b/.github/workflows/build.yml
> @@ -0,0 +1,100 @@
> +name: build
> +
> +on:
> + push:
> + schedule:
> + - cron: '0 0 * * 1'
> +
> +defaults:
> + run:
> + shell: bash --noprofile --norc -exo pipefail {0}
> +
> +jobs:
> + build:
> + name: ${{ join(matrix.config.*, '-') }}
> + runs-on: ${{ matrix.config.os }}
> + env:
> + AARCH64: ${{ matrix.config.cross == 'aarch64' }}
> + BUILD_32BIT: ${{ matrix.config.cross == 'i386' }}
> + BUILD_DOCS: ${{ contains(matrix.config.checks, 'doc') }}
> + CC: ccache ${{ matrix.config.compiler }}
> + DEF_LIB: ${{ matrix.config.library }}
> + RUN_TESTS: ${{ contains(matrix.config.checks, 'tests') }}
> +
> + strategy:
> + fail-fast: false
> + matrix:
> + config:
> + - os: ubuntu-18.04
> + compiler: gcc
> + library: static
> + - os: ubuntu-18.04
> + compiler: gcc
> + library: shared
> + checks: doc+tests
> + - os: ubuntu-18.04
> + compiler: clang
> + library: static
> + - os: ubuntu-18.04
> + compiler: clang
> + library: shared
> + checks: doc+tests
> + - os: ubuntu-18.04
> + compiler: gcc
> + library: static
> + cross: i386
> + - os: ubuntu-18.04
> + compiler: gcc
> + library: static
> + cross: aarch64
> + - os: ubuntu-18.04
> + compiler: gcc
> + library: shared
> + cross: aarch64
> +
> + steps:
> + - name: Checkout sources
> + uses: actions/checkout@v2
> + - name: Generate cache keys
> + id: get_ref_keys
> + run: |
> + echo -n '::set-output name=ccache::'
> + echo 'ccache-${{ matrix.config.os }}-${{ matrix.config.compiler }}-${{ matrix.config.cross }}-'$(date -u +%Y-w%W)
> + - 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
> + - 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
> + - name: Install i386 cross compiling packages
> + if: env.BUILD_32BIT == 'true'
> + run: sudo apt install -y gcc-multilib
> + - name: Install aarch64 cross compiling packages
> + if: env.AARCH64 == 'true'
> + run: sudo apt install -y gcc-aarch64-linux-gnu libc6-dev-arm64-cross
> + pkg-config-aarch64-linux-gnu
> + - name: Install doc generation packages
> + if: env.BUILD_DOCS == 'true'
> + run: sudo apt install -y doxygen graphviz python3-sphinx
> + python3-sphinx-rtd-theme
> + - name: Run setup
> + run: |
> + .ci/linux-setup.sh
> + # Workaround on $HOME permissions as EAL checks them for plugin loading
> + chmod o-w $HOME
> + - name: Build and test
> + run: .ci/linux-build.sh
> + - name: Upload logs on failure
> + if: failure()
> + uses: actions/upload-artifact@v2
> + with:
> + name: meson-logs-${{ join(matrix.config.*, '-') }}
> + path: |
> + build/meson-logs/testlog.txt
> + build/.ninja_log
> + build/meson-logs/meson-log.txt
> diff --git a/.travis.yml b/.travis.yml
> index 5e12db23b5..d655e286c3 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -34,10 +34,10 @@ jobs:
> - env: DEF_LIB="static"
> arch: amd64
> compiler: gcc
> - - env: DEF_LIB="shared" RUN_TESTS=1
> + - env: DEF_LIB="shared" RUN_TESTS=true
> arch: amd64
> compiler: gcc
> - - env: DEF_LIB="shared" BUILD_DOCS=1
> + - env: DEF_LIB="shared" BUILD_DOCS=true
> arch: amd64
> compiler: gcc
> addons:
> @@ -49,10 +49,10 @@ jobs:
> - env: DEF_LIB="static"
> arch: amd64
> compiler: clang
> - - env: DEF_LIB="shared" RUN_TESTS=1
> + - env: DEF_LIB="shared" RUN_TESTS=true
> arch: amd64
> compiler: clang
> - - env: DEF_LIB="shared" BUILD_DOCS=1
> + - env: DEF_LIB="shared" BUILD_DOCS=true
> arch: amd64
> compiler: clang
> addons:
> @@ -61,7 +61,7 @@ jobs:
> - *required_packages
> - *doc_packages
> # x86_64 cross-compiling 32-bits jobs
> - - env: DEF_LIB="static" BUILD_32BIT=1
> + - env: DEF_LIB="static" BUILD_32BIT=true
> arch: amd64
> compiler: gcc
> addons:
> @@ -69,14 +69,14 @@ jobs:
> packages:
> - *build_32b_packages
> # x86_64 cross-compiling aarch64 jobs
> - - env: DEF_LIB="static" AARCH64=1
> + - env: DEF_LIB="static" AARCH64=true
> arch: amd64
> compiler: gcc
> addons:
> apt:
> packages:
> - *aarch64_packages
> - - env: DEF_LIB="shared" AARCH64=1
> + - env: DEF_LIB="shared" AARCH64=true
> arch: amd64
> compiler: gcc
> addons:
> @@ -87,16 +87,16 @@ jobs:
> - env: DEF_LIB="static"
> arch: arm64
> compiler: gcc
> - - env: DEF_LIB="shared" RUN_TESTS=1
> + - env: DEF_LIB="shared" RUN_TESTS=true
> arch: arm64
> compiler: gcc
> - - env: DEF_LIB="shared" RUN_TESTS=1
> + - env: DEF_LIB="shared" RUN_TESTS=true
> dist: focal
> arch: arm64-graviton2
> virt: vm
> group: edge
> compiler: gcc
> - - env: DEF_LIB="shared" BUILD_DOCS=1
> + - env: DEF_LIB="shared" BUILD_DOCS=true
> arch: arm64
> compiler: gcc
> addons:
> @@ -108,10 +108,10 @@ jobs:
> - env: DEF_LIB="static"
> arch: arm64
> compiler: clang
> - - env: DEF_LIB="shared" RUN_TESTS=1
> + - env: DEF_LIB="shared" RUN_TESTS=true
> arch: arm64
> compiler: clang
> - - env: DEF_LIB="shared" RUN_TESTS=1
> + - env: DEF_LIB="shared" RUN_TESTS=true
> dist: focal
> arch: arm64-graviton2
> virt: vm
> diff --git a/MAINTAINERS b/MAINTAINERS
> index eafe9f8c46..f45c8c1b13 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -109,6 +109,7 @@ Public CI
> M: Aaron Conole <aconole@redhat.com>
> M: Michael Santana <maicolgabriel@hotmail.com>
> F: .travis.yml
> +F: .github/workflows/build.yml
> F: .ci/
>
> ABI Policy & Versioning
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 1/2] ci: hook to GitHub Actions
2020-12-11 20:07 3% ` [dpdk-dev] [PATCH v2 1/2] ci: hook to GitHub Actions Ferruh Yigit
@ 2020-12-14 10:44 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2020-12-14 10:44 UTC (permalink / raw)
To: David Marchand; +Cc: dev, aconole, Michael Santana, Ferruh Yigit
11/12/2020 21:07, Ferruh Yigit:
> On 12/4/2020 5:36 PM, David Marchand wrote:
> > With the recent changes in terms of free access to the Travis CI, let's
> > offer an alternative with GitHub Actions.
> > Running jobs on ARM is not supported unless using external runners, so
> > this commit only adds builds for x86_64 and cross compiling for i386 and
> > aarch64.
> >
> > Differences with the Travis CI integration:
> > - Error logs are not dumped to the console when something goes wrong.
> > Instead, they are gathered in a "catch-all" step and attached as
> > artifacts.
> > - A cache entry is stored once and for all, but if no cache is found you
> > can inherit from the default branch cache. The cache is 5GB large, for
> > the whole git repository.
> > - The maximum retention of logs and artifacts is 3 months.
> > - /home/runner is world writable, so a workaround has been added for
> > starting dpdk processes.
> > - Ilya, working on OVS GHA support, noticed that jobs can run with
> > processors that don't have the same capabilities. For DPDK, this
> > impacts the ccache content since everything was built with
> > -march=native so far, and we will end up with binaries that can't run
> > in a later build. The problem has not been seen in Travis CI (?) but
> > it is safer to use a fixed "-Dmachine=default" in any case.
> > - Scheduling jobs is part of the configuration and takes the form of a
> > crontab. A build is scheduled every Monday at 0:00 (UTC) to provide a
> > default ccache for the week (useful for the ovsrobot).
> >
> > Signed-off-by: David Marchand <david.marchand@redhat.com>
> > ---
> > Changelog since v1:
> > - changed shell variables value in CI scripts and Travis configuration
> > (s/=[^\$]*1/=\1true), this makes it easier for GHA,
> > - forced compilation as 'default' to avoid random unit tests issues in
> > GHA,
> > - scheduled a run per week on Monday at 0:00 UTC,
> > - updated the ccache key:
> > - no need to depend on the default-library parameter since this
> > parameter only impacts the linking of dpdk binaries,
> > - the week when the cache is generated is added so that jobs in
> > other branches can benefit from a recent cache (mimicking what we had
> > for the robot in Travis),
> > - realigned documentation generation with what is done in Travis:
> > generating the doc in all jobs was a waste of resources,
> >
>
> For series,
> Tested-by: Ferruh Yigit <ferruh.yigit@intel.com>
>
> Confirmed that ABI check script is detecting issues, in the absence of the
> Travis checks I am for having this alternative.
Thanks for offering an interesting CI alternative.
For the series,
Acked-by: Thomas Monjalon <thomas@monjalon.net>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 1/2] ci: hook to GitHub Actions
2020-12-04 17:36 4% ` [dpdk-dev] [PATCH v2 1/2] ci: hook to GitHub Actions David Marchand
2020-12-04 17:36 20% ` [dpdk-dev] [PATCH v2 2/2] ci: enable v21 ABI checks David Marchand
@ 2020-12-11 20:07 3% ` Ferruh Yigit
2020-12-14 10:44 0% ` Thomas Monjalon
2020-12-14 14:12 0% ` Aaron Conole
2 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2020-12-11 20:07 UTC (permalink / raw)
To: David Marchand, dev; +Cc: aconole, Michael Santana, Thomas Monjalon
On 12/4/2020 5:36 PM, David Marchand wrote:
> With the recent changes in terms of free access to the Travis CI, let's
> offer an alternative with GitHub Actions.
> Running jobs on ARM is not supported unless using external runners, so
> this commit only adds builds for x86_64 and cross compiling for i386 and
> aarch64.
>
> Differences with the Travis CI integration:
> - Error logs are not dumped to the console when something goes wrong.
> Instead, they are gathered in a "catch-all" step and attached as
> artifacts.
> - A cache entry is stored once and for all, but if no cache is found you
> can inherit from the default branch cache. The cache is 5GB large, for
> the whole git repository.
> - The maximum retention of logs and artifacts is 3 months.
> - /home/runner is world writable, so a workaround has been added for
> starting dpdk processes.
> - Ilya, working on OVS GHA support, noticed that jobs can run with
> processors that don't have the same capabilities. For DPDK, this
> impacts the ccache content since everything was built with
> -march=native so far, and we will end up with binaries that can't run
> in a later build. The problem has not been seen in Travis CI (?) but
> it is safer to use a fixed "-Dmachine=default" in any case.
> - Scheduling jobs is part of the configuration and takes the form of a
> crontab. A build is scheduled every Monday at 0:00 (UTC) to provide a
> default ccache for the week (useful for the ovsrobot).
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
> Changelog since v1:
> - changed shell variables value in CI scripts and Travis configuration
> (s/=[^\$]*1/=\1true), this makes it easier for GHA,
> - forced compilation as 'default' to avoid random unit tests issues in
> GHA,
> - scheduled a run per week on Monday at 0:00 UTC,
> - updated the ccache key:
> - no need to depend on the default-library parameter since this
> parameter only impacts the linking of dpdk binaries,
> - the week when the cache is generated is added so that jobs in
> other branches can benefit from a recent cache (mimicking what we had
> for the robot in Travis),
> - realigned documentation generation with what is done in Travis:
> generating the doc in all jobs was a waste of resources,
>
For series,
Tested-by: Ferruh Yigit <ferruh.yigit@intel.com>
Confirmed that ABI check script is detecting issues, in the absence of the
Travis checks I am for having this alternative.
^ permalink raw reply [relevance 3%]
* [dpdk-dev] DPDK Release Status Meeting 10/12/2020
@ 2020-12-10 10:54 3% Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2020-12-10 10:54 UTC (permalink / raw)
To: dev; +Cc: Thomas Monjalon
Meeting minutes of 10 December 2020
-----------------------------------
Agenda:
* Release Dates
* Subtrees
* LTS
* OvS
* Opens
Participants:
* Arm
* Broadcom
* Debian/Microsoft
* Intel
* Nvidia
* Red Hat
Release Dates
-------------
* v21.02 dates
* Proposal/V1: Sunday, 20 December 2020
* -rc1: Friday, 15 January 2021
* Release: Friday, 5 February 2021
* Please send roadmaps, preferably before beginning of the release
* Thanks to NTT for sending roadmap
Subtrees
--------
* main
* Tooling/testing patches in the backlog
* There are patches deferred from previous release
* It is preferred to get risky patches early, to give enough time them to be
tested
* Travis not working is a concern for ABI checks
* David sent patch a patch to enable github actions for checks
* https://patches.dpdk.org/project/dpdk/list/?series=14188
* Please test
* Many people will be taking holidays on last two weeks of the year
* next-net
* A few patches reviewed & merged
* No big backlog as of now, nothing interesting
* next-crypto
* No update
* next-eventdev
* No update
* next-virtio
* There are some patches deferred from previous release
* next-net-mlx, next-net-brcm
* Some patches merged and can be pulled
* next-net-intel, next-net-mrvl
* No update
LTS
---
* v19.11.6-rc1 is out, please test
* http://inbox.dpdk.org/dev/20201203093856.299103-1-luca.boccassi@gmail.com/
* Waiting for test reports
* Target release date is 17 December
* v18.11.10 work is going on
* waiting for backports, request emails sent
* Some backports received, waiting for some others
* target is to close the -rc1 before holidays
OvS
---
* OvS side reported a build error related to the pkgconfig flag
* Bruce is investigating it
Opens
-----
* Asaf shared a draft release process documentation
* After review there were no objection to the document, it will be shared
publicly
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 3%]
* Re: [dpdk-dev] [PATCH 1/1] devtools: avoid installing static binaries
2020-12-08 15:37 4% ` David Marchand
@ 2020-12-08 15:52 5% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2020-12-08 15:52 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Bruce Richardson
08/12/2020 16:37, David Marchand:
> On Mon, Dec 7, 2020 at 6:33 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> >
> > When testing compilation and checking ABI compatibility,
> > there is no real need of static binaries eating disks.
> > The static linkage of applications are tested with GCC and Clang,
> > plus some examples are statically linked.
> > The after-installation build test is limited to "helloworld" example.
> > Note the meson static build test was already limited to "l3fwd" example.
> >
> > The ABI compatibility is checked on shared libraries, so no need
> > running this test a second time on builds intended for static linking.
> > However, limiting ABI check to "shared builds" means all test cases
> > must have a "shared build" occurence.
> > As a consequence the 32-bit build test is switched to shared linking.
>
> I see no reason to tie the ABI check to default-library.
The only reason is that ABI check triggers binary installation,
which is big when statically linked.
> What about the mingw target?
ABI check is not required for Windows.
BTW there are issues with DLL support.
> What you want is to avoid doing duplicate ABI checks.
> This happens for the gcc/clang x86 builds, so I'd rather control the
> ABI checks out of the build() function (passing a new parameter?).
Yes, it would be cleaner to separate ABI check requirement
and static linking.
In v2, ABI check will be enabled explicitly when calling "build" function
for shared builds.
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH 1/1] devtools: avoid installing static binaries
2020-12-07 17:33 10% [dpdk-dev] [PATCH 1/1] devtools: avoid installing static binaries Thomas Monjalon
2020-12-07 17:47 3% ` Bruce Richardson
@ 2020-12-08 15:37 4% ` David Marchand
2020-12-08 15:52 5% ` Thomas Monjalon
2021-01-13 19:05 13% ` [dpdk-dev] [PATCH v2 " Thomas Monjalon
2 siblings, 1 reply; 200+ results
From: David Marchand @ 2020-12-08 15:37 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Bruce Richardson
On Mon, Dec 7, 2020 at 6:33 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> When testing compilation and checking ABI compatibility,
> there is no real need of static binaries eating disks.
> The static linkage of applications are tested with GCC and Clang,
> plus some examples are statically linked.
> The after-installation build test is limited to "helloworld" example.
> Note the meson static build test was already limited to "l3fwd" example.
>
> The ABI compatibility is checked on shared libraries, so no need
> running this test a second time on builds intended for static linking.
> However, limiting ABI check to "shared builds" means all test cases
> must have a "shared build" occurence.
> As a consequence the 32-bit build test is switched to shared linking.
I see no reason to tie the ABI check to default-library.
What about the mingw target?
What you want is to avoid doing duplicate ABI checks.
This happens for the gcc/clang x86 builds, so I'd rather control the
ABI checks out of the build() function (passing a new parameter?).
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 1/1] devtools: adjust verbosity of ABI check
2020-12-08 15:22 9% ` Kinsella, Ray
@ 2020-12-08 15:32 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2020-12-08 15:32 UTC (permalink / raw)
To: dev, Kinsella, Ray; +Cc: david.marchand, bruce.richardson, Neil Horman
08/12/2020 16:22, Kinsella, Ray:
>
> On 07/12/2020 17:32, Thomas Monjalon wrote:
> > 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.
>
> So there is a bit of a disconnect here - you change gen-abi/check-abi to
> correctly direct errors to sterr.
>
> You then however provide a method to ignore them in test_meson_build.sh.
> I thinking giving people a way of ignoring the indicated lines below,
> is a bad plan.
>
> No problem with the changes to check-abi/gen-abi - but I think the changes
> to test_meson_build.sh are a bad idea.
No the errors are not ignored.
Only stdout (report details) is redirected.
> > $srcdir/devtools/check-abi.sh $abirefdir/$targetdir \
> > - $(readlink -f $builds_dir/$targetdir/install)
> > + $(readlink -f $builds_dir/$targetdir/install) >&$verbose
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 1/1] devtools: adjust verbosity of ABI check
2020-12-07 17:32 36% [dpdk-dev] [PATCH 1/1] devtools: adjust verbosity of ABI check Thomas Monjalon
2020-12-08 15:22 9% ` Kinsella, Ray
@ 2020-12-08 15:31 4% ` David Marchand
2020-12-17 9:05 36% ` [dpdk-dev] [PATCH v2 " Thomas Monjalon
2 siblings, 0 replies; 200+ results
From: David Marchand @ 2020-12-08 15:31 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Bruce Richardson, Ray Kinsella, Neil Horman
On Mon, Dec 7, 2020 at 6:33 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> diff --git a/devtools/check-abi.sh b/devtools/check-abi.sh
> index ab6748cfbc..381db2cdd1 100755
> --- a/devtools/check-abi.sh
> +++ b/devtools/check-abi.sh
[snip]
> @@ -46,23 +46,24 @@ for dump in $(find $refdir -name "*.dump"); do
> fi
> dump2=$(find $newdir -name $name)
> if [ -z "$dump2" ] || [ ! -e "$dump2" ]; then
> - echo "Error: can't find $name in $newdir"
> + echo "Error: cannot find $name in $newdir" >&2
> error=1
> continue
> fi
> + echo abidiff $ABIDIFF_OPTIONS $dump $dump2
On error, this same command is repeated below, so I don't see the need
for this new debug message.
> abidiff $ABIDIFF_OPTIONS $dump $dump2 || {
> abiret=$?
> - echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $dump $dump2'"
> + echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $dump $dump2'" >&2
> error=1
> echo
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 1/1] devtools: adjust verbosity of ABI check
2020-12-07 17:32 36% [dpdk-dev] [PATCH 1/1] devtools: adjust verbosity of ABI check Thomas Monjalon
@ 2020-12-08 15:22 9% ` Kinsella, Ray
2020-12-08 15:32 4% ` Thomas Monjalon
2020-12-08 15:31 4% ` David Marchand
2020-12-17 9:05 36% ` [dpdk-dev] [PATCH v2 " Thomas Monjalon
2 siblings, 1 reply; 200+ results
From: Kinsella, Ray @ 2020-12-08 15:22 UTC (permalink / raw)
To: Thomas Monjalon, dev; +Cc: david.marchand, bruce.richardson, Neil Horman
On 07/12/2020 17:32, Thomas Monjalon wrote:
> 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.
So there is a bit of a disconnect here - you change gen-abi/check-abi to
correctly direct errors to sterr.
You then however provide a method to ignore them in test_meson_build.sh.
I thinking giving people a way of ignoring the indicated lines below,
is a bad plan.
No problem with the changes to check-abi/gen-abi - but I think the changes
to test_meson_build.sh are a bad idea.
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> ---
> devtools/check-abi.sh | 21 +++++++++++----------
> devtools/gen-abi.sh | 4 ++--
> devtools/test-meson-builds.sh | 9 +++++++--
> 3 files changed, 20 insertions(+), 14 deletions(-)
>
> diff --git a/devtools/check-abi.sh b/devtools/check-abi.sh
> index ab6748cfbc..381db2cdd1 100755
> --- a/devtools/check-abi.sh
> +++ b/devtools/check-abi.sh
> @@ -3,7 +3,7 @@
> # Copyright (c) 2019 Red Hat, Inc.
>
> if [ $# != 2 ] && [ $# != 3 ]; then
> - echo "Usage: $0 refdir newdir [warnonly]"
> + echo "Usage: $0 refdir newdir [warnonly]" >&2
> exit 1
> fi
>
> @@ -13,23 +13,23 @@ warnonly=${3:-}
> ABIDIFF_OPTIONS="--suppr $(dirname $0)/libabigail.abignore --no-added-syms"
>
> if [ ! -d $refdir ]; then
> - echo "Error: reference directory '$refdir' does not exist."
> + echo "Error: reference directory '$refdir' does not exist." >&2
> exit 1
> fi
> incdir=$(find $refdir -type d -a -name include)
> if [ -z "$incdir" ] || [ ! -e "$incdir" ]; then
> - echo "WARNING: could not identify a include directory for $refdir, expect false positives..."
> + echo "WARNING: could not identify an include directory for $refdir, expect false positives..." >&2
> else
> ABIDIFF_OPTIONS="$ABIDIFF_OPTIONS --headers-dir1 $incdir"
> fi
>
> if [ ! -d $newdir ]; then
> - echo "Error: directory to check '$newdir' does not exist."
> + echo "Error: directory to check '$newdir' does not exist." >&2
> exit 1
> fi
> incdir2=$(find $newdir -type d -a -name include)
> if [ -z "$incdir2" ] || [ ! -e "$incdir2" ]; then
> - echo "WARNING: could not identify a include directory for $newdir, expect false positives..."
> + echo "WARNING: could not identify an include directory for $newdir, expect false positives..." >&2
> else
> ABIDIFF_OPTIONS="$ABIDIFF_OPTIONS --headers-dir2 $incdir2"
> fi
> @@ -46,23 +46,24 @@ for dump in $(find $refdir -name "*.dump"); do
> fi
> dump2=$(find $newdir -name $name)
> if [ -z "$dump2" ] || [ ! -e "$dump2" ]; then
> - echo "Error: can't find $name in $newdir"
> + echo "Error: cannot find $name in $newdir" >&2
> error=1
> continue
> fi
> + echo abidiff $ABIDIFF_OPTIONS $dump $dump2
> abidiff $ABIDIFF_OPTIONS $dump $dump2 || {
> abiret=$?
> - echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $dump $dump2'"
> + echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $dump $dump2'" >&2
> error=1
> echo
> if [ $(($abiret & 3)) -ne 0 ]; then
> - echo "ABIDIFF_ERROR|ABIDIFF_USAGE_ERROR, this could be a script or environment issue."
> + echo "ABIDIFF_ERROR|ABIDIFF_USAGE_ERROR, this could be a script or environment issue." >&2
> fi
> if [ $(($abiret & 4)) -ne 0 ]; then
> - echo "ABIDIFF_ABI_CHANGE, this change requires a review (abidiff flagged this as a potential issue)."
> + echo "ABIDIFF_ABI_CHANGE, this change requires a review (abidiff flagged this as a potential issue)." >&2
> fi
> if [ $(($abiret & 8)) -ne 0 ]; then
> - echo "ABIDIFF_ABI_INCOMPATIBLE_CHANGE, this change breaks the ABI."
> + echo "ABIDIFF_ABI_INCOMPATIBLE_CHANGE, this change breaks the ABI." >&2> fi
> echo
> }
> diff --git a/devtools/gen-abi.sh b/devtools/gen-abi.sh
> index c44b0e228a..f15a3b9aaf 100755
> --- a/devtools/gen-abi.sh
> +++ b/devtools/gen-abi.sh
> @@ -3,13 +3,13 @@
> # Copyright (c) 2019 Red Hat, Inc.
>
> if [ $# != 1 ]; then
> - echo "Usage: $0 installdir"
> + echo "Usage: $0 installdir" >&2
> exit 1
> fi
>
> installdir=$1
> if [ ! -d $installdir ]; then
> - echo "Error: install directory '$installdir' does not exist."
> + echo "Error: install directory '$installdir' does not exist." >&2
> exit 1
> fi
>
> diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
> index ed44d4ffb1..16a81b6241 100755
> --- a/devtools/test-meson-builds.sh
> +++ b/devtools/test-meson-builds.sh
> @@ -194,10 +194,15 @@ build () # <directory> <target compiler | cross file> <meson options>
>
> install_target $builds_dir/$targetdir \
> $(readlink -f $builds_dir/$targetdir/install)
> + echo "Checking ABI compatibility of $targetdir" >&$verbose
> + echo $srcdir/devtools/gen-abi.sh \
> + $(readlink -f $builds_dir/$targetdir/install) >&$veryverbose
> $srcdir/devtools/gen-abi.sh \
> - $(readlink -f $builds_dir/$targetdir/install)
> + $(readlink -f $builds_dir/$targetdir/install) >&$veryverbose
> + echo $srcdir/devtools/check-abi.sh $abirefdir/$targetdir \
> + $(readlink -f $builds_dir/$targetdir/install) >&$veryverbose
> $srcdir/devtools/check-abi.sh $abirefdir/$targetdir \
> - $(readlink -f $builds_dir/$targetdir/install)
> + $(readlink -f $builds_dir/$targetdir/install) >&$verbose
> fi
> }
>
>
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] [PATCH] ci: hook to Github Actions
@ 2020-12-08 14:08 4% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2020-12-08 14:08 UTC (permalink / raw)
To: Honnappa Nagarahalli, Aaron Conole
Cc: dev, Michael Santana, thomas, nd, Ruifeng Wang, Juraj Linkeš
On Thu, Nov 26, 2020 at 6:01 PM Honnappa Nagarahalli
<Honnappa.Nagarahalli@arm.com> wrote:
> > > Is there any guarantee that GitHub actions will be free forever?
> >
> > There is no "forever".
> I think we are spending our efforts on things that will not work for the community in the long run (unless the project spends money to buy credits)
That was not the initial goal of the patch, but GHA can be used by
developers who work on their github forks too, like for testing before
submitting to the public ml.
On spending efforts, the lab should be the priority.
My main concern was to get ABI checks back quickly since 21.02
proposals started to hit the list.
A ticket has been opened for the lab to handle this, but this can take
some time so in the interim we have GHA support.
I sent the v2 with ABI checks.
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 1/1] devtools: avoid installing static binaries
2020-12-07 18:12 0% ` Thomas Monjalon
@ 2020-12-08 9:33 0% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2020-12-08 9:33 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, david.marchand
On Mon, Dec 07, 2020 at 07:12:32PM +0100, Thomas Monjalon wrote:
> 07/12/2020 18:47, Bruce Richardson:
> > On Mon, Dec 07, 2020 at 06:33:19PM +0100, Thomas Monjalon wrote:
> > > When testing compilation and checking ABI compatibility,
> > > there is no real need of static binaries eating disks.
> > > The static linkage of applications are tested with GCC and Clang,
> > > plus some examples are statically linked.
> > > The after-installation build test is limited to "helloworld" example.
> > > Note the meson static build test was already limited to "l3fwd" example.
> > >
> > > The ABI compatibility is checked on shared libraries, so no need
> > > running this test a second time on builds intended for static linking.
> > > However, limiting ABI check to "shared builds" means all test cases
> > > must have a "shared build" occurence.
> > > As a consequence the 32-bit build test is switched to shared linking.
> > >
> > > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> > > ---
> > > devtools/test-meson-builds.sh | 8 ++++++--
> > > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > I think this might be better as two patches - one for the ABI check changes
> > and a second for the example build changes with installed DPDK.
>
> Yes could be 2 patches.
>
>
> > > 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
> >
> > Just wonder are we likely to miss things with this change? Would changing
> > the order to do a clean at the end to free back up the disk space not
> > achieve much the same result while still saving disk space?
>
> Not building static flavour of most examples is also faster.
> Ideally we should not rebuild an example if the libs did not change.
>
> To the question "will we miss something", the difference between static
> and shared examples is just the pkg-config call in the Makefile.
> I think the risk is small.
>
Yes, for the majority of the apps that is the case. However, the only
concern I have is for a number of the apps which link directly against a
driver or two. Looking at vm_power_manager example, which links against 3
drivers, I see that the extra flags are only added for shared builds so we
should be ok for that one anyway.
Therefore ok with this change exactly as you suggest.
/Bruce
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 1/1] devtools: avoid installing static binaries
2020-12-07 17:47 3% ` Bruce Richardson
@ 2020-12-07 18:12 0% ` Thomas Monjalon
2020-12-08 9:33 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2020-12-07 18:12 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev, david.marchand
07/12/2020 18:47, Bruce Richardson:
> On Mon, Dec 07, 2020 at 06:33:19PM +0100, Thomas Monjalon wrote:
> > When testing compilation and checking ABI compatibility,
> > there is no real need of static binaries eating disks.
> > The static linkage of applications are tested with GCC and Clang,
> > plus some examples are statically linked.
> > The after-installation build test is limited to "helloworld" example.
> > Note the meson static build test was already limited to "l3fwd" example.
> >
> > The ABI compatibility is checked on shared libraries, so no need
> > running this test a second time on builds intended for static linking.
> > However, limiting ABI check to "shared builds" means all test cases
> > must have a "shared build" occurence.
> > As a consequence the 32-bit build test is switched to shared linking.
> >
> > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> > ---
> > devtools/test-meson-builds.sh | 8 ++++++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
>
> I think this might be better as two patches - one for the ABI check changes
> and a second for the example build changes with installed DPDK.
Yes could be 2 patches.
> > 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
>
> Just wonder are we likely to miss things with this change? Would changing
> the order to do a clean at the end to free back up the disk space not
> achieve much the same result while still saving disk space?
Not building static flavour of most examples is also faster.
Ideally we should not rebuild an example if the libs did not change.
To the question "will we miss something", the difference between static
and shared examples is just the pkg-config call in the Makefile.
I think the risk is small.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 1/1] devtools: avoid installing static binaries
2020-12-07 17:33 10% [dpdk-dev] [PATCH 1/1] devtools: avoid installing static binaries Thomas Monjalon
@ 2020-12-07 17:47 3% ` Bruce Richardson
2020-12-07 18:12 0% ` Thomas Monjalon
2020-12-08 15:37 4% ` David Marchand
2021-01-13 19:05 13% ` [dpdk-dev] [PATCH v2 " Thomas Monjalon
2 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2020-12-07 17:47 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, david.marchand
On Mon, Dec 07, 2020 at 06:33:19PM +0100, Thomas Monjalon wrote:
> When testing compilation and checking ABI compatibility,
> there is no real need of static binaries eating disks.
> The static linkage of applications are tested with GCC and Clang,
> plus some examples are statically linked.
> The after-installation build test is limited to "helloworld" example.
> Note the meson static build test was already limited to "l3fwd" example.
>
> The ABI compatibility is checked on shared libraries, so no need
> running this test a second time on builds intended for static linking.
> However, limiting ABI check to "shared builds" means all test cases
> must have a "shared build" occurence.
> As a consequence the 32-bit build test is switched to shared linking.
>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> ---
> devtools/test-meson-builds.sh | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
I think this might be better as two patches - one for the ABI check changes
and a second for the example build changes with installed DPDK.
>
> diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
> index 7280b7a93d..ed44d4ffb1 100755
> --- a/devtools/test-meson-builds.sh
> +++ b/devtools/test-meson-builds.sh
> @@ -166,6 +166,9 @@ build () # <directory> <target compiler | cross file> <meson options>
> config $srcdir $builds_dir/$targetdir $cross --werror $*
> compile $builds_dir/$targetdir
> if [ -n "$DPDK_ABI_REF_VERSION" ]; then
> + if echo $* | grep -qw -- '--default-library=static' ; then
> + return # skip ABI check for static build
> + fi
> abirefdir=${DPDK_ABI_REF_DIR:-reference}/$DPDK_ABI_REF_VERSION
> if [ ! -d $abirefdir/$targetdir ]; then
> # clone current sources
> @@ -230,7 +233,7 @@ 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 -Dc_args='-m32' -Dc_link_args='-m32' $use_shared
> target_override=
> unset PKG_CONFIG_LIBDIR
> fi
> @@ -274,7 +277,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
Just wonder are we likely to miss things with this change? Would changing
the order to do a clean at the end to free back up the disk space not
achieve much the same result while still saving disk space?
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH 1/1] devtools: avoid installing static binaries
@ 2020-12-07 17:33 10% Thomas Monjalon
2020-12-07 17:47 3% ` Bruce Richardson
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Thomas Monjalon @ 2020-12-07 17:33 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 are tested with GCC and Clang,
plus some examples are statically linked.
The after-installation build test is limited to "helloworld" example.
Note the meson static build test was already limited to "l3fwd" example.
The ABI compatibility is checked on shared libraries, so no need
running this test a second time on builds intended for static linking.
However, limiting ABI check to "shared builds" means all test cases
must have a "shared build" occurence.
As a consequence the 32-bit build test is switched to shared linking.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
devtools/test-meson-builds.sh | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index 7280b7a93d..ed44d4ffb1 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -166,6 +166,9 @@ build () # <directory> <target compiler | cross file> <meson options>
config $srcdir $builds_dir/$targetdir $cross --werror $*
compile $builds_dir/$targetdir
if [ -n "$DPDK_ABI_REF_VERSION" ]; then
+ if echo $* | grep -qw -- '--default-library=static' ; then
+ return # skip ABI check for static build
+ fi
abirefdir=${DPDK_ABI_REF_DIR:-reference}/$DPDK_ABI_REF_VERSION
if [ ! -d $abirefdir/$targetdir ]; then
# clone current sources
@@ -230,7 +233,7 @@ 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 -Dc_args='-m32' -Dc_link_args='-m32' $use_shared
target_override=
unset PKG_CONFIG_LIBDIR
fi
@@ -274,7 +277,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 10%]
* [dpdk-dev] [PATCH 1/1] devtools: adjust verbosity of ABI check
@ 2020-12-07 17:32 36% Thomas Monjalon
2020-12-08 15:22 9% ` Kinsella, Ray
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Thomas Monjalon @ 2020-12-07 17:32 UTC (permalink / raw)
To: dev; +Cc: david.marchand, bruce.richardson, Ray Kinsella, Neil Horman
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>
---
devtools/check-abi.sh | 21 +++++++++++----------
devtools/gen-abi.sh | 4 ++--
devtools/test-meson-builds.sh | 9 +++++++--
3 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/devtools/check-abi.sh b/devtools/check-abi.sh
index ab6748cfbc..381db2cdd1 100755
--- a/devtools/check-abi.sh
+++ b/devtools/check-abi.sh
@@ -3,7 +3,7 @@
# Copyright (c) 2019 Red Hat, Inc.
if [ $# != 2 ] && [ $# != 3 ]; then
- echo "Usage: $0 refdir newdir [warnonly]"
+ echo "Usage: $0 refdir newdir [warnonly]" >&2
exit 1
fi
@@ -13,23 +13,23 @@ warnonly=${3:-}
ABIDIFF_OPTIONS="--suppr $(dirname $0)/libabigail.abignore --no-added-syms"
if [ ! -d $refdir ]; then
- echo "Error: reference directory '$refdir' does not exist."
+ echo "Error: reference directory '$refdir' does not exist." >&2
exit 1
fi
incdir=$(find $refdir -type d -a -name include)
if [ -z "$incdir" ] || [ ! -e "$incdir" ]; then
- echo "WARNING: could not identify a include directory for $refdir, expect false positives..."
+ echo "WARNING: could not identify an include directory for $refdir, expect false positives..." >&2
else
ABIDIFF_OPTIONS="$ABIDIFF_OPTIONS --headers-dir1 $incdir"
fi
if [ ! -d $newdir ]; then
- echo "Error: directory to check '$newdir' does not exist."
+ echo "Error: directory to check '$newdir' does not exist." >&2
exit 1
fi
incdir2=$(find $newdir -type d -a -name include)
if [ -z "$incdir2" ] || [ ! -e "$incdir2" ]; then
- echo "WARNING: could not identify a include directory for $newdir, expect false positives..."
+ echo "WARNING: could not identify an include directory for $newdir, expect false positives..." >&2
else
ABIDIFF_OPTIONS="$ABIDIFF_OPTIONS --headers-dir2 $incdir2"
fi
@@ -46,23 +46,24 @@ for dump in $(find $refdir -name "*.dump"); do
fi
dump2=$(find $newdir -name $name)
if [ -z "$dump2" ] || [ ! -e "$dump2" ]; then
- echo "Error: can't find $name in $newdir"
+ echo "Error: cannot find $name in $newdir" >&2
error=1
continue
fi
+ echo abidiff $ABIDIFF_OPTIONS $dump $dump2
abidiff $ABIDIFF_OPTIONS $dump $dump2 || {
abiret=$?
- echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $dump $dump2'"
+ echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $dump $dump2'" >&2
error=1
echo
if [ $(($abiret & 3)) -ne 0 ]; then
- echo "ABIDIFF_ERROR|ABIDIFF_USAGE_ERROR, this could be a script or environment issue."
+ echo "ABIDIFF_ERROR|ABIDIFF_USAGE_ERROR, this could be a script or environment issue." >&2
fi
if [ $(($abiret & 4)) -ne 0 ]; then
- echo "ABIDIFF_ABI_CHANGE, this change requires a review (abidiff flagged this as a potential issue)."
+ echo "ABIDIFF_ABI_CHANGE, this change requires a review (abidiff flagged this as a potential issue)." >&2
fi
if [ $(($abiret & 8)) -ne 0 ]; then
- echo "ABIDIFF_ABI_INCOMPATIBLE_CHANGE, this change breaks the ABI."
+ echo "ABIDIFF_ABI_INCOMPATIBLE_CHANGE, this change breaks the ABI." >&2
fi
echo
}
diff --git a/devtools/gen-abi.sh b/devtools/gen-abi.sh
index c44b0e228a..f15a3b9aaf 100755
--- a/devtools/gen-abi.sh
+++ b/devtools/gen-abi.sh
@@ -3,13 +3,13 @@
# Copyright (c) 2019 Red Hat, Inc.
if [ $# != 1 ]; then
- echo "Usage: $0 installdir"
+ echo "Usage: $0 installdir" >&2
exit 1
fi
installdir=$1
if [ ! -d $installdir ]; then
- echo "Error: install directory '$installdir' does not exist."
+ echo "Error: install directory '$installdir' does not exist." >&2
exit 1
fi
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index ed44d4ffb1..16a81b6241 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -194,10 +194,15 @@ build () # <directory> <target compiler | cross file> <meson options>
install_target $builds_dir/$targetdir \
$(readlink -f $builds_dir/$targetdir/install)
+ echo "Checking ABI compatibility of $targetdir" >&$verbose
+ echo $srcdir/devtools/gen-abi.sh \
+ $(readlink -f $builds_dir/$targetdir/install) >&$veryverbose
$srcdir/devtools/gen-abi.sh \
- $(readlink -f $builds_dir/$targetdir/install)
+ $(readlink -f $builds_dir/$targetdir/install) >&$veryverbose
+ echo $srcdir/devtools/check-abi.sh $abirefdir/$targetdir \
+ $(readlink -f $builds_dir/$targetdir/install) >&$veryverbose
$srcdir/devtools/check-abi.sh $abirefdir/$targetdir \
- $(readlink -f $builds_dir/$targetdir/install)
+ $(readlink -f $builds_dir/$targetdir/install) >&$verbose
fi
}
--
2.29.2
^ permalink raw reply [relevance 36%]
* [dpdk-dev] [PATCH v2 2/2] ci: enable v21 ABI checks
2020-12-04 17:36 4% ` [dpdk-dev] [PATCH v2 1/2] ci: hook to GitHub Actions David Marchand
@ 2020-12-04 17:36 20% ` David Marchand
2020-12-14 14:13 4% ` Aaron Conole
2020-12-11 20:07 3% ` [dpdk-dev] [PATCH v2 1/2] ci: hook to GitHub Actions Ferruh Yigit
2020-12-14 14:12 0% ` Aaron Conole
2 siblings, 1 reply; 200+ results
From: David Marchand @ 2020-12-04 17:36 UTC (permalink / raw)
To: dev; +Cc: aconole, Michael Santana
v21 ABI will be maintained until v21.11.
Let's use the latest released libabigail 1.8.
In GitHub Actions, libabigail binaries and the ABI reference are stored
in two shared caches as all branches can use the same.
While at it, we can reproduce changes from the commit 0b8086ce3fe7
("devtools: remove useless files from ABI reference").
This will save some space in the CI caches.
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
.ci/linux-build.sh | 5 ++++-
.github/workflows/build.yml | 26 +++++++++++++++++++++++++-
.travis.yml | 27 +++++++++++++++++++++++++++
3 files changed, 56 insertions(+), 2 deletions(-)
diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
index ee8d07f865..d2c821adf3 100755
--- a/.ci/linux-build.sh
+++ b/.ci/linux-build.sh
@@ -86,10 +86,13 @@ if [ "$ABI_CHECKS" = "true" ]; then
if [ ! -d reference ]; then
refsrcdir=$(readlink -f $(pwd)/../dpdk-$REF_GIT_TAG)
git clone --single-branch -b $REF_GIT_TAG $REF_GIT_REPO $refsrcdir
- meson --werror $OPTS $refsrcdir $refsrcdir/build
+ meson $OPTS -Dexamples= $refsrcdir $refsrcdir/build
ninja -C $refsrcdir/build
DESTDIR=$(pwd)/reference ninja -C $refsrcdir/build install
devtools/gen-abi.sh reference
+ find reference/usr/local -name '*.a' -delete
+ rm -rf reference/usr/local/bin
+ rm -rf reference/usr/local/share
echo $REF_GIT_TAG > reference/VERSION
fi
diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
index bef6e52372..05eb59527f 100644
--- a/.github/workflows/build.yml
+++ b/.github/workflows/build.yml
@@ -15,10 +15,13 @@ jobs:
runs-on: ${{ matrix.config.os }}
env:
AARCH64: ${{ matrix.config.cross == 'aarch64' }}
+ ABI_CHECKS: ${{ contains(matrix.config.checks, 'abi') }}
BUILD_32BIT: ${{ matrix.config.cross == 'i386' }}
BUILD_DOCS: ${{ contains(matrix.config.checks, 'doc') }}
CC: ccache ${{ matrix.config.compiler }}
DEF_LIB: ${{ matrix.config.library }}
+ LIBABIGAIL_VERSION: libabigail-1.8
+ REF_GIT_TAG: v20.11
RUN_TESTS: ${{ contains(matrix.config.checks, 'tests') }}
strategy:
@@ -31,7 +34,7 @@ jobs:
- os: ubuntu-18.04
compiler: gcc
library: shared
- checks: doc+tests
+ checks: abi+doc+tests
- os: ubuntu-18.04
compiler: clang
library: static
@@ -60,6 +63,10 @@ jobs:
run: |
echo -n '::set-output name=ccache::'
echo 'ccache-${{ matrix.config.os }}-${{ matrix.config.compiler }}-${{ matrix.config.cross }}-'$(date -u +%Y-w%W)
+ echo -n '::set-output name=libabigail::'
+ 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 }}'
- name: Retrieve ccache cache
uses: actions/cache@v2
with:
@@ -67,10 +74,27 @@ jobs:
key: ${{ steps.get_ref_keys.outputs.ccache }}-${{ github.ref }}
restore-keys: |
${{ steps.get_ref_keys.outputs.ccache }}-refs/heads/main
+ - name: Retrieve libabigail cache
+ id: libabigail-cache
+ uses: actions/cache@v2
+ if: env.ABI_CHECKS == 'true'
+ with:
+ path: libabigail
+ key: ${{ steps.get_ref_keys.outputs.libabigail }}
+ - name: Retrieve ABI reference cache
+ uses: actions/cache@v2
+ if: env.ABI_CHECKS == 'true'
+ with:
+ path: reference
+ key: ${{ steps.get_ref_keys.outputs.abi }}
- 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
+ - 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
+ libdw-dev
- name: Install i386 cross compiling packages
if: env.BUILD_32BIT == 'true'
run: sudo apt install -y gcc-multilib
diff --git a/.travis.yml b/.travis.yml
index d655e286c3..5aa7ad49f1 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -2,6 +2,9 @@
language: c
cache:
ccache: true
+ directories:
+ - libabigail
+ - reference
dist: bionic
@@ -18,6 +21,9 @@ _aarch64_packages: &aarch64_packages
- *required_packages
- [gcc-aarch64-linux-gnu, libc6-dev-arm64-cross, pkg-config-aarch64-linux-gnu]
+_libabigail_build_packages: &libabigail_build_packages
+ - [autoconf, automake, libtool, pkg-config, libxml2-dev, libdw-dev]
+
_build_32b_packages: &build_32b_packages
- *required_packages
- [gcc-multilib]
@@ -28,6 +34,11 @@ _doc_packages: &doc_packages
before_install: ./.ci/${TRAVIS_OS_NAME}-setup.sh
script: ./.ci/${TRAVIS_OS_NAME}-build.sh
+env:
+ global:
+ - LIBABIGAIL_VERSION=libabigail-1.8
+ - REF_GIT_TAG=v20.11
+
jobs:
include:
# x86_64 gcc jobs
@@ -45,6 +56,14 @@ jobs:
packages:
- *required_packages
- *doc_packages
+ - env: DEF_LIB="shared" ABI_CHECKS=true
+ arch: amd64
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - *required_packages
+ - *libabigail_build_packages
# x86_64 clang jobs
- env: DEF_LIB="static"
arch: amd64
@@ -104,6 +123,14 @@ jobs:
packages:
- *required_packages
- *doc_packages
+ - env: DEF_LIB="shared" ABI_CHECKS=true
+ arch: arm64
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - *required_packages
+ - *libabigail_build_packages
# aarch64 clang jobs
- env: DEF_LIB="static"
arch: arm64
--
2.23.0
^ permalink raw reply [relevance 20%]
* [dpdk-dev] [PATCH v2 1/2] ci: hook to GitHub Actions
2020-11-24 21:57 4% [dpdk-dev] [PATCH] ci: hook to Github Actions David Marchand
2020-11-25 13:44 0% ` Aaron Conole
@ 2020-12-04 17:36 4% ` David Marchand
2020-12-04 17:36 20% ` [dpdk-dev] [PATCH v2 2/2] ci: enable v21 ABI checks David Marchand
` (2 more replies)
1 sibling, 3 replies; 200+ results
From: David Marchand @ 2020-12-04 17:36 UTC (permalink / raw)
To: dev; +Cc: aconole, Michael Santana, Thomas Monjalon
With the recent changes in terms of free access to the Travis CI, let's
offer an alternative with GitHub Actions.
Running jobs on ARM is not supported unless using external runners, so
this commit only adds builds for x86_64 and cross compiling for i386 and
aarch64.
Differences with the Travis CI integration:
- Error logs are not dumped to the console when something goes wrong.
Instead, they are gathered in a "catch-all" step and attached as
artifacts.
- A cache entry is stored once and for all, but if no cache is found you
can inherit from the default branch cache. The cache is 5GB large, for
the whole git repository.
- The maximum retention of logs and artifacts is 3 months.
- /home/runner is world writable, so a workaround has been added for
starting dpdk processes.
- Ilya, working on OVS GHA support, noticed that jobs can run with
processors that don't have the same capabilities. For DPDK, this
impacts the ccache content since everything was built with
-march=native so far, and we will end up with binaries that can't run
in a later build. The problem has not been seen in Travis CI (?) but
it is safer to use a fixed "-Dmachine=default" in any case.
- Scheduling jobs is part of the configuration and takes the form of a
crontab. A build is scheduled every Monday at 0:00 (UTC) to provide a
default ccache for the week (useful for the ovsrobot).
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
Changelog since v1:
- changed shell variables value in CI scripts and Travis configuration
(s/=[^\$]*1/=\1true), this makes it easier for GHA,
- forced compilation as 'default' to avoid random unit tests issues in
GHA,
- scheduled a run per week on Monday at 0:00 UTC,
- updated the ccache key:
- no need to depend on the default-library parameter since this
parameter only impacts the linking of dpdk binaries,
- the week when the cache is generated is added so that jobs in
other branches can benefit from a recent cache (mimicking what we had
for the robot in Travis),
- realigned documentation generation with what is done in Travis:
generating the doc in all jobs was a waste of resources,
---
.ci/linux-build.sh | 17 +++---
.github/workflows/build.yml | 100 ++++++++++++++++++++++++++++++++++++
.travis.yml | 24 ++++-----
MAINTAINERS | 1 +
4 files changed, 123 insertions(+), 19 deletions(-)
create mode 100644 .github/workflows/build.yml
diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
index d079801d78..ee8d07f865 100755
--- a/.ci/linux-build.sh
+++ b/.ci/linux-build.sh
@@ -12,7 +12,9 @@ on_error() {
fi
done
}
-trap on_error EXIT
+# We capture the error logs as artifacts in Github Actions, no need to dump
+# them via a EXIT handler.
+[ -n "$GITHUB_WORKFLOW" ] || trap on_error EXIT
install_libabigail() {
version=$1
@@ -28,16 +30,16 @@ install_libabigail() {
rm ${version}.tar.gz
}
-if [ "$AARCH64" = "1" ]; then
+if [ "$AARCH64" = "true" ]; then
# convert the arch specifier
OPTS="$OPTS --cross-file config/arm/arm64_armv8_linux_gcc"
fi
-if [ "$BUILD_DOCS" = "1" ]; then
+if [ "$BUILD_DOCS" = "true" ]; then
OPTS="$OPTS -Denable_docs=true"
fi
-if [ "$BUILD_32BIT" = "1" ]; then
+if [ "$BUILD_32BIT" = "true" ]; then
OPTS="$OPTS -Dc_args=-m32 -Dc_link_args=-m32"
export PKG_CONFIG_LIBDIR="/usr/lib32/pkgconfig"
fi
@@ -48,16 +50,17 @@ else
OPTS="$OPTS -Dexamples=all"
fi
+OPTS="$OPTS -Dmachine=default"
OPTS="$OPTS --default-library=$DEF_LIB"
OPTS="$OPTS --buildtype=debugoptimized"
meson build --werror $OPTS
ninja -C build
-if [ "$AARCH64" != "1" ]; then
+if [ "$AARCH64" != "true" ]; then
devtools/test-null.sh
fi
-if [ "$ABI_CHECKS" = "1" ]; then
+if [ "$ABI_CHECKS" = "true" ]; then
LIBABIGAIL_VERSION=${LIBABIGAIL_VERSION:-libabigail-1.6}
if [ "$(cat libabigail/VERSION 2>/dev/null)" != "$LIBABIGAIL_VERSION" ]; then
@@ -95,6 +98,6 @@ if [ "$ABI_CHECKS" = "1" ]; then
devtools/check-abi.sh reference install ${ABI_CHECKS_WARN_ONLY:-}
fi
-if [ "$RUN_TESTS" = "1" ]; then
+if [ "$RUN_TESTS" = "true" ]; then
sudo meson test -C build --suite fast-tests -t 3
fi
diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
new file mode 100644
index 0000000000..bef6e52372
--- /dev/null
+++ b/.github/workflows/build.yml
@@ -0,0 +1,100 @@
+name: build
+
+on:
+ push:
+ schedule:
+ - cron: '0 0 * * 1'
+
+defaults:
+ run:
+ shell: bash --noprofile --norc -exo pipefail {0}
+
+jobs:
+ build:
+ name: ${{ join(matrix.config.*, '-') }}
+ runs-on: ${{ matrix.config.os }}
+ env:
+ AARCH64: ${{ matrix.config.cross == 'aarch64' }}
+ BUILD_32BIT: ${{ matrix.config.cross == 'i386' }}
+ BUILD_DOCS: ${{ contains(matrix.config.checks, 'doc') }}
+ CC: ccache ${{ matrix.config.compiler }}
+ DEF_LIB: ${{ matrix.config.library }}
+ RUN_TESTS: ${{ contains(matrix.config.checks, 'tests') }}
+
+ strategy:
+ fail-fast: false
+ matrix:
+ config:
+ - os: ubuntu-18.04
+ compiler: gcc
+ library: static
+ - os: ubuntu-18.04
+ compiler: gcc
+ library: shared
+ checks: doc+tests
+ - os: ubuntu-18.04
+ compiler: clang
+ library: static
+ - os: ubuntu-18.04
+ compiler: clang
+ library: shared
+ checks: doc+tests
+ - os: ubuntu-18.04
+ compiler: gcc
+ library: static
+ cross: i386
+ - os: ubuntu-18.04
+ compiler: gcc
+ library: static
+ cross: aarch64
+ - os: ubuntu-18.04
+ compiler: gcc
+ library: shared
+ cross: aarch64
+
+ steps:
+ - name: Checkout sources
+ uses: actions/checkout@v2
+ - name: Generate cache keys
+ id: get_ref_keys
+ run: |
+ echo -n '::set-output name=ccache::'
+ echo 'ccache-${{ matrix.config.os }}-${{ matrix.config.compiler }}-${{ matrix.config.cross }}-'$(date -u +%Y-w%W)
+ - 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
+ - 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
+ - name: Install i386 cross compiling packages
+ if: env.BUILD_32BIT == 'true'
+ run: sudo apt install -y gcc-multilib
+ - name: Install aarch64 cross compiling packages
+ if: env.AARCH64 == 'true'
+ run: sudo apt install -y gcc-aarch64-linux-gnu libc6-dev-arm64-cross
+ pkg-config-aarch64-linux-gnu
+ - name: Install doc generation packages
+ if: env.BUILD_DOCS == 'true'
+ run: sudo apt install -y doxygen graphviz python3-sphinx
+ python3-sphinx-rtd-theme
+ - name: Run setup
+ run: |
+ .ci/linux-setup.sh
+ # Workaround on $HOME permissions as EAL checks them for plugin loading
+ chmod o-w $HOME
+ - name: Build and test
+ run: .ci/linux-build.sh
+ - name: Upload logs on failure
+ if: failure()
+ uses: actions/upload-artifact@v2
+ with:
+ name: meson-logs-${{ join(matrix.config.*, '-') }}
+ path: |
+ build/meson-logs/testlog.txt
+ build/.ninja_log
+ build/meson-logs/meson-log.txt
diff --git a/.travis.yml b/.travis.yml
index 5e12db23b5..d655e286c3 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -34,10 +34,10 @@ jobs:
- env: DEF_LIB="static"
arch: amd64
compiler: gcc
- - env: DEF_LIB="shared" RUN_TESTS=1
+ - env: DEF_LIB="shared" RUN_TESTS=true
arch: amd64
compiler: gcc
- - env: DEF_LIB="shared" BUILD_DOCS=1
+ - env: DEF_LIB="shared" BUILD_DOCS=true
arch: amd64
compiler: gcc
addons:
@@ -49,10 +49,10 @@ jobs:
- env: DEF_LIB="static"
arch: amd64
compiler: clang
- - env: DEF_LIB="shared" RUN_TESTS=1
+ - env: DEF_LIB="shared" RUN_TESTS=true
arch: amd64
compiler: clang
- - env: DEF_LIB="shared" BUILD_DOCS=1
+ - env: DEF_LIB="shared" BUILD_DOCS=true
arch: amd64
compiler: clang
addons:
@@ -61,7 +61,7 @@ jobs:
- *required_packages
- *doc_packages
# x86_64 cross-compiling 32-bits jobs
- - env: DEF_LIB="static" BUILD_32BIT=1
+ - env: DEF_LIB="static" BUILD_32BIT=true
arch: amd64
compiler: gcc
addons:
@@ -69,14 +69,14 @@ jobs:
packages:
- *build_32b_packages
# x86_64 cross-compiling aarch64 jobs
- - env: DEF_LIB="static" AARCH64=1
+ - env: DEF_LIB="static" AARCH64=true
arch: amd64
compiler: gcc
addons:
apt:
packages:
- *aarch64_packages
- - env: DEF_LIB="shared" AARCH64=1
+ - env: DEF_LIB="shared" AARCH64=true
arch: amd64
compiler: gcc
addons:
@@ -87,16 +87,16 @@ jobs:
- env: DEF_LIB="static"
arch: arm64
compiler: gcc
- - env: DEF_LIB="shared" RUN_TESTS=1
+ - env: DEF_LIB="shared" RUN_TESTS=true
arch: arm64
compiler: gcc
- - env: DEF_LIB="shared" RUN_TESTS=1
+ - env: DEF_LIB="shared" RUN_TESTS=true
dist: focal
arch: arm64-graviton2
virt: vm
group: edge
compiler: gcc
- - env: DEF_LIB="shared" BUILD_DOCS=1
+ - env: DEF_LIB="shared" BUILD_DOCS=true
arch: arm64
compiler: gcc
addons:
@@ -108,10 +108,10 @@ jobs:
- env: DEF_LIB="static"
arch: arm64
compiler: clang
- - env: DEF_LIB="shared" RUN_TESTS=1
+ - env: DEF_LIB="shared" RUN_TESTS=true
arch: arm64
compiler: clang
- - env: DEF_LIB="shared" RUN_TESTS=1
+ - env: DEF_LIB="shared" RUN_TESTS=true
dist: focal
arch: arm64-graviton2
virt: vm
diff --git a/MAINTAINERS b/MAINTAINERS
index eafe9f8c46..f45c8c1b13 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -109,6 +109,7 @@ Public CI
M: Aaron Conole <aconole@redhat.com>
M: Michael Santana <maicolgabriel@hotmail.com>
F: .travis.yml
+F: .github/workflows/build.yml
F: .ci/
ABI Policy & Versioning
--
2.23.0
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH] version: 21.02-rc0
@ 2020-11-30 9:23 10% David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2020-11-30 9:23 UTC (permalink / raw)
To: dev; +Cc: thomas
Start a new release cycle with empty release notes.
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
Here we go again!
Patches have been archived in patchwork, all deferred patches are back in
the NEW state.
I'll send a separate patch to re-enable the ABI checks in the CI.
Please maintainers, rebase your trees.
The current dates for this release:
- Proposal deadline (RFC/v1 patches): December 20, 2020
- API freeze (-rc1): January 15, 2021
- Release: February 5, 2021
---
ABI_VERSION | 2 +-
VERSION | 2 +-
doc/guides/rel_notes/index.rst | 1 +
doc/guides/rel_notes/release_21_02.rst | 139 +++++++++++++++++++++++++
5 files changed, 143 insertions(+), 3 deletions(-)
create mode 100644 doc/guides/rel_notes/release_21_02.rst
diff --git a/ABI_VERSION b/ABI_VERSION
index 204da679a1..a9ac8dacb0 100644
--- a/ABI_VERSION
+++ b/ABI_VERSION
@@ -1 +1 @@
-21.0
+21.1
diff --git a/VERSION b/VERSION
index 4e3f998d00..30bbcd61a4 100644
--- a/VERSION
+++ b/VERSION
@@ -1 +1 @@
-20.11.0
+21.02.0-rc0
diff --git a/doc/guides/rel_notes/index.rst b/doc/guides/rel_notes/index.rst
index 31278d2a8a..05c9d837a4 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_02
release_20_11
release_20_08
release_20_05
diff --git a/doc/guides/rel_notes/release_21_02.rst b/doc/guides/rel_notes/release_21_02.rst
new file mode 100644
index 0000000000..39064afbe9
--- /dev/null
+++ b/doc/guides/rel_notes/release_21_02.rst
@@ -0,0 +1,139 @@
+.. SPDX-License-Identifier: BSD-3-Clause
+ Copyright 2020 The DPDK contributors
+
+.. include:: <isonum.txt>
+
+DPDK Release 21.02
+==================
+
+.. **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_02.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.23.0
^ permalink raw reply [relevance 10%]
* [dpdk-dev] [dpdk-announce] DPDK 20.11 released
@ 2020-11-27 21:37 4% Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2020-11-27 21:37 UTC (permalink / raw)
To: announce
A new major release is available:
https://fast.dpdk.org/rel/dpdk-20.11.tar.xz
Our Thanksgiving gift is the biggest DPDK release ever:
2195 commits from 214 authors
2665 files changed, 269546 insertions(+), 107426 deletions(-)
The branch 20.11 should be supported for at least two years,
making it recommended for system integration and deployment.
The maintainer of this new LTS is Kevin Traynor.
The new major ABI version is 21.
The next releases 21.02, 21.05 and 21.08 will be ABI compatible with 20.11.
Below are some new features, grouped by category.
* General
- mbuf dynamic area increased from 16 to 36 bytes
- ring zero copy
- SIMD bitwidth limit API
- Windows PCI netuio
- moved igb_uio to dpdk-kmods/linux
- removed Python 2 support
- removed Make support
* Networking
- FEC API
- Rx buffer split
- thread safety in flow API
- shared action in flow API
- flow sampling and mirroring
- tunnel offload API
- multi-port hairpin
- Solarflare EF100 architecture
- Wangxun txgbe driver
- vhost-vDPA backend in virtio-user
- removed vhost dequeue zero-copy
- removed legacy ethdev filtering
- SWX pipeline aligned with P4
* Baseband
- Intel ACC100 driver
* Cryptography
- raw datapath API
- Broadcom BCMFS symmetric crypto driver
* RegEx
- Marvell OCTEON TX2 regex driver
* Others
- Intel DLB/DLB2 drivers
- Intel DSA support in IOAT driver
More details in the release notes:
https://doc.dpdk.org/guides/rel_notes/release_20_11.html
There are 64 new contributors (including authors, reviewers and testers).
Welcome to Aidan Goddard, Amit Bernstein, Andrey Vesnovaty, Artur Rojek,
Benoît Ganne, Brandon Lo, Brian Johnson, Brian Poole, Christophe Grosse,
Churchill Khangar, Conor Walsh, David Liu, Dawid Lukwinski,
Diogo Behrens, Dongdong Liu, Franck Lenormand, Galazka Krzysztof,
Guoyang Zhou, Haggai Eran, Harshitha Ramamurthy, Ibtisam Tariq,
Ido Segev, Jay Jayatheerthan, Jiawen Wu, Jie Zhou, John Alexander,
Julien Massonneau, Jørgen Østergaard Sloth, Khoa To, Li Zhang,
Lingli Chen, Liu Tianjiao, Maciej Rabeda, Marcel Cornu, Mike Ximing Chen,
Muthurajan Jayakumar, Nan Chen, Nick Connolly, Norbert Ciosek,
Omkar Maslekar, Padraig Connolly, Piotr Bronowski, Przemyslaw Ciesielski,
Qin Sun, Radha Mohan Chintakuntla, Rani Sharoni, Raveendra Padasalagi,
Robin Zhang, RongQing Li, Shay Amir, Steve Yang, Steven Lariau, Tom Rix,
Venkata Suresh Kumar P, Vijay Kumar Srivastava, Vikas Gupta,
Vimal Chungath, Vipul Ashri, Wei Huang, Wei Ling, Weqaar Janjua, Yi Yang,
Yogesh Jangra and Zhenghua Zhou.
Below is the number of commits per employer (with authors count):
687 Intel (72)
439 Nvidia (34)
150 Huawei (11)
123 Broadcom (15)
116 Solarflare (1)
104 Red Hat (6)
96 OKTET Labs (3)
79 Marvell (16)
71 Arm (7)
59 Trustnet (1)
52 Microsoft (3)
51 NXP (12)
27 Semihalf (1)
27 Samsung (2)
19 6WIND (5)
17 Cisco (4)
13 BIFIT (1)
11 Emumba (2)
7 Xilinx (1)
7 Chelsio (2)
5 Inspur (1)
4 MayaData (1)
Based on Reviewed-by and Acked-by tags, the top non-PMD reviewers are:
128 Ferruh Yigit <ferruh.yigit@intel.com>
68 Bruce Richardson <bruce.richardson@intel.com>
63 Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
62 David Marchand <david.marchand@redhat.com>
53 Ruifeng Wang <ruifeng.wang@arm.com>
40 Konstantin Ananyev <konstantin.ananyev@intel.com>
38 Ajit Khaparde <ajit.khaparde@broadcom.com>
37 Ori Kam <orika@nvidia.com>
33 Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
The new features for 21.02 may be submitted during the next 3 weeks,
in order to be reviewed and integrated before mid-January.
DPDK 21.02 should be small in order to release in early February:
https://core.dpdk.org/roadmap#dates
Please share your roadmap.
Thanks everyone, enjoy a well deserved rest.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: add sample for ABI checks in contribution guide
@ 2020-11-27 14:37 4% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2020-11-27 14:37 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: John McNamara, Marko Kovacevic, dev
On Fri, Jul 3, 2020 at 7:15 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
>
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Ray Kinsella <mdr@ashroe.eu>
Sample sounds odd to me, but applied as is.
Thanks.
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: clarify abi reference version to use in patches
@ 2020-11-27 14:37 4% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2020-11-27 14:37 UTC (permalink / raw)
To: Ray Kinsella; +Cc: dev, Yigit, Ferruh, John McNamara, Marko Kovacevic
On Mon, Aug 10, 2020 at 11:24 AM Ray Kinsella <mdr@ashroe.eu> wrote:
>
> Clarify the ABI reference version (DPDK_ABI_REF_VERSION) tag, to use
> when testing builds with devtools/test_build[_meson].sh before
devtools/test-meson-builds.sh*
> submitting patches.
>
> Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
Reviewed-by: David Marchand <david.marchand@redhat.com>
Applied, thanks.
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] eal: fix errno on service cores init failure
2020-11-26 16:37 0% ` Olivier Matz
@ 2020-11-26 16:42 0% ` Van Haaren, Harry
0 siblings, 0 replies; 200+ results
From: Van Haaren, Harry @ 2020-11-26 16:42 UTC (permalink / raw)
To: Olivier Matz; +Cc: dev, Richardson, Bruce, Jerin Jacob, stable
> -----Original Message-----
> From: Olivier Matz <olivier.matz@6wind.com>
> Sent: Thursday, November 26, 2020 4:37 PM
> To: Van Haaren, Harry <harry.van.haaren@intel.com>
> Cc: dev@dpdk.org; Richardson, Bruce <bruce.richardson@intel.com>; Jerin Jacob
> <jerin.jacob@caviumnetworks.com>; stable@dpdk.org
> Subject: Re: [PATCH] eal: fix errno on service cores init failure
>
> Hi Harry,
>
> On Thu, Nov 26, 2020 at 02:46:30PM +0000, Van Haaren, Harry wrote:
> > > -----Original Message-----
> > > From: Olivier Matz <olivier.matz@6wind.com>
> > > Sent: Thursday, November 26, 2020 2:25 PM
> > > To: dev@dpdk.org
> > > Cc: Richardson, Bruce <bruce.richardson@intel.com>; Jerin Jacob
> > > <jerin.jacob@caviumnetworks.com>; Van Haaren, Harry
> > > <harry.van.haaren@intel.com>; stable@dpdk.org
> > > Subject: [PATCH] eal: fix errno on service cores init failure
> > >
> > > Currently, when rte_service_init() fails at initialization, we
> > > see the following message:
> > >
> > > Cannot init EAL: Exec format error
> > >
> > > This error code does describe the real issue. Instead, use the error
> > > code returned by the function.
> >
> > Should the above read as "does NOT describe" .. ?
> >
> > > Fixes: e39824500825 ("service: initialize with EAL")
> > > Cc: stable@dpdk.org
> > >
> > > Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
> >
> > Few comments below, assuming agree on those, add my Ack on v2?
> >
> > Checked, -ENOMEM and -EALREADY are returned today, which seem
> > better descriptive terms. Thanks for fixing,
> >
> > Acked-by: Harry van Haaren <harry.van.haaren@intel.com>
> >
> >
> > > ---
> > > lib/librte_eal/freebsd/eal.c | 4 ++--
> > > lib/librte_eal/linux/eal.c | 4 ++--
> > > 2 files changed, 4 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/lib/librte_eal/freebsd/eal.c b/lib/librte_eal/freebsd/eal.c
> > > index d6ea023750..51478358c7 100644
> > > --- a/lib/librte_eal/freebsd/eal.c
> > > +++ b/lib/librte_eal/freebsd/eal.c
> > > @@ -906,7 +906,7 @@ rte_eal_init(int argc, char **argv)
> > > ret = rte_service_init();
> > > if (ret) {
> > > rte_eal_init_alert("rte_service_init() failed");
> > > - rte_errno = ENOEXEC;
> > > + rte_errno = -ret;
> > > return -1;
> > > }
> >
> > Here we set rte_errno as -ret, as in rte_service_init() we return the negative,
> e.g. -ENOMEM.
> > Perhaps it is cleaner to to return ENOMEM from rte_service_init(), and avoid the
> duplicate negation?
> >
> > rte_service_init() is not exported publicly in the .map file, so is internal only, and
> hence not an ABI break.
>
> I think returning -errno is common in dpdk, so I'll keep it like
> this. Or it can eventually return -1 and set rte_errno.
OK, fine with as is too, minor thing, thanks!
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] eal: fix errno on service cores init failure
2020-11-26 14:46 3% ` Van Haaren, Harry
@ 2020-11-26 16:37 0% ` Olivier Matz
2020-11-26 16:42 0% ` Van Haaren, Harry
0 siblings, 1 reply; 200+ results
From: Olivier Matz @ 2020-11-26 16:37 UTC (permalink / raw)
To: Van Haaren, Harry; +Cc: dev, Richardson, Bruce, Jerin Jacob, stable
Hi Harry,
On Thu, Nov 26, 2020 at 02:46:30PM +0000, Van Haaren, Harry wrote:
> > -----Original Message-----
> > From: Olivier Matz <olivier.matz@6wind.com>
> > Sent: Thursday, November 26, 2020 2:25 PM
> > To: dev@dpdk.org
> > Cc: Richardson, Bruce <bruce.richardson@intel.com>; Jerin Jacob
> > <jerin.jacob@caviumnetworks.com>; Van Haaren, Harry
> > <harry.van.haaren@intel.com>; stable@dpdk.org
> > Subject: [PATCH] eal: fix errno on service cores init failure
> >
> > Currently, when rte_service_init() fails at initialization, we
> > see the following message:
> >
> > Cannot init EAL: Exec format error
> >
> > This error code does describe the real issue. Instead, use the error
> > code returned by the function.
>
> Should the above read as "does NOT describe" .. ?
>
> > Fixes: e39824500825 ("service: initialize with EAL")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
>
> Few comments below, assuming agree on those, add my Ack on v2?
>
> Checked, -ENOMEM and -EALREADY are returned today, which seem
> better descriptive terms. Thanks for fixing,
>
> Acked-by: Harry van Haaren <harry.van.haaren@intel.com>
>
>
> > ---
> > lib/librte_eal/freebsd/eal.c | 4 ++--
> > lib/librte_eal/linux/eal.c | 4 ++--
> > 2 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/lib/librte_eal/freebsd/eal.c b/lib/librte_eal/freebsd/eal.c
> > index d6ea023750..51478358c7 100644
> > --- a/lib/librte_eal/freebsd/eal.c
> > +++ b/lib/librte_eal/freebsd/eal.c
> > @@ -906,7 +906,7 @@ rte_eal_init(int argc, char **argv)
> > ret = rte_service_init();
> > if (ret) {
> > rte_eal_init_alert("rte_service_init() failed");
> > - rte_errno = ENOEXEC;
> > + rte_errno = -ret;
> > return -1;
> > }
>
> Here we set rte_errno as -ret, as in rte_service_init() we return the negative, e.g. -ENOMEM.
> Perhaps it is cleaner to to return ENOMEM from rte_service_init(), and avoid the duplicate negation?
>
> rte_service_init() is not exported publicly in the .map file, so is internal only, and hence not an ABI break.
I think returning -errno is common in dpdk, so I'll keep it like
this. Or it can eventually return -1 and set rte_errno.
>
>
> > @@ -922,7 +922,7 @@ rte_eal_init(int argc, char **argv)
> > */
> > ret = rte_service_start_with_defaults();
> > if (ret < 0 && ret != -ENOTSUP) {
> > - rte_errno = ENOEXEC;
> > + rte_errno = -ret;
> > return -1;
> > }
> >
> > diff --git a/lib/librte_eal/linux/eal.c b/lib/librte_eal/linux/eal.c
> > index a4161be630..32b48c3de9 100644
> > --- a/lib/librte_eal/linux/eal.c
> > +++ b/lib/librte_eal/linux/eal.c
> > @@ -1273,7 +1273,7 @@ rte_eal_init(int argc, char **argv)
> > ret = rte_service_init();
> > if (ret) {
> > rte_eal_init_alert("rte_service_init() failed");
> > - rte_errno = ENOEXEC;
> > + rte_errno = -ret;
> > return -1;
> > }
> >
> > @@ -1295,7 +1295,7 @@ rte_eal_init(int argc, char **argv)
> > */
> > ret = rte_service_start_with_defaults();
> > if (ret < 0 && ret != -ENOTSUP) {
> > - rte_errno = ENOEXEC;
> > + rte_errno = -ret;
> > return -1;
> > }
> >
> > --
> > 2.25.1
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] eal: fix errno on service cores init failure
@ 2020-11-26 14:46 3% ` Van Haaren, Harry
2020-11-26 16:37 0% ` Olivier Matz
0 siblings, 1 reply; 200+ results
From: Van Haaren, Harry @ 2020-11-26 14:46 UTC (permalink / raw)
To: Olivier Matz, dev; +Cc: Richardson, Bruce, Jerin Jacob, stable
> -----Original Message-----
> From: Olivier Matz <olivier.matz@6wind.com>
> Sent: Thursday, November 26, 2020 2:25 PM
> To: dev@dpdk.org
> Cc: Richardson, Bruce <bruce.richardson@intel.com>; Jerin Jacob
> <jerin.jacob@caviumnetworks.com>; Van Haaren, Harry
> <harry.van.haaren@intel.com>; stable@dpdk.org
> Subject: [PATCH] eal: fix errno on service cores init failure
>
> Currently, when rte_service_init() fails at initialization, we
> see the following message:
>
> Cannot init EAL: Exec format error
>
> This error code does describe the real issue. Instead, use the error
> code returned by the function.
Should the above read as "does NOT describe" .. ?
> Fixes: e39824500825 ("service: initialize with EAL")
> Cc: stable@dpdk.org
>
> Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
Few comments below, assuming agree on those, add my Ack on v2?
Checked, -ENOMEM and -EALREADY are returned today, which seem
better descriptive terms. Thanks for fixing,
Acked-by: Harry van Haaren <harry.van.haaren@intel.com>
> ---
> lib/librte_eal/freebsd/eal.c | 4 ++--
> lib/librte_eal/linux/eal.c | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/lib/librte_eal/freebsd/eal.c b/lib/librte_eal/freebsd/eal.c
> index d6ea023750..51478358c7 100644
> --- a/lib/librte_eal/freebsd/eal.c
> +++ b/lib/librte_eal/freebsd/eal.c
> @@ -906,7 +906,7 @@ rte_eal_init(int argc, char **argv)
> ret = rte_service_init();
> if (ret) {
> rte_eal_init_alert("rte_service_init() failed");
> - rte_errno = ENOEXEC;
> + rte_errno = -ret;
> return -1;
> }
Here we set rte_errno as -ret, as in rte_service_init() we return the negative, e.g. -ENOMEM.
Perhaps it is cleaner to to return ENOMEM from rte_service_init(), and avoid the duplicate negation?
rte_service_init() is not exported publicly in the .map file, so is internal only, and hence not an ABI break.
> @@ -922,7 +922,7 @@ rte_eal_init(int argc, char **argv)
> */
> ret = rte_service_start_with_defaults();
> if (ret < 0 && ret != -ENOTSUP) {
> - rte_errno = ENOEXEC;
> + rte_errno = -ret;
> return -1;
> }
>
> diff --git a/lib/librte_eal/linux/eal.c b/lib/librte_eal/linux/eal.c
> index a4161be630..32b48c3de9 100644
> --- a/lib/librte_eal/linux/eal.c
> +++ b/lib/librte_eal/linux/eal.c
> @@ -1273,7 +1273,7 @@ rte_eal_init(int argc, char **argv)
> ret = rte_service_init();
> if (ret) {
> rte_eal_init_alert("rte_service_init() failed");
> - rte_errno = ENOEXEC;
> + rte_errno = -ret;
> return -1;
> }
>
> @@ -1295,7 +1295,7 @@ rte_eal_init(int argc, char **argv)
> */
> ret = rte_service_start_with_defaults();
> if (ret < 0 && ret != -ENOTSUP) {
> - rte_errno = ENOEXEC;
> + rte_errno = -ret;
> return -1;
> }
>
> --
> 2.25.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] ci: hook to Github Actions
2020-11-24 21:57 4% [dpdk-dev] [PATCH] ci: hook to Github Actions David Marchand
@ 2020-11-25 13:44 0% ` Aaron Conole
2020-12-04 17:36 4% ` [dpdk-dev] [PATCH v2 1/2] ci: hook to GitHub Actions David Marchand
1 sibling, 1 reply; 200+ results
From: Aaron Conole @ 2020-11-25 13:44 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Michael Santana, Thomas Monjalon
David Marchand <david.marchand@redhat.com> writes:
> With the recent changes in terms of free access to the Travis CI, let's
> offer an alternative with Github Actions.
> Running jobs on ARM is not supported unless using external runners, so
> this commit only adds builds for x86_64 and cross compiling for i386 and
> aarch64.
>
> Differences with the Travis CI integration:
> - All jobs generate documentation.
> This is not that heavy and the default timeout on actions is never
> reached so no reason splitting this into multiple jobs.
> - Error logs are not dumped to the console when something goes wrong.
> Instead, they are gathered in a "catch-all" step and attached as
> artifacts.
> - A cache entry is stored once and for all, but if no cache is found you
> can inherit from the default branch cache. The cache is 5GB large, for
> the whole git repository.
> - The maximum retention of logs and artifacts is 3 months.
> - /home/runner is world writable, so a workaround has been added for
> starting dpdk processes.
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
Thanks for working on this. Sadly, I think we will have to abandon
Travis soon - given the new changes it is looking very awful. Robot
already is starved for job time.
Since we don't have ARM test runs, I guess we will have to rely on
something else for that coverage now, but I like that there is coverage
included at least to compile.
I will need to update the robot to pull information from github actions,
so for now it will need to be manually checked (but here's an example of
a run: https://github.com/ovsrobot/dpdk/actions/runs/382073265). What's
nice is the robot is already primed to run the jobs, so that's good.
Acked-by: Aaron Conole <aconole@redhat.com>
> .ci/linux-build.sh | 4 +-
> .github/workflows/build.yml | 98 +++++++++++++++++++++++++++++++++++++
> MAINTAINERS | 1 +
> 3 files changed, 102 insertions(+), 1 deletion(-)
> create mode 100644 .github/workflows/build.yml
>
> diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
> index d079801d78..a2a0e5bf42 100755
> --- a/.ci/linux-build.sh
> +++ b/.ci/linux-build.sh
> @@ -12,7 +12,9 @@ on_error() {
> fi
> done
> }
> -trap on_error EXIT
> +# We capture the error logs as artifacts in Github Actions, no need to dump
> +# them via a EXIT handler.
> +[ -n "$GITHUB_WORKFLOW" ] || trap on_error EXIT
>
> install_libabigail() {
> version=$1
> diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
> new file mode 100644
> index 0000000000..e0a8f1ed52
> --- /dev/null
> +++ b/.github/workflows/build.yml
> @@ -0,0 +1,98 @@
> +name: build
> +
> +on: push
> +
> +defaults:
> + run:
> + shell: bash --noprofile --norc -exo pipefail {0}
> +
> +jobs:
> + build:
> + name: ${{ join(matrix.config.*, '-') }}
> + runs-on: ${{ matrix.config.os }}
> + env:
> + PKGS: |
> + ccache libnuma-dev python3-setuptools python3-wheel python3-pip \
> + ninja-build libbsd-dev libpcap-dev libibverbs-dev libcrypto++-dev \
> + libfdt-dev libjansson-dev doxygen graphviz python3-sphinx \
> + python3-sphinx-rtd-theme
> + CC: ccache ${{ matrix.config.compiler }}
> + JOBNAME: ${{ join(matrix.config.*, '-') }}
> +
> + strategy:
> + fail-fast: false
> + matrix:
> + config:
> + - os: ubuntu-18.04
> + compiler: gcc
> + library: static
> + - os: ubuntu-18.04
> + compiler: gcc
> + library: shared
> + - os: ubuntu-18.04
> + compiler: clang
> + library: static
> + - os: ubuntu-18.04
> + compiler: clang
> + library: shared
> + - os: ubuntu-18.04
> + compiler: gcc
> + library: static
> + cross: i386
> + - os: ubuntu-18.04
> + compiler: gcc
> + library: static
> + cross: aarch64
> + - os: ubuntu-18.04
> + compiler: gcc
> + library: shared
> + cross: aarch64
> +
> + steps:
> + - uses: actions/checkout@v2
> + - uses: actions/cache@v2
> + with:
> + path: ~/.ccache
> + key: ${{ env.JOBNAME }}-${{ github.ref }}
> + restore-keys: |
> + ${{ env.JOBNAME }}-refs/heads/main
> + - name: Install packages
> + run: sudo apt install -y ${{ env.PKGS }}
> + - name: Install i386 cross compiling packages
> + if: matrix.config.cross == 'i386'
> + run: sudo apt install -y gcc-multilib
> + - name: Install aarch64 cross compiling packages
> + if: matrix.config.cross == 'aarch64'
> + run: |
> + sudo apt install -y gcc-aarch64-linux-gnu libc6-dev-arm64-cross \
> + pkg-config-aarch64-linux-gnu
> + - name: Prepare environment
> + run: |
> + .ci/linux-setup.sh
> + # Workaround on $HOME permissions as EAL checks them for plugin loading
> + chmod o-w $HOME
> + - name: Build and test
> + run: |
> + export DEF_LIB=${{ matrix.config.library }}
> + export BUILD_DOCS=1
> + case '${{ matrix.config.cross }}' in
> + 'i386')
> + export BUILD_32BIT=1
> + ;;
> + 'aarch64')
> + export AARCH64=1
> + ;;
> + '')
> + export RUN_TESTS=1
> + ;;
> + esac
> + .ci/linux-build.sh
> + - name: Upload logs on failure
> + if: failure()
> + uses: actions/upload-artifact@v2
> + with:
> + name: meson-logs-${{ env.JOBNAME }}
> + path: |
> + build/meson-logs/testlog.txt
> + build/.ninja_log
> + build/meson-logs/meson-log.txt
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 214515060a..95b61085b7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -109,6 +109,7 @@ Public CI
> M: Aaron Conole <aconole@redhat.com>
> M: Michael Santana <maicolgabriel@hotmail.com>
> F: .travis.yml
> +F: .github/workflows/build.yml
> F: .ci/
>
> ABI Policy & Versioning
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH] ci: hook to Github Actions
@ 2020-11-24 21:57 4% David Marchand
2020-11-25 13:44 0% ` Aaron Conole
2020-12-04 17:36 4% ` [dpdk-dev] [PATCH v2 1/2] ci: hook to GitHub Actions David Marchand
0 siblings, 2 replies; 200+ results
From: David Marchand @ 2020-11-24 21:57 UTC (permalink / raw)
To: dev; +Cc: Aaron Conole, Michael Santana, Thomas Monjalon
With the recent changes in terms of free access to the Travis CI, let's
offer an alternative with Github Actions.
Running jobs on ARM is not supported unless using external runners, so
this commit only adds builds for x86_64 and cross compiling for i386 and
aarch64.
Differences with the Travis CI integration:
- All jobs generate documentation.
This is not that heavy and the default timeout on actions is never
reached so no reason splitting this into multiple jobs.
- Error logs are not dumped to the console when something goes wrong.
Instead, they are gathered in a "catch-all" step and attached as
artifacts.
- A cache entry is stored once and for all, but if no cache is found you
can inherit from the default branch cache. The cache is 5GB large, for
the whole git repository.
- The maximum retention of logs and artifacts is 3 months.
- /home/runner is world writable, so a workaround has been added for
starting dpdk processes.
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
.ci/linux-build.sh | 4 +-
.github/workflows/build.yml | 98 +++++++++++++++++++++++++++++++++++++
MAINTAINERS | 1 +
3 files changed, 102 insertions(+), 1 deletion(-)
create mode 100644 .github/workflows/build.yml
diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
index d079801d78..a2a0e5bf42 100755
--- a/.ci/linux-build.sh
+++ b/.ci/linux-build.sh
@@ -12,7 +12,9 @@ on_error() {
fi
done
}
-trap on_error EXIT
+# We capture the error logs as artifacts in Github Actions, no need to dump
+# them via a EXIT handler.
+[ -n "$GITHUB_WORKFLOW" ] || trap on_error EXIT
install_libabigail() {
version=$1
diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
new file mode 100644
index 0000000000..e0a8f1ed52
--- /dev/null
+++ b/.github/workflows/build.yml
@@ -0,0 +1,98 @@
+name: build
+
+on: push
+
+defaults:
+ run:
+ shell: bash --noprofile --norc -exo pipefail {0}
+
+jobs:
+ build:
+ name: ${{ join(matrix.config.*, '-') }}
+ runs-on: ${{ matrix.config.os }}
+ env:
+ PKGS: |
+ ccache libnuma-dev python3-setuptools python3-wheel python3-pip \
+ ninja-build libbsd-dev libpcap-dev libibverbs-dev libcrypto++-dev \
+ libfdt-dev libjansson-dev doxygen graphviz python3-sphinx \
+ python3-sphinx-rtd-theme
+ CC: ccache ${{ matrix.config.compiler }}
+ JOBNAME: ${{ join(matrix.config.*, '-') }}
+
+ strategy:
+ fail-fast: false
+ matrix:
+ config:
+ - os: ubuntu-18.04
+ compiler: gcc
+ library: static
+ - os: ubuntu-18.04
+ compiler: gcc
+ library: shared
+ - os: ubuntu-18.04
+ compiler: clang
+ library: static
+ - os: ubuntu-18.04
+ compiler: clang
+ library: shared
+ - os: ubuntu-18.04
+ compiler: gcc
+ library: static
+ cross: i386
+ - os: ubuntu-18.04
+ compiler: gcc
+ library: static
+ cross: aarch64
+ - os: ubuntu-18.04
+ compiler: gcc
+ library: shared
+ cross: aarch64
+
+ steps:
+ - uses: actions/checkout@v2
+ - uses: actions/cache@v2
+ with:
+ path: ~/.ccache
+ key: ${{ env.JOBNAME }}-${{ github.ref }}
+ restore-keys: |
+ ${{ env.JOBNAME }}-refs/heads/main
+ - name: Install packages
+ run: sudo apt install -y ${{ env.PKGS }}
+ - name: Install i386 cross compiling packages
+ if: matrix.config.cross == 'i386'
+ run: sudo apt install -y gcc-multilib
+ - name: Install aarch64 cross compiling packages
+ if: matrix.config.cross == 'aarch64'
+ run: |
+ sudo apt install -y gcc-aarch64-linux-gnu libc6-dev-arm64-cross \
+ pkg-config-aarch64-linux-gnu
+ - name: Prepare environment
+ run: |
+ .ci/linux-setup.sh
+ # Workaround on $HOME permissions as EAL checks them for plugin loading
+ chmod o-w $HOME
+ - name: Build and test
+ run: |
+ export DEF_LIB=${{ matrix.config.library }}
+ export BUILD_DOCS=1
+ case '${{ matrix.config.cross }}' in
+ 'i386')
+ export BUILD_32BIT=1
+ ;;
+ 'aarch64')
+ export AARCH64=1
+ ;;
+ '')
+ export RUN_TESTS=1
+ ;;
+ esac
+ .ci/linux-build.sh
+ - name: Upload logs on failure
+ if: failure()
+ uses: actions/upload-artifact@v2
+ with:
+ name: meson-logs-${{ env.JOBNAME }}
+ path: |
+ build/meson-logs/testlog.txt
+ build/.ninja_log
+ build/meson-logs/meson-log.txt
diff --git a/MAINTAINERS b/MAINTAINERS
index 214515060a..95b61085b7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -109,6 +109,7 @@ Public CI
M: Aaron Conole <aconole@redhat.com>
M: Michael Santana <maicolgabriel@hotmail.com>
F: .travis.yml
+F: .github/workflows/build.yml
F: .ci/
ABI Policy & Versioning
--
2.23.0
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v1] doc: update release notes for 20.11
@ 2020-11-24 20:40 7% John McNamara
0 siblings, 0 replies; 200+ results
From: John McNamara @ 2020-11-24 20:40 UTC (permalink / raw)
To: dev; +Cc: thomas, John McNamara
Fix grammar, spelling and formatting of DPDK 20.11 release notes.
Signed-off-by: John McNamara <john.mcnamara@intel.com>
---
doc/guides/rel_notes/release_20_11.rst | 178 +++++++++++++------------
1 file changed, 94 insertions(+), 84 deletions(-)
diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
index ea70289af..2ce47614c 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -59,7 +59,7 @@ New Features
Added ``rte_write32_wc`` and ``rte_write32_wc_relaxed`` APIs
that enable write combining stores (depending on architecture).
- The functions are provided as a generic stubs and
+ The functions are provided as a generic stub and
x86 specific implementation.
* **Added prefetch with intention to write APIs.**
@@ -108,45 +108,50 @@ New Features
* **Added the FEC API, for a generic FEC query and config.**
Added the FEC API which provides functions for query FEC capabilities and
- current FEC mode from device. Also, API for configuring FEC mode is also provided.
+ current FEC mode from device. An API for configuring FEC mode is also provided.
* **Added thread safety to rte_flow functions.**
- Added ``RTE_ETH_DEV_FLOW_OPS_THREAD_SAFE`` device flag to indicate
- whether PMD supports thread safe operations. If PMD doesn't set the flag,
- rte_flow API level functions will protect the flow operations with mutex.
+ Added the ``RTE_ETH_DEV_FLOW_OPS_THREAD_SAFE`` device flag to indicate
+ whether a PMD supports thread safe operations. If the PMD doesn't set the flag,
+ the rte_flow API level functions will protect the flow operations with a mutex.
* **Added flow-based traffic sampling support.**
- Added new action: ``RTE_FLOW_ACTION_TYPE_SAMPLE`` to duplicate the matching
- packets with specified ratio, and apply with own set of actions with a fate
- action. When the ratio is set to 1 then the packets will be 100% mirrored.
+ Added a new action ``RTE_FLOW_ACTION_TYPE_SAMPLE`` that will sample the
+ incoming traffic and send a duplicated traffic with the specified ratio to
+ the application, while the original packet will continue to the target
+ destination.
+
+ The packets sampling is '1/ratio'. A ratio value set to 1 means that the
+ packets will be completely mirrored. The sample packet can be assigned with
+ a different set of actions than the original packet.
* **Added support of shared action in flow API.**
- Added shared action support to utilize single flow action in multiple flow
- rules. An update of shared action configuration alters the behavior of all
+ Added shared action support to use single flow actions in multiple flow
+ rules. An update to the shared action configuration alters the behavior of all
flow rules using it.
- * Added new action: ``RTE_FLOW_ACTION_TYPE_SHARED`` to use shared action
- as flow action.
- * Added new flow APIs to create/update/destroy/query shared action.
+ * Added a new action: ``RTE_FLOW_ACTION_TYPE_SHARED`` to use shared action
+ as a flow action.
+ * Added new flow APIs to create/update/destroy/query shared actions.
-* **Flow rules allowed to use private PMD items / actions.**
+* **Added support to flow rules to allow private PMD items/actions.**
- * Flow rule verification was updated to accept private PMD
+ * Flow rule verification has been updated to accept private PMD
items and actions.
-* **Added generic API to offload tunneled traffic and restore missed packet.**
+* **Added a generic API to offload tunneled traffic and restore missed packets.**
- * Added a new hardware independent helper to flow API that
+ * Added a new hardware independent helper to the flow API that
offloads tunneled traffic and restores missed packets.
* **Updated the ethdev library to support hairpin between two ports.**
- New APIs are introduced to support binding / unbinding 2 ports hairpin.
- Hairpin Tx part flow rules can be inserted explicitly.
- New API is added to get the hairpin peer ports list.
+ New APIs have been introduced to support binding / unbinding of 2 ports in a
+ hairpin configuration. The hairpin Tx part flow rules can be inserted
+ explicitly. A new API has been added to get the hairpin peer ports list.
* **Updated the Amazon ena driver.**
@@ -175,12 +180,12 @@ New Features
* **Added hns3 FEC PMD, for supporting query and config FEC mode.**
- Added the FEC PMD which provides functions for query FEC capabilities and
- current FEC mode from device. Also, PMD for configuring FEC mode is also provided.
+ Added the FEC PMD which provides functions for querying FEC capabilities and
+ current FEC mode from a device. A PMD for configuring FEC mode is also provided.
-* **Updated Intel iavf driver.**
+* **Updated the Intel iavf driver.**
- Updated iavf PMD with new features and improvements, including:
+ Updated the iavf PMD with new features and improvements, including:
* Added support for flexible descriptor metadata extraction.
* Added support for outer IP hash of GTPC and GTPU.
@@ -189,12 +194,12 @@ New Features
* **Updated Intel ice driver.**
- * Used write combining stores.
- * Added ACL filter support for Intel DCF.
+ * Added support for write combining stores.
+ * Added ACL filter support for the Intel DCF.
-* **Updated Mellanox mlx5 driver.**
+* **Updated the Mellanox mlx5 driver.**
- Updated Mellanox mlx5 driver with new features and improvements, including:
+ Updated the Mellanox mlx5 driver with new features and improvements, including:
* Added vectorized Multi-Packet Rx Queue burst.
* Added support for 2 new miniCQE formats: Flow Tag and L3/L4 header.
@@ -204,9 +209,9 @@ New Features
* Added support for the new VLAN fields ``has_vlan`` in the Ethernet item
and ``has_more_vlan`` in the VLAN item.
* Updated the supported timeout for Age action to the maximal value supported
- by rte_flow API.
- * Added support of Age action query.
- * Added support of multi-ports hairpin.
+ by the rte_flow API.
+ * Added support for Age action query.
+ * Added support for multi-ports hairpin.
* Allow unknown link speed.
Updated Mellanox mlx5 vDPA driver:
@@ -221,7 +226,7 @@ New Features
* Added Alveo SN1000 SmartNICs (EF100 architecture) support including
flow API transfer rules for switch HW offload
* Added ARMv8 support
- * Claimed flow API native thread safety
+ * Added flow API native thread safety
* **Added Wangxun txgbe PMD.**
@@ -231,9 +236,9 @@ New Features
* **Updated Virtio driver.**
- * Added support for Vhost-vDPA backend to Virtio-user PMD.
+ * Added support for Vhost-vDPA backend to the Virtio-user PMD.
* Changed default link speed to unknown.
- * Added support for 200G link speed.
+ * Added support for the 200G link speed.
* **Updated Intel i40e driver.**
@@ -249,40 +254,40 @@ New Features
* **Updated Memif PMD.**
- * Added support for abstract socket address.
+ * Added support for abstract socket addresses.
* Changed default socket address type to abstract.
* **Added Ice Lake (Gen4) support for Intel NTB.**
- Added NTB device support (4th generation) for Intel Ice Lake platform.
+ Added NTB device support (4th generation) for the Intel Ice Lake platform.
* **Added UDP/IPv4 GRO support for VxLAN and non-VxLAN packets.**
For VxLAN packets, added inner UDP/IPv4 support.
For non-VxLAN packets, added UDP/IPv4 support.
-* **Extended flow-perf application.**
+* **Extended the flow-perf application.**
- * Started supporting user order instead of bit mask:
+ * Added support for user order instead of bit mask.
Now the user can create any structure of rte_flow
- using flow performance application with any order,
- moreover the app also now starts to support inner
+ using the flow performance application with any order.
+ Moreover the app also now starts to support inner
items matching as well.
* Added header modify actions.
* Added flag action.
* Added raw encap/decap actions.
* Added VXLAN encap/decap actions.
- * Added ICMP(code/type/identifier/sequence number) and ICMP6(code/type) matching items.
+ * Added ICMP (code/type/identifier/sequence number) and ICMP6 (code/type) matching items.
* Added option to set port mask for insertion/deletion:
``--portmask=N``
- where N represents the hexadecimal bitmask of ports used.
+ where N represents the hexadecimal bitmask of the ports used.
* **Added raw data-path APIs for cryptodev library.**
- Cryptodev is added with raw data-path APIs to accelerate external
- libraries or applications which need to avail fast cryptodev
- enqueue/dequeue operations but does not necessarily depends on
- mbufs and cryptodev operation mempools.
+ Added raw data-path APIs to Cryptodev to help accelerate external libraries
+ or applications which need to avail of fast cryptodev enqueue/dequeue
+ operations but which do not necessarily need to depend on mbufs and
+ cryptodev operation mempools.
* **Updated the aesni_mb crypto PMD.**
@@ -319,7 +324,7 @@ New Features
* Updated the OCTEON TX2 crypto PMD lookaside protocol offload for IPsec with
IPv6 support.
-* **Updated QAT crypto PMD.**
+* **Updated the QAT crypto PMD.**
* Added Raw Data-path APIs support.
@@ -332,18 +337,18 @@ New Features
* **Updated rte_security library to support SDAP.**
``rte_security_pdcp_xform`` in ``rte_security`` lib is updated to enable
- 5G NR processing of SDAP header in PMDs.
+ 5G NR processing of SDAP headers in PMDs.
* **Added Marvell OCTEON TX2 regex PMD.**
- Added a new PMD driver for hardware regex offload block for OCTEON TX2 SoC.
+ Added a new PMD driver for the hardware regex offload block for OCTEON TX2 SoC.
See the :doc:`../regexdevs/octeontx2` for more details.
* **Updated Software Eventdev driver.**
Added performance tuning arguments to allow tuning the scheduler for
- better throughtput in high core count use cases.
+ better throughput in high core count use cases.
* **Added a new driver for the Intel Dynamic Load Balancer v1.0 device.**
@@ -355,12 +360,14 @@ New Features
Added the new ``dlb2`` eventdev driver for the Intel DLB V2.0 device. See the
:doc:`../eventdevs/dlb2` eventdev guide for more details on this new driver.
-* **Updated ioat rawdev driver**
+* **Updated ioat rawdev driver.**
The ioat rawdev driver has been updated and enhanced. Changes include:
- * Added support for Intel\ |reg| Data Streaming Accelerator hardware.
- For more information, see https://01.org/blogs/2019/introducing-intel-data-streaming-accelerator
+ * Added support for Intel\ |reg| Data Streaming Accelerator hardware. For
+ more information, see `Introducing the Intel Data Streaming Accelerator
+ (Intel DSA)
+ <https://01.org/blogs/2019/introducing-intel-data-streaming-accelerator>`_.
* Added support for the fill operation via the API ``rte_ioat_enqueue_fill()``,
where the hardware fills an area of memory with a repeating pattern.
* Added a per-device configuration flag to disable management
@@ -369,7 +376,7 @@ New Features
and renamed the ``rte_ioat_completed_copies()`` API to ``rte_ioat_completed_ops()``
to better reflect the APIs' purposes, and remove the implication that
they are limited to copy operations only.
- [Note: The old API is still provided but marked as deprecated in the code]
+ Note: The old API is still provided but marked as deprecated in the code.
* Added a new API ``rte_ioat_fence()`` to add a fence between operations.
This API replaces the ``fence`` flag parameter in the ``rte_ioat_enqueue_copies()`` function,
and is clearer as there is no ambiguity as to whether the flag should be
@@ -377,11 +384,12 @@ New Features
* **Updated the pipeline library for alignment with the P4 language.**
- Added new Software Switch (SWX) pipeline type that provides more
- flexibility through API and feature alignment with the P4 language.
+ Added a new Software Switch (SWX) pipeline type that provides more
+ flexibility through APIs and feature alignment with the P4 language.
+ Some enhancements are:
* The packet headers, meta-data, actions, tables and pipelines are
- dynamically defined instead of selected from pre-defined set.
+ dynamically defined instead of selected from a pre-defined set.
* The actions and the pipeline are defined with instructions.
* Extern objects and functions can be plugged into the pipeline.
* Transaction-oriented table updates.
@@ -401,9 +409,9 @@ New Features
* **Added support to update subport bandwidth dynamically.**
* Added new API ``rte_sched_port_subport_profile_add`` to add new
- subport bandwidth profile to subport porfile table at runtime.
+ subport bandwidth profiles to the subport profile table at runtime.
- * Added support to update subport rate dynamically.
+ * Added support to update the subport rate dynamically.
* **Updated FIPS validation sample application.**
@@ -420,8 +428,8 @@ New Features
* **Updated vhost sample application.**
- Added vhost asynchronous APIs support, which demonstrated how the application
- leverage IOAT DMA channel with vhost asynchronous APIs.
+ Added vhost asynchronous APIs support, which demonstrates how the application
+ can leverage IOAT DMA channels with vhost asynchronous APIs.
See the :doc:`../sample_app_ug/vhost` for more details.
@@ -437,16 +445,18 @@ Removed Items
Also, make sure to start the actual text at the margin.
=======================================================
-* build: Support for the Make build system was removed for compiling DPDK,
+* build: Support for the Make build system has been removed from DPDK.
Meson is now the primary build system.
Sample applications can still be built with Make standalone, using pkg-config.
* vhost: Dequeue zero-copy support has been removed.
* kernel: The module ``igb_uio`` has been moved to the git repository
- ``dpdk-kmods`` in a new directory ``linux/igb_uio``.
+ `dpdk-kmods <https://git.dpdk.org/dpdk-kmods/>`_ in a new directory
+ ``linux/igb_uio``.
-* Removed Python 2 support since it was EOL'd in January 2020.
+* Removed Python 2 support since it was sunsetted in January 2020. See
+ `Sunsetting Python 2 <https://www.python.org/doc/sunset-python-2/>`_
* Removed TEP termination sample application.
@@ -466,11 +476,11 @@ API Changes
Also, make sure to start the actual text at the margin.
=======================================================
-* build macros: The macros defining ``RTE_MACHINE_CPUFLAG_*`` are removed.
- The information provided by these macros is available through standard
+* build macros: The macros defining ``RTE_MACHINE_CPUFLAG_*`` have been removed.
+ The information provided by these macros is now available through standard
compiler macros.
-* eal: Replaced the function ``rte_get_master_lcore()`` to
+* eal: Replaced the function ``rte_get_master_lcore()`` with
``rte_get_main_lcore()``. The old function is deprecated.
The iterator for worker lcores is also changed:
@@ -478,7 +488,7 @@ API Changes
``RTE_LCORE_FOREACH_WORKER``.
* eal: The definitions related to including and excluding devices
- has been changed from blacklist/whitelist to block/allow list.
+ have been changed from blacklist/whitelist to block/allow list.
There are compatibility macros and command line mapping to accept
the old values but applications and scripts are strongly encouraged
to migrate to the new names.
@@ -494,11 +504,11 @@ API Changes
* mem: Removed the unioned field ``phys_addr`` from
the structures ``rte_memseg`` and ``rte_memzone``.
- The field ``iova`` is remaining from the old unions.
+ The field ``iova`` remains from the old unions.
* mempool: Removed the unioned fields ``phys_addr`` and ``physaddr`` from
the structures ``rte_mempool_memhdr`` and ``rte_mempool_objhdr``.
- The field ``iova`` is remaining from the old unions.
+ The field ``iova`` remains from the old unions.
The flag name ``MEMPOOL_F_NO_PHYS_CONTIG`` is removed,
while the aliased flag ``MEMPOOL_F_NO_IOVA_CONTIG`` is kept.
@@ -508,11 +518,11 @@ API Changes
having ``iova`` in their names instead of ``dma_addr`` or ``mtophys``.
* mbuf: Removed the unioned field ``buf_physaddr`` from ``rte_mbuf``.
- The field ``buf_iova`` is remaining from the old union.
+ The field ``buf_iova`` remains from the old union.
* mbuf: Removed the unioned field ``refcnt_atomic`` from
the structures ``rte_mbuf`` and ``rte_mbuf_ext_shared_info``.
- The field ``refcnt`` is remaining from the old unions.
+ The field ``refcnt`` remains from the old unions.
* mbuf: Removed the unioned fields ``userdata`` and ``udata64``
from the structure ``rte_mbuf``. It is replaced with dynamic fields.
@@ -558,7 +568,7 @@ API Changes
* ethdev: Modified field type of ``base`` and ``nb_queue`` in struct
``rte_eth_dcb_tc_queue_mapping`` from ``uint8_t`` to ``uint16_t``.
- As the data of ``uint8_t`` will be truncated when queue number under
+ As the data of ``uint8_t`` will be truncated when queue number in
a TC is greater than 256.
* ethdev: Removed the legacy filter API, including
@@ -574,7 +584,7 @@ API Changes
instead of ``rte_vhost_driver_start`` by crypto applications.
* cryptodev: The structure ``rte_crypto_sym_vec`` is updated to support both
- cpu_crypto synchrounous operation and asynchronous raw data-path APIs.
+ cpu_crypto synchronous operations and asynchronous raw data-path APIs.
* cryptodev: ``RTE_CRYPTO_AEAD_LIST_END`` from ``enum rte_crypto_aead_algorithm``,
``RTE_CRYPTO_CIPHER_LIST_END`` from ``enum rte_crypto_cipher_algorithm`` and
@@ -592,12 +602,12 @@ API Changes
``RTE_CRYPTODEV_SCHEDULER_MAX_NB_SLAVES`` to
``RTE_CRYPTODEV_SCHEDULER_MAX_NB_WORKERS``.
-* security: ``hfn_ovrd`` field in ``rte_security_pdcp_xform`` is changed from
+* security: The ``hfn_ovrd`` field in ``rte_security_pdcp_xform`` is changed from
``uint32_t`` to ``uint8_t`` so that a new field ``sdap_enabled`` can be added
to support SDAP.
* security: The API ``rte_security_session_create`` is updated to take two
- mempool objects one for session and other for session private data.
+ mempool objects: one for session and other for session private data.
So the application need to create two mempools and get the size of session
private data using API ``rte_security_session_get_size`` for private session
mempool.
@@ -645,10 +655,10 @@ API Changes
* ``pkt`` is not freed, no matter whether it is GSOed, leaving to the caller.
* acl: ``RTE_ACL_CLASSIFY_NUM`` enum value has been removed.
- This enum value was not used inside DPDK, while it prevented to add new
+ This enum value was not used inside DPDK, while it prevented the addition of new
classify algorithms without causing an ABI breakage.
-* sched: Added ``subport_profile_id`` as argument
+* sched: Added ``subport_profile_id`` as an argument
to function ``rte_sched_subport_config``.
* sched: Removed ``tb_rate``, ``tc_rate``, ``tc_period`` and ``tb_size``
@@ -670,11 +680,11 @@ ABI Changes
Also, make sure to start the actual text at the margin.
=======================================================
-* eal: Removed the not implemented function ``rte_dump_registers()``.
+* eal: Removed the unimplemented function ``rte_dump_registers()``.
* ``ethdev`` changes
- * Following device operation function pointers moved
+ * The following device operation function pointers moved
from ``struct eth_dev_ops`` to ``struct rte_eth_dev``:
* ``eth_rx_queue_count_t rx_queue_count;``
@@ -682,8 +692,8 @@ ABI Changes
* ``eth_rx_descriptor_status_t rx_descriptor_status;``
* ``eth_tx_descriptor_status_t tx_descriptor_status;``
- * ``struct eth_dev_ops`` is no more accessible by applications,
- which was already internal data structure.
+ * ``struct eth_dev_ops`` is no longer accessible by applications,
+ which was already an internal data structure.
* ``ethdev`` internal functions are marked with ``__rte_internal`` tag.
@@ -704,11 +714,11 @@ ABI Changes
* Added new field ``has_vlan`` to structure ``rte_flow_item_eth``,
indicating that packet header contains at least one VLAN.
- * Added new field ``has_more_vlan`` to structure
+ * Added new field ``has_more_vlan`` to the structure
``rte_flow_item_vlan``, indicating that packet header contains
at least one more VLAN, after this VLAN.
-* eventdev: Following structures are modified to support DLB/DLB2 PMDs
+* eventdev: The following structures are modified to support DLB/DLB2 PMDs
and future extensions:
* ``rte_event_dev_info``
--
2.25.1
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [PATCH] doc: announce flow API matching pattern struct changes
2020-11-24 13:00 4% ` Andrew Rybchenko
@ 2020-11-24 13:01 0% ` Andrew Rybchenko
0 siblings, 0 replies; 200+ results
From: Andrew Rybchenko @ 2020-11-24 13:01 UTC (permalink / raw)
To: Ferruh Yigit, Ori Kam, Ray Kinsella, Neil Horman
Cc: dev, NBU-Contact-Thomas Monjalon
On 11/24/20 4:00 PM, Andrew Rybchenko wrote:
> On 11/24/20 3:56 PM, Ferruh Yigit wrote:
>> On 11/24/2020 11:43 AM, Ori Kam wrote:
>>> Hi
>>>
>>>> -----Original Message-----
>>>> From: Ferruh Yigit <ferruh.yigit@intel.com>
>>>> Sent: Monday, November 23, 2020 5:51 PM
>>>> Subject: Re: [PATCH] doc: announce flow API matching pattern struct
>>>> changes
>>>>
>>>> On 11/23/2020 2:25 PM, Andrew Rybchenko wrote:
>>>>> On 11/23/20 5:17 PM, Ferruh Yigit wrote:
>>>>>> On 11/23/2020 1:50 PM, Andrew Rybchenko wrote:
>>>>>>> On 11/23/20 4:40 PM, Ferruh Yigit wrote:
>>>>>>>> Proposing to replace protocol header fields in the
>>>>>>>> ``rte_flow_item_*``
>>>>>>>> structures with the protocol structs, like:
>>>>>>>>
>>>>>>>> Current ``struct rte_flow_item_eth``,
>>>>>>>>
>>>>>>>> struct rte_flow_item_eth {
>>>>>>>> struct rte_ether_addr dst;
>>>>>>>> struct rte_ether_addr src;
>>>>>>>> rte_be16_t type;
>>>>>>>> uint32_t has_vlan:1;
>>>>>>>> uint32_t reserved:31;
>>>>>>>> }
>>>>>>>>
>>>>>>>> will become
>>>>>>>>
>>>>>>>> struct rte_flow_item_eth {
>>>>>>>> struct rte_ether_hdr hdr;
>>>>>>>> uint32_t has_vlan:1;
>>>>>>>> uint32_t reserved:31;
>>>>>>>> }
>>>>>>>>
>>>>>>>> This is both for documenting the intention and to be sure
>>>>>>>> ``rte_flow_item_*`` always starts with complete protocol header.
>>>>>>>>
>>>>>>>> Already many ``rte_flow_item_*`` structs implemented to have
>>>>>>>> protocol
>>>>>>>> struct, target is convert all to this usage.
>>>>>>>>
>>>>>>>> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
>>>>>>>
>>>>>>> Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>>>>>>>
>>>>>>> a minor note below
>>>>>>>
>>>>>>>> ---
>>>>>>>> Cc: Thomas Monjalon <thomas@monjalon.net>
>>>>>>>> Cc: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>>>>>>>> Cc: Ori Kam <orika@nvidia.com>
>>>>>>>> ---
>>>>>>>> doc/guides/rel_notes/deprecation.rst | 7 +++++++
>>>>>>>> 1 file changed, 7 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/doc/guides/rel_notes/deprecation.rst
>>>>>>>> b/doc/guides/rel_notes/deprecation.rst
>>>>>>>> index 96986fabd598..a2fa0c196472 100644
>>>>>>>> --- a/doc/guides/rel_notes/deprecation.rst
>>>>>>>> +++ b/doc/guides/rel_notes/deprecation.rst
>>>>>>>> @@ -88,6 +88,13 @@ Deprecation Notices
>>>>>>>> will be limited to maximum 256 queues.
>>>>>>>> Also compile time flag ``RTE_ETHDEV_QUEUE_STAT_CNTRS``
>>>>>>>> will be
>>>>>>>> removed.
>>>>>>>> +* ethdev: The flow API matching pattern structures, ``struct
>>>>>>>> rte_flow_item_*``,
>>>>>>>> + should start with relevant protocol header.
>>>>>>>> + Some matching pattern structures implements this by duplicating
>>>>>>>> protocol header
>>>>>>>> + fields in the struct. To clarify the intention and to be sure
>>>>>>>> protocol header
>>>>>>>> + is intact, will replace those fields with relevant protocol
>>>>>>>> header struct.
>>>>>>>> + Target is v21.02 release and this should not change the ABI.
>>>>>>>> +
>>>>>>>> * sched: To allow more traffic classes, flexible mapping of
>>>>>>>> pipe
>>>>>>>> queues to
>>>>>>>> traffic classes, and subport level configuration of pipes and
>>>>>>>> queues
>>>>>>>> changes will be made to macros, data structures and API
>>>>>>>> functions defined
>>>>>>>>
>>>>>>>
>>>>>>> Just want to highlight that even API could be kept using
>>>>>>> unnamed union for hdr and unnamed structure for existing
>>>>>>> protocol header fields.
>>>>>>>
>>>>>>
>>>>>> Then we may never clean the protocol header fields out of it,
>>>>>> yes this will impact the user but I believe the impact is small and
>>>>>> trivial,
>>>>>> I prefer replacing fields with protocol struct.
>>>>>
>>>>> The problem that API breakages are bad and, for example, OvS uses
>>>>> these
>>>>> fields.
>>>>>
>>>>> May be API breakage should be postponed to 21.11?
>>>>>
>>>>
>>>> Agree but it is not as bad as ABI break, if user is already
>>>> compiling their
>>>> code, it is not too bad to adjust the struct for changes, and the
>>>> changes are
>>>> straightforward.
>>>>
>>> I'm not sure which is worse ABI or API, API is more straight forward
>>> but all apps must be modified,
>>> while ABI is hidden and happens only in rare cases.
>>> In a addition it may result in large number of changes (simple but
>>> large number)
>>>
>>>> But if, somehow, application needs to support multiple version of
>>>> the DPDK it
>>>> can be headache.
>>>>
>>>
>>> Agree,
>>>
>>>> We may go with your suggestion until 21.11, and do the cleanup on
>>>> 21.11, will
>>>> it
>>>> work?
>>> +1 also when considering my next line,
>>>
>>> One more point to consider what happens to struct that are not
>>> according to spec,
>>> for example mpls, geneve where the struct is different than the item.
>>>
>>
>> At least for mpls & geneve, the ABI still looks same so change is
>> still possible, but a few fields seems merged which means the change
>> will require more updates in the user application and the drivers.
>> Anyway, agree to postpone change to the 21.11.
>>
>> I will send a v2.
>
> I hope it is still possible to add hdr fields without ABI/ABI breakage
> in 20.02.
>
21.02 of course
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] doc: announce flow API matching pattern struct changes
2020-11-24 12:56 3% ` Ferruh Yigit
@ 2020-11-24 13:00 4% ` Andrew Rybchenko
2020-11-24 13:01 0% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Andrew Rybchenko @ 2020-11-24 13:00 UTC (permalink / raw)
To: Ferruh Yigit, Ori Kam, Ray Kinsella, Neil Horman
Cc: dev, NBU-Contact-Thomas Monjalon
On 11/24/20 3:56 PM, Ferruh Yigit wrote:
> On 11/24/2020 11:43 AM, Ori Kam wrote:
>> Hi
>>
>>> -----Original Message-----
>>> From: Ferruh Yigit <ferruh.yigit@intel.com>
>>> Sent: Monday, November 23, 2020 5:51 PM
>>> Subject: Re: [PATCH] doc: announce flow API matching pattern struct
>>> changes
>>>
>>> On 11/23/2020 2:25 PM, Andrew Rybchenko wrote:
>>>> On 11/23/20 5:17 PM, Ferruh Yigit wrote:
>>>>> On 11/23/2020 1:50 PM, Andrew Rybchenko wrote:
>>>>>> On 11/23/20 4:40 PM, Ferruh Yigit wrote:
>>>>>>> Proposing to replace protocol header fields in the
>>>>>>> ``rte_flow_item_*``
>>>>>>> structures with the protocol structs, like:
>>>>>>>
>>>>>>> Current ``struct rte_flow_item_eth``,
>>>>>>>
>>>>>>> struct rte_flow_item_eth {
>>>>>>> struct rte_ether_addr dst;
>>>>>>> struct rte_ether_addr src;
>>>>>>> rte_be16_t type;
>>>>>>> uint32_t has_vlan:1;
>>>>>>> uint32_t reserved:31;
>>>>>>> }
>>>>>>>
>>>>>>> will become
>>>>>>>
>>>>>>> struct rte_flow_item_eth {
>>>>>>> struct rte_ether_hdr hdr;
>>>>>>> uint32_t has_vlan:1;
>>>>>>> uint32_t reserved:31;
>>>>>>> }
>>>>>>>
>>>>>>> This is both for documenting the intention and to be sure
>>>>>>> ``rte_flow_item_*`` always starts with complete protocol header.
>>>>>>>
>>>>>>> Already many ``rte_flow_item_*`` structs implemented to have
>>>>>>> protocol
>>>>>>> struct, target is convert all to this usage.
>>>>>>>
>>>>>>> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
>>>>>>
>>>>>> Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>>>>>>
>>>>>> a minor note below
>>>>>>
>>>>>>> ---
>>>>>>> Cc: Thomas Monjalon <thomas@monjalon.net>
>>>>>>> Cc: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>>>>>>> Cc: Ori Kam <orika@nvidia.com>
>>>>>>> ---
>>>>>>> doc/guides/rel_notes/deprecation.rst | 7 +++++++
>>>>>>> 1 file changed, 7 insertions(+)
>>>>>>>
>>>>>>> diff --git a/doc/guides/rel_notes/deprecation.rst
>>>>>>> b/doc/guides/rel_notes/deprecation.rst
>>>>>>> index 96986fabd598..a2fa0c196472 100644
>>>>>>> --- a/doc/guides/rel_notes/deprecation.rst
>>>>>>> +++ b/doc/guides/rel_notes/deprecation.rst
>>>>>>> @@ -88,6 +88,13 @@ Deprecation Notices
>>>>>>> will be limited to maximum 256 queues.
>>>>>>> Also compile time flag ``RTE_ETHDEV_QUEUE_STAT_CNTRS``
>>>>>>> will be
>>>>>>> removed.
>>>>>>> +* ethdev: The flow API matching pattern structures, ``struct
>>>>>>> rte_flow_item_*``,
>>>>>>> + should start with relevant protocol header.
>>>>>>> + Some matching pattern structures implements this by duplicating
>>>>>>> protocol header
>>>>>>> + fields in the struct. To clarify the intention and to be sure
>>>>>>> protocol header
>>>>>>> + is intact, will replace those fields with relevant protocol
>>>>>>> header struct.
>>>>>>> + Target is v21.02 release and this should not change the ABI.
>>>>>>> +
>>>>>>> * sched: To allow more traffic classes, flexible mapping of
>>>>>>> pipe
>>>>>>> queues to
>>>>>>> traffic classes, and subport level configuration of pipes and
>>>>>>> queues
>>>>>>> changes will be made to macros, data structures and API
>>>>>>> functions defined
>>>>>>>
>>>>>>
>>>>>> Just want to highlight that even API could be kept using
>>>>>> unnamed union for hdr and unnamed structure for existing
>>>>>> protocol header fields.
>>>>>>
>>>>>
>>>>> Then we may never clean the protocol header fields out of it,
>>>>> yes this will impact the user but I believe the impact is small and
>>>>> trivial,
>>>>> I prefer replacing fields with protocol struct.
>>>>
>>>> The problem that API breakages are bad and, for example, OvS uses
>>>> these
>>>> fields.
>>>>
>>>> May be API breakage should be postponed to 21.11?
>>>>
>>>
>>> Agree but it is not as bad as ABI break, if user is already
>>> compiling their
>>> code, it is not too bad to adjust the struct for changes, and the
>>> changes are
>>> straightforward.
>>>
>> I'm not sure which is worse ABI or API, API is more straight forward
>> but all apps must be modified,
>> while ABI is hidden and happens only in rare cases.
>> In a addition it may result in large number of changes (simple but
>> large number)
>>
>>> But if, somehow, application needs to support multiple version of
>>> the DPDK it
>>> can be headache.
>>>
>>
>> Agree,
>>
>>> We may go with your suggestion until 21.11, and do the cleanup on
>>> 21.11, will
>>> it
>>> work?
>> +1 also when considering my next line,
>>
>> One more point to consider what happens to struct that are not
>> according to spec,
>> for example mpls, geneve where the struct is different than the item.
>>
>
> At least for mpls & geneve, the ABI still looks same so change is
> still possible, but a few fields seems merged which means the change
> will require more updates in the user application and the drivers.
> Anyway, agree to postpone change to the 21.11.
>
> I will send a v2.
I hope it is still possible to add hdr fields without ABI/ABI breakage
in 20.02.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce flow API matching pattern struct changes
2020-11-24 11:43 4% ` Ori Kam
@ 2020-11-24 12:56 3% ` Ferruh Yigit
2020-11-24 13:00 4% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2020-11-24 12:56 UTC (permalink / raw)
To: Ori Kam, Andrew Rybchenko, Ray Kinsella, Neil Horman
Cc: dev, NBU-Contact-Thomas Monjalon
On 11/24/2020 11:43 AM, Ori Kam wrote:
> Hi
>
>> -----Original Message-----
>> From: Ferruh Yigit <ferruh.yigit@intel.com>
>> Sent: Monday, November 23, 2020 5:51 PM
>> Subject: Re: [PATCH] doc: announce flow API matching pattern struct changes
>>
>> On 11/23/2020 2:25 PM, Andrew Rybchenko wrote:
>>> On 11/23/20 5:17 PM, Ferruh Yigit wrote:
>>>> On 11/23/2020 1:50 PM, Andrew Rybchenko wrote:
>>>>> On 11/23/20 4:40 PM, Ferruh Yigit wrote:
>>>>>> Proposing to replace protocol header fields in the ``rte_flow_item_*``
>>>>>> structures with the protocol structs, like:
>>>>>>
>>>>>> Current ``struct rte_flow_item_eth``,
>>>>>>
>>>>>> struct rte_flow_item_eth {
>>>>>> struct rte_ether_addr dst;
>>>>>> struct rte_ether_addr src;
>>>>>> rte_be16_t type;
>>>>>> uint32_t has_vlan:1;
>>>>>> uint32_t reserved:31;
>>>>>> }
>>>>>>
>>>>>> will become
>>>>>>
>>>>>> struct rte_flow_item_eth {
>>>>>> struct rte_ether_hdr hdr;
>>>>>> uint32_t has_vlan:1;
>>>>>> uint32_t reserved:31;
>>>>>> }
>>>>>>
>>>>>> This is both for documenting the intention and to be sure
>>>>>> ``rte_flow_item_*`` always starts with complete protocol header.
>>>>>>
>>>>>> Already many ``rte_flow_item_*`` structs implemented to have protocol
>>>>>> struct, target is convert all to this usage.
>>>>>>
>>>>>> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
>>>>>
>>>>> Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>>>>>
>>>>> a minor note below
>>>>>
>>>>>> ---
>>>>>> Cc: Thomas Monjalon <thomas@monjalon.net>
>>>>>> Cc: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>>>>>> Cc: Ori Kam <orika@nvidia.com>
>>>>>> ---
>>>>>> doc/guides/rel_notes/deprecation.rst | 7 +++++++
>>>>>> 1 file changed, 7 insertions(+)
>>>>>>
>>>>>> diff --git a/doc/guides/rel_notes/deprecation.rst
>>>>>> b/doc/guides/rel_notes/deprecation.rst
>>>>>> index 96986fabd598..a2fa0c196472 100644
>>>>>> --- a/doc/guides/rel_notes/deprecation.rst
>>>>>> +++ b/doc/guides/rel_notes/deprecation.rst
>>>>>> @@ -88,6 +88,13 @@ Deprecation Notices
>>>>>> will be limited to maximum 256 queues.
>>>>>> Also compile time flag ``RTE_ETHDEV_QUEUE_STAT_CNTRS`` will be
>>>>>> removed.
>>>>>> +* ethdev: The flow API matching pattern structures, ``struct
>>>>>> rte_flow_item_*``,
>>>>>> + should start with relevant protocol header.
>>>>>> + Some matching pattern structures implements this by duplicating
>>>>>> protocol header
>>>>>> + fields in the struct. To clarify the intention and to be sure
>>>>>> protocol header
>>>>>> + is intact, will replace those fields with relevant protocol
>>>>>> header struct.
>>>>>> + Target is v21.02 release and this should not change the ABI.
>>>>>> +
>>>>>> * sched: To allow more traffic classes, flexible mapping of pipe
>>>>>> queues to
>>>>>> traffic classes, and subport level configuration of pipes and
>>>>>> queues
>>>>>> changes will be made to macros, data structures and API
>>>>>> functions defined
>>>>>>
>>>>>
>>>>> Just want to highlight that even API could be kept using
>>>>> unnamed union for hdr and unnamed structure for existing
>>>>> protocol header fields.
>>>>>
>>>>
>>>> Then we may never clean the protocol header fields out of it,
>>>> yes this will impact the user but I believe the impact is small and
>>>> trivial,
>>>> I prefer replacing fields with protocol struct.
>>>
>>> The problem that API breakages are bad and, for example, OvS uses these
>>> fields.
>>>
>>> May be API breakage should be postponed to 21.11?
>>>
>>
>> Agree but it is not as bad as ABI break, if user is already compiling their
>> code, it is not too bad to adjust the struct for changes, and the changes are
>> straightforward.
>>
> I'm not sure which is worse ABI or API, API is more straight forward but all apps must be modified,
> while ABI is hidden and happens only in rare cases.
> In a addition it may result in large number of changes (simple but large number)
>
>> But if, somehow, application needs to support multiple version of the DPDK it
>> can be headache.
>>
>
> Agree,
>
>> We may go with your suggestion until 21.11, and do the cleanup on 21.11, will
>> it
>> work?
> +1 also when considering my next line,
>
> One more point to consider what happens to struct that are not according to spec,
> for example mpls, geneve where the struct is different than the item.
>
At least for mpls & geneve, the ABI still looks same so change is still
possible, but a few fields seems merged which means the change will require more
updates in the user application and the drivers. Anyway, agree to postpone
change to the 21.11.
I will send a v2.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] doc: announce flow API matching pattern struct changes
2020-11-23 15:51 3% ` Ferruh Yigit
@ 2020-11-24 11:43 4% ` Ori Kam
2020-11-24 12:56 3% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Ori Kam @ 2020-11-24 11:43 UTC (permalink / raw)
To: Ferruh Yigit, Andrew Rybchenko, Ray Kinsella, Neil Horman
Cc: dev, NBU-Contact-Thomas Monjalon
Hi
> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> Sent: Monday, November 23, 2020 5:51 PM
> Subject: Re: [PATCH] doc: announce flow API matching pattern struct changes
>
> On 11/23/2020 2:25 PM, Andrew Rybchenko wrote:
> > On 11/23/20 5:17 PM, Ferruh Yigit wrote:
> >> On 11/23/2020 1:50 PM, Andrew Rybchenko wrote:
> >>> On 11/23/20 4:40 PM, Ferruh Yigit wrote:
> >>>> Proposing to replace protocol header fields in the ``rte_flow_item_*``
> >>>> structures with the protocol structs, like:
> >>>>
> >>>> Current ``struct rte_flow_item_eth``,
> >>>>
> >>>> struct rte_flow_item_eth {
> >>>> struct rte_ether_addr dst;
> >>>> struct rte_ether_addr src;
> >>>> rte_be16_t type;
> >>>> uint32_t has_vlan:1;
> >>>> uint32_t reserved:31;
> >>>> }
> >>>>
> >>>> will become
> >>>>
> >>>> struct rte_flow_item_eth {
> >>>> struct rte_ether_hdr hdr;
> >>>> uint32_t has_vlan:1;
> >>>> uint32_t reserved:31;
> >>>> }
> >>>>
> >>>> This is both for documenting the intention and to be sure
> >>>> ``rte_flow_item_*`` always starts with complete protocol header.
> >>>>
> >>>> Already many ``rte_flow_item_*`` structs implemented to have protocol
> >>>> struct, target is convert all to this usage.
> >>>>
> >>>> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> >>>
> >>> Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> >>>
> >>> a minor note below
> >>>
> >>>> ---
> >>>> Cc: Thomas Monjalon <thomas@monjalon.net>
> >>>> Cc: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> >>>> Cc: Ori Kam <orika@nvidia.com>
> >>>> ---
> >>>> doc/guides/rel_notes/deprecation.rst | 7 +++++++
> >>>> 1 file changed, 7 insertions(+)
> >>>>
> >>>> diff --git a/doc/guides/rel_notes/deprecation.rst
> >>>> b/doc/guides/rel_notes/deprecation.rst
> >>>> index 96986fabd598..a2fa0c196472 100644
> >>>> --- a/doc/guides/rel_notes/deprecation.rst
> >>>> +++ b/doc/guides/rel_notes/deprecation.rst
> >>>> @@ -88,6 +88,13 @@ Deprecation Notices
> >>>> will be limited to maximum 256 queues.
> >>>> Also compile time flag ``RTE_ETHDEV_QUEUE_STAT_CNTRS`` will be
> >>>> removed.
> >>>> +* ethdev: The flow API matching pattern structures, ``struct
> >>>> rte_flow_item_*``,
> >>>> + should start with relevant protocol header.
> >>>> + Some matching pattern structures implements this by duplicating
> >>>> protocol header
> >>>> + fields in the struct. To clarify the intention and to be sure
> >>>> protocol header
> >>>> + is intact, will replace those fields with relevant protocol
> >>>> header struct.
> >>>> + Target is v21.02 release and this should not change the ABI.
> >>>> +
> >>>> * sched: To allow more traffic classes, flexible mapping of pipe
> >>>> queues to
> >>>> traffic classes, and subport level configuration of pipes and
> >>>> queues
> >>>> changes will be made to macros, data structures and API
> >>>> functions defined
> >>>>
> >>>
> >>> Just want to highlight that even API could be kept using
> >>> unnamed union for hdr and unnamed structure for existing
> >>> protocol header fields.
> >>>
> >>
> >> Then we may never clean the protocol header fields out of it,
> >> yes this will impact the user but I believe the impact is small and
> >> trivial,
> >> I prefer replacing fields with protocol struct.
> >
> > The problem that API breakages are bad and, for example, OvS uses these
> > fields.
> >
> > May be API breakage should be postponed to 21.11?
> >
>
> Agree but it is not as bad as ABI break, if user is already compiling their
> code, it is not too bad to adjust the struct for changes, and the changes are
> straightforward.
>
I'm not sure which is worse ABI or API, API is more straight forward but all apps must be modified,
while ABI is hidden and happens only in rare cases.
In a addition it may result in large number of changes (simple but large number)
> But if, somehow, application needs to support multiple version of the DPDK it
> can be headache.
>
Agree,
> We may go with your suggestion until 21.11, and do the cleanup on 21.11, will
> it
> work?
+1 also when considering my next line,
One more point to consider what happens to struct that are not according to spec,
for example mpls, geneve where the struct is different than the item.
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v2] build: alias default build as generic
@ 2020-11-24 7:52 3% ` Juraj Linkeš
0 siblings, 0 replies; 200+ results
From: Juraj Linkeš @ 2020-11-24 7:52 UTC (permalink / raw)
To: thomas, bruce.richardson, Honnappa.Nagarahalli; +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>
---
config/arm/meson.build | 5 +++--
config/meson.build | 13 +++++++------
devtools/test-meson-builds.sh | 12 ++++++------
doc/guides/prog_guide/build-sdk-meson.rst | 4 ++--
meson_options.txt | 2 +-
5 files changed, 19 insertions(+), 17 deletions(-)
diff --git a/config/arm/meson.build b/config/arm/meson.build
index 42b4e43c7..d4066ade8 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -1,12 +1,13 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017 Intel Corporation.
# Copyright(c) 2017 Cavium, Inc
+# Copyright(c) 2020 PANTHEON.tech s.r.o.
# for checking defines we need to use the correct compiler flags
march_opt = '-march=@0@'.format(machine)
arm_force_native_march = false
-arm_force_default_march = (machine == 'default')
+arm_force_generic_march = (machine == 'generic')
flags_common_default = [
# Accelarate rte_memcpy. Be sure to run unit test (memcpy_perf_autotest)
@@ -148,7 +149,7 @@ else
cmd_generic = ['generic', '', '', 'default', '']
cmd_output = cmd_generic # Set generic by default
machine_args = [] # Clear previous machine args
- if arm_force_default_march and not meson.is_cross_build()
+ if arm_force_generic_march and not meson.is_cross_build()
machine = impl_generic
impl_pn = 'default'
elif not meson.is_cross_build()
diff --git a/config/meson.build b/config/meson.build
index a29693b88..3db2f55e0 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 3ce49368c..11aa9bf11 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -209,11 +209,11 @@ 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 -Dlibdir=lib -Dmachine=$default_machine $use_shared
+build build-x86-generic cc -Dlibdir=lib -Dmachine=$generic_machine $use_shared
# 32-bit with default compiler
if check_cc_flags '-m32' ; then
@@ -253,10 +253,10 @@ for f in $srcdir/config/ppc/ppc* ; do
build build-$(basename $f | cut -d'-' -f-2) $f $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
# No need to reinstall if ABI checks are enabled
if [ -z "$DPDK_ABI_REF_VERSION" ]; then
diff --git a/doc/guides/prog_guide/build-sdk-meson.rst b/doc/guides/prog_guide/build-sdk-meson.rst
index 3429e2647..c7e12eedf 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 e384e6dbb..ebd28d8b8 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -21,7 +21,7 @@ option('kernel_dir', type: 'string', value: '',
option('lib_musdk_dir', type: 'string', value: '',
description: 'path to the MUSDK library installation directory')
option('machine', type: 'string', value: 'native',
- description: 'set the target machine type')
+ description: 'set the target machine type. Special values: "generic" is a build usable on all machines of the build machine architecture, "native" 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] doc: announce flow API matching pattern struct changes
2020-11-23 14:25 0% ` Andrew Rybchenko
@ 2020-11-23 15:51 3% ` Ferruh Yigit
2020-11-24 11:43 4% ` Ori Kam
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2020-11-23 15:51 UTC (permalink / raw)
To: Andrew Rybchenko, Ray Kinsella, Neil Horman; +Cc: dev, Thomas Monjalon, Ori Kam
On 11/23/2020 2:25 PM, Andrew Rybchenko wrote:
> On 11/23/20 5:17 PM, Ferruh Yigit wrote:
>> On 11/23/2020 1:50 PM, Andrew Rybchenko wrote:
>>> On 11/23/20 4:40 PM, Ferruh Yigit wrote:
>>>> Proposing to replace protocol header fields in the ``rte_flow_item_*``
>>>> structures with the protocol structs, like:
>>>>
>>>> Current ``struct rte_flow_item_eth``,
>>>>
>>>> struct rte_flow_item_eth {
>>>> struct rte_ether_addr dst;
>>>> struct rte_ether_addr src;
>>>> rte_be16_t type;
>>>> uint32_t has_vlan:1;
>>>> uint32_t reserved:31;
>>>> }
>>>>
>>>> will become
>>>>
>>>> struct rte_flow_item_eth {
>>>> struct rte_ether_hdr hdr;
>>>> uint32_t has_vlan:1;
>>>> uint32_t reserved:31;
>>>> }
>>>>
>>>> This is both for documenting the intention and to be sure
>>>> ``rte_flow_item_*`` always starts with complete protocol header.
>>>>
>>>> Already many ``rte_flow_item_*`` structs implemented to have protocol
>>>> struct, target is convert all to this usage.
>>>>
>>>> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
>>>
>>> Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>>>
>>> a minor note below
>>>
>>>> ---
>>>> Cc: Thomas Monjalon <thomas@monjalon.net>
>>>> Cc: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>>>> Cc: Ori Kam <orika@nvidia.com>
>>>> ---
>>>> doc/guides/rel_notes/deprecation.rst | 7 +++++++
>>>> 1 file changed, 7 insertions(+)
>>>>
>>>> diff --git a/doc/guides/rel_notes/deprecation.rst
>>>> b/doc/guides/rel_notes/deprecation.rst
>>>> index 96986fabd598..a2fa0c196472 100644
>>>> --- a/doc/guides/rel_notes/deprecation.rst
>>>> +++ b/doc/guides/rel_notes/deprecation.rst
>>>> @@ -88,6 +88,13 @@ Deprecation Notices
>>>> will be limited to maximum 256 queues.
>>>> Also compile time flag ``RTE_ETHDEV_QUEUE_STAT_CNTRS`` will be
>>>> removed.
>>>> +* ethdev: The flow API matching pattern structures, ``struct
>>>> rte_flow_item_*``,
>>>> + should start with relevant protocol header.
>>>> + Some matching pattern structures implements this by duplicating
>>>> protocol header
>>>> + fields in the struct. To clarify the intention and to be sure
>>>> protocol header
>>>> + is intact, will replace those fields with relevant protocol
>>>> header struct.
>>>> + Target is v21.02 release and this should not change the ABI.
>>>> +
>>>> * sched: To allow more traffic classes, flexible mapping of pipe
>>>> queues to
>>>> traffic classes, and subport level configuration of pipes and
>>>> queues
>>>> changes will be made to macros, data structures and API
>>>> functions defined
>>>>
>>>
>>> Just want to highlight that even API could be kept using
>>> unnamed union for hdr and unnamed structure for existing
>>> protocol header fields.
>>>
>>
>> Then we may never clean the protocol header fields out of it,
>> yes this will impact the user but I believe the impact is small and
>> trivial,
>> I prefer replacing fields with protocol struct.
>
> The problem that API breakages are bad and, for example, OvS uses these
> fields.
>
> May be API breakage should be postponed to 21.11?
>
Agree but it is not as bad as ABI break, if user is already compiling their
code, it is not too bad to adjust the struct for changes, and the changes are
straightforward.
But if, somehow, application needs to support multiple version of the DPDK it
can be headache.
We may go with your suggestion until 21.11, and do the cleanup on 21.11, will it
work?
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] doc: announce flow API matching pattern struct changes
2020-11-23 14:17 0% ` Ferruh Yigit
@ 2020-11-23 14:25 0% ` Andrew Rybchenko
2020-11-23 15:51 3% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Andrew Rybchenko @ 2020-11-23 14:25 UTC (permalink / raw)
To: Ferruh Yigit, Ray Kinsella, Neil Horman; +Cc: dev, Thomas Monjalon, Ori Kam
On 11/23/20 5:17 PM, Ferruh Yigit wrote:
> On 11/23/2020 1:50 PM, Andrew Rybchenko wrote:
>> On 11/23/20 4:40 PM, Ferruh Yigit wrote:
>>> Proposing to replace protocol header fields in the ``rte_flow_item_*``
>>> structures with the protocol structs, like:
>>>
>>> Current ``struct rte_flow_item_eth``,
>>>
>>> struct rte_flow_item_eth {
>>> struct rte_ether_addr dst;
>>> struct rte_ether_addr src;
>>> rte_be16_t type;
>>> uint32_t has_vlan:1;
>>> uint32_t reserved:31;
>>> }
>>>
>>> will become
>>>
>>> struct rte_flow_item_eth {
>>> struct rte_ether_hdr hdr;
>>> uint32_t has_vlan:1;
>>> uint32_t reserved:31;
>>> }
>>>
>>> This is both for documenting the intention and to be sure
>>> ``rte_flow_item_*`` always starts with complete protocol header.
>>>
>>> Already many ``rte_flow_item_*`` structs implemented to have protocol
>>> struct, target is convert all to this usage.
>>>
>>> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
>>
>> Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>>
>> a minor note below
>>
>>> ---
>>> Cc: Thomas Monjalon <thomas@monjalon.net>
>>> Cc: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>>> Cc: Ori Kam <orika@nvidia.com>
>>> ---
>>> doc/guides/rel_notes/deprecation.rst | 7 +++++++
>>> 1 file changed, 7 insertions(+)
>>>
>>> diff --git a/doc/guides/rel_notes/deprecation.rst
>>> b/doc/guides/rel_notes/deprecation.rst
>>> index 96986fabd598..a2fa0c196472 100644
>>> --- a/doc/guides/rel_notes/deprecation.rst
>>> +++ b/doc/guides/rel_notes/deprecation.rst
>>> @@ -88,6 +88,13 @@ Deprecation Notices
>>> will be limited to maximum 256 queues.
>>> Also compile time flag ``RTE_ETHDEV_QUEUE_STAT_CNTRS`` will be
>>> removed.
>>> +* ethdev: The flow API matching pattern structures, ``struct
>>> rte_flow_item_*``,
>>> + should start with relevant protocol header.
>>> + Some matching pattern structures implements this by duplicating
>>> protocol header
>>> + fields in the struct. To clarify the intention and to be sure
>>> protocol header
>>> + is intact, will replace those fields with relevant protocol
>>> header struct.
>>> + Target is v21.02 release and this should not change the ABI.
>>> +
>>> * sched: To allow more traffic classes, flexible mapping of pipe
>>> queues to
>>> traffic classes, and subport level configuration of pipes and
>>> queues
>>> changes will be made to macros, data structures and API
>>> functions defined
>>>
>>
>> Just want to highlight that even API could be kept using
>> unnamed union for hdr and unnamed structure for existing
>> protocol header fields.
>>
>
> Then we may never clean the protocol header fields out of it,
> yes this will impact the user but I believe the impact is small and
> trivial,
> I prefer replacing fields with protocol struct.
The problem that API breakages are bad and, for example, OvS uses these
fields.
May be API breakage should be postponed to 21.11?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] doc: announce flow API matching pattern struct changes
2020-11-23 13:50 0% ` Andrew Rybchenko
@ 2020-11-23 14:17 0% ` Ferruh Yigit
2020-11-23 14:25 0% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2020-11-23 14:17 UTC (permalink / raw)
To: Andrew Rybchenko, Ray Kinsella, Neil Horman; +Cc: dev, Thomas Monjalon, Ori Kam
On 11/23/2020 1:50 PM, Andrew Rybchenko wrote:
> On 11/23/20 4:40 PM, Ferruh Yigit wrote:
>> Proposing to replace protocol header fields in the ``rte_flow_item_*``
>> structures with the protocol structs, like:
>>
>> Current ``struct rte_flow_item_eth``,
>>
>> struct rte_flow_item_eth {
>> struct rte_ether_addr dst;
>> struct rte_ether_addr src;
>> rte_be16_t type;
>> uint32_t has_vlan:1;
>> uint32_t reserved:31;
>> }
>>
>> will become
>>
>> struct rte_flow_item_eth {
>> struct rte_ether_hdr hdr;
>> uint32_t has_vlan:1;
>> uint32_t reserved:31;
>> }
>>
>> This is both for documenting the intention and to be sure
>> ``rte_flow_item_*`` always starts with complete protocol header.
>>
>> Already many ``rte_flow_item_*`` structs implemented to have protocol
>> struct, target is convert all to this usage.
>>
>> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
>
> Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>
> a minor note below
>
>> ---
>> Cc: Thomas Monjalon <thomas@monjalon.net>
>> Cc: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>> Cc: Ori Kam <orika@nvidia.com>
>> ---
>> doc/guides/rel_notes/deprecation.rst | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
>> index 96986fabd598..a2fa0c196472 100644
>> --- a/doc/guides/rel_notes/deprecation.rst
>> +++ b/doc/guides/rel_notes/deprecation.rst
>> @@ -88,6 +88,13 @@ Deprecation Notices
>> will be limited to maximum 256 queues.
>> Also compile time flag ``RTE_ETHDEV_QUEUE_STAT_CNTRS`` will be removed.
>>
>> +* ethdev: The flow API matching pattern structures, ``struct rte_flow_item_*``,
>> + should start with relevant protocol header.
>> + Some matching pattern structures implements this by duplicating protocol header
>> + fields in the struct. To clarify the intention and to be sure protocol header
>> + is intact, will replace those fields with relevant protocol header struct.
>> + Target is v21.02 release and this should not change the ABI.
>> +
>> * sched: To allow more traffic classes, flexible mapping of pipe queues to
>> traffic classes, and subport level configuration of pipes and queues
>> changes will be made to macros, data structures and API functions defined
>>
>
> Just want to highlight that even API could be kept using
> unnamed union for hdr and unnamed structure for existing
> protocol header fields.
>
Then we may never clean the protocol header fields out of it,
yes this will impact the user but I believe the impact is small and trivial,
I prefer replacing fields with protocol struct.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] doc: announce flow API matching pattern struct changes
2020-11-23 13:40 5% [dpdk-dev] [PATCH] doc: announce flow API matching pattern struct changes Ferruh Yigit
@ 2020-11-23 13:50 0% ` Andrew Rybchenko
2020-11-23 14:17 0% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Andrew Rybchenko @ 2020-11-23 13:50 UTC (permalink / raw)
To: Ferruh Yigit, Ray Kinsella, Neil Horman; +Cc: dev, Thomas Monjalon, Ori Kam
On 11/23/20 4:40 PM, Ferruh Yigit wrote:
> Proposing to replace protocol header fields in the ``rte_flow_item_*``
> structures with the protocol structs, like:
>
> Current ``struct rte_flow_item_eth``,
>
> struct rte_flow_item_eth {
> struct rte_ether_addr dst;
> struct rte_ether_addr src;
> rte_be16_t type;
> uint32_t has_vlan:1;
> uint32_t reserved:31;
> }
>
> will become
>
> struct rte_flow_item_eth {
> struct rte_ether_hdr hdr;
> uint32_t has_vlan:1;
> uint32_t reserved:31;
> }
>
> This is both for documenting the intention and to be sure
> ``rte_flow_item_*`` always starts with complete protocol header.
>
> Already many ``rte_flow_item_*`` structs implemented to have protocol
> struct, target is convert all to this usage.
>
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
a minor note below
> ---
> Cc: Thomas Monjalon <thomas@monjalon.net>
> Cc: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> Cc: Ori Kam <orika@nvidia.com>
> ---
> doc/guides/rel_notes/deprecation.rst | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index 96986fabd598..a2fa0c196472 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -88,6 +88,13 @@ Deprecation Notices
> will be limited to maximum 256 queues.
> Also compile time flag ``RTE_ETHDEV_QUEUE_STAT_CNTRS`` will be removed.
>
> +* ethdev: The flow API matching pattern structures, ``struct rte_flow_item_*``,
> + should start with relevant protocol header.
> + Some matching pattern structures implements this by duplicating protocol header
> + fields in the struct. To clarify the intention and to be sure protocol header
> + is intact, will replace those fields with relevant protocol header struct.
> + Target is v21.02 release and this should not change the ABI.
> +
> * sched: To allow more traffic classes, flexible mapping of pipe queues to
> traffic classes, and subport level configuration of pipes and queues
> changes will be made to macros, data structures and API functions defined
>
Just want to highlight that even API could be kept using
unnamed union for hdr and unnamed structure for existing
protocol header fields.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH] doc: announce flow API matching pattern struct changes
@ 2020-11-23 13:40 5% Ferruh Yigit
2020-11-23 13:50 0% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2020-11-23 13:40 UTC (permalink / raw)
To: Ray Kinsella, Neil Horman
Cc: Ferruh Yigit, dev, Thomas Monjalon, Andrew Rybchenko, Ori Kam
Proposing to replace protocol header fields in the ``rte_flow_item_*``
structures with the protocol structs, like:
Current ``struct rte_flow_item_eth``,
struct rte_flow_item_eth {
struct rte_ether_addr dst;
struct rte_ether_addr src;
rte_be16_t type;
uint32_t has_vlan:1;
uint32_t reserved:31;
}
will become
struct rte_flow_item_eth {
struct rte_ether_hdr hdr;
uint32_t has_vlan:1;
uint32_t reserved:31;
}
This is both for documenting the intention and to be sure
``rte_flow_item_*`` always starts with complete protocol header.
Already many ``rte_flow_item_*`` structs implemented to have protocol
struct, target is convert all to this usage.
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
Cc: Thomas Monjalon <thomas@monjalon.net>
Cc: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Cc: Ori Kam <orika@nvidia.com>
---
doc/guides/rel_notes/deprecation.rst | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 96986fabd598..a2fa0c196472 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -88,6 +88,13 @@ Deprecation Notices
will be limited to maximum 256 queues.
Also compile time flag ``RTE_ETHDEV_QUEUE_STAT_CNTRS`` will be removed.
+* ethdev: The flow API matching pattern structures, ``struct rte_flow_item_*``,
+ should start with relevant protocol header.
+ Some matching pattern structures implements this by duplicating protocol header
+ fields in the struct. To clarify the intention and to be sure protocol header
+ is intact, will replace those fields with relevant protocol header struct.
+ Target is v21.02 release and this should not change the ABI.
+
* sched: To allow more traffic classes, flexible mapping of pipe queues to
traffic classes, and subport level configuration of pipes and queues
changes will be made to macros, data structures and API functions defined
--
2.26.2
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [dpdk-techboard] Minutes of Technical Board Meeting, 2020-11-18
2020-11-23 10:00 0% ` [dpdk-dev] [dpdk-techboard] " Thomas Monjalon
@ 2020-11-23 11:16 0% ` Morten Brørup
0 siblings, 0 replies; 200+ results
From: Morten Brørup @ 2020-11-23 11:16 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: Bruce Richardson, dev, techboard
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Monday, November 23, 2020 11:00 AM
>
> 23/11/2020 10:30, Morten Brørup:
> > Bruce,
> >
> > Here's my input as a developer of hardware appliances. It is my
> opinion, and as such may contradict the trend towards making DPDK a
> library, rather than a development kit.
> >
> > > DPDK build configuration - future enhancements
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > There are multiple requests (sometimes controversial) for new
> abilities
> > > to add into DPDK build system.
> > > In particular, request from few different teams:
> > > - add ability to enable/disable individual apps/libs
> > > - override some build settings for specific libs/drivers
> >
> > My wish list, in prioritized order:
> >
> > 1. The ability to remove features to reduce complexity - and thus the
> likelihood of bugs!
> >
> > Remember to consider this in application context.
> >
> > Background: Our previous firmware used the Linux kernel, and some
> loadable modules. We ran into a lot of extremely rare and unexpected
> cases where the Linux kernel network stack did something completely
> unusual, and our firmware needed to consider all these exceptional
> cases. This is one of the key reasons we switched to DPDK - the fast
> path libraries are clean and simple, and don't do anything we didn't
> ask them to do.
> >
> > DPDK example: If support for segmented packets are considered
> "required" by DPDK libraries and drivers, is it also required for
> applications to support segmented packet? If the application doesn’t
> need segmented packets, can it safely assume that no DPDK libraries or
> drivers create segmented packets under any circumstances? If support
> for segmented packets is a compile time option, there is an implicit
> guarantee that they don't appear.
>
> The primary rule in DPDK is that the application remains in control.
> If the application does not call the API function for a feature,
> it won't be enabled. So no need to remove the unused libraries.
I think that this principle - the application remaining in control - is extremely important for DPDK, and we must always remember this principle when adding features to DPDK.
However, being able to disable some features at compile time elevates the certainty that these features are not being unexpectedly used from "trust" to "absolute certainty".
The DPDK core and libraries are growing in complexity, and I am starting to worry about this. Once bitten twice shy.
By the way, I consider the Dynamic MBUF concept a great enhancement in this area. The cleanup part of the Dynamic MBUF patch set made non-essential fields in the mbuf truly optional.
>
>
> > 2. The ability to remove/tweak features to improve *application*
> performance in specific environments would be good.
> >
> > E.g. removing support for multiple mbuf pools would free up an mbuf
> field (m->pool) for application use.
> > So would removing support for segmented packets (m->nb_segs, m-
> >next).
> >
> > Both of these modifications would also reduce complexity, although
> they would increase source code complexity in all the libraries and
> drivers needing to support a multidimensional matrix of features. (I
> highly doubt that all libraries support the combination of all features
> today... I remember having to argue strongly for the DPDK eBPF library
> to support reading data inside segmented packets.)
>
> Because code must remain simple, the mbuf layout is fixed
> (except dynamic fields).
The mbuf layout could remain fixed (so vector implementations can rely on the layout), but the removed fields would become unused and available for application use instead, thus improving the application performance.
In the example of removing support for multiple mbuf pools, the functions free()'ing mbufs in the DPDK mbuf library and the DPDK drivers would be simpler, thus improving the performance. Removing support for segmented packets would also allow simpler (and thus higher performing) implementations of a few DPDK core functions.
It is somewhat difficult to formulate in writing, but I will try rephrasing my original point: Tweaking DPDK can provide performance improvements in the application itself, not only in the DPDK libraries/drivers.
>
>
> > 3. Removing cruft that has no effect on performance or similar, is
> "nice to have".
> >
> > E.g. drivers for hardware that we do not use.
> >
> > > As a first step to move forward - produce design doc of current
> build
> > > system.
> > > Discuss further enhancements based on that doc.
> >
> > > While planning changes to the build system backward compatibility
> > > with 20.11 should be considered.
> >
> > Backward compatibility is not a high priority for us. It is an
> extremely rare event for us to upgrade to a new version of any external
> software (Linux Kernel, DPDK and other libraries) or build tools,
> because we consider switching any of it to another version high effort
> (e.g. it requires extensive testing). In this perspective, having to
> change some details in the build system is a relatively small effort.
> >
> > With this said, the documentation of each DPDK release should include
> a chapter describing what an application developer should do different
> than with the previous release. E.g. the Release Note enumerates the
> key modifications as bullet points, but it is not always obvious how
> that affects an application being developed. (DPDK generally has great
> documentation, but is somewhat lacking in this area.)
> >
> > I know that ABI Stability is supposed to make much of this go away,
> but DPDK is clearly not there yet.
> >
> > > AR to Bruce to create initial version of the DD.
> > >
> >
> > The following may be scope creep, so just consider it me thinking out
> loud:
> >
> > Consider a general design documents in the form of a "life of an
> mbuf" document, describing how mbufs are pre-allocated for driver RX
> descriptors, and then handed over to the application trough the receive
> function, and then possibly going through defragmentation and
> reordering libraries, and then handed over to another driver's transmit
> function, which uses the mbufs to set up TX descriptors, and after
> transmission frees the mbufs to their original pool, where they are
> ultimately allocated again by a driver to refill its RX descriptor
> pool.
> >
> > The document can start off with the simple case with a single non-
> segmented, non-fragmented, in-order packet. And then it can be extended
> with variations, e.g. adding the description of segmented packets would
> explain how the m->nb_segs and m->next are being used when the packet
> is handled by the drivers and libraries.
> >
> > In the context of being able to enable/disable libraries and
> features, the purpose of this document would be to help showing
> interdependencies.
>
> I agree we need this kind of doc.
> It could be part of the prog guide.
> Feel free to draft a skeleton.
>
>
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [dpdk-techboard] Minutes of Technical Board Meeting, 2020-11-18
@ 2020-11-23 10:00 0% ` Thomas Monjalon
2020-11-23 11:16 0% ` Morten Brørup
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2020-11-23 10:00 UTC (permalink / raw)
To: Morten Brørup; +Cc: Bruce Richardson, dev, techboard
23/11/2020 10:30, Morten Brørup:
> Bruce,
>
> Here's my input as a developer of hardware appliances. It is my opinion, and as such may contradict the trend towards making DPDK a library, rather than a development kit.
>
> > DPDK build configuration - future enhancements
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > There are multiple requests (sometimes controversial) for new abilities
> > to add into DPDK build system.
> > In particular, request from few different teams:
> > - add ability to enable/disable individual apps/libs
> > - override some build settings for specific libs/drivers
>
> My wish list, in prioritized order:
>
> 1. The ability to remove features to reduce complexity - and thus the likelihood of bugs!
>
> Remember to consider this in application context.
>
> Background: Our previous firmware used the Linux kernel, and some loadable modules. We ran into a lot of extremely rare and unexpected cases where the Linux kernel network stack did something completely unusual, and our firmware needed to consider all these exceptional cases. This is one of the key reasons we switched to DPDK - the fast path libraries are clean and simple, and don't do anything we didn't ask them to do.
>
> DPDK example: If support for segmented packets are considered "required" by DPDK libraries and drivers, is it also required for applications to support segmented packet? If the application doesn’t need segmented packets, can it safely assume that no DPDK libraries or drivers create segmented packets under any circumstances? If support for segmented packets is a compile time option, there is an implicit guarantee that they don't appear.
The primary rule in DPDK is that the application remains in control.
If the application does not call the API function for a feature,
it won't be enabled. So no need to remove the unused libraries.
> 2. The ability to remove/tweak features to improve *application* performance in specific environments would be good.
>
> E.g. removing support for multiple mbuf pools would free up an mbuf field (m->pool) for application use.
> So would removing support for segmented packets (m->nb_segs, m->next).
>
> Both of these modifications would also reduce complexity, although they would increase source code complexity in all the libraries and drivers needing to support a multidimensional matrix of features. (I highly doubt that all libraries support the combination of all features today... I remember having to argue strongly for the DPDK eBPF library to support reading data inside segmented packets.)
Because code must remain simple, the mbuf layout is fixed
(except dynamic fields).
> 3. Removing cruft that has no effect on performance or similar, is "nice to have".
>
> E.g. drivers for hardware that we do not use.
>
> > As a first step to move forward - produce design doc of current build
> > system.
> > Discuss further enhancements based on that doc.
>
> > While planning changes to the build system backward compatibility
> > with 20.11 should be considered.
>
> Backward compatibility is not a high priority for us. It is an extremely rare event for us to upgrade to a new version of any external software (Linux Kernel, DPDK and other libraries) or build tools, because we consider switching any of it to another version high effort (e.g. it requires extensive testing). In this perspective, having to change some details in the build system is a relatively small effort.
>
> With this said, the documentation of each DPDK release should include a chapter describing what an application developer should do different than with the previous release. E.g. the Release Note enumerates the key modifications as bullet points, but it is not always obvious how that affects an application being developed. (DPDK generally has great documentation, but is somewhat lacking in this area.)
>
> I know that ABI Stability is supposed to make much of this go away, but DPDK is clearly not there yet.
>
> > AR to Bruce to create initial version of the DD.
> >
>
> The following may be scope creep, so just consider it me thinking out loud:
>
> Consider a general design documents in the form of a "life of an mbuf" document, describing how mbufs are pre-allocated for driver RX descriptors, and then handed over to the application trough the receive function, and then possibly going through defragmentation and reordering libraries, and then handed over to another driver's transmit function, which uses the mbufs to set up TX descriptors, and after transmission frees the mbufs to their original pool, where they are ultimately allocated again by a driver to refill its RX descriptor pool.
>
> The document can start off with the simple case with a single non-segmented, non-fragmented, in-order packet. And then it can be extended with variations, e.g. adding the description of segmented packets would explain how the m->nb_segs and m->next are being used when the packet is handled by the drivers and libraries.
>
> In the context of being able to enable/disable libraries and features, the purpose of this document would be to help showing interdependencies.
I agree we need this kind of doc.
It could be part of the prog guide.
Feel free to draft a skeleton.
^ permalink raw reply [relevance 0%]
Results 4401-4600 of ~18000 next (older) | prev (newer) | reverse | sort options + mbox downloads above
-- links below jump to the message on this page --
2020-07-03 17:15 [dpdk-dev] [PATCH] doc: add sample for ABI checks in contribution guide Ferruh Yigit
2020-11-27 14:37 4% ` David Marchand
2020-08-10 9:24 [dpdk-dev] [PATCH] doc: clarify abi reference version to use in patches Ray Kinsella
2020-11-27 14:37 4% ` David Marchand
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-20 12:27 [dpdk-dev] [PATCH v1 1/1] build: alias default build as generic Juraj Linkeš
2020-11-24 7:52 3% ` [dpdk-dev] [PATCH v2] " Juraj Linkeš
2020-11-22 13:40 [dpdk-dev] Minutes of Technical Board Meeting, 2020-11-18 Ananyev, Konstantin
2020-11-23 9:30 ` Morten Brørup
2020-11-23 10:00 0% ` [dpdk-dev] [dpdk-techboard] " Thomas Monjalon
2020-11-23 11:16 0% ` Morten Brørup
2020-11-23 13:40 5% [dpdk-dev] [PATCH] doc: announce flow API matching pattern struct changes Ferruh Yigit
2020-11-23 13:50 0% ` Andrew Rybchenko
2020-11-23 14:17 0% ` Ferruh Yigit
2020-11-23 14:25 0% ` Andrew Rybchenko
2020-11-23 15:51 3% ` Ferruh Yigit
2020-11-24 11:43 4% ` Ori Kam
2020-11-24 12:56 3% ` Ferruh Yigit
2020-11-24 13:00 4% ` Andrew Rybchenko
2020-11-24 13:01 0% ` Andrew Rybchenko
2020-11-24 20:40 7% [dpdk-dev] [PATCH v1] doc: update release notes for 20.11 John McNamara
2020-11-24 21:57 4% [dpdk-dev] [PATCH] ci: hook to Github Actions David Marchand
2020-11-25 13:44 0% ` Aaron Conole
2020-11-25 14:31 ` David Marchand
2020-11-26 4:46 ` Honnappa Nagarahalli
2020-11-26 8:06 ` David Marchand
2020-11-26 17:01 ` Honnappa Nagarahalli
2020-12-08 14:08 4% ` David Marchand
2020-12-04 17:36 4% ` [dpdk-dev] [PATCH v2 1/2] ci: hook to GitHub Actions David Marchand
2020-12-04 17:36 20% ` [dpdk-dev] [PATCH v2 2/2] ci: enable v21 ABI checks David Marchand
2020-12-14 14:13 4% ` Aaron Conole
2020-12-11 20:07 3% ` [dpdk-dev] [PATCH v2 1/2] ci: hook to GitHub Actions Ferruh Yigit
2020-12-14 10:44 0% ` Thomas Monjalon
2020-12-14 14:12 0% ` Aaron Conole
2020-11-26 14:25 [dpdk-dev] [PATCH] eal: fix errno on service cores init failure Olivier Matz
2020-11-26 14:46 3% ` Van Haaren, Harry
2020-11-26 16:37 0% ` Olivier Matz
2020-11-26 16:42 0% ` Van Haaren, Harry
2020-11-27 21:37 4% [dpdk-dev] [dpdk-announce] DPDK 20.11 released Thomas Monjalon
2020-11-30 9:23 10% [dpdk-dev] [PATCH] version: 21.02-rc0 David Marchand
2020-12-07 17:32 36% [dpdk-dev] [PATCH 1/1] devtools: adjust verbosity of ABI check Thomas Monjalon
2020-12-08 15:22 9% ` Kinsella, Ray
2020-12-08 15:32 4% ` Thomas Monjalon
2020-12-08 15:31 4% ` David Marchand
2020-12-17 9:05 36% ` [dpdk-dev] [PATCH v2 " Thomas Monjalon
2021-01-13 9:21 4% ` Thomas Monjalon
2020-12-07 17:33 10% [dpdk-dev] [PATCH 1/1] devtools: avoid installing static binaries Thomas Monjalon
2020-12-07 17:47 3% ` Bruce Richardson
2020-12-07 18:12 0% ` Thomas Monjalon
2020-12-08 9:33 0% ` Bruce Richardson
2020-12-08 15:37 4% ` David Marchand
2020-12-08 15:52 5% ` 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-10 10:54 3% [dpdk-dev] DPDK Release Status Meeting 10/12/2020 Ferruh Yigit
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-17 14:05 [dpdk-dev] [PATCH v12 00/11] Add PMD power management Anatoly Burakov
2020-11-02 11:09 ` [dpdk-dev] [PATCH v11 0/6] Add PMD power mgmt Liang Ma
2020-12-17 14:05 2% ` [dpdk-dev] [PATCH v12 01/11] eal: uninline power intrinsics 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 3% ` [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-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 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-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-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-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-01 20:39 4% ` Maxime Coquelin
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).