Re: [dpdk-dev] [PATCH v4] net/i40e: relaxed barrier in the tx fastpath
Hi Jerin,
Could you help review this patch? We discussed a lot on this topic and I think
we agreed already to relax the barrier only on the fast path.
Best Regards,
Gavin
> -Original Message-
> From: Gavin Hu
> Sent: Friday, February 14, 2020 3:58 PM
> To: Gavin Hu
> Subject: Re: [dpdk-dev] [PATCH v4] net/i40e: relaxed barrier in the tx
> fastpath
>
> To keep ordering of mixed accesses, rte_cio is sufficient.
> The rte_io barrier inside the I40E_PCI_REG_WRITE is overkill.[1]
>
> [1] http://inbox.dpdk.org/dev/CALBAE1M-ezVWCjqCZDBw+MMDEC4O9
> qf0kpn89emdgdajepk...@mail.gmail.com
>
> Fixes: 4861cde46116 ("i40e: new poll mode driver")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Gavin Hu
> ---
> V4:
> - add the Fixes tag and CC stable
> V3:
> - optimize the barriers in the fast path only, leave as it is for the
> barriers in the slow path and control path
> - drop the virtio patches from the list as they are in the control path
> - it makes more sense to relax the barrier in the fast path, at the PMD level.
> relaxing the fundamental rte_io_x barriers APIs requires scrutinizations for
> each PMDs which use the barriers directly or indirectly.
> V2:
> - remove virtio_pci_read/write64 APIs definitions, they are not needed and
> generate compiling errors like " error: unused function 'virtio_pci_write64'
> [-
> Werror,-Wunused-function]"
> - update the reference link to kernel source code
> ---
> drivers/net/i40e/i40e_rxtx.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
> index fd1ae80da..8c0f7cc67 100644
> --- a/drivers/net/i40e/i40e_rxtx.c
> +++ b/drivers/net/i40e/i40e_rxtx.c
> @@ -1248,7 +1248,8 @@ i40e_xmit_pkts(void *tx_queue, struct rte_mbuf
> **tx_pkts, uint16_t nb_pkts)
> (unsigned) txq->port_id, (unsigned) txq->queue_id,
> (unsigned) tx_id, (unsigned) nb_tx);
>
> -I40E_PCI_REG_WRITE(txq->qtx_tail, tx_id);
> +rte_cio_wmb();
> +I40E_PCI_REG_WRITE_RELAXED(txq->qtx_tail, tx_id);
> txq->tx_tail = tx_id;
>
> return nb_tx;
> --
> 2.17.1
>
Re: [dpdk-dev] [PATCH v2] eal: fix to set the rte_device ptr's device args before hotplug
On 14/02/2020 07:43, Somnath Kotur wrote:
As per the comments in this code section, since there is a matching device,
it is now its responsibility to manage the devargs we've just inserted.
But the matching device ptr's devargs is still uninitialized or not pointing
to the newest dev_args that were passed as a parameter to local_dev_probe().
This is needed particularly in the case when *probe is called again* on an
already probed device as part of adding a representor port to an OVS
switch(OVS-DPDK)
Fixes: 7e8b26650146 ("eal: fix hotplug add / remove")
Signed-off-by: Somnath Kotur
---
v1->v2: Incorporated suggestions from Gaetan Rivet
drivers/bus/pci/linux/pci.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/bus/pci/linux/pci.c b/drivers/bus/pci/linux/pci.c
index 740a2cd..71b0a30 100644
--- a/drivers/bus/pci/linux/pci.c
+++ b/drivers/bus/pci/linux/pci.c
@@ -377,6 +377,11 @@
*/
RTE_LOG(ERR, EAL, "Unexpected device
scan at %s!\n",
filename);
+ else if (dev2->device.devargs !=
+dev->device.devargs) {
+
rte_devargs_remove(dev2->device.devargs);
+ pci_name_set(dev2);
+ }
}
free(dev);
}
Hi Somnath,
I see that this is already pretty similar in BSD (minus the
rte_devargs_remove()),
so if you have tested and validated that this works properly I'm fine with this
patch.
This might miss a Cc: sta...@dpdk.org, otherwise,
Acked-by: Gaetan Rivet
Re: [dpdk-dev] [PATCH v2] net/i40e: fix unchecked return value
On 02/12, Beilei Xing wrote:
>This patch fixes unchecked return value
>of the i40e_xmit_cleanup function.
>
>Coverity issue: 353617
>Fixes: 4861cde46116 ("i40e: new poll mode driver")
>
>Signed-off-by: Beilei Xing
>---
>V2 change:
> - Use cast.
>
> drivers/net/i40e/i40e_rxtx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
>index fd1ae80..f6d23c9 100644
>--- a/drivers/net/i40e/i40e_rxtx.c
>+++ b/drivers/net/i40e/i40e_rxtx.c
>@@ -1039,7 +1039,7 @@ i40e_xmit_pkts(void *tx_queue, struct rte_mbuf
>**tx_pkts, uint16_t nb_pkts)
>
> /* Check if the descriptor ring needs to be cleaned. */
> if (txq->nb_tx_free < txq->tx_free_thresh)
>- i40e_xmit_cleanup(txq);
>+ (void)i40e_xmit_cleanup(txq);
>
> for (nb_tx = 0; nb_tx < nb_pkts; nb_tx++) {
> td_cmd = 0;
>--
>2.7.4
>
Acked-by: Xiaolong Ye
Applied to dpdk-next-net-intel, Thanks.
Re: [dpdk-dev] [PATCH v1] net/ice: resolve unchecked return value
On 02/12, Sunil Pai G wrote:
>This checks the return value of the function ice_xmit_cleanup
>
>Coverity issue: 353623
>Fixes: 17c7d0f9d6a4 ("net/ice: support basic Rx/Tx")
>Cc: wenzhuo...@intel.com
Cc: sta...@dpdk.org
>
>Signed-off-by: Sunil Pai G
>---
> drivers/net/ice/ice_rxtx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/net/ice/ice_rxtx.c b/drivers/net/ice/ice_rxtx.c
>index ce5b8e6ca..60c411bfa 100644
>--- a/drivers/net/ice/ice_rxtx.c
>+++ b/drivers/net/ice/ice_rxtx.c
>@@ -2471,7 +2471,7 @@ ice_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
>uint16_t nb_pkts)
>
> /* Check if the descriptor ring needs to be cleaned. */
> if (txq->nb_tx_free < txq->tx_free_thresh)
>- ice_xmit_cleanup(txq);
>+ (void)ice_xmit_cleanup(txq);
>
> for (nb_tx = 0; nb_tx < nb_pkts; nb_tx++) {
> tx_pkt = *tx_pkts++;
>--
>2.17.1
>
Acked-by: Xiaolong Ye
Applied to dpdk-next-net-intel, Thanks.
Re: [dpdk-dev] [PATCH] doc: add new features and improvements to ixgbe
On 02/14, Jiaqi Min wrote: >Added support for API rte_eth_tx_done_cleanup. >Added support setting VF MAC address by PF driver. >Added support for setting the link to specific speed. > >Signed-off-by: Jiaqi Min >--- > doc/guides/rel_notes/release_20_02.rst | 6 ++ > 1 file changed, 6 insertions(+) > >diff --git a/doc/guides/rel_notes/release_20_02.rst >b/doc/guides/rel_notes/release_20_02.rst >index 786f9b119..b705bdf73 100644 >--- a/doc/guides/rel_notes/release_20_02.rst >+++ b/doc/guides/rel_notes/release_20_02.rst >@@ -92,6 +92,12 @@ New Features > * Added more supported device IDs. > * Updated virtual channel to latest AVF spec. > >+* **Updated the Intel ixgbe driver.** >+ >+ * Added support for API rte_eth_tx_done_cleanup. >+ * Added support setting VF MAC address by PF driver. >+ * Added support for setting the link to specific speed. >+ > * **Updated Intel i40e driver.** > > Updated i40e PMD with new features and improvements, including: >-- >2.17.1 > Acked-by: Xiaolong Ye Applied to dpdk-next-net-intel, Thanks.
Re: [dpdk-dev] [PATCH] doc: add new features and improvements to ice
On 02/14, Jiaqi Min wrote: >Added support for API rte_eth_tx_done_cleanup. > >Signed-off-by: Jiaqi Min >--- > doc/guides/rel_notes/release_20_02.rst | 1 + > 1 file changed, 1 insertion(+) > >diff --git a/doc/guides/rel_notes/release_20_02.rst >b/doc/guides/rel_notes/release_20_02.rst >index 786f9b119..5d01dac58 100644 >--- a/doc/guides/rel_notes/release_20_02.rst >+++ b/doc/guides/rel_notes/release_20_02.rst >@@ -84,6 +84,7 @@ New Features > * Added support for MAC rules on specific port. > * Added support for MAC/VLAN with TCP/UDP in switch rule. > * Added support for 1/10G device. >+ * Added support for API rte_eth_tx_done_cleanup. > > * **Updated Intel iavf driver.** > >-- >2.17.1 > Acked-by: Xiaolong Ye Applied to dpdk-next-net-intel, Thanks.
Re: [dpdk-dev] [PATCH] doc: add new features and improvements to i40e
On 02/14, Jiaqi Min wrote: >Added support for API rte_eth_tx_done_cleanup. >Added support for VF multiple queues interrupt. >Added support for setting the link to specific speed. > >Signed-off-by: Jiaqi Min >--- > doc/guides/rel_notes/release_20_02.rst | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > >diff --git a/doc/guides/rel_notes/release_20_02.rst >b/doc/guides/rel_notes/release_20_02.rst >index 786f9b119..e26a60d23 100644 >--- a/doc/guides/rel_notes/release_20_02.rst >+++ b/doc/guides/rel_notes/release_20_02.rst >@@ -104,7 +104,10 @@ New Features > * Added LLDP support. > * Extended PHY access AQ cmd. > * Added support for reading LPI counters. >- * Added support for Energy Efficient Ethernet >+ * Added support for Energy Efficient Ethernet. >+ * Added support for API rte_eth_tx_done_cleanup. >+ * Added support for VF multiple queues interrupt. >+ * Added support for setting the link to specific speed. > > * **Updated Mellanox mlx5 driver.** > >-- >2.17.1 > Acked-by: Xiaolong Ye Applied to dpdk-next-net-intel, Thanks.
[dpdk-dev] [PATCH v2] kni: fix not contiguous FIFO
From: Scott Wasson
KNI requires FIFO to be physically contiguous, with existing
'rte_memzone_reserve()' API this is not guaranteed by default and as a
result KNI rings and packet delivery may be broken if reserved memory
is not physically contiguous.
Fixing it by providing 'RTE_MEMZONE_IOVA_CONTIG' flag to ask physically
contiguous memory.
Fixes: 23fa86e529e4 ("memzone: enable IOVA-contiguous reserving")
Cc: sta...@dpdk.org
Signed-off-by: Scott Wasson
Acked-by: Ferruh Yigit
---
lib/librte_kni/rte_kni.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/lib/librte_kni/rte_kni.c b/lib/librte_kni/rte_kni.c
index e388751e3..bcf82cc2d 100644
--- a/lib/librte_kni/rte_kni.c
+++ b/lib/librte_kni/rte_kni.c
@@ -145,31 +145,38 @@ kni_reserve_mz(struct rte_kni *kni)
char mz_name[RTE_MEMZONE_NAMESIZE];
snprintf(mz_name, RTE_MEMZONE_NAMESIZE, KNI_TX_Q_MZ_NAME_FMT,
kni->name);
- kni->m_tx_q = rte_memzone_reserve(mz_name, KNI_FIFO_SIZE,
SOCKET_ID_ANY, 0);
+ kni->m_tx_q = rte_memzone_reserve(mz_name, KNI_FIFO_SIZE, SOCKET_ID_ANY,
+ RTE_MEMZONE_IOVA_CONTIG);
KNI_MEM_CHECK(kni->m_tx_q == NULL, tx_q_fail);
snprintf(mz_name, RTE_MEMZONE_NAMESIZE, KNI_RX_Q_MZ_NAME_FMT,
kni->name);
- kni->m_rx_q = rte_memzone_reserve(mz_name, KNI_FIFO_SIZE,
SOCKET_ID_ANY, 0);
+ kni->m_rx_q = rte_memzone_reserve(mz_name, KNI_FIFO_SIZE, SOCKET_ID_ANY,
+ RTE_MEMZONE_IOVA_CONTIG);
KNI_MEM_CHECK(kni->m_rx_q == NULL, rx_q_fail);
snprintf(mz_name, RTE_MEMZONE_NAMESIZE, KNI_ALLOC_Q_MZ_NAME_FMT,
kni->name);
- kni->m_alloc_q = rte_memzone_reserve(mz_name, KNI_FIFO_SIZE,
SOCKET_ID_ANY, 0);
+ kni->m_alloc_q = rte_memzone_reserve(mz_name, KNI_FIFO_SIZE,
SOCKET_ID_ANY,
+ RTE_MEMZONE_IOVA_CONTIG);
KNI_MEM_CHECK(kni->m_alloc_q == NULL, alloc_q_fail);
snprintf(mz_name, RTE_MEMZONE_NAMESIZE, KNI_FREE_Q_MZ_NAME_FMT,
kni->name);
- kni->m_free_q = rte_memzone_reserve(mz_name, KNI_FIFO_SIZE,
SOCKET_ID_ANY, 0);
+ kni->m_free_q = rte_memzone_reserve(mz_name, KNI_FIFO_SIZE,
SOCKET_ID_ANY,
+ RTE_MEMZONE_IOVA_CONTIG);
KNI_MEM_CHECK(kni->m_free_q == NULL, free_q_fail);
snprintf(mz_name, RTE_MEMZONE_NAMESIZE, KNI_REQ_Q_MZ_NAME_FMT,
kni->name);
- kni->m_req_q = rte_memzone_reserve(mz_name, KNI_FIFO_SIZE,
SOCKET_ID_ANY, 0);
+ kni->m_req_q = rte_memzone_reserve(mz_name, KNI_FIFO_SIZE,
SOCKET_ID_ANY,
+ RTE_MEMZONE_IOVA_CONTIG);
KNI_MEM_CHECK(kni->m_req_q == NULL, req_q_fail);
snprintf(mz_name, RTE_MEMZONE_NAMESIZE, KNI_RESP_Q_MZ_NAME_FMT,
kni->name);
- kni->m_resp_q = rte_memzone_reserve(mz_name, KNI_FIFO_SIZE,
SOCKET_ID_ANY, 0);
+ kni->m_resp_q = rte_memzone_reserve(mz_name, KNI_FIFO_SIZE,
SOCKET_ID_ANY,
+ RTE_MEMZONE_IOVA_CONTIG);
KNI_MEM_CHECK(kni->m_resp_q == NULL, resp_q_fail);
snprintf(mz_name, RTE_MEMZONE_NAMESIZE, KNI_SYNC_ADDR_MZ_NAME_FMT,
kni->name);
- kni->m_sync_addr = rte_memzone_reserve(mz_name, KNI_FIFO_SIZE,
SOCKET_ID_ANY, 0);
+ kni->m_sync_addr = rte_memzone_reserve(mz_name, KNI_FIFO_SIZE,
SOCKET_ID_ANY,
+ RTE_MEMZONE_IOVA_CONTIG);
KNI_MEM_CHECK(kni->m_sync_addr == NULL, sync_addr_fail);
return 0;
--
2.24.1
Re: [dpdk-dev] [PATCH 2/2] l3fwd-power: fix interrupt disable
On 30/1/2020 5:40 PM, Liang, Ma wrote:
On 20 Jan 22:06, Xiao Wang wrote:
Since all related queues' interrupts are turned on before epoll, we need
to turn off all the interrupts after wakeup. This patch fixes the issue
of only turning off the interrupted queues.
Fixes: b736d64787fc ("examples/l3fwd-power: disable Rx interrupt when waking
up")
Cc: sta...@dpdk.org
Signed-off-by: Xiao Wang
Hi Xiao,
I'm OK with the patch.
Reviewed-by: Liang Ma
Regards
Liang
Hi,
I've discussed the before/after testing with Liang, and the code looks
good to me.
Acked-by: David Hunt
Also, from Liang's email above, but without the leading spaces:
Reviewed-by: Liang Ma
Thanks,
Dave
Re: [dpdk-dev] [PATCH 1/2] l3fwd-power: fix a typo
On 21/1/2020 3:06 AM, Xiao Wang wrote:
Fixes: aee3bc79cc34 ("examples/l3fwd-power: enable one-shot Rx interrupt and polling
switch")
Cc: sta...@dpdk.org
Signed-off-by: Xiao Wang
---
examples/l3fwd-power/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/examples/l3fwd-power/main.c b/examples/l3fwd-power/main.c
index d049d8a5d..ffcc7ecf4 100644
--- a/examples/l3fwd-power/main.c
+++ b/examples/l3fwd-power/main.c
@@ -1338,7 +1338,7 @@ main_loop(__attribute__((unused)) void *dummy)
*/
rte_delay_us(lcore_idle_hint);
else {
- /* suspend until rx interrupt trigges */
+ /* suspend until rx interrupt triggers */
if (intr_en) {
turn_on_intr(qconf);
sleep_until_rx_interrupt(
Re: [dpdk-dev] [PATCH 1/2] l3fwd-power: fix a typo
On 21/1/2020 3:06 AM, Xiao Wang wrote:
Fixes: aee3bc79cc34 ("examples/l3fwd-power: enable one-shot Rx interrupt and polling
switch")
Cc: sta...@dpdk.org
Signed-off-by: Xiao Wang
---
examples/l3fwd-power/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/examples/l3fwd-power/main.c b/examples/l3fwd-power/main.c
index d049d8a5d..ffcc7ecf4 100644
--- a/examples/l3fwd-power/main.c
+++ b/examples/l3fwd-power/main.c
@@ -1338,7 +1338,7 @@ main_loop(__attribute__((unused)) void *dummy)
*/
rte_delay_us(lcore_idle_hint);
else {
- /* suspend until rx interrupt trigges */
+ /* suspend until rx interrupt triggers */
if (intr_en) {
turn_on_intr(qconf);
sleep_until_rx_interrupt(
Acked-by: David Hunt
Re: [dpdk-dev] [PATCH 1/2] examples/ip_pipeline: fix crypto queue config
> -Original Message-
> From: dev On Behalf Of Hemant Agrawal
> Sent: Wednesday, December 11, 2019 5:26 AM
> To: dev@dpdk.org
> Cc: Dumitrescu, Cristian ; sta...@dpdk.org;
> Jun Yang ; Hemant Agrawal
>
> Subject: [dpdk-dev] [PATCH 1/2] examples/ip_pipeline: fix crypto queue
> config
>
> queue_conf need to have mempool details before pair setup.
>
> Fixes: 261bbff75e34 ("examples: use separate crypto session mempools")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Jun Yang
> Signed-off-by: Hemant Agrawal
> ---
Acked-by: Fan Zhang
Re: [dpdk-dev] [PATCH 1/2] examples/ip_pipeline: fix crypto queue config
> -Original Message-
> From: dev On Behalf Of Hemant Agrawal
> Sent: Wednesday, December 11, 2019 5:26 AM
> To: dev@dpdk.org
> Cc: Dumitrescu, Cristian ; sta...@dpdk.org;
> Jun Yang ; Hemant Agrawal
>
> Subject: [dpdk-dev] [PATCH 1/2] examples/ip_pipeline: fix crypto queue
> config
>
> queue_conf need to have mempool details before pair setup.
>
> Fixes: 261bbff75e34 ("examples: use separate crypto session mempools")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Jun Yang
> Signed-off-by: Hemant Agrawal
> ---
> examples/ip_pipeline/cryptodev.c | 24 +---
> 1 file changed, 13 insertions(+), 11 deletions(-)
>
> diff --git a/examples/ip_pipeline/cryptodev.c
> b/examples/ip_pipeline/cryptodev.c
> index b0d9f3d217..ae65a90859 100644
> --- a/examples/ip_pipeline/cryptodev.c
> +++ b/examples/ip_pipeline/cryptodev.c
> @@ -99,17 +99,6 @@ cryptodev_create(const char *name, struct
> cryptodev_params *params)
> if (status < 0)
> return NULL;
>
> - queue_conf.nb_descriptors = params->queue_size;
> - for (i = 0; i < params->n_queues; i++) {
> - status = rte_cryptodev_queue_pair_setup(dev_id, i,
> - &queue_conf, socket_id);
> - if (status < 0)
> - return NULL;
> - }
> -
> - if (rte_cryptodev_start(dev_id) < 0)
> - return NULL;
> -
> cryptodev = calloc(1, sizeof(struct cryptodev));
> if (cryptodev == NULL) {
> rte_cryptodev_stop(dev_id);
> @@ -149,6 +138,19 @@ cryptodev_create(const char *name, struct
> cryptodev_params *params)
>
> TAILQ_INSERT_TAIL(&cryptodev_list, cryptodev, node);
>
> + queue_conf.nb_descriptors = params->queue_size;
> + queue_conf.mp_session = cryptodev->mp_create;
> + queue_conf.mp_session_private = cryptodev->mp_init;
> + for (i = 0; i < params->n_queues; i++) {
> + status = rte_cryptodev_queue_pair_setup(dev_id, i,
> + &queue_conf, socket_id);
> + if (status < 0)
> + goto error_exit;
> + }
> +
> + if (rte_cryptodev_start(dev_id) < 0)
> + goto error_exit;
> +
> return cryptodev;
>
> error_exit:
> --
> 2.17.1
Idea is correct, implementation is broken, so rework is needed.
The cryptodev->mp_create and cryptodev->mp_init are not valid at this point
where you assign them to queue_conf.mp_session and
queue_conf.mp_session_private, as they only get created later in this same
function. Please fix.
Re: [dpdk-dev] [PATCH 2/2] examples/ip_pipeline: fix to use sock id instead of cpuid
> -Original Message-
> From: dev On Behalf Of Hemant Agrawal
> Sent: Wednesday, December 11, 2019 5:26 AM
> To: dev@dpdk.org
> Cc: Dumitrescu, Cristian ; sta...@dpdk.org;
> Jun Yang
> Subject: [dpdk-dev] [PATCH 2/2] examples/ip_pipeline: fix to use sock id
> instead of cpuid
>
> From: Jun Yang
>
> rte_lcore_to_socket_id should be used to convert cpu ID to socket ID.
>
> Fixes: 6bfe74f8c93e ("examples/ip_pipeline: add mempool object")
> Fixes: d75c371e9b46 ("examples/ip_pipeline: add pipeline object")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Jun Yang
> ---
> examples/ip_pipeline/mempool.c | 2 +-
> examples/ip_pipeline/pipeline.c | 10 +-
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/examples/ip_pipeline/mempool.c
> b/examples/ip_pipeline/mempool.c
> index f5d2a7d108..d7eea85f8f 100644
> --- a/examples/ip_pipeline/mempool.c
> +++ b/examples/ip_pipeline/mempool.c
> @@ -58,7 +58,7 @@ mempool_create(const char *name, struct
> mempool_params *params)
> params->cache_size,
> 0,
> params->buffer_size - sizeof(struct rte_mbuf),
> - params->cpu_id);
> + rte_lcore_to_socket_id(params->cpu_id));
>
> if (m == NULL)
> return NULL;
> diff --git a/examples/ip_pipeline/pipeline.c
> b/examples/ip_pipeline/pipeline.c
> index b627310a0c..d8df62d785 100644
> --- a/examples/ip_pipeline/pipeline.c
> +++ b/examples/ip_pipeline/pipeline.c
> @@ -94,7 +94,7 @@ pipeline_create(const char *name, struct
> pipeline_params *params)
>
> msgq_req = rte_ring_create(msgq_name,
> PIPELINE_MSGQ_SIZE,
> - params->cpu_id,
> + rte_lcore_to_socket_id(params->cpu_id),
> RING_F_SP_ENQ | RING_F_SC_DEQ);
> if (msgq_req == NULL)
> return NULL;
> @@ -103,7 +103,7 @@ pipeline_create(const char *name, struct
> pipeline_params *params)
>
> msgq_rsp = rte_ring_create(msgq_name,
> PIPELINE_MSGQ_SIZE,
> - params->cpu_id,
> + rte_lcore_to_socket_id(params->cpu_id),
> RING_F_SP_ENQ | RING_F_SC_DEQ);
> if (msgq_rsp == NULL) {
> rte_ring_free(msgq_req);
> @@ -111,7 +111,7 @@ pipeline_create(const char *name, struct
> pipeline_params *params)
> }
>
> pp.name = name;
> - pp.socket_id = (int) params->cpu_id;
> + pp.socket_id = (int) rte_lcore_to_socket_id(params->cpu_id);
> pp.offset_port_id = params->offset_port_id;
>
> p = rte_pipeline_create(&pp);
> @@ -332,7 +332,7 @@ pipeline_port_in_create(const char *pipeline_name,
>
> if (ap) {
> action = rte_port_in_action_create(ap->ap,
> - pipeline->cpu_id);
> + rte_lcore_to_socket_id(pipeline->cpu_id));
> if (action == NULL)
> return -1;
>
> @@ -1002,7 +1002,7 @@ pipeline_table_create(const char *pipeline_name,
>
> if (ap) {
> action = rte_table_action_create(ap->ap,
> - pipeline->cpu_id);
> + rte_lcore_to_socket_id(pipeline->cpu_id));
> if (action == NULL)
> return -1;
>
> --
> 2.17.1
NACK.
This is incorrect, probably a misunderstanding: the params->cpu_id is already
the CPU socket ID (passed as parameter), and not the core ID. For core ID, we
typically use variable names as core_id or lcore_id, and never cpu_id.
Re: [dpdk-dev] [dpdk-stable] [PATCH v2] kni: fix not contiguous FIFO
On Fri, Feb 14, 2020 at 11:01 AM Ferruh Yigit wrote:
>
> From: Scott Wasson
>
> KNI requires FIFO to be physically contiguous, with existing
> 'rte_memzone_reserve()' API this is not guaranteed by default and as a
> result KNI rings and packet delivery may be broken if reserved memory
> is not physically contiguous.
>
> Fixing it by providing 'RTE_MEMZONE_IOVA_CONTIG' flag to ask physically
> contiguous memory.
>
Bugzilla ID: 389
> Fixes: 23fa86e529e4 ("memzone: enable IOVA-contiguous reserving")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Scott Wasson
> Acked-by: Ferruh Yigit
Applied, thanks.
--
David Marchand
Re: [dpdk-dev] [RFC] meter: fix ABI break due to experimental tag removal
On Thu, Feb 13, 2020 at 09:40:40PM -0500, Neil Horman wrote: > On Thu, Feb 13, 2020 at 05:40:43PM +, Ray Kinsella wrote: > > > > > > On 05/02/2020 11:32, Neil Horman wrote: > > > On Wed, Feb 05, 2020 at 11:04:29AM +0100, Luca Boccassi wrote: > > >> On Tue, 2020-02-04 at 07:02 -0500, Neil Horman wrote: > > But if we can do the versioning in the master, LTS can backport it > > and can have mature version of that API in LTS without breaking > > the existing users. > > > > >>> > > >>> But why bother? The only thing you've changed is the version > > >>> tagging. Its ok to leave that alone in LTS, you just cant change > > >>> it. > > >>> > > >>> Thats part of the burden of an LTS release, it will have some drift > > >>> from the upstream head, because you have to keep things stable. So > > >>> you stabilize the upstream ABI version for this API and just never > > >>> backport it to the current LTS release. > > >> > > >> Hi, > > >> > > >> A customer (OVS) explicitly and specifically requested backporting > > >> the symbol change to 19.11, as they don't want to enable > > >> experimental APIs in their releases. I replied that it would only be > > >> acceptable with aliasing to keep compatibility, and Ferruh very > > >> kindly did the work to implement that. > > >> > > > but, thats part of the agreement, no? You can't always have new > > > features and stability at the same time. > > > > > > I get that this is an odd corner case, because strictly speaking you > > > could waive the ABI change that libabigail is reporting, and most > > > application users (like OVS) could get away with it, because their > > > application does all the right things to make it ok, but I don't > > > think you can make a decsion like this for all users based on the > > > request of a single user. > > > > > > It seems like the right thing is for OVS to augment their build time > > > configuration to allow developers to select the ability to use > > > experimental apis at compile time, and then the decision is placed in > > > the hands of end users. > > > > So this is not isolated case right ... it is common from API's to > > graduate from experimental to mature, we _want_ that to happen, we > > _want_ APIs to mature. > > > Sure, I can absolutely agree with that, though I would suggest that the > maturity of the ABI is orthogonal to its labeling as such (more on that > below) > > > I am worried what you are proposing will encourage a behavior whereby > > maintainers to wait until the declaration of the next major ABI version > > to make these symbol changes, causing these kinds of changes to queue > > up for that release. > > > I think you're probably right about that, and would make the agrument > that thats perfectly fine (again I'll clarify below) > > > And you would have to ask why? In the case of a reasonably mature API, > > there will be no functional or signature change - its mature! So what > > is the harm of providing an alias back to Experimental until the next > > ABI version is declared? > > > From a philosophical standpoint, there is absoluely no harm, and I don't > think anyone would disagree, the harm comes from the details of the > implementation, as you've noted. > > > So while yes, you are 100% right - experimental mean no guarantees. > > But if the API is baked, it is not going to change, so I don't see the > > harm. > > > > We don't want the unnecessary triumph of policy over pragmatism. > > > I would make the converse argument here. While I agree that when an API > is mature, theres no point in calling it experimental anymore, I would > also suggest that, if an API is mature, and not expected to change, > theres no harm in leaving its version tag as experimental for an LTS > release. This is what I was referring to above. Once an application > developer has done the work to integrate an API from DPDK into its > application, that work is done. If the API remains stable, then I > honestly don't know that they care that the version label is EXPERIMENTAL > versus 20.11 or 20.05 or whatever. They care about the API being stable > more so than its version label. As such, it seemsreasonable to me to > have developers queue their migration of experimental APIs to official > versioned APIs at the next major release deliniation point. > > I'd welcome counter arguments, but it seems pretty natural to me to make > these sorts of changes at the major release mark. People using > experimantal apis have already implicity agreed to manage changes to > them, so if we just hold it stable in an LTS release (and don't update > the version label), its just gravy for them. > The counter argument that I see is that while the experimental tag remains in place the user has no way to know that an API is stable or not, and so in many projects cannot use the API. If for example an API that is experimental in 19.11 is unchanged through 20.05 at which point we decide to promote it to stable.
[dpdk-dev] [PATCH] examples/fips_validation: fix typo
This patch fixes the cipher len keyword typo.
Fixes: 07f5e4553293 ("examples/fips_validation: fix cipher length for AES-GCM")
Cc: ssaranan...@marvell.com
Signed-off-by: Fan Zhang
---
examples/fips_validation/fips_validation_gcm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/examples/fips_validation/fips_validation_gcm.c
b/examples/fips_validation/fips_validation_gcm.c
index f29502559..bc2d37dcb 100644
--- a/examples/fips_validation/fips_validation_gcm.c
+++ b/examples/fips_validation/fips_validation_gcm.c
@@ -19,7 +19,7 @@
#define PTLEN_STR "PTlen = "
#define AADLEN_STR "AADlen = "
#define TAGLEN_STR "Taglen = "
-#define CTLEN_STR "PTlen = "
+#define CTLEN_STR "CTlen = "
#define COUNT_STR "Count = "
#define KEY_STR"Key = "
--
2.20.1
Re: [dpdk-dev] [PATCH v3 2/2] net/virtio: add link speed devarg
Hi Ivan, On 2/14/20 8:59 AM, Ivan Dyukov wrote: > Hi Maxime, > > 13.02.2020 16:54, Maxime Coquelin пишет: >> Hi Ivan, >> >> On 2/12/20 11:40 AM, Maxime Coquelin wrote: >>> On 2/12/20 11:35 AM, Tiwei Bie wrote: On Fri, Feb 07, 2020 at 02:25:26PM +0300, Ivan Dyukov wrote: > Some applications like pktgen use link_speed to calculate > transmit rate. It limits outcome traffic to hardcoded 10G. > > This patch adds link_speed devarg which allows to configure > link_speed of virtio device. > > Signed-off-by: Ivan Dyukov > --- > doc/guides/nics/virtio.rst | 7 ++ > drivers/net/virtio/virtio_ethdev.c | 101 - > drivers/net/virtio/virtio_pci.h| 1 + > 3 files changed, 92 insertions(+), 17 deletions(-) Maybe I missed something.. Why not enable the VIRTIO_NET_F_SPEED_DUPLEX support directly? When that feature is supported and negotiated, we will ignore this devarg? >>> IMHO, yes. When VIRTIO_NET_F_SPEED_DUPLEX will be implemented and >>> negotiated, this devarg will be ignored. >>> If we want this devarg, it looks better to support it in virtio-user as well (most code is shared between virtio-PMD and virtio-user). >>> That's a valid point, Virtio-user should also support it. >>> Ivan, can you send a new revision with Virtio-user support as well? >> Do you plan to submit the new revision today? > > I have a lot of work which is not related to opensource contribution. I need > few days to prepare the patch. OK, that's a problem for v20.02 as we are already at -rc3, which should not contain new features but only fixes. I was fine to waive for -rc3, but it will be too risky for -rc4. Regards, Maxime > Best regards, > Ivan > >> Thanks, >> Maxime >> >>> Thanks, >>> Maxime >>> Thanks! Tiwei > > > > >
Re: [dpdk-dev] [PATCH 0/2] l3fwd-power fixes
On Mon, Jan 20, 2020 at 4:12 PM Xiao Wang wrote: > > The second patch will apply failed without the first patch applied, so make > them a series. The first patch is just a typo fix. The second patch fixes > the issue that the interrupts are turned off only on the Rx queues that > has traffic arrived, rather than all the Rx queues a core has taken. Series applied, thanks. -- David Marchand
Re: [dpdk-dev] [PATCH] examples/fips_validation: fix typo
On Fri, Feb 14, 2020 at 12:41 PM Fan Zhang wrote:
>
> This patch fixes the cipher len keyword typo.
>
> Fixes: 07f5e4553293 ("examples/fips_validation: fix cipher length for
> AES-GCM")
>
Suggested-by: Akhil Goyal
> Signed-off-by: Fan Zhang
Acked-by: David Marchand
Applied, thanks.
--
David Marchand
Re: [dpdk-dev] [PATCH v1 1/2] devtools: allow test-null.sh to run on ppc64le
On Fri, Feb 14, 2020 at 12:22 AM dwilder wrote: > > On 2020-02-13 14:17, Thomas Monjalon wrote: > > 13/02/2020 21:58, dwilder: > >> On 2020-02-13 12:32, Thomas Monjalon wrote: > >> > 13/02/2020 21:24, David Wilder: > >> >> - The --no-huge option requires iova-mode=VA. > >> >> On ppc64le iova-mode defaults to PA therefor > >> >> VA mode must be explicitly set. > >> > > >> > Should we make VA mode automatic when using --no-huge? > >> > Should we log an error message when using --no-huge with PA mode? > >> > >> Logging a messages sounds like a good idea. Ignoring the users > >> request > >> of iova-mode=PA (in the case of x86) and just switching modes would be > >> bad. > > > > Yes, I mean for ppc64, if --no-huge is specified, > > would you like to change the default to VA mode? > > OK, that would be better. > I will switch to VA when --no-huge is set (ppc64 only). With no-huge, we can't ensure the physical addresses won't change (might be different if we locked the pages in memory... but not possible and/or not handled in eal afaics). This limitation is generic, not arch specific. > Add log messages if PA is selected with --no-huge (all arches). -- David Marchand
[dpdk-dev] [PATCH] lpm6: add const to IPv6 addresses
LPM6 does not modify input IPv6 addresses so mark them as 'const'.
The real need is to add those annotations to the API but in addition
they were added also to internal functions and slight formatting changes
were performed (aligning of input args).
Signed-off-by: Andrzej Ostruszka
---
lib/librte_lpm/rte_lpm6.c | 71 ---
lib/librte_lpm/rte_lpm6.h | 20 ++-
2 files changed, 47 insertions(+), 44 deletions(-)
diff --git a/lib/librte_lpm/rte_lpm6.c b/lib/librte_lpm/rte_lpm6.c
index c46e557e2..0e6b5ab19 100644
--- a/lib/librte_lpm/rte_lpm6.c
+++ b/lib/librte_lpm/rte_lpm6.c
@@ -156,7 +156,7 @@ ip6_copy_addr(uint8_t *dst, const uint8_t *src)
*/
static inline uint32_t
rule_hash(const void *data, __rte_unused uint32_t data_len,
- uint32_t init_val)
+ uint32_t init_val)
{
return rte_jhash(data, sizeof(struct rte_lpm6_rule_key), init_val);
}
@@ -219,7 +219,7 @@ tbl8_available(struct rte_lpm6 *lpm)
* note that ip must be already masked
*/
static inline void
-rule_key_init(struct rte_lpm6_rule_key *key, uint8_t *ip, uint8_t depth)
+rule_key_init(struct rte_lpm6_rule_key *key, const uint8_t *ip, uint8_t depth)
{
ip6_copy_addr(key->ip, ip);
key->depth = depth;
@@ -445,8 +445,8 @@ rte_lpm6_free(struct rte_lpm6 *lpm)
/* Find a rule */
static inline int
rule_find_with_key(struct rte_lpm6 *lpm,
- const struct rte_lpm6_rule_key *rule_key,
- uint32_t *next_hop)
+ const struct rte_lpm6_rule_key *rule_key,
+ uint32_t *next_hop)
{
uint64_t hash_val;
int ret;
@@ -464,8 +464,8 @@ rule_find_with_key(struct rte_lpm6 *lpm,
/* Find a rule */
static int
-rule_find(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
- uint32_t *next_hop)
+rule_find(struct rte_lpm6 *lpm, const uint8_t *ip, uint8_t depth,
+ uint32_t *next_hop)
{
struct rte_lpm6_rule_key rule_key;
@@ -485,7 +485,8 @@ rule_find(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
* <0 - error
*/
static inline int
-rule_add(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth, uint32_t next_hop)
+rule_add(struct rte_lpm6 *lpm, const uint8_t *ip, uint8_t depth,
+uint32_t next_hop)
{
int ret, rule_exist;
struct rte_lpm6_rule_key rule_key;
@@ -526,7 +527,7 @@ rule_add(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
uint32_t next_hop)
*/
static void
expand_rule(struct rte_lpm6 *lpm, uint32_t tbl8_gindex, uint8_t old_depth,
- uint8_t new_depth, uint32_t next_hop, uint8_t valid)
+ uint8_t new_depth, uint32_t next_hop, uint8_t valid)
{
uint32_t tbl8_group_end, tbl8_gindex_next, j;
@@ -561,7 +562,7 @@ expand_rule(struct rte_lpm6 *lpm, uint32_t tbl8_gindex,
uint8_t old_depth,
*/
static inline void
init_tbl8_header(struct rte_lpm6 *lpm, uint32_t tbl_ind,
- uint32_t owner_tbl_ind, uint32_t owner_entry_ind)
+uint32_t owner_tbl_ind, uint32_t owner_entry_ind)
{
struct rte_lpm_tbl8_hdr *tbl_hdr = &lpm->tbl8_hdrs[tbl_ind];
tbl_hdr->owner_tbl_ind = owner_tbl_ind;
@@ -600,9 +601,9 @@ get_bitshift(const uint8_t *ip, uint8_t first_byte, uint8_t
bytes)
*/
static inline int
simulate_add_step(struct rte_lpm6 *lpm, struct rte_lpm6_tbl_entry *tbl,
- struct rte_lpm6_tbl_entry **next_tbl, const uint8_t *ip,
- uint8_t bytes, uint8_t first_byte, uint8_t depth,
- uint32_t *need_tbl_nb)
+ struct rte_lpm6_tbl_entry **next_tbl, const uint8_t *ip,
+ uint8_t bytes, uint8_t first_byte, uint8_t depth,
+ uint32_t *need_tbl_nb)
{
uint32_t entry_ind;
uint8_t bits_covered;
@@ -652,10 +653,10 @@ simulate_add_step(struct rte_lpm6 *lpm, struct
rte_lpm6_tbl_entry *tbl,
*/
static inline int
add_step(struct rte_lpm6 *lpm, struct rte_lpm6_tbl_entry *tbl,
- uint32_t tbl_ind, struct rte_lpm6_tbl_entry **next_tbl,
- uint32_t *next_tbl_ind, uint8_t *ip, uint8_t bytes,
- uint8_t first_byte, uint8_t depth, uint32_t next_hop,
- uint8_t is_new_rule)
+uint32_t tbl_ind, struct rte_lpm6_tbl_entry **next_tbl,
+uint32_t *next_tbl_ind, const uint8_t *ip, uint8_t bytes,
+uint8_t first_byte, uint8_t depth, uint32_t next_hop,
+uint8_t is_new_rule)
{
uint32_t entry_ind, tbl_range, tbl8_group_start, tbl8_group_end, i;
uint32_t tbl8_gindex;
@@ -854,8 +855,8 @@ simulate_add(struct rte_lpm6 *lpm, const uint8_t
*masked_ip, uint8_t depth)
* Add a route
*/
int
-rte_lpm6_add(struct rte_lpm6 *lpm, uint8_t *ip, uint8_t depth,
- uint32_t next_hop)
+rte_lpm6_add(struct rte_lpm6 *lpm, const uint8_t *ip, uint8_t depth,
+uint32_t next_hop)
{
struct rte_lpm6_tbl_entry *tbl;
struct rte_lpm6_tbl_entry *tbl_next = NULL;
@@ -913,8 +914,8 @@ rte_lpm6_ad
Re: [dpdk-dev] [PATCH v8 1/1] fbarray: fix duplicated fbarray file in secondary
On Fri, Feb 14, 2020 at 8:46 AM Yasufumi Ogawa wrote: > > Hi, > > Could I confirm that this patch is going to be merged in 20.02? Sorry, but I can't take this patch in 20.02. It breaks compilation on FreeBSD. http://mails.dpdk.org/archives/test-report/2019-November/109435.html I am still unconvinced on the need to change the size to something so huge to accommodate with this new use case (secondary processes in containers). Why can't we truncate the container hostname so that it fits in 64 bytes? Thomas, opinion? -- David Marchand
Re: [dpdk-dev] [PATCH 0/7] vfio/pci: SR-IOV support
On Fri, 14 Feb 2020 15:57:04 +1100 Alexey Kardashevskiy wrote: > On 12/02/2020 10:05, Alex Williamson wrote: > > Given the mostly positive feedback from the RFC[1], here's a new > > non-RFC revision. Changes since RFC: > > > > - vfio_device_ops.match semantics refined > > - Use helpers for struct pci_dev.physfn to avoid breakage without > >CONFIG_PCI_IOV > > - Relax to allow SR-IOV configuration changes while PF is opened. > >There are potentially interesting use cases here, including > >perhaps QEMU emulating an SR-IOV capability and calling out > >to a privileged entity to manipulate sriov_numvfs and corral > >the resulting devices. > > - Retest vfio_device_feature.argsz to include uuid length. > > - Add Connie's R-b on 6/7 > > > > I still wish we had a solution to make it less opaque to the user > > why a VFIO_GROUP_GET_DEVICE_FD() has failed if a VF token is > > required, but this is still the best I've been able to come up with. > > If there are objections or better ideas, please raise them now. > > > > The synopsis of this series is that we have an ongoing desire to drive > > PCIe SR-IOV PFs from userspace with VFIO. There's an immediate need > > for this with DPDK drivers and potentially interesting future use > > cases in virtualization. We've been reluctant to add this support > > previously due to the dependency and trust relationship between the > > VF device and PF driver. Minimally the PF driver can induce a denial > > of service to the VF, but depending on the specific implementation, > > the PF driver might also be responsible for moving data between VFs > > or have direct access to the state of the VF, including data or state > > otherwise private to the VF or VF driver. > > > > To help resolve these concerns, we introduce a VF token into the VFIO > > PCI ABI, which acts as a shared secret key between drivers. The > > userspace PF driver is required to set the VF token to a known value > > and userspace VF drivers are required to provide the token to access > > the VF device. If a PF driver is restarted with VF drivers in use, it > > must also provide the current token in order to prevent a rogue > > untrusted PF driver from replacing a known driver. The degree to > > which this new token is considered secret is left to the userspace > > drivers, the kernel intentionally provides no means to retrieve the > > current token. > > > > Note that the above token is only required for this new model where > > both the PF and VF devices are usable through vfio-pci. Existing > > models of VFIO drivers where the PF is used without SR-IOV enabled > > or the VF is bound to a userspace driver with an in-kernel, host PF > > driver are unaffected. > > > > The latter configuration above also highlights a new inverted scenario > > that is now possible, a userspace PF driver with in-kernel VF drivers. > > I believe this is a scenario that should be allowed, but should not be > > enabled by default. This series includes code to set a default > > driver_override for VFs sourced from a vfio-pci user owned PF, such > > that the VFs are also bound to vfio-pci. This model is compatible > > with tools like driverctl and allows the system administrator to > > decide if other bindings should be enabled. The VF token interface > > above exists only between vfio-pci PF and VF drivers, once a VF is > > bound to another driver, the administrator has effectively pronounced > > the device as trusted. The vfio-pci driver will note alternate > > binding in dmesg for logging and debugging purposes. > > > > Please review, comment, and test. The example QEMU implementation > > provided with the RFC[2] is still current for this version. Thanks, > > > It is a cool feature. One question - what device have you tested it with? > > Does not a PF want to control/manage VFs on a PF driver side? I am > thinking of Mellanox CX5 or similar NIC and it acts as an managed > ethernet switch which might want to do something to VFs and VFs may not > work as expected without PF's native driver doing things to it, or this > is not a concern, is it? Thanks, TBH, I'm starting with the premise that a userspace PF driver already works. The DPDK folks have produced some "interesting" code that allows SR-IOV to be enabled on a PF underneath vfio-pci. There's also a non-upstream igb-uio driver associated with DPDK that seems to be recommended for SR-IOV PF driver use cases, particularly for an FPGA device. The testing I've done, and what's provided by the QEMU patch I reference, is really only unit testing the vf_token support and DEVICE_FEATURE ioctl provided here. I used this with an Intel 82576 (igb) where the PF driver doesn't particularly like being assigned to a VM with SR-IOV enabled. Likewise, I can prove that the interfaces here provide the correct restrictions for the VF, but the VF doesn't work in a VM due to the state of the PF. I'm hoping we'll have some confirmation from the DPDK f
Re: [dpdk-dev] [PATCH v8 1/1] fbarray: fix duplicated fbarray file in secondary
14/02/2020 16:08, David Marchand: > On Fri, Feb 14, 2020 at 8:46 AM Yasufumi Ogawa wrote: > > > > Hi, > > > > Could I confirm that this patch is going to be merged in 20.02? > > Sorry, but I can't take this patch in 20.02. > It breaks compilation on FreeBSD. > http://mails.dpdk.org/archives/test-report/2019-November/109435.html > > > I am still unconvinced on the need to change the size to something so > huge to accommodate with this new use case (secondary processes in > containers). > Why can't we truncate the container hostname so that it fits in 64 bytes? > > > Thomas, opinion? If the use case is justified enough, I would prefer merging such change in 20.11 avoiding an ABI breakage in a core library, even if it is experimental.
Re: [dpdk-dev] [PATCH] lpm6: add const to IPv6 addresses
On Fri, 14 Feb 2020 15:37:59 +0100 Andrzej Ostruszka wrote: > LPM6 does not modify input IPv6 addresses so mark them as 'const'. > > The real need is to add those annotations to the API but in addition > they were added also to internal functions and slight formatting changes > were performed (aligning of input args). > > Signed-off-by: Andrzej Ostruszka This is a duplicate of: https://patchwork.dpdk.org/patch/65126/
Re: [dpdk-dev] [dpdk-stable] [PATCH v2] crypto/ccp: enable IOMMU for CCP
12/02/2020 14:50, Akhil Goyal: > > Acked-by: Ravi Kumar > > > Applied to dpdk-next-crypto > Removed stable tag as it is a feature not a fix. Sorry I must drop this patch because it does not compile on i686. Note: it is too late in the cycle to add such a feature.
Re: [dpdk-dev] [PATCH] lpm6: add const to IPv6 addresses
On 2/14/20 4:47 PM, Stephen Hemminger wrote: > On Fri, 14 Feb 2020 15:37:59 +0100 > Andrzej Ostruszka wrote: > >> LPM6 does not modify input IPv6 addresses so mark them as 'const'. >> >> The real need is to add those annotations to the API but in addition >> they were added also to internal functions and slight formatting changes >> were performed (aligning of input args). >> >> Signed-off-by: Andrzej Ostruszka > > This is a duplicate of: > https://patchwork.dpdk.org/patch/65126/ Yes indeed. Thank you for pointing out, will drop it. With regards Andrzej Ostruszka PS. Did you remember this patch, or is there some neat way to search for relevant outstanding patches? I'm pretty sure I've seen it but there are so many changes being sent and at the time had no need for this change that it escaped from my memory.
[dpdk-dev] [PATCH v2] lib: fix unnecessary double negation
An equality expression already returns either 0 or 1.
There is no need to use double negation for these cases.
Fixes: ea672a8b1655 ("mbuf: remove the rte_pktmbuf structure")
Fixes: a0fd91cefcc0 ("mempool: rename functions with confusing names")
Cc: olivier.m...@6wind.com
Cc: bruce.richard...@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Ciara Power
Acked-by: Olivier Matz
Reviewed-by: Ferruh Yigit
---
V2:
- Rebased onto master
- Changed commit subject and description
---
lib/librte_mbuf/rte_mbuf.h | 2 +-
lib/librte_mempool/rte_mempool.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 219b110b7..6d080527f 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -1535,7 +1535,7 @@ static inline int rte_pktmbuf_trim(struct rte_mbuf *m,
uint16_t len)
static inline int rte_pktmbuf_is_contiguous(const struct rte_mbuf *m)
{
__rte_mbuf_sanity_check(m, 1);
- return !!(m->nb_segs == 1);
+ return m->nb_segs == 1;
}
/**
diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h
index f81152af9..e588c5d9b 100644
--- a/lib/librte_mempool/rte_mempool.h
+++ b/lib/librte_mempool/rte_mempool.h
@@ -1653,7 +1653,7 @@ rte_mempool_in_use_count(const struct rte_mempool *mp);
static inline int
rte_mempool_full(const struct rte_mempool *mp)
{
- return !!(rte_mempool_avail_count(mp) == mp->size);
+ return rte_mempool_avail_count(mp) == mp->size;
}
/**
@@ -1672,7 +1672,7 @@ rte_mempool_full(const struct rte_mempool *mp)
static inline int
rte_mempool_empty(const struct rte_mempool *mp)
{
- return !!(rte_mempool_avail_count(mp) == 0);
+ return rte_mempool_avail_count(mp) == 0;
}
/**
--
2.17.1
Re: [dpdk-dev] [PATCH v2] lib: fix unnecessary double negation
On Fri, Feb 14, 2020 at 5:28 PM Ciara Power wrote:
>
> An equality expression already returns either 0 or 1.
> There is no need to use double negation for these cases.
>
> Fixes: ea672a8b1655 ("mbuf: remove the rte_pktmbuf structure")
> Fixes: a0fd91cefcc0 ("mempool: rename functions with confusing names")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Ciara Power
> Acked-by: Olivier Matz
> Reviewed-by: Ferruh Yigit
Applied, thanks.
--
David Marchand
Re: [dpdk-dev] [PATCH v2] service: don't walk out of bounds when checking services
On 07/02/2020 14:27, Aaron Conole wrote:
> Kevin Traynor writes:
>
>> On 20/12/2019 14:43, David Marchand wrote:
>>> On Wed, Dec 4, 2019 at 9:34 AM David Marchand
>>> wrote:
On Wed, Dec 4, 2019 at 9:33 AM David Marchand
wrote:
>
> On Tue, Dec 3, 2019 at 10:15 PM Aaron Conole wrote:
>>
>> The service_valid call is used without properly bounds checking the
>> input parameter. Almost all instances of the service_valid call are
>> inside a for() loop that prevents excessive walks, but some of the
>> public APIs don't bounds check and will pass invalid arguments.
>>
>> Prevent this by using SERVICE_GET_OR_ERR_RET where it makes sense,
>> and adding a bounds check to one service_valid() use.
>>
>> Fixes: 8d39d3e237c2 ("service: fix race in service on app lcore
>> function")
>> Fixes: e9139a32f6e8 ("service: add function to run on app lcore")
>> Fixes: e30dd31847d2 ("service: add mechanism for quiescing")
Cc: sta...@dpdk.org
>>
>> With the commit below, this patch will apply cleanly on 18.11.
>>
>> Seems ok to me to add below commit, wdyt?
>
> If I'm reading it correctly, the move is for an internal data structure
> in librte_eal, so I think it shouldn't be an ABI breakage.
>
> Looks safe to me as well.
>
Thanks, both patches applied.
>> commit e484ccddbe1b41886fef1e445ef2fdfa55086198
>> Author: Nikhil Rao
>> Date: Mon Sep 16 15:31:02 2019 +0530
>>
>> service: avoid false sharing on core state
>>
>>
>> Signed-off-by: Aaron Conole
>
> Reviewed-by: David Marchand
>>>
>>> Applied, thanks.
>>>
>>>
>>> --
>>> David Marchand
>>>
Re: [dpdk-dev] [EXT] RE: [PATCH 2/2] examples/ip_pipeline: fix to use sock id instead of cpuid
Hi Cristian,
Per my debug log, the CPU ID is actually DPDK current core ID on NXP ARM64
platform whose socket ID is always 0.
-Original Message-
From: Dumitrescu, Cristian [mailto:cristian.dumitre...@intel.com]
Sent: Friday, February 14, 2020 7:27 PM
To: Hemant Agrawal ; dev@dpdk.org
Cc: sta...@dpdk.org; Jun Yang
Subject: [EXT] RE: [dpdk-dev] [PATCH 2/2] examples/ip_pipeline: fix to use sock
id instead of cpuid
Caution: EXT Email
> -Original Message-
> From: dev On Behalf Of Hemant Agrawal
> Sent: Wednesday, December 11, 2019 5:26 AM
> To: dev@dpdk.org
> Cc: Dumitrescu, Cristian ;
> sta...@dpdk.org; Jun Yang
> Subject: [dpdk-dev] [PATCH 2/2] examples/ip_pipeline: fix to use sock
> id instead of cpuid
>
> From: Jun Yang
>
> rte_lcore_to_socket_id should be used to convert cpu ID to socket ID.
>
> Fixes: 6bfe74f8c93e ("examples/ip_pipeline: add mempool object")
> Fixes: d75c371e9b46 ("examples/ip_pipeline: add pipeline object")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Jun Yang
> ---
> examples/ip_pipeline/mempool.c | 2 +-
> examples/ip_pipeline/pipeline.c | 10 +-
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/examples/ip_pipeline/mempool.c
> b/examples/ip_pipeline/mempool.c index f5d2a7d108..d7eea85f8f 100644
> --- a/examples/ip_pipeline/mempool.c
> +++ b/examples/ip_pipeline/mempool.c
> @@ -58,7 +58,7 @@ mempool_create(const char *name, struct
> mempool_params *params)
> params->cache_size,
> 0,
> params->buffer_size - sizeof(struct rte_mbuf),
> - params->cpu_id);
> + rte_lcore_to_socket_id(params->cpu_id));
>
> if (m == NULL)
> return NULL;
> diff --git a/examples/ip_pipeline/pipeline.c
> b/examples/ip_pipeline/pipeline.c index b627310a0c..d8df62d785 100644
> --- a/examples/ip_pipeline/pipeline.c
> +++ b/examples/ip_pipeline/pipeline.c
> @@ -94,7 +94,7 @@ pipeline_create(const char *name, struct
> pipeline_params *params)
>
> msgq_req = rte_ring_create(msgq_name,
> PIPELINE_MSGQ_SIZE,
> - params->cpu_id,
> + rte_lcore_to_socket_id(params->cpu_id),
> RING_F_SP_ENQ | RING_F_SC_DEQ);
> if (msgq_req == NULL)
> return NULL;
> @@ -103,7 +103,7 @@ pipeline_create(const char *name, struct
> pipeline_params *params)
>
> msgq_rsp = rte_ring_create(msgq_name,
> PIPELINE_MSGQ_SIZE,
> - params->cpu_id,
> + rte_lcore_to_socket_id(params->cpu_id),
> RING_F_SP_ENQ | RING_F_SC_DEQ);
> if (msgq_rsp == NULL) {
> rte_ring_free(msgq_req); @@ -111,7 +111,7 @@
> pipeline_create(const char *name, struct pipeline_params *params)
> }
>
> pp.name = name;
> - pp.socket_id = (int) params->cpu_id;
> + pp.socket_id = (int) rte_lcore_to_socket_id(params->cpu_id);
> pp.offset_port_id = params->offset_port_id;
>
> p = rte_pipeline_create(&pp);
> @@ -332,7 +332,7 @@ pipeline_port_in_create(const char *pipeline_name,
>
> if (ap) {
> action = rte_port_in_action_create(ap->ap,
> - pipeline->cpu_id);
> + rte_lcore_to_socket_id(pipeline->cpu_id));
> if (action == NULL)
> return -1;
>
> @@ -1002,7 +1002,7 @@ pipeline_table_create(const char *pipeline_name,
>
> if (ap) {
> action = rte_table_action_create(ap->ap,
> - pipeline->cpu_id);
> + rte_lcore_to_socket_id(pipeline->cpu_id));
> if (action == NULL)
> return -1;
>
> --
> 2.17.1
NACK.
This is incorrect, probably a misunderstanding: the params->cpu_id is already
the CPU socket ID (passed as parameter), and not the core ID. For core ID, we
typically use variable names as core_id or lcore_id, and never cpu_id.
[dpdk-dev] L3fwd-power queue utilization issue
Hi, I'm trying to run l3fwd-power application for 2 Port with queue. Always only queue 1 of port 0 and port 1 are utilized. CPU C-state, hpet are enabled, ports are binded to igb_uio. Tried with NIC's x772 (10 GbE) and XXV710(25 GbE), Observed same behavior. I am observing the below output: */root/comms/dpdk/examples/l3fwd-power/build/l3fwd-power -l 2,3,4,5 -n 6 --socket-mem 512,0 -w 17:00.0 -w 17:00.1 -- -p 0x3 --config '(0,0,2),(0,1,3),(1,0,4),(1,1,5)' -P* EAL: Detected 48 lcore(s) EAL: Detected 1 NUMA nodes EAL: Multi-process socket /var/run/dpdk/l3fwd/mp_socket EAL: Probing VFIO support... EAL: PCI device :17:00.0 on NUMA socket 0 EAL: probe driver: 8086:158b net_i40e EAL: PCI device :17:00.1 on NUMA socket 0 EAL: probe driver: 8086:158b net_i40e Promiscuous mode selected POWER: Attempting to initialise ACPI cpufreq power management... POWER: Power management governor of lcore 2 has been set to user space successfully POWER: Initialized successfully for lcore 2 power management POWER: Power management governor of lcore 3 has been set to user space successfully POWER: Initialized successfully for lcore 3 power management POWER: Power management governor of lcore 4 has been set to user space successfully POWER: Initialized successfully for lcore 4 power management POWER: Power management governor of lcore 5 has been set to user space successfully POWER: Initialized successfully for lcore 5 power management Initializing port 0 ... Creating queues: nb_rxq=2 nb_txq=4... Port 0 modified RSS hash function based on hardware support,requested:0x20820 configured:0x820 Address:00:E0:ED:96:2B:AA, Allocated mbuf pool on socket 0 Initializing rx queues on lcore 2 ... rxq=0,0,0 Initializing rx queues on lcore 3 ... rxq=0,1,0 Initializing rx queues on lcore 4 ... rxq=1,0,0 Initializing rx queues on lcore 5 ... rxq=1,1,0 Checking link status.done Port 0 Link Up - speed 25000 Mbps - full-duplex Port 1 Link Up - speed 25000 Mbps - full-duplex L3FWD_POWER: entering main loop on lcore 3 L3FWD_POWER: -- lcoreid=3 portid=0 rxqueueid=1 L3FWD_POWER: entering main loop on lcore 4 L3FWD_POWER: -- lcoreid=4 portid=1 rxqueueid=0 L3FWD_POWER: entering main loop on lcore 5 L3FWD_POWER: -- lcoreid=5 portid=1 rxqueueid=1 EAL: Event already been added. L3FWD_POWER: entering main loop on lcore 2 L3FWD_POWER: -- lcoreid=2 portid=0 rxqueueid=0 EAL: Event already been added. L3FWD_POWER: lcore 3 sleeps until interrupt triggers L3FWD_POWER: lcore 4 sleeps until interrupt triggers L3FWD_POWER: lcore 5 sleeps until interrupt triggers L3FWD_POWER: lcore 2 sleeps until interrupt triggers L3FWD_POWER: lcore 3 is waked up from rx interrupt on port 0 queue 1 L3FWD_POWER: lcore 3 sleeps until interrupt triggers L3FWD_POWER: lcore 5 is waked up from rx interrupt on port 1 queue 1 L3FWD_POWER: lcore 5 sleeps until interrupt triggers I would appreciate it if some expert can shade a light on this. Thanks & Regards, Soumen
Re: [dpdk-dev] [RFC] meter: fix ABI break due to experimental tag removal
On Fri, Feb 14, 2020 at 11:36:34AM +, Bruce Richardson wrote: > On Thu, Feb 13, 2020 at 09:40:40PM -0500, Neil Horman wrote: > > On Thu, Feb 13, 2020 at 05:40:43PM +, Ray Kinsella wrote: > > > > > > > > > On 05/02/2020 11:32, Neil Horman wrote: > > > > On Wed, Feb 05, 2020 at 11:04:29AM +0100, Luca Boccassi wrote: > > > >> On Tue, 2020-02-04 at 07:02 -0500, Neil Horman wrote: > > > But if we can do the versioning in the master, LTS can backport it > > > and can have mature version of that API in LTS without breaking > > > the existing users. > > > > > > >>> > > > >>> But why bother? The only thing you've changed is the version > > > >>> tagging. Its ok to leave that alone in LTS, you just cant change > > > >>> it. > > > >>> > > > >>> Thats part of the burden of an LTS release, it will have some drift > > > >>> from the upstream head, because you have to keep things stable. So > > > >>> you stabilize the upstream ABI version for this API and just never > > > >>> backport it to the current LTS release. > > > >> > > > >> Hi, > > > >> > > > >> A customer (OVS) explicitly and specifically requested backporting > > > >> the symbol change to 19.11, as they don't want to enable > > > >> experimental APIs in their releases. I replied that it would only be > > > >> acceptable with aliasing to keep compatibility, and Ferruh very > > > >> kindly did the work to implement that. > > > >> > > > > but, thats part of the agreement, no? You can't always have new > > > > features and stability at the same time. > > > > > > > > I get that this is an odd corner case, because strictly speaking you > > > > could waive the ABI change that libabigail is reporting, and most > > > > application users (like OVS) could get away with it, because their > > > > application does all the right things to make it ok, but I don't > > > > think you can make a decsion like this for all users based on the > > > > request of a single user. > > > > > > > > It seems like the right thing is for OVS to augment their build time > > > > configuration to allow developers to select the ability to use > > > > experimental apis at compile time, and then the decision is placed in > > > > the hands of end users. > > > > > > So this is not isolated case right ... it is common from API's to > > > graduate from experimental to mature, we _want_ that to happen, we > > > _want_ APIs to mature. > > > > > Sure, I can absolutely agree with that, though I would suggest that the > > maturity of the ABI is orthogonal to its labeling as such (more on that > > below) > > > > > I am worried what you are proposing will encourage a behavior whereby > > > maintainers to wait until the declaration of the next major ABI version > > > to make these symbol changes, causing these kinds of changes to queue > > > up for that release. > > > > > I think you're probably right about that, and would make the agrument > > that thats perfectly fine (again I'll clarify below) > > > > > And you would have to ask why? In the case of a reasonably mature API, > > > there will be no functional or signature change - its mature! So what > > > is the harm of providing an alias back to Experimental until the next > > > ABI version is declared? > > > > > From a philosophical standpoint, there is absoluely no harm, and I don't > > think anyone would disagree, the harm comes from the details of the > > implementation, as you've noted. > > > > > So while yes, you are 100% right - experimental mean no guarantees. > > > But if the API is baked, it is not going to change, so I don't see the > > > harm. > > > > > > We don't want the unnecessary triumph of policy over pragmatism. > > > > > I would make the converse argument here. While I agree that when an API > > is mature, theres no point in calling it experimental anymore, I would > > also suggest that, if an API is mature, and not expected to change, > > theres no harm in leaving its version tag as experimental for an LTS > > release. This is what I was referring to above. Once an application > > developer has done the work to integrate an API from DPDK into its > > application, that work is done. If the API remains stable, then I > > honestly don't know that they care that the version label is EXPERIMENTAL > > versus 20.11 or 20.05 or whatever. They care about the API being stable > > more so than its version label. As such, it seemsreasonable to me to > > have developers queue their migration of experimental APIs to official > > versioned APIs at the next major release deliniation point. > > > > I'd welcome counter arguments, but it seems pretty natural to me to make > > these sorts of changes at the major release mark. People using > > experimantal apis have already implicity agreed to manage changes to > > them, so if we just hold it stable in an LTS release (and don't update > > the version label), its just gravy for them. > > > The counter argument that I see is that while the experime
Re: [dpdk-dev] [RFC] meter: fix ABI break due to experimental tag removal
On Fri, Feb 14, 2020 at 03:48:48PM -0500, Neil Horman wrote: > On Fri, Feb 14, 2020 at 11:36:34AM +, Bruce Richardson wrote: > > On Thu, Feb 13, 2020 at 09:40:40PM -0500, Neil Horman wrote: > > > On Thu, Feb 13, 2020 at 05:40:43PM +, Ray Kinsella wrote: > > > > > > > > > > > > On 05/02/2020 11:32, Neil Horman wrote: > > > > > On Wed, Feb 05, 2020 at 11:04:29AM +0100, Luca Boccassi wrote: > > > > >> On Tue, 2020-02-04 at 07:02 -0500, Neil Horman wrote: > > > > But if we can do the versioning in the master, LTS can backport it > > > > and can have mature version of that API in LTS without breaking > > > > the existing users. > > > > > > > > >>> > > > > >>> But why bother? The only thing you've changed is the version > > > > >>> tagging. Its ok to leave that alone in LTS, you just cant change > > > > >>> it. > > > > >>> > > > > >>> Thats part of the burden of an LTS release, it will have some drift > > > > >>> from the upstream head, because you have to keep things stable. So > > > > >>> you stabilize the upstream ABI version for this API and just never > > > > >>> backport it to the current LTS release. > > > > >> > > > > >> Hi, > > > > >> > > > > >> A customer (OVS) explicitly and specifically requested backporting > > > > >> the symbol change to 19.11, as they don't want to enable > > > > >> experimental APIs in their releases. I replied that it would only be > > > > >> acceptable with aliasing to keep compatibility, and Ferruh very > > > > >> kindly did the work to implement that. > > > > >> > > > > > but, thats part of the agreement, no? You can't always have new > > > > > features and stability at the same time. > > > > > > > > > > I get that this is an odd corner case, because strictly speaking you > > > > > could waive the ABI change that libabigail is reporting, and most > > > > > application users (like OVS) could get away with it, because their > > > > > application does all the right things to make it ok, but I don't > > > > > think you can make a decsion like this for all users based on the > > > > > request of a single user. > > > > > > > > > > It seems like the right thing is for OVS to augment their build time > > > > > configuration to allow developers to select the ability to use > > > > > experimental apis at compile time, and then the decision is placed in > > > > > the hands of end users. > > > > > > > > So this is not isolated case right ... it is common from API's to > > > > graduate from experimental to mature, we _want_ that to happen, we > > > > _want_ APIs to mature. > > > > > > > Sure, I can absolutely agree with that, though I would suggest that the > > > maturity of the ABI is orthogonal to its labeling as such (more on that > > > below) > > > > > > > I am worried what you are proposing will encourage a behavior whereby > > > > maintainers to wait until the declaration of the next major ABI version > > > > to make these symbol changes, causing these kinds of changes to queue > > > > up for that release. > > > > > > > I think you're probably right about that, and would make the agrument > > > that thats perfectly fine (again I'll clarify below) > > > > > > > And you would have to ask why? In the case of a reasonably mature API, > > > > there will be no functional or signature change - its mature! So what > > > > is the harm of providing an alias back to Experimental until the next > > > > ABI version is declared? > > > > > > > From a philosophical standpoint, there is absoluely no harm, and I don't > > > think anyone would disagree, the harm comes from the details of the > > > implementation, as you've noted. > > > > > > > So while yes, you are 100% right - experimental mean no guarantees. > > > > But if the API is baked, it is not going to change, so I don't see the > > > > harm. > > > > > > > > We don't want the unnecessary triumph of policy over pragmatism. > > > > > > > I would make the converse argument here. While I agree that when an API > > > is mature, theres no point in calling it experimental anymore, I would > > > also suggest that, if an API is mature, and not expected to change, > > > theres no harm in leaving its version tag as experimental for an LTS > > > release. This is what I was referring to above. Once an application > > > developer has done the work to integrate an API from DPDK into its > > > application, that work is done. If the API remains stable, then I > > > honestly don't know that they care that the version label is EXPERIMENTAL > > > versus 20.11 or 20.05 or whatever. They care about the API being stable > > > more so than its version label. As such, it seemsreasonable to me to > > > have developers queue their migration of experimental APIs to official > > > versioned APIs at the next major release deliniation point. > > > > > > I'd welcome counter arguments, but it seems pretty natural to me to make > > > these sorts of changes at the major release mark. People using > > > experimantal
Re: [dpdk-dev] [PATCH 3/7] vfio/pci: Introduce VF token
On Thu, 13 Feb 2020 19:35:16 +0100 Cornelia Huck wrote: > On Thu, 13 Feb 2020 10:23:21 -0700 > Alex Williamson wrote: > > > On Thu, 13 Feb 2020 12:46:54 +0100 > > Cornelia Huck wrote: > > > > > On Tue, 11 Feb 2020 16:05:42 -0700 > > > Alex Williamson wrote: > > > > > > > If we enable SR-IOV on a vfio-pci owned PF, the resulting VFs are not > > > > fully isolated from the PF. The PF can always cause a denial of > > > > service to the VF, if not access data passed through the VF directly. > > > > This is why vfio-pci currently does not bind to PFs with SR-IOV enabled > > > > and does not provide access itself to enabling SR-IOV on a PF. The > > > > IOMMU grouping mechanism might allow us a solution to this lack of > > > > isolation, however the deficiency isn't actually in the DMA path, so > > > > much as the potential cooperation between PF and VF devices. Also, > > > > if we were to force VFs into the same IOMMU group as the PF, we severely > > > > limit the utility of having independent drivers managing PFs and VFs > > > > with vfio. > > > > > > > > Therefore we introduce the concept of a VF token. The token is > > > > implemented as a UUID and represents a shared secret which must be set > > > > by the PF driver and used by the VF drivers in order to access a vfio > > > > device file descriptor for the VF. The ioctl to set the VF token will > > > > be provided in a later commit, this commit implements the underlying > > > > infrastructure. The concept here is to augment the string the user > > > > passes to match a device within a group in order to retrieve access to > > > > the device descriptor. For example, rather than passing only the PCI > > > > device name (ex. ":03:00.0") the user would also pass a vf_token > > > > UUID (ex. "2ab74924-c335-45f4-9b16-8569e5b08258"). The device match > > > > string therefore becomes: > > > > > > > > ":03:00.0 vf_token=2ab74924-c335-45f4-9b16-8569e5b08258" > > > > > > > > This syntax is expected to be extensible to future options as well, with > > > > the standard being: > > > > > > > > "$DEVICE_NAME $OPTION1=$VALUE1 $OPTION2=$VALUE2" > > > > > > Is this designed to be an AND condition? (I read it as such.) > > > > Not sure I understand, the device name is always required for > > compatibility, then zero or more key/value pairs may be needed > > depending on the vfio bus driver and device requirements. I'm not > > suggesting that the user would pass multiple vf_token= options and the > > implementation here would only parse the first. I'm really only > > suggesting the parsing format we'd use for multiple options, I'm not > > trying to dictate how a bus driver might make use of them. Does that > > make sense, should I change some wording? > > Not multiple vf_token= options, but multiple, different options. > > E.g. we have something like "$NAME foo=xyz bar=zyx". What is supposed > to happen? > > - both the foo= and bar= values have to give a match > - either foo= or bar= have to match > - if foo= doesn't match, try bar= > - foo= and bar= are ignored, if not applicable I'm not sure how we can make generic predictions like that, as soon as we start adding options we risk having two options that are incompatible, or one deprecates another. > (My understanding is that $NAME matching continues to be mandatory?) Yes, there can still be multiple devices per group, so the user needs to ask for a device by name. > What should happen for vf_token= is reasonably clear, but I'm wondering > about further extensions, as you already talk about it. It's gotten a bit more fuzzy for me as I've been working on the next iteration. For instance, if we reject rather than ignore unknown options, should we also reject a vf_token= option when it isn't needed? For example, if a user provides a vf_token= option because they think they know the PF driver, but the PF is actually managed by an in-kernel host driver, it seems like that should fail. So it seems that sets a user mindset that if the vf_token= isn't rejected that it's used, so rather than ignoring a vf_token= option when opening a PF with no VF users, should providing that value actually be a mechanism for setting the VF token? If it is, do we need VFIO_DEVICE_FEATURE? I still like VFIO_DEVICE_FEATURE from the aspect that the user doesn't commit to using a VF token when they open a device, they can set or change it later, but clearly the functionality has an overlap. I'm also tempted to look whether there's something we could do with cgroups to imply this relationship, but I know very little there and we'd want to be careful not to impose a namespace beyond this PF/VF collaboration idea. > > > > The device name must be first and option=value pairs are separated by > > > > spaces. > > > > > > > > The vf_token option is only required for VFs where the PF device is > > > > bound to vfio-pci. There is no change for PFs using existing host > > > > drivers. > > > > > > > >
Re: [dpdk-dev] [PATCH] event/octeontx2: remove WFE from dualslot dequeue
Hi Pavan, > -Original Message- > From: pbhagavat...@marvell.com > Sent: Friday, February 14, 2020 2:45 PM > To: jer...@marvell.com; Pavan Nikhilesh > Cc: Gavin Hu ; dev@dpdk.org > Subject: [dpdk-dev] [PATCH] event/octeontx2: remove WFE from dualslot > dequeue > > From: Pavan Nikhilesh > > Each workslot is always bound to a specific lcore there is no multi-core > contention to cause cache trashing as a result it is safe to remove the > WFE. Also, in dual workslot dequeue work will mostlikely be available on > the pair workslot making WFE impractical. Does SSO still signal EVENTI to exit from WFE? Then the core ignore it? Can this be disabled as WFE is removed? > > Signed-off-by: Pavan Nikhilesh > --- > > Also, this in-turn reduces the branch misses > > Before: > 0 > arm_spe_0/ts_enable=1,pct_enable=1,pa_enable=1,branch_filter=1,jitter=1, > min_latency=0/ > 0 dummy:u > 0 llc-miss > 0 tlb-miss > 853 branch-miss > 0 remote-access > 0 l1d-miss > > After: > 0 > arm_spe_0/ts_enable=1,pct_enable=1,pa_enable=1,branch_filter=1,jitter=1, > min_latency=0/ > 0 dummy:u > 0 llc-miss > 0 tlb-miss > 250 branch-miss > 0 remote-access > 0 l1d-miss > > WFE Data: > > 0x4C40 - WFI_WFE_WAIT_CYCLES - Number of cycles waiting at a WFI or > WFE instruction. > > - WFE Cycles before the patch for Dual workslot > #perf stat -C 20 -e r4C40 sleep 1 > Performance counter stats for 'CPU(s) 20': > >264 r4C40 >1.002494168 seconds time elapsed > > - WFE Cycles for single workslot > #perf stat -C 20 -e r4C40 sleep 1 > Performance counter stats for 'CPU(s) 20': > >908,778,351 r4C40 >1.002598253 seconds time elapsed > > drivers/event/octeontx2/otx2_worker_dual.h | 6 +- > 1 file changed, 1 insertion(+), 5 deletions(-) > > diff --git a/drivers/event/octeontx2/otx2_worker_dual.h > b/drivers/event/octeontx2/otx2_worker_dual.h > index 5134e3d52..c88420eb4 100644 > --- a/drivers/event/octeontx2/otx2_worker_dual.h > +++ b/drivers/event/octeontx2/otx2_worker_dual.h > @@ -29,11 +29,7 @@ otx2_ssogws_dual_get_work(struct > otx2_ssogws_state *ws, > rte_prefetch_non_temporal(lookup_mem); > #ifdef RTE_ARCH_ARM64 > asm volatile( > - "ldr %[tag], [%[tag_loc]]\n" > - "ldr %[wqp], [%[wqp_loc]]\n" > - "tbz %[tag], 63, done%= \n" > - "sevl\n" > - "rty%=: wfe \n" > + "rty%=: \n" > "ldr %[tag], [%[tag_loc]]\n" > "ldr %[wqp], [%[wqp_loc]]\n" > "tbnz %[tag], 63, rty%= \n" > -- > 2.17.1
Re: [dpdk-dev] [PATCH] event/dpaa2: set number of order sequeuences
On Thu, Feb 13, 2020 at 3:44 PM Nipun Gupta wrote: > > Hi Jerin, > > This patch (bug fix) is required for RC3. > Do you have any comments/concerns on this? No. Applied to dpdk-next-eventdev/master. Thanks. > Thanks, > Nipun > > > -Original Message- > > From: Hemant Agrawal > > Sent: Thursday, February 13, 2020 3:09 PM > > To: Nipun Gupta ; dev@dpdk.org > > Cc: Jerin Jacob Kollanukkaran ; sta...@dpdk.org; > > Nipun Gupta > > Subject: RE: [PATCH] event/dpaa2: set number of order sequeuences > > > > Acked-by: Hemant Agrawal
Re: [dpdk-dev] [PATCH] examples/l2fwd-event: fix return value handling from API
On Mon, Feb 3, 2020 at 10:44 AM Pavan Nikhilesh Bhagavatula
wrote:
>
> >Subject: [PATCH] examples/l2fwd-event: fix return value handling from
> >API
> >
> >Patch fixes coverity issues which handles return values from API
> >calling.
> >
> >Coverity issue: 350588
> >Coverity issue: 350594
> >Coverity issue: 350598
> >Coverity issue: 350599
> >
> >Fixes: 3b5476db4823 ("examples/l2fwd-event: setup event queue and
> >port")
Cc: sta...@dpdk.org
> >Signed-off-by: Sunil Kumar Kori
>
> Acked-by: Pavan Nikhilesh
>
Applied to dpdk-next-eventdev/master. Thanks.
Re: [dpdk-dev] [PATCH] doc: fix service core mask used in l3fwd example
On Fri, Feb 7, 2020 at 11:04 AM wrote:
>
> From: Pavan Nikhilesh
>
> Service core mask should be a hexadecimal value rather than a range of
> lcores.
>
> Bugzilla ID: 392
> Fixes: 55499896d91a ("doc: add event mode to l3fwd guide")
>
> Signed-off-by: Pavan Nikhilesh
Applied to dpdk-next-eventdev/master. Thanks.
> ---
> doc/guides/sample_app_ug/l3_forward.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/doc/guides/sample_app_ug/l3_forward.rst
> b/doc/guides/sample_app_ug/l3_forward.rst
> index 153e46893..07c8d4493 100644
> --- a/doc/guides/sample_app_ug/l3_forward.rst
> +++ b/doc/guides/sample_app_ug/l3_forward.rst
> @@ -166,7 +166,7 @@ scheduler. Following is the sample command:
>
> .. code-block:: console
>
> -./build/l3fwd -l 0-7 -s 0-3 -n 4 --vdev event_sw0 -- -p 0x3
> --mode=eventdev --eventq-sched=ordered
> +./build/l3fwd -l 0-7 -s 0xf -n 4 --vdev event_sw0 -- -p 0x3
> --mode=eventdev --eventq-sched=ordered
>
> In case of eventdev mode, *--config* option is not used for ethernet port
> configuration. Instead each ethernet port will be configured with mentioned
> --
> 2.17.1
>
Re: [dpdk-dev] [PATCH] examples/ipsec-secgw: extend inline session to non AES-GCM
> This patch extends creation of inline session to all the algorithms.
> Previously the inline session was enabled only for AES-GCM cipher.
>
> Fixes: 3a690d5a65e2 ("examples/ipsec-secgw: fix first packet with inline
> crypto")
>
> Signed-off-by: Ankur Dwivedi
> ---
> examples/ipsec-secgw/sa.c | 26 --
> 1 file changed, 12 insertions(+), 14 deletions(-)
Acked-by: Anoob Joseph
Re: [dpdk-dev] [PATCH] app/eventdev: fix test pipeline meson build
On Mon, Feb 3, 2020 at 10:23 AM wrote:
>
> From: Pavan Nikhilesh
>
> Add missing pipeline test to meson build.
>
> Fixes: 2ff67267b049 ("app/eventdev: build with meson")
Cc: sta...@dpdk.org
>
> Signed-off-by: Pavan Nikhilesh
Acked-by: Jerin Jacob
Applied to dpdk-next-eventdev/master. Thanks.
> ---
> app/test-eventdev/meson.build | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/app/test-eventdev/meson.build b/app/test-eventdev/meson.build
> index 7ff2b786c..9e588d9ec 100644
> --- a/app/test-eventdev/meson.build
> +++ b/app/test-eventdev/meson.build
> @@ -10,5 +10,8 @@ sources = files('evt_main.c',
> 'test_order_queue.c',
> 'test_perf_common.c',
> 'test_perf_atq.c',
> - 'test_perf_queue.c')
> + 'test_perf_queue.c',
> + 'test_pipeline_common.c',
> + 'test_pipeline_atq.c',
> + 'test_pipeline_queue.c')
> deps += 'eventdev'
> --
> 2.17.1
>
