[dpdk-dev] [PATCH] vdpa/mlx5: add device configuration lock
Under active traffic, qemu switch vq enable state, there will be segment
fault.
The reason is that timer polling thread or channel event thread still
referencing resources that being destroyed or partially initialized.
This patch add per device vq configuration lock and test device ready
flag in event thread to make sure vq being accessed fully initialized.
Redmine: 2239647
Signed-off-by: Xueming Li
---
drivers/vdpa/mlx5/mlx5_vdpa.c | 8 +++-
drivers/vdpa/mlx5/mlx5_vdpa.h | 1 +
drivers/vdpa/mlx5/mlx5_vdpa_event.c | 8
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/vdpa/mlx5/mlx5_vdpa.c b/drivers/vdpa/mlx5/mlx5_vdpa.c
index c0b87bcc01..a8f3e4b1de 100644
--- a/drivers/vdpa/mlx5/mlx5_vdpa.c
+++ b/drivers/vdpa/mlx5/mlx5_vdpa.c
@@ -133,6 +133,7 @@ mlx5_vdpa_set_vring_state(int vid, int vring, int state)
struct rte_vdpa_device *vdev = rte_vhost_get_vdpa_device(vid);
struct mlx5_vdpa_priv *priv =
mlx5_vdpa_find_priv_resource_by_vdev(vdev);
+ int ret;
if (priv == NULL) {
DRV_LOG(ERR, "Invalid vDPA device: %s.", vdev->device->name);
@@ -142,7 +143,10 @@ mlx5_vdpa_set_vring_state(int vid, int vring, int state)
DRV_LOG(ERR, "Too big vring id: %d.", vring);
return -E2BIG;
}
- return mlx5_vdpa_virtq_enable(priv, vring, state);
+ pthread_mutex_lock(&priv->vq_config_lock);
+ ret = mlx5_vdpa_virtq_enable(priv, vring, state);
+ pthread_mutex_unlock(&priv->vq_config_lock);
+ return ret;
}
static int
@@ -742,6 +746,7 @@ mlx5_vdpa_pci_probe(struct rte_pci_driver *pci_drv
__rte_unused,
}
mlx5_vdpa_config_get(pci_dev->device.devargs, priv);
SLIST_INIT(&priv->mr_list);
+ pthread_mutex_init(&priv->vq_config_lock, NULL);
pthread_mutex_lock(&priv_list_lock);
TAILQ_INSERT_TAIL(&priv_list, priv, next);
pthread_mutex_unlock(&priv_list_lock);
@@ -793,6 +798,7 @@ mlx5_vdpa_pci_remove(struct rte_pci_device *pci_dev)
priv->var = NULL;
}
mlx5_glue->close_device(priv->ctx);
+ pthread_mutex_destroy(&priv->vq_config_lock);
rte_free(priv);
}
return 0;
diff --git a/drivers/vdpa/mlx5/mlx5_vdpa.h b/drivers/vdpa/mlx5/mlx5_vdpa.h
index 57044d9d33..462805a352 100644
--- a/drivers/vdpa/mlx5/mlx5_vdpa.h
+++ b/drivers/vdpa/mlx5/mlx5_vdpa.h
@@ -120,6 +120,7 @@ enum {
struct mlx5_vdpa_priv {
TAILQ_ENTRY(mlx5_vdpa_priv) next;
uint8_t configured;
+ pthread_mutex_t vq_config_lock;
uint64_t last_traffic_tic;
pthread_t timer_tid;
pthread_mutex_t timer_lock;
diff --git a/drivers/vdpa/mlx5/mlx5_vdpa_event.c
b/drivers/vdpa/mlx5/mlx5_vdpa_event.c
index 7dc1ac0fa9..4a8b7b0bd9 100644
--- a/drivers/vdpa/mlx5/mlx5_vdpa_event.c
+++ b/drivers/vdpa/mlx5/mlx5_vdpa_event.c
@@ -274,6 +274,7 @@ mlx5_vdpa_poll_handle(void *arg)
priv->event_us;
while (1) {
max = 0;
+ pthread_mutex_lock(&priv->vq_config_lock);
for (i = 0; i < priv->nr_virtqs; i++) {
cq = &priv->virtqs[i].eqp.cq;
if (cq->cq && !cq->armed) {
@@ -298,6 +299,7 @@ mlx5_vdpa_poll_handle(void *arg)
priv->vdev->device->name);
mlx5_vdpa_arm_all_cqs(priv);
pthread_mutex_lock(&priv->timer_lock);
+ pthread_mutex_unlock(&priv->vq_config_lock);
priv->timer_on = 0;
while (!priv->timer_on)
pthread_cond_wait(&priv->timer_cond,
@@ -312,6 +314,7 @@ mlx5_vdpa_poll_handle(void *arg)
} else {
priv->last_traffic_tic = current_tic;
}
+ pthread_mutex_unlock(&priv->vq_config_lock);
mlx5_vdpa_timer_sleep(priv, max);
}
return NULL;
@@ -327,6 +330,7 @@ mlx5_vdpa_interrupt_handler(void *cb_arg)
uint8_t buf[sizeof(struct mlx5dv_devx_async_event_hdr) + 128];
} out;
+ pthread_mutex_lock(&priv->vq_config_lock);
while (mlx5_glue->devx_get_event(priv->eventc, &out.event_resp,
sizeof(out.buf)) >=
(ssize_t)sizeof(out.event_resp.cookie)) {
@@ -337,12 +341,15 @@ mlx5_vdpa_interrupt_handler(void *cb_arg)
struct mlx5_vdpa_virtq *virtq = container_of(eqp,
struct mlx5_vdpa_virtq, eqp);
+ if (!virtq->enable)
+ continue;
mlx5_vdpa_cq_poll(cq);
/* Notify guest for descs consuming. */
if (cq->callfd !
[dpdk-dev] [v2] vdpa/mlx5: fix queue update synchronization
The driver CQ event management is done by non vhost library thread,
either the dpdk host thread or the internal vDPA driver thread.
When a queue is updated the CQ may be destroyed and created by the vhost
library thread via the queue state operation.
When the queue update feature was added, it didn't synchronize the CQ
management to the queue update what may cause invalid memory access.
Add the aforementioned synchronization by a new per device configuration
mutex.
Fixes: c47d6e83334e ("vdpa/mlx5: support queue update")
Signed-off-by: Xueming Li
Acked-by: Matan Azrad
---
drivers/vdpa/mlx5/mlx5_vdpa.c | 8 +++-
drivers/vdpa/mlx5/mlx5_vdpa.h | 1 +
drivers/vdpa/mlx5/mlx5_vdpa_event.c | 8
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/vdpa/mlx5/mlx5_vdpa.c b/drivers/vdpa/mlx5/mlx5_vdpa.c
index c0b87bcc01..a8f3e4b1de 100644
--- a/drivers/vdpa/mlx5/mlx5_vdpa.c
+++ b/drivers/vdpa/mlx5/mlx5_vdpa.c
@@ -133,6 +133,7 @@ mlx5_vdpa_set_vring_state(int vid, int vring, int state)
struct rte_vdpa_device *vdev = rte_vhost_get_vdpa_device(vid);
struct mlx5_vdpa_priv *priv =
mlx5_vdpa_find_priv_resource_by_vdev(vdev);
+ int ret;
if (priv == NULL) {
DRV_LOG(ERR, "Invalid vDPA device: %s.", vdev->device->name);
@@ -142,7 +143,10 @@ mlx5_vdpa_set_vring_state(int vid, int vring, int state)
DRV_LOG(ERR, "Too big vring id: %d.", vring);
return -E2BIG;
}
- return mlx5_vdpa_virtq_enable(priv, vring, state);
+ pthread_mutex_lock(&priv->vq_config_lock);
+ ret = mlx5_vdpa_virtq_enable(priv, vring, state);
+ pthread_mutex_unlock(&priv->vq_config_lock);
+ return ret;
}
static int
@@ -742,6 +746,7 @@ mlx5_vdpa_pci_probe(struct rte_pci_driver *pci_drv
__rte_unused,
}
mlx5_vdpa_config_get(pci_dev->device.devargs, priv);
SLIST_INIT(&priv->mr_list);
+ pthread_mutex_init(&priv->vq_config_lock, NULL);
pthread_mutex_lock(&priv_list_lock);
TAILQ_INSERT_TAIL(&priv_list, priv, next);
pthread_mutex_unlock(&priv_list_lock);
@@ -793,6 +798,7 @@ mlx5_vdpa_pci_remove(struct rte_pci_device *pci_dev)
priv->var = NULL;
}
mlx5_glue->close_device(priv->ctx);
+ pthread_mutex_destroy(&priv->vq_config_lock);
rte_free(priv);
}
return 0;
diff --git a/drivers/vdpa/mlx5/mlx5_vdpa.h b/drivers/vdpa/mlx5/mlx5_vdpa.h
index 57044d9d33..462805a352 100644
--- a/drivers/vdpa/mlx5/mlx5_vdpa.h
+++ b/drivers/vdpa/mlx5/mlx5_vdpa.h
@@ -120,6 +120,7 @@ enum {
struct mlx5_vdpa_priv {
TAILQ_ENTRY(mlx5_vdpa_priv) next;
uint8_t configured;
+ pthread_mutex_t vq_config_lock;
uint64_t last_traffic_tic;
pthread_t timer_tid;
pthread_mutex_t timer_lock;
diff --git a/drivers/vdpa/mlx5/mlx5_vdpa_event.c
b/drivers/vdpa/mlx5/mlx5_vdpa_event.c
index 7dc1ac0fa9..4a8b7b0bd9 100644
--- a/drivers/vdpa/mlx5/mlx5_vdpa_event.c
+++ b/drivers/vdpa/mlx5/mlx5_vdpa_event.c
@@ -274,6 +274,7 @@ mlx5_vdpa_poll_handle(void *arg)
priv->event_us;
while (1) {
max = 0;
+ pthread_mutex_lock(&priv->vq_config_lock);
for (i = 0; i < priv->nr_virtqs; i++) {
cq = &priv->virtqs[i].eqp.cq;
if (cq->cq && !cq->armed) {
@@ -298,6 +299,7 @@ mlx5_vdpa_poll_handle(void *arg)
priv->vdev->device->name);
mlx5_vdpa_arm_all_cqs(priv);
pthread_mutex_lock(&priv->timer_lock);
+ pthread_mutex_unlock(&priv->vq_config_lock);
priv->timer_on = 0;
while (!priv->timer_on)
pthread_cond_wait(&priv->timer_cond,
@@ -312,6 +314,7 @@ mlx5_vdpa_poll_handle(void *arg)
} else {
priv->last_traffic_tic = current_tic;
}
+ pthread_mutex_unlock(&priv->vq_config_lock);
mlx5_vdpa_timer_sleep(priv, max);
}
return NULL;
@@ -327,6 +330,7 @@ mlx5_vdpa_interrupt_handler(void *cb_arg)
uint8_t buf[sizeof(struct mlx5dv_devx_async_event_hdr) + 128];
} out;
+ pthread_mutex_lock(&priv->vq_config_lock);
while (mlx5_glue->devx_get_event(priv->eventc, &out.event_resp,
sizeof(out.buf)) >=
(ssize_t)sizeof(out.event_resp.cookie)) {
@@ -337,12 +341,15 @@ mlx5_vdpa_interrupt_handler(void *cb_arg)
struct mlx5_vdpa_virtq *virtq = container_of(eqp,
struct mlx5_vdpa_virtq, eqp);
+ if (!vir
Re: [dpdk-dev] Queue Management Support in DPDK
Hi Stephen, Thanks for the reply. On Thu, Jul 30, 2020 at 12:37 AM Stephen Hemminger wrote: > > rte_sched is not a generic AQM mechanism. You will have to write a new > replacement for rte_sched if you want something else. Yes, we did realize that rte_sched is not suitable for AQM algorithms. We have implemented a bare-bones AQM mechanism that is independent of rte_sched. Using this implementation we have successfully added and tested PIE and CoDel. > I would recommend starting with Cake. It is latest and most complete > and the developers are active and friendly. CAKE can be added using what we have built, but before we do that we wanted to know if such a feature would be welcomed by the community. Subsequently, we will submit an RFC patch series to the dev mailing list. Thanks, Archit Pandey. On Thu, Jul 30, 2020 at 12:37 AM Stephen Hemminger wrote: > > On Thu, 30 Jul 2020 00:07:29 +0530 > Archit Pandey wrote: > > > Hello everyone, > > > > We have been using DPDK's QoS framework over the last year and found > > that rte_sched and the provided qos_sched app work great for QoS. > > > > However, when we ventured into trying to add CoDel (to replace RED) as > > a dropper to the framework, we faced several challenges due to how > > tightly rte_sched and rte_red were coupled together. As we had no > > success with rte_sched, we would like to propose a new framework for > > queue management in DPDK. > > > > Goals we have in mind for the framework: > > - Act as an abstraction for queue management algorithms (AQMs) such as > > CoDel, PiE and RED. > > - Make it easy for new algorithms to be added. > > > > We’d appreciate feedback on whether such a framework would be welcomed > > in the community, or what else could be done for adding queue > > management support. > > > > Sincerely, > > Archit Pandey. > > rte_sched is not a generic AQM mechanism. You will have to write a new > replacement for rte_sched if you want something else. > > I would recommend starting with Cake. It is latest and most complete > and the developers are active and friendly. -- Archit Pandey Senior Year B.Tech. Department of Computer Science and Engineering National Institute of Technology Karnataka Surathkal, India On Thu, Jul 30, 2020 at 12:37 AM Stephen Hemminger wrote: > > On Thu, 30 Jul 2020 00:07:29 +0530 > Archit Pandey wrote: > > > Hello everyone, > > > > We have been using DPDK's QoS framework over the last year and found > > that rte_sched and the provided qos_sched app work great for QoS. > > > > However, when we ventured into trying to add CoDel (to replace RED) as > > a dropper to the framework, we faced several challenges due to how > > tightly rte_sched and rte_red were coupled together. As we had no > > success with rte_sched, we would like to propose a new framework for > > queue management in DPDK. > > > > Goals we have in mind for the framework: > > - Act as an abstraction for queue management algorithms (AQMs) such as > > CoDel, PiE and RED. > > - Make it easy for new algorithms to be added. > > > > We’d appreciate feedback on whether such a framework would be welcomed > > in the community, or what else could be done for adding queue > > management support. > > > > Sincerely, > > Archit Pandey. > > rte_sched is not a generic AQM mechanism. You will have to write a new > replacement for rte_sched if you want something else. > > I would recommend starting with Cake. It is latest and most complete > and the developers are active and friendly. -- Archit Pandey Senior Year B.Tech. Department of Computer Science and Engineering National Institute of Technology Karnataka Surathkal, India
[dpdk-dev] [PATCH] doc: announce changes to eventdev public structures
From: Pavan Nikhilesh Add 64 byte padding at the end of event device public structure to allow future extensions. Signed-off-by: Pavan Nikhilesh --- http://patches.dpdk.org/project/dpdk/list/?series=10728&state=* doc/guides/rel_notes/deprecation.rst | 9 + 1 file changed, 9 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index ea4cfa7a4..37c7c9029 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -151,3 +151,12 @@ 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``. -- 2.17.1
[dpdk-dev] [PATCH] net/bonding: fix deadloop when update RSS RETA
From: Zhiguang He <191390...@qq.com>
when parament reta_size < RTE_RETA_GROUP_SIZE,
reta_count will be 0. Then this function will
be deadloop
Fixes: 734ce47f71e0 ("bonding: support RSS dynamic configuration")
Cc: sta...@dpdk.org
Signed-off-by: Zhiguang He <1913909...@qq.com>
---
drivers/net/bonding/rte_eth_bond_pmd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c
b/drivers/net/bonding/rte_eth_bond_pmd.c
index 116e2f2..cdbd815 100644
--- a/drivers/net/bonding/rte_eth_bond_pmd.c
+++ b/drivers/net/bonding/rte_eth_bond_pmd.c
@@ -2935,7 +2935,8 @@ struct bwg_slave {
return -EINVAL;
/* Copy RETA table */
- reta_count = reta_size / RTE_RETA_GROUP_SIZE;
+ reta_count = (reta_size + RTE_RETA_GROUP_SIZE - 1) /
+ RTE_RETA_GROUP_SIZE;
for (i = 0; i < reta_count; i++) {
internals->reta_conf[i].mask = reta_conf[i].mask;
--
1.8.3.1
Re: [dpdk-dev] [Bug 519] DPDK 20.08-rc3 meson build fails with MLNX_OFED_LINUX-5.1-0.6.6.0
The compilation fault did not reproduce on my setup: $ cat /etc/redhat-release Red Hat Enterprise Linux release 8.2 (Ootpa) $ meson --version 0.49.2 $ ninja --version 1.8.2 ofed_info -s MLNX_OFED_LINUX-5.1-0.6.6.0 $ git show HEAD commit 6636b04b82897816e0e05134f55a578cb7e124bc (tag: v20.08-rc3) $ meson -Dexamples=all build $ ninja -C build According to the log, compiler failed to locate symbols defined in libibverbs include directory. Please verify openibd service was running during compilation. Regards, Gregory > -Original Message- > From: dev On Behalf Of bugzi...@dpdk.org > Sent: Friday, July 31, 2020 07:03 > To: dev@dpdk.org > Subject: [dpdk-dev] [Bug 519] DPDK 20.08-rc3 meson build fails with > MLNX_OFED_LINUX-5.1-0.6.6.0 > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs. > dpdk.org%2Fshow_bug.cgi%3Fid%3D519&data=02%7C01%7Cgetelson% > 40mellanox.com%7C989a13808b2a402eb9bd08d835069c26%7Ca652971c7d2 > e4d9ba6a4d149256f461b%7C0%7C0%7C637317649796122841&sdata=9 > lB8qWK1KjBitjt3%2BFswpSPu%2F3UbkHEEOruL%2B%2BgqgFk%3D&rese > rved=0 > > Bug ID: 519 >Summary: DPDK 20.08-rc3 meson build fails with > MLNX_OFED_LINUX-5.1-0.6.6.0 >Product: DPDK >Version: 20.08 > Hardware: x86 > OS: Linux > Status: UNCONFIRMED > Severity: normal > Priority: Normal > Component: meson > Assignee: dev@dpdk.org > Reporter: lee.robe...@hpe.com > Target Milestone: --- > > Created attachment 114 > --> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs. > dpdk.org%2Fattachment.cgi%3Fid%3D114%26action%3Dedit&data=02% > 7C01%7Cgetelson%40mellanox.com%7C989a13808b2a402eb9bd08d835069c > 26%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C63731764979612 > 2841&sdata=fYyBoMnz9xsmwr7IMmXpb%2FRMjLNVir6PesYIpSztxvc%3 > D&reserved=0 > console output from failed build > > DPDK 20.08-rc3 fails to build on RHEL 8.2 with MLNX_OFED_LINUX-5.1- > 0.6.6.0. > MLNX_OFED_LINUX was installed with "./mlnxofedinstall --upstream-libs -- > dpdk". > > [root@vp10p1 dpdk-20.08-rc3]# ninja -C build > ninja: Entering directory `build' > [1053/2565]GLinkingitarget_drivers/librte_common_mlx5.so.20.0.3.Kstom/c > ommand.Khns3_fdir.c.o'.Ktor.c.o'.KKs'.K3.symbols'.K'.Ko'.K > FAILED: drivers/librte_common_mlx5.so.20.0.3 > cc -o drivers/librte_common_mlx5.so.20.0.3 > 'drivers/a715181@@rte_common_mlx5@sha/meson- > generated_.._rte_common_mlx5.pmd.c.o' > 'drivers/a7 > 15181@@tmp_rte_common_mlx5@sta/common_mlx5_mlx5_devx_cmds.c. > o' > 'drivers/a715181@@tmp_rte_common_mlx5@sta/common_mlx5_mlx5_co > mmon.c.o' 'dr > ivers/a715181@@tmp_rte_common_mlx5@sta/common_mlx5_mlx5_comm > on_mp.c.o' > 'drivers/a715181@@tmp_rte_common_mlx5@sta/common_mlx5_mlx5_co > mmon_ > mr.c.o' > 'drivers/a715181@@tmp_rte_common_mlx5@sta/common_mlx5_mlx5_ma > lloc.c.o' > 'drivers/a715181@@tmp_rte_common_mlx5@sta/common_mlx5_mlx5 > _common_pci.c.o' > 'drivers/a715181@@tmp_rte_common_mlx5@sta/common_mlx5_linux_ml > x5_nl.c.o' > 'drivers/a715181@@tmp_rte_common_mlx5@sta/commo > n_mlx5_linux_mlx5_common_os.c.o' > 'drivers/a715181@@tmp_rte_common_mlx5@sta/common_mlx5_linux_ml > x5_common_verbs.c.o' > 'drivers/a715181@@tmp > _rte_common_mlx5@sta/common_mlx5_linux_mlx5_glue.c.o' -Wl,--no- > undefined -Wl,--as-needed -Wl,-O1 -shared -fPIC -Wl,--start-group -Wl,-son > ame,librte_common_mlx5.so.20.0 -Wl,--no-as-needed -pthread -lm -ldl - > lnuma > lib/librte_hash.so.20.0.3 lib/librte_eal.so.20.0.3 lib/librte_kvargs.so.20.0.3 > lib/librte_telemetry.so.20.0.3 lib/librte_ring.so.20.0.3 > lib/librte_pci.so.20.0.3 drivers/librte_bus_pci.so.20.0.3 > lib/librte_net.so.20.0.3 lib/librte_mbuf.so.20.0.3 > lib/librte_mempool.so.20.0.3 -Wl,--end-group -Wl,--version- > script=/home/lroberts/dpdk-20.08- > rc3/drivers/common/mlx5/rte_common_mlx5_version.map > '-Wl,-rpath,$ORIGIN/../lib:$ORIGIN/' > -Wl,-rpath-link,/home/lroberts/dpdk-20.08- > rc3/build/lib:/home/lroberts/dpdk-20.08-rc3/build/drivers > drivers/a715181@@tmp_rte_common_mlx5@sta/common_mlx5_linux_mlx > 5_glue.c.o: In function `mlx5_glue_dv_open_device': > mlx5_glue.c:(.text+0x3e0): undefined reference to `mlx5dv_open_device' > drivers/a715181@@tmp_rte_common_mlx5@sta/common_mlx5_linux_mlx > 5_glue.c.o: In function `mlx5_glue_dv_free_pp': > mlx5_glue.c:(.text+0x211): undefined reference to `mlx5dv_pp_free' > drivers/a715181@@tmp_rte_common_mlx5@sta/common_mlx5_linux_mlx > 5_glue.c.o: In function `mlx5_glue_dv_alloc_pp': > mlx5_glue.c:(.text+0x221): undefined reference to `mlx5dv_pp_alloc' > drivers/a715181@@tmp_rte_common_mlx5@sta/common_mlx5_linux_mlx > 5_glue.c.o: In function `mlx5_glue_dr_reclaim_domain_memory': > mlx5_glue.c:(.text+0x23b): undefined reference to > `mlx5dv_dr_domain_set_reclaim_device_memory' > drivers/a715181@@tmp_rte_common_mlx5@sta/common_mlx5_linux_mlx > 5_glue.c.o: In function `mlx5_glue_devx_get_event': > mlx5_glue.c:(.text+0x2
Re: [dpdk-dev] [PATCH] net/netvsc: return the correct chimney index
On Sat, 1 Aug 2020 23:04:28 -0700
lon...@linuxonhyperv.com wrote:
> From: Long Li
>
> The code should look into "slab" to figure out the index returned from
> rte_bitmap_scan().
>
> Fixes: cc02518132 ("net/netvsc: split send buffers from Tx descriptors")
> Cc: sta...@dpdk.org
> Signed-off-by: Long Li
Acked-by: Stephen Hemminger
[dpdk-dev] [PATCH v2 2/3] examples/l3fwd: use IP reserved addresses for EM mode
From: Pavan Nikhilesh
The l3fwd example should use the reserved IPv4/v6 reserved address
ranges defined in RFC5735 and RFC5180 and RFC863 discard protocol for
the port number in the exact match mode of L3 forwarding.
Signed-off-by: Pavan Nikhilesh
---
examples/l3fwd/l3fwd_em.c | 87 ++-
1 file changed, 59 insertions(+), 28 deletions(-)
diff --git a/examples/l3fwd/l3fwd_em.c b/examples/l3fwd/l3fwd_em.c
index fdbee70b4..481b6dcce 100644
--- a/examples/l3fwd/l3fwd_em.c
+++ b/examples/l3fwd/l3fwd_em.c
@@ -99,33 +99,64 @@ struct ipv6_l3fwd_em_route {
uint8_t if_out;
};
-static struct ipv4_l3fwd_em_route ipv4_l3fwd_em_route_array[] = {
- {{RTE_IPV4(101, 0, 0, 0), RTE_IPV4(100, 10, 0, 1), 101, 11,
IPPROTO_TCP}, 0},
- {{RTE_IPV4(201, 0, 0, 0), RTE_IPV4(200, 20, 0, 1), 102, 12,
IPPROTO_TCP}, 1},
- {{RTE_IPV4(111, 0, 0, 0), RTE_IPV4(100, 30, 0, 1), 101, 11,
IPPROTO_TCP}, 2},
- {{RTE_IPV4(211, 0, 0, 0), RTE_IPV4(200, 40, 0, 1), 102, 12,
IPPROTO_TCP}, 3},
+/* 198.18.0.0/16 are set aside for RFC2544 benchmarking (RFC5735).
+ * Use RFC863 Discard Protocol.
+ */
+static const struct ipv4_l3fwd_em_route ipv4_l3fwd_em_route_array[] = {
+ {{RTE_IPV4(198, 18, 0, 0), RTE_IPV4(198, 18, 0, 1), 9, 9,
IPPROTO_TCP}, 0},
+ {{RTE_IPV4(198, 18, 1, 0), RTE_IPV4(198, 18, 1, 1), 9, 9,
IPPROTO_TCP}, 1},
+ {{RTE_IPV4(198, 18, 2, 0), RTE_IPV4(198, 18, 2, 1), 9, 9,
IPPROTO_TCP}, 2},
+ {{RTE_IPV4(198, 18, 3, 0), RTE_IPV4(198, 18, 3, 1), 9, 9,
IPPROTO_TCP}, 3},
+ {{RTE_IPV4(198, 18, 4, 0), RTE_IPV4(198, 18, 4, 1), 9, 9,
IPPROTO_TCP}, 4},
+ {{RTE_IPV4(198, 18, 5, 0), RTE_IPV4(198, 18, 5, 1), 9, 9,
IPPROTO_TCP}, 5},
+ {{RTE_IPV4(198, 18, 6, 0), RTE_IPV4(198, 18, 6, 1), 9, 9,
IPPROTO_TCP}, 6},
+ {{RTE_IPV4(198, 18, 7, 0), RTE_IPV4(198, 18, 7, 1), 9, 9,
IPPROTO_TCP}, 7},
+ {{RTE_IPV4(198, 18, 8, 0), RTE_IPV4(198, 18, 8, 1), 9, 9,
IPPROTO_TCP}, 8},
+ {{RTE_IPV4(198, 18, 9, 0), RTE_IPV4(198, 18, 9, 1), 9, 9,
IPPROTO_TCP}, 9},
+ {{RTE_IPV4(198, 18, 10, 0), RTE_IPV4(198, 18, 10, 1), 9, 9,
IPPROTO_TCP}, 10},
+ {{RTE_IPV4(198, 18, 11, 0), RTE_IPV4(198, 18, 11, 1), 9, 9,
IPPROTO_TCP}, 11},
+ {{RTE_IPV4(198, 18, 12, 0), RTE_IPV4(198, 18, 12, 1), 9, 9,
IPPROTO_TCP}, 12},
+ {{RTE_IPV4(198, 18, 13, 0), RTE_IPV4(198, 18, 13, 1), 9, 9,
IPPROTO_TCP}, 13},
+ {{RTE_IPV4(198, 18, 14, 0), RTE_IPV4(198, 18, 14, 1), 9, 9,
IPPROTO_TCP}, 14},
+ {{RTE_IPV4(198, 18, 15, 0), RTE_IPV4(198, 18, 15, 1), 9, 9,
IPPROTO_TCP}, 15},
};
-static struct ipv6_l3fwd_em_route ipv6_l3fwd_em_route_array[] = {
- {{
- {0xfe, 0x80, 0, 0, 0, 0, 0, 0, 0x02, 0x1e, 0x67, 0xff, 0xfe, 0, 0, 0},
- {0xfe, 0x80, 0, 0, 0, 0, 0, 0, 0x02, 0x1b, 0x21, 0xff, 0xfe, 0x91,
0x38, 0x05},
- 101, 11, IPPROTO_TCP}, 0},
-
- {{
- {0xfe, 0x90, 0, 0, 0, 0, 0, 0, 0x02, 0x1e, 0x67, 0xff, 0xfe, 0, 0, 0},
- {0xfe, 0x90, 0, 0, 0, 0, 0, 0, 0x02, 0x1b, 0x21, 0xff, 0xfe, 0x91,
0x38, 0x05},
- 102, 12, IPPROTO_TCP}, 1},
-
- {{
- {0xfe, 0xa0, 0, 0, 0, 0, 0, 0, 0x02, 0x1e, 0x67, 0xff, 0xfe, 0, 0, 0},
- {0xfe, 0xa0, 0, 0, 0, 0, 0, 0, 0x02, 0x1b, 0x21, 0xff, 0xfe, 0x91,
0x38, 0x05},
- 101, 11, IPPROTO_TCP}, 2},
-
- {{
- {0xfe, 0xb0, 0, 0, 0, 0, 0, 0, 0x02, 0x1e, 0x67, 0xff, 0xfe, 0, 0, 0},
- {0xfe, 0xb0, 0, 0, 0, 0, 0, 0, 0x02, 0x1b, 0x21, 0xff, 0xfe, 0x91,
0x38, 0x05},
- 102, 12, IPPROTO_TCP}, 3},
+/* 2001:0200::/48 is IANA reserved range for IPv6 benchmarking (RFC5180).
+ * Use RFC863 Discard Protocol.
+ */
+static const struct ipv6_l3fwd_em_route ipv6_l3fwd_em_route_array[] = {
+ {{{32, 1, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
+ {32, 1, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1}, 9, 9,
IPPROTO_TCP}, 0},
+ {{{32, 1, 2, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0},
+ {32, 1, 2, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 1}, 9, 9,
IPPROTO_TCP}, 1},
+ {{{32, 1, 2, 0, 0, 0, 0, 0, 0, 2, 0, 0, 0, 0, 0, 0},
+ {32, 1, 2, 0, 0, 0, 0, 0, 0, 2, 0, 0, 0, 0, 0, 1}, 9, 9,
IPPROTO_TCP}, 2},
+ {{{32, 1, 2, 0, 0, 0, 0, 0, 0, 3, 0, 0, 0, 0, 0, 0},
+ {32, 1, 2, 0, 0, 0, 0, 0, 0, 3, 0, 0, 0, 0, 0, 1}, 9, 9,
IPPROTO_TCP}, 3},
+ {{{32, 1, 2, 0, 0, 0, 0, 0, 0, 4, 0, 0, 0, 0, 0, 0},
+ {32, 1, 2, 0, 0, 0, 0, 0, 0, 4, 0, 0, 0, 0, 0, 1}, 9, 9,
IPPROTO_TCP}, 4},
+ {{{32, 1, 2, 0, 0, 0, 0, 0, 0, 5, 0, 0, 0, 0, 0, 0},
+ {32, 1, 2, 0, 0, 0, 0, 0, 0, 5, 0, 0, 0, 0, 0, 1}, 9, 9,
IPPROTO_TCP}, 5},
+ {{{32, 1, 2, 0, 0, 0, 0, 0, 0, 6, 0, 0, 0, 0, 0, 0},
+ {32, 1, 2, 0, 0, 0, 0, 0, 0, 6, 0, 0, 0, 0, 0, 1}, 9, 9,
IPPROTO_TCP}, 6},
+ {{{32, 1, 2, 0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0},
+ {32, 1, 2, 0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 1}, 9, 9,
IPPROTO_TCP}, 7},
+ {{{32, 1, 2, 0, 0, 0, 0, 0, 0, 8, 0, 0, 0, 0, 0, 0},
+ {32, 1, 2, 0, 0
[dpdk-dev] [PATCH v2 3/3] examples/l3fwd: print port bdf when initializing routes
From: Pavan Nikhilesh
Since the number of Ethernet ports have gone up, print the pci bdf along
with the routes.
This is also helpful for cases where whitelisting order is honored.
Signed-off-by: Pavan Nikhilesh
---
examples/l3fwd/l3fwd_lpm.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/examples/l3fwd/l3fwd_lpm.c b/examples/l3fwd/l3fwd_lpm.c
index 00047c706..65639d65a 100644
--- a/examples/l3fwd/l3fwd_lpm.c
+++ b/examples/l3fwd/l3fwd_lpm.c
@@ -496,6 +496,7 @@ setup_lpm(const int socketid)
/* populate the LPM table */
for (i = 0; i < RTE_DIM(ipv4_l3fwd_lpm_route_array); i++) {
+ struct rte_eth_dev_info dev_info;
struct in_addr in;
/* skip unused ports */
@@ -503,6 +504,8 @@ setup_lpm(const int socketid)
enabled_port_mask) == 0)
continue;
+ rte_eth_dev_info_get(ipv4_l3fwd_lpm_route_array[i].if_out,
+&dev_info);
ret = rte_lpm_add(ipv4_l3fwd_lpm_lookup_struct[socketid],
ipv4_l3fwd_lpm_route_array[i].ip,
ipv4_l3fwd_lpm_route_array[i].depth,
@@ -515,10 +518,11 @@ setup_lpm(const int socketid)
}
in.s_addr = htonl(ipv4_l3fwd_lpm_route_array[i].ip);
- printf("LPM: Adding route %s / %d (%d)\n",
+ printf("LPM: Adding route %s / %d (%d) [%s]\n",
inet_ntop(AF_INET, &in, abuf, sizeof(abuf)),
ipv4_l3fwd_lpm_route_array[i].depth,
- ipv4_l3fwd_lpm_route_array[i].if_out);
+ ipv4_l3fwd_lpm_route_array[i].if_out,
+ dev_info.device->name);
}
/* create the LPM6 table */
@@ -536,12 +540,15 @@ setup_lpm(const int socketid)
/* populate the LPM table */
for (i = 0; i < RTE_DIM(ipv6_l3fwd_lpm_route_array); i++) {
+ struct rte_eth_dev_info dev_info;
/* skip unused ports */
if ((1 << ipv6_l3fwd_lpm_route_array[i].if_out &
enabled_port_mask) == 0)
continue;
+ rte_eth_dev_info_get(ipv4_l3fwd_lpm_route_array[i].if_out,
+&dev_info);
ret = rte_lpm6_add(ipv6_l3fwd_lpm_lookup_struct[socketid],
ipv6_l3fwd_lpm_route_array[i].ip,
ipv6_l3fwd_lpm_route_array[i].depth,
@@ -553,11 +560,12 @@ setup_lpm(const int socketid)
i, socketid);
}
- printf("LPM: Adding route %s / %d (%d)\n",
+ printf("LPM: Adding route %s / %d (%d) [%s]\n",
inet_ntop(AF_INET6, ipv6_l3fwd_lpm_route_array[i].ip,
abuf, sizeof(abuf)),
ipv6_l3fwd_lpm_route_array[i].depth,
- ipv6_l3fwd_lpm_route_array[i].if_out);
+ ipv6_l3fwd_lpm_route_array[i].if_out,
+ dev_info.device->name);
}
}
--
2.17.1
[dpdk-dev] [PATCH v2 1/3] examples/l3fwd: increase number of routes
From: Pavan Nikhilesh
Increase the number of routes from 8 to 16 that are statically added for
lpm and em mode as most of the SoCs support more than 8 interfaces.
Signed-off-by: Pavan Nikhilesh
---
v2 Changes:
- Fixup for EM mode.
examples/l3fwd/l3fwd_lpm.c | 16
1 file changed, 16 insertions(+)
diff --git a/examples/l3fwd/l3fwd_lpm.c b/examples/l3fwd/l3fwd_lpm.c
index 91eb74272..00047c706 100644
--- a/examples/l3fwd/l3fwd_lpm.c
+++ b/examples/l3fwd/l3fwd_lpm.c
@@ -52,6 +52,14 @@ static const struct ipv4_l3fwd_lpm_route
ipv4_l3fwd_lpm_route_array[] = {
{RTE_IPV4(198, 18, 5, 0), 24, 5},
{RTE_IPV4(198, 18, 6, 0), 24, 6},
{RTE_IPV4(198, 18, 7, 0), 24, 7},
+ {RTE_IPV4(198, 18, 8, 0), 24, 8},
+ {RTE_IPV4(198, 18, 9, 0), 24, 9},
+ {RTE_IPV4(198, 18, 10, 0), 24, 10},
+ {RTE_IPV4(198, 18, 11, 0), 24, 11},
+ {RTE_IPV4(198, 18, 12, 0), 24, 12},
+ {RTE_IPV4(198, 18, 13, 0), 24, 13},
+ {RTE_IPV4(198, 18, 14, 0), 24, 14},
+ {RTE_IPV4(198, 18, 15, 0), 24, 15},
};
/* 2001:0200::/48 is IANA reserved range for IPv6 benchmarking (RFC5180) */
@@ -64,6 +72,14 @@ static const struct ipv6_l3fwd_lpm_route
ipv6_l3fwd_lpm_route_array[] = {
{{32, 1, 2, 0, 0, 0, 0, 0, 0, 5, 0, 0, 0, 0, 0, 0}, 48, 5},
{{32, 1, 2, 0, 0, 0, 0, 0, 0, 6, 0, 0, 0, 0, 0, 0}, 48, 6},
{{32, 1, 2, 0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0}, 48, 7},
+ {{32, 1, 2, 0, 0, 0, 0, 0, 0, 8, 0, 0, 0, 0, 0, 0}, 48, 8},
+ {{32, 1, 2, 0, 0, 0, 0, 0, 0, 9, 0, 0, 0, 0, 0, 0}, 48, 9},
+ {{32, 1, 2, 0, 0, 0, 0, 0, 0, 10, 0, 0, 0, 0, 0, 0}, 48, 10},
+ {{32, 1, 2, 0, 0, 0, 0, 0, 0, 11, 0, 0, 0, 0, 0, 0}, 48, 11},
+ {{32, 1, 2, 0, 0, 0, 0, 0, 0, 12, 0, 0, 0, 0, 0, 0}, 48, 12},
+ {{32, 1, 2, 0, 0, 0, 0, 0, 0, 13, 0, 0, 0, 0, 0, 0}, 48, 13},
+ {{32, 1, 2, 0, 0, 0, 0, 0, 0, 14, 0, 0, 0, 0, 0, 0}, 48, 14},
+ {{32, 1, 2, 0, 0, 0, 0, 0, 0, 15, 0, 0, 0, 0, 0, 0}, 48, 15},
};
#define IPV4_L3FWD_LPM_MAX_RULES 1024
--
2.17.1
Re: [dpdk-dev] [PATCH] doc: announce API change in mbuf
On Fri, Jul 31, 2020 at 06:03:49PM +0200, Thomas Monjalon wrote: > In order to prepare for adding more features requiring more space in mbuf, > some static fields must become dynamic. > Some small layout changes may have performance benefits as well. > > The deprecation notice for atomic refcount is moved and reworded > to fit below the layout deprecation. > > Signed-off-by: Thomas Monjalon Acked-by: Olivier Matz
Re: [dpdk-dev] [PATCH V1 2/3] mbuf: change free_cb interface to adapt to GSO case
Hi, On Sun, Aug 02, 2020 at 07:12:36AM +0800, yang_y_yi wrote: > > > At 2020-07-31 23:15:43, "Olivier Matz" wrote: > >Hi, > > > >On Thu, Jul 30, 2020 at 08:08:59PM +0800, yang_y...@163.com wrote: > >> From: Yi Yang > >> > >> In GSO case, segmented mbufs are attached to original > >> mbuf which can't be freed when it is external. The issue > >> is free_cb doesn't know original mbuf and doesn't free > >> it when refcnt of shinfo is 0. > >> > >> Original mbuf can be freed by rte_pktmbuf_free segmented > >> mbufs or by rte_pktmbuf_free original mbuf. Two kind of > >> cases should have different behaviors. free_cb won't > >> explicitly call rte_pktmbuf_free to free original mbuf > >> if it is freed by rte_pktmbuf_free original mbuf, but it > >> has to call rte_pktmbuf_free to free original mbuf if it > >> is freed by rte_pktmbuf_free segmented mbufs. > >> > >> In order to fix this issue, free_cb interface has to been > >> changed, __rte_pktmbuf_free_extbuf must deliver called > >> mbuf pointer to free_cb, argument opaque can be defined > >> as a custom struct by user, it can includes original mbuf > >> pointer, user-defined free_cb can compare caller mbuf with > >> mbuf in opaque struct, free_cb should free original mbuf > >> if they are not same, this corresponds to rte_pktmbuf_free > >> segmented mbufs case, otherwise, free_cb won't free original > >> mbuf because the caller explicitly called rte_pktmbuf_free > >> to free it. > >> > >> Here is pseduo code to show two kind of cases. > >> > >> case 1. rte_pktmbuf_free segmented mbufs > >> > >> nb_tx = rte_gso_segment(original_mbuf, /* original mbuf */ > >> &gso_ctx, > >> /* segmented mbuf */ > >> (struct rte_mbuf **)&gso_mbufs, > >> MAX_GSO_MBUFS); > > > >I'm sorry but it is not very clear to me what operations are done by > >rte_gso_segment(). > > > >In the current code, I only see calls to rte_pktmbuf_attach(), > >which do not deal with external buffers. Am I missing something? > > > >Are you able to show the issue only with mbuf functions? It would > >be helpful to understand what does not work. > > > > > >Thanks, > >Olivier > > > Oliver, thank you for comment, let me show you why it doesn't work for my use > case. In OVS DPDK, VM uses vhostuserclient to send large packets whose size > is about 64K because we enabled TSO & UFO, these large packets use rte_mbufs > allocated by DPDK virtio_net function > virtio_dev_pktmbuf_alloc() (in file lib/librte_vhost/virtio_net.c. Please > refer to [PATCH V1 3/3], I changed free_cb as below, these packets use the > same allocate function and the same free_cb no matter they are TCP packet or > UDP packets, in case of VXLAN TSO, most NICs can't support inner UDP fragment > offload, so OVS DPDK has to do it by software, for UDP case, the original > rte_mbuf only can be freed by segmented rte_mbufs which are output packets of > rte_gso_segment, i.e. the original rte_mbuf only can freed by free_cb, you > can see, it explicitly called rte_pktmbuf_free(arg->mbuf), the condition > statement "if (caller_m != arg->mbuf)" is true for this case, this has no > problem, but for TCP case, the original mbuf is delivered to > rte_eth_tx_burst() but not segmented rte_mbufs output by rte_gso_segment, PMD > driver will call rte_pktmbuf_free(original_rte_mbuf) but not > rte_pktmbuf_free(segmented_rte_mbufs), the same free_cb will be called, that > means original_rte_mbuf will be freed twice, you know what will happen, this > is just the issue I'm fixing. I bring in caller_m argument, it can help work > around this because caller_m is arg->mbuf and the condition statement "if > (caller_m != arg->mbuf)" is false, you can't fix it without the change this > patch series did. I'm sill not sure to get your issue. Please, if you have a simple test case using only mbufs functions (without virtio, gso, ...), it would be very helpful because we will be sure that we are talking about the same thing. In case there is an issue, it can easily become a unit test. That said, I looked at vhost mbuf allocation and gso segmentation, and I found some strange things: 1/ In virtio_dev_extbuf_alloc(), and I there are 2 paths to create the ext mbuf. a/ The first one stores the shinfo struct in the mbuf, basically like this: pkt = rte_pktmbuf_alloc(mp); shinfo = rte_pktmbuf_mtod(pkt, struct rte_mbuf_ext_shared_info *); buf = rte_malloc(NULL, buf_len, RTE_CACHE_LINE_SIZE); shinfo->free_cb = virtio_dev_extbuf_free; shinfo->fcb_opaque = buf; rte_mbuf_ext_refcnt_set(shinfo, 1); I don't think it is a good idea, because there is no guarantee that the mbuf won't be freed before the buffer. For instance, doing this will probably fail: pkt2 = rte_pktmbuf_alloc(mp); rte_pktmbuf_attach(pkt2, pkt); rte_pktmbuf_free(pkt); /* pkt is freed, but it contai
Re: [dpdk-dev] [PATCH V1 2/3] mbuf: change free_cb interface to adapt to GSO case
On Sun, Aug 02, 2020 at 10:29:07PM +0200, Olivier Matz wrote: > Hi, > > On Sun, Aug 02, 2020 at 07:12:36AM +0800, yang_y_yi wrote: > > > > > > At 2020-07-31 23:15:43, "Olivier Matz" wrote: > > >Hi, > > > > > >On Thu, Jul 30, 2020 at 08:08:59PM +0800, yang_y...@163.com wrote: > > >> From: Yi Yang > > >> > > >> In GSO case, segmented mbufs are attached to original > > >> mbuf which can't be freed when it is external. The issue > > >> is free_cb doesn't know original mbuf and doesn't free > > >> it when refcnt of shinfo is 0. > > >> > > >> Original mbuf can be freed by rte_pktmbuf_free segmented > > >> mbufs or by rte_pktmbuf_free original mbuf. Two kind of > > >> cases should have different behaviors. free_cb won't > > >> explicitly call rte_pktmbuf_free to free original mbuf > > >> if it is freed by rte_pktmbuf_free original mbuf, but it > > >> has to call rte_pktmbuf_free to free original mbuf if it > > >> is freed by rte_pktmbuf_free segmented mbufs. > > >> > > >> In order to fix this issue, free_cb interface has to been > > >> changed, __rte_pktmbuf_free_extbuf must deliver called > > >> mbuf pointer to free_cb, argument opaque can be defined > > >> as a custom struct by user, it can includes original mbuf > > >> pointer, user-defined free_cb can compare caller mbuf with > > >> mbuf in opaque struct, free_cb should free original mbuf > > >> if they are not same, this corresponds to rte_pktmbuf_free > > >> segmented mbufs case, otherwise, free_cb won't free original > > >> mbuf because the caller explicitly called rte_pktmbuf_free > > >> to free it. > > >> > > >> Here is pseduo code to show two kind of cases. > > >> > > >> case 1. rte_pktmbuf_free segmented mbufs > > >> > > >> nb_tx = rte_gso_segment(original_mbuf, /* original mbuf */ > > >> &gso_ctx, > > >> /* segmented mbuf */ > > >> (struct rte_mbuf **)&gso_mbufs, > > >> MAX_GSO_MBUFS); > > > > > >I'm sorry but it is not very clear to me what operations are done by > > >rte_gso_segment(). > > > > > >In the current code, I only see calls to rte_pktmbuf_attach(), > > >which do not deal with external buffers. Am I missing something? > > > > > >Are you able to show the issue only with mbuf functions? It would > > >be helpful to understand what does not work. > > > > > > > > >Thanks, > > >Olivier > > > > > Oliver, thank you for comment, let me show you why it doesn't work for my > > use case. In OVS DPDK, VM uses vhostuserclient to send large packets whose > > size is about 64K because we enabled TSO & UFO, these large packets use > > rte_mbufs allocated by DPDK virtio_net function > > virtio_dev_pktmbuf_alloc() (in file lib/librte_vhost/virtio_net.c. Please > > refer to [PATCH V1 3/3], I changed free_cb as below, these packets use the > > same allocate function and the same free_cb no matter they are TCP packet > > or UDP packets, in case of VXLAN TSO, most NICs can't support inner UDP > > fragment offload, so OVS DPDK has to do it by software, for UDP case, the > > original rte_mbuf only can be freed by segmented rte_mbufs which are output > > packets of rte_gso_segment, i.e. the original rte_mbuf only can freed by > > free_cb, you can see, it explicitly called rte_pktmbuf_free(arg->mbuf), the > > condition statement "if (caller_m != arg->mbuf)" is true for this case, > > this has no problem, but for TCP case, the original mbuf is delivered to > > rte_eth_tx_burst() but not segmented rte_mbufs output by rte_gso_segment, > > PMD driver will call rte_pktmbuf_free(original_rte_mbuf) but not > > rte_pktmbuf_free(segmented_rte_mbufs), the same free_cb will be called, > > that means original_rte_mbuf will be freed twice, you know what will > > happen, this is just the issue I'm fixing. I bring in caller_m argument, it > > can help work around this because caller_m is arg->mbuf and the condition > > statement "if (caller_m != arg->mbuf)" is false, you can't fix it without > > the change this patch series did. > > I'm sill not sure to get your issue. Please, if you have a simple test > case using only mbufs functions (without virtio, gso, ...), it would be > very helpful because we will be sure that we are talking about the same > thing. In case there is an issue, it can easily become a unit test. > > That said, I looked at vhost mbuf allocation and gso segmentation, and > I found some strange things: > > 1/ In virtio_dev_extbuf_alloc(), and I there are 2 paths to create the >ext mbuf. > >a/ The first one stores the shinfo struct in the mbuf, basically > like this: > > pkt = rte_pktmbuf_alloc(mp); > shinfo = rte_pktmbuf_mtod(pkt, struct rte_mbuf_ext_shared_info *); > buf = rte_malloc(NULL, buf_len, RTE_CACHE_LINE_SIZE); > shinfo->free_cb = virtio_dev_extbuf_free; > shinfo->fcb_opaque = buf; > rte_mbuf_ext_refcnt_set(shinfo, 1); > > I don't think it is a good idea, because there is no
Re: [dpdk-dev] Queue Management Support in DPDK
On Sun, Aug 2, 2020 at 4:43 AM Archit Pandey wrote: > Hi Stephen, > > Thanks for the reply. > > On Thu, Jul 30, 2020 at 12:37 AM Stephen Hemminger > wrote: > > > > rte_sched is not a generic AQM mechanism. You will have to write a new > > replacement for rte_sched if you want something else. > > Yes, we did realize that rte_sched is not suitable for AQM algorithms. > We have implemented a bare-bones AQM mechanism that is independent of > rte_sched. > Using this implementation we have successfully added and tested PIE and > CoDel. > > > I would recommend starting with Cake. It is latest and most complete > > and the developers are active and friendly. > > CAKE can be added using what we have built, but before we do that we wanted > to know if such a feature would be welcomed by the community. In a word, yes. > Subsequently, we will submit an RFC patch series to the dev mailing list. > > Thanks, > Archit Pandey. > HTH, jdl
Re: [dpdk-dev] [PATCH V1 2/3] mbuf: change free_cb interface to adapt to GSO case
At 2020-08-03 04:29:07, "Olivier Matz" wrote: >Hi, > >On Sun, Aug 02, 2020 at 07:12:36AM +0800, yang_y_yi wrote: >> >> >> At 2020-07-31 23:15:43, "Olivier Matz" wrote: >> >Hi, >> > >> >On Thu, Jul 30, 2020 at 08:08:59PM +0800, yang_y...@163.com wrote: >> >> From: Yi Yang >> >> >> >> In GSO case, segmented mbufs are attached to original >> >> mbuf which can't be freed when it is external. The issue >> >> is free_cb doesn't know original mbuf and doesn't free >> >> it when refcnt of shinfo is 0. >> >> >> >> Original mbuf can be freed by rte_pktmbuf_free segmented >> >> mbufs or by rte_pktmbuf_free original mbuf. Two kind of >> >> cases should have different behaviors. free_cb won't >> >> explicitly call rte_pktmbuf_free to free original mbuf >> >> if it is freed by rte_pktmbuf_free original mbuf, but it >> >> has to call rte_pktmbuf_free to free original mbuf if it >> >> is freed by rte_pktmbuf_free segmented mbufs. >> >> >> >> In order to fix this issue, free_cb interface has to been >> >> changed, __rte_pktmbuf_free_extbuf must deliver called >> >> mbuf pointer to free_cb, argument opaque can be defined >> >> as a custom struct by user, it can includes original mbuf >> >> pointer, user-defined free_cb can compare caller mbuf with >> >> mbuf in opaque struct, free_cb should free original mbuf >> >> if they are not same, this corresponds to rte_pktmbuf_free >> >> segmented mbufs case, otherwise, free_cb won't free original >> >> mbuf because the caller explicitly called rte_pktmbuf_free >> >> to free it. >> >> >> >> Here is pseduo code to show two kind of cases. >> >> >> >> case 1. rte_pktmbuf_free segmented mbufs >> >> >> >> nb_tx = rte_gso_segment(original_mbuf, /* original mbuf */ >> >> &gso_ctx, >> >> /* segmented mbuf */ >> >> (struct rte_mbuf **)&gso_mbufs, >> >> MAX_GSO_MBUFS); >> > >> >I'm sorry but it is not very clear to me what operations are done by >> >rte_gso_segment(). >> > >> >In the current code, I only see calls to rte_pktmbuf_attach(), >> >which do not deal with external buffers. Am I missing something? >> > >> >Are you able to show the issue only with mbuf functions? It would >> >be helpful to understand what does not work. >> > >> > >> >Thanks, >> >Olivier >> > >> Oliver, thank you for comment, let me show you why it doesn't work for my >> use case. In OVS DPDK, VM uses vhostuserclient to send large packets whose >> size is about 64K because we enabled TSO & UFO, these large packets use >> rte_mbufs allocated by DPDK virtio_net function >> virtio_dev_pktmbuf_alloc() (in file lib/librte_vhost/virtio_net.c. Please >> refer to [PATCH V1 3/3], I changed free_cb as below, these packets use the >> same allocate function and the same free_cb no matter they are TCP packet or >> UDP packets, in case of VXLAN TSO, most NICs can't support inner UDP >> fragment offload, so OVS DPDK has to do it by software, for UDP case, the >> original rte_mbuf only can be freed by segmented rte_mbufs which are output >> packets of rte_gso_segment, i.e. the original rte_mbuf only can freed by >> free_cb, you can see, it explicitly called rte_pktmbuf_free(arg->mbuf), the >> condition statement "if (caller_m != arg->mbuf)" is true for this case, this >> has no problem, but for TCP case, the original mbuf is delivered to >> rte_eth_tx_burst() but not segmented rte_mbufs output by rte_gso_segment, >> PMD driver will call rte_pktmbuf_free(original_rte_mbuf) but not >> rte_pktmbuf_free(segmented_rte_mbufs), the same free_cb will be called, that >> means original_rte_mbuf will be freed twice, you know what will happen, this >> is just the issue I'm fixing. I bring in caller_m argument, it can help work >> around this because caller_m is arg->mbuf and the condition statement "if >> (caller_m != arg->mbuf)" is false, you can't fix it without the change this >> patch series did. > >I'm sill not sure to get your issue. Please, if you have a simple test >case using only mbufs functions (without virtio, gso, ...), it would be >very helpful because we will be sure that we are talking about the same >thing. In case there is an issue, it can easily become a unit test. Oliver, I think you don't get the point, free operation can't be controlled by the application itself, it is done by PMD driver and triggered by rte_eth_tx_burst, I have shown pseudo code, rte_gso_segment just segments a large mbuf to multiple mbufs, it won't send them, the application will call rte_eth_tx_burst to send them finally. > >That said, I looked at vhost mbuf allocation and gso segmentation, and >I found some strange things: > >1/ In virtio_dev_extbuf_alloc(), and I there are 2 paths to create the > ext mbuf. > > a/ The first one stores the shinfo struct in the mbuf, basically > like this: > > pkt = rte_pktmbuf_alloc(mp); > shinfo = rte_pktmbuf_mtod(pkt, struct rte_mbuf_ext_shared_info *); > buf = rte_mal
Re: [dpdk-dev] [PATCH V1 2/3] mbuf: change free_cb interface to adapt to GSO case
At 2020-08-03 04:45:12, "Olivier Matz" wrote: >On Sun, Aug 02, 2020 at 10:29:07PM +0200, Olivier Matz wrote: >> Hi, >> >> On Sun, Aug 02, 2020 at 07:12:36AM +0800, yang_y_yi wrote: >> > >> > >> > At 2020-07-31 23:15:43, "Olivier Matz" wrote: >> > >Hi, >> > > >> > >On Thu, Jul 30, 2020 at 08:08:59PM +0800, yang_y...@163.com wrote: >> > >> From: Yi Yang >> > >> >> > >> In GSO case, segmented mbufs are attached to original >> > >> mbuf which can't be freed when it is external. The issue >> > >> is free_cb doesn't know original mbuf and doesn't free >> > >> it when refcnt of shinfo is 0. >> > >> >> > >> Original mbuf can be freed by rte_pktmbuf_free segmented >> > >> mbufs or by rte_pktmbuf_free original mbuf. Two kind of >> > >> cases should have different behaviors. free_cb won't >> > >> explicitly call rte_pktmbuf_free to free original mbuf >> > >> if it is freed by rte_pktmbuf_free original mbuf, but it >> > >> has to call rte_pktmbuf_free to free original mbuf if it >> > >> is freed by rte_pktmbuf_free segmented mbufs. >> > >> >> > >> In order to fix this issue, free_cb interface has to been >> > >> changed, __rte_pktmbuf_free_extbuf must deliver called >> > >> mbuf pointer to free_cb, argument opaque can be defined >> > >> as a custom struct by user, it can includes original mbuf >> > >> pointer, user-defined free_cb can compare caller mbuf with >> > >> mbuf in opaque struct, free_cb should free original mbuf >> > >> if they are not same, this corresponds to rte_pktmbuf_free >> > >> segmented mbufs case, otherwise, free_cb won't free original >> > >> mbuf because the caller explicitly called rte_pktmbuf_free >> > >> to free it. >> > >> >> > >> Here is pseduo code to show two kind of cases. >> > >> >> > >> case 1. rte_pktmbuf_free segmented mbufs >> > >> >> > >> nb_tx = rte_gso_segment(original_mbuf, /* original mbuf */ >> > >> &gso_ctx, >> > >> /* segmented mbuf */ >> > >> (struct rte_mbuf **)&gso_mbufs, >> > >> MAX_GSO_MBUFS); >> > > >> > >I'm sorry but it is not very clear to me what operations are done by >> > >rte_gso_segment(). >> > > >> > >In the current code, I only see calls to rte_pktmbuf_attach(), >> > >which do not deal with external buffers. Am I missing something? >> > > >> > >Are you able to show the issue only with mbuf functions? It would >> > >be helpful to understand what does not work. >> > > >> > > >> > >Thanks, >> > >Olivier >> > > >> > Oliver, thank you for comment, let me show you why it doesn't work for my >> > use case. In OVS DPDK, VM uses vhostuserclient to send large packets >> > whose size is about 64K because we enabled TSO & UFO, these large packets >> > use rte_mbufs allocated by DPDK virtio_net function >> > virtio_dev_pktmbuf_alloc() (in file lib/librte_vhost/virtio_net.c. Please >> > refer to [PATCH V1 3/3], I changed free_cb as below, these packets use the >> > same allocate function and the same free_cb no matter they are TCP packet >> > or UDP packets, in case of VXLAN TSO, most NICs can't support inner UDP >> > fragment offload, so OVS DPDK has to do it by software, for UDP case, the >> > original rte_mbuf only can be freed by segmented rte_mbufs which are >> > output packets of rte_gso_segment, i.e. the original rte_mbuf only can >> > freed by free_cb, you can see, it explicitly called >> > rte_pktmbuf_free(arg->mbuf), the condition statement "if (caller_m != >> > arg->mbuf)" is true for this case, this has no problem, but for TCP case, >> > the original mbuf is delivered to rte_eth_tx_burst() but not segmented >> > rte_mbufs output by rte_gso_segment, PMD driver will call >> > rte_pktmbuf_free(original_rte_mbuf) but not >> > rte_pktmbuf_free(segmented_rte_mbufs), the same free_cb will be called, >> > that means original_rte_mbuf will be freed twice, you know what will >> > happen, this is just the issue I'm fixing. I bring in caller_m argument, >> > it can help work around this because caller_m is arg->mbuf and the >> > condition statement "if (caller_m != arg->mbuf)" is false, you can't fix >> > it without the change this patch series did. >> >> I'm sill not sure to get your issue. Please, if you have a simple test >> case using only mbufs functions (without virtio, gso, ...), it would be >> very helpful because we will be sure that we are talking about the same >> thing. In case there is an issue, it can easily become a unit test. >> >> That said, I looked at vhost mbuf allocation and gso segmentation, and >> I found some strange things: >> >> 1/ In virtio_dev_extbuf_alloc(), and I there are 2 paths to create the >>ext mbuf. >> >>a/ The first one stores the shinfo struct in the mbuf, basically >> like this: >> >> pkt = rte_pktmbuf_alloc(mp); >> shinfo = rte_pktmbuf_mtod(pkt, struct rte_mbuf_ext_shared_info *); >> buf = rte_malloc(NULL, buf_len, RTE_CACHE_LINE_SIZE); >> shinfo->free_cb = virtio_dev_extbu
Re: [dpdk-dev] [PATCH] net/bonding: fix deadloop when update RSS RETA
Hi, Zhiguang He
On 2020/8/2 20:27, 1913909...@qq.com wrote:
From: Zhiguang He <191390...@qq.com>
when parament reta_size < RTE_RETA_GROUP_SIZE,
reta_count will be 0. Then this function will
be deadloop
Fixes: 734ce47f71e0 ("bonding: support RSS dynamic configuration")
Cc: sta...@dpdk.org
Signed-off-by: Zhiguang He <1913909...@qq.com>
Acked-by: Wei Hu (Xavier)
Thank you for fixing this issue.
Xavier
---
drivers/net/bonding/rte_eth_bond_pmd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c
b/drivers/net/bonding/rte_eth_bond_pmd.c
index 116e2f2..cdbd815 100644
--- a/drivers/net/bonding/rte_eth_bond_pmd.c
+++ b/drivers/net/bonding/rte_eth_bond_pmd.c
@@ -2935,7 +2935,8 @@ struct bwg_slave {
return -EINVAL;
/* Copy RETA table */
- reta_count = reta_size / RTE_RETA_GROUP_SIZE;
+ reta_count = (reta_size + RTE_RETA_GROUP_SIZE - 1) /
+ RTE_RETA_GROUP_SIZE;
for (i = 0; i < reta_count; i++) {
internals->reta_conf[i].mask = reta_conf[i].mask;
[dpdk-dev] [PATCH 0/2] add AVF RSS support for IPv6 prefix
RSS for IPv6 prefix fields are supported in this patchset, so that we can use prefixes instead of full IPv6 address for AVF RSS. The prefix here includes the first 64 bits of both SRC and DST IPv6 address. [PATCH 1/2] common/iavf: support virtual channel for IPv6 prefix. [PATCH 2/2] net/iavf: support RSS for IPv6 prefix 64bit. Junfeng Guo (2): common/iavf: support virtual channel for IPv6 prefix net/iavf: support RSS for IPv6 prefix 64bit drivers/common/iavf/virtchnl.h | 13 ++ drivers/net/iavf/iavf_hash.c | 232 + 2 files changed, 245 insertions(+) -- 2.25.1
[dpdk-dev] [PATCH 1/2] common/iavf: support virtual channel for IPv6 prefix
Some IPv6 prefix related protocol header fields are defined in this
patch, so that we can use prefix instead of full IPv6 address for RSS.
Ref https://tools.ietf.org/html/rfc6052.
Signed-off-by: Junfeng Guo
---
drivers/common/iavf/virtchnl.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/common/iavf/virtchnl.h b/drivers/common/iavf/virtchnl.h
index 79515ee8b..424e18a11 100644
--- a/drivers/common/iavf/virtchnl.h
+++ b/drivers/common/iavf/virtchnl.h
@@ -881,6 +881,19 @@ enum virtchnl_proto_hdr_field {
VIRTCHNL_PROTO_HDR_IPV6_TC,
VIRTCHNL_PROTO_HDR_IPV6_HOP_LIMIT,
VIRTCHNL_PROTO_HDR_IPV6_PROT,
+ /* IPV6 Prefix */
+ VIRTCHNL_PROTO_HDR_IPV6_PREFIX32_SRC,
+ VIRTCHNL_PROTO_HDR_IPV6_PREFIX32_DST,
+ VIRTCHNL_PROTO_HDR_IPV6_PREFIX40_SRC,
+ VIRTCHNL_PROTO_HDR_IPV6_PREFIX40_DST,
+ VIRTCHNL_PROTO_HDR_IPV6_PREFIX48_SRC,
+ VIRTCHNL_PROTO_HDR_IPV6_PREFIX48_DST,
+ VIRTCHNL_PROTO_HDR_IPV6_PREFIX56_SRC,
+ VIRTCHNL_PROTO_HDR_IPV6_PREFIX56_DST,
+ VIRTCHNL_PROTO_HDR_IPV6_PREFIX64_SRC,
+ VIRTCHNL_PROTO_HDR_IPV6_PREFIX64_DST,
+ VIRTCHNL_PROTO_HDR_IPV6_PREFIX96_SRC,
+ VIRTCHNL_PROTO_HDR_IPV6_PREFIX96_DST,
/* TCP */
VIRTCHNL_PROTO_HDR_TCP_SRC_PORT =
PROTO_HDR_FIELD_START(VIRTCHNL_PROTO_HDR_TCP),
--
2.25.1
[dpdk-dev] [PATCH 2/2] net/iavf: support RSS for IPv6 prefix 64bit
RSS for IPv6 prefix 64bit fields are supported in this patch, so that
we can use prefix instead of full IPv6 address for RSS. The prefix
here only includes the first 64 bits of both SRC and DST IPv6 address.
Signed-off-by: Junfeng Guo
---
drivers/net/iavf/iavf_hash.c | 232 +++
1 file changed, 232 insertions(+)
diff --git a/drivers/net/iavf/iavf_hash.c b/drivers/net/iavf/iavf_hash.c
index e2eebd2d3..3dc96d0f6 100644
--- a/drivers/net/iavf/iavf_hash.c
+++ b/drivers/net/iavf/iavf_hash.c
@@ -445,6 +445,41 @@ static struct iavf_pattern_match_item
iavf_hash_pattern_list[] = {
FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV6_DST) | \
FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV6_PROT), {BUFF_NOUSED } }
+/* IPV6 Prefix 64 for L3 */
+#define proto_hint_ipv6_pre64 { \
+ VIRTCHNL_PROTO_HDR_IPV6, \
+ FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV6_PREFIX64_SRC) | \
+ FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV6_PREFIX64_DST), {BUFF_NOUSED } }
+
+#define proto_hint_ipv6_pre64_src { \
+ VIRTCHNL_PROTO_HDR_IPV6, \
+ FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV6_PREFIX64_SRC), {BUFF_NOUSED } }
+
+#define proto_hint_ipv6_pre64_dst { \
+ VIRTCHNL_PROTO_HDR_IPV6, \
+ FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV6_PREFIX64_DST), {BUFF_NOUSED } }
+
+/* IPV6 Prefix 64 for L4 */
+#define proto_hint_ipv6_pre64_prot { \
+ VIRTCHNL_PROTO_HDR_IPV6, \
+ FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV6_PREFIX64_SRC) | \
+ FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV6_PREFIX64_DST) | \
+ FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV6_PROT), {BUFF_NOUSED } }
+
+#define proto_hint_ipv6_pre64_src_prot { \
+ VIRTCHNL_PROTO_HDR_IPV6, \
+ FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV6_PREFIX64_SRC) | \
+ FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV6_PROT), {BUFF_NOUSED } }
+
+#define proto_hint_ipv6_pre64_dst_prot { \
+ VIRTCHNL_PROTO_HDR_IPV6, \
+ FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV6_PREFIX64_DST) | \
+ FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV6_PROT), {BUFF_NOUSED } }
+
+#define proto_hint_ipv6_pre64_only_prot { \
+ VIRTCHNL_PROTO_HDR_IPV6, \
+ FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV6_PROT), {BUFF_NOUSED } }
+
#define proto_hint_gtpu_ip_teid { \
VIRTCHNL_PROTO_HDR_GTPU_IP, \
FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_GTPU_IP_TEID), {BUFF_NOUSED } }
@@ -1999,6 +2034,139 @@ struct virtchnl_proto_hdrs hdrs_hint_ipv6_udp_esp = {
proto_hint_udp_only, proto_hint_esp }
};
+/* IPV6 Prefix 64 */
+struct virtchnl_proto_hdrs hdrs_hint_ipv6_pre64 = {
+ TUNNEL_LEVEL_OUTER, PROTO_COUNT_ONE, {proto_hint_ipv6_pre64 }
+};
+
+struct virtchnl_proto_hdrs hdrs_hint_ipv6_pre64_src = {
+ TUNNEL_LEVEL_OUTER, PROTO_COUNT_ONE, {proto_hint_ipv6_pre64_src }
+};
+
+struct virtchnl_proto_hdrs hdrs_hint_ipv6_pre64_dst = {
+ TUNNEL_LEVEL_OUTER, PROTO_COUNT_ONE, {proto_hint_ipv6_pre64_dst }
+};
+
+struct virtchnl_proto_hdrs hdrs_hint_ipv6_pre64_prot = {
+ TUNNEL_LEVEL_OUTER, PROTO_COUNT_ONE, {proto_hint_ipv6_pre64_prot }
+};
+
+struct virtchnl_proto_hdrs hdrs_hint_ipv6_pre64_src_prot = {
+ TUNNEL_LEVEL_OUTER, PROTO_COUNT_ONE, {proto_hint_ipv6_pre64_src_prot }
+};
+
+struct virtchnl_proto_hdrs hdrs_hint_ipv6_pre64_dst_prot = {
+ TUNNEL_LEVEL_OUTER, PROTO_COUNT_ONE, {proto_hint_ipv6_pre64_dst_prot }
+};
+
+/* IPV6 Prefix 64 UDP */
+struct virtchnl_proto_hdrs hdrs_hint_ipv6_pre64_udp = {
+ TUNNEL_LEVEL_OUTER, PROTO_COUNT_TWO, {proto_hint_ipv6_pre64_prot,
+ proto_hint_udp }
+};
+
+struct virtchnl_proto_hdrs hdrs_hint_ipv6_pre64_src_udp_src_port = {
+ TUNNEL_LEVEL_OUTER, PROTO_COUNT_TWO, {proto_hint_ipv6_pre64_src_prot,
+ proto_hint_udp_src_port }
+};
+
+struct virtchnl_proto_hdrs hdrs_hint_ipv6_pre64_src_udp_dst_port = {
+ TUNNEL_LEVEL_OUTER, PROTO_COUNT_TWO, {proto_hint_ipv6_pre64_src_prot,
+ proto_hint_udp_dst_port }
+};
+
+struct virtchnl_proto_hdrs hdrs_hint_ipv6_pre64_dst_udp_src_port = {
+ TUNNEL_LEVEL_OUTER, PROTO_COUNT_TWO, {proto_hint_ipv6_pre64_dst_prot,
+ proto_hint_udp_src_port }
+};
+
+struct virtchnl_proto_hdrs hdrs_hint_ipv6_pre64_dst_udp_dst_port = {
+ TUNNEL_LEVEL_OUTER, PROTO_COUNT_TWO, {proto_hint_ipv6_pre64_dst_prot,
+ proto_hint_udp_dst_port }
+};
+
+struct virtchnl_proto_hdrs hdrs_hint_ipv6_pre64_udp_src_port = {
+ TUNNEL_LEVEL_OUTER, PROTO_COUNT_TWO, {proto_hint_ipv6_pre64_only_prot,
+ proto_hint_udp_src_port }
+};
+
+struct virtchnl_proto_hdrs hdrs_hint_ipv6_pre64_udp_dst_port = {
+ TUNNEL_LEVEL_OUTER, PROTO_COUNT_TWO, {proto_hint_ipv6_pre64_only_prot,
+ proto_hint_udp_dst_port }
+};
+
+/* IPV6 Prefix 64 TCP */
+struct virtchnl_proto_hdrs hdrs_hint_ipv6_pre64_tcp = {
+ TUNNEL_LEVEL_OUTER, PROTO_COUNT_TWO, {proto_hint_ipv6_pre64_prot,
+ proto_hint_tcp }
+};
+
+struct virtchnl_proto_hdrs hdrs_hint_ipv6_pre64_src_tcp_src_port = {
+ TUNNEL_LEVEL_OUTER, PROTO_COUNT_TWO, {proto_hint_ipv6_pre64_src_prot,
+ proto_hint_tcp_
Re: [dpdk-dev] [PATCH] doc: announce changes to eventdev public data structures
On Sat, Aug 1, 2020 at 1:04 AM McDaniel, Timothy wrote: > > From: "McDaniel, Timothy" The patch should have some description and Please change the subject to: "doc: eventdev ABI change to support DLB PMD" > > Signed-off-by: McDaniel, Timothy We don't use "," in the Signed-off-by. Please change to ``Signed-off-by: McDaniel Timothy `` > --- > 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..b9682a7 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 change to support DLB PMD and future extensions > + The following structures and will be modified to support to DLB PMD and > future > + extension in the eventdev library. > + - ``rte_event_dev_info`` > + - ``rte_event_dev_config`` > + - ``rte_event_port_conf`` > + Patches containing justification, documentation, and proposed modifications > + can be found at: > + - https://patches.dpdk.org/patch/71457/ > + - https://patches.dpdk.org/patch/71456/ The HTML rendering of the above text is not proper. Please run "make doc-guides-html" to check generated HTML output. You could use the below text as an example for sphinx syntax. * eventdev: ABI change to support DLB PMD and future extensions: ``rte_event_dev_info``, ``rte_event_dev_config``, ``rte_event_port_conf`` will be modified to support to DLB PMD and future extension 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/ With the above changes: Acked-by: Jerin Jacob > -- > 1.7.10 >
Re: [dpdk-dev] [PATCH] doc: announce changes to eventdev public structures
On Sun, Aug 2, 2020 at 4:21 PM wrote: > > From: Pavan Nikhilesh I think, git subject can be changed to "doc: add reserve fields to eventdev public structures" > > Add 64 byte padding at the end of event device public structure to allow > future extensions. > > Signed-off-by: Pavan Nikhilesh > --- > http://patches.dpdk.org/project/dpdk/list/?series=10728&state=* > > doc/guides/rel_notes/deprecation.rst | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index ea4cfa7a4..37c7c9029 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -151,3 +151,12 @@ 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``. You could point the existing patches for the same as the reference here. http://patches.dpdk.org/patch/72786/ http://patches.dpdk.org/patch/72787/ With the above change: Acked-by: Jerin Jacob > -- > 2.17.1 >
Re: [dpdk-dev] [PATCH 0/5] compiling ethdev lib under windows
> -Original Message-
> From: Narcisa Ana Maria Vasile
> Sent: Wednesday, July 29, 2020 4:02 AM
> To: Fady Bader
> Cc: dev@dpdk.org; Thomas Monjalon ; Tasnim Bashar
> ; Tal Shnaiderman ; Yohad Tor
> ; dmitry.kozl...@gmail.com;
> harini.ramakrish...@microsoft.com; ocard...@microsoft.com;
> ranjit.me...@intel.com; pallavi.ka...@intel.com; kevin.la...@intel.com;
> ferruh.yi...@intel.com; arybche...@solarflare.com
> Subject: Re: [dpdk-dev] [PATCH 0/5] compiling ethdev lib under windows
>
> On Thu, Jun 25, 2020 at 04:30:33PM +0300, Fady Bader wrote:
> > Added needed changes in order to get ethdev compiling under windows.
> >
> > Depends-on: series-10382 ("compile librte_net for windows")
> >
> > Fady Bader (5):
> > eal: added interrupts empty stubs
> > eal: updated export list for Windows
> > ethdev: remove structs from export list
> > telemetry: implement empty stubs for Windows
> > ethdev: compiling ethdev under Windows
> >
> > lib/librte_eal/rte_eal_exports.def | 10
> > lib/librte_eal/windows/eal_interrupts.c | 17 +
> > lib/librte_eal/windows/meson.build | 1 +
> > lib/librte_ethdev/rte_ethdev_version.map | 2 --
> > lib/librte_telemetry/rte_telemetry.h | 4 +++
> > lib/librte_telemetry/telemetry.c | 43
> +++-
> > lib/librte_telemetry/telemetry_legacy.c | 26 ++-
> > lib/meson.build | 7 --
> > 8 files changed, 104 insertions(+), 6 deletions(-) create mode
> > 100644 lib/librte_eal/windows/eal_interrupts.c
> >
> Tested-by: Narcisa Vasile
>
> Compiled successfully with mingw and clang. It does need a rebase, as more
> changes have been added in telemetry.
> Also, there's a missing export that needs to be added as well
> 'rte_log_register_type_and_pick_level'
Thanks Narcisa, I'll send a rebased patch.
>
>
> > --
> > 2.16.1.windows.4
