Re: [dpdk-dev] [RFC PATCH] config: remap flags used for Arm platforms
On Fri, Aug 14, 2020 at 02:03:20PM +0800, Ruifeng Wang wrote: > Flags are used to distinguish different platform architectures. > These flags can be used to pick different code paths for different > architectures at compile time. > For Arm platforms, there are 3 flags in use: RTE_ARCH_ARM, > RTE_ARCH_ARMv7 and RTE_ARCH_ARM64. > RTE_ARCH_ARM64 is used to flag 64-bit aarch64 platforms, > while RTE_ARCH_ARM & RTE_ARCH_ARMv7 are used to flag 32-bit platforms. > RTE_ARCH_ARMv7 is for ARMv7 platforms as its name suggested. > > The issue is that flag name RTE_ARCH_ARM is unclear and could cause > confusion. No info about platform word length is included in the name. > To make the flag names more clear, a naming scheme is proposed. > > RTE_ARCH_ARM > | > +RTE_ARCH_ARM32 > || > |+RTE_ARCH_ARMv7 > || > |+RTE_ARCH_ARMv8_AARCH32 > | > +RTE_ARCH_ARM64 > > RTE_ARCH_ARM32 will be used for 32-bit Arm platforms. > It includes RTE_ARCH_ARMv7 and RTE_ARCH_ARMv8_AARCH32. > RTE_ARCH_ARMv7 is for ARMv7 platforms. > RTE_ARCH_ARMv8_AARCH32 is for aarch32 state on aarch64 platforms. > RTE_ARCH_ARM64 is for 64-bit Arm platforms. > RTE_ARCH_ARM will be used for all Arm platforms, including RTE_ARCH_ARM32 > and RTE_ARCH_ARM64. > > To fit into the new naming scheme, current usage of RTE_ARCH_ARM in > project code is mapped to RTE_ARCH_ARM32. > > Suggested-by: Honnappa Nagarahalli > Signed-off-by: Ruifeng Wang > Reviewed-by: Phil Yang > --- Just to note that for all architectures there is the RTE_ARCH_64 define which is set if the system is 64-bit. That could be used instead if you didn't want to have to specially define ARM32 and ARM64 macros. /Bruce
Re: [dpdk-dev] [RFC PATCH] config: remap flags used for Arm platforms
> -Original Message- > From: Bruce Richardson > Sent: Friday, August 14, 2020 4:13 PM > To: Ruifeng Wang > Cc: hemant.agra...@nxp.com; jer...@marvell.com; > vikto...@rehivetech.com; dev@dpdk.org; Honnappa Nagarahalli > ; Phil Yang ; nd > > Subject: Re: [dpdk-dev] [RFC PATCH] config: remap flags used for Arm > platforms > > On Fri, Aug 14, 2020 at 02:03:20PM +0800, Ruifeng Wang wrote: > > Flags are used to distinguish different platform architectures. > > These flags can be used to pick different code paths for different > > architectures at compile time. > > For Arm platforms, there are 3 flags in use: RTE_ARCH_ARM, > > RTE_ARCH_ARMv7 and RTE_ARCH_ARM64. > > RTE_ARCH_ARM64 is used to flag 64-bit aarch64 platforms, while > > RTE_ARCH_ARM & RTE_ARCH_ARMv7 are used to flag 32-bit platforms. > > RTE_ARCH_ARMv7 is for ARMv7 platforms as its name suggested. > > > > The issue is that flag name RTE_ARCH_ARM is unclear and could cause > > confusion. No info about platform word length is included in the name. > > To make the flag names more clear, a naming scheme is proposed. > > > > RTE_ARCH_ARM > > | > > +RTE_ARCH_ARM32 > > || > > |+RTE_ARCH_ARMv7 > > || > > |+RTE_ARCH_ARMv8_AARCH32 > > | > > +RTE_ARCH_ARM64 > > > > RTE_ARCH_ARM32 will be used for 32-bit Arm platforms. > > It includes RTE_ARCH_ARMv7 and RTE_ARCH_ARMv8_AARCH32. > > RTE_ARCH_ARMv7 is for ARMv7 platforms. > > RTE_ARCH_ARMv8_AARCH32 is for aarch32 state on aarch64 platforms. > > RTE_ARCH_ARM64 is for 64-bit Arm platforms. > > RTE_ARCH_ARM will be used for all Arm platforms, including > > RTE_ARCH_ARM32 and RTE_ARCH_ARM64. > > > > To fit into the new naming scheme, current usage of RTE_ARCH_ARM in > > project code is mapped to RTE_ARCH_ARM32. > > > > Suggested-by: Honnappa Nagarahalli > > Signed-off-by: Ruifeng Wang > > Reviewed-by: Phil Yang > > --- > Just to note that for all architectures there is the RTE_ARCH_64 define which > is set if the system is 64-bit. That could be used instead if you didn't want > to > have to specially define ARM32 and ARM64 macros. > Yes. Thanks for the note. RTE_ARCH_ARM64 is used in architecture specific cases. For example, when a processing path is not implemented by some of 64-bit architectures, RTE_ARCH_64 is not sufficient. > /Bruce
[dpdk-dev] [PATCH] cryptodev: revert ABI compatibility for ChaCha20-Poly1305
This reverts commit a0f0de06d457753c94688d551a6e8659b4d4e041 as the
rte_cryptodev_info_get function versioning was a temporary solution
to maintain ABI compatibility for ChaCha20-Poly1305 and is not
needed in 20.11.
Fixes: a0f0de06d457 ("cryptodev: fix ABI compatibility for ChaCha20-Poly1305")
Signed-off-by: Adam Dybkowski
Reviewed-by: Arek Kusztal
---
lib/librte_cryptodev/meson.build | 1 -
lib/librte_cryptodev/rte_cryptodev.c | 147 +-
lib/librte_cryptodev/rte_cryptodev.h | 34 +---
.../rte_cryptodev_version.map | 6 -
4 files changed, 6 insertions(+), 182 deletions(-)
diff --git a/lib/librte_cryptodev/meson.build b/lib/librte_cryptodev/meson.build
index df1144058..c4c6b3b6a 100644
--- a/lib/librte_cryptodev/meson.build
+++ b/lib/librte_cryptodev/meson.build
@@ -1,7 +1,6 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017-2019 Intel Corporation
-use_function_versioning = true
sources = files('rte_cryptodev.c', 'rte_cryptodev_pmd.c',
'cryptodev_trace_points.c')
headers = files('rte_cryptodev.h',
'rte_cryptodev_pmd.h',
diff --git a/lib/librte_cryptodev/rte_cryptodev.c
b/lib/librte_cryptodev/rte_cryptodev.c
index 1dd795bcb..6c9a19f25 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -36,8 +36,6 @@
#include
#include
#include
-#include
-#include
#include "rte_crypto.h"
#include "rte_cryptodev.h"
@@ -59,14 +57,6 @@ static struct rte_cryptodev_global cryptodev_globals = {
/* spinlock for crypto device callbacks */
static rte_spinlock_t rte_cryptodev_cb_lock = RTE_SPINLOCK_INITIALIZER;
-static const struct rte_cryptodev_capabilities
- cryptodev_undefined_capabilities[] = {
- RTE_CRYPTODEV_END_OF_CAPABILITIES_LIST()
-};
-
-static struct rte_cryptodev_capabilities
- *capability_copy[RTE_CRYPTO_MAX_DEVS];
-static uint8_t is_capability_checked[RTE_CRYPTO_MAX_DEVS];
/**
* The user application callback description.
@@ -291,43 +281,8 @@ rte_crypto_auth_operation_strings[] = {
[RTE_CRYPTO_AUTH_OP_GENERATE] = "generate"
};
-const struct rte_cryptodev_symmetric_capability __vsym *
-rte_cryptodev_sym_capability_get_v20(uint8_t dev_id,
- const struct rte_cryptodev_sym_capability_idx *idx)
-{
- const struct rte_cryptodev_capabilities *capability;
- struct rte_cryptodev_info dev_info;
- int i = 0;
-
- rte_cryptodev_info_get_v20(dev_id, &dev_info);
-
- while ((capability = &dev_info.capabilities[i++])->op !=
- RTE_CRYPTO_OP_TYPE_UNDEFINED) {
- if (capability->op != RTE_CRYPTO_OP_TYPE_SYMMETRIC)
- continue;
-
- if (capability->sym.xform_type != idx->type)
- continue;
-
- if (idx->type == RTE_CRYPTO_SYM_XFORM_AUTH &&
- capability->sym.auth.algo == idx->algo.auth)
- return &capability->sym;
-
- if (idx->type == RTE_CRYPTO_SYM_XFORM_CIPHER &&
- capability->sym.cipher.algo == idx->algo.cipher)
- return &capability->sym;
-
- if (idx->type == RTE_CRYPTO_SYM_XFORM_AEAD &&
- capability->sym.aead.algo == idx->algo.aead)
- return &capability->sym;
- }
-
- return NULL;
-}
-VERSION_SYMBOL(rte_cryptodev_sym_capability_get, _v20, 20.0);
-
-const struct rte_cryptodev_symmetric_capability __vsym *
-rte_cryptodev_sym_capability_get_v21(uint8_t dev_id,
+const struct rte_cryptodev_symmetric_capability *
+rte_cryptodev_sym_capability_get(uint8_t dev_id,
const struct rte_cryptodev_sym_capability_idx *idx)
{
const struct rte_cryptodev_capabilities *capability;
@@ -358,12 +313,8 @@ rte_cryptodev_sym_capability_get_v21(uint8_t dev_id,
}
return NULL;
+
}
-MAP_STATIC_SYMBOL(const struct rte_cryptodev_symmetric_capability *
- rte_cryptodev_sym_capability_get(uint8_t dev_id,
- const struct rte_cryptodev_sym_capability_idx *idx),
- rte_cryptodev_sym_capability_get_v21);
-BIND_DEFAULT_SYMBOL(rte_cryptodev_sym_capability_get, _v21, 21);
static int
param_range_check(uint16_t size, const struct rte_crypto_param_range *range)
@@ -1085,12 +1036,6 @@ rte_cryptodev_close(uint8_t dev_id)
retval = (*dev->dev_ops->dev_close)(dev);
rte_cryptodev_trace_close(dev_id, retval);
- if (capability_copy[dev_id]) {
- free(capability_copy[dev_id]);
- capability_copy[dev_id] = NULL;
- }
- is_capability_checked[dev_id] = 0;
-
if (retval < 0)
return retval;
@@ -1233,61 +1178,9 @@ rte_cryptodev_stats_reset(uint8_t dev_id)
(*dev->dev_ops->stats_reset)(dev);
}
-static void
-get_v20_capabilities(uint8_t dev_id, struct rte_cryptodev_info *dev_inf
Re: [dpdk-dev] [RFC PATCH] config: remap flags used for Arm platforms
On Fri, Aug 14, 2020 at 09:05:23AM +, Ruifeng Wang wrote: > > > -Original Message- > > From: Bruce Richardson > > Sent: Friday, August 14, 2020 4:13 PM > > To: Ruifeng Wang > > Cc: hemant.agra...@nxp.com; jer...@marvell.com; > > vikto...@rehivetech.com; dev@dpdk.org; Honnappa Nagarahalli > > ; Phil Yang ; nd > > > > Subject: Re: [dpdk-dev] [RFC PATCH] config: remap flags used for Arm > > platforms > > > > On Fri, Aug 14, 2020 at 02:03:20PM +0800, Ruifeng Wang wrote: > > > Flags are used to distinguish different platform architectures. > > > These flags can be used to pick different code paths for different > > > architectures at compile time. > > > For Arm platforms, there are 3 flags in use: RTE_ARCH_ARM, > > > RTE_ARCH_ARMv7 and RTE_ARCH_ARM64. > > > RTE_ARCH_ARM64 is used to flag 64-bit aarch64 platforms, while > > > RTE_ARCH_ARM & RTE_ARCH_ARMv7 are used to flag 32-bit platforms. > > > RTE_ARCH_ARMv7 is for ARMv7 platforms as its name suggested. > > > > > > The issue is that flag name RTE_ARCH_ARM is unclear and could cause > > > confusion. No info about platform word length is included in the name. > > > To make the flag names more clear, a naming scheme is proposed. > > > > > > RTE_ARCH_ARM > > > | > > > +RTE_ARCH_ARM32 > > > || > > > |+RTE_ARCH_ARMv7 > > > || > > > |+RTE_ARCH_ARMv8_AARCH32 > > > | > > > +RTE_ARCH_ARM64 > > > > > > RTE_ARCH_ARM32 will be used for 32-bit Arm platforms. > > > It includes RTE_ARCH_ARMv7 and RTE_ARCH_ARMv8_AARCH32. > > > RTE_ARCH_ARMv7 is for ARMv7 platforms. > > > RTE_ARCH_ARMv8_AARCH32 is for aarch32 state on aarch64 platforms. > > > RTE_ARCH_ARM64 is for 64-bit Arm platforms. > > > RTE_ARCH_ARM will be used for all Arm platforms, including > > > RTE_ARCH_ARM32 and RTE_ARCH_ARM64. > > > > > > To fit into the new naming scheme, current usage of RTE_ARCH_ARM in > > > project code is mapped to RTE_ARCH_ARM32. > > > > > > Suggested-by: Honnappa Nagarahalli > > > Signed-off-by: Ruifeng Wang > > > Reviewed-by: Phil Yang > > > --- > > Just to note that for all architectures there is the RTE_ARCH_64 define > > which > > is set if the system is 64-bit. That could be used instead if you didn't > > want to > > have to specially define ARM32 and ARM64 macros. > > > Yes. Thanks for the note. > RTE_ARCH_ARM64 is used in architecture specific cases. For example, when a > processing > path is not implemented by some of 64-bit architectures, RTE_ARCH_64 is not > sufficient. > Yes, but is RTE_ARCH_ARM64 not identical to RTE_ARCH_ARM && RTE_ARCH_64?
[dpdk-dev] [Bug 526] ixgbe: X550 flow type ETH / VLAN / RAW not supported
https://bugs.dpdk.org/show_bug.cgi?id=526
Bug ID: 526
Summary: ixgbe: X550 flow type ETH / VLAN / RAW not supported
Product: DPDK
Version: 20.05
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: ethdev
Assignee: dev@dpdk.org
Reporter: pawel...@gmail.com
Target Milestone: ---
While trying to add ETH / VLAN it works OK. But when trying ETH / VLAN / RAW
with RAW item & mask:
struct rte_flow_item_raw raw = {};
raw.relative = 0;
raw.search = 0;
raw.reserved = 0;
raw.offset = off;
raw.limit = 0;
raw.length = 2;
raw.pattern = (uint8_t *)&raw_pattern;
struct rte_flow_item_raw raw_mask = {};
raw_mask.relative = 1;
raw_mask.search = 1;
raw_mask.reserved = 0;
raw_mask.offset = 0x;
raw_mask.limit = 0x;
raw_mask.length = 0x;
uint16_t raw_mask_pattern = 0x;
raw_mask.pattern = (uint8_t *)&raw_mask_pattern;
item->type = RTE_FLOW_ITEM_TYPE_RAW;
item->spec = (void *)&raw;
item->mask = (void *)&raw_mask;
It returns: EINVAL: "Not supported by fdir filter"
This NIC (and others from ixgbe) support FLEX bytes so it should be considered
as a bug.
I can't test DPDK version > 20.05 but since fdir code is quite the same I think
it is presen in master branch as well.
--
You are receiving this mail because:
You are the assignee for the bug.
[dpdk-dev] [RFC v1 0/2] Add device emulation support in DPDK
This series enables DPDK to be an alternative I/O device emulation library of building virtualized devices in separate processes outside QEMU. It introduces a new library (librte_vfio_user), a new device class (emudev) and one pilot device provider (avf_emudev) with its backend of Ethdev PMD (avfbe_ethdev). *librte_vfio_user* is a server implementation of VFIO-over-socket[1] (also known as vfio-user) which is a protocol that allows a device to be virtualized in a separate process outside of QEMU. *emudev* is a device type for emulated devices. It is up to device provider to choose the transport. In avf_emudev case, it uses vfio-user as transport communicate with its client (e.g., QEMU). *avf_emudev* is the emudev provider of AVF which is a device specification for Intel Virtual Function cross generation. It’s implemented by an AVF emudev driver which offers a few APIs for avfbe_ethdev or app logic to operate. *avfbe_ethdev* is a normal ethdev PMD to supply the basic I/O as backend data path of avf_emudev. One simple usage of avfbe_ethdev could be a para-virtualized backend connected with network application logic. Background & Motivation --- In order to reduce the attack surface, QEMU community is disaggregating QEMU by removing part of device emulation from it. The disaggregated/multi-process QEMU is using VFIO-over-socket/vfio-user as the main transport mechanism to disaggregate I/O services from QEMU[2]. Vfio-user essentially implements the VFIO device model presented to the user process by a set of messages over a unix-domain socket. The main difference between application using vfio-user and application using vfio kernel module is that device manipulation is based on socket messages for vfio-user but system calls for vfio kernel module. The vfio-user devices consist of a generic VFIO device type, living in QEMU, which is called the client[3], and the core device implementation (emulated device), living outside of QEMU, which is called the server. With the introduction and support of vfio-user in QEMU, QEMU is explicitly adding support for external emulated device and data path. We are trying to leverage that and introducing vfio-user support in DPDK. By doing so, DPDK is enabled to be an alternative I/O device emulation library of building virtualized devices along with high-performance data path in separate processes outside QEMU. It will be easy for hardware vendors to provide virtualized solutions of their hardware devices by implementing emulated device in DPDK. Except for vfio-user introduced in DPDK, this series also introduces the first emulated device implementation. That is emulated AVF device (avf_emudev) implemented by AVF emulation driver (avf_emudev driver). Emulated AVF device demos how emulated device could be implemented in DPDK. SPDK is also investigating to implement use case for NVMe. Design overview --- +--+ | +---+ +---+ | | | avf_emudev | | avfbe_ethdev | | | |driver | | driver| | | +---+ +---+ | | | | | | --- VDEV BUS | | | | | | +---+ +--+ | +--+| | vdev: | | vdev:| | | +--+ || | /path/to/vfio | | avf_emudev_# | | | | Generic | || +---+ +--+ | | | vfio-dev | || | | | +--+ || | | | +--+ || +--+| | | vfio-user| || | vfio-user|| | | client | |<---|->| server || | +--+ || +--+| | QEMU || DPDK | +--++--+ - vfio-user. Vfio-user in DPDK is referred to the vfio-user protocol implementation playing server role. It provides transport between emulated device and generic VFIO device in QEMU. Emulated device in DPDK and generic VFIO device in QEMU are working together to present VFIO device model to VM. This series introduces vfio-user implementation as a library called librte_vfio_user which is under lib/librte_vfio_user. - vdev:/path/to/vfio. It defines the emudev device and binds to vdev bus driver. The emudev de
[dpdk-dev] [RFC v1 2/2] emudev: Add library for emulated device
To enable DPDK to be an alternative I/O device emulation library
of building virtualized devices in separate processes outside QEMU,
a new device class named emudev is introduced in this patch. Emudev
is a device type for emulated devices. Providers, which are specific
emudev drivers, could choose the transport to QEMU. An option of
tranport could be vfio-over-socket (also called vfio-user), which is
defined by a standard protocol in QEMU.
Signed-off-by: Chenbo Xia
Signed-off-by: Xiuchun Lu
---
lib/librte_emudev/rte_emudev.h | 315 +
1 file changed, 315 insertions(+)
create mode 100644 lib/librte_emudev/rte_emudev.h
diff --git a/lib/librte_emudev/rte_emudev.h b/lib/librte_emudev/rte_emudev.h
new file mode 100644
index 0..2ffc4dbe0
--- /dev/null
+++ b/lib/librte_emudev/rte_emudev.h
@@ -0,0 +1,315 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2020 Intel Corporation
+ */
+
+#ifndef _RTE_EMUDEV_H_
+#define _RTE_EMUDEV_H_
+
+#include
+#include
+#include
+
+typedef void *rte_emudev_conf_t;
+typedef void *rte_emudev_attr_t;
+typedef void *rte_emudev_mem_table_t;
+typedef char *emu_dev_type_t;
+
+struct rte_emu_dev;
+
+struct emu_dev_info {
+ emu_dev_type_t dev_type;
+ uint32_t max_qp_num;
+ uint32_t max_event_num;
+};
+
+struct emu_dev_q_info {
+ uint64_t base;
+ uint64_t size;
+ uint32_t doorbell_id;
+ uint32_t irq_vector;
+ void *priv;
+};
+
+struct emu_dev_irq_info {
+ uint32_t vector;
+ int fd;
+ void *priv;
+};
+
+struct emu_dev_db_info {
+ uint32_t id;
+ uint32_t flag;
+#define EMU_DEV_DB_FD (0x1 << 0)
+#define EMU_DEV_DB_MEM (0x1 << 1)
+ union {
+ int fd;
+ struct {
+ uint64_t base;
+ uint64_t size;
+ } mem;
+ } data;
+ void *priv;
+};
+
+/**
+ * Back-end driver and emualated device provider should have
+ * the same definiton of events and events message.
+ */
+struct emu_dev_event_channel {
+ int fd;
+ struct rte_ring *queue;
+};
+
+struct emu_dev_attr_info {
+ const char *attr_name;
+ rte_emudev_attr_t attr;
+};
+
+struct emu_dev_ops {
+ int (*dev_start)(struct rte_emu_dev *dev);
+ void (*dev_stop)(struct rte_emu_dev *dev);
+ int (*dev_configure)(struct rte_emu_dev *dev,
+ rte_emudev_conf_t dev_conf);
+ int (*dev_close)(struct rte_emu_dev *dev);
+ struct emu_dev_info *(*get_dev_info)(struct rte_emu_dev *dev);
+ int (*subscribe_event)(struct rte_emu_dev *dev,
+ const struct emu_dev_event_channel *ev_chnl);
+ int (*unsubscribe_event)(struct rte_emu_dev *dev,
+ const struct emu_dev_event_channel *ev_chnl);
+ rte_emudev_mem_table_t (*get_mem_table)(struct rte_emu_dev *dev);
+ struct emu_dev_q_info *(*get_queue_info)(struct rte_emu_dev *dev,
+ uint32_t queue);
+ struct emu_dev_irq_info *(*get_irq_info)(struct rte_emu_dev *dev,
+ uint32_t vector);
+ struct emu_dev_db_info *(*get_db_info)(struct rte_emu_dev *dev,
+ uint32_t doorbell);
+ rte_emudev_attr_t (*get_attr)(struct rte_emu_dev *dev,
+ const char *attr_name);
+ int (*set_attr)(struct rte_emu_dev *dev, const char *attr_name,
+ rte_emudev_attr_t attr);
+ int (*region_map)(struct rte_emu_dev *dev, const char *region_name,
+ uint16_t region_size, uint64_t *base_addr);
+};
+
+struct rte_emu_dev {
+ struct rte_device *device;
+ const struct emu_dev_ops *dev_ops;
+ const struct emu_dev_event_channel *ev_chnl;
+ struct emu_dev_info *dev_info;
+ uint16_t num_attr;
+ struct emu_dev_attr_info **attr;
+ void *priv_data;
+} __rte_cache_aligned;
+
+/**
+ * Note that 'rte_emu_dev_allocate','rte_emu_dev_release' and
+ * 'rte_emu_dev_allocated' should be called by emulated device
+ * provider.
+ * /
+
+/**
+ * Allocate a new emudev for an emulation device and retures the pointer
+ * to the emudev.
+ *
+ * @param name
+ * Name of the emudev
+ * @return
+ * Pointer to rte_emu_dev on success, NULL on failure
+ */
+struct rte_emu_dev *
+rte_emu_dev_allocate(const char *name);
+
+/**
+ * Release the emudev.
+ *
+ * @param dev
+ * The emulated device
+ * @return
+ * 0 on success, -1 on failure
+ */
+int
+rte_emu_dev_release(struct rte_emu_dev *dev);
+
+/**
+ * Find an emudev using name.
+ *
+ * @param name
+ * Name of the emudev
+ * @return
+ * Pointer to rte_emu_dev on success, NULL on failure
+ */
+struct rte_emu_dev *
+rte_emu_dev_allocated(const char *name);
+
+/**
+ * Start an emulation device.
+ *
+ * @param dev_id
+ * Device ID of emudev
+ * @return
+ * 0 on success, -1 on failure
+ */
+int rte_emu_dev_start(uint16_t dev_id);
+
+/**
+ * Stop an emulation device.
+ *
+ * @param dev_id
+ * Device ID of emudev
+ */
+void rte_emu_dev_stop(uint16_t dev
[dpdk-dev] [RFC v1 1/2] vfio_user: Add library for vfio over socket
Vfio-over-socket, also named as vfio-user, is a protocol for
emulating devices in a separate process outside of QEMU. The
main difference between APP using vfio-user and vfio kernel
module is that device manipulation is based on socket messages
for vfio-user but system calls for vfio kernel module.
This protocol has a server/client model and for now QEMU plays
the role of client. This patch implements vfio-user server of the
protocol in DPDK.
Signed-off-by: Chenbo Xia
Signed-off-by: Xiuchun Lu
---
lib/librte_vfio_user/rte_vfio_user.h | 335 +++
1 file changed, 335 insertions(+)
create mode 100644 lib/librte_vfio_user/rte_vfio_user.h
diff --git a/lib/librte_vfio_user/rte_vfio_user.h
b/lib/librte_vfio_user/rte_vfio_user.h
new file mode 100644
index 0..d36516084
--- /dev/null
+++ b/lib/librte_vfio_user/rte_vfio_user.h
@@ -0,0 +1,335 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2020 Intel Corporation
+ */
+
+#ifndef _VFIO_USER_H
+#define _VFIO_USER_H
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define VFIO_USER_MSG_MAX_NREGIONS 8
+#define VFIO_USER_MAX_MEM_REGIONS 256
+#define VFIO_MAX_RW_DATA 256
+#define VFIO_USER_MAX_FD 64
+#define VFIO_USER_IRQ_MAX_DATA 64
+#define VFIO_USER_MAX_IRQ_FD 64
+
+typedef enum VFIO_USER_CMD_TYPE {
+ VFIO_USER_NONE = 0,
+ VFIO_USER_VERSION = 1,
+ VFIO_USER_DMA_MAP = 2,
+ VFIO_USER_DMA_UNMAP = 3,
+ VFIO_USER_DEVICE_GET_INFO = 4,
+ VFIO_USER_DEVICE_GET_REGION_INFO = 5,
+ VFIO_USER_DEVICE_GET_IRQ_INFO = 6,
+ VFIO_USER_DEVICE_SET_IRQS = 7,
+ VFIO_USER_REGION_READ = 8,
+ VFIO_USER_REGION_WRITE = 9,
+ VFIO_USER_DMA_READ = 10,
+ VFIO_USER_DMA_WRITE = 11,
+ VFIO_USER_VM_INTERRUPT = 12,
+ VFIO_USER_DEVICE_RESET = 13,
+ VFIO_USER_MAX = 14,
+} VFIO_USER_CMD_TYPE;
+
+struct vfio_user_mem_reg {
+ uint64_t gpa;
+ uint64_t size;
+ uint64_t fd_offset;
+ uint32_t protection;/* attributes in */
+#define VFIO_USER_MEM_MAPPABLE (0x1 << 0)
+ uint32_t flags;
+};
+
+struct vfio_user_dev_info {
+ uint32_t argsz; /* Reserved in vfio-user */
+ uint32_t flags;
+ uint32_t num_regions;
+ uint32_t num_irqs;
+};
+
+struct vfio_user_reg_rw {
+ uint64_t reg_offset;
+ uint32_t reg_idx;
+ uint32_t size;
+ char data[VFIO_MAX_RW_DATA];
+};
+
+struct vfio_user_dma_rw {
+ uint64_t addr;
+ uint32_t size;
+ char data[VFIO_MAX_RW_DATA];
+};
+
+struct vfio_user_intr {
+ uint32_t type;
+ uint32_t vector;
+};
+
+typedef struct vfio_user_msg {
+ uint16_t dev_id;
+ uint16_t msg_id;
+ uint32_t cmd;
+ uint32_t size;
+#define VFIO_USER_REPLY_MASK (0x1 << 0)
+#define VFIO_USER_NEED_NO_RP (0x1 << 1)
+ uint32_t flags;
+ union {
+ struct vfio_user_mem_reg memory[VFIO_USER_MSG_MAX_NREGIONS];
+ struct vfio_user_dev_info dev_info;
+ struct vfio_region_info reg_info;
+ struct vfio_irq_info irq_info;
+ struct vfio_irq_set irq_set;
+ struct vfio_user_reg_rw reg_rw;
+ struct vfio_user_dma_rw dma_rw;
+ struct vfio_user_intr intr;
+ } payload;
+ int fds[VFIO_USER_MAX_FD];
+ int fd_num;
+} __attribute((packed)) VFIO_USER_MSG;
+
+#define VFIO_USER_MSG_HDR_SIZE offsetof(VFIO_USER_MSG, payload.dev_info)
+
+enum vfio_user_msg_handle_result {
+ VFIO_USER_MSG_HANDLE_ERR = -1,
+ VFIO_USER_MSG_HANDLE_OK = 0,
+ VFIO_USER_MSG_HANDLE_REPLY = 1,
+};
+
+struct vfio_user_mem_table_entry {
+ struct vfio_user_mem_reg region;
+ uint64_t host_user_addr;
+ void *mmap_addr;
+ uint64_t mmap_size;
+ int fd;
+};
+
+struct vfio_user_mem {
+ uint32_t entry_num;
+ struct vfio_user_mem_table_entry entry[VFIO_USER_MAX_MEM_REGIONS];
+};
+
+struct vfio_user_regions {
+ uint32_t reg_num;
+ struct vfio_region_info **reg_info;
+};
+
+struct vfio_user_irq_info {
+ uint32_t irq_num;
+ struct vfio_irq_info *irq_info;
+};
+
+struct vfio_user_irq_set {
+ uint32_t set_num;
+ struct vfio_irq_set **irq;
+ int fds[VFIO_USER_MAX_IRQ_FD];
+};
+
+struct vfio_user_irqs {
+ struct vfio_user_irq_info *info;
+ struct vfio_user_irq_set *set;
+};
+
+struct vfio_user_region_resource {
+ void *base;
+ uint32_t size;
+ int fd;
+};
+
+struct vfio_user_resource {
+ uint16_t resource_num;
+ struct vfio_user_region_resource res[];
+};
+
+struct vfio_user {
+ int dev_id;
+ int is_ready;
+#define IF_NAME_SZ (IFNAMSIZ > PATH_MAX ? IFNAMSIZ : PATH_MAX)
+ char sock_addr[IF_NAME_SZ];
+ const struct vfio_user_notify_ops *ops;
+ struct vfio_user_mem *mem;
+ struct vfio_user_dev_info *dev_info;
+ struct vfio_user_regions *reg;
+ struct vfio_user_irqs *irq;
+
Re: [dpdk-dev] [PATCH 20.11 01/19] examples: remove legacy sections of makefiles
On Fri, Aug 07, 2020 at 01:29:51PM +0100, Ciara Power wrote: > The example app makefiles contained sections using the legacy method of > compiling with make. These are no longer needed, and are removed, > leaving only the section that uses pkg-config for the make build. > > Signed-off-by: Ciara Power > --- > examples/bbdev_app/Makefile | 23 ++- > examples/vmdq/Makefile | 23 ++- > examples/vmdq_dcb/Makefile | 31 ++-- > 43 files changed, 129 insertions(+), 1078 deletions(-) > > diff --git a/examples/bbdev_app/Makefile b/examples/bbdev_app/Makefile > index 3c8eb75a4e..9675c6d096 100644 > --- a/examples/bbdev_app/Makefile > +++ b/examples/bbdev_app/Makefile > @@ -8,7 +8,9 @@ APP = bbdev > SRCS-y := main.c > > # Build using pkg-config variables if possible > -ifeq ($(shell pkg-config --exists libdpdk && echo 0),0) > +ifneq ($(shell pkg-config --exists libdpdk && echo 0),0) > + $(error "no installation of DPDK found") > +endif > Unfortunately make is whitespace sensitive, so you can't indent here without getting a syntax error in the case that dpdk is not installed. Instead of the error message you get e.g.: Makefile:12: *** recipe commences before first target. Stop. This applies to all makefiles in this patch, I think. /Bruce
[dpdk-dev] [PATCH v7 0/5] aarch64 -> aarch32 cross compilation support
Add support for aarch32 cross build in meson and add aarch64 -> aarch32 cross build to Travis. Aarch32 is an execution state that allows execution of 32-bit code on armv8 machines. This execution state contains a superset of previous armv7 32-bit instructions and features. Thus the aarch32 build is distinct from arvm7 build. Tested here: [v6] https://travis-ci.com/github/jlinkes/dpdk/builds/179252628 [v7] https://travis-ci.com/github/jlinkes/dpdk/builds/179723067 v4: Removed disabled drivers which actually build on arm32. Also tested the patchset with series 9609 which fixes underlying failures. v5: Changed the condition for running test-null.sh in ci. Re-uploaded after underlying fixes have been committed. v6: Changed the condition for running test-null.sh again. Reworked the patch to do aarch32 build instead of arvm7-a build. Simplified meson build flags. Changed commit msgs. Added 32b qualifier to .travis.yml. Added a patch with fixes for bnxt. Added a patch with cross compilation docs. v7: Rebased the patchset. Juraj Linkeš (3): build: add aarch32 meson build flags build: add aarch32 to meson cross-compilation ci: add aarch64 -> aarch32 cross compiling jobs Phil Yang (1): doc: add aarch32 build guidance Ruifeng Wang (1): net/bnxt: add support for aarch32 .ci/linux-build.sh| 7 - .travis.yml | 19 config/arm/arm32_armv8a_linux_gcc | 17 +++ config/arm/meson.build| 20 +++-- .../linux_gsg/cross_build_dpdk_for_arm64.rst | 30 ++- drivers/net/bnxt/Makefile | 2 +- drivers/net/bnxt/bnxt_rxq.h | 2 +- drivers/net/bnxt/bnxt_rxr.h | 2 +- drivers/net/bnxt/bnxt_txr.h | 2 +- 9 files changed, 87 insertions(+), 14 deletions(-) create mode 100644 config/arm/arm32_armv8a_linux_gcc -- 2.20.1
[dpdk-dev] [PATCH v7 1/5] net/bnxt: add support for aarch32
From: Ruifeng Wang
Expand vector PMD support to aarch32.
Signed-off-by: Ruifeng Wang
---
drivers/net/bnxt/Makefile | 2 +-
drivers/net/bnxt/bnxt_rxq.h | 2 +-
drivers/net/bnxt/bnxt_rxr.h | 2 +-
drivers/net/bnxt/bnxt_txr.h | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/bnxt/Makefile b/drivers/net/bnxt/Makefile
index 0c5b74918..06a47dc49 100644
--- a/drivers/net/bnxt/Makefile
+++ b/drivers/net/bnxt/Makefile
@@ -43,7 +43,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_BNXT_PMD) += rte_pmd_bnxt.c
ifeq ($(CONFIG_RTE_ARCH_X86), y)
SRCS-$(CONFIG_RTE_LIBRTE_BNXT_PMD) += bnxt_rxtx_vec_sse.c
endif
-ifeq ($(CONFIG_RTE_ARCH_ARM64), y)
+ifneq ($(filter y,$(CONFIG_RTE_ARCH_ARM) $(CONFIG_RTE_ARCH_ARM64)),)
SRCS-$(CONFIG_RTE_LIBRTE_BNXT_PMD) += bnxt_rxtx_vec_neon.c
endif
diff --git a/drivers/net/bnxt/bnxt_rxq.h b/drivers/net/bnxt/bnxt_rxq.h
index d5ce3b6d5..1c4027711 100644
--- a/drivers/net/bnxt/bnxt_rxq.h
+++ b/drivers/net/bnxt/bnxt_rxq.h
@@ -22,7 +22,7 @@ struct bnxt_rx_queue {
uint16_tnb_rx_hold; /* num held free RX desc */
uint16_trx_free_thresh; /* max free RX desc to hold */
uint16_tqueue_id; /* RX queue index */
-#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_ARM64)
+#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_ARM64) || defined(RTE_ARCH_ARM)
uint16_trxrearm_nb; /* number of descs to reinit. */
uint16_trxrearm_start; /* next desc index to reinit. */
#endif
diff --git a/drivers/net/bnxt/bnxt_rxr.h b/drivers/net/bnxt/bnxt_rxr.h
index 2bf46cd91..e2fba1647 100644
--- a/drivers/net/bnxt/bnxt_rxr.h
+++ b/drivers/net/bnxt/bnxt_rxr.h
@@ -221,7 +221,7 @@ int bnxt_init_one_rx_ring(struct bnxt_rx_queue *rxq);
int bnxt_rx_queue_start(struct rte_eth_dev *dev, uint16_t rx_queue_id);
int bnxt_rx_queue_stop(struct rte_eth_dev *dev, uint16_t rx_queue_id);
-#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_ARM64)
+#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_ARM64) || defined(RTE_ARCH_ARM)
uint16_t bnxt_recv_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
uint16_t nb_pkts);
int bnxt_rxq_vec_setup(struct bnxt_rx_queue *rxq);
diff --git a/drivers/net/bnxt/bnxt_txr.h b/drivers/net/bnxt/bnxt_txr.h
index 7715c11b8..38e5ac9df 100644
--- a/drivers/net/bnxt/bnxt_txr.h
+++ b/drivers/net/bnxt/bnxt_txr.h
@@ -59,7 +59,7 @@ uint16_t bnxt_xmit_pkts(void *tx_queue, struct rte_mbuf
**tx_pkts,
uint16_t nb_pkts);
uint16_t bnxt_dummy_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
uint16_t nb_pkts);
-#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_ARM64)
+#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_ARM64) || defined(RTE_ARCH_ARM)
uint16_t bnxt_xmit_pkts_vec(void *tx_queue, struct rte_mbuf **tx_pkts,
uint16_t nb_pkts);
#endif
--
2.20.1
[dpdk-dev] [PATCH v7 4/5] ci: add aarch64 -> aarch32 cross compiling jobs
Add two jobs (static and shared libs), both building on aarch64 and producing 32-bit arm binaries executable on armv8-a, but not armv7. Do not run tests in these jobs. Signed-off-by: Juraj Linkeš --- .ci/linux-build.sh | 7 ++- .travis.yml| 19 +++ 2 files changed, 25 insertions(+), 1 deletion(-) diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh index d079801d7..c042b065c 100755 --- a/.ci/linux-build.sh +++ b/.ci/linux-build.sh @@ -33,6 +33,11 @@ if [ "$AARCH64" = "1" ]; then OPTS="$OPTS --cross-file config/arm/arm64_armv8_linux_gcc" fi +if [ "$AARCH32" = "1" ]; then +# convert the arch specifier +OPTS="$OPTS --cross-file config/arm/arm32_armv8a_linux_gcc" +fi + if [ "$BUILD_DOCS" = "1" ]; then OPTS="$OPTS -Denable_docs=true" fi @@ -53,7 +58,7 @@ OPTS="$OPTS --buildtype=debugoptimized" meson build --werror $OPTS ninja -C build -if [ "$AARCH64" != "1" ]; then +if file build/app/dpdk-testpmd | sed 's/-/_/g' | grep -q "$(uname -m)"; then devtools/test-null.sh fi diff --git a/.travis.yml b/.travis.yml index d6eeab371..850faaac1 100644 --- a/.travis.yml +++ b/.travis.yml @@ -18,6 +18,10 @@ _aarch64_packages: &aarch64_packages - *required_packages - [gcc-aarch64-linux-gnu, libc6-dev-arm64-cross, pkg-config-aarch64-linux-gnu] +_arm_32b_packages: &arm_32b_packages + - *required_packages + - [gcc-arm-linux-gnueabihf, libc6-dev-armhf-cross, pkg-config-arm-linux-gnueabihf] + _build_32b_packages: &build_32b_packages - *required_packages - [gcc-multilib] @@ -98,6 +102,21 @@ jobs: packages: - *required_packages - *doc_packages + # aarch64 cross-compiling aarch32 jobs + - env: DEF_LIB="shared" AARCH32=1 +arch: arm64 +compiler: gcc +addons: + apt: +packages: + - *arm_32b_packages + - env: DEF_LIB="static" AARCH32=1 +arch: arm64 +compiler: gcc +addons: + apt: +packages: + - *arm_32b_packages # aarch64 clang jobs - env: DEF_LIB="static" arch: arm64 -- 2.20.1
[dpdk-dev] [PATCH v7 2/5] build: add aarch32 meson build flags
Add aarch32 extra build flags and aarch32 machine flags to generic
machine args.
Also modify how arm flags are updated in meson build - for 32-bit build,
update only if cross-compiling.
Signed-off-by: Juraj Linkeš
---
config/arm/meson.build | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/config/arm/meson.build b/config/arm/meson.build
index 8728051d5..b29f27097 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -63,6 +63,11 @@ flags_armada = [
['RTE_MAX_LCORE', 16]]
flags_default_extra = []
+flags_aarch32_extra = [
+['RTE_ARCH_ARM_NEON_MEMCPY', false],
+['RTE_ARCH_STRICT_ALIGN', true],
+['RTE_EAL_NUMA_AWARE_HUGEPAGES', false],
+['RTE_MAX_LCORE', 256]]
flags_n1sdp_extra = [
['RTE_MACHINE', '"n1sdp"'],
['RTE_MAX_NUMA_NODES', 1],
@@ -90,6 +95,7 @@ flags_octeontx2_extra = [
machine_args_generic = [
['default', ['-march=armv8-a+crc']],
['native', ['-march=native']],
+ ['aarch32', ['-march=armv8-a', '-mfpu=neon'], flags_aarch32_extra],
['0xd03', ['-mcpu=cortex-a53']],
['0xd04', ['-mcpu=cortex-a35']],
['0xd07', ['-mcpu=cortex-a57']],
@@ -129,15 +135,23 @@ impl_0x69 = ['Intel', flags_generic, machine_args_generic]
impl_dpaa = ['NXP DPAA', flags_dpaa, machine_args_generic]
dpdk_conf.set('RTE_FORCE_INTRINSICS', 1)
-
+update_flags = false
if not dpdk_conf.get('RTE_ARCH_64')
dpdk_conf.set('RTE_CACHE_LINE_SIZE', 64)
dpdk_conf.set('RTE_ARCH_ARM', 1)
dpdk_conf.set('RTE_ARCH_ARMv7', 1)
# the minimum architecture supported, armv7-a, needs the following,
# mk/machine/armv7a/rte.vars.mk sets it too
- machine_args += '-mfpu=neon'
+ if meson.is_cross_build()
+ update_flags = true
+ impl_id = meson.get_cross_property('implementor_id', 'aarch32')
+ impl_pn = meson.get_cross_property('implementor_pn', 'default')
+ machine = get_variable('impl_' + impl_id)
+ else
+ machine_args += '-mfpu=neon'
+ endif
else
+ update_flags = true
dpdk_conf.set('RTE_CACHE_LINE_SIZE', 128)
dpdk_conf.set('RTE_ARCH_ARM64', 1)
@@ -172,7 +186,9 @@ else
impl_pn = meson.get_cross_property('implementor_pn', 'default')
machine = get_variable('impl_' + impl_id)
endif
+endif
+if update_flags == true
# Apply Common Defaults. These settings may be overwritten by machine
# settings later.
foreach flag: flags_common_default
--
2.20.1
[dpdk-dev] [PATCH v7 5/5] doc: add aarch32 build guidance
From: Phil Yang Add cross-compiling guidance for 32-bit aarch32 DPDK on aarch64 host. Signed-off-by: Phil Yang --- .../linux_gsg/cross_build_dpdk_for_arm64.rst | 30 ++- 1 file changed, 23 insertions(+), 7 deletions(-) diff --git a/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst b/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst index c5875a6d5..07085e3ea 100644 --- a/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst +++ b/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst @@ -1,15 +1,16 @@ .. SPDX-License-Identifier: BSD-3-Clause Copyright(c) 2018 ARM Corporation. -Cross compile DPDK for ARM64 - -This chapter describes how to cross compile DPDK for ARM64 from x86 build hosts. +Cross compile DPDK for aarch64 and aarch32 +== +This chapter describes how to cross compile DPDK for aarch64 from x86 build hosts and compile +32-bit aarch32 DPDK from aarch64 build hosts. .. note:: - Whilst it is recommended to natively build DPDK on ARM64 (just - like with x86), it is also possible to cross-build DPDK for ARM64. An - ARM64 cross compile GNU toolchain is used for this. + Whilst it is recommended to natively build DPDK on aarch64 (just + like with x86), it is also possible to cross-build DPDK for aarch64. + An aarch64 cross compile GNU toolchain is used for this. Obtain the cross tool chain --- @@ -88,18 +89,33 @@ To install it in Ubuntu:: sudo apt-get install pkg-config-aarch64-linux-gnu +.. note:: + +Some aarch64 platforms support EL0 aarch32 mode, which means the 32-bit aarch32 applications +can run on aarch64. The armhf architecture toolchain ``gcc-arm-linux-gnueabihf`` is required +for aarch32 on aarch64. To install it in Ubuntu:: + + sudo dpkg --add-architecture armhf + sudo apt-get update + sudo apt-get install -y gcc gcc-arm-linux-gnueabihf libc6:armhf make binutils + To cross-compile DPDK on a desired target machine we can use the following command:: meson cross-build --cross-file ninja -C cross-build -For example if the target machine is arm64 we can use the following +For example if the target machine is aarch64 we can use the following command:: meson arm64-build --cross-file config/arm/arm64_armv8_linux_gcc ninja -C arm64-build +If the target machine is aarch32 we can use the following command:: + + meson arm32-build --cross-file config/arm/arm32_armv8a_linux_gcc + ninja -C arm32-build + Configure and Cross Compile DPDK using Make --- To configure a build, choose one of the target configurations, like arm64-dpaa-linux-gcc and arm64-thunderx-linux-gcc. -- 2.20.1
[dpdk-dev] [PATCH v7 3/5] build: add aarch32 to meson cross-compilation
Create meson cross file arm32_armv8a_linux_gcc. Use arm-linux-gnueabihf- toolset which comes with standard packages on most used systems, such as Ubuntu and CentOS. Signed-off-by: Juraj Linkeš --- config/arm/arm32_armv8a_linux_gcc | 17 + 1 file changed, 17 insertions(+) create mode 100644 config/arm/arm32_armv8a_linux_gcc diff --git a/config/arm/arm32_armv8a_linux_gcc b/config/arm/arm32_armv8a_linux_gcc new file mode 100644 index 0..d3c4bce6c --- /dev/null +++ b/config/arm/arm32_armv8a_linux_gcc @@ -0,0 +1,17 @@ +[binaries] +c = 'arm-linux-gnueabihf-gcc' +cpp = 'arm-linux-gnueabihf-cpp' +ar = 'arm-linux-gnueabihf-gcc-ar' +strip = 'arm-linux-gnueabihf-strip' +pkgconfig = 'arm-linux-gnueabihf-pkg-config' +pcap-config = '' + +[host_machine] +system = 'linux' +cpu_family = 'aarch64' +cpu = 'armv8-a' +endian = 'little' + +[properties] +implementor_id = '0x41' +implementor_pn = 'aarch32' -- 2.20.1
[dpdk-dev] [Bug 413] rte_ring: capacity was set incorrectly
https://bugs.dpdk.org/show_bug.cgi?id=413 Bruce Richardson (bruce.richard...@intel.com) changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Bruce Richardson (bruce.richard...@intel.com) --- Closing off this bug as current behaviour is as designed and the requested behaviour is not possible with the current rte_ring architecture. -- You are receiving this mail because: You are the assignee for the bug.
Re: [dpdk-dev] [RFC PATCH] config: remap flags used for Arm platforms
> -Original Message- > From: Bruce Richardson > Sent: Friday, August 14, 2020 6:01 PM > To: Ruifeng Wang > Cc: hemant.agra...@nxp.com; jer...@marvell.com; > vikto...@rehivetech.com; dev@dpdk.org; Honnappa Nagarahalli > ; Phil Yang ; nd > > Subject: Re: [dpdk-dev] [RFC PATCH] config: remap flags used for Arm > platforms > > On Fri, Aug 14, 2020 at 09:05:23AM +, Ruifeng Wang wrote: > > > > > -Original Message- > > > From: Bruce Richardson > > > Sent: Friday, August 14, 2020 4:13 PM > > > To: Ruifeng Wang > > > Cc: hemant.agra...@nxp.com; jer...@marvell.com; > > > vikto...@rehivetech.com; dev@dpdk.org; Honnappa Nagarahalli > > > ; Phil Yang ; nd > > > > > > Subject: Re: [dpdk-dev] [RFC PATCH] config: remap flags used for Arm > > > platforms > > > > > > On Fri, Aug 14, 2020 at 02:03:20PM +0800, Ruifeng Wang wrote: > > > > Flags are used to distinguish different platform architectures. > > > > These flags can be used to pick different code paths for different > > > > architectures at compile time. > > > > For Arm platforms, there are 3 flags in use: RTE_ARCH_ARM, > > > > RTE_ARCH_ARMv7 and RTE_ARCH_ARM64. > > > > RTE_ARCH_ARM64 is used to flag 64-bit aarch64 platforms, while > > > > RTE_ARCH_ARM & RTE_ARCH_ARMv7 are used to flag 32-bit platforms. > > > > RTE_ARCH_ARMv7 is for ARMv7 platforms as its name suggested. > > > > > > > > The issue is that flag name RTE_ARCH_ARM is unclear and could > > > > cause confusion. No info about platform word length is included in the > name. > > > > To make the flag names more clear, a naming scheme is proposed. > > > > > > > > RTE_ARCH_ARM > > > > | > > > > +RTE_ARCH_ARM32 > > > > || > > > > |+RTE_ARCH_ARMv7 > > > > || > > > > |+RTE_ARCH_ARMv8_AARCH32 > > > > | > > > > +RTE_ARCH_ARM64 > > > > > > > > RTE_ARCH_ARM32 will be used for 32-bit Arm platforms. > > > > It includes RTE_ARCH_ARMv7 and RTE_ARCH_ARMv8_AARCH32. > > > > RTE_ARCH_ARMv7 is for ARMv7 platforms. > > > > RTE_ARCH_ARMv8_AARCH32 is for aarch32 state on aarch64 platforms. > > > > RTE_ARCH_ARM64 is for 64-bit Arm platforms. > > > > RTE_ARCH_ARM will be used for all Arm platforms, including > > > > RTE_ARCH_ARM32 and RTE_ARCH_ARM64. > > > > > > > > To fit into the new naming scheme, current usage of RTE_ARCH_ARM > > > > in project code is mapped to RTE_ARCH_ARM32. > > > > > > > > Suggested-by: Honnappa Nagarahalli > > > > Signed-off-by: Ruifeng Wang > > > > Reviewed-by: Phil Yang > > > > --- > > > Just to note that for all architectures there is the RTE_ARCH_64 > > > define which is set if the system is 64-bit. That could be used > > > instead if you didn't want to have to specially define ARM32 and ARM64 > macros. > > > > > Yes. Thanks for the note. > > RTE_ARCH_ARM64 is used in architecture specific cases. For example, > > when a processing path is not implemented by some of 64-bit architectures, > RTE_ARCH_64 is not sufficient. > > > Yes, but is RTE_ARCH_ARM64 not identical to RTE_ARCH_ARM && > RTE_ARCH_64? My thought is: 1. RTE_ARCH_ARM64 is a direct macro, so with better readability. 2. RTE_ARCH_ARM64 is already used widely in the project. So I think it is better not to replace the occurrences with combination of other macros.
[dpdk-dev] [PATCH 2/4] examples/vm_power_manager: fix string truncation warning
When compiling on ubuntu 20.04, a warning was issued about possible
truncation of the path string for the power management socket.
channel_manager.c: In function ‘add_all_channels’:
channel_manager.c:470:41: warning: ‘%s’ directive output may be truncated
writing up to 255 bytes into a region of size 90 [-Wformat-truncation=]
470 | sizeof(chan_info->channel_path), "%s%s",
| ^~
This can be fixed by adding in an explicit truncation check to the code and
handling it appropriately.
Fixes: e8ae9b662506 ("examples/vm_power: channel manager and monitor in host")
Cc: sta...@dpdk.org
Signed-off-by: Bruce Richardson
---
examples/vm_power_manager/channel_manager.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/examples/vm_power_manager/channel_manager.c
b/examples/vm_power_manager/channel_manager.c
index 3da01b46d8..0a28cb643b 100644
--- a/examples/vm_power_manager/channel_manager.c
+++ b/examples/vm_power_manager/channel_manager.c
@@ -466,9 +466,15 @@ add_all_channels(const char *vm_name)
continue;
}
- snprintf(chan_info->channel_path,
+ if ((size_t)snprintf(chan_info->channel_path,
sizeof(chan_info->channel_path), "%s%s",
- CHANNEL_MGR_SOCKET_PATH, dir->d_name);
+ CHANNEL_MGR_SOCKET_PATH, dir->d_name)
+ >= sizeof(chan_info->channel_path)) {
+ RTE_LOG(ERR, CHANNEL_MANAGER, "Pathname too long for
channel '%s%s'\n",
+ CHANNEL_MGR_SOCKET_PATH, dir->d_name);
+ rte_free(chan_info);
+ continue;
+ }
if (setup_channel_info(&vm_info, &chan_info, channel_num) < 0) {
rte_free(chan_info);
--
2.25.1
[dpdk-dev] [PATCH 3/4] examples/mp_server: fix snprintf overflow
When producing a printable mac address the buffer was appropriately sized
for holding the mac address exactly, but the actual snprintf included a
'\n' character at the end, which means that the snprintf technically is
getting truncated i.e. the \n would not be added due to lack of space.
This gets flagged as a problem by modern versions of gcc, e.g. on Ubuntu
20.04.
main.c:77:37: warning: ‘__builtin___snprintf_chk’ output truncated before the
last format character [-Wformat-truncation=]
77 | "%02x:%02x:%02x:%02x:%02x:%02x\n",
| ^
Since the \n is getting stripped anyway, we can fix the issue by just
removing it from the printf string.
Fixes: af75078fece3 ("first public release")
Cc: sta...@dpdk.org
Signed-off-by: Bruce Richardson
---
examples/multi_process/client_server_mp/mp_server/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/examples/multi_process/client_server_mp/mp_server/main.c
b/examples/multi_process/client_server_mp/mp_server/main.c
index 280dab8672..af5af672c3 100644
--- a/examples/multi_process/client_server_mp/mp_server/main.c
+++ b/examples/multi_process/client_server_mp/mp_server/main.c
@@ -74,7 +74,7 @@ get_printable_mac_addr(uint16_t port)
return err_address;
}
snprintf(addresses[port], sizeof(addresses[port]),
- "%02x:%02x:%02x:%02x:%02x:%02x\n",
+ "%02x:%02x:%02x:%02x:%02x:%02x",
mac.addr_bytes[0], mac.addr_bytes[1],
mac.addr_bytes[2],
mac.addr_bytes[3], mac.addr_bytes[4],
mac.addr_bytes[5]);
}
--
2.25.1
[dpdk-dev] [PATCH 0/4] fixes for example app builds
While helping prepare some patches for converting the DPDK examples to
build using pkg-config, a number of errors and warnings were encountered in
the example app builds. These patches fix those issues.
Bruce Richardson (4):
power: make guest channel headers public
examples/vm_power_manager: fix string truncation warning
examples/mp_server: fix snprintf overflow
examples/mp_server: clear string truncation warning
.../multi_process/client_server_mp/mp_server/main.c | 2 +-
.../multi_process/client_server_mp/shared/common.h| 2 +-
examples/vm_power_manager/channel_manager.c | 11 ---
examples/vm_power_manager/channel_monitor.c | 1 -
examples/vm_power_manager/channel_monitor.h | 2 +-
examples/vm_power_manager/guest_cli/main.c| 1 +
.../vm_power_manager/guest_cli/vm_power_cli_guest.c | 2 +-
.../vm_power_manager/guest_cli/vm_power_cli_guest.h | 2 +-
examples/vm_power_manager/vm_power_cli.c | 1 -
lib/librte_power/guest_channel.c | 3 +--
lib/librte_power/meson.build | 4 +++-
lib/librte_power/power_kvm_vm.c | 3 +--
...hannel_commands.h => rte_power_channel_commands.h} | 0
.../{guest_channel.h => rte_power_guest_channel.h}| 2 +-
14 files changed, 20 insertions(+), 16 deletions(-)
rename lib/librte_power/{channel_commands.h => rte_power_channel_commands.h}
(100%)
rename lib/librte_power/{guest_channel.h => rte_power_guest_channel.h} (98%)
--
2.25.1
[dpdk-dev] [PATCH 1/4] power: make guest channel headers public
The channel commands header file contains definitions that are used by the
example application for power management, and so need to be made public.
Similarly the guest_channel.h header is used by the guest_cli example
utility, so needs to be public also. Without this change, the example
apps, or any end-user apps based on them, can not be compiled outside the
main DPDK build.
Fixes: 210c383e247b ("power: packet format for vm power management")
Fixes: cd0d5547e873 ("power: vm communication channels in guest")
Cc: sta...@dpdk.org
Signed-off-by: Bruce Richardson
---
examples/vm_power_manager/channel_manager.c | 1 -
examples/vm_power_manager/channel_monitor.c | 1 -
examples/vm_power_manager/channel_monitor.h | 2 +-
examples/vm_power_manager/guest_cli/main.c| 1 +
examples/vm_power_manager/guest_cli/vm_power_cli_guest.c | 2 +-
examples/vm_power_manager/guest_cli/vm_power_cli_guest.h | 2 +-
examples/vm_power_manager/vm_power_cli.c | 1 -
lib/librte_power/guest_channel.c | 3 +--
lib/librte_power/meson.build | 4 +++-
lib/librte_power/power_kvm_vm.c | 3 +--
.../{channel_commands.h => rte_power_channel_commands.h} | 0
.../{guest_channel.h => rte_power_guest_channel.h}| 2 +-
12 files changed, 10 insertions(+), 12 deletions(-)
rename lib/librte_power/{channel_commands.h => rte_power_channel_commands.h}
(100%)
rename lib/librte_power/{guest_channel.h => rte_power_guest_channel.h} (98%)
diff --git a/examples/vm_power_manager/channel_manager.c
b/examples/vm_power_manager/channel_manager.c
index 74a2a677e8..3da01b46d8 100644
--- a/examples/vm_power_manager/channel_manager.c
+++ b/examples/vm_power_manager/channel_manager.c
@@ -27,7 +27,6 @@
#include
#include "channel_manager.h"
-#include "channel_commands.h"
#include "channel_monitor.h"
#include "power_manager.h"
diff --git a/examples/vm_power_manager/channel_monitor.c
b/examples/vm_power_manager/channel_monitor.c
index 1d00a6cf6c..75a29d2589 100644
--- a/examples/vm_power_manager/channel_monitor.c
+++ b/examples/vm_power_manager/channel_monitor.c
@@ -35,7 +35,6 @@
#include
#include "channel_monitor.h"
-#include "channel_commands.h"
#include "channel_manager.h"
#include "power_manager.h"
#include "oob_monitor.h"
diff --git a/examples/vm_power_manager/channel_monitor.h
b/examples/vm_power_manager/channel_monitor.h
index 7362a80d26..fe6ceedc95 100644
--- a/examples/vm_power_manager/channel_monitor.h
+++ b/examples/vm_power_manager/channel_monitor.h
@@ -6,7 +6,7 @@
#define CHANNEL_MONITOR_H_
#include "channel_manager.h"
-#include "channel_commands.h"
+#include "rte_power_channel_commands.h"
struct core_share {
unsigned int pcpu;
diff --git a/examples/vm_power_manager/guest_cli/main.c
b/examples/vm_power_manager/guest_cli/main.c
index f63b3c988a..4c0c98f498 100644
--- a/examples/vm_power_manager/guest_cli/main.c
+++ b/examples/vm_power_manager/guest_cli/main.c
@@ -14,6 +14,7 @@
#include
#include
+#include "rte_power_channel_commands.h"
#include "vm_power_cli_guest.h"
#include "parse.h"
diff --git a/examples/vm_power_manager/guest_cli/vm_power_cli_guest.c
b/examples/vm_power_manager/guest_cli/vm_power_cli_guest.c
index 96c1a1ff69..263e7ec9ff 100644
--- a/examples/vm_power_manager/guest_cli/vm_power_cli_guest.c
+++ b/examples/vm_power_manager/guest_cli/vm_power_cli_guest.c
@@ -19,7 +19,7 @@
#include
#include
-#include
+#include
#include "vm_power_cli_guest.h"
diff --git a/examples/vm_power_manager/guest_cli/vm_power_cli_guest.h
b/examples/vm_power_manager/guest_cli/vm_power_cli_guest.h
index 6ad14a3dea..33c01ff7ca 100644
--- a/examples/vm_power_manager/guest_cli/vm_power_cli_guest.h
+++ b/examples/vm_power_manager/guest_cli/vm_power_cli_guest.h
@@ -9,7 +9,7 @@
extern "C" {
#endif
-#include "channel_commands.h"
+struct channel_packet;
struct channel_packet *get_policy(void);
diff --git a/examples/vm_power_manager/vm_power_cli.c
b/examples/vm_power_manager/vm_power_cli.c
index 7edeaccda5..4c41645664 100644
--- a/examples/vm_power_manager/vm_power_cli.c
+++ b/examples/vm_power_manager/vm_power_cli.c
@@ -21,7 +21,6 @@
#include "channel_manager.h"
#include "channel_monitor.h"
#include "power_manager.h"
-#include "channel_commands.h"
struct cmd_quit_result {
cmdline_fixed_string_t quit;
diff --git a/lib/librte_power/guest_channel.c b/lib/librte_power/guest_channel.c
index 7b5926e5c4..d49cf0cd57 100644
--- a/lib/librte_power/guest_channel.c
+++ b/lib/librte_power/guest_channel.c
@@ -16,8 +16,7 @@
#include
-#include "guest_channel.h"
-#include "channel_commands.h"
+#include "rte_power_guest_channel.h"
#define RTE_LOGTYPE_GUEST_CHANNEL RTE_LOGTYPE_USER1
diff --git a/lib/librte_power/meson.build b/lib/librte_power/meson.build
index 78c031c943..e9b1fa6e45 100644
---
[dpdk-dev] [PATCH 4/4] examples/mp_server: clear string truncation warning
Compiling with GCC 9.3 on Ubuntu 20.04 gives a warning about possible
string truncation when getting the RX queue name:
In file included from init.c:36:
init.c: In function ‘init’:
../shared/common.h:38:28: warning: ‘%u’ directive output may be truncated
writing between 1 and 10 bytes into a region of size 8 [-Wformat-truncation=]
38 | #define MP_CLIENT_RXQ_NAME "MProc_Client_%u_RX"
|^~~~
../shared/common.h:52:35: note: in expansion of macro ‘MP_CLIENT_RXQ_NAME’
52 | snprintf(buffer, sizeof(buffer), MP_CLIENT_RXQ_NAME, id);
| ^~
This is a false positive, as the value of the "id" is limited to 255, being
stored in the app as a uint8_t value, removing the possibility of the %u
being replaced by anything other then 3 characters max (rather than up to
10 as thought by the compiler). Therefore, the warning can be easily
removed by changing the type of the "id" parameter to the local function
from "unsigned" to "uint8_t" also, ensuring the compiler is aware of the
range limit.
Cc: sta...@dpdk.org
Signed-off-by: Bruce Richardson
---
examples/multi_process/client_server_mp/shared/common.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/examples/multi_process/client_server_mp/shared/common.h
b/examples/multi_process/client_server_mp/shared/common.h
index 6dd43fcac2..76beca0101 100644
--- a/examples/multi_process/client_server_mp/shared/common.h
+++ b/examples/multi_process/client_server_mp/shared/common.h
@@ -43,7 +43,7 @@ struct port_info {
* Given the rx queue name template above, get the queue name
*/
static inline const char *
-get_rx_queue_name(unsigned id)
+get_rx_queue_name(uint8_t id)
{
/* buffer for return value. Size calculated by %u being replaced
* by maximum 3 digits (plus an extra byte for safety) */
--
2.25.1
Re: [dpdk-dev] [PATCH 1/4] power: make guest channel headers public
On Fri, Aug 14, 2020 at 12:00:42PM +0100, Bruce Richardson wrote:
> The channel commands header file contains definitions that are used by the
> example application for power management, and so need to be made public.
> Similarly the guest_channel.h header is used by the guest_cli example
> utility, so needs to be public also. Without this change, the example
> apps, or any end-user apps based on them, can not be compiled outside the
> main DPDK build.
>
> Fixes: 210c383e247b ("power: packet format for vm power management")
> Fixes: cd0d5547e873 ("power: vm communication channels in guest")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Bruce Richardson
> ---
> examples/vm_power_manager/channel_manager.c | 1 -
> examples/vm_power_manager/channel_monitor.c | 1 -
> examples/vm_power_manager/channel_monitor.h | 2 +-
> examples/vm_power_manager/guest_cli/main.c| 1 +
> examples/vm_power_manager/guest_cli/vm_power_cli_guest.c | 2 +-
> examples/vm_power_manager/guest_cli/vm_power_cli_guest.h | 2 +-
> examples/vm_power_manager/vm_power_cli.c | 1 -
> lib/librte_power/guest_channel.c | 3 +--
> lib/librte_power/meson.build | 4 +++-
> lib/librte_power/power_kvm_vm.c | 3 +--
> .../{channel_commands.h => rte_power_channel_commands.h} | 0
> .../{guest_channel.h => rte_power_guest_channel.h}| 2 +-
> 12 files changed, 10 insertions(+), 12 deletions(-)
> rename lib/librte_power/{channel_commands.h => rte_power_channel_commands.h}
> (100%)
> rename lib/librte_power/{guest_channel.h => rte_power_guest_channel.h} (98%)
>
Note, this patch does not include the makefile changes, as the work was
done when testing with the makefile removal patchset applied, and make
support is being removed in this release.
Re: [dpdk-dev] [PATCH v3 2/7] app/proc-info: eliminate useless borders
Hi Stephen, > > > snipped > > > > > > snipped > > > > > > > > > > snipped > > > > > > > > > > > > 15/07/2020 23:22, Stephen Hemminger: > > > > > > > Printing extra borders does not improve readability, and is > > > > > > > just unnecessary. Putting TSC hz in header also makes no sense > here. > > > > > > > > > > > > The CPU frequency on headers! > > > > > > OK to remove :) > > > > > > > > > > > > > > > > The rational of having Time Stamp Counter as the header for port > > > > > info and > > > > stats, is to account for each iteration for an average `packets > > > > per second`. That is using `watch -d -n 1 ./dpdk-procinfo -- --xstats | > > > > grep - > v ": 0"`. > > > > > > > > > > But if there better way to do this or add as new feature, +1 to > > > > > remove. > > > > > > > > Proc info should just use standard clock for its updates, not TSC? > > > > > > Can you please explain the rationale behind the (syscall for time) and not > TSC? > > > > Looking forward for the patch with clock change too. > > There is no part of what proc-info is show with xstats that displays or uses > tsc > directly. > Do you have a driver that is putting TSC information in xstats? I am sorry I did not follow you on this, In the earlier implementation with `proc-info` header we had TSC so coupling `--show --xstats`. But with the header removed out with TSC, how can we get this?
Re: [dpdk-dev] [PATCH v3 2/7] app/proc-info: eliminate useless borders
On Fri, 14 Aug 2020 11:08:31 + "Varghese, Vipin" wrote: > Hi Stephen, > > > > > > snipped > > > > > > > > snipped > > > > > > > > > > > > snipped > > > > > > > > > > > > > > 15/07/2020 23:22, Stephen Hemminger: > > > > > > > > Printing extra borders does not improve readability, and is > > > > > > > > just unnecessary. Putting TSC hz in header also makes no sense > > here. > > > > > > > > > > > > > > The CPU frequency on headers! > > > > > > > OK to remove :) > > > > > > > > > > > > > > > > > > > The rational of having Time Stamp Counter as the header for port > > > > > > info and > > > > > stats, is to account for each iteration for an average `packets > > > > > per second`. That is using `watch -d -n 1 ./dpdk-procinfo -- --xstats > > > > > | grep - > > v ": 0"`. > > > > > > > > > > > > But if there better way to do this or add as new feature, +1 to > > > > > > remove. > > > > > > > > > > Proc info should just use standard clock for its updates, not TSC? > > > > > > > > Can you please explain the rationale behind the (syscall for time) and > > > > not > > TSC? > > > > > > Looking forward for the patch with clock change too. > > > > There is no part of what proc-info is show with xstats that displays or > > uses tsc > > directly. > > Do you have a driver that is putting TSC information in xstats? > > I am sorry I did not follow you on this, In the earlier implementation with > `proc-info` header we had TSC so coupling `--show --xstats`. But with the > header removed out with TSC, how can we get this? I am asking why is the TSC hz a useful piece of information here? Sure, proc-info could print lots of things but unless it serves a useful purpose for examining the interfaces, it is just noise. Developers love to clutter output, but it just raises the signal to noise ratio.
Re: [dpdk-dev] [PATCH 00/22] windows/netuio: add netuio driver for Windows
On Thu, Aug 13, 2020 at 04:21:23PM -0700, Narcisa Ana Maria Vasile wrote: > From: Narcisa Vasile > > The NetUIO driver for Windows allows the usermode application > to directly access the hardware and allocates the memory that gets mapped in > usermode. > > Anand Rawat (1): > Updated Source and Project files to use Clang toolset > > Harini Ramakrishnan (10): > Windows DPDK libraries and applications have now been updated to the > latest public release v18.08, of the main DPDK source. > doc: remove embedded buffer from Windows UIO ioctl > Windows DPDK libraries and applications have now been updated to the > latest public release v18.08, of the main DPDK source. > doc: change the Windows UIO driver's default security descriptor to > admin only > doc: remove lower bound on mapped address from Windows UIO driver > doc: remove embedded buffer from Windows UIO ioctl > uio: move SDDL string to INF on Windows > uio: Fix 64 bit BARs mapping > license: update headers with BSD 3-clause license: > doc: updating REAME for NetUIO driver > > Jason Messer (2): > Initial commit of UIO driver for Windows > Added new core libraries for Windows > > Narcisa Vasile (8): > Update .gitignore and create .gitattributes > uio: Use local time when verifying INF DriverVer > uio: Remove co-installers section from inf > uio: Wrap call into try/except block > uio: Use request handler that guarantees execution in correct context > uio: Change the device setup class to a custom one > Enable DMA remapping through INF directive > Move all files under windows folder > > Thomas Monjalon (1): > init DPDK repository > > -- > 2.23.0.vfs.1.1.63.g5a5ad7f Acked-by: Harini Ramakrishnan
Re: [dpdk-dev] [RFC v1 0/2] Add device emulation support in DPDK
On Fri, 14 Aug 2020 19:16:04 + Chenbo Xia wrote: > This series enables DPDK to be an alternative I/O device emulation library of > building virtualized devices in separate processes outside QEMU. It introduces > a new library (librte_vfio_user), a new device class (emudev) and one pilot > device provider (avf_emudev) with its backend of Ethdev PMD (avfbe_ethdev). > > *librte_vfio_user* is a server implementation of VFIO-over-socket[1] (also > known as vfio-user) which is a protocol that allows a device to be virtualized > in a separate process outside of QEMU. > > *emudev* is a device type for emulated devices. It is up to device provider to > choose the transport. In avf_emudev case, it uses vfio-user as transport > communicate with its client (e.g., QEMU). > > *avf_emudev* is the emudev provider of AVF which is a device specification for > Intel Virtual Function cross generation. It’s implemented by an AVF emudev > driver which offers a few APIs for avfbe_ethdev or app logic to operate. > > *avfbe_ethdev* is a normal ethdev PMD to supply the basic I/O as backend data > path of avf_emudev. One simple usage of avfbe_ethdev could be a > para-virtualized > backend connected with network application logic. > > Background & Motivation > --- > In order to reduce the attack surface, QEMU community is disaggregating QEMU > by > removing part of device emulation from it. The disaggregated/multi-process > QEMU > is using VFIO-over-socket/vfio-user as the main transport mechanism to > disaggregate > I/O services from QEMU[2]. Vfio-user essentially implements the VFIO device > model > presented to the user process by a set of messages over a unix-domain socket. > The > main difference between application using vfio-user and application using vfio > kernel module is that device manipulation is based on socket messages for > vfio-user > but system calls for vfio kernel module. The vfio-user devices consist of a > generic > VFIO device type, living in QEMU, which is called the client[3], and the core > device > implementation (emulated device), living outside of QEMU, which is called the > server. > > With the introduction and support of vfio-user in QEMU, QEMU is explicitly > adding > support for external emulated device and data path. We are trying to leverage > that > and introducing vfio-user support in DPDK. By doing so, DPDK is enabled to be > an > alternative I/O device emulation library of building virtualized devices > along with > high-performance data path in separate processes outside QEMU. It will be > easy for > hardware vendors to provide virtualized solutions of their hardware devices by > implementing emulated device in DPDK. > > Except for vfio-user introduced in DPDK, this series also introduces the first > emulated device implementation. That is emulated AVF device (avf_emudev) > implemented > by AVF emulation driver (avf_emudev driver). Emulated AVF device demos how > emulated > device could be implemented in DPDK. SPDK is also investigating to implement > use case > for NVMe. > > Design overview > --- > > +--+ > | +---+ +---+ | > | | avf_emudev | | avfbe_ethdev | | > | |driver | | driver| | > | +---+ +---+ | > | | | | > | --- VDEV BUS | > | | | | > | +---+ +--+ | > +--+| | vdev: | | vdev:| | > | +--+ || | /path/to/vfio | | avf_emudev_# | | > | | Generic | || +---+ +--+ | > | | vfio-dev | || | | > | +--+ || | | > | +--+ || +--+| > | | vfio-user| || | vfio-user|| > | | client | |<---|->| server || > | +--+ || +--+| > | QEMU || DPDK | > +--++--+ > > - vfio-user. Vfio-user in DPDK is referred to the vfio-user protocol > implementation > playing server role. It provides transport between emulated device and > generic VFIO > device in QEMU. Emulated device in DPDK and generic VFIO device in QEMU are > working > together to
Re: [dpdk-dev] [PATCH 3/4] examples/mp_server: fix snprintf overflow
On Fri, 14 Aug 2020 12:00:44 +0100
Bruce Richardson wrote:
> When producing a printable mac address the buffer was appropriately sized
> for holding the mac address exactly, but the actual snprintf included a
> '\n' character at the end, which means that the snprintf technically is
> getting truncated i.e. the \n would not be added due to lack of space.
> This gets flagged as a problem by modern versions of gcc, e.g. on Ubuntu
> 20.04.
>
> main.c:77:37: warning: ‘__builtin___snprintf_chk’ output truncated before the
> last format character [-Wformat-truncation=]
>77 | "%02x:%02x:%02x:%02x:%02x:%02x\n",
> | ^
>
> Since the \n is getting stripped anyway, we can fix the issue by just
> removing it from the printf string.
>
> Fixes: af75078fece3 ("first public release")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Bruce Richardson
> ---
> examples/multi_process/client_server_mp/mp_server/main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/examples/multi_process/client_server_mp/mp_server/main.c
> b/examples/multi_process/client_server_mp/mp_server/main.c
> index 280dab8672..af5af672c3 100644
> --- a/examples/multi_process/client_server_mp/mp_server/main.c
> +++ b/examples/multi_process/client_server_mp/mp_server/main.c
> @@ -74,7 +74,7 @@ get_printable_mac_addr(uint16_t port)
> return err_address;
> }
> snprintf(addresses[port], sizeof(addresses[port]),
> - "%02x:%02x:%02x:%02x:%02x:%02x\n",
> + "%02x:%02x:%02x:%02x:%02x:%02x",
> mac.addr_bytes[0], mac.addr_bytes[1],
> mac.addr_bytes[2],
> mac.addr_bytes[3], mac.addr_bytes[4],
> mac.addr_bytes[5]);
> }
Please convert to rte_ether_format_addr() instead of local hard coded format.
[dpdk-dev] Please note: v21 ABI notification
Please note, ABI v21 has been declared aligned with the DPDK 20.11 release. (https://git.dpdk.org/dpdk/commit/?id=4f86c0ba19ba065c8c32a5b0111efc7bb74c9b96) The requirement to preserve compatibility with the previous major ABI version v20 in DPDK 19.11 is now dropped. This is commonly known as the ABI breakage window, and some amended rules apply for the duration of this cycle: * The requirement to preserve compatibility with the previous major ABI version v20, no longer applies. * Contributors of compatibility preserving code and/or symbol aliases to experimental in previous releases, are now kindly asked to remove this code. I will send a direct notification to this group as a followup to this mail. * Symbol versioning references to the old ABI version v20, have been updated to reference the new ABI version v21. * Finally, please note, the ABI breakage window is *not* permission to circumvent the other aspects of the procedures to make ABI changes, that is, 3 ACKs of the requirement to break the ABI and the observance of a deprecation notice are still considered mandatory. Kinds regards, Ray Kinsella ABI Maintainer
Re: [dpdk-dev] Please note: v21 ABI notification
Hi folks, Now is the time to remove old ABI compatibility preserving code. Remove versioning code: * Cryptodev Fiona Trahe Arek Kusztal * Mempool Olivier Matz Remove alias to experimental: * Metering Ferruh Yigit Finally, Along the way I noted the following public symbols that are not assigned to a version node. * Regex Device Ori Kam Symbols: - rte_regexdev_unregister rte_regexdev_register rte_regexdev_get_device_by_name rte_regexdev_is_valid_dev Thanks, Ray Kinsella On 14/08/2020 16:16, Kinsella, Ray wrote: > Please note, > > ABI v21 has been declared aligned with the DPDK 20.11 release. > (https://git.dpdk.org/dpdk/commit/?id=4f86c0ba19ba065c8c32a5b0111efc7bb74c9b96) > > The requirement to preserve compatibility with the previous major ABI version > v20 > in DPDK 19.11 is now dropped. This is commonly known as the ABI breakage > window, > and some amended rules apply for the duration of this cycle: > > * The requirement to preserve compatibility with the previous major ABI >version v20, no longer applies. > > * Contributors of compatibility preserving code and/or symbol aliases to >experimental in previous releases, are now kindly asked to remove this > code. > >I will send a direct notification to this group as a followup to this > mail. > > * Symbol versioning references to the old ABI version v20, have been >updated to reference the new ABI version v21. > > * Finally, please note, the ABI breakage window is *not* permission to >circumvent the other aspects of the procedures to make ABI changes, >that is, 3 ACKs of the requirement to break the ABI and >the observance of a deprecation notice are still considered mandatory. > > Kinds regards, > > Ray Kinsella > ABI Maintainer >
[dpdk-dev] [PATCH v1] common/iavf: mark the global functions internal
According to ABI policy, the internal functions should have the new tag
__rte_internal and linked into INTERNAL sessions.
Signed-off-by: Haiyue Wang
---
drivers/common/iavf/iavf_prototype.h| 6 ++
drivers/common/iavf/rte_common_iavf_version.map | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/common/iavf/iavf_prototype.h
b/drivers/common/iavf/iavf_prototype.h
index 31ce2af49..f34e77db0 100644
--- a/drivers/common/iavf/iavf_prototype.h
+++ b/drivers/common/iavf/iavf_prototype.h
@@ -17,7 +17,9 @@
*/
/* adminq functions */
+__rte_internal
enum iavf_status iavf_init_adminq(struct iavf_hw *hw);
+__rte_internal
enum iavf_status iavf_shutdown_adminq(struct iavf_hw *hw);
enum iavf_status iavf_init_asq(struct iavf_hw *hw);
enum iavf_status iavf_init_arq(struct iavf_hw *hw);
@@ -30,6 +32,7 @@ void iavf_free_adminq_asq(struct iavf_hw *hw);
void iavf_free_adminq_arq(struct iavf_hw *hw);
enum iavf_status iavf_validate_mac_addr(u8 *mac_addr);
void iavf_adminq_init_ring_data(struct iavf_hw *hw);
+__rte_internal
enum iavf_status iavf_clean_arq_element(struct iavf_hw *hw,
struct iavf_arq_event_info *e,
u16 *events_pending);
@@ -61,6 +64,7 @@ enum iavf_status iavf_aq_set_rss_key(struct iavf_hw *hw,
const char *iavf_aq_str(struct iavf_hw *hw, enum iavf_admin_queue_err aq_err);
const char *iavf_stat_str(struct iavf_hw *hw, enum iavf_status stat_err);
+__rte_internal
enum iavf_status iavf_set_mac_type(struct iavf_hw *hw);
extern struct iavf_rx_ptype_decoded iavf_ptype_lookup[];
@@ -76,9 +80,11 @@ void iavf_acquire_spinlock(struct iavf_spinlock *sp);
void iavf_release_spinlock(struct iavf_spinlock *sp);
void iavf_destroy_spinlock(struct iavf_spinlock *sp);
+__rte_internal
void iavf_vf_parse_hw_config(struct iavf_hw *hw,
struct virtchnl_vf_resource *msg);
enum iavf_status iavf_vf_reset(struct iavf_hw *hw);
+__rte_internal
enum iavf_status iavf_aq_send_msg_to_pf(struct iavf_hw *hw,
enum virtchnl_ops v_opcode,
enum iavf_status v_retval,
diff --git a/drivers/common/iavf/rte_common_iavf_version.map
b/drivers/common/iavf/rte_common_iavf_version.map
index 44142499e..e0f117197 100644
--- a/drivers/common/iavf/rte_common_iavf_version.map
+++ b/drivers/common/iavf/rte_common_iavf_version.map
@@ -1,4 +1,4 @@
-DPDK_21 {
+INTERNAL {
global:
iavf_aq_send_msg_to_pf;
--
2.28.0
[dpdk-dev] [PATCH v2] common/iavf: mark internal symbols
According to ABI policy, the internal functions should have the new tag
__rte_internal and linked into INTERNAL sessions.
Signed-off-by: Haiyue Wang
---
v2: update the commit title
---
drivers/common/iavf/iavf_prototype.h| 6 ++
drivers/common/iavf/rte_common_iavf_version.map | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/common/iavf/iavf_prototype.h
b/drivers/common/iavf/iavf_prototype.h
index 31ce2af49..f34e77db0 100644
--- a/drivers/common/iavf/iavf_prototype.h
+++ b/drivers/common/iavf/iavf_prototype.h
@@ -17,7 +17,9 @@
*/
/* adminq functions */
+__rte_internal
enum iavf_status iavf_init_adminq(struct iavf_hw *hw);
+__rte_internal
enum iavf_status iavf_shutdown_adminq(struct iavf_hw *hw);
enum iavf_status iavf_init_asq(struct iavf_hw *hw);
enum iavf_status iavf_init_arq(struct iavf_hw *hw);
@@ -30,6 +32,7 @@ void iavf_free_adminq_asq(struct iavf_hw *hw);
void iavf_free_adminq_arq(struct iavf_hw *hw);
enum iavf_status iavf_validate_mac_addr(u8 *mac_addr);
void iavf_adminq_init_ring_data(struct iavf_hw *hw);
+__rte_internal
enum iavf_status iavf_clean_arq_element(struct iavf_hw *hw,
struct iavf_arq_event_info *e,
u16 *events_pending);
@@ -61,6 +64,7 @@ enum iavf_status iavf_aq_set_rss_key(struct iavf_hw *hw,
const char *iavf_aq_str(struct iavf_hw *hw, enum iavf_admin_queue_err aq_err);
const char *iavf_stat_str(struct iavf_hw *hw, enum iavf_status stat_err);
+__rte_internal
enum iavf_status iavf_set_mac_type(struct iavf_hw *hw);
extern struct iavf_rx_ptype_decoded iavf_ptype_lookup[];
@@ -76,9 +80,11 @@ void iavf_acquire_spinlock(struct iavf_spinlock *sp);
void iavf_release_spinlock(struct iavf_spinlock *sp);
void iavf_destroy_spinlock(struct iavf_spinlock *sp);
+__rte_internal
void iavf_vf_parse_hw_config(struct iavf_hw *hw,
struct virtchnl_vf_resource *msg);
enum iavf_status iavf_vf_reset(struct iavf_hw *hw);
+__rte_internal
enum iavf_status iavf_aq_send_msg_to_pf(struct iavf_hw *hw,
enum virtchnl_ops v_opcode,
enum iavf_status v_retval,
diff --git a/drivers/common/iavf/rte_common_iavf_version.map
b/drivers/common/iavf/rte_common_iavf_version.map
index 44142499e..e0f117197 100644
--- a/drivers/common/iavf/rte_common_iavf_version.map
+++ b/drivers/common/iavf/rte_common_iavf_version.map
@@ -1,4 +1,4 @@
-DPDK_21 {
+INTERNAL {
global:
iavf_aq_send_msg_to_pf;
--
2.28.0
[dpdk-dev] [PATCH] eal: add option to put timestamp on console output
When debugging driver or startup issues, it is useful to have
a timestamp on each message printed. The messages in syslog
already have a timestamp, but often syslog is not available
during testing. The timestamp format is chosen to look
like the default Linux dmesg timestamp.
Example:
[ 0.40] EAL: Probing VFIO support...
Signed-off-by: Stephen Hemminger
---
doc/guides/linux_gsg/linux_eal_parameters.rst | 5 +++
lib/librte_eal/common/eal_common_options.c| 5 +++
lib/librte_eal/common/eal_internal_cfg.h | 1 +
lib/librte_eal/common/eal_options.h | 2 +
lib/librte_eal/linux/eal_log.c| 41 +--
5 files changed, 51 insertions(+), 3 deletions(-)
diff --git a/doc/guides/linux_gsg/linux_eal_parameters.rst
b/doc/guides/linux_gsg/linux_eal_parameters.rst
index bd3977cb3d91..9336046c63a9 100644
--- a/doc/guides/linux_gsg/linux_eal_parameters.rst
+++ b/doc/guides/linux_gsg/linux_eal_parameters.rst
@@ -118,3 +118,8 @@ Other options
local5
local6
local7
+
+* ``--log-timestamp``
+
+Add a timestamp of seconds and microseconds to each log message
+written to standard output.
diff --git a/lib/librte_eal/common/eal_common_options.c
b/lib/librte_eal/common/eal_common_options.c
index a5426e12346a..240610770ee1 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -76,6 +76,7 @@ eal_long_options[] = {
{OPT_IOVA_MODE, 1, NULL, OPT_IOVA_MODE_NUM},
{OPT_LCORES,1, NULL, OPT_LCORES_NUM },
{OPT_LOG_LEVEL, 1, NULL, OPT_LOG_LEVEL_NUM},
+ {OPT_LOG_TIMESTAMP, 0, NULL, OPT_LOG_TIMESTAMP_NUM},
{OPT_TRACE, 1, NULL, OPT_TRACE_NUM},
{OPT_TRACE_DIR, 1, NULL, OPT_TRACE_DIR_NUM},
{OPT_TRACE_BUF_SIZE,1, NULL, OPT_TRACE_BUF_SIZE_NUM },
@@ -1626,6 +1627,9 @@ eal_parse_common_option(int opt, const char *optarg,
}
break;
}
+ case OPT_LOG_TIMESTAMP_NUM:
+ conf->log_timestamp = 1;
+ break;
#ifndef RTE_EXEC_ENV_WINDOWS
case OPT_TRACE_NUM: {
@@ -1945,6 +1949,7 @@ eal_common_usage(void)
" --"OPT_PROC_TYPE" Type of this process
(primary|secondary|auto)\n"
#ifndef RTE_EXEC_ENV_WINDOWS
" --"OPT_SYSLOG"Set syslog facility\n"
+ " --"OPT_LOG_TIMESTAMP" Timestamp log output\n"
#endif
" --"OPT_LOG_LEVEL"= Set global log level\n"
" --"OPT_LOG_LEVEL"=:\n"
diff --git a/lib/librte_eal/common/eal_internal_cfg.h
b/lib/librte_eal/common/eal_internal_cfg.h
index 13f93388a781..75c476870c57 100644
--- a/lib/librte_eal/common/eal_internal_cfg.h
+++ b/lib/librte_eal/common/eal_internal_cfg.h
@@ -70,6 +70,7 @@ struct internal_config {
* per-node) non-legacy mode only.
*/
volatile int syslog_facility; /**< facility passed to openlog() */
+ volatile uint8_t log_timestamp; /**< add timestamp to console output
*/
/** default interrupt mode for VFIO */
volatile enum rte_intr_mode vfio_intr_mode;
/** the shared VF token for VFIO-PCI bound PF and VFs devices */
diff --git a/lib/librte_eal/common/eal_options.h
b/lib/librte_eal/common/eal_options.h
index 89769d48b487..7c86f2e19109 100644
--- a/lib/librte_eal/common/eal_options.h
+++ b/lib/librte_eal/common/eal_options.h
@@ -35,6 +35,8 @@ enum {
OPT_LCORES_NUM,
#define OPT_LOG_LEVEL "log-level"
OPT_LOG_LEVEL_NUM,
+#define OPT_LOG_TIMESTAMP "log-timestamp"
+ OPT_LOG_TIMESTAMP_NUM,
#define OPT_TRACE "trace"
OPT_TRACE_NUM,
#define OPT_TRACE_DIR "trace-dir"
diff --git a/lib/librte_eal/linux/eal_log.c b/lib/librte_eal/linux/eal_log.c
index 43c8460bfb07..cbd0924ec847 100644
--- a/lib/librte_eal/linux/eal_log.c
+++ b/lib/librte_eal/linux/eal_log.c
@@ -5,9 +5,12 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
+#include
#include
#include
@@ -18,6 +21,9 @@
#include
#include "eal_private.h"
+#include "eal_internal_cfg.h"
+
+static struct timespec log_start_time;
/*
* default log function
@@ -25,11 +31,38 @@
static ssize_t
console_log_write(__rte_unused void *c, const char *buf, size_t size)
{
+ const struct internal_config *internal_conf
+ = eal_get_internal_configuration();
ssize_t ret;
+ char tbuf[64];
+ struct iovec iov[2];
+
+ if (internal_conf->log_timestamp) {
+ struct timespec ts;
+
+ /* format up monotonic timestamp */
+ clock_gettime(CLOCK_MONOTONIC, &ts);
+ ts.tv_sec -= log_start_time.tv_sec;
+ ts.tv_nsec -= log_start_time.tv_nsec;
+ if (ts.tv_nsec < 0) {
+ --ts.tv_sec;
+
[dpdk-dev] [PATCH] net/failsafe: don't double space warning
Already get a newline from WARN() macro call.
Fixes: 9dda3e3393c2 ("net/failsafe: add timestamp to stats snapshot")
Cc: ma...@mellanox.com
Signed-off-by: Stephen Hemminger
---
drivers/net/failsafe/failsafe_ether.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/failsafe/failsafe_ether.c
b/drivers/net/failsafe/failsafe_ether.c
index 2b748bd8b426..70972d67174f 100644
--- a/drivers/net/failsafe/failsafe_ether.c
+++ b/drivers/net/failsafe/failsafe_ether.c
@@ -322,10 +322,10 @@ fs_dev_stats_save(struct sub_device *sdev)
if (err) {
uint64_t timestamp = sdev->stats_snapshot.timestamp;
- WARN("Could not access latest statistics from sub-device %d.\n",
+ WARN("Could not access latest statistics from sub-device %d.",
SUB_ID(sdev));
if (timestamp != 0)
- WARN("Using latest snapshot taken before %"PRIu64"
seconds.\n",
+ WARN("Using latest snapshot taken before %"PRIu64"
seconds.",
(rte_rdtsc() - timestamp) / rte_get_tsc_hz());
}
failsafe_stats_increment
--
2.27.0
[dpdk-dev] [PATCH] eal: change debug diagnostic message from udev handler
The debug message was poorly worded and did not include the
part that would be useful. I.e it never said what was being ignored.
Change it to print the message so that if udev changes format or
other subsystems need to be added then the necessary information
will be in the debug log.
Fixes: 0d0f478d0483 ("eal/linux: add uevent parse and process")
Cc: jia@intel.com
Signed-off-by: Stephen Hemminger
---
lib/librte_eal/linux/eal_dev.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/lib/librte_eal/linux/eal_dev.c b/lib/librte_eal/linux/eal_dev.c
index 83c9cd660754..83b6068264cb 100644
--- a/lib/librte_eal/linux/eal_dev.c
+++ b/lib/librte_eal/linux/eal_dev.c
@@ -234,8 +234,7 @@ dev_uev_handler(__rte_unused void *param)
ret = dev_uev_parse(buf, &uevent, EAL_UEV_MSG_LEN);
if (ret < 0) {
- RTE_LOG(DEBUG, EAL, "It is not an valid event "
- "that need to be handle.\n");
+ RTE_LOG(DEBUG, EAL, "Ignoring uevent '%s'\n", buf);
return;
}
--
2.27.0
Re: [dpdk-dev] [PATCH] eal: add option to put timestamp on console output
On Fri, 14 Aug 2020 10:34:41 -0700, Stephen Hemminger wrote: > When debugging driver or startup issues, it is useful to have > a timestamp on each message printed. The messages in syslog > already have a timestamp, but often syslog is not available > during testing. The timestamp format is chosen to look > like the default Linux dmesg timestamp. > > Example: > [ 0.40] EAL: Probing VFIO support... > > Signed-off-by: Stephen Hemminger > --- > doc/guides/linux_gsg/linux_eal_parameters.rst | 5 +++ > lib/librte_eal/common/eal_common_options.c| 5 +++ > lib/librte_eal/common/eal_internal_cfg.h | 1 + > lib/librte_eal/common/eal_options.h | 2 + > lib/librte_eal/linux/eal_log.c| 41 +-- > 5 files changed, 51 insertions(+), 3 deletions(-) [snip] > @@ -1945,6 +1949,7 @@ eal_common_usage(void) > " --"OPT_PROC_TYPE" Type of this process > (primary|secondary|auto)\n" > #ifndef RTE_EXEC_ENV_WINDOWS > " --"OPT_SYSLOG"Set syslog facility\n" > +" --"OPT_LOG_TIMESTAMP" Timestamp log output\n" > #endif Seems like FreeBSD doesn't support this option as well. It is clear that iovec approach saves a syscall on each write, but is it worth implementing log timestamps on each platform instead of prepending it in common code (with a second fwrite call)? For fast event stream with precise timestamps, there is tracing framework.
Re: [dpdk-dev] [PATCH] eal: add option to put timestamp on console output
On Fri, 14 Aug 2020 21:39:29 +0300 Dmitry Kozlyuk wrote: > On Fri, 14 Aug 2020 10:34:41 -0700, Stephen Hemminger wrote: > > When debugging driver or startup issues, it is useful to have > > a timestamp on each message printed. The messages in syslog > > already have a timestamp, but often syslog is not available > > during testing. The timestamp format is chosen to look > > like the default Linux dmesg timestamp. > > > > Example: > > [ 0.40] EAL: Probing VFIO support... > > > > Signed-off-by: Stephen Hemminger > > --- > > doc/guides/linux_gsg/linux_eal_parameters.rst | 5 +++ > > lib/librte_eal/common/eal_common_options.c| 5 +++ > > lib/librte_eal/common/eal_internal_cfg.h | 1 + > > lib/librte_eal/common/eal_options.h | 2 + > > lib/librte_eal/linux/eal_log.c| 41 +-- > > 5 files changed, 51 insertions(+), 3 deletions(-) > [snip] > > > @@ -1945,6 +1949,7 @@ eal_common_usage(void) > >" --"OPT_PROC_TYPE" Type of this process > > (primary|secondary|auto)\n" > > #ifndef RTE_EXEC_ENV_WINDOWS > >" --"OPT_SYSLOG"Set syslog facility\n" > > + " --"OPT_LOG_TIMESTAMP" Timestamp log output\n" > > #endif > > Seems like FreeBSD doesn't support this option as well. > > It is clear that iovec approach saves a syscall on each write, but is it worth > implementing log timestamps on each platform instead of prepending it in > common code (with a second fwrite call)? For fast event stream with precise > timestamps, there is tracing framework. FreeBsd doesn't go through the same log code. Iovec is to keep timestamp and message as an atomic message. There is no good way to use fwrite to get anything atomic. Fwrite is unnecessary here anyway saving a copy and avoid issues with library getting corrupted is good.
Re: [dpdk-dev] [PATCH] eal: add option to put timestamp on console output
On Fri, 14 Aug 2020 11:45:49 -0700, Stephen Hemminger wrote: > On Fri, 14 Aug 2020 21:39:29 +0300 > Dmitry Kozlyuk wrote: [...] > FreeBsd doesn't go through the same log code. Then --log-timestamp shouldn't appear on FreeBSD if it's unsupported. > Iovec is to keep timestamp and message as an atomic message. > There is no good way to use fwrite to get anything atomic. > Fwrite is unnecessary here anyway saving a copy and avoid issues with library > getting corrupted is good. Got it, thanks.
Re: [dpdk-dev] [PATCH] eal: add option to put timestamp on console output
On Fri, 14 Aug 2020 22:09:11 +0300 Dmitry Kozlyuk wrote: > On Fri, 14 Aug 2020 11:45:49 -0700, Stephen Hemminger wrote: > > On Fri, 14 Aug 2020 21:39:29 +0300 > > Dmitry Kozlyuk wrote: > [...] > > FreeBsd doesn't go through the same log code. > > Then --log-timestamp shouldn't appear on FreeBSD if it's unsupported. Was using same ifdef that is already there. There are several options already (like syslog facility) which do nothing on FreeBSD anyway. > > > Iovec is to keep timestamp and message as an atomic message. > > There is no good way to use fwrite to get anything atomic. > > Fwrite is unnecessary here anyway saving a copy and avoid issues with > > library > > getting corrupted is good. > > Got it, thanks.
Re: [dpdk-dev] [PATCH 03/22] Added new core libraries for Windows
On Thu, 13 Aug 2020 16:21:26 -0700, Narcisa Ana Maria Vasile wrote: > From: Jason Messer > > --- > mk/exec-env/windows/netuio/netuio.vcxproj | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/mk/exec-env/windows/netuio/netuio.vcxproj > b/mk/exec-env/windows/netuio/netuio.vcxproj > index 251b8eb95..9e769b5d0 100644 > --- a/mk/exec-env/windows/netuio/netuio.vcxproj > +++ b/mk/exec-env/windows/netuio/netuio.vcxproj > @@ -66,7 +66,7 @@ >false > > > - 0.6.0.2 > + 0.6.0.5 > > > Condition="'$(Configuration)|$(Platform)'=='Release|x64'"> > @@ -78,7 +78,7 @@ >false > > > - 0.6.0.2 > + 0.6.0.5 > > > Commit subject does not match content. Is this commit even needed?
Re: [dpdk-dev] [PATCH 00/22] windows/netuio: add netuio driver for Windows
On Thu, 13 Aug 2020 16:21:23 -0700, Narcisa Ana Maria Vasile wrote:
> From: Narcisa Vasile
>
> The NetUIO driver for Windows allows the usermode application
> to directly access the hardware
> and allocates the memory that gets mapped in usermode.
It doesn't allocate the buffer anymore, does it?
As far as I understand, you're importing history from dpdk-draft-repo and
then changing file layout. Not sure how this is beneficial, especially
since there are bugfixes along the way. Or are there legal reasons?
Please follow the guidelines on commit formatting, in particular:
* Subject must have a topic ("windows/netuio"?), its length is limited.
* Description is mandatory and should explain the changes.
Re: [dpdk-dev] [PATCH 01/22] init DPDK repository
On Thu, 13 Aug 2020 16:21:24 -0700, Narcisa Ana Maria Vasile wrote: > From: Thomas Monjalon > > --- > .gitignore | 0 > 1 file changed, 0 insertions(+), 0 deletions(-) > create mode 100644 .gitignore > > diff --git a/.gitignore b/.gitignore > new file mode 100644 > index 0..e69de29bb This commit is not needed.
Re: [dpdk-dev] [PATCH 11/22] Updated Source and Project files to use Clang toolset
On Thu, 13 Aug 2020 16:21:34 -0700, Narcisa Ana Maria Vasile wrote: > From: Anand Rawat > > Updated the code for using LLVM toolset. The code still uses > msbuild and VS2017. Some header files and windows specific > utility functions are removed due to conflicts with Clang > intrinsic functions. Project files have been updated to use > LLVM and additional project settings for Clang. > > Change-Id: I274de21379287c664e072f58e94271c654afe603 Not sure what this means for DPDK. > Signed-off-by: Anand Rawat > --- > kernel/windows/netuio/netuio_queue.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/kernel/windows/netuio/netuio_queue.c > b/kernel/windows/netuio/netuio_queue.c > index 929192880..760b4a7e5 100644 > --- a/kernel/windows/netuio/netuio_queue.c > +++ b/kernel/windows/netuio/netuio_queue.c > @@ -156,8 +156,8 @@ netuio_evt_IO_device_control(_In_ WDFQUEUE Queue, _In_ > WDFREQUEST Request, > break; > } > > -// Zero out the physically contiguous block > -RtlZeroMemory(netuio_contextdata->dpdk_seg.mem.virt_addr, > netuio_contextdata->dpdk_seg.mem.size); > + // Zero out the physically contiguous block > + RtlZeroMemory(netuio_contextdata->dpdk_seg.mem.virt_addr, > netuio_contextdata->dpdk_seg.mem.size); > > // Return relevant data to the caller > status = WdfRequestRetrieveOutputBuffer(Request, sizeof(struct > dpdk_private_info), &output_buf, &output_buf_size); Subject does not match content. Is this commit needed as standalone?
Re: [dpdk-dev] [PATCH 20/22] license: update headers with BSD 3-clause license:
On Thu, 13 Aug 2020 16:21:43 -0700, Narcisa Ana Maria Vasile wrote: > From: Harini Ramakrishnan > > Signed-off-by: Harini Ramakrishnan > --- > kernel/windows/netuio/netuio.inf | 3 +- > kernel/windows/netuio/netuio.rc | Bin 4772 -> 8098 bytes > kernel/windows/netuio/netuio_dev.c | 32 +++-- > kernel/windows/netuio/netuio_dev.h | 32 +++-- > kernel/windows/netuio/netuio_drv.c | 34 --- > kernel/windows/netuio/netuio_drv.h | 32 +++-- > kernel/windows/netuio/netuio_interface.h | 34 --- > kernel/windows/netuio/netuio_queue.c | 34 --- > kernel/windows/netuio/netuio_queue.h | 34 --- > 9 files changed, 208 insertions(+), 27 deletions(-) Why not use proper license from the commit each file is introduced? I'm not even sure it is allowed to add files under unapproved license. Please use "SPDX-License-Identifier: BSD-3-Clause" line to indicate licensing. In fact, there was a cleanup of license boilerplate in DPDK some time ago. Lastly, commit topic should be "windows/netuio" and there's an colon in the end (a typo?).
Re: [dpdk-dev] [PATCH 05/22] doc: remove embedded buffer from Windows UIO ioctl
On Thu, 13 Aug 2020 16:21:28 -0700, Narcisa Ana Maria Vasile wrote: > From: Harini Ramakrishnan > > --- > mk/exec-env/windows/netuio/netuio.vcxproj | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/mk/exec-env/windows/netuio/netuio.vcxproj > b/mk/exec-env/windows/netuio/netuio.vcxproj > index b6564e4e7..b6b11e49a 100644 > --- a/mk/exec-env/windows/netuio/netuio.vcxproj > +++ b/mk/exec-env/windows/netuio/netuio.vcxproj > @@ -68,6 +68,9 @@ > >0.6.0.5 > > + > + > %(AdditionalDependencies);$(KernelBufferOverflowLib);$(DDK_LIB_PATH)ntoskrnl.lib;$(DDK_LIB_PATH)hal.lib;$(DDK_LIB_PATH)wmilib.lib;$(KMDF_LIB_PATH)$(KMDF_VER_PATH)\WdfLdr.lib;$(KMDF_LIB_PATH)$(KMDF_VER_PATH)\WdfDriverEntry.lib;$(DDK_LIB_PATH)\wdmsec.lib > + > > Condition="'$(Configuration)|$(Platform)'=='Release|x64'"> > > @@ -80,6 +83,9 @@ > >0.6.0.5 > > + > + > %(AdditionalDependencies);$(KernelBufferOverflowLib);$(DDK_LIB_PATH)ntoskrnl.lib;$(DDK_LIB_PATH)hal.lib;$(DDK_LIB_PATH)wmilib.lib;$(KMDF_LIB_PATH)$(KMDF_VER_PATH)\WdfLdr.lib;$(KMDF_LIB_PATH)$(KMDF_VER_PATH)\WdfDriverEntry.lib;$(DDK_LIB_PATH)\wdmsec.lib > + > > > Commit subject doesn't match content. It this commit needed as standalone?
Re: [dpdk-dev] [PATCH 21/22] doc: updating REAME for NetUIO driver
On Thu, 13 Aug 2020 16:21:44 -0700, Narcisa Ana Maria Vasile wrote: > From: Harini Ramakrishnan > > Signed-off-by: Harini Ramakrishnan > --- > kernel/README_NetUIO.rst | 63 > 1 file changed, 63 insertions(+) > create mode 100644 kernel/README_NetUIO.rst > > diff --git a/kernel/README_NetUIO.rst b/kernel/README_NetUIO.rst > new file mode 100644 > index 0..9b21a4a8b > --- /dev/null > +++ b/kernel/README_NetUIO.rst > @@ -0,0 +1,63 @@ > +.. SPDX-License-Identifier: BSD-3-Clause > +Copyright(c) 2020 Microsoft Corporation. > + > +Compiling the NetUIO Driver from Source > +=== > + > +Operating System > + > + > +The NetUIO source has been validated against the following operating systems: > + > +* Windows Server 2016 > +* Windows Server 2019 > + > +Hardware Requirements > +~ > +The NetUIO driver has been validated using the following network adapters on > the Windows platform: > + > +* > +* NICs missing. > + > +Software Requirements > +~ > + > +* Install Microsoft Visual Studio 2017 or Visual Stuido Studio 2019 > Enterprise from https://visualstudio.microsoft.com/downloads/ AFAIK, Visual Studio 2019 Community Edition is sufficient. > + * During installation ensure following components are selected: > + Windows 10 SDK (10.0.15063.0) > + Windows 10 SDK (10.0.17763.0) > + Windows Drivers Kit > + > +* Install WDK for Windows 10 (10.0.17763.1) from > https://docs.microsoft.com/en-us/windows-hardware/drivers/download-the-wdk > + > +Building the NetUIO Driver > +-- > +Follow the steps below to build the NetUIO driver and install the driver for > the network adapter. > + > +* Clone the dpdk-kmods repository: git clone git://dpdk.org/dpdk-kmods > +* Navigate to \dpdk-kmods\windows\netuio\mk\exec-env\windows\netuio > +* Load netuio.sln in Microsoft Visual Studio 2017 or 2019 > +* Choose Release as the configuration mode and Build the solution > +* The resultant output files can be found in > \dpdk-kmods\windows\netuio\x64\Release\netuio > + > +Installing netuio.sys Driver for development > + > +NOTE: In a development environment, NetUIO driver can be loaded by enabling > test-signing. > +Please implement adequate precautionary measures before installing a > test-signed driver, replacing a signed-driver. reStructured Text syntax for banners (note, warning) is as follows: .. note:: Banner text. > + > +To ensure test-signed kernel-mode drivers can load on Windows, enable > test-signing, using the following BCDEdit command. > + > +C:\windows\system32>Bcdedit.exe -set TESTSIGNING ON > + > +Windows displays the text “Test Mode” to remind users the system has > test-signing enabled. > +Refer to the MSDN documentation on how to Test-Sign a Driver Package. There are similar instructions in windows/README.rst. You might choose to point there, but this is not a strong opinion. > + > +To procure a WHQL signed NetUIO driver for Windows, please reach out to > dpdk...@microsoft.com > + > +* Go to Device Manager -> Network Adapters. > +* Right Click on target network adapter -> Select Update Driver. > +* Select “Browse my computer for driver software”. > +* In the resultant Window, select “Let me pick from a list of available > drivers on my computer”. s/Window/window/ > +* Select “DPDK netUIO for Network Adapter” from the list of drivers. > +* The NetUIO.sys driver is successfully installed. > + > \ No newline at end of file No newline at end of file.
Re: [dpdk-dev] [PATCH 00/22] windows/netuio: add netuio driver for Windows
On Fri, Aug 14, 2020 at 11:01:39PM +0300, Dmitry Kozlyuk wrote:
> On Thu, 13 Aug 2020 16:21:23 -0700, Narcisa Ana Maria Vasile wrote:
> > From: Narcisa Vasile
> >
> > The NetUIO driver for Windows allows the usermode application
> > to directly access the hardware
>
> > and allocates the memory that gets mapped in usermode.
>
> It doesn't allocate the buffer anymore, does it?
>
> As far as I understand, you're importing history from dpdk-draft-repo and
> then changing file layout. Not sure how this is beneficial, especially
> since there are bugfixes along the way. Or are there legal reasons?
>
Harini, Omar, please advise if we need to preserve history. If not,
I think it's better to just squash all commits and send the netuio code
as one patch. In this way, I can easily make sure that this one patch
has the right signoff, description, subject formatting etc.
Dmitry, would pushing the netuio code as one patch be ok?
> Please follow the guidelines on commit formatting, in particular:
>
> * Subject must have a topic ("windows/netuio"?), its length is limited.
> * Description is mandatory and should explain the changes.
Re: [dpdk-dev] [PATCH] net/failsafe: don't double space warning
On 14/08/20 10:39 -0700, Stephen Hemminger wrote:
> Already get a newline from WARN() macro call.
>
> Fixes: 9dda3e3393c2 ("net/failsafe: add timestamp to stats snapshot")
> Cc: ma...@mellanox.com
> Signed-off-by: Stephen Hemminger
Acked-by: Gaetan Rivet
>
> ---
> drivers/net/failsafe/failsafe_ether.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/failsafe/failsafe_ether.c
> b/drivers/net/failsafe/failsafe_ether.c
> index 2b748bd8b426..70972d67174f 100644
> --- a/drivers/net/failsafe/failsafe_ether.c
> +++ b/drivers/net/failsafe/failsafe_ether.c
> @@ -322,10 +322,10 @@ fs_dev_stats_save(struct sub_device *sdev)
> if (err) {
> uint64_t timestamp = sdev->stats_snapshot.timestamp;
>
> - WARN("Could not access latest statistics from sub-device %d.\n",
> + WARN("Could not access latest statistics from sub-device %d.",
>SUB_ID(sdev));
> if (timestamp != 0)
> - WARN("Using latest snapshot taken before %"PRIu64"
> seconds.\n",
> + WARN("Using latest snapshot taken before %"PRIu64"
> seconds.",
>(rte_rdtsc() - timestamp) / rte_get_tsc_hz());
> }
> failsafe_stats_increment
> --
> 2.27.0
>
--
Gaëtan
Re: [dpdk-dev] [PATCH] net/failsafe: don't double space warning
On 14/08/20 22:28 +0200, Gaëtan Rivet wrote:
> On 14/08/20 10:39 -0700, Stephen Hemminger wrote:
> > Already get a newline from WARN() macro call.
> >
> > Fixes: 9dda3e3393c2 ("net/failsafe: add timestamp to stats snapshot")
> > Cc: ma...@mellanox.com
> > Signed-off-by: Stephen Hemminger
>
> Acked-by: Gaetan Rivet
>
Ah, I forgot: the patch itself is fine, but it should be backported
probably. Missing Cc: stable, Fixes, and the title should be reworded "fix
double space warning" I think.
> >
> > ---
> > drivers/net/failsafe/failsafe_ether.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/failsafe/failsafe_ether.c
> > b/drivers/net/failsafe/failsafe_ether.c
> > index 2b748bd8b426..70972d67174f 100644
> > --- a/drivers/net/failsafe/failsafe_ether.c
> > +++ b/drivers/net/failsafe/failsafe_ether.c
> > @@ -322,10 +322,10 @@ fs_dev_stats_save(struct sub_device *sdev)
> > if (err) {
> > uint64_t timestamp = sdev->stats_snapshot.timestamp;
> >
> > - WARN("Could not access latest statistics from sub-device %d.\n",
> > + WARN("Could not access latest statistics from sub-device %d.",
> > SUB_ID(sdev));
> > if (timestamp != 0)
> > - WARN("Using latest snapshot taken before %"PRIu64"
> > seconds.\n",
> > + WARN("Using latest snapshot taken before %"PRIu64"
> > seconds.",
> > (rte_rdtsc() - timestamp) / rte_get_tsc_hz());
> > }
> > failsafe_stats_increment
> > --
> > 2.27.0
> >
>
> --
> Gaëtan
--
Gaëtan
Re: [dpdk-dev] [PATCH 00/22] windows/netuio: add netuio driver for Windows
On Fri, 14 Aug 2020 13:26:11 -0700, Narcisa Ana Maria Vasile wrote: > On Fri, Aug 14, 2020 at 11:01:39PM +0300, Dmitry Kozlyuk wrote: > > On Thu, 13 Aug 2020 16:21:23 -0700, Narcisa Ana Maria Vasile wrote: [...] > > As far as I understand, you're importing history from dpdk-draft-repo and > > then changing file layout. Not sure how this is beneficial, especially > > since there are bugfixes along the way. Or are there legal reasons? > > > Harini, Omar, please advise if we need to preserve history. If not, > I think it's better to just squash all commits and send the netuio code > as one patch. In this way, I can easily make sure that this one patch > has the right signoff, description, subject formatting etc. > > Dmitry, would pushing the netuio code as one patch be ok? Yes, I think so.
Re: [dpdk-dev] [PATCH 00/22] windows/netuio: add netuio driver for Windows
On 8/14/2020 1:57 PM, Dmitry Kozlyuk wrote: On Fri, 14 Aug 2020 13:26:11 -0700, Narcisa Ana Maria Vasile wrote: On Fri, Aug 14, 2020 at 11:01:39PM +0300, Dmitry Kozlyuk wrote: On Thu, 13 Aug 2020 16:21:23 -0700, Narcisa Ana Maria Vasile wrote: [...] As far as I understand, you're importing history from dpdk-draft-repo and then changing file layout. Not sure how this is beneficial, especially since there are bugfixes along the way. Or are there legal reasons? Harini, Omar, please advise if we need to preserve history. If not, I think it's better to just squash all commits and send the netuio code as one patch. In this way, I can easily make sure that this one patch has the right signoff, description, subject formatting etc. Dmitry, would pushing the netuio code as one patch be ok? Yes, I think so. I agree too. This code is going to be committed into a new repo (kmods), so there is no real benefit in maintaining prior history. ranjit m.
Re: [dpdk-dev] [PATCH 00/22] windows/netuio: add netuio driver for Windows
Hi Naty,
IMHO this is small and sufficiently scoped where history (individual buildable
patches) are not necessary. We'd prefer to avoid that overhead here.
DmitryK,
Please let us know if otherwise.
-Original Message-
From: Narcisa Ana Maria Vasile
Sent: Friday, August 14, 2020 1:26 PM
To: Dmitry Kozlyuk
Cc: dev@dpdk.org; tho...@monjalon.net; haram...@linux.microsoft.com; Omar
Cardona ; pallavi.ka...@intel.com;
ranjit.me...@intel.com; Dmitry Malloy (MESHCHANINOV) ;
Narcisa Ana Maria Vasile
Subject: Re: [PATCH 00/22] windows/netuio: add netuio driver for Windows
On Fri, Aug 14, 2020 at 11:01:39PM +0300, Dmitry Kozlyuk wrote:
> On Thu, 13 Aug 2020 16:21:23 -0700, Narcisa Ana Maria Vasile wrote:
> > From: Narcisa Vasile
> >
> > The NetUIO driver for Windows allows the usermode application to
> > directly access the hardware
>
> > and allocates the memory that gets mapped in usermode.
>
> It doesn't allocate the buffer anymore, does it?
>
> As far as I understand, you're importing history from dpdk-draft-repo
> and then changing file layout. Not sure how this is beneficial,
> especially since there are bugfixes along the way. Or are there legal reasons?
>
Harini, Omar, please advise if we need to preserve history. If not, I think
it's better to just squash all commits and send the netuio code as one patch.
In this way, I can easily make sure that this one patch has the right signoff,
description, subject formatting etc.
Dmitry, would pushing the netuio code as one patch be ok?
> Please follow the guidelines on commit formatting, in particular:
>
> * Subject must have a topic ("windows/netuio"?), its length is limited.
> * Description is mandatory and should explain the changes.
Re: [dpdk-dev] [PATCH v3 2/7] app/proc-info: eliminate useless borders
> > > Hi Stephen, > > > > > > > > > snipped > > > > > > > > > > snipped > > > > > > > > > > > > > > snipped > > > > > > > > > > > > > > > > 15/07/2020 23:22, Stephen Hemminger: > > > > > > > > > Printing extra borders does not improve readability, and > > > > > > > > > is just unnecessary. Putting TSC hz in header also makes > > > > > > > > > no sense > > > here. > > > > > > > > > > > > > > > > The CPU frequency on headers! > > > > > > > > OK to remove :) > > > > > > > > > > > > > > > > > > > > > > The rational of having Time Stamp Counter as the header for > > > > > > > port info and > > > > > > stats, is to account for each iteration for an average > > > > > > `packets per second`. That is using `watch -d -n 1 > > > > > > ./dpdk-procinfo -- --xstats | grep - > > > v ": 0"`. > > > > > > > > > > > > > > But if there better way to do this or add as new feature, +1 to > remove. > > > > > > > > > > > > Proc info should just use standard clock for its updates, not TSC? > > > > > > > > > > Can you please explain the rationale behind the (syscall for > > > > > time) and not > > > TSC? > > > > > > > > Looking forward for the patch with clock change too. > > > > > > There is no part of what proc-info is show with xstats that displays > > > or uses tsc directly. > > > Do you have a driver that is putting TSC information in xstats? > > > > I am sorry I did not follow you on this, In the earlier implementation with > `proc-info` header we had TSC so coupling `--show --xstats`. But with the > header removed out with TSC, how can we get this? > > I am asking why is the TSC hz a useful piece of information here? > Sure, proc-info could print lots of things but unless it serves a useful > purpose > for examining the interfaces, it is just noise. > > Developers love to clutter output, but it just raises the signal to noise > ratio. Thanks for the update, as mentioned earlier from my end `+1` for cleaning up the console output interface. Also `+1` for adding option to get timestamp too. But I am still not able to understand the suggestions like `1. Why Proc info should just use standard clock for its updates, not TSC? 2. CPU frequency in header?` As I understand standard clock is syscall and TSC is register fetch for clock ticks after reset and not CPU frequency.
