Re: [dpdk-dev] [PATCH v1] net/iavf: fix hash default set
Tested-by: Xie,WeiX < weix@intel.com>
Regards,
Xie Wei
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jeff Guo
Sent: Tuesday, August 4, 2020 10:59 AM
To: Zhang, Qi Z ; Wu, Jingjing ;
Xing, Beilei
Cc: dev@dpdk.org; Guo, Junfeng ; Su, Simei
; Guo, Jia
Subject: [dpdk-dev] [PATCH v1] net/iavf: fix hash default set
Different device has different hash capability, it should not be expected that
all hash set would be successful to set into all devices by default. So remove
the return checking when hash default set. And remove gtpu hash default set,
iavf only enable hash for general protocols.
Fixes: c94366cfc641 ("net/iavf: add GTPU in default hash")
Signed-off-by: Jeff Guo
---
drivers/net/iavf/iavf_hash.c | 23 ++-
1 file changed, 2 insertions(+), 21 deletions(-)
diff --git a/drivers/net/iavf/iavf_hash.c b/drivers/net/iavf/iavf_hash.c index
e2eebd2d3..c06b52ea9 100644
--- a/drivers/net/iavf/iavf_hash.c
+++ b/drivers/net/iavf/iavf_hash.c
@@ -3639,18 +3639,6 @@ struct virtchnl_proto_hdrs *iavf_hash_default_hdrs[] = {
&hdrs_hint_ipv6_udp,
&hdrs_hint_ipv6_tcp,
&hdrs_hint_ipv6_sctp,
- &hdrs_hint_ipv4_gtpu_ip,
- &hdrs_hint_ipv4_udp_gtpu_ip,
- &hdrs_hint_ipv4_tcp_gtpu_ip,
- &hdrs_hint_ipv4_gtpu_eh,
- &hdrs_hint_ipv4_udp_gtpu_eh,
- &hdrs_hint_ipv4_tcp_gtpu_eh,
- &hdrs_hint_ipv6_gtpu_ip,
- &hdrs_hint_ipv6_udp_gtpu_ip,
- &hdrs_hint_ipv6_tcp_gtpu_ip,
- &hdrs_hint_ipv6_gtpu_eh,
- &hdrs_hint_ipv6_udp_gtpu_eh,
- &hdrs_hint_ipv6_tcp_gtpu_eh,
};
static struct iavf_flow_engine iavf_hash_engine = { @@ -3676,7 +3664,6 @@
iavf_hash_default_set(struct iavf_adapter *ad, bool add) {
struct virtchnl_rss_cfg *rss_cfg;
uint16_t i;
- int ret;
rss_cfg = rte_zmalloc("iavf rss rule",
sizeof(struct virtchnl_rss_cfg), 0); @@ -3687,16
+3674,10 @@ iavf_hash_default_set(struct iavf_adapter *ad, bool add)
rss_cfg->proto_hdrs = *iavf_hash_default_hdrs[i];
rss_cfg->rss_algorithm = VIRTCHNL_RSS_ALG_TOEPLITZ_ASYMMETRIC;
- ret = iavf_add_del_rss_cfg(ad, rss_cfg, add);
- if (ret) {
- PMD_DRV_LOG(ERR, "fail to %s RSS configure",
- add ? "add" : "delete");
- rte_free(rss_cfg);
- return ret;
- }
+ iavf_add_del_rss_cfg(ad, rss_cfg, add);
}
- return ret;
+ return 0;
}
RTE_INIT(iavf_hash_engine_init)
--
2.20.1
[dpdk-dev] [PATCH v2 1/4] net/virtio: add DEVICE_NEEDS_RESET status bit
For the sake of completeness, add the definition of the missing status bit in accordance with the virtio spec Signed-off-by: Adrian Moreno --- drivers/net/virtio/virtio_pci.h | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/net/virtio/virtio_pci.h b/drivers/net/virtio/virtio_pci.h index 74ed77e33..ab61e911b 100644 --- a/drivers/net/virtio/virtio_pci.h +++ b/drivers/net/virtio/virtio_pci.h @@ -57,12 +57,13 @@ struct virtnet_ctl; #define VIRTIO_ID_9P 0x09 /* Status byte for guest to report progress. */ -#define VIRTIO_CONFIG_STATUS_RESET 0x00 -#define VIRTIO_CONFIG_STATUS_ACK 0x01 -#define VIRTIO_CONFIG_STATUS_DRIVER0x02 -#define VIRTIO_CONFIG_STATUS_DRIVER_OK 0x04 -#define VIRTIO_CONFIG_STATUS_FEATURES_OK 0x08 -#define VIRTIO_CONFIG_STATUS_FAILED0x80 +#define VIRTIO_CONFIG_STATUS_RESET 0x00 +#define VIRTIO_CONFIG_STATUS_ACK 0x01 +#define VIRTIO_CONFIG_STATUS_DRIVER0x02 +#define VIRTIO_CONFIG_STATUS_DRIVER_OK 0x04 +#define VIRTIO_CONFIG_STATUS_FEATURES_OK 0x08 +#define VIRTIO_CONFIG_STATUS_DEV_NEED_RESET0x40 +#define VIRTIO_CONFIG_STATUS_FAILED0x80 /* * Each virtqueue indirect descriptor list must be physically contiguous. -- 2.26.2
[dpdk-dev] [PATCH v2 0/4] Add support for GET/SET_STATUS on virtio-user pmd
Recently, two new messages have been added to the vhost-user protocol that make the device initialization more robust. VHOST_VIRTIO_SET_STATUS allows the driver to set the device status VHOST_VIRTIO_GET_STATUS allows the driver to read the status back from the device This series implements these features in the virtio-user pmd --- v2: - Drop "net/virtio: split virtio-net and virtio status" An identical patch has already been merged - [Chenbo] Log when set-status fails Adrian Moreno (3): net/virtio: add DEVICE_NEEDS_RESET status bit net/virtio: add GET_STATUS support to virtio-user net/virtio: enable feature checking on virtio-user Maxime Coquelin (1): net/virtio: add VIRTIO_SET_STATUS support to Virtio-user drivers/net/virtio/virtio_ethdev.c| 13 ++-- drivers/net/virtio/virtio_pci.h | 13 ++-- drivers/net/virtio/virtio_user/vhost.h| 6 ++ drivers/net/virtio/virtio_user/vhost_user.c | 12 .../net/virtio/virtio_user/virtio_user_dev.c | 68 ++- .../net/virtio/virtio_user/virtio_user_dev.h | 2 + drivers/net/virtio/virtio_user_ethdev.c | 3 + 7 files changed, 104 insertions(+), 13 deletions(-) -- 2.26.2
[dpdk-dev] [PATCH v2 3/4] net/virtio: add GET_STATUS support to virtio-user
This patch adds support for VHOST_USER_GET_STATUS request.
Only vhost-user backed is supported for now
Signed-off-by: Adrian Moreno
---
drivers/net/virtio/virtio_user/vhost_user.c | 2 +
.../net/virtio/virtio_user/virtio_user_dev.c | 42 +++
.../net/virtio/virtio_user/virtio_user_dev.h | 1 +
drivers/net/virtio/virtio_user_ethdev.c | 2 +
4 files changed, 47 insertions(+)
diff --git a/drivers/net/virtio/virtio_user/vhost_user.c
b/drivers/net/virtio/virtio_user/vhost_user.c
index 337e51199..12b6c7dbc 100644
--- a/drivers/net/virtio/virtio_user/vhost_user.c
+++ b/drivers/net/virtio/virtio_user/vhost_user.c
@@ -279,6 +279,7 @@ vhost_user_sock(struct virtio_user_dev *dev,
switch (req) {
case VHOST_USER_GET_FEATURES:
case VHOST_USER_GET_PROTOCOL_FEATURES:
+ case VHOST_USER_GET_STATUS:
need_reply = 1;
break;
@@ -373,6 +374,7 @@ vhost_user_sock(struct virtio_user_dev *dev,
switch (req) {
case VHOST_USER_GET_FEATURES:
+ case VHOST_USER_GET_STATUS:
case VHOST_USER_GET_PROTOCOL_FEATURES:
if (msg.size != sizeof(m.payload.u64)) {
PMD_DRV_LOG(ERR, "Received bad msg size");
diff --git a/drivers/net/virtio/virtio_user/virtio_user_dev.c
b/drivers/net/virtio/virtio_user/virtio_user_dev.c
index 670fc9d40..a5b2d7057 100644
--- a/drivers/net/virtio/virtio_user/virtio_user_dev.c
+++ b/drivers/net/virtio/virtio_user/virtio_user_dev.c
@@ -807,3 +807,45 @@ virtio_user_send_status_update(struct virtio_user_dev
*dev, uint8_t status)
return 0;
}
+
+int
+virtio_user_update_status(struct virtio_user_dev *dev)
+{
+ uint64_t ret;
+ int err;
+
+ /* Vhost-user only for now */
+ if (!is_vhost_user_by_type(dev->path))
+ return 0;
+
+ if (!(dev->protocol_features & (1UL << VHOST_USER_PROTOCOL_F_STATUS)))
+ return 0;
+
+ err = dev->ops->send_request(dev, VHOST_USER_GET_STATUS, &ret);
+ if (err) {
+ PMD_INIT_LOG(ERR, "VHOST_USER_GET_STATUS failed (%d): %s", err,
+strerror(errno));
+ return -1;
+ }
+ if (ret > UINT8_MAX) {
+ PMD_INIT_LOG(ERR, "Invalid VHOST_USER_GET_STATUS response 0x%"
PRIx64 "\n", ret);
+ return -1;
+ }
+
+ dev->status = ret;
+ PMD_INIT_LOG(DEBUG, "Updated Device Status(0x%08x):\n"
+ "\t-ACKNOWLEDGE: %u\n"
+ "\t-DRIVER: %u\n"
+ "\t-DRIVER_OK: %u\n"
+ "\t-FEATURES_OK: %u\n"
+ "\t-DEVICE_NEED_RESET: %u\n"
+ "\t-FAILED: %u\n",
+ dev->status,
+ !!(dev->status & VIRTIO_CONFIG_STATUS_ACK),
+ !!(dev->status & VIRTIO_CONFIG_STATUS_DRIVER),
+ !!(dev->status & VIRTIO_CONFIG_STATUS_DRIVER_OK),
+ !!(dev->status & VIRTIO_CONFIG_STATUS_FEATURES_OK),
+ !!(dev->status & VIRTIO_CONFIG_STATUS_DEV_NEED_RESET),
+ !!(dev->status & VIRTIO_CONFIG_STATUS_FAILED));
+ return 0;
+}
diff --git a/drivers/net/virtio/virtio_user/virtio_user_dev.h
b/drivers/net/virtio/virtio_user/virtio_user_dev.h
index 835ab64ae..9377d5ba6 100644
--- a/drivers/net/virtio/virtio_user/virtio_user_dev.h
+++ b/drivers/net/virtio/virtio_user/virtio_user_dev.h
@@ -73,4 +73,5 @@ void virtio_user_handle_cq_packed(struct virtio_user_dev *dev,
uint16_t queue_idx);
uint8_t virtio_user_handle_mq(struct virtio_user_dev *dev, uint16_t q_pairs);
int virtio_user_send_status_update(struct virtio_user_dev *dev, uint8_t
status);
+int virtio_user_update_status(struct virtio_user_dev *dev);
#endif
diff --git a/drivers/net/virtio/virtio_user_ethdev.c
b/drivers/net/virtio/virtio_user_ethdev.c
index 785882e06..87f6cb695 100644
--- a/drivers/net/virtio/virtio_user_ethdev.c
+++ b/drivers/net/virtio/virtio_user_ethdev.c
@@ -280,6 +280,8 @@ virtio_user_get_status(struct virtio_hw *hw)
{
struct virtio_user_dev *dev = virtio_user_get_dev(hw);
+ virtio_user_update_status(dev);
+
return dev->status;
}
--
2.26.2
[dpdk-dev] [PATCH v2 2/4] net/virtio: add VIRTIO_SET_STATUS support to Virtio-user
From: Maxime Coquelin
This patch adds support for VHOST_USER_SET_STATUS
request. It is used to make the backend aware of
Virtio devices status update.
It is useful for the backend to know when the Virtio
driver is done with the Virtio device configuration.
Signed-off-by: Maxime Coquelin
Signed-off-by: Adrian Moreno
---
drivers/net/virtio/virtio_user/vhost.h| 6 +
drivers/net/virtio/virtio_user/vhost_user.c | 10 +++
.../net/virtio/virtio_user/virtio_user_dev.c | 26 ++-
.../net/virtio/virtio_user/virtio_user_dev.h | 1 +
drivers/net/virtio/virtio_user_ethdev.c | 1 +
5 files changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/net/virtio/virtio_user/vhost.h
b/drivers/net/virtio/virtio_user/vhost.h
index 260e1c308..8f49ef457 100644
--- a/drivers/net/virtio/virtio_user/vhost.h
+++ b/drivers/net/virtio/virtio_user/vhost.h
@@ -57,6 +57,10 @@ struct vhost_vring_addr {
#define VHOST_USER_PROTOCOL_F_REPLY_ACK 3
#endif
+#ifndef VHOST_USER_PROTOCOL_F_STATUS
+#define VHOST_USER_PROTOCOL_F_STATUS 16
+#endif
+
enum vhost_user_request {
VHOST_USER_NONE = 0,
VHOST_USER_GET_FEATURES = 1,
@@ -77,6 +81,8 @@ enum vhost_user_request {
VHOST_USER_SET_PROTOCOL_FEATURES = 16,
VHOST_USER_GET_QUEUE_NUM = 17,
VHOST_USER_SET_VRING_ENABLE = 18,
+ VHOST_USER_SET_STATUS = 39,
+ VHOST_USER_GET_STATUS = 40,
VHOST_USER_MAX
};
diff --git a/drivers/net/virtio/virtio_user/vhost_user.c
b/drivers/net/virtio/virtio_user/vhost_user.c
index ad48bafd4..337e51199 100644
--- a/drivers/net/virtio/virtio_user/vhost_user.c
+++ b/drivers/net/virtio/virtio_user/vhost_user.c
@@ -244,6 +244,8 @@ const char * const vhost_msg_strings[] = {
[VHOST_USER_SET_VRING_ENABLE] = "VHOST_SET_VRING_ENABLE",
[VHOST_USER_GET_PROTOCOL_FEATURES] = "VHOST_USER_GET_PROTOCOL_FEATURES",
[VHOST_USER_SET_PROTOCOL_FEATURES] = "VHOST_USER_SET_PROTOCOL_FEATURES",
+ [VHOST_USER_SET_STATUS] = "VHOST_SET_STATUS",
+ [VHOST_USER_GET_STATUS] = "VHOST_GET_STATUS",
};
static int
@@ -280,6 +282,14 @@ vhost_user_sock(struct virtio_user_dev *dev,
need_reply = 1;
break;
+ case VHOST_USER_SET_STATUS:
+ if (!(dev->protocol_features &
+ (1ULL << VHOST_USER_PROTOCOL_F_STATUS)))
+ return 0;
+
+ if (has_reply_ack)
+ msg.flags |= VHOST_USER_NEED_REPLY_MASK;
+ /* Fallthrough */
case VHOST_USER_SET_FEATURES:
case VHOST_USER_SET_PROTOCOL_FEATURES:
case VHOST_USER_SET_LOG_BASE:
diff --git a/drivers/net/virtio/virtio_user/virtio_user_dev.c
b/drivers/net/virtio/virtio_user/virtio_user_dev.c
index 0a6991bcc..670fc9d40 100644
--- a/drivers/net/virtio/virtio_user/virtio_user_dev.c
+++ b/drivers/net/virtio/virtio_user/virtio_user_dev.c
@@ -424,7 +424,8 @@ virtio_user_dev_setup(struct virtio_user_dev *dev)
#define VIRTIO_USER_SUPPORTED_PROTOCOL_FEATURES\
(1ULL << VHOST_USER_PROTOCOL_F_MQ | \
-1ULL << VHOST_USER_PROTOCOL_F_REPLY_ACK)
+1ULL << VHOST_USER_PROTOCOL_F_REPLY_ACK | \
+1ULL << VHOST_USER_PROTOCOL_F_STATUS)
int
virtio_user_dev_init(struct virtio_user_dev *dev, char *path, int queues,
@@ -783,3 +784,26 @@ virtio_user_handle_cq(struct virtio_user_dev *dev,
uint16_t queue_idx)
__atomic_add_fetch(&vring->used->idx, 1, __ATOMIC_RELAXED);
}
}
+
+int
+virtio_user_send_status_update(struct virtio_user_dev *dev, uint8_t status)
+{
+ int ret;
+ uint64_t arg = status;
+
+ /* Vhost-user only for now */
+ if (!is_vhost_user_by_type(dev->path))
+ return 0;
+
+ if (!(dev->protocol_features & (1ULL << VHOST_USER_PROTOCOL_F_STATUS)))
+ return 0;
+
+ ret = dev->ops->send_request(dev, VHOST_USER_SET_STATUS, &arg);
+ if (ret) {
+ PMD_INIT_LOG(ERR, "VHOST_USER_SET_STATUS failed (%d): %s", ret,
+strerror(errno));
+ return -1;
+ }
+
+ return 0;
+}
diff --git a/drivers/net/virtio/virtio_user/virtio_user_dev.h
b/drivers/net/virtio/virtio_user/virtio_user_dev.h
index 554174e81..835ab64ae 100644
--- a/drivers/net/virtio/virtio_user/virtio_user_dev.h
+++ b/drivers/net/virtio/virtio_user/virtio_user_dev.h
@@ -72,4 +72,5 @@ void virtio_user_handle_cq(struct virtio_user_dev *dev,
uint16_t queue_idx);
void virtio_user_handle_cq_packed(struct virtio_user_dev *dev,
uint16_t queue_idx);
uint8_t virtio_user_handle_mq(struct virtio_user_dev *dev, uint16_t q_pairs);
+int virtio_user_send_status_update(struct virtio_user_dev *dev, uint8_t
status);
#endif
diff --git a/drivers/net/virtio/virtio_user_ethdev.c
b/drivers/net/virtio/virtio_user_ethdev.c
index 6003f6d50..785882e06 100644
--- a/drivers/net/virtio/virtio_user_ethde
[dpdk-dev] [PATCH v2 4/4] net/virtio: enable feature checking on virtio-user
virtio 1.0 introduced a mechanism for the driver to verify that the
feature bits it sets are accepted by the device. This mechanism consists
in setting the VIRTIO_STATUS_FEATURE_OK status bit and re-reading it,
whitch gives a chance for the device to clear it if the the features
were not accepted.
This is currently being done only in modern virtio-pci devices but since
the appropriate vhost-user messages have been added, it can also be done
in virtio-user (vhost-user only).
This patch activates this mechanism on virtio-user.
Signed-off-by: Adrian Moreno
---
drivers/net/virtio/virtio_ethdev.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/virtio/virtio_ethdev.c
b/drivers/net/virtio/virtio_ethdev.c
index dc0093bdf..9063bfeb2 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -1355,12 +1355,13 @@ virtio_negotiate_features(struct virtio_hw *hw,
uint64_t req_features)
PMD_INIT_LOG(DEBUG, "features after negotiate = %" PRIx64,
hw->guest_features);
- if (hw->modern) {
- if (!vtpci_with_feature(hw, VIRTIO_F_VERSION_1)) {
- PMD_INIT_LOG(ERR,
- "VIRTIO_F_VERSION_1 features is not enabled.");
- return -1;
- }
+ if (hw->modern && !vtpci_with_feature(hw, VIRTIO_F_VERSION_1)) {
+ PMD_INIT_LOG(ERR,
+ "VIRTIO_F_VERSION_1 features is not enabled.");
+ return -1;
+ }
+
+ if (hw->modern || hw->virtio_user_dev) {
vtpci_set_status(hw, VIRTIO_CONFIG_STATUS_FEATURES_OK);
if (!(vtpci_get_status(hw) & VIRTIO_CONFIG_STATUS_FEATURES_OK))
{
PMD_INIT_LOG(ERR,
--
2.26.2
Re: [dpdk-dev] [PATCH] doc: announce deprecation of port mirroring API
On Mon, Aug 3, 2020 at 5:33 PM Thomas Monjalon wrote: > > A new API is planned to be introduced for sampling and mirroring > with rte_flow. It should be more generic and allow more use cases. > > This deprecation is to show the direction, avoiding overlapping APIs. > > Signed-off-by: Thomas Monjalon Acked-by: David Marchand -- David Marchand
Re: [dpdk-dev] [PATCH] doc: announce removal of ethdev flow director API
On Mon, Aug 3, 2020 at 7:49 PM Thomas Monjalon wrote: > > The flow director config, part of the legacy filtering API, > was marked as deprecated last year. > A separate notice is added to make clear that these specific structs > will be removed as well in DPDK 20.11, as the rest of the legacy > filtering API. > > Signed-off-by: Thomas Monjalon Acked-by: David Marchand -- David Marchand
[dpdk-dev] [PATCH] devtools: ignore PREFER_FALLTHROUGH
The PREFER_FALLTHROUGH check warns if a passthrough comment is found
because, in the kernel, the special macro "fallthrough" is prefered.
Since that keyword is not defined in DPDK, ignore the warning.
Ignoring this check does not affect the MISSING_BREAK check that will
warn if a switch case/default is not preceded by break or a fallthrough
comment.
Signed-off-by: Adrian Moreno
---
devtools/checkpatches.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/devtools/checkpatches.sh b/devtools/checkpatches.sh
index acf921ae0..4283ca82b 100755
--- a/devtools/checkpatches.sh
+++ b/devtools/checkpatches.sh
@@ -33,7 +33,7 @@ VOLATILE,PREFER_PACKED,PREFER_ALIGNED,PREFER_PRINTF,\
PREFER_KERNEL_TYPES,BIT_MACRO,CONST_STRUCT,\
SPLIT_STRING,LONG_LINE_STRING,C99_COMMENT_TOLERANCE,\
LINE_SPACING,PARENTHESIS_ALIGNMENT,NETWORKING_BLOCK_COMMENT_STYLE,\
-NEW_TYPEDEFS,COMPARISON_TO_NULL"
+NEW_TYPEDEFS,COMPARISON_TO_NULL,PREFER_FALLTHROUGH"
options="$options $DPDK_CHECKPATCH_OPTIONS"
print_usage () {
--
2.26.2
Re: [dpdk-dev] [PATCH] doc: eventdev ABI change to support DLB PMD
On Mon, Aug 3, 2020 at 11:28 PM McDaniel, Timothy wrote: > > From: "McDaniel, Timothy" There is still "," in the name. > > The ABI changes associated with this notification will better support > devices that: > 1. Have limits on the number or queues that may be linked to a port > 2. Have ports that are limited to exactly one linked queue > 3. Are not able to transparently transfer the event flow_id field > > Signed-off-by: McDaniel Timothy > Acked-by: Jerin Jacob > --- > doc/guides/rel_notes/deprecation.rst | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index 99c9806..bfe6661 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -148,3 +148,14 @@ Deprecation Notices >Python 2 support will be completely removed in 20.11. >In 20.08, explicit deprecation warnings will be displayed when running >scripts with Python 2. > + > +* eventdev: ABI changes to support DLB PMD and future extensions: > + ``rte_event_dev_info``, ``rte_event_dev_config``, ``rte_event_port_conf`` > will > + be modified to support DLB PMD and future extensions in the eventdev > library. > + Patches containing justification, documentation, and proposed modifications > + can be found at: > + > + - https://patches.dpdk.org/patch/71457/ > + - https://patches.dpdk.org/patch/71456/ > + > + > -- > 1.7.10 >
Re: [dpdk-dev] [PATCH] devtools: ignore PREFER_FALLTHROUGH
On 8/4/2020 8:38 AM, Adrian Moreno wrote: > The PREFER_FALLTHROUGH check warns if a passthrough comment is found > because, in the kernel, the special macro "fallthrough" is prefered. > > Since that keyword is not defined in DPDK, ignore the warning. > > Ignoring this check does not affect the MISSING_BREAK check that will > warn if a switch case/default is not preceded by break or a fallthrough > comment. > > Signed-off-by: Adrian Moreno Acked-by: Ferruh Yigit
Re: [dpdk-dev] [PATCH] doc: announce removal of ethdev flow director API
> On Mon, Aug 3, 2020 at 7:49 PM Thomas Monjalon > wrote: > > > > The flow director config, part of the legacy filtering API, was marked > > as deprecated last year. > > A separate notice is added to make clear that these specific structs > > will be removed as well in DPDK 20.11, as the rest of the legacy > > filtering API. > > > > Signed-off-by: Thomas Monjalon > > Acked-by: David Marchand Acked-by: Hemant Agrawal
Re: [dpdk-dev] [PATCH] doc: announce removal of L2 tunnel filtering API
On Mon, Aug 3, 2020 at 8:06 PM Thomas Monjalon wrote: > > The functions for L2 tunnel were missed when marking the legacy > filtering API as deprecated. That's why a separate notice is done > to make clear that it will be removed as well in DPDK 20.11. > > Signed-off-by: Thomas Monjalon Acked-by: David Marchand -- David Marchand
Re: [dpdk-dev] [PATCH] doc: announce removal of legacy ethdev filtering API
On Mon, Aug 3, 2020 at 1:49 PM Thomas Monjalon wrote: > > Deprecation of rte_eth_dev_filter_ctrl() was announced in 2016, > and confirmed last year by avoiding include of rte_eth_ctrl.h. > After 4 years, it is time to complete the removal of the API > which is replaced with rte_flow. > > Signed-off-by: Thomas Monjalon Acked-by: David Marchand -- David Marchand
Re: [dpdk-dev] [PATCH] doc: announce removal of L2 tunnel filtering API
On Mon, Aug 3, 2020 at 11:06 AM Thomas Monjalon wrote: > The functions for L2 tunnel were missed when marking the legacy > filtering API as deprecated. That's why a separate notice is done > to make clear that it will be removed as well in DPDK 20.11. > > Signed-off-by: Thomas Monjalon > Acked-by: Ajit Khaparde > --- > doc/guides/rel_notes/deprecation.rst | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index ea4cfa7a48..cad2f777f2 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -84,6 +84,12 @@ Deprecation Notices >Target release for removal of the legacy API will be defined once most >PMDs have switched to rte_flow. > > +* ethdev: the legacy L2 tunnel filtering API is deprecated as the rest of > + the legacy filtering API. > + The functions ``rte_eth_dev_l2_tunnel_eth_type_conf`` and > + ``rte_eth_dev_l2_tunnel_offload_set`` which were not marked as > deprecated, > + will be removed in DPDK 20.11. > + > * ethdev: Update API functions returning ``void`` to return ``int`` with >negative errno values to indicate various error conditions (e.g. >invalid port ID, unsupported operation, failed operation): > -- > 2.27.0 > >
Re: [dpdk-dev] [PATCH] devtools: ignore PREFER_FALLTHROUGH
> -Original Message-
> From: Adrian Moreno
> Sent: Tuesday, August 4, 2020 3:39 PM
> To: dev@dpdk.org
> Cc: tho...@monjalon.net; Xia, Chenbo ;
> david.march...@redhat.com; Adrian Moreno
> Subject: [PATCH] devtools: ignore PREFER_FALLTHROUGH
>
> The PREFER_FALLTHROUGH check warns if a passthrough comment is found
> because, in the kernel, the special macro "fallthrough" is prefered.
>
> Since that keyword is not defined in DPDK, ignore the warning.
>
> Ignoring this check does not affect the MISSING_BREAK check that will warn if
> a
> switch case/default is not preceded by break or a fallthrough comment.
>
> Signed-off-by: Adrian Moreno
> ---
> devtools/checkpatches.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/devtools/checkpatches.sh b/devtools/checkpatches.sh index
> acf921ae0..4283ca82b 100755
> --- a/devtools/checkpatches.sh
> +++ b/devtools/checkpatches.sh
> @@ -33,7 +33,7 @@
> VOLATILE,PREFER_PACKED,PREFER_ALIGNED,PREFER_PRINTF,\
> PREFER_KERNEL_TYPES,BIT_MACRO,CONST_STRUCT,\
> SPLIT_STRING,LONG_LINE_STRING,C99_COMMENT_TOLERANCE,\
>
> LINE_SPACING,PARENTHESIS_ALIGNMENT,NETWORKING_BLOCK_COMMENT_
> STYLE,\
> -NEW_TYPEDEFS,COMPARISON_TO_NULL"
> +NEW_TYPEDEFS,COMPARISON_TO_NULL,PREFER_FALLTHROUGH"
> options="$options $DPDK_CHECKPATCH_OPTIONS"
>
> print_usage () {
> --
> 2.26.2
Acked-by: Chenbo Xia
Re: [dpdk-dev] [PATCH v2 1/2] doc: announce rte_dev_probe() API change
On Thu, Jun 25, 2020 at 10:04 AM Maxime Coquelin wrote: > > In order to simplify the use of rte_dev_probe() and > rte_dev_remove() by applications, rte_dev_probe() will > return a reference on the rte_device stating DPDK v20.11. > > Signed-off-by: Maxime Coquelin Acked-by: David Marchand -- David Marchand
[dpdk-dev] [PATCH v2] doc: update RSS action with best effort
Using the rte_flow action RSS types field, may result in undefined outcome. For example selecting both UDP and TCP, selecting TCP RSS type but the pattern is targeting UDP traffic. another option is that the PMD doesn't support all requested types. Until now, it wasn't clear what will happen in such cases. This commit clarify this issue by stating that the PMD will work in the best-effort mode. Signed-off-by: Ori Kam --- v2: * Based on ML, update that using only unsupported hash type may cause the flow to be rejected by PMD. --- doc/guides/prog_guide/rte_flow.rst | 11 +++ 1 file changed, 11 insertions(+) diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst index 3e5cd1e..d730b66 100644 --- a/doc/guides/prog_guide/rte_flow.rst +++ b/doc/guides/prog_guide/rte_flow.rst @@ -1735,6 +1735,17 @@ unspecified "best-effort" settings from the underlying PMD, which depending on the flow rule, may result in anything ranging from empty (single queue) to all-inclusive RSS. +Best effort will be used, in case there is a conflict inside the rule. +The conflict can be the result of: + +- Conflicting RSS types, for example setting both UDP and TCP. + +- Conflicting between RSS types and the requested pattern to match, + for example matching on UDP and hashing RSS on TCP. + +If requested RSS hash type is not supported, +and no supported hash type is requested then the PMD may reject the flow. + Note: RSS hash result is stored in the ``hash.rss`` mbuf field which overlaps ``hash.fdir.lo``. Since `Action: MARK`_ sets the ``hash.fdir.hi`` field only, both can be requested simultaneously. -- 1.8.3.1
[dpdk-dev] [PATCH] doc: announce PCI resources map API removal
The PCI resources map API (pci_map_resource/pci_unmap_resource) was
imposing use of Unix mmap flags while it does not make sense on Windows.
This API was only used to internally setup PCI devices in the PCI bus
driver and has no known external users.
Announce its removal in 20.11 with its associated structures.
The workaround implemented in the commit 9d2b24593724 ("pci: keep API
compatibility with mmap values") will be removed at the same time.
Signed-off-by: David Marchand
---
doc/guides/rel_notes/deprecation.rst | 11 +++
1 file changed, 11 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst
b/doc/guides/rel_notes/deprecation.rst
index ea4cfa7a48..24808c002c 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -67,6 +67,17 @@ Deprecation Notices
us extending existing enum/define.
One solution can be using a fixed size array instead of ``.*MAX.*`` value.
+* pci: The PCI resources map API (``pci_map_resource`` and
+ ``pci_unmap_resource``) was not abstracting the Unix mmap flags (see the
+ workaround for Windows support implemented in the commit
+ 9d2b24593724 ("pci: keep API compatibility with mmap values")).
+ This API will be removed from the public API in 20.11 and moved to the PCI
+ bus driver along with the PCI resources lists and associated structures
+ (``pci_map``, ``pci_msix_table``, ``mapped_pci_resource`` and
+ ``mapped_pci_res_list``).
+ With this removal, there won't be a need for the mentioned workaround which
+ will be reverted.
+
* ethdev: Split the ``struct eth_dev_ops`` struct to hide it as much as
possible
will be done in 20.11.
Currently the ``struct eth_dev_ops`` struct is accessible by the application
--
2.23.0
Re: [dpdk-dev] [20.11, PATCH v2] baseband/fpga_5gnr_fec: add companion PF config App
Hi Nicolas, On 8/3/20 6:18 PM, Chautru, Nicolas wrote: > Hi Maxime, Thomas, > >> From: Maxime Coquelin >> Hi Nicolas, >> >> On 7/31/20 5:17 PM, Chautru, Nicolas wrote: >>> Hi Maxime, >>> Hi Nicolas, On 7/16/20 10:20 PM, Nicolas Chautru wrote: > Adding companion application to configure HW Device from the PF. > Then the device can be accessed through BBDEV from VF (or PF). > > Signed-off-by: Nicolas Chautru > --- > doc/guides/bbdevs/fpga_5gnr_fec.rst| 80 +++-- > .../baseband/fpga_5gnr_fec/pf_config_app/Makefile | 36 +++ > .../fpga_5gnr_fec/pf_config_app/config_app.c | 333 +++ > .../pf_config_app/fpga_5gnr_cfg_app.c | 351 + > .../pf_config_app/fpga_5gnr_cfg_app.h | 102 ++ > .../pf_config_app/fpga_5gnr_cfg_parser.c | 187 +++ > .../pf_config_app/fpga_5gnr_config.cfg | 18 ++ > 7 files changed, 1087 insertions(+), 20 deletions(-) create mode > 100644 drivers/baseband/fpga_5gnr_fec/pf_config_app/Makefile > create mode 100644 > drivers/baseband/fpga_5gnr_fec/pf_config_app/config_app.c > create mode 100644 > drivers/baseband/fpga_5gnr_fec/pf_config_app/fpga_5gnr_cfg_app.c > create mode 100644 > drivers/baseband/fpga_5gnr_fec/pf_config_app/fpga_5gnr_cfg_app.h > create mode 100644 > >> drivers/baseband/fpga_5gnr_fec/pf_config_app/fpga_5gnr_cfg_parser.c > create mode 100644 > drivers/baseband/fpga_5gnr_fec/pf_config_app/fpga_5gnr_config.cfg I think having the pf_config_app in the driver directory is not a good idea, this is not the place for applications. Also, it is not integrated in the DPDK build system, so it cannot benefit from the CI. Having an external dependency that is not packaged in distributions will not help to have it integrated in the build >> system. >>> >>> Thanks for sharing. >>> Note that all these points were raised openly explicitly earlier as you >>> know, >> ie part of both pros and cons. >>> Still happy to get feedback from others notably Thomas. It appears you had >> side conversations with him on this very topic. >>> I see some alternatives: 1. Move it in another directory in the main DPDK repo, but it is not a DPDK example, not a dev tool and not a build tool, so it would need a new directory. 2. Create a BBDEV tools repository on dpdk.org (It would require techboard approval). 3. Host it in a dedicated repository on Intel's github 4. Move it into some Intel FPGA tools repository >>> >>> There are several others options which were indeed considered in case this >> option was not viable. >>> Still DPDK was considered best option so far to keep everything in one >> recognized place for BBDEV devices but happy to get further input from >> others. >>> I think option 3 would be the best to get it packaged into distributions as it has no build dependency with any DPDK library. You could maybe add inih library as a git sub-repository within this repo. Other advantage is you wouldn't depend on DPDK release cycles to get fixes merged. Regarding the tool itself, I understand from the commit message that the tool has a dependency on the BBDEV PMD version, but the tool run on the host while the PMD driver is used in the guest/container. So having it in the driver directory will not really help, as host DPDK (if any) and guest DPDK may come from different parties. >>> >>> Yes this was captured earlier, purely stored there as a companion >>> application for a given version of the PMD (ie. different subdirectories for >> each PMD directory). >>> They do no run in the same container for deployment and are not built at >> the same time indeed, their interface is the HW really and one being needed >> to be run prior to the other one to be functional. >>> One question I have is whether this is the tool itself that has a dependency on the PMD, or just the config file? >>> >>> Each PMD directory would have its own version of the companion PF >> config application. >>> Ie. the patch above is only for baseband/fpga_5gnr_fec ie. Intel Vista Creek >> with 5G LDPC user image. >> >> OK. Does it mean the same application and configuration will work for >> baseband/fpga_5gnr_fec PMD versions v20.11, v21.02, v21.05, etc, ...? >> >> If not, is there a way for the PMD driver to detect whether a wrong >> configuration was applied? Something like checking the FW version of a NIC >> is supported by the PMD driver. >> > > As mentioned above there is no API between the 2 config-app companion and > BBDEV/DPDK, as they belong logically to 2 different entities (possibly > containers) without shared interface except indirectly through HW. > There is no strict API which could be broken between the 2, but purely 2 SW > ingr
Re: [dpdk-dev] [PATCH] doc: announce PCI resources map API removal
On Tue, Aug 4, 2020 at 2:18 PM David Marchand wrote:
>
> The PCI resources map API (pci_map_resource/pci_unmap_resource) was
> imposing use of Unix mmap flags while it does not make sense on Windows.
> This API was only used to internally setup PCI devices in the PCI bus
> driver and has no known external users.
>
> Announce its removal in 20.11 with its associated structures.
>
> The workaround implemented in the commit 9d2b24593724 ("pci: keep API
> compatibility with mmap values") will be removed at the same time.
>
> Signed-off-by: David Marchand
Acked-by: Jerin Jacob
> ---
> doc/guides/rel_notes/deprecation.rst | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> index ea4cfa7a48..24808c002c 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -67,6 +67,17 @@ Deprecation Notices
>us extending existing enum/define.
>One solution can be using a fixed size array instead of ``.*MAX.*`` value.
>
> +* pci: The PCI resources map API (``pci_map_resource`` and
> + ``pci_unmap_resource``) was not abstracting the Unix mmap flags (see the
> + workaround for Windows support implemented in the commit
> + 9d2b24593724 ("pci: keep API compatibility with mmap values")).
> + This API will be removed from the public API in 20.11 and moved to the PCI
> + bus driver along with the PCI resources lists and associated structures
> + (``pci_map``, ``pci_msix_table``, ``mapped_pci_resource`` and
> + ``mapped_pci_res_list``).
> + With this removal, there won't be a need for the mentioned workaround which
> + will be reverted.
> +
> * ethdev: Split the ``struct eth_dev_ops`` struct to hide it as much as
> possible
>will be done in 20.11.
>Currently the ``struct eth_dev_ops`` struct is accessible by the
> application
> --
> 2.23.0
>
[dpdk-dev] [PATCH] net/bnxt: fix variable size of port id
Currenly the variable size of ethdev port id is 8 bits. This
patch standarizes it to 16 bits.
Fixes: 769de16872ab ("net/bnxt: fix port default rule create/destroy")
Cc: sta...@dpdk.org
Reported-by: Yinan Wang
Signed-off-by: Chenbo Xia
---
drivers/net/bnxt/tf_ulp/ulp_def_rules.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/bnxt/tf_ulp/ulp_def_rules.c
b/drivers/net/bnxt/tf_ulp/ulp_def_rules.c
index 9fb1a028f..ff5aed3d7 100644
--- a/drivers/net/bnxt/tf_ulp/ulp_def_rules.c
+++ b/drivers/net/bnxt/tf_ulp/ulp_def_rules.c
@@ -397,7 +397,7 @@ void
bnxt_ulp_destroy_df_rules(struct bnxt *bp, bool global)
{
struct bnxt_ulp_df_rule_info *info;
- uint8_t port_id;
+ uint16_t port_id;
if (!BNXT_TRUFLOW_EN(bp) ||
BNXT_ETH_DEV_IS_REPRESENTOR(bp->eth_dev))
--
2.17.1
Re: [dpdk-dev] [PATCH v2 1/2] doc: announce rte_dev_probe() API change
On Tue, Aug 4, 2020 at 1:42 PM David Marchand wrote: > > On Thu, Jun 25, 2020 at 10:04 AM Maxime Coquelin > wrote: > > > > In order to simplify the use of rte_dev_probe() and > > rte_dev_remove() by applications, rte_dev_probe() will > > return a reference on the rte_device stating DPDK v20.11. > > > > Signed-off-by: Maxime Coquelin > > Acked-by: David Marchand Acked-by: Jerin Jacob > > > -- > David Marchand >
Re: [dpdk-dev] [PATCH] doc: announce removal of L2 tunnel filtering API
On Tue, Aug 4, 2020 at 1:21 PM David Marchand wrote: > > On Mon, Aug 3, 2020 at 8:06 PM Thomas Monjalon wrote: > > > > The functions for L2 tunnel were missed when marking the legacy > > filtering API as deprecated. That's why a separate notice is done > > to make clear that it will be removed as well in DPDK 20.11. > > > > Signed-off-by: Thomas Monjalon > > Acked-by: David Marchand Acked-by: Jerin Jacob > > > -- > David Marchand >
[dpdk-dev] [PATCH] doc: announce ethdev port freeing on close operation
Since DPDK 18.11, some drivers are migrating to a new behaviour, releasing port resources on close. The temporary flag RTE_ETH_DEV_CLOSE_REMOVE triggers this new mode in the migrated drivers. After 2 years, the flag and the old behaviour will be removed. Last drivers not migrated will have to complete the switch. Signed-off-by: Thomas Monjalon --- doc/guides/rel_notes/deprecation.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index ea4cfa7a48..b5e8045d00 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -91,6 +91,12 @@ Deprecation Notices - ``rte_eth_dev_stop`` - ``rte_eth_dev_close`` +* ethdev: The temporary flag RTE_ETH_DEV_CLOSE_REMOVE will be removed in 20.11. + As a consequence, the new behaviour introduced in 18.11 will be effective + for all drivers: generic port resources are freed on close operation. + Private resources are expected to be released in the ``dev_close`` callback. + More details in http://inbox.dpdk.org/dev/5248162.j6AOsuQRmx@thomas/ + * ethdev: New offload flags ``DEV_RX_OFFLOAD_FLOW_MARK`` will be added in 19.11. This will allow application to enable or disable PMDs from updating ``rte_mbuf::hash::fdir``. -- 2.27.0
Re: [dpdk-dev] [PATCH] doc: announce ethdev port freeing on close operation
On Tue, Aug 4, 2020 at 2:50 PM Thomas Monjalon wrote: > > Since DPDK 18.11, some drivers are migrating to a new behaviour, > releasing port resources on close. > The temporary flag RTE_ETH_DEV_CLOSE_REMOVE triggers this new mode > in the migrated drivers. > After 2 years, the flag and the old behaviour will be removed. > Last drivers not migrated will have to complete the switch. > > Signed-off-by: Thomas Monjalon Acked-by: Jerin Jacob > --- > doc/guides/rel_notes/deprecation.rst | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index ea4cfa7a48..b5e8045d00 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -91,6 +91,12 @@ Deprecation Notices >- ``rte_eth_dev_stop`` >- ``rte_eth_dev_close`` > > +* ethdev: The temporary flag RTE_ETH_DEV_CLOSE_REMOVE will be removed in > 20.11. > + As a consequence, the new behaviour introduced in 18.11 will be effective > + for all drivers: generic port resources are freed on close operation. > + Private resources are expected to be released in the ``dev_close`` > callback. > + More details in http://inbox.dpdk.org/dev/5248162.j6AOsuQRmx@thomas/ > + > * ethdev: New offload flags ``DEV_RX_OFFLOAD_FLOW_MARK`` will be added in > 19.11. >This will allow application to enable or disable PMDs from updating >``rte_mbuf::hash::fdir``. > -- > 2.27.0 >
Re: [dpdk-dev] [PATCH] doc: announce ethdev port freeing on close operation
> On Tue, Aug 4, 2020 at 2:50 PM Thomas Monjalon > wrote: > > > > Since DPDK 18.11, some drivers are migrating to a new behaviour, > > releasing port resources on close. > > The temporary flag RTE_ETH_DEV_CLOSE_REMOVE triggers this new mode > in > > the migrated drivers. > > After 2 years, the flag and the old behaviour will be removed. > > Last drivers not migrated will have to complete the switch. > > > > Signed-off-by: Thomas Monjalon > Acked-by: Hemant Agrawal
Re: [dpdk-dev] [PATCH] app/testpmd: fix the default RSS key configuration
> -Original Message-
> From: oulijun
> Sent: Tuesday, August 4, 2020 9:29 AM
> To: Phil Yang ; wenzhuo...@intel.com;
> beilei.x...@intel.com; bernard.iremon...@intel.com;
> adrien.mazarg...@6wind.com; ferruh.yi...@intel.com
> Cc: dev@dpdk.org; linux...@huawei.com; nd
> Subject: Re: [dpdk-dev] [PATCH] app/testpmd: fix the default RSS key
> configuration
>
>
>
> 在 2020/7/17 15:29, Phil Yang 写道:
> >
> >
> Subject: [dpdk-dev] [PATCH] app/testpmd: fix the default RSS key
> configuration
>
> When an user runs a flow create cmd to configure an RSS rule
> without specifying the empty rss actions in testpmd, this mean
> that the flow gets the default RSS functions. However, the
> testpmd is not set the default RSS key incorrectly when RSS key
> is specified in flow create cmd.
> >>> Hi Lijun,
> >>>
> >>> I think it works.
> >>> When we create an RSS flow rule which doesn't specify any 'rss-hash-
> key',
> >> the 'rss-hash-key' will be updated with the default key.
> >>> Step 1:
> >>> testpmd> show port 0 rss-hash key
> >>> RSS functions:
> >>>all ipv4-frag ipv4-other ipv6-frag ipv6-other ip
> >>> RSS key:
> >>>
> >>
> 4439796BB54C5023B675EA5B124F9F30B8A2C03DDFDC4D02A08C9B334AF64A4
> >> C05C6FA343958D8557D99583AE138C92E81150366
> >>> Step 2:
> >>> testpmd> flow create 0 ingress pattern eth / ipv4 / udp / end actions rss
> >> types ipv4-udp end queues end / end
> >>> Flow rule #0 created
> >>>
> >>> Step 3:
> >>> testpmd> show port 0 rss-hash key
> >>> RSS functions:
> >>>all ipv4-udp udp
> >>> RSS key:
> >>>
> >>
> 74657374706D6427732064656661756C74205253532068617368206B65792C206F
> >> 7665727269646520697420666F722062657474
> >>>
> >>> Thanks,
> >>> Phil
> >> Yes, However, it is not the default value that users use when testpmd
> >> starts. This may mislead users. When the driver is initialized, the
> >> default key used by the driver is provided for users. The key varies
> >> according to the DPDK vendor.However, after the DPDK is initialized, if
> >> the user runs the flow create command without specifying the rss key,
> >> the driver obtains another default key value, which may be different
> >> from the default value expected by the user.
> > It needs a dummy key.
> > a4391f8bae85 - app/testpmd: set default RSS key as null
> Hi, Phil Yang
> Yes, I've reviewed the patch("a4391f8bae85 - app/testpmd: set
> default RSS key as null") and read all other people's comments.
> However, the patch has been reverted in V2 and restored to the orginal
> states. The link as follows:
> https://patches.dpdk.org/patch/47961/
I got your point now.
Your patch makes testpmd using the valid NIC default RSS hash key as the flow
rule default RSS, is that right?
The patch looks good to me. Please fix the typo in your commit message and make
it more accurate.
For example, you can put the cmd line and the expected output in the commit
message.
> I also don't think the key_len parameter is very profitable
> for users to configure. Others say that other optimizations will be
> considered later. Do you have any plans?
I have no plans for it now.
Thanks,
Phil
[dpdk-dev] [PATCH] ethdev: remove device-specific comments from VLAN API
Some confusing comments were still present from old days, when most drivers were from Intel. Signed-off-by: Thomas Monjalon --- lib/librte_ethdev/rte_ethdev.h | 11 ++- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h index 57e4a6ca58..2df4d34d0d 100644 --- a/lib/librte_ethdev/rte_ethdev.h +++ b/lib/librte_ethdev/rte_ethdev.h @@ -2846,7 +2846,6 @@ int rte_eth_dev_vlan_filter(uint16_t port_id, uint16_t vlan_id, int on); /** * Enable/Disable hardware VLAN Strip by a rx queue of an Ethernet device. - * 82599/X540/X550 can support VLAN stripping at the rx queue level * * @param port_id * The port identifier of the Ethernet device. @@ -2868,8 +2867,7 @@ int rte_eth_dev_set_vlan_strip_on_queue(uint16_t port_id, uint16_t rx_queue_id, /** * Set the Outer VLAN Ether Type by an Ethernet device, it can be inserted to - * the VLAN Header. This is a register setup available on some Intel NIC, not - * but all, please check the data sheet for availability. + * the VLAN header. * * @param port_id * The port identifier of the Ethernet device. @@ -2888,12 +2886,7 @@ int rte_eth_dev_set_vlan_ether_type(uint16_t port_id, uint16_t tag_type); /** - * Set VLAN offload configuration on an Ethernet device - * Enable/Disable Extended VLAN by an Ethernet device, This is a register setup - * available on some Intel NIC, not but all, please check the data sheet for - * availability. - * Enable/Disable VLAN Strip can be done on rx queue for certain NIC, but here - * the configuration is applied on the port level. + * Set VLAN offload configuration on an Ethernet device. * * @param port_id * The port identifier of the Ethernet device. -- 2.27.0
[dpdk-dev] [PATCH v2] ethdev: remove device-specific comments from VLAN API
Some confusing comments were still present from old days,
when most drivers were from Intel.
Signed-off-by: Thomas Monjalon
---
v2: remove i40e comment for pvid field
---
lib/librte_ethdev/rte_ethdev.h | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index 57e4a6ca58..d29930fd84 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -924,7 +924,6 @@ struct rte_eth_txmode {
*/
uint64_t offloads;
- /* For i40e specifically */
uint16_t pvid;
__extension__
uint8_t hw_vlan_reject_tagged : 1,
@@ -2846,7 +2845,6 @@ int rte_eth_dev_vlan_filter(uint16_t port_id, uint16_t
vlan_id, int on);
/**
* Enable/Disable hardware VLAN Strip by a rx queue of an Ethernet device.
- * 82599/X540/X550 can support VLAN stripping at the rx queue level
*
* @param port_id
* The port identifier of the Ethernet device.
@@ -2868,8 +2866,7 @@ int rte_eth_dev_set_vlan_strip_on_queue(uint16_t port_id,
uint16_t rx_queue_id,
/**
* Set the Outer VLAN Ether Type by an Ethernet device, it can be inserted to
- * the VLAN Header. This is a register setup available on some Intel NIC, not
- * but all, please check the data sheet for availability.
+ * the VLAN header.
*
* @param port_id
* The port identifier of the Ethernet device.
@@ -2888,12 +2885,7 @@ int rte_eth_dev_set_vlan_ether_type(uint16_t port_id,
uint16_t tag_type);
/**
- * Set VLAN offload configuration on an Ethernet device
- * Enable/Disable Extended VLAN by an Ethernet device, This is a register setup
- * available on some Intel NIC, not but all, please check the data sheet for
- * availability.
- * Enable/Disable VLAN Strip can be done on rx queue for certain NIC, but here
- * the configuration is applied on the port level.
+ * Set VLAN offload configuration on an Ethernet device.
*
* @param port_id
* The port identifier of the Ethernet device.
--
2.27.0
[dpdk-dev] discussion about VLAN API
Hi, We have a quite complex API for VLAN filter/push/pop, per port, per queue or per flow. These are the old per-port functions: rte_eth_dev_vlan_filter rte_eth_dev_set_vlan_strip_on_queue rte_eth_dev_set_vlan_ether_type rte_eth_dev_set_vlan_offload rte_eth_dev_get_vlan_offload rte_eth_dev_set_vlan_pvid In rte_eth_dev_data: struct rte_vlan_filter_conf vlan_filter_conf In rte_eth_txmode struct: uint16_t pvid; hw_vlan_reject_tagged : 1, hw_vlan_reject_untagged : 1, hw_vlan_insert_pvid : 1; Configurartion flags: ETH_VLAN_STRIP_OFFLOAD ETH_VLAN_FILTER_OFFLOAD ETH_VLAN_EXTEND_OFFLOAD ETH_QINQ_STRIP_OFFLOAD RX offload capabilities: DEV_RX_OFFLOAD_VLAN_STRIP DEV_RX_OFFLOAD_VLAN_FILTER DEV_RX_OFFLOAD_VLAN_EXTEND DEV_RX_OFFLOAD_QINQ_STRIP TX offload capabilities: DEV_TX_OFFLOAD_VLAN_INSERT Types: ETH_VLAN_TYPE_UNKNOWN ETH_VLAN_TYPE_INNER ETH_VLAN_TYPE_OUTER rte_flow configuration: RTE_FLOW_ITEM_TYPE_VLAN RTE_FLOW_ACTION_TYPE_OF_POP_VLAN RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP What can be done to simplify this mess? Wouldn't it be simpler to keep only rte_flow?
[dpdk-dev] [PATCH] doc: announce removal of interactive setup script
Environment configuration is the responsibility of distributions or upper-level frameworks. DPDK focus on documenting the requirements and some recommendations. Maintaining a good adaptative deployment setup is a project by itself. Anyway this script was interactive, useful only for experimenters. Signed-off-by: Thomas Monjalon --- doc/guides/rel_notes/deprecation.rst | 4 1 file changed, 4 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index ea4cfa7a48..7ce9fc3e4f 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -151,3 +151,7 @@ Deprecation Notices Python 2 support will be completely removed in 20.11. In 20.08, explicit deprecation warnings will be displayed when running scripts with Python 2. + +* dpdk-setup.sh: This old script relies on deprecated stuff, and especially + ``make``. Given environments are too much variables for such a simple script, + it will be removed in DPDK 20.11. -- 2.27.0
Re: [dpdk-dev] [PATCH] doc: announce removal of interactive setup script
On 8/4/20 12:26 PM, Thomas Monjalon wrote: > Environment configuration is the responsibility of distributions > or upper-level frameworks. > DPDK focus on documenting the requirements and some recommendations. > > Maintaining a good adaptative deployment setup is a project by itself. > Anyway this script was interactive, useful only for experimenters. > > Signed-off-by: Thomas Monjalon > --- > doc/guides/rel_notes/deprecation.rst | 4 > 1 file changed, 4 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index ea4cfa7a48..7ce9fc3e4f 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -151,3 +151,7 @@ Deprecation Notices >Python 2 support will be completely removed in 20.11. >In 20.08, explicit deprecation warnings will be displayed when running >scripts with Python 2. > + > +* dpdk-setup.sh: This old script relies on deprecated stuff, and especially > + ``make``. Given environments are too much variables for such a simple > script, > + it will be removed in DPDK 20.11. > Acked-by: Maxime Coquelin Thanks, Maxime
Re: [dpdk-dev] [PATCH] doc: announce removal of interactive setup script
On Tue, Aug 4, 2020 at 4:00 PM Maxime Coquelin wrote: > > > > On 8/4/20 12:26 PM, Thomas Monjalon wrote: > > Environment configuration is the responsibility of distributions > > or upper-level frameworks. > > DPDK focus on documenting the requirements and some recommendations. > > > > Maintaining a good adaptative deployment setup is a project by itself. > > Anyway this script was interactive, useful only for experimenters. > > > > Signed-off-by: Thomas Monjalon > > --- > > doc/guides/rel_notes/deprecation.rst | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > > b/doc/guides/rel_notes/deprecation.rst > > index ea4cfa7a48..7ce9fc3e4f 100644 > > --- a/doc/guides/rel_notes/deprecation.rst > > +++ b/doc/guides/rel_notes/deprecation.rst > > @@ -151,3 +151,7 @@ Deprecation Notices > >Python 2 support will be completely removed in 20.11. > >In 20.08, explicit deprecation warnings will be displayed when running > >scripts with Python 2. > > + > > +* dpdk-setup.sh: This old script relies on deprecated stuff, and especially > > + ``make``. Given environments are too much variables for such a simple > > script, > > + it will be removed in DPDK 20.11. > > > > Acked-by: Maxime Coquelin Acked-by: Jerin Jacob > > Thanks, > Maxime >
Re: [dpdk-dev] [PATCH v2] doc: add reserve fields to eventdev public structures
On Mon, Aug 03, 2020 at 12:59:03PM +0530, pbhagavat...@marvell.com wrote: > From: Pavan Nikhilesh > > Add 64 byte padding at the end of event device public structure to allow > future extensions. > > Signed-off-by: Pavan Nikhilesh > Acked-by: Jerin Jacob > --- > v2 Changes: > - Modify commit title. > - Add patch reference to doc. > > doc/guides/rel_notes/deprecation.rst | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index ea4cfa7a4..ec5db68e9 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -151,3 +151,14 @@ Deprecation Notices >Python 2 support will be completely removed in 20.11. >In 20.08, explicit deprecation warnings will be displayed when running >scripts with Python 2. > + > +* eventdev: A 64 byte padding is added at the end of the following structures > + in event device library to support future extensions: > + ``rte_event_crypto_adapter_conf``, ``rte_event_eth_rx_adapter_conf``, > + ``rte_event_eth_rx_adapter_queue_conf``, ``rte_event_eth_tx_adapter_conf``, > + ``rte_event_timer_adapter_conf``, ``rte_event_timer_adapter_info``, > + ``rte_event_dev_info``, ``rte_event_dev_config``, ``rte_event_queue_conf``, > + ``rte_event_port_conf``, ``rte_event_timer_adapter``, > + ``rte_event_timer_adapter_data``. > + Reference: > + > http://patches.dpdk.org/project/dpdk/list/?series=10728&archive=both&state=* > -- I don't like this idea of adding lots of padding to the ends of these structures. For some structures, such as the public arrays for devices it may be necessary, but for all the conf structures passed as parameters to functions I think we can do better. Since these structures are passed by the user to various functions, function versioning can be used to ensure that the correct function in eventdev is always called. From there to the individual PMDs, we can implement ABI compatibility by either: 1. including the length of the struct as a parameter to the driver. (This is a bit similar to my proposal for rawdev [1]) 2. including the ABI version as a parameter to the driver. Regards /Bruce [1] http://inbox.dpdk.org/dev/?q=enhance+rawdev+APIs
Re: [dpdk-dev] [PATCH] net/rte_pmd_i40e: remove duplicate check
On 8/1/2020 2:57 AM, Gaurav Singh wrote: > remove duplicate check > > Signed-off-by: Gaurav Singh Acked-by: Ferruh Yigit
Re: [dpdk-dev] [PATCH] doc: announce PCI resources map API removal
On 04/08/20 14:22 +0530, Jerin Jacob wrote:
> On Tue, Aug 4, 2020 at 2:18 PM David Marchand
> wrote:
> >
> > The PCI resources map API (pci_map_resource/pci_unmap_resource) was
> > imposing use of Unix mmap flags while it does not make sense on Windows.
> > This API was only used to internally setup PCI devices in the PCI bus
> > driver and has no known external users.
> >
> > Announce its removal in 20.11 with its associated structures.
> >
> > The workaround implemented in the commit 9d2b24593724 ("pci: keep API
> > compatibility with mmap values") will be removed at the same time.
> >
> > Signed-off-by: David Marchand
>
> Acked-by: Jerin Jacob
>
Acked-by: Gaetan Rivet
>
> > ---
> > doc/guides/rel_notes/deprecation.rst | 11 +++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/doc/guides/rel_notes/deprecation.rst
> > b/doc/guides/rel_notes/deprecation.rst
> > index ea4cfa7a48..24808c002c 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -67,6 +67,17 @@ Deprecation Notices
> >us extending existing enum/define.
> >One solution can be using a fixed size array instead of ``.*MAX.*``
> > value.
> >
> > +* pci: The PCI resources map API (``pci_map_resource`` and
> > + ``pci_unmap_resource``) was not abstracting the Unix mmap flags (see the
> > + workaround for Windows support implemented in the commit
> > + 9d2b24593724 ("pci: keep API compatibility with mmap values")).
> > + This API will be removed from the public API in 20.11 and moved to the
> > PCI
> > + bus driver along with the PCI resources lists and associated structures
> > + (``pci_map``, ``pci_msix_table``, ``mapped_pci_resource`` and
> > + ``mapped_pci_res_list``).
> > + With this removal, there won't be a need for the mentioned workaround
> > which
> > + will be reverted.
> > +
> > * ethdev: Split the ``struct eth_dev_ops`` struct to hide it as much as
> > possible
> >will be done in 20.11.
> >Currently the ``struct eth_dev_ops`` struct is accessible by the
> > application
> > --
> > 2.23.0
> >
--
Gaëtan
Re: [dpdk-dev] [PATCH v2] doc: add reserve fields to eventdev public structures
On Tue, Aug 4, 2020 at 4:12 PM Bruce Richardson
wrote:
>
> On Mon, Aug 03, 2020 at 12:59:03PM +0530, pbhagavat...@marvell.com wrote:
> > From: Pavan Nikhilesh
> >
> > Add 64 byte padding at the end of event device public structure to allow
> > future extensions.
> >
> > Signed-off-by: Pavan Nikhilesh
> > Acked-by: Jerin Jacob
> > ---
> > v2 Changes:
> > - Modify commit title.
> > - Add patch reference to doc.
> >
> > doc/guides/rel_notes/deprecation.rst | 11 +++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/doc/guides/rel_notes/deprecation.rst
> > b/doc/guides/rel_notes/deprecation.rst
> > index ea4cfa7a4..ec5db68e9 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -151,3 +151,14 @@ Deprecation Notices
> >Python 2 support will be completely removed in 20.11.
> >In 20.08, explicit deprecation warnings will be displayed when running
> >scripts with Python 2.
> > +
> > +* eventdev: A 64 byte padding is added at the end of the following
> > structures
> > + in event device library to support future extensions:
> > + ``rte_event_crypto_adapter_conf``, ``rte_event_eth_rx_adapter_conf``,
> > + ``rte_event_eth_rx_adapter_queue_conf``,
> > ``rte_event_eth_tx_adapter_conf``,
> > + ``rte_event_timer_adapter_conf``, ``rte_event_timer_adapter_info``,
> > + ``rte_event_dev_info``, ``rte_event_dev_config``,
> > ``rte_event_queue_conf``,
> > + ``rte_event_port_conf``, ``rte_event_timer_adapter``,
> > + ``rte_event_timer_adapter_data``.
> > + Reference:
> > +
> > http://patches.dpdk.org/project/dpdk/list/?series=10728&archive=both&state=*
> > --
>
> I don't like this idea of adding lots of padding to the ends of these
> structures. For some structures, such as the public arrays for devices it
> may be necessary, but for all the conf structures passed as parameters to
> functions I think we can do better. Since these structures are passed by
> the user to various functions, function versioning can be used to ensure
> that the correct function in eventdev is always called. From there to the
> individual PMDs, we can implement ABI compatibility by either:
> 1. including the length of the struct as a parameter to the driver. (This is
> a bit similar to my proposal for rawdev [1])
> 2. including the ABI version as a parameter to the driver.
But, Will the above solution work if the application is dependent on
struct size?
i.e change of s1 size will change offset of s3 i.e
app_sepecific_struct_s3. Right?
i.e DPDK version should not change the offset of s3. Right?
example,
struct app_struct {
struct dpdk_public_struct_s1 s1;
struct dpdk_public_struct_s2 s2;
struct app_sepecific_struct_s3 s3;
}
>
> Regards
> /Bruce
>
> [1] http://inbox.dpdk.org/dev/?q=enhance+rawdev+APIs
Re: [dpdk-dev] [PATCH] doc: announce change in IPv6 item struct
Kind reminder to all maintainers, please review and ack/comment. > -Original Message- > From: Dekel Peled > Sent: Monday, August 3, 2020 10:51 PM > To: dev@dpdk.org > Cc: jerinjac...@gmail.com; step...@networkplumber.org; > arybche...@solarflare.com; ajit.khapa...@broadcom.com; > maxime.coque...@redhat.com; olivier.m...@6wind.com; > david.march...@redhat.com; ferruh.yi...@intel.com > Subject: [PATCH] doc: announce change in IPv6 item struct > > Struct rte_flow_item_ipv6 will be modified to include additional values, > indicating existence or absence of IPv6 extension headers following the IPv6 > header, as proposed in RFC https://mails.dpdk.org/archives/dev/2020- > August/177257.html. > Because of ABI break this change is proposed for 20.11. > > Signed-off-by: Dekel Peled > --- > doc/guides/rel_notes/deprecation.rst | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index ea4cfa7..5201142 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -110,6 +110,11 @@ Deprecation Notices >break the ABI checks, that is why change is planned for 20.11. >The list of internal APIs are mainly ones listed in > ``rte_ethdev_driver.h``. > > +* ethdev: The ``struct rte_flow_item_ipv6`` struct will be modified to > +include > + additional values, indicating existence or absence of IPv6 extension > +headers > + following the IPv6 header, as proposed in RFC > + https://mails.dpdk.org/archives/dev/2020-August/177257.html. > + > * traffic manager: All traffic manager API's in ``rte_tm.h`` were mistakenly > made >ABI stable in the v19.11 release. The TM maintainer and other contributors > have >agreed to keep the TM APIs as experimental in expectation of additional > spec > -- > 1.8.3.1
Re: [dpdk-dev] [PATCH] doc: announce changes to ethdev rxconf structure
On Mon, Aug 3, 2020 at 6:36 PM Slava Ovsiienko wrote:
>
> Hi, Jerin,
>
> Thanks for the comment, please, see below.
>
> > -Original Message-
> > From: Jerin Jacob
> > Sent: Monday, August 3, 2020 14:57
> > To: Slava Ovsiienko
> > Cc: dpdk-dev ; Matan Azrad ;
> > Raslan Darawsheh ; Thomas Monjalon
> > ; Ferruh Yigit ; Stephen
> > Hemminger ; Andrew Rybchenko
> > ; Ajit Khaparde
> > ; Maxime Coquelin
> > ; Olivier Matz ;
> > David Marchand
> > Subject: Re: [PATCH] doc: announce changes to ethdev rxconf structure
> >
> > On Mon, Aug 3, 2020 at 4:28 PM Viacheslav Ovsiienko
> > wrote:
> > >
> > > The DPDK datapath in the transmit direction is very flexible.
> > > The applications can build multisegment packets and manages almost all
> > > data aspects - the memory pools where segments are allocated from, the
> > > segment lengths, the memory attributes like external, registered, etc.
> > >
> > > In the receiving direction, the datapath is much less flexible, the
> > > applications can only specify the memory pool to configure the
> > > receiving queue and nothing more. In order to extend the receiving
> > > datapath capabilities it is proposed to add the new fields into
> > > rte_eth_rxconf structure:
> > >
> > > struct rte_eth_rxconf {
> > > ...
> > > uint16_t rx_split_num; /* number of segments to split */
> > > uint16_t *rx_split_len; /* array of segment lengthes */
> > > struct rte_mempool **mp; /* array of segment memory pools */
> >
> > The pool has the packet length it's been configured for.
> > So I think, rx_split_len can be removed.
>
> Yes, it is one of the supposed options - if pointer to array of segment
> lengths
> is NULL , the queue_setup() could use the lengths from the pool's properties.
> But we are talking about packet split, in general, it should not depend
> on pool properties. What if application provides the single pool
> and just wants to have the tunnel header in the first dedicated mbuf?
>
> >
> > This feature also available in Marvell HW. So it not specific to one vendor.
> > Maybe we could just the use case mention the use case in the depreciation
> > notice and the tentative change in rte_eth_rxconf and exact details can be
> > worked out at the time of implementation.
> >
> So, if I understand correctly, the struct changes in the commit message
> should be marked as just possible implementation?
Yes.
We may need to have a detailed discussion on the correct abstraction for various
HW is available with this feature.
On Marvell HW, We can configure TWO pools for given eth Rx queue.
One pool can be configured as a small packet pool and other one as
large packet pool.
And there is a threshold value to decide the pool between small and large.
For example:
- The small pool is configured 2k
- The large pool is configured with 10k
- And if the threshold value is configured as 2k.
Any packet size <=2K will land in small pool and others in a large pool.
The use case, we are targeting is to save the memory space for jumbo frames.
If you can share the MLX HW working model, Then we can find the
correct abstraction.
>
> With best regards,
> Slava
>
> > With the above change:
> > Acked-by: Jerin Jacob
> >
> >
> > > ...
> > > };
> > >
> > > The non-zero value of rx_split_num field configures the receiving
> > > queue to split ingress packets into multiple segments to the mbufs
> > > allocated from various memory pools according to the specified
> > > lengths. The zero value of rx_split_num field provides the backward
> > > compatibility and queue should be configured in a regular way (with
> > > single/multiple mbufs of the same data buffer length allocated from
> > > the single memory pool).
> > >
> > > The new approach would allow splitting the ingress packets into
> > > multiple parts pushed to the memory with different attributes.
> > > For example, the packet headers can be pushed to the embedded data
> > > buffers within mbufs and the application data into the external
> > > buffers attached to mbufs allocated from the different memory pools.
> > > The memory attributes for the split parts may differ either - for
> > > example the application data may be pushed into the external memory
> > > located on the dedicated physical device, say GPU or NVMe. This would
> > > improve the DPDK receiving datapath flexibility preserving
> > > compatibility with existing API.
> > >
> > > Signed-off-by: Viacheslav Ovsiienko
> > > ---
> > > doc/guides/rel_notes/deprecation.rst | 5 +
> > > 1 file changed, 5 insertions(+)
> > >
> > > diff --git a/doc/guides/rel_notes/deprecation.rst
> > > b/doc/guides/rel_notes/deprecation.rst
> > > index ea4cfa7..cd700ae 100644
> > > --- a/doc/guides/rel_notes/deprecation.rst
> > > +++ b/doc/guides/rel_notes/deprecation.rst
> > > @@ -99,6 +99,11 @@ Deprecation Notices
> > >In 19.11 PMDs will still update the field even when the offload is not
> > >enabled.
> > >
> > > +* ethdev: add new fields to ``rte_eth_rxconf`` to c
Re: [dpdk-dev] [PATCH] doc: eventdev ABI change to support DLB PMD
> -Original Message- > From: McDaniel, Timothy > Sent: Monday, August 3, 2020 6:56 PM > To: jer...@marvell.com > Cc: mattias.ronnb...@ericsson.com; dev@dpdk.org; Eads, Gage > ; Van Haaren, Harry ; > McDaniel, Timothy > Subject: [PATCH] doc: eventdev ABI change to support DLB PMD > > From: "McDaniel, Timothy" > > The ABI changes associated with this notification will better support > devices that: > 1. Have limits on the number or queues that may be linked to a port > 2. Have ports that are limited to exactly one linked queue > 3. Are not able to transparently transfer the event flow_id field > > Signed-off-by: McDaniel Timothy > Nitpick: git warns on added extra new blank line at end of file. Acked-by: Harry van Haaren
[dpdk-dev] [PATCH] doc: announce internal hotplug structure removal
rte_dev_event has never been used outside of the EAL. No point in exposing it. Signed-off-by: David Marchand --- doc/guides/rel_notes/deprecation.rst | 3 +++ 1 file changed, 3 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 24808c002c..9f73297173 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -27,6 +27,9 @@ Deprecation Notices remove it from the externally visible ABI and allow it to be updated in the future. +* eal: The ``rte_dev_event`` structure will be made private to the EAL as no + public API makes use of it. + * rte_atomicNN_xxx: These APIs do not take memory order parameter. This does not allow for writing optimized code for all the CPU architectures supported in DPDK. DPDK will adopt C11 atomic operations semantics and provide wrappers -- 2.23.0
[dpdk-dev] [PATCH v4 2/9] usertools/dpdk-devbind: support python3 only
Changed script to explicitly use python3 only to avoid
maintaining python 2 and removed deprecation notice.
Signed-off-by: Louise Kilheeney
---
usertools/dpdk-devbind.py | 22 --
1 file changed, 4 insertions(+), 18 deletions(-)
diff --git a/usertools/dpdk-devbind.py b/usertools/dpdk-devbind.py
index 86b6b53c40..bcdc5da881 100755
--- a/usertools/dpdk-devbind.py
+++ b/usertools/dpdk-devbind.py
@@ -1,19 +1,14 @@
-#! /usr/bin/env python
+#!/usr/bin/env python3
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2010-2014 Intel Corporation
#
-from __future__ import print_function
import sys
import os
import getopt
import subprocess
from os.path import exists, abspath, dirname, basename
-if sys.version_info.major < 3:
-print("WARNING: Python 2 is deprecated for use in DPDK, and will not work
in future releases.", file=sys.stderr)
-print("Please use Python 3 instead", file=sys.stderr)
-
# The PCI base class for all devices
network_class = {'Class': '02', 'Vendor': None, 'Device': None,
'SVendor': None, 'SDevice': None}
@@ -147,14 +142,6 @@ def usage():
""" % locals()) # replace items from local variables
-
-# This is roughly compatible with check_output function in subprocess module
-# which is only available in python 2.7.
-def check_output(args, stderr=None):
-'''Run a command and capture its output'''
-return subprocess.Popen(args, stdout=subprocess.PIPE,
-stderr=stderr).communicate()[0]
-
# check if a specific kernel module is loaded
def module_is_loaded(module):
global loaded_modules
@@ -211,8 +198,7 @@ def get_pci_device_details(dev_id, probe_lspci):
device = {}
if probe_lspci:
-extra_info = check_output(["lspci", "-vmmks", dev_id]).splitlines()
-
+extra_info = subprocess.check_output(["lspci", "-vmmks",
dev_id]).splitlines()
# parse lspci details
for line in extra_info:
if len(line) == 0:
@@ -248,7 +234,7 @@ def get_device_details(devices_type):
# first loop through and read details for all devices
# request machine readable format, with numeric IDs and String
dev = {}
-dev_lines = check_output(["lspci", "-Dvmmnnk"]).splitlines()
+dev_lines = subprocess.check_output(["lspci", "-Dvmmnnk"]).splitlines()
for dev_line in dev_lines:
if len(dev_line) == 0:
if device_type_match(dev, devices_type):
@@ -276,7 +262,7 @@ def get_device_details(devices_type):
# check what is the interface if any for an ssh connection if
# any to this host, so we can mark it later.
ssh_if = []
-route = check_output(["ip", "-o", "route"])
+route = subprocess.check_output(["ip", "-o", "route"])
# filter out all lines for 169.254 routes
route = "\n".join(filter(lambda ln: not ln.startswith("169.254"),
route.decode().splitlines()))
--
2.17.1
[dpdk-dev] [PATCH] doc: announce kernel driver enum removal
rte_kernel_driver is only used by the PCI subsystem and has polluted ethdev for no reason. Hide it in the PCI bus driver. Signed-off-by: David Marchand --- doc/guides/rel_notes/deprecation.rst | 7 +++ 1 file changed, 7 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 9f73297173..6e86963c39 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -81,6 +81,13 @@ Deprecation Notices With this removal, there won't be a need for the mentioned workaround which will be reverted. +* pci: The ``rte_kernel_driver`` enum defined in rte_dev.h will be made private + to the PCI subsystem as it is used only by the PCI bus driver and PCI + drivers. + The associated field ``kdrv`` in the ethdev ``rte_eth_dev_data`` structure + will be removed as it gave no useful abstracted information to the + applications and had no user (neither internal nor external). + * ethdev: Split the ``struct eth_dev_ops`` struct to hide it as much as possible will be done in 20.11. Currently the ``struct eth_dev_ops`` struct is accessible by the application -- 2.23.0
[dpdk-dev] [PATCH v4 0/9] adding support for python 3 only.
This patch set converts all python scripts in the project to use python3 only and removes all deprecation notices associated with these changes. This is due to python2 being EOL in January 2020. Louise Kilheeney (9): usertools/dpdk-telemetry-client: support python3 only usertools/dpdk-devbind: support python3 only usertools/dpdk-pmdinfo: support python3 only usertools/cpu_layout: support python3 only app/test-cmdline: support python3 only app/test: support python3 only devtools: support python3 only config/arm: support python3 only app/test-bbdev: support python3 only app/test-bbdev/test-bbdev.py | 7 +-- app/test-cmdline/cmdline_test.py | 7 +-- app/test-cmdline/cmdline_test_data.py | 1 + app/test/autotest.py | 7 +-- app/test/autotest_data.py | 1 + app/test/autotest_runner.py | 21 - app/test/autotest_test_funcs.py | 1 + config/arm/armv8_machine.py | 2 +- devtools/update_version_map_abi.py| 7 +-- mk/rte.sdktest.mk | 6 +++--- usertools/cpu_layout.py | 13 ++--- usertools/dpdk-devbind.py | 22 -- usertools/dpdk-pmdinfo.py | 7 +-- usertools/dpdk-telemetry-client.py| 20 14 files changed, 30 insertions(+), 92 deletions(-) -- 2.17.1
[dpdk-dev] [PATCH v4 1/9] usertools/dpdk-telemetry-client: support python3 only
Changed script to explicitly use python3 only to avoid
maintaining python 2 and removed deprecation notice.
Cc: Kevin Laatz
Signed-off-by: Louise Kilheeney
---
usertools/dpdk-telemetry-client.py | 20
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git a/usertools/dpdk-telemetry-client.py
b/usertools/dpdk-telemetry-client.py
index 98d28fa89b..fa599046a4 100755
--- a/usertools/dpdk-telemetry-client.py
+++ b/usertools/dpdk-telemetry-client.py
@@ -1,10 +1,7 @@
-#! /usr/bin/env python
+#! /usr/bin/env python3
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2018 Intel Corporation
-from __future__ import print_function
-from __future__ import unicode_literals
-
import socket
import os
import sys
@@ -18,15 +15,6 @@
GLOBAL_METRICS_REQ =
"{\"action\":0,\"command\":\"global_stat_values\",\"data\":null}"
DEFAULT_FP = "/var/run/dpdk/default_client"
-try:
-raw_input # Python 2
-except NameError:
-raw_input = input # Python 3
-
-if sys.version_info.major < 3:
-print("WARNING: Python 2 is deprecated for use in DPDK, and will not work
in future releases.", file=sys.stderr)
-print("Please use Python 3 instead", file=sys.stderr)
-
class Socket:
def __init__(self):
@@ -53,7 +41,7 @@ def __init__(self): # Creates a client instance
def __del__(self):
try:
if self.unregistered == 0:
-self.unregister();
+self.unregister()
except:
print("Error - Client could not be destroyed")
@@ -86,7 +74,7 @@ def requestMetrics(self): # Requests metrics for given client
def repeatedlyRequestMetrics(self, sleep_time): # Recursively requests
metrics for given client
print("\nPlease enter the number of times you'd like to continuously
request Metrics:")
-n_requests = int(raw_input("\n:"))
+n_requests = int(input("\n:"))
print("\033[F") #Removes the user input from screen, cleans it up
print("\033[K")
for i in range(n_requests):
@@ -107,7 +95,7 @@ def interactiveMenu(self, sleep_time): # Creates Interactive
menu within the scr
print("[4] Unregister client")
try:
-self.choice = int(raw_input("\n:"))
+self.choice = int(input("\n:"))
print("\033[F") #Removes the user input for screen, cleans it
up
print("\033[K")
if self.choice == 1:
--
2.17.1
[dpdk-dev] [PATCH v4 3/9] usertools/dpdk-pmdinfo: support python3 only
Changed script to explicitly use python3 only to avoid
maintaining python 2 and removed deprecation notice.
Cc: Neil Horman
Signed-off-by: Louise Kilheeney
---
usertools/dpdk-pmdinfo.py | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/usertools/dpdk-pmdinfo.py b/usertools/dpdk-pmdinfo.py
index f9ed755176..1661982791 100755
--- a/usertools/dpdk-pmdinfo.py
+++ b/usertools/dpdk-pmdinfo.py
@@ -1,4 +1,4 @@
-#!/usr/bin/env python
+#!/usr/bin/env python3
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2016 Neil Horman
@@ -7,8 +7,6 @@
# Utility to dump PMD_INFO_STRING support from an object file
#
# -
-from __future__ import print_function
-from __future__ import unicode_literals
import json
import io
import os
@@ -28,9 +26,6 @@
pcidb = None
# ===
-if sys.version_info.major < 3:
-print("WARNING: Python 2 is deprecated for use in DPDK, and will not
work in future releases.", file=sys.stderr)
-print("Please use Python 3 instead", file=sys.stderr)
class Vendor:
"""
--
2.17.1
[dpdk-dev] [PATCH v4 6/9] app/test: support python3 only
Changed script to explicitly use python3 only to avoid
maintaining python 2 and removed deprecation notice.
Signed-off-by: Louise Kilheeney
---
app/test/autotest.py| 7 +--
app/test/autotest_data.py | 1 +
app/test/autotest_runner.py | 21 -
app/test/autotest_test_funcs.py | 1 +
mk/rte.sdktest.mk | 4 ++--
5 files changed, 13 insertions(+), 21 deletions(-)
diff --git a/app/test/autotest.py b/app/test/autotest.py
index cf7584ccd7..9eef1efbe5 100644
--- a/app/test/autotest.py
+++ b/app/test/autotest.py
@@ -1,9 +1,8 @@
-#!/usr/bin/env python
+#!/usr/bin/env python3
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2010-2014 Intel Corporation
# Script that uses either test app or qemu controlled by python-pexpect
-from __future__ import print_function
import autotest_data
import autotest_runner
import sys
@@ -17,10 +16,6 @@ def usage():
usage()
sys.exit(1)
-if sys.version_info.major < 3:
-print("WARNING: Python 2 is deprecated for use in DPDK, and will not work
in future releases.", file=sys.stderr)
-print("Please use Python 3 instead", file=sys.stderr)
-
target = sys.argv[2]
test_whitelist = None
diff --git a/app/test/autotest_data.py b/app/test/autotest_data.py
index 4b7da45e09..097638941f 100644
--- a/app/test/autotest_data.py
+++ b/app/test/autotest_data.py
@@ -1,3 +1,4 @@
+#!/usr/bin/env python3
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2010-2014 Intel Corporation
diff --git a/app/test/autotest_runner.py b/app/test/autotest_runner.py
index 95e74c760d..998fe57a55 100644
--- a/app/test/autotest_runner.py
+++ b/app/test/autotest_runner.py
@@ -1,10 +1,10 @@
+#!/usr/bin/env python3
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2010-2014 Intel Corporation
# The main logic behind running autotests in parallel
-from __future__ import print_function
-import StringIO
+import io
import csv
from multiprocessing import Pool, Queue
import pexpect
@@ -50,11 +50,7 @@ def first_cpu_on_node(node_nr):
map(os.path.basename, cpu_path)
)
)
-# for compatibility between python 3 and 2 we need to make interable out
-# of filter return as it returns list in python 2 and a generator in 3
-m = next(iter(cpu_name))
-return int(m.group(1))
-
+return int(next(cpu_name).group(1))
pool_child = None # per-process child
@@ -78,7 +74,7 @@ def pool_init(queue, result_queue):
cmdline = "%s %s" % (cmdline, prefix_cmdline)
# prepare logging of init
-startuplog = StringIO.StringIO()
+startuplog = io.StringIO()
# run test app
try:
@@ -86,8 +82,7 @@ def pool_init(queue, result_queue):
print("\n%s %s\n" % ("=" * 20, prefix), file=startuplog)
print("\ncmdline=%s" % cmdline, file=startuplog)
-pool_child = pexpect.spawn(cmdline, logfile=startuplog)
-
+pool_child = pexpect.spawn(cmdline, logfile=startuplog,
encoding='utf-8')
# wait for target to boot
if not wait_prompt(pool_child):
pool_child.close()
@@ -138,7 +133,7 @@ def run_test(target, test):
# create log buffer for each test
# in multiprocessing environment, the logging would be
# interleaved and will create a mess, hence the buffering
-logfile = StringIO.StringIO()
+logfile = io.StringIO()
pool_child.logfile = logfile
# make a note when the test started
@@ -210,9 +205,9 @@ def __init__(self, cmdline, target, blacklist, whitelist,
n_processes):
# parse the binary for available test commands
binary = cmdline.split()[0]
stripped = 'not stripped' not in \
- subprocess.check_output(['file', binary])
+ subprocess.check_output(['file', binary]).decode()
if not stripped:
-symbols = subprocess.check_output(['nm', binary]).decode('utf-8')
+symbols = subprocess.check_output(['nm', binary]).decode()
self.avail_cmds = re.findall('test_register_(\w+)', symbols)
else:
self.avail_cmds = None
diff --git a/app/test/autotest_test_funcs.py b/app/test/autotest_test_funcs.py
index 26688b7132..775dfd1dc5 100644
--- a/app/test/autotest_test_funcs.py
+++ b/app/test/autotest_test_funcs.py
@@ -1,3 +1,4 @@
+#!/usr/bin/env python3
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2010-2014 Intel Corporation
diff --git a/mk/rte.sdktest.mk b/mk/rte.sdktest.mk
index ad7ef138f0..81eff0c08f 100644
--- a/mk/rte.sdktest.mk
+++ b/mk/rte.sdktest.mk
@@ -49,7 +49,7 @@ test test-fast test-perf test-drivers test-dump:
@mkdir -p $(AUTOTEST_DIR) ; \
cd $(AUTOTEST_DIR) ; \
if [ -f $(RTE_OUTPUT)/app/test ]; then \
- python $(RTE_SDK)/app/test/autotest.py \
+ python3 $(RTE_SDK)/app/test/autotest.py \
$(RTE_OUTPUT)/app/test \
$(RTE_TARGET) \
$(BLACKL
[dpdk-dev] [PATCH v4 7/9] devtools: support python3 only
Changed script to explicitly use python3 only to avoid
maintaining python 2 and removed deprecation notice.
Cc: Neil Horman
Cc: Ray Kinsella
Signed-off-by: Louise Kilheeney
---
devtools/update_version_map_abi.py | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/devtools/update_version_map_abi.py
b/devtools/update_version_map_abi.py
index 80a61641ed..830e6c58c8 100755
--- a/devtools/update_version_map_abi.py
+++ b/devtools/update_version_map_abi.py
@@ -1,4 +1,4 @@
-#!/usr/bin/env python
+#!/usr/bin/env python3
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2019 Intel Corporation
@@ -9,7 +9,6 @@
from the devtools/update-abi.sh utility.
"""
-from __future__ import print_function
import argparse
import sys
import re
@@ -160,10 +159,6 @@ def __generate_internal_abi(f_out, lines):
print("};", file=f_out)
def __main():
-if sys.version_info.major < 3:
-print("WARNING: Python 2 is deprecated for use in DPDK, and will not
work in future releases.", file=sys.stderr)
-print("Please use Python 3 instead", file=sys.stderr)
-
arg_parser = argparse.ArgumentParser(
description='Merge versions in linker version script.')
--
2.17.1
[dpdk-dev] [PATCH v4 4/9] usertools/cpu_layout: support python3 only
Changed script to explicitly use python3 only to avoid
maintaining python 2 and removed deprecation notice.
Signed-off-by: Louise Kilheeney
---
usertools/cpu_layout.py | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/usertools/cpu_layout.py b/usertools/cpu_layout.py
index 5423c7965f..89a48cec46 100755
--- a/usertools/cpu_layout.py
+++ b/usertools/cpu_layout.py
@@ -1,18 +1,9 @@
-#!/usr/bin/env python
+#!/usr/bin/env python3
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2010-2014 Intel Corporation
# Copyright(c) 2017 Cavium, Inc. All rights reserved.
-from __future__ import print_function
import sys
-try:
-xrange # Python 2
-except NameError:
-xrange = range # Python 3
-
-if sys.version_info.major < 3:
-print("WARNING: Python 2 is deprecated for use in DPDK, and will not work
in future releases.", file=sys.stderr)
-print("Please use Python 3 instead", file=sys.stderr)
sockets = []
cores = []
@@ -21,7 +12,7 @@
fd = open("{}/kernel_max".format(base_path))
max_cpus = int(fd.read())
fd.close()
-for cpu in xrange(max_cpus + 1):
+for cpu in range(max_cpus + 1):
try:
fd = open("{}/cpu{}/topology/core_id".format(base_path, cpu))
except IOError:
--
2.17.1
[dpdk-dev] [PATCH v4 5/9] app/test-cmdline: support python3 only
Changed script to explicitly use python3 only to avoid
maintaining python 2 and removed deprecation notice.
Cc: Olivier Matz
Signed-off-by: Louise Kilheeney
---
app/test-cmdline/cmdline_test.py | 7 +--
app/test-cmdline/cmdline_test_data.py | 1 +
mk/rte.sdktest.mk | 2 +-
3 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/app/test-cmdline/cmdline_test.py b/app/test-cmdline/cmdline_test.py
index 954428e2bf..ec55647f6e 100755
--- a/app/test-cmdline/cmdline_test.py
+++ b/app/test-cmdline/cmdline_test.py
@@ -1,9 +1,8 @@
-#!/usr/bin/env python
+#!/usr/bin/env python3
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2010-2014 Intel Corporation
# Script that runs cmdline_test app and feeds keystrokes into it.
-from __future__ import print_function
import cmdline_test_data
import os
import pexpect
@@ -19,10 +18,6 @@ def runTest(child, test):
return 0
child.expect(test["Result"], 1)
-if sys.version_info.major < 3:
-print("WARNING: Python 2 is deprecated for use in DPDK, and will not work
in future releases.", file=sys.stderr)
-print("Please use Python 3 instead", file=sys.stderr)
-
#
# history test is a special case
#
diff --git a/app/test-cmdline/cmdline_test_data.py
b/app/test-cmdline/cmdline_test_data.py
index 114d2cb6a0..2d9b3262a6 100644
--- a/app/test-cmdline/cmdline_test_data.py
+++ b/app/test-cmdline/cmdline_test_data.py
@@ -1,3 +1,4 @@
+#!/usr/bin/env python3
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2010-2014 Intel Corporation
diff --git a/mk/rte.sdktest.mk b/mk/rte.sdktest.mk
index 803018ba3a..ad7ef138f0 100644
--- a/mk/rte.sdktest.mk
+++ b/mk/rte.sdktest.mk
@@ -63,7 +63,7 @@ coverage:
@mkdir -p $(AUTOTEST_DIR) ; \
cd $(AUTOTEST_DIR) ; \
if [ -f $(RTE_OUTPUT)/app/test ]; then \
- python $(RTE_SDK)/test/cmdline_test/cmdline_test.py \
+ python3 $(RTE_SDK)/test/cmdline_test/cmdline_test.py \
$(RTE_OUTPUT)/app/cmdline_test; \
ulimit -S -n 100 ; \
python $(RTE_SDK)/app/test/autotest.py \
--
2.17.1
[dpdk-dev] [PATCH v4 9/9] app/test-bbdev: support python3 only
Changed script to explicitly use python3 only to avoid
maintaining python 2 and removed deprecation notice.
Cc: Nicolas Chautru
Signed-off-by: Louise Kilheeney
---
app/test-bbdev/test-bbdev.py | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/app/test-bbdev/test-bbdev.py b/app/test-bbdev/test-bbdev.py
index 5ae2dc6c49..7d67dbe30a 100755
--- a/app/test-bbdev/test-bbdev.py
+++ b/app/test-bbdev/test-bbdev.py
@@ -1,9 +1,8 @@
-#!/usr/bin/env python
+#!/usr/bin/env python3
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017 Intel Corporation
-from __future__ import print_function
import sys
import os
import argparse
@@ -16,10 +15,6 @@ def kill(process):
print("ERROR: Test app timed out")
process.kill()
-if sys.version_info.major < 3:
-print("WARNING: Python 2 is deprecated for use in DPDK, and will not work
in future releases.", file=sys.stderr)
-print("Please use Python 3 instead", file=sys.stderr)
-
if "RTE_SDK" in os.environ:
dpdk_path = os.environ["RTE_SDK"]
else:
--
2.17.1
[dpdk-dev] [PATCH v4 8/9] config/arm: support python3 only
Changed script to explicitly use python3 only to avoid maintaining python 2. Cc: Thomas Monjalon Signed-off-by: Louise Kilheeney --- config/arm/armv8_machine.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/config/arm/armv8_machine.py b/config/arm/armv8_machine.py index 404866d2f8..1f689d9a83 100755 --- a/config/arm/armv8_machine.py +++ b/config/arm/armv8_machine.py @@ -1,4 +1,4 @@ -#!/usr/bin/python +#!/usr/bin/env python3 # SPDX-License-Identifier: BSD-3-Clause # Copyright(c) 2017 Cavium, Inc -- 2.17.1
Re: [dpdk-dev] [PATCH v4] doc: add deprecation notice for sched changes
> -Original Message- > From: dev On Behalf Of Savinay Dharmappa > Sent: Wednesday, July 29, 2020 4:38 PM > To: Dharmappa, Savinay ; Singh, Jasvinder > ; Shetty, Praveen ; > Tummala, Sivaprasad ; dev@dpdk.org > Cc: Dumitrescu, Cristian > Subject: [dpdk-dev] [PATCH v4] doc: add deprecation notice for sched changes > > Add deprecation note for making changes in data structures and APIs in order > to > allow dynamic configuration of subport bandwidth profile. > These changes are aligned as suggested in the RFC[1]. > > https://mails.dpdk.org/archives/dev/2020-July/175161.html > > Signed-off-by: Savinay Dharmappa > Acked-by: Jasvinder Singh > Acked-by: Praveen Shetty > --- > doc/guides/rel_notes/deprecation.rst | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index 99c9806..9a9ecb1 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -135,6 +135,12 @@ Deprecation Notices >will be removed in 20.11. It will be replaced with ``refcnt`` of type >``uint16_t``. > > +* sched: To allow dynamic configuration of the subport bandwidth > +profile, > + changes will be made to data structures ``rte_sched_subport_params`` > + ``rte_sched_port_params`` and new data structure, API functions will > +be > + defined in "rte_sched.h". These changes are aligned as suggested in > +the > + RFC https://mails.dpdk.org/archives/dev/2020-July/175161.html > + > * metrics: The function ``rte_metrics_init`` will have a non-void return >in order to notify errors instead of calling ``rte_exit``. > > -- > 2.7.4 Acked-by: Sunil Pai G
Re: [dpdk-dev] [PATCH] doc: announce API change in timer
> -Original Message- > From: Sarosh Arif > Sent: Monday, August 3, 2020 10:29 PM > To: Honnappa Nagarahalli ; Carrillo, Erik G > > Cc: rsanf...@akamai.com; dev@dpdk.org; nd > Subject: Re: [dpdk-dev] [PATCH] doc: announce API change in timer > > Thank you Eric, I will fix the mistakes in v2 > > On Tue, Aug 4, 2020 at 4:16 AM Honnappa Nagarahalli > wrote: > > > > > > > > > > > > If the user tries to reset/stop some other timer in it's callback > > > function, which > > Is there any use case for this? Why not just say document that the user is > not allowed to reset some other timer in the call back function? How does > the user get access to some other timer in the call back function? > > Not sure if this was discussed earlier, I might have missed. > The issue is more clearly described in bug 491 here is a link: > https://bugs.dpdk.org/show_bug.cgi?id=491 > further discussion on this issue was done on the following patch: > https://patches.dpdk.org/patch/73683/ > I like Honnappa's suggestion... we could document that the *_sync functions shouldn't be used inside timer callbacks since there are cases where it could hang. Instead, if doing this was desired, the regular versions could be used there, and the return values could be checked in that case. > > > > > is also about to expire, using > > > rte_timer_reset_sync/rte_timer_stop_sync the application goes into > > > an infinite loop. This happens because > > > rte_timer_reset_sync/rte_timer_stop_sync loop until the timer > > > resets/stops and there is check inside timer_set_config_state which > > > prevents a running timer from being reset/stopped by not it's own > > > timer_cb. Therefore timer_set_config_state returns -1 due to which > > > rte_timer_reset returns -1 and rte_timer_reset_sync goes into an > > > infinite loop > > > > > > To to prevent this rte_timer_reset_sync and rte_timer_stop_sync > > > should have int return types, so that -1 can be returned if the > > > above condition occurs > > > > > > Signed-off-by: Sarosh Arif > > > --- > > > doc/guides/rel_notes/deprecation.rst | 6 ++ > > > 1 file changed, 6 insertions(+) > > > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > > > b/doc/guides/rel_notes/deprecation.rst > > > index ea4cfa7a4..ed93a707d 100644 > > > --- a/doc/guides/rel_notes/deprecation.rst > > > +++ b/doc/guides/rel_notes/deprecation.rst > > > @@ -151,3 +151,9 @@ Deprecation Notices > > >Python 2 support will be completely removed in 20.11. > > >In 20.08, explicit deprecation warnings will be displayed when running > > >scripts with Python 2. > > > + > > > +* timer: Since timer can get stuck in an infinite loop if the > > > +application tries to > > > + reset/stop some other timer in it's callback function, which is > > > +also about to > > > + expire. The function ``rte_timer_stop_sync`` and > > > +``rte_timer_stop_sync`` will > > > + have a int return type in order to return with -1 in when this > > > +condition > > > + occures. > > > -- > > > 2.17.1 > >
Re: [dpdk-dev] [PATCH v2] doc: add reserve fields to eventdev public structures
On Tue, Aug 04, 2020 at 05:07:12PM +0530, Jerin Jacob wrote:
> On Tue, Aug 4, 2020 at 4:12 PM Bruce Richardson
> wrote:
> >
> > On Mon, Aug 03, 2020 at 12:59:03PM +0530, pbhagavat...@marvell.com wrote:
> > > From: Pavan Nikhilesh
> > >
> > > Add 64 byte padding at the end of event device public structure to allow
> > > future extensions.
> > >
> > > Signed-off-by: Pavan Nikhilesh
> > > Acked-by: Jerin Jacob
> > > ---
> > > v2 Changes:
> > > - Modify commit title.
> > > - Add patch reference to doc.
> > >
> > > doc/guides/rel_notes/deprecation.rst | 11 +++
> > > 1 file changed, 11 insertions(+)
> > >
> > > diff --git a/doc/guides/rel_notes/deprecation.rst
> > > b/doc/guides/rel_notes/deprecation.rst
> > > index ea4cfa7a4..ec5db68e9 100644
> > > --- a/doc/guides/rel_notes/deprecation.rst
> > > +++ b/doc/guides/rel_notes/deprecation.rst
> > > @@ -151,3 +151,14 @@ Deprecation Notices
> > >Python 2 support will be completely removed in 20.11.
> > >In 20.08, explicit deprecation warnings will be displayed when running
> > >scripts with Python 2.
> > > +
> > > +* eventdev: A 64 byte padding is added at the end of the following
> > > structures
> > > + in event device library to support future extensions:
> > > + ``rte_event_crypto_adapter_conf``, ``rte_event_eth_rx_adapter_conf``,
> > > + ``rte_event_eth_rx_adapter_queue_conf``,
> > > ``rte_event_eth_tx_adapter_conf``,
> > > + ``rte_event_timer_adapter_conf``, ``rte_event_timer_adapter_info``,
> > > + ``rte_event_dev_info``, ``rte_event_dev_config``,
> > > ``rte_event_queue_conf``,
> > > + ``rte_event_port_conf``, ``rte_event_timer_adapter``,
> > > + ``rte_event_timer_adapter_data``.
> > > + Reference:
> > > +
> > > http://patches.dpdk.org/project/dpdk/list/?series=10728&archive=both&state=*
> > > --
> >
> > I don't like this idea of adding lots of padding to the ends of these
> > structures. For some structures, such as the public arrays for devices it
> > may be necessary, but for all the conf structures passed as parameters to
> > functions I think we can do better. Since these structures are passed by
> > the user to various functions, function versioning can be used to ensure
> > that the correct function in eventdev is always called. From there to the
> > individual PMDs, we can implement ABI compatibility by either:
> > 1. including the length of the struct as a parameter to the driver. (This is
> > a bit similar to my proposal for rawdev [1])
> > 2. including the ABI version as a parameter to the driver.
>
> But, Will the above solution work if the application is dependent on
> struct size?
> i.e change of s1 size will change offset of s3 i.e
> app_sepecific_struct_s3. Right?
> i.e DPDK version should not change the offset of s3. Right?
>
> example,
> struct app_struct {
> struct dpdk_public_struct_s1 s1;
> struct dpdk_public_struct_s2 s2;
> struct app_sepecific_struct_s3 s3;
> }
>
Not sure what exactly you mean here. The actual offsets and sizes of the
structs will obviously change as you change the struct, but the end
compiled app has no idea of structs, all it knows of is offsets, which is
why you provide ABI compatible versions of the functions which use "legacy"
copies of the structs to ensure correct offsets. It's pretty much standard
practice for ABI versioning.
The real complication arises because the actual eventdev driver functions
are not called directly with the linker resolving symbol versioning.
Instead they are called using function pointers from the code. This is why
one needs to add in the additional parameter to the driver APIs so that the
ABI info - be it struct size or version - can be passed from the versioned
eventdev library function through to the driver.
Regards,
/Bruce
Re: [dpdk-dev] [PATCH] doc: announce internal hotplug structure removal
On Tue, Aug 04, 2020 at 04:07:17PM +0200, David Marchand wrote: > rte_dev_event has never been used outside of the EAL. > No point in exposing it. > > Signed-off-by: David Marchand > --- > doc/guides/rel_notes/deprecation.rst | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index 24808c002c..9f73297173 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -27,6 +27,9 @@ Deprecation Notices >remove it from the externally visible ABI and allow it to be updated in the >future. > > +* eal: The ``rte_dev_event`` structure will be made private to the EAL as no > + public API makes use of it. > + > * rte_atomicNN_xxx: These APIs do not take memory order parameter. This does >not allow for writing optimized code for all the CPU architectures > supported >in DPDK. DPDK will adopt C11 atomic operations semantics and provide > wrappers > -- Acked-by: Bruce Richardson
Re: [dpdk-dev] [PATCH] doc: announce kernel driver enum removal
On Tue, Aug 04, 2020 at 04:07:52PM +0200, David Marchand wrote: > rte_kernel_driver is only used by the PCI subsystem and has polluted > ethdev for no reason. > Hide it in the PCI bus driver. > > Signed-off-by: David Marchand > --- > doc/guides/rel_notes/deprecation.rst | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index 9f73297173..6e86963c39 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -81,6 +81,13 @@ Deprecation Notices >With this removal, there won't be a need for the mentioned workaround which >will be reverted. > > +* pci: The ``rte_kernel_driver`` enum defined in rte_dev.h will be made > private > + to the PCI subsystem as it is used only by the PCI bus driver and PCI > + drivers. > + The associated field ``kdrv`` in the ethdev ``rte_eth_dev_data`` structure > + will be removed as it gave no useful abstracted information to the > + applications and had no user (neither internal nor external). > + > * ethdev: Split the ``struct eth_dev_ops`` struct to hide it as much as > possible >will be done in 20.11. >Currently the ``struct eth_dev_ops`` struct is accessible by the > application > -- Acked-by: Bruce Richardson
Re: [dpdk-dev] [PATCH] doc: announce kernel driver enum removal
On 04/08/20 15:29 +0100, Bruce Richardson wrote: > On Tue, Aug 04, 2020 at 04:07:52PM +0200, David Marchand wrote: > > rte_kernel_driver is only used by the PCI subsystem and has polluted > > ethdev for no reason. > > Hide it in the PCI bus driver. > > > > Signed-off-by: David Marchand > > --- > > doc/guides/rel_notes/deprecation.rst | 7 +++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > > b/doc/guides/rel_notes/deprecation.rst > > index 9f73297173..6e86963c39 100644 > > --- a/doc/guides/rel_notes/deprecation.rst > > +++ b/doc/guides/rel_notes/deprecation.rst > > @@ -81,6 +81,13 @@ Deprecation Notices > >With this removal, there won't be a need for the mentioned workaround > > which > >will be reverted. > > > > +* pci: The ``rte_kernel_driver`` enum defined in rte_dev.h will be made > > private > > + to the PCI subsystem as it is used only by the PCI bus driver and PCI > > + drivers. > > + The associated field ``kdrv`` in the ethdev ``rte_eth_dev_data`` > > structure > > + will be removed as it gave no useful abstracted information to the > > + applications and had no user (neither internal nor external). > > + > > * ethdev: Split the ``struct eth_dev_ops`` struct to hide it as much as > > possible > >will be done in 20.11. > >Currently the ``struct eth_dev_ops`` struct is accessible by the > > application > > -- > > Acked-by: Bruce Richardson Acked-by: Gaetan Rivet -- Gaëtan
[dpdk-dev] [RFC] ethdev: add VLAN attributes to ETH item
In existing code the match on tagged/untagged packets is not explicit.
Recent documentation update [1] describes the different patterns and
clarifies the intended use of different patterns.
This patch proposes an update to ETH item struct, to clearly define the
required characteristic of a packet, and enable precise match criteria.
[1] http://mails.dpdk.org/archives/dev/2020-May/166257.html
Signed-off-by: Dekel Peled
---
lib/librte_ethdev/rte_flow.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
index cf0eccb..345feb5 100644
--- a/lib/librte_ethdev/rte_flow.h
+++ b/lib/librte_ethdev/rte_flow.h
@@ -726,11 +726,20 @@ struct rte_flow_item_raw {
* If the @p ETH item is the only item in the pattern, and the @p type field
* is not specified, then both tagged and untagged packets will match the
* pattern.
+ * The fields @p cvlan_exist and @p svlan_exist can be used to match specific
+ * packet types, instead of using the @p type field. This can be used to match
+ * on packets that do/don't contain either cvlan, svlan, or both.
+ * The field @p num_of_vlans can be used to match packets by the exact number
+ * of VLANs in header.
*/
struct rte_flow_item_eth {
struct rte_ether_addr dst; /**< Destination MAC. */
struct rte_ether_addr src; /**< Source MAC. */
rte_be16_t type; /**< EtherType or TPID. */
+ uint32_t cvlan_exist:1; /**< C-tag VLAN exist in header. */
+ uint32_t svlan_exist:1; /**< S-tag VLAN exist in header. */
+ uint32_t reserved:14; /**< Reserved, must be zero. */
+ uint32_t num_of_vlans:16; /**< Number of VLANs in header. */
};
/** Default mask for RTE_FLOW_ITEM_TYPE_ETH. */
--
1.8.3.1
Re: [dpdk-dev] [PATCH] doc: eventdev ABI change to support DLB PMD
> -Original Message- > From: dev On Behalf Of Jerin Jacob > Sent: Tuesday, August 4, 2020 1:09 PM > To: McDaniel, Timothy > Cc: Jerin Jacob ; Mattias Rönnblom > ; dpdk-dev ; Gage Eads > ; Van Haaren, Harry > Subject: Re: [dpdk-dev] [PATCH] doc: eventdev ABI change to support DLB > PMD > > On Mon, Aug 3, 2020 at 11:28 PM McDaniel, Timothy > wrote: > > > > From: "McDaniel, Timothy" > > There is still "," in the name. > > > > > The ABI changes associated with this notification will better support > > devices that: > > 1. Have limits on the number or queues that may be linked to a port 2. > > Have ports that are limited to exactly one linked queue 3. Are not > > able to transparently transfer the event flow_id field > > > > Signed-off-by: McDaniel Timothy > > > > > Acked-by: Jerin Jacob Acked-by: Hemant Agrawal > > > > --- > > doc/guides/rel_notes/deprecation.rst | 11 +++ > > 1 file changed, 11 insertions(+) > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > > b/doc/guides/rel_notes/deprecation.rst > > index 99c9806..bfe6661 100644 > > --- a/doc/guides/rel_notes/deprecation.rst > > +++ b/doc/guides/rel_notes/deprecation.rst > > @@ -148,3 +148,14 @@ Deprecation Notices > >Python 2 support will be completely removed in 20.11. > >In 20.08, explicit deprecation warnings will be displayed when running > >scripts with Python 2. > > + > > +* eventdev: ABI changes to support DLB PMD and future extensions: > > + ``rte_event_dev_info``, ``rte_event_dev_config``, > > +``rte_event_port_conf`` will > > + be modified to support DLB PMD and future extensions in the eventdev > library. > > + Patches containing justification, documentation, and proposed > > +modifications > > + can be found at: > > + > > + - > > + > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpa > > + > tches.dpdk.org%2Fpatch%2F71457%2F&data=02%7C01%7Chemant.agra > wal% > > + > 40nxp.com%7C0a8caadf8d834b79220b08d838497b8b%7C686ea1d3bc2b4c6fa > 92cd > > + > 99c5c301635%7C0%7C0%7C637321235549807830&sdata=9cH1qyDLlJz%2 > BNoI > > + whoam9rzpuMKGqZJWG6lMDkuoy1A%3D&reserved=0 > > + - > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch > es.dpdk.org%2Fpatch%2F71456%2F&data=02%7C01%7Chemant.agrawa > l%40nxp.com%7C0a8caadf8d834b79220b08d838497b8b%7C686ea1d3bc2b4c6 > fa92cd99c5c301635%7C0%7C0%7C637321235549817822&sdata=dHNynX > 75PGfiOtIycdm4raCRt5MWQPTWgHi%2Bj9Q331A%3D&reserved=0 > > + > > + > > -- > > 1.7.10 > >
Re: [dpdk-dev] [PATCH v2] doc: add reserve fields to eventdev public structures
On Tue, Aug 4, 2020 at 7:55 PM Bruce Richardson
wrote:
>
> On Tue, Aug 04, 2020 at 05:07:12PM +0530, Jerin Jacob wrote:
> > On Tue, Aug 4, 2020 at 4:12 PM Bruce Richardson
> > wrote:
> > >
> > > On Mon, Aug 03, 2020 at 12:59:03PM +0530, pbhagavat...@marvell.com wrote:
> > > > From: Pavan Nikhilesh
> > > >
> > > > Add 64 byte padding at the end of event device public structure to allow
> > > > future extensions.
> > > >
> > > > Signed-off-by: Pavan Nikhilesh
> > > > Acked-by: Jerin Jacob
> > > > ---
> > > > v2 Changes:
> > > > - Modify commit title.
> > > > - Add patch reference to doc.
> > > >
> > > > doc/guides/rel_notes/deprecation.rst | 11 +++
> > > > 1 file changed, 11 insertions(+)
> > > >
> > > > diff --git a/doc/guides/rel_notes/deprecation.rst
> > > > b/doc/guides/rel_notes/deprecation.rst
> > > > index ea4cfa7a4..ec5db68e9 100644
> > > > --- a/doc/guides/rel_notes/deprecation.rst
> > > > +++ b/doc/guides/rel_notes/deprecation.rst
> > > > @@ -151,3 +151,14 @@ Deprecation Notices
> > > >Python 2 support will be completely removed in 20.11.
> > > >In 20.08, explicit deprecation warnings will be displayed when
> > > > running
> > > >scripts with Python 2.
> > > > +
> > > > +* eventdev: A 64 byte padding is added at the end of the following
> > > > structures
> > > > + in event device library to support future extensions:
> > > > + ``rte_event_crypto_adapter_conf``, ``rte_event_eth_rx_adapter_conf``,
> > > > + ``rte_event_eth_rx_adapter_queue_conf``,
> > > > ``rte_event_eth_tx_adapter_conf``,
> > > > + ``rte_event_timer_adapter_conf``, ``rte_event_timer_adapter_info``,
> > > > + ``rte_event_dev_info``, ``rte_event_dev_config``,
> > > > ``rte_event_queue_conf``,
> > > > + ``rte_event_port_conf``, ``rte_event_timer_adapter``,
> > > > + ``rte_event_timer_adapter_data``.
> > > > + Reference:
> > > > +
> > > > http://patches.dpdk.org/project/dpdk/list/?series=10728&archive=both&state=*
> > > > --
> > >
> > > I don't like this idea of adding lots of padding to the ends of these
> > > structures. For some structures, such as the public arrays for devices it
> > > may be necessary, but for all the conf structures passed as parameters to
> > > functions I think we can do better. Since these structures are passed by
> > > the user to various functions, function versioning can be used to ensure
> > > that the correct function in eventdev is always called. From there to the
> > > individual PMDs, we can implement ABI compatibility by either:
> > > 1. including the length of the struct as a parameter to the driver. (This
> > > is
> > > a bit similar to my proposal for rawdev [1])
> > > 2. including the ABI version as a parameter to the driver.
> >
> > But, Will the above solution work if the application is dependent on
> > struct size?
> > i.e change of s1 size will change offset of s3 i.e
> > app_sepecific_struct_s3. Right?
> > i.e DPDK version should not change the offset of s3. Right?
> >
> > example,
> > struct app_struct {
> > struct dpdk_public_struct_s1 s1;
> > struct dpdk_public_struct_s2 s2;
> > struct app_sepecific_struct_s3 s3;
> > }
> >
> Not sure what exactly you mean here. The actual offsets and sizes of the
> structs will obviously change as you change the struct, but the end
> compiled app has no idea of structs, all it knows of is offsets, which is
> why you provide ABI compatible versions of the functions which use "legacy"
> copies of the structs to ensure correct offsets. It's pretty much standard
> practice for ABI versioning.
Currently, We have only function versioning(not structure versioning).
Are you suggesting having structure versioning?
Will it complicate the code in terms of readability and supporting multiple
structure versions aginst its support functions.
>
> The real complication arises because the actual eventdev driver functions
> are not called directly with the linker resolving symbol versioning.
> Instead they are called using function pointers from the code. This is why
> one needs to add in the additional parameter to the driver APIs so that the
> ABI info - be it struct size or version - can be passed from the versioned
> eventdev library function through to the driver.
If I understand it correctly, it is easy for rawdev subsystem as
config structure as _opaque_.
But in the case for ethdev, cryptodev, eventdev, config structure are
not opaque.
If we take structure versioning, Is n't call for adding structure
version change to
functions that's been associated with(Kind of M x N case to make a
structure change. Here M means
offending structure to make change and N means function associated
with structure)
>
> Regards,
> /Bruce
[dpdk-dev] [PATCH] doc: announce change in ETH item struct
Struct rte_flow_item_eth will be modified to include additional values, indicating existence or absence of VLAN headers following the ETH header, as proposed in RFC https://mails.dpdk.org/archives/dev/2020-August/177349.html. Because of ABI break this change is proposed for 20.11. Signed-off-by: Dekel Peled --- doc/guides/rel_notes/deprecation.rst | 5 + 1 file changed, 5 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 5201142..6241709 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -115,6 +115,11 @@ Deprecation Notices following the IPv6 header, as proposed in RFC https://mails.dpdk.org/archives/dev/2020-August/177257.html. +* ethdev: The ``struct rte_flow_item_eth`` struct will be modified to include + additional values, indicating existence or absence of VLAN headers + following the ETH header, as proposed in RFC + https://mails.dpdk.org/archives/dev/2020-August/177349.html. + * traffic manager: All traffic manager API's in ``rte_tm.h`` were mistakenly made ABI stable in the v19.11 release. The TM maintainer and other contributors have agreed to keep the TM APIs as experimental in expectation of additional spec -- 1.8.3.1
Re: [dpdk-dev] [PATCH v2] doc: add reserve fields to eventdev public structures
On Tue, 4 Aug 2020 11:41:53 +0100 Bruce Richardson wrote: > On Mon, Aug 03, 2020 at 12:59:03PM +0530, pbhagavat...@marvell.com wrote: > > From: Pavan Nikhilesh > > > > Add 64 byte padding at the end of event device public structure to allow > > future extensions. > > > > Signed-off-by: Pavan Nikhilesh > > Acked-by: Jerin Jacob > > --- > > v2 Changes: > > - Modify commit title. > > - Add patch reference to doc. > > > > doc/guides/rel_notes/deprecation.rst | 11 +++ > > 1 file changed, 11 insertions(+) > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > > b/doc/guides/rel_notes/deprecation.rst > > index ea4cfa7a4..ec5db68e9 100644 > > --- a/doc/guides/rel_notes/deprecation.rst > > +++ b/doc/guides/rel_notes/deprecation.rst > > @@ -151,3 +151,14 @@ Deprecation Notices > >Python 2 support will be completely removed in 20.11. > >In 20.08, explicit deprecation warnings will be displayed when running > >scripts with Python 2. > > + > > +* eventdev: A 64 byte padding is added at the end of the following > > structures > > + in event device library to support future extensions: > > + ``rte_event_crypto_adapter_conf``, ``rte_event_eth_rx_adapter_conf``, > > + ``rte_event_eth_rx_adapter_queue_conf``, > > ``rte_event_eth_tx_adapter_conf``, > > + ``rte_event_timer_adapter_conf``, ``rte_event_timer_adapter_info``, > > + ``rte_event_dev_info``, ``rte_event_dev_config``, > > ``rte_event_queue_conf``, > > + ``rte_event_port_conf``, ``rte_event_timer_adapter``, > > + ``rte_event_timer_adapter_data``. > > + Reference: > > + > > http://patches.dpdk.org/project/dpdk/list/?series=10728&archive=both&state=* > > -- > > I don't like this idea of adding lots of padding to the ends of these > structures. For some structures, such as the public arrays for devices it > may be necessary, but for all the conf structures passed as parameters to > functions I think we can do better. Since these structures are passed by > the user to various functions, function versioning can be used to ensure > that the correct function in eventdev is always called. From there to the > individual PMDs, we can implement ABI compatibility by either: > 1. including the length of the struct as a parameter to the driver. (This is > a bit similar to my proposal for rawdev [1]) > 2. including the ABI version as a parameter to the driver. > > Regards > /Bruce > > [1] http://inbox.dpdk.org/dev/?q=enhance+rawdev+APIs This is a bad idea. Reserved fields won't work because nothing requires that the application zero them. You can't start using them later because the application may put uninitialized or junk data there.
Re: [dpdk-dev] [RFC] ethdev: add VLAN attributes to ETH item
On Tue, 4 Aug 2020 18:36:20 +0300
Dekel Peled wrote:
> In existing code the match on tagged/untagged packets is not explicit.
> Recent documentation update [1] describes the different patterns and
> clarifies the intended use of different patterns.
>
> This patch proposes an update to ETH item struct, to clearly define the
> required characteristic of a packet, and enable precise match criteria.
>
> [1] http://mails.dpdk.org/archives/dev/2020-May/166257.html
>
> Signed-off-by: Dekel Peled
> ---
> lib/librte_ethdev/rte_flow.h | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> index cf0eccb..345feb5 100644
> --- a/lib/librte_ethdev/rte_flow.h
> +++ b/lib/librte_ethdev/rte_flow.h
> @@ -726,11 +726,20 @@ struct rte_flow_item_raw {
> * If the @p ETH item is the only item in the pattern, and the @p type field
> * is not specified, then both tagged and untagged packets will match the
> * pattern.
> + * The fields @p cvlan_exist and @p svlan_exist can be used to match specific
> + * packet types, instead of using the @p type field. This can be used to
> match
> + * on packets that do/don't contain either cvlan, svlan, or both.
> + * The field @p num_of_vlans can be used to match packets by the exact number
> + * of VLANs in header.
> */
> struct rte_flow_item_eth {
> struct rte_ether_addr dst; /**< Destination MAC. */
> struct rte_ether_addr src; /**< Source MAC. */
> rte_be16_t type; /**< EtherType or TPID. */
> + uint32_t cvlan_exist:1; /**< C-tag VLAN exist in header. */
> + uint32_t svlan_exist:1; /**< S-tag VLAN exist in header. */
> + uint32_t reserved:14; /**< Reserved, must be zero. */
> + uint32_t num_of_vlans:16; /**< Number of VLANs in header. */
> };
>
> /** Default mask for RTE_FLOW_ITEM_TYPE_ETH. */
You are making life easy for you but harder for existing
users of flow_item_eth API.
Why not add new flow_item for vlan and handle multiple levels there.
Re: [dpdk-dev] [PATCH] net/bnxt: fix variable size of port id
On Tue, 4 Aug 2020 17:41:47 +
Chenbo Xia wrote:
> Currenly the variable size of ethdev port id is 8 bits. This
> patch standarizes it to 16 bits.
>
> Fixes: 769de16872ab ("net/bnxt: fix port default rule create/destroy")
> Cc: sta...@dpdk.org
>
> Reported-by: Yinan Wang
> Signed-off-by: Chenbo Xia
> ---
BNXT_ETH_DEV_IS_REPRESENTOR(bp->eth_dev))
Acked-by: Stephen Hemminger
Re: [dpdk-dev] [PATCH v2] doc: add reserve fields to eventdev public structures
On Tue, Aug 04, 2020 at 09:33:14PM +0530, Jerin Jacob wrote:
> On Tue, Aug 4, 2020 at 7:55 PM Bruce Richardson
> wrote:
> >
> > On Tue, Aug 04, 2020 at 05:07:12PM +0530, Jerin Jacob wrote:
> > > On Tue, Aug 4, 2020 at 4:12 PM Bruce Richardson
> > > wrote:
> > > >
> > > > On Mon, Aug 03, 2020 at 12:59:03PM +0530, pbhagavat...@marvell.com
> > > > wrote:
> > > > > From: Pavan Nikhilesh
> > > > >
> > > > > Add 64 byte padding at the end of event device public structure to
> > > > > allow
> > > > > future extensions.
> > > > >
> > > > > Signed-off-by: Pavan Nikhilesh
> > > > > Acked-by: Jerin Jacob
> > > > > ---
> > > > > v2 Changes:
> > > > > - Modify commit title.
> > > > > - Add patch reference to doc.
> > > > >
> > > > > doc/guides/rel_notes/deprecation.rst | 11 +++
> > > > > 1 file changed, 11 insertions(+)
> > > > >
> > > > > diff --git a/doc/guides/rel_notes/deprecation.rst
> > > > > b/doc/guides/rel_notes/deprecation.rst
> > > > > index ea4cfa7a4..ec5db68e9 100644
> > > > > --- a/doc/guides/rel_notes/deprecation.rst
> > > > > +++ b/doc/guides/rel_notes/deprecation.rst
> > > > > @@ -151,3 +151,14 @@ Deprecation Notices
> > > > >Python 2 support will be completely removed in 20.11.
> > > > >In 20.08, explicit deprecation warnings will be displayed when
> > > > > running
> > > > >scripts with Python 2.
> > > > > +
> > > > > +* eventdev: A 64 byte padding is added at the end of the following
> > > > > structures
> > > > > + in event device library to support future extensions:
> > > > > + ``rte_event_crypto_adapter_conf``,
> > > > > ``rte_event_eth_rx_adapter_conf``,
> > > > > + ``rte_event_eth_rx_adapter_queue_conf``,
> > > > > ``rte_event_eth_tx_adapter_conf``,
> > > > > + ``rte_event_timer_adapter_conf``, ``rte_event_timer_adapter_info``,
> > > > > + ``rte_event_dev_info``, ``rte_event_dev_config``,
> > > > > ``rte_event_queue_conf``,
> > > > > + ``rte_event_port_conf``, ``rte_event_timer_adapter``,
> > > > > + ``rte_event_timer_adapter_data``.
> > > > > + Reference:
> > > > > +
> > > > > http://patches.dpdk.org/project/dpdk/list/?series=10728&archive=both&state=*
> > > > > --
> > > >
> > > > I don't like this idea of adding lots of padding to the ends of these
> > > > structures. For some structures, such as the public arrays for devices
> > > > it
> > > > may be necessary, but for all the conf structures passed as parameters
> > > > to
> > > > functions I think we can do better. Since these structures are passed by
> > > > the user to various functions, function versioning can be used to ensure
> > > > that the correct function in eventdev is always called. From there to
> > > > the
> > > > individual PMDs, we can implement ABI compatibility by either:
> > > > 1. including the length of the struct as a parameter to the driver.
> > > > (This is
> > > > a bit similar to my proposal for rawdev [1])
> > > > 2. including the ABI version as a parameter to the driver.
> > >
> > > But, Will the above solution work if the application is dependent on
> > > struct size?
> > > i.e change of s1 size will change offset of s3 i.e
> > > app_sepecific_struct_s3. Right?
> > > i.e DPDK version should not change the offset of s3. Right?
> > >
> > > example,
> > > struct app_struct {
> > > struct dpdk_public_struct_s1 s1;
> > > struct dpdk_public_struct_s2 s2;
> > > struct app_sepecific_struct_s3 s3;
> > > }
> > >
> > Not sure what exactly you mean here. The actual offsets and sizes of the
> > structs will obviously change as you change the struct, but the end
> > compiled app has no idea of structs, all it knows of is offsets, which is
> > why you provide ABI compatible versions of the functions which use "legacy"
> > copies of the structs to ensure correct offsets. It's pretty much standard
> > practice for ABI versioning.
>
> Currently, We have only function versioning(not structure versioning).
> Are you suggesting having structure versioning?
> Will it complicate the code in terms of readability and supporting multiple
> structure versions aginst its support functions.
>
We don't, and can't version structures, only functions are versioned.
Even if we do what you suggest and add a block of 64-bytes expansion room
at the end of the structures, how is the function you are calling expected
to know what the structure actually contains? For example, if you add a
field to the end, and reduce the padding by 8 bytes, your structure is
still the same size, and how does the called function know whether X or X+8
bytes are valid in it. Basically, you still need to version all
functions using the structure, just as if you didn't bother extending the
struct.
> >
> > The real complication arises because the actual eventdev driver functions
> > are not called directly with the linker resolving symbol versioning.
> > Instead they are called using function pointers from the code. This is why
> > one needs to add in the additional parameter to the dri
Re: [dpdk-dev] [PATCH v2] doc: add reserve fields to eventdev public structures
On Tue, Aug 4, 2020 at 9:54 PM Bruce Richardson
wrote:
>
> On Tue, Aug 04, 2020 at 09:33:14PM +0530, Jerin Jacob wrote:
> > On Tue, Aug 4, 2020 at 7:55 PM Bruce Richardson
> > wrote:
> > >
> > > On Tue, Aug 04, 2020 at 05:07:12PM +0530, Jerin Jacob wrote:
> > > > On Tue, Aug 4, 2020 at 4:12 PM Bruce Richardson
> > > > wrote:
> > > > >
> > > > > On Mon, Aug 03, 2020 at 12:59:03PM +0530, pbhagavat...@marvell.com
> > > > > wrote:
> > > > > > From: Pavan Nikhilesh
> > > > > >
> > > > > > Add 64 byte padding at the end of event device public structure to
> > > > > > allow
> > > > > > future extensions.
> > > > > >
> > > > > > Signed-off-by: Pavan Nikhilesh
> > > > > > Acked-by: Jerin Jacob
> > > > > > ---
> > > > > > v2 Changes:
> > > > > > - Modify commit title.
> > > > > > - Add patch reference to doc.
> > > > > >
> > > > > > doc/guides/rel_notes/deprecation.rst | 11 +++
> > > > > > 1 file changed, 11 insertions(+)
> > > > > >
> > > > > > diff --git a/doc/guides/rel_notes/deprecation.rst
> > > > > > b/doc/guides/rel_notes/deprecation.rst
> > > > > > index ea4cfa7a4..ec5db68e9 100644
> > > > > > --- a/doc/guides/rel_notes/deprecation.rst
> > > > > > +++ b/doc/guides/rel_notes/deprecation.rst
> > > > > > @@ -151,3 +151,14 @@ Deprecation Notices
> > > > > >Python 2 support will be completely removed in 20.11.
> > > > > >In 20.08, explicit deprecation warnings will be displayed when
> > > > > > running
> > > > > >scripts with Python 2.
> > > > > > +
> > > > > > +* eventdev: A 64 byte padding is added at the end of the following
> > > > > > structures
> > > > > > + in event device library to support future extensions:
> > > > > > + ``rte_event_crypto_adapter_conf``,
> > > > > > ``rte_event_eth_rx_adapter_conf``,
> > > > > > + ``rte_event_eth_rx_adapter_queue_conf``,
> > > > > > ``rte_event_eth_tx_adapter_conf``,
> > > > > > + ``rte_event_timer_adapter_conf``,
> > > > > > ``rte_event_timer_adapter_info``,
> > > > > > + ``rte_event_dev_info``, ``rte_event_dev_config``,
> > > > > > ``rte_event_queue_conf``,
> > > > > > + ``rte_event_port_conf``, ``rte_event_timer_adapter``,
> > > > > > + ``rte_event_timer_adapter_data``.
> > > > > > + Reference:
> > > > > > +
> > > > > > http://patches.dpdk.org/project/dpdk/list/?series=10728&archive=both&state=*
> > > > > > --
> > > > >
> > > > > I don't like this idea of adding lots of padding to the ends of these
> > > > > structures. For some structures, such as the public arrays for
> > > > > devices it
> > > > > may be necessary, but for all the conf structures passed as
> > > > > parameters to
> > > > > functions I think we can do better. Since these structures are passed
> > > > > by
> > > > > the user to various functions, function versioning can be used to
> > > > > ensure
> > > > > that the correct function in eventdev is always called. From there to
> > > > > the
> > > > > individual PMDs, we can implement ABI compatibility by either:
> > > > > 1. including the length of the struct as a parameter to the driver.
> > > > > (This is
> > > > > a bit similar to my proposal for rawdev [1])
> > > > > 2. including the ABI version as a parameter to the driver.
> > > >
> > > > But, Will the above solution work if the application is dependent on
> > > > struct size?
> > > > i.e change of s1 size will change offset of s3 i.e
> > > > app_sepecific_struct_s3. Right?
> > > > i.e DPDK version should not change the offset of s3. Right?
> > > >
> > > > example,
> > > > struct app_struct {
> > > > struct dpdk_public_struct_s1 s1;
> > > > struct dpdk_public_struct_s2 s2;
> > > > struct app_sepecific_struct_s3 s3;
> > > > }
> > > >
> > > Not sure what exactly you mean here. The actual offsets and sizes of the
> > > structs will obviously change as you change the struct, but the end
> > > compiled app has no idea of structs, all it knows of is offsets, which is
> > > why you provide ABI compatible versions of the functions which use
> > > "legacy"
> > > copies of the structs to ensure correct offsets. It's pretty much standard
> > > practice for ABI versioning.
> >
> > Currently, We have only function versioning(not structure versioning).
> > Are you suggesting having structure versioning?
> > Will it complicate the code in terms of readability and supporting multiple
> > structure versions aginst its support functions.
> >
>
> We don't, and can't version structures, only functions are versioned.
> Even if we do what you suggest and add a block of 64-bytes expansion room
> at the end of the structures, how is the function you are calling expected
> to know what the structure actually contains? For example, if you add a
> field to the end, and reduce the padding by 8 bytes, your structure is
> still the same size, and how does the called function know whether X or X+8
> bytes are valid in it. Basically, you still need to version all
> functions using the structure, just as if you didn't bother extending the
[dpdk-dev] [PATCH] tracepoint: fix compilation with C++
trace_mem is declared as 'void *' which triggers following error:
'...invalid conversion from ‘void*’ to ‘__rte_trace_header*’
[-fpermissive]...'
Fix this by changing void to struct __rte_trace_header
---
lib/librte_eal/common/eal_common_trace.c | 2 +-
lib/librte_eal/include/rte_trace_point.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_trace.c
b/lib/librte_eal/common/eal_common_trace.c
index 875553d7e..18e5e64be 100644
--- a/lib/librte_eal/common/eal_common_trace.c
+++ b/lib/librte_eal/common/eal_common_trace.c
@@ -16,7 +16,7 @@
#include "eal_trace.h"
RTE_DEFINE_PER_LCORE(volatile int, trace_point_sz);
-RTE_DEFINE_PER_LCORE(void *, trace_mem);
+RTE_DEFINE_PER_LCORE(struct __rte_trace_header *, trace_mem);
static RTE_DEFINE_PER_LCORE(char, ctf_field[TRACE_CTF_FIELD_SIZE]);
static RTE_DEFINE_PER_LCORE(int, ctf_count);
diff --git a/lib/librte_eal/include/rte_trace_point.h
b/lib/librte_eal/include/rte_trace_point.h
index b45171275..587f600ec 100644
--- a/lib/librte_eal/include/rte_trace_point.h
+++ b/lib/librte_eal/include/rte_trace_point.h
@@ -295,7 +295,7 @@ struct __rte_trace_header {
uint8_t mem[];
};
-RTE_DECLARE_PER_LCORE(void *, trace_mem);
+RTE_DECLARE_PER_LCORE(struct __rte_trace_header *, trace_mem);
static __rte_always_inline void *
__rte_trace_mem_get(uint64_t in)
--
2.17.1
Re: [dpdk-dev] [PATCH v4 1/5] eal: added interrupts empty stubs
On Tue, Aug 04, 2020 at 09:29:43AM +0300, Fady Bader wrote: > The ethdev lib uses interrupts. Interrupts are not implemented for Windows. > To solve this, empty interrupt stubs were added under Windows. > > Signed-off-by: Fady Bader > --- > lib/librte_eal/windows/eal_interrupts.c | 17 + > lib/librte_eal/windows/meson.build | 1 + > 2 files changed, 18 insertions(+) > create mode 100644 lib/librte_eal/windows/eal_interrupts.c > Acked-by: Narcisa Vasile
Re: [dpdk-dev] [PATCH v4 2/5] eal: updated export list for Windows
On Tue, Aug 04, 2020 at 09:29:44AM +0300, Fady Bader wrote: > Added eal functions used by ethdev lib to the export list under Windows. > > Signed-off-by: Fady Bader > --- > lib/librte_eal/rte_eal_exports.def | 11 +++ > 1 file changed, 11 insertions(+) > Acked-by: Narcisa Vasile
Re: [dpdk-dev] [PATCH v4 3/5] ethdev: remove structs from export list
On Tue, Aug 04, 2020 at 09:29:45AM +0300, Fady Bader wrote: > Some ethdev structs were present in ethdev export list. > There structs were removed from the export list. > > Signed-off-by: Fady Bader > --- > lib/librte_ethdev/rte_ethdev_version.map | 2 -- > 1 file changed, 2 deletions(-) > Acked-by: Narcisa Vasile
Re: [dpdk-dev] [PATCH v4 4/5] telemetry: implement empty stubs for Windows
On Tue, Aug 04, 2020 at 09:29:46AM +0300, Fady Bader wrote: > Telemetry didn't compile under Windows. > Empty stubs implementation was added for Windows. > > Signed-off-by: Fady Bader > --- > lib/librte_telemetry/rte_telemetry.h| 4 +++ > lib/librte_telemetry/telemetry.c| 51 > - > lib/librte_telemetry/telemetry_legacy.c | 26 - > 3 files changed, 79 insertions(+), 2 deletions(-) > Acked-by: Narcisa Vasile
Re: [dpdk-dev] [PATCH v4 5/5] ethdev: compiling ethdev under Windows
On Tue, Aug 04, 2020 at 09:29:47AM +0300, Fady Bader wrote: > Compiling needed libraries for ethdev under Windows. > > Signed-off-by: Fady Bader > --- > lib/meson.build | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > Acked-by: Narcisa Vasile
Re: [dpdk-dev] [PATCH] doc: announce API change in timer
[ > > Subject: Re: [dpdk-dev] [PATCH] doc: announce API change in timer > > > > Thank you Eric, I will fix the mistakes in v2 > > > > On Tue, Aug 4, 2020 at 4:16 AM Honnappa Nagarahalli > > wrote: > > > > > > > > > > > > > > > > > If the user tries to reset/stop some other timer in it's callback > > > > function, which > > > Is there any use case for this? Why not just say document that the > > > user is > > not allowed to reset some other timer in the call back function? How > > does the user get access to some other timer in the call back function? > > > Not sure if this was discussed earlier, I might have missed. > > The issue is more clearly described in bug 491 here is a link: > > https://bugs.dpdk.org/show_bug.cgi?id=491 > > further discussion on this issue was done on the following patch: > > https://patches.dpdk.org/patch/73683/ Thanks for the links. > > > > I like Honnappa's suggestion... we could document that the *_sync functions > shouldn't be used inside timer callbacks since there are cases where it could > hang. Instead, if doing this was desired, the regular versions could be used > there, and the return values could be checked in that case. Agree, non sync functions can be used. > > > > > > > > is also about to expire, using > > > > rte_timer_reset_sync/rte_timer_stop_sync the application goes into > > > > an infinite loop. This happens because > > > > rte_timer_reset_sync/rte_timer_stop_sync loop until the timer > > > > resets/stops and there is check inside timer_set_config_state > > > > which prevents a running timer from being reset/stopped by not > > > > it's own timer_cb. Therefore timer_set_config_state returns -1 due > > > > to which rte_timer_reset returns -1 and rte_timer_reset_sync goes > > > > into an infinite loop > > > > > > > > To to prevent this rte_timer_reset_sync and rte_timer_stop_sync > > > > should have int return types, so that -1 can be returned if the > > > > above condition occurs > > > > > > > > Signed-off-by: Sarosh Arif > > > > --- > > > > doc/guides/rel_notes/deprecation.rst | 6 ++ > > > > 1 file changed, 6 insertions(+) > > > > > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > > > > b/doc/guides/rel_notes/deprecation.rst > > > > index ea4cfa7a4..ed93a707d 100644 > > > > --- a/doc/guides/rel_notes/deprecation.rst > > > > +++ b/doc/guides/rel_notes/deprecation.rst > > > > @@ -151,3 +151,9 @@ Deprecation Notices > > > >Python 2 support will be completely removed in 20.11. > > > >In 20.08, explicit deprecation warnings will be displayed when > > > > running > > > >scripts with Python 2. > > > > + > > > > +* timer: Since timer can get stuck in an infinite loop if the > > > > +application tries to > > > > + reset/stop some other timer in it's callback function, which is > > > > +also about to > > > > + expire. The function ``rte_timer_stop_sync`` and > > > > +``rte_timer_stop_sync`` will > > > > + have a int return type in order to return with -1 in when this > > > > +condition > > > > + occures. > > > > -- > > > > 2.17.1 > > >
Re: [dpdk-dev] [PATCH] doc: announce ethdev port freeing on close operation
On Tue, Aug 4, 2020 at 2:29 AM Hemant Agrawal wrote: > > On Tue, Aug 4, 2020 at 2:50 PM Thomas Monjalon > > wrote: > > > > > > Since DPDK 18.11, some drivers are migrating to a new behaviour, > > > releasing port resources on close. > > > The temporary flag RTE_ETH_DEV_CLOSE_REMOVE triggers this new mode > > in > > > the migrated drivers. > > > After 2 years, the flag and the old behaviour will be removed. > > > Last drivers not migrated will have to complete the switch. > > > > > > Signed-off-by: Thomas Monjalon > > > Acked-by: Hemant Agrawal > Acked-by: Ajit Khaparde
Re: [dpdk-dev] [PATCH v4 4/5] telemetry: implement empty stubs for Windows
On Tue, 4 Aug 2020 09:29:46 +0300, Fady Bader wrote: > Telemetry didn't compile under Windows. > Empty stubs implementation was added for Windows. > > Signed-off-by: Fady Bader > --- > lib/librte_telemetry/rte_telemetry.h| 4 +++ > lib/librte_telemetry/telemetry.c| 51 > - > lib/librte_telemetry/telemetry_legacy.c | 26 - > 3 files changed, 79 insertions(+), 2 deletions(-) You could #ifdef code in librte_ethdev that uses librte_telemetry and not build librte_telemetry at all. This approach is already taken in eal_common_options.c and it avoids spreading #ifdef throughout telemetry code.
Re: [dpdk-dev] [PATCH v4 1/5] eal: added interrupts empty stubs
On Tue, 4 Aug 2020 09:29:43 +0300, Fady Bader wrote: [snip] > diff --git a/lib/librte_eal/windows/eal_interrupts.c > b/lib/librte_eal/windows/eal_interrupts.c > new file mode 100644 > index 00..1e3c6d20d2 > --- /dev/null > +++ b/lib/librte_eal/windows/eal_interrupts.c > @@ -0,0 +1,17 @@ > +/* SPDX-License-Identifier: BSD-3-Clause > + * Copyright 2020 Mellanox Technologies, Ltd > + */ Blank line is needed here, like in other files. > +#include [snip] > diff --git a/lib/librte_eal/windows/meson.build > b/lib/librte_eal/windows/meson.build > index 08c888e018..c5a19648d6 100644 > --- a/lib/librte_eal/windows/meson.build > +++ b/lib/librte_eal/windows/meson.build > @@ -17,6 +17,7 @@ sources += files( > 'eal_timer.c', > 'fnmatch.c', > 'getopt.c', > + 'eal_interrupts.c', > ) Please keep the list sorted.
[dpdk-dev] [PATCH V1] doc: Add tested Intel platforms for DPDK 20.08 release
From: ChenBo doc: add tested Intel platforms with Intel NICs. Signed-off-by: ChenBo --- doc/guides/rel_notes/release_20_08.rst | 107 + 1 file changed, 107 insertions(+) diff --git a/doc/guides/rel_notes/release_20_08.rst b/doc/guides/rel_notes/release_20_08.rst index 9761f5a4f..034c4e244 100644 --- a/doc/guides/rel_notes/release_20_08.rst +++ b/doc/guides/rel_notes/release_20_08.rst @@ -351,6 +351,113 @@ Tested Platforms Also, make sure to start the actual text at the margin. = +* Intel\ |reg| platforms with Intel\ |reg| NICs combinations + + * CPU + +* Intel\ |reg| Atom\ |trade| CPU C3758 @ 2.20GHz +* Intel\ |reg| Atom\ |trade| CPU C3858 @ 2.00GHz +* Intel\ |reg| Atom\ |trade| CPU C3958 @ 2.00GHz +* Intel\ |reg| Xeon\ |reg| CPU D-1541 @ 2.10GHz +* Intel\ |reg| Xeon\ |reg| CPU D-1553N @ 2.30GHz +* Intel\ |reg| Xeon\ |reg| CPU E5-2680 0 @ 2.70GHz +* Intel\ |reg| Xeon\ |reg| CPU E5-2680 v2 @ 2.80GHz +* Intel\ |reg| Xeon\ |reg| CPU E5-2699 v3 @ 2.30GHz +* Intel\ |reg| Xeon\ |reg| CPU E5-2699 v4 @ 2.20GHz +* Intel\ |reg| Xeon\ |reg| Gold 5218N CPU @ 2.30GHz +* Intel\ |reg| Xeon\ |reg| Gold 6139 CPU @ 2.30GHz +* Intel\ |reg| Xeon\ |reg| Gold 6252N CPU @ 2.30GHz +* Intel\ |reg| Xeon\ |reg| Platinum 8180 CPU @ 2.50GHz +* Intel\ |reg| Xeon\ |reg| Platinum 8280M CPU @ 2.70GHz + + * OS: + +* CentOS 7.7 +* CentOS 8.0 +* CentOS 8.2 +* Fedora 32 +* FreeBSD 12.1 +* OpenWRT 19.07 +* Red Hat Enterprise Linux Server release 8.2 +* Suse15 SP1 +* Ubuntu 16.04 +* Ubuntu 18.04 +* Ubuntu 20.04 + + * NICs: + +* Intel\ |reg| 82599ES 10 Gigabit Ethernet Controller + + * Firmware version: 0x61bf0001 + * Device id (pf/vf): 8086:10fb / 8086:10ed + * Driver version: 5.7.1 (ixgbe) + +* Intel\ |reg| Corporation Ethernet Connection X552/X557-AT 10GBASE-T + + * Firmware version: 0x83e7 + * Device id (pf/vf): 8086:15ad / 8086:15a8 + * Driver version: 5.1.0-k (ixgbe) + +* Intel\ |reg| Corporation Ethernet Controller 10G X550T + + * Firmware version: 0x8482 + * Device id (pf): 8086:1563 + * Driver version: 5.7.1 (ixgbe) + +* Intel\ |reg| Ethernet Converged Network Adapter X710-DA4 (4x10G) + + * Firmware version: 7.20 0x800079e8 1.2585.0 + * Device id (pf/vf): 8086:1572 / 8086:154c + * Driver version: 2.12.6 (i40e) + +* Intel\ |reg| Corporation Ethernet Connection X722 for 10GbE SFP+ (4x10G) + + * Firmware version: 4.11 0x80001def 1.1999.0 + * Device id (pf/vf): 8086:37d0 / 8086:37cd + * Driver version: 2.12.6 (i40e) + +* Intel\ |reg| Corporation Ethernet Connection X722 for 10GBASE-T (2x10G) + + * Firmware version: 4.10 0x80001a7a + * Device id (pf/vf): 8086:37d2 / 8086:37cd + * Driver version: 2.12.6 (i40e) + +* Intel\ |reg| Ethernet Converged Network Adapter XXV710-DA2 (2x25G) + + * Firmware version: 7.30 0x800080a2 1.2658.0 + * Device id (pf/vf): 8086:158b / 8086:154c + * Driver version: 2.12.6 (i40e) + +* Intel\ |reg| Ethernet Converged Network Adapter XL710-QDA2 (2X40G) + + * Firmware version: 7.30 0x800080ab 1.2658.0 + * Device id (pf/vf): 8086:1583 / 8086:154c + * Driver version: 2.12.6 (i40e) + +* Intel\ |reg| Corporation I350 Gigabit Network Connection + + * Firmware version: 1.63, 0x8cbc + * Device id (pf/vf): 8086:1521 / 8086:1520 + * Driver version: 5.4.0-k (igb) + +* Intel\ |reg| Corporation I210 Gigabit Network Connection + + * Firmware version: 3.25, 0x86eb + * Device id (pf): 8086:1533 + * Driver version: 5.4.0-k (igb) + +* Intel\ |reg| Ethernet Controller 10-Gigabit X540-AT2 + + * Firmware version: 0x85f9 + * Device id (pf): 8086:1528 + * Driver version: 5.1.0-k (ixgbe) + +* Intel\ |reg| Ethernet Converged Network Adapter X710-T2L + + * Firmware version: 7.30 0x80008061 1.2585.0 + * Device id (pf): 8086:15ff + * Driver version: 2.12.6(i40e) + * Intel\ |reg| platforms with Mellanox\ |reg| NICs combinations * CPU: -- 2.17.1
[dpdk-dev] [PATCH V1] doc: update firmware/dricer mapping table for i40e
From: ChenBo Update i40e PMD firmware/driver mapping table. Signed-off-by: ChenBo --- doc/guides/nics/i40e.rst | 4 1 file changed, 4 insertions(+) diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst index cf1ae2d0b..b7430f6c4 100644 --- a/doc/guides/nics/i40e.rst +++ b/doc/guides/nics/i40e.rst @@ -88,6 +88,8 @@ For X710/XL710/XXV710, +--+---+--+ | DPDK version | Kernel driver version | Firmware version | +==+===+==+ + |20.08 | 2.12.6| 7.30 | + +--+---+--+ |20.05 | 2.11.27 | 7.30 | +--+---+--+ |20.02 | 2.10.19 | 7.20 | @@ -129,6 +131,8 @@ For X722, +--+---+--+ | DPDK version | Kernel driver version | Firmware version | +==+===+==+ + |20.08 | 2.12.6| 4.11 | + +--+---+--+ |20.05 | 2.11.27 | 4.11 | +--+---+--+ |20.02 | 2.10.19 | 4.11 | -- 2.17.1
Re: [dpdk-dev] [PATCH] [RFC] cryptodev: move AES-GMAC to aead algorithms
Hi Akhil, @Akhil: Is there a chance getting this change into 20.11? Any more comments or anyone see any potential issues with this approach? Regards, Arek -Original Message- From: Doherty, Declan Sent: piątek, 31 lipca 2020 16:34 To: Kusztal, ArkadiuszX ; dev@dpdk.org Cc: akhil.go...@nxp.com; Trahe, Fiona ; ano...@marvell.com; shal...@marvell.com; Zhang, Roy Fan ; Ananyev, Konstantin Subject: Re: [PATCH] [RFC] cryptodev: move AES-GMAC to aead algorithms On 29/07/2020 3:22 PM, Arek Kusztal wrote: > This is proposal to move AES-GMAC algorithm to AEAD set of algorithms. > It is however not 100% conformant GMAC as instead of aad pointer data > to be authenticated is passed normally and aead.data.length field is > used to specify length of data to be authenticated. > Reason behind this move is that GMAC is variant of GCM so it may > simplify implementations that are using these algorithms (mainly IPsec). > AES-GMAC therefore needs to be removed from auth algorithms. > > Signed-off-by: Arek Kusztal > --- .. > I think this makes sense in light of how AES-GMAC support is specified in the IPsec GMAC rfc (https://tools.ietf.org/html/rfc4543) Acked-by: Declan Doherty
[dpdk-dev] [PATCH v2 2/4] test/ring: fix wrong size used in memcmp
When using memcmp function to check data, the third param should be the
size of all elements, rather than the number of the elements.
Fixes: a9fe152363e2 ("test/ring: add custom element size functional tests")
Cc: honnappa.nagaraha...@arm.com
Cc: sta...@dpdk.org
Signed-off-by: Feifei Wang
Reviewed-by: Ruifeng Wang
---
app/test/test_ring.c | 31 +--
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/app/test/test_ring.c b/app/test/test_ring.c
index 0ae97d341..c508a13a9 100644
--- a/app/test/test_ring.c
+++ b/app/test/test_ring.c
@@ -444,7 +444,12 @@ test_ring_burst_bulk_tests1(unsigned int test_idx)
TEST_RING_VERIFY(rte_ring_empty(r));
/* check data */
- TEST_RING_VERIFY(memcmp(src, dst, rsz) == 0);
+ if (esize[i] == -1) {
+ TEST_RING_VERIFY(memcmp(src, dst,
+ rsz * sizeof(void *)) == 0);
+ } else
+ TEST_RING_VERIFY(memcmp(src, dst,
+ rsz * esize[i]) == 0);
}
/* Free memory before test completed */
@@ -538,9 +543,11 @@ test_ring_burst_bulk_tests2(unsigned int test_idx)
cur_dst = test_ring_inc_ptr(cur_dst, esize[i], MAX_BULK);
/* check data */
- if (memcmp(src, dst, cur_dst - dst)) {
- rte_hexdump(stdout, "src", src, cur_src - src);
- rte_hexdump(stdout, "dst", dst, cur_dst - dst);
+ if (memcmp(src, dst, RTE_PTR_DIFF(cur_dst, dst))) {
+ rte_hexdump(stdout, "src", src,
+ RTE_PTR_DIFF(cur_src, src));
+ rte_hexdump(stdout, "dst", dst,
+ RTE_PTR_DIFF(cur_dst, dst));
printf("data after dequeue is not the same\n");
goto fail;
}
@@ -614,9 +621,11 @@ test_ring_burst_bulk_tests3(unsigned int test_idx)
}
/* check data */
- if (memcmp(src, dst, cur_dst - dst)) {
- rte_hexdump(stdout, "src", src, cur_src - src);
- rte_hexdump(stdout, "dst", dst, cur_dst - dst);
+ if (memcmp(src, dst, RTE_PTR_DIFF(cur_dst, dst))) {
+ rte_hexdump(stdout, "src", src,
+ RTE_PTR_DIFF(cur_src, src));
+ rte_hexdump(stdout, "dst", dst,
+ RTE_PTR_DIFF(cur_dst, dst));
printf("data after dequeue is not the same\n");
goto fail;
}
@@ -747,9 +756,11 @@ test_ring_burst_bulk_tests4(unsigned int test_idx)
goto fail;
/* check data */
- if (memcmp(src, dst, cur_dst - dst)) {
- rte_hexdump(stdout, "src", src, cur_src - src);
- rte_hexdump(stdout, "dst", dst, cur_dst - dst);
+ if (memcmp(src, dst, RTE_PTR_DIFF(cur_dst, dst))) {
+ rte_hexdump(stdout, "src", src,
+ RTE_PTR_DIFF(cur_src, src));
+ rte_hexdump(stdout, "dst", dst,
+ RTE_PTR_DIFF(cur_dst, dst));
printf("data after dequeue is not the same\n");
goto fail;
}
--
2.17.1
[dpdk-dev] [PATCH v2 0/4] wrong pointer passed and add check
Fix wrong pointer passed problems when using test_ring_enqueue APIs to enqueue one element into the ring. Furthermore, add check to validate the dequeued objects in test_ring.c when calling test_ring_enqueue APIs. v2: 1. add check to validate the dequeued objects in test_ring.c and fix some bugs of it. (David/Honnappa) 2. remove the patch to change the description for the param of rte_ring_[sp/mp]_enqueue APIs. (David/Konstantin/Honnappa) Feifei Wang (4): test/ring: fix wrong parameter passed to the enqueue APIs test/ring: fix wrong size used in memcmp test/ring: fix the wrong number of enq/deq elements test/ring: add check to validate the dequeued objects app/test/test_ring.c | 180 +++ app/test/test_ring.h | 6 +- 2 files changed, 135 insertions(+), 51 deletions(-) -- 2.17.1
[dpdk-dev] [PATCH v2 1/4] test/ring: fix wrong parameter passed to the enqueue APIs
When enqueue one element to ring in the performance test, a pointer
should be passed to rte_ring_[sp|mp]enqueue APIs, not the pointer
to a table of void *pointers.
Fixes: a9fe152363e2 ("test/ring: add custom element size functional tests")
Cc: honnappa.nagaraha...@arm.com
Cc: sta...@dpdk.org
Signed-off-by: Feifei Wang
Reviewed-by: Ruifeng Wang
Reviewed-by: Honnappa Nagarahalli
---
app/test/test_ring.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/app/test/test_ring.h b/app/test/test_ring.h
index aa6ae67ca..d4b15af7c 100644
--- a/app/test/test_ring.h
+++ b/app/test/test_ring.h
@@ -50,11 +50,11 @@ test_ring_enqueue(struct rte_ring *r, void **obj, int
esize, unsigned int n,
if ((esize) == -1)
switch (api_type) {
case (TEST_RING_THREAD_DEF | TEST_RING_ELEM_SINGLE):
- return rte_ring_enqueue(r, obj);
+ return rte_ring_enqueue(r, *obj);
case (TEST_RING_THREAD_SPSC | TEST_RING_ELEM_SINGLE):
- return rte_ring_sp_enqueue(r, obj);
+ return rte_ring_sp_enqueue(r, *obj);
case (TEST_RING_THREAD_MPMC | TEST_RING_ELEM_SINGLE):
- return rte_ring_mp_enqueue(r, obj);
+ return rte_ring_mp_enqueue(r, *obj);
case (TEST_RING_THREAD_DEF | TEST_RING_ELEM_BULK):
return rte_ring_enqueue_bulk(r, obj, n, NULL);
case (TEST_RING_THREAD_SPSC | TEST_RING_ELEM_BULK):
--
2.17.1
[dpdk-dev] [PATCH v2 3/4] test/ring: fix the wrong number of enq/deq elements
The actual capacity of ring should be the (RING_SIZE - 1), thus only
(RING_SIZE - 1) elements can be enqueued into the ring.
Fixes: a9fe152363e2 ("test/ring: add custom element size functional tests")
Cc: honnappa.nagaraha...@arm.com
Cc: sta...@dpdk.org
Signed-off-by: Feifei Wang
Reviewed-by: Ruifeng Wang
---
app/test/test_ring.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/app/test/test_ring.c b/app/test/test_ring.c
index c508a13a9..51bae0d48 100644
--- a/app/test/test_ring.c
+++ b/app/test/test_ring.c
@@ -822,7 +822,7 @@ test_ring_basic_ex(void)
printf("%u ring entries are now free\n",
rte_ring_free_count(rp));
- for (j = 0; j < RING_SIZE; j++) {
+ for (j = 0; j < RING_SIZE - 1; j++) {
test_ring_enqueue(rp, obj, esize[i], 1,
TEST_RING_THREAD_DEF | TEST_RING_ELEM_SINGLE);
}
@@ -833,7 +833,7 @@ test_ring_basic_ex(void)
goto fail_test;
}
- for (j = 0; j < RING_SIZE; j++) {
+ for (j = 0; j < RING_SIZE - 1; j++) {
test_ring_dequeue(rp, obj, esize[i], 1,
TEST_RING_THREAD_DEF | TEST_RING_ELEM_SINGLE);
}
--
2.17.1
[dpdk-dev] [PATCH v2 4/4] test/ring: add check to validate the dequeued objects
For the single element enqueue and dequeue in test_ring_basic_ex and
test_ring_with_exact_size, add check to validate the dequeued objects.
Signed-off-by: Feifei Wang
Reviewed-by: Ruifeng Wang
Reviewed-by: Honnappa Nagarahalli
---
app/test/test_ring.c | 145 ---
1 file changed, 109 insertions(+), 36 deletions(-)
diff --git a/app/test/test_ring.c b/app/test/test_ring.c
index 51bae0d48..a1ff73a05 100644
--- a/app/test/test_ring.c
+++ b/app/test/test_ring.c
@@ -791,15 +791,9 @@ test_ring_basic_ex(void)
int ret = -1;
unsigned int i, j;
struct rte_ring *rp = NULL;
- void *obj = NULL;
+ void **src = NULL, **cur_src = NULL, **dst = NULL, **cur_dst = NULL;
for (i = 0; i < RTE_DIM(esize); i++) {
- obj = test_ring_calloc(RING_SIZE, esize[i]);
- if (obj == NULL) {
- printf("%s: failed to alloc memory\n", __func__);
- goto fail_test;
- }
-
rp = test_ring_create("test_ring_basic_ex", esize[i], RING_SIZE,
SOCKET_ID_ANY,
RING_F_SP_ENQ | RING_F_SC_DEQ);
@@ -808,6 +802,23 @@ test_ring_basic_ex(void)
goto fail_test;
}
+ /* alloc dummy object pointers */
+ src = test_ring_calloc(RING_SIZE, esize[i]);
+ if (src == NULL) {
+ printf("%s: failed to alloc src memory\n", __func__);
+ goto fail_test;
+ }
+ test_ring_mem_init(src, RING_SIZE, esize[i]);
+ cur_src = src;
+
+ /* alloc some room for copied objects */
+ dst = test_ring_calloc(RING_SIZE, esize[i]);
+ if (dst == NULL) {
+ printf("%s: failed to alloc dst memory\n", __func__);
+ goto fail_test;
+ }
+ cur_dst = dst;
+
if (rte_ring_lookup("test_ring_basic_ex") != rp) {
printf("%s: failed to find ring\n", __func__);
goto fail_test;
@@ -823,8 +834,9 @@ test_ring_basic_ex(void)
rte_ring_free_count(rp));
for (j = 0; j < RING_SIZE - 1; j++) {
- test_ring_enqueue(rp, obj, esize[i], 1,
+ test_ring_enqueue(rp, cur_src, esize[i], 1,
TEST_RING_THREAD_DEF | TEST_RING_ELEM_SINGLE);
+ cur_src = test_ring_inc_ptr(cur_src, esize[i], 1);
}
if (rte_ring_full(rp) != 1) {
@@ -834,8 +846,9 @@ test_ring_basic_ex(void)
}
for (j = 0; j < RING_SIZE - 1; j++) {
- test_ring_dequeue(rp, obj, esize[i], 1,
+ test_ring_dequeue(rp, cur_dst, esize[i], 1,
TEST_RING_THREAD_DEF | TEST_RING_ELEM_SINGLE);
+ cur_dst = test_ring_inc_ptr(cur_dst, esize[i], 1);
}
if (rte_ring_empty(rp) != 1) {
@@ -844,52 +857,88 @@ test_ring_basic_ex(void)
goto fail_test;
}
+ /* check data */
+ if (memcmp(src, dst, RTE_PTR_DIFF(cur_src, src))) {
+ rte_hexdump(stdout, "src", src,
+ RTE_PTR_DIFF(cur_src, src));
+ rte_hexdump(stdout, "dst", dst,
+ RTE_PTR_DIFF(cur_dst, dst));
+ printf("data after dequeue is not the same\n");
+ goto fail_test;
+ }
+
+
/* Following tests use the configured flags to decide
* SP/SC or MP/MC.
*/
+ /* reset dst */
+ if (esize[i] == -1)
+ memset(dst, 0, RING_SIZE * sizeof(void *));
+ else
+ memset(dst, 0, RING_SIZE * esize[i]);
+
+ /* reset cur_src and cur_dst */
+ cur_src = src;
+ cur_dst = dst;
+
/* Covering the ring burst operation */
- ret = test_ring_enqueue(rp, obj, esize[i], 2,
+ ret = test_ring_enqueue(rp, cur_src, esize[i], 2,
TEST_RING_THREAD_DEF | TEST_RING_ELEM_BURST);
if (ret != 2) {
printf("%s: rte_ring_enqueue_burst fails\n", __func__);
goto fail_test;
}
+ cur_src = test_ring_inc_ptr(cur_src, esize[i], 2);
- ret = test_ring_dequeue(rp, obj, esize[i], 2,
+ ret = test_ring_dequeue(rp, cur_dst, esize[i], 2,
TEST_RING_THREAD_DEF | TEST_RING_ELEM_BURST);
if (ret != 2) {
pr
Re: [dpdk-dev] [PATCH] doc: announce changes to ethdev rxconf structure
> -Original Message-
> From: Jerin Jacob
> Sent: Tuesday, August 4, 2020 16:33
> To: Slava Ovsiienko
> Cc: dpdk-dev ; Matan Azrad ;
> Raslan Darawsheh ; Thomas Monjalon
> ; Ferruh Yigit ; Stephen
> Hemminger ; Andrew Rybchenko
> ; Ajit Khaparde
> ; Maxime Coquelin
> ; Olivier Matz ;
> David Marchand
> Subject: Re: [PATCH] doc: announce changes to ethdev rxconf structure
>
> On Mon, Aug 3, 2020 at 6:36 PM Slava Ovsiienko
> wrote:
> >
> > Hi, Jerin,
> >
> > Thanks for the comment, please, see below.
> >
> > > -Original Message-
> > > From: Jerin Jacob
> > > Sent: Monday, August 3, 2020 14:57
> > > To: Slava Ovsiienko
> > > Cc: dpdk-dev ; Matan Azrad ;
> > > Raslan Darawsheh ; Thomas Monjalon
> > > ; Ferruh Yigit ;
> > > Stephen Hemminger ; Andrew
> Rybchenko
> > > ; Ajit Khaparde
> > > ; Maxime Coquelin
> > > ; Olivier Matz
> ;
> > > David Marchand
> > > Subject: Re: [PATCH] doc: announce changes to ethdev rxconf
> > > structure
> > >
> > > On Mon, Aug 3, 2020 at 4:28 PM Viacheslav Ovsiienko
> > > wrote:
> > > >
> > > > The DPDK datapath in the transmit direction is very flexible.
> > > > The applications can build multisegment packets and manages almost
> > > > all data aspects - the memory pools where segments are allocated
> > > > from, the segment lengths, the memory attributes like external,
> registered, etc.
> > > >
> > > > In the receiving direction, the datapath is much less flexible,
> > > > the applications can only specify the memory pool to configure the
> > > > receiving queue and nothing more. In order to extend the receiving
> > > > datapath capabilities it is proposed to add the new fields into
> > > > rte_eth_rxconf structure:
> > > >
> > > > struct rte_eth_rxconf {
> > > > ...
> > > > uint16_t rx_split_num; /* number of segments to split */
> > > > uint16_t *rx_split_len; /* array of segment lengthes */
> > > > struct rte_mempool **mp; /* array of segment memory pools */
> > >
> > > The pool has the packet length it's been configured for.
> > > So I think, rx_split_len can be removed.
> >
> > Yes, it is one of the supposed options - if pointer to array of
> > segment lengths is NULL , the queue_setup() could use the lengths from the
> pool's properties.
> > But we are talking about packet split, in general, it should not
> > depend on pool properties. What if application provides the single
> > pool and just wants to have the tunnel header in the first dedicated mbuf?
> >
> > >
> > > This feature also available in Marvell HW. So it not specific to one
> vendor.
> > > Maybe we could just the use case mention the use case in the
> > > depreciation notice and the tentative change in rte_eth_rxconf and
> > > exact details can be worked out at the time of implementation.
> > >
> > So, if I understand correctly, the struct changes in the commit
> > message should be marked as just possible implementation?
>
> Yes.
>
> We may need to have a detailed discussion on the correct abstraction for
> various HW is available with this feature.
>
> On Marvell HW, We can configure TWO pools for given eth Rx queue.
> One pool can be configured as a small packet pool and other one as large
> packet pool.
> And there is a threshold value to decide the pool between small and large.
> For example:
> - The small pool is configured 2k
> - The large pool is configured with 10k
> - And if the threshold value is configured as 2k.
> Any packet size <=2K will land in small pool and others in a large pool.
> The use case, we are targeting is to save the memory space for jumbo
> frames.
It is a little bit different than split feature, it is about somehow packet
smart sorting.
"Buffer split" is just about more flexible description of rx buffers. Currently
the rx buffers can only be the chain of the buffers of the same size and
allocated from the same memory pool. It is simple and not versatile way,
we could extend this.
Of course, there is no any objection against sharing this split Rx buffer
description
with other features, but, for the example above (2k/10k) it is only the part, it
would require some other parameters (threshold) not used by split. Yes, let's
discuss.
>
> If you can share the MLX HW working model, Then we can find the correct
> abstraction.
From MLNX HW point of view buffer split feature does require nothing special.
The HW rx buffer descriptors support flexible buffer formats, there is
no problem to specify the chain of mbufs with different sizes and dedicated
pointers to receive and split packet into by hardware.
With best regards,
Slava
> >
> > > With the above change:
> > > Acked-by: Jerin Jacob
> > >
> > >
> > > > ...
> > > > };
> > > >
> > > > The non-zero value of rx_split_num field configures the receiving
> > > > queue to split ingress packets into multiple segments to the mbufs
> > > > allocated from various memory pools according to the specified
> > > > lengths. The zero value of rx_split_num field provides the
> > > > backward compati
Re: [dpdk-dev] [RFC] ethdev: add VLAN attributes to ETH item
Thanks, PSB.
> -Original Message-
> From: Stephen Hemminger
> Sent: Tuesday, August 4, 2020 7:22 PM
> To: Dekel Peled
> Cc: ferruh.yi...@intel.com; arybche...@solarflare.com; Ori Kam
> ; Thomas Monjalon ; Asaf
> Penso ; Matan Azrad ; Eli
> Britstein ; dev@dpdk.org
> Subject: Re: [dpdk-dev] [RFC] ethdev: add VLAN attributes to ETH item
>
> On Tue, 4 Aug 2020 18:36:20 +0300
> Dekel Peled wrote:
>
> > In existing code the match on tagged/untagged packets is not explicit.
> > Recent documentation update [1] describes the different patterns and
> > clarifies the intended use of different patterns.
> >
> > This patch proposes an update to ETH item struct, to clearly define
> > the required characteristic of a packet, and enable precise match criteria.
> >
> > [1]
> >
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmails
> > .dpdk.org%2Farchives%2Fdev%2F2020-
> May%2F166257.html&data=02%7C01%7
> >
> Cdekelp%40mellanox.com%7Cc1ca8148f6ad42ad532708d838928c72%7Ca6529
> 71c7d
> >
> 2e4d9ba6a4d149256f461b%7C0%7C0%7C637321549359549952&sdata=W
> kklrEiL
> > KzWsd4UJCt5MKlWw40qIhiVn3vUPEjzE%2BNo%3D&reserved=0
> >
> > Signed-off-by: Dekel Peled
> > ---
> > lib/librte_ethdev/rte_flow.h | 9 +
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/lib/librte_ethdev/rte_flow.h
> > b/lib/librte_ethdev/rte_flow.h index cf0eccb..345feb5 100644
> > --- a/lib/librte_ethdev/rte_flow.h
> > +++ b/lib/librte_ethdev/rte_flow.h
> > @@ -726,11 +726,20 @@ struct rte_flow_item_raw {
> > * If the @p ETH item is the only item in the pattern, and the @p type
> > field
> > * is not specified, then both tagged and untagged packets will match the
> > * pattern.
> > + * The fields @p cvlan_exist and @p svlan_exist can be used to match
> > + specific
> > + * packet types, instead of using the @p type field. This can be used
> > + to match
> > + * on packets that do/don't contain either cvlan, svlan, or both.
> > + * The field @p num_of_vlans can be used to match packets by the
> > + exact number
> > + * of VLANs in header.
> > */
> > struct rte_flow_item_eth {
> > struct rte_ether_addr dst; /**< Destination MAC. */
> > struct rte_ether_addr src; /**< Source MAC. */
> > rte_be16_t type; /**< EtherType or TPID. */
> > + uint32_t cvlan_exist:1; /**< C-tag VLAN exist in header. */
> > + uint32_t svlan_exist:1; /**< S-tag VLAN exist in header. */
> > + uint32_t reserved:14; /**< Reserved, must be zero. */
> > + uint32_t num_of_vlans:16; /**< Number of VLANs in header. */
> > };
> >
> > /** Default mask for RTE_FLOW_ITEM_TYPE_ETH. */
>
> You are making life easy for you but harder for existing users of
> flow_item_eth API.
>
I think new and existing users of this item can benefit from the new fields.
> Why not add new flow_item for vlan and handle multiple levels there.
There is already rte_flow_item_vlan available.
The proposed update is intended to clarify the use of this item.
For example pattern 'eth / ipv4 / end' can be interpreted as no-vlan, or as
any-vlan.
The pattern 'eth / vlan / ipv4 / end' can be interpreted as one-vlan, or
many-vlans.
The proposed update will allow specific match on vlan attributes of packet,
without ambiguity.
Regards,
Dekel
Re: [dpdk-dev] [RFC] ethdev: add VLAN attributes to ETH item
Thanks, PSB.
> -Original Message-
> From: Eli Britstein
> Sent: Tuesday, August 4, 2020 6:47 PM
> To: Dekel Peled ; ferruh.yi...@intel.com;
> arybche...@solarflare.com; Ori Kam ; Thomas
> Monjalon
> Cc: Asaf Penso ; Matan Azrad
> ; dev@dpdk.org
> Subject: Re: [RFC] ethdev: add VLAN attributes to ETH item
>
>
> On 8/4/2020 6:36 PM, Dekel Peled wrote:
> > In existing code the match on tagged/untagged packets is not explicit.
> > Recent documentation update [1] describes the different patterns and
> > clarifies the intended use of different patterns.
> >
> > This patch proposes an update to ETH item struct, to clearly define
> > the required characteristic of a packet, and enable precise match criteria.
> >
> > [1] http://mails.dpdk.org/archives/dev/2020-May/166257.html
> >
> > Signed-off-by: Dekel Peled
> > ---
> > lib/librte_ethdev/rte_flow.h | 9 +
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/lib/librte_ethdev/rte_flow.h
> > b/lib/librte_ethdev/rte_flow.h index cf0eccb..345feb5 100644
> > --- a/lib/librte_ethdev/rte_flow.h
> > +++ b/lib/librte_ethdev/rte_flow.h
> > @@ -726,11 +726,20 @@ struct rte_flow_item_raw {
> >* If the @p ETH item is the only item in the pattern, and the @p type
> > field
> >* is not specified, then both tagged and untagged packets will match the
> >* pattern.
> > + * The fields @p cvlan_exist and @p svlan_exist can be used to match
> > + specific
> > + * packet types, instead of using the @p type field. This can be used
> > + to match
> > + * on packets that do/don't contain either cvlan, svlan, or both.
> > + * The field @p num_of_vlans can be used to match packets by the
> > + exact number
> > + * of VLANs in header.
> >*/
> > struct rte_flow_item_eth {
> > struct rte_ether_addr dst; /**< Destination MAC. */
> > struct rte_ether_addr src; /**< Source MAC. */
> > rte_be16_t type; /**< EtherType or TPID. */
> > + uint32_t cvlan_exist:1; /**< C-tag VLAN exist in header. */
> > + uint32_t svlan_exist:1; /**< S-tag VLAN exist in header. */
> > + uint32_t reserved:14; /**< Reserved, must be zero. */
> > + uint32_t num_of_vlans:16; /**< Number of VLANs in header. */
> We can deduct from num_of_vlans the values of cvlan_exist/svlan_exist, so
> those are redundant fields. Keeping them introduce a conflicting match. For
> example num_of_vlans=0 and cvlan_exist=1.
Such conflict is simple to validate and reject.
Even if num_of_vlans is removed, we can still get conflict svlan_exist=1,
cvlan_exist=0.
The different fields are proposed to allow flexible match on different VLAN
attributes.
Every PMD can choose to support any or none of them.
> > };
> >
> > /** Default mask for RTE_FLOW_ITEM_TYPE_ETH. */
