[dpdk-dev] [PATCH] lib/librte_ethdev: Error checking for stats mapping

2018-07-10 Thread Kiran Kumar
With current implementation, we are not checking for queue_id range
and stat_idx range in stats mapping function. This patch will add
check for queue_id and stat_idx range.

Fixes: 5de201df892 ("ethdev: add stats per queue")

Signed-off-by: Kiran Kumar 
---
 lib/librte_ethdev/rte_ethdev.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index a9977df..0849016 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -2457,6 +2457,16 @@ set_queue_stats_mapping(uint16_t port_id, uint16_t 
queue_id, uint8_t stat_idx,
dev = &rte_eth_devices[port_id];
 
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->queue_stats_mapping_set, 
-ENOTSUP);
+
+   if (is_rx && (queue_id >= dev->data->nb_rx_queues))
+   return -EINVAL;
+
+   if (!is_rx && (queue_id >= dev->data->nb_tx_queues))
+   return -EINVAL;
+
+   if (stat_idx >= RTE_ETHDEV_QUEUE_STAT_CNTRS)
+   return -EINVAL;
+
return (*dev->dev_ops->queue_stats_mapping_set)
(dev, queue_id, stat_idx, is_rx);
 }
-- 
2.7.4



[dpdk-dev] [PATCH] net/thunderx: Block sq door writes on zero pkts

2018-07-11 Thread Kiran Kumar
With current code, we are performing sq door writes even with 0 pkts.
this will create pressure on register bus. This patch will block these
writes.

Fixes: 1c421f18e0 ("net/thunderx: add single and multi-segment Tx")

Signed-off-by: Kiran Kumar 
---
 drivers/net/thunderx/nicvf_rxtx.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/net/thunderx/nicvf_rxtx.c 
b/drivers/net/thunderx/nicvf_rxtx.c
index 72305d9..8075a8e 100644
--- a/drivers/net/thunderx/nicvf_rxtx.c
+++ b/drivers/net/thunderx/nicvf_rxtx.c
@@ -162,12 +162,14 @@ nicvf_xmit_pkts(void *tx_queue, struct rte_mbuf 
**tx_pkts, uint16_t nb_pkts)
free_desc -= TX_DESC_PER_PKT;
}
 
-   sq->tail = tail;
-   sq->xmit_bufs += i;
-   rte_wmb();
+   if (likely(i)) {
+   sq->tail = tail;
+   sq->xmit_bufs += i;
+   rte_wmb();
 
-   /* Inform HW to xmit the packets */
-   nicvf_addr_write(sq->sq_door, i * TX_DESC_PER_PKT);
+   /* Inform HW to xmit the packets */
+   nicvf_addr_write(sq->sq_door, i * TX_DESC_PER_PKT);
+   }
return i;
 }
 
-- 
2.7.4



[dpdk-dev] [PATCH v2] net/thunderx: avoid sq door bell writes on zero packets

2018-07-11 Thread Kiran Kumar
Avoid sq door bell write on zero packet case to reduce additional
traffic on register bus.

Fixes: 1c421f18e0 ("net/thunderx: add single and multi-segment Tx")
Cc: sta...@dpdk.org

Signed-off-by: Kiran Kumar 
---
 v2 Changes:
 - changed summery and description.
 - added same optimization to nicvf_xmit_pkts_multiseg

 drivers/net/thunderx/nicvf_rxtx.c | 24 ++--
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/drivers/net/thunderx/nicvf_rxtx.c 
b/drivers/net/thunderx/nicvf_rxtx.c
index 72305d9..6e075e2 100644
--- a/drivers/net/thunderx/nicvf_rxtx.c
+++ b/drivers/net/thunderx/nicvf_rxtx.c
@@ -162,12 +162,14 @@ nicvf_xmit_pkts(void *tx_queue, struct rte_mbuf 
**tx_pkts, uint16_t nb_pkts)
free_desc -= TX_DESC_PER_PKT;
}

-   sq->tail = tail;
-   sq->xmit_bufs += i;
-   rte_wmb();
+   if (likely(i)) {
+   sq->tail = tail;
+   sq->xmit_bufs += i;
+   rte_wmb();

-   /* Inform HW to xmit the packets */
-   nicvf_addr_write(sq->sq_door, i * TX_DESC_PER_PKT);
+   /* Inform HW to xmit the packets */
+   nicvf_addr_write(sq->sq_door, i * TX_DESC_PER_PKT);
+   }
return i;
 }

@@ -218,12 +220,14 @@ nicvf_xmit_pkts_multiseg(void *tx_queue, struct rte_mbuf 
**tx_pkts,
}
}

-   sq->tail = tail;
-   sq->xmit_bufs += used_bufs;
-   rte_wmb();
+   if (likely(used_desc)) {
+   sq->tail = tail;
+   sq->xmit_bufs += used_bufs;
+   rte_wmb();

-   /* Inform HW to xmit the packets */
-   nicvf_addr_write(sq->sq_door, used_desc);
+   /* Inform HW to xmit the packets */
+   nicvf_addr_write(sq->sq_door, used_desc);
+   }
return i;
 }

--
2.7.4



[dpdk-dev] [PATCH v2] ethdev: check queue stats mapping input arguments

2018-07-11 Thread Kiran Kumar
With current implementation, we are not checking for queue_id range
and stat_idx range in stats mapping function. This patch will add
check for queue_id and stat_idx range.

Fixes: 5de201df892 ("ethdev: add stats per queue")

Signed-off-by: Kiran Kumar 
Acked-by: Andrew Rybchenko 
---
 v2 changes:
 - changed summery

 lib/librte_ethdev/rte_ethdev.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index a9977df..0849016 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -2457,6 +2457,16 @@ set_queue_stats_mapping(uint16_t port_id, uint16_t 
queue_id, uint8_t stat_idx,
dev = &rte_eth_devices[port_id];

RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->queue_stats_mapping_set, 
-ENOTSUP);
+
+   if (is_rx && (queue_id >= dev->data->nb_rx_queues))
+   return -EINVAL;
+
+   if (!is_rx && (queue_id >= dev->data->nb_tx_queues))
+   return -EINVAL;
+
+   if (stat_idx >= RTE_ETHDEV_QUEUE_STAT_CNTRS)
+   return -EINVAL;
+
return (*dev->dev_ops->queue_stats_mapping_set)
(dev, queue_id, stat_idx, is_rx);
 }
--
2.7.4



[dpdk-dev] [PATCH] kni: fix kni rx fifo producer synchronization

2018-08-09 Thread Kiran Kumar
With existing code in kni_fifo_put, rx_q values are not being updated
before updating fifo_write. While reading rx_q in kni_net_rx_normal,
This is causing the sync issue on other core. So adding a write
barrier to make sure the values being synced before updating fifo_write.

Fixes: 3fc5ca2f6352 ("kni: initial import")

Signed-off-by: Kiran Kumar 
---
 lib/librte_kni/rte_kni_fifo.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/librte_kni/rte_kni_fifo.h b/lib/librte_kni/rte_kni_fifo.h
index ac26a8c..4d6b33e 100644
--- a/lib/librte_kni/rte_kni_fifo.h
+++ b/lib/librte_kni/rte_kni_fifo.h
@@ -39,6 +39,7 @@ kni_fifo_put(struct rte_kni_fifo *fifo, void **data, unsigned 
num)
fifo->buffer[fifo_write] = data[i];
fifo_write = new_write;
}
+   rte_smp_wmb();
fifo->write = fifo_write;
return i;
 }
-- 
2.7.4



[dpdk-dev] [PATCH v2] kni: fix kni Rx fifo producer synchronization

2018-08-16 Thread Kiran Kumar
With existing code in kni_fifo_put, rx_q values are not being updated
before updating fifo_write. While reading rx_q in kni_net_rx_normal,
This is causing the sync issue on other core. So adding a write
barrier to make sure the values being synced before updating fifo_write.

Fixes: 3fc5ca2f6352 ("kni: initial import")

Signed-off-by: Kiran Kumar 
Acked-by: Jerin Jacob 
---
 v2 changes:
- Changed rx in headline
 lib/librte_kni/rte_kni_fifo.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/librte_kni/rte_kni_fifo.h b/lib/librte_kni/rte_kni_fifo.h
index ac26a8c..4d6b33e 100644
--- a/lib/librte_kni/rte_kni_fifo.h
+++ b/lib/librte_kni/rte_kni_fifo.h
@@ -39,6 +39,7 @@ kni_fifo_put(struct rte_kni_fifo *fifo, void **data, unsigned 
num)
fifo->buffer[fifo_write] = data[i];
fifo_write = new_write;
}
+   rte_smp_wmb();
fifo->write = fifo_write;
return i;
 }
--
2.7.4



[dpdk-dev] [PATCH] kni: add IOVA va support for kni

2018-09-27 Thread Kiran Kumar
With current KNI implementation kernel module will work only in
IOVA=PA mode. This patch will add support for kernel module to work
with IOVA=VA mode.

The idea is to maintain a mapping in KNI module between user pages and
kernel pages and in fast path perform a lookup in this table and get
the kernel virtual address for corresponding user virtual address.

In IOVA=VA mode, the memory allocated to the pool is physically
and virtually contiguous. We will take advantage of this and create a
mapping in the kernel.In kernel we need mapping for queues
(tx_q, rx_q,... slow path) and mbuf memory (fast path).

At the KNI init time, in slow path we will create a mapping for the
queues and mbuf using get_user_pages similar to af_xdp. Using pool
memory base address, we will create a page map table for the mbuf,
which we will use in the fast path for kernel page translation.

At KNI init time, we will pass the base address of the pool and size of
the pool to kernel. In kernel, using get_user_pages API, we will get
the pages with size PAGE_SIZE and store the mapping and start address
of user space in a table.

In fast path for any user address perform PAGE_SHIFT
(user_addr >> PAGE_SHIFT) and subtract the start address from this value,
we will get the index of the kernel page with in the page map table.
Adding offset to this kernel page address, we will get the kernel address
for this user virtual address.

For example user pool base address is X, and size is S that we passed to
kernel. In kernel we will create a mapping for this using get_user_pages.
Our page map table will look like [Y, Y+PAGE_SIZE, Y+(PAGE_SIZE*2) ]
and user start page will be U (we will get it from X >> PAGE_SHIFT).

For any user address Z we will get the index of the page map table using
((Z >> PAGE_SHIFT) - U). Adding offset (Z & (PAGE_SIZE - 1)) to this
address will give kernel virtual address.

Signed-off-by: Kiran Kumar 
---
 kernel/linux/kni/kni_dev.h|  37 +++
 kernel/linux/kni/kni_misc.c   | 211 +-
 kernel/linux/kni/kni_net.c| 112 --
 lib/librte_eal/linuxapp/eal/eal.c |   9 -
 .../eal/include/exec-env/rte_kni_common.h |   8 +
 lib/librte_kni/rte_kni.c  |  21 ++
 6 files changed, 363 insertions(+), 35 deletions(-)

diff --git a/kernel/linux/kni/kni_dev.h b/kernel/linux/kni/kni_dev.h
index 6275ef27f..6a92da497 100644
--- a/kernel/linux/kni/kni_dev.h
+++ b/kernel/linux/kni/kni_dev.h
@@ -29,10 +29,47 @@
 
 #define MBUF_BURST_SZ 32
 
+struct iova_page_info {
+   /* User to kernel page table map, used for
+* fast path lookup
+*/
+   struct mbuf_page {
+   void *addr;
+   } *page_map;
+
+   /* Page mask */
+   u64 page_mask;
+
+   /* Start page for user address */
+   u64 start_page;
+
+   struct page_info {
+   /* Physical pages returned by get_user_pages */
+   struct page **pgs;
+
+   /* Number of Pages returned by get_user_pages */
+   u32 npgs;
+   } page_info;
+
+   /* Queue info */
+   struct page_info tx_q;
+   struct page_info rx_q;
+   struct page_info alloc_q;
+   struct page_info free_q;
+   struct page_info req_q;
+   struct page_info resp_q;
+   struct page_info sync_va;
+};
+
 /**
  * A structure describing the private information for a kni device.
  */
 struct kni_dev {
+   /* Page info for IOVA=VA mode */
+   struct iova_page_info va_info;
+   /* IOVA mode 0 = PA, 1 = VA */
+   uint8_t iova_mode;
+
/* kni list */
struct list_head list;
 
diff --git a/kernel/linux/kni/kni_misc.c b/kernel/linux/kni/kni_misc.c
index fa69f8e63..2627c1f69 100644
--- a/kernel/linux/kni/kni_misc.c
+++ b/kernel/linux/kni/kni_misc.c
@@ -197,6 +197,117 @@ kni_dev_remove(struct kni_dev *dev)
return 0;
 }
 
+static void
+kni_unpin_pages(struct page_info *mem)
+{
+   u32 i;
+
+   /* Set the user pages as dirty, so that these pages will not be
+* allocated to other applications until we release them.
+*/
+   for (i = 0; i < mem->npgs; i++) {
+   struct page *page = mem->pgs[i];
+
+   set_page_dirty_lock(page);
+   put_page(page);
+   }
+
+   kfree(mem->pgs);
+   mem->pgs = NULL;
+}
+
+static void
+kni_clean_queue(struct page_info *mem)
+{
+   if (mem->pgs) {
+   set_page_dirty_lock(mem->pgs[0]);
+   put_page(mem->pgs[0]);
+   kfree(mem->pgs);
+   mem->pgs = NULL;
+   }
+}
+
+static void
+kni_cleanup_iova(struct iova_page_info *mem)
+{
+   kni_unpin_pages(&mem->page_info);
+   kfree(mem->page_map);
+   mem->page_map = NULL;
+
+   kni_clean_queue(&mem->tx_q);
+   kni_clean_queue(&mem->rx_q);
+   kni_clean_queue(&mem-&g

[dpdk-dev] [PATCH] drivers/bonding: fix bond mac address reset

2018-05-23 Thread Kiran Kumar
Currently when resetting bond mac address, we are getting the
persisted mac address from slave info considering primary port
as index. But we need to compare the port id from slave info
with the primary port to get the primary slave index and get
the persisted mac address. Without this fix, persisted mac addr
will be zero and rte_eth_dev_default_mac_addr_set will fail.

Fixes: a45b288ef21a ("bond: support link status polling")

Signed-off-by: Kiran Kumar 
---
 drivers/net/bonding/rte_eth_bond_api.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/net/bonding/rte_eth_bond_api.c 
b/drivers/net/bonding/rte_eth_bond_api.c
index d558df8b9..d1a110ec9 100644
--- a/drivers/net/bonding/rte_eth_bond_api.c
+++ b/drivers/net/bonding/rte_eth_bond_api.c
@@ -716,9 +716,21 @@ rte_eth_bond_mac_address_reset(uint16_t bonded_port_id)
internals->user_defined_mac = 0;
 
if (internals->slave_count > 0) {
+   int slave_port;
+   /* Get the primary slave location based on the primary port
+* number as, while slave_add(), we will keep the primary
+* slave based on slave_count,but not based on the primary port.
+*/
+   for (slave_port = 0; slave_port < internals->slave_count;
+slave_port++) {
+   if (internals->slaves[slave_port].port_id ==
+   internals->primary_port)
+   break;
+   }
+
/* Set MAC Address of Bonded Device */
if (mac_address_set(bonded_eth_dev,
-   
&internals->slaves[internals->primary_port].persisted_mac_addr)
+   &internals->slaves[slave_port].persisted_mac_addr)
!= 0) {
RTE_BOND_LOG(ERR, "Failed to set MAC address on bonded 
device");
return -1;
-- 
2.17.0



RE: [EXT] [PATCH] graph: fix node shrink

2023-01-19 Thread Kiran Kumar Kokkilagadda



> -Original Message-
> From: David Marchand 
> Sent: 19 January 2023 04:03 PM
> To: dev@dpdk.org
> Cc: sta...@dpdk.org; Jerin Jacob Kollanukkaran ; Kiran
> Kumar Kokkilagadda ; Nithin Kumar Dabilpuram
> ; Pavan Nikhilesh Bhagavatula
> 
> Subject: [EXT] [PATCH] graph: fix node shrink
> 
> External Email
> 
> --
> If the node id check failed, graph_lock was not taken before releasing.
> 
> Fixes: c59dac2ca14a ("graph: implement node operations")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: David Marchand 

Acked-by: Kiran Kumar Kokkilagadda 

> ---
>  lib/graph/node.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/lib/graph/node.c b/lib/graph/node.c index fc6345de07..149414dcd9
> 100644
> --- a/lib/graph/node.c
> +++ b/lib/graph/node.c
> @@ -300,16 +300,16 @@ rte_node_edge_shrink(rte_node_t id, rte_edge_t
> size)
>   if (node->id == id) {
>   if (node->nb_edges < size) {
>   rte_errno = E2BIG;
> - goto fail;
> + } else {
> + node->nb_edges = size;
> + rc = size;
>   }
> - node->nb_edges = size;
> - rc = size;
>   break;
>   }
>   }
> 
> -fail:
>   graph_spinlock_unlock();
> +fail:
>   return rc;
>  }
> 
> --
> 2.39.0



Re: [dpdk-dev] [EXT] [PATCH 1/2] graph: fix memory leak

2021-04-22 Thread Kiran Kumar Kokkilagadda



> -Original Message-
> From: Min Hu (Connor) 
> Sent: Thursday, April 22, 2021 5:22 PM
> To: dev@dpdk.org
> Cc: ferruh.yi...@intel.com; Jerin Jacob Kollanukkaran ;
> Kiran Kumar Kokkilagadda 
> Subject: [EXT] [PATCH 1/2] graph: fix memory leak
> 
> External Email
> 
> --
> From: HongBo Zheng 
> 
> Fix function 'stats_mem_populate' return without free dynamic memory
> referenced by 'stats'.
> 
> Fixes: af1ae8b6a32c ("graph: implement stats")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: HongBo Zheng 
> Signed-off-by: Min Hu (Connor) 
> ---
>  lib/librte_graph/graph_stats.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/librte_graph/graph_stats.c b/lib/librte_graph/graph_stats.c 
> index
> 125e08d..f698bb3 100644
> --- a/lib/librte_graph/graph_stats.c
> +++ b/lib/librte_graph/graph_stats.c
> @@ -174,7 +174,7 @@ stats_mem_populate(struct rte_graph_cluster_stats
> **stats_in,
>   cluster->stat.hz = rte_get_timer_hz();
>   node = graph_node_id_to_ptr(graph, id);
>   if (node == NULL)
> - SET_ERR_JMP(ENOENT, err, "Failed to find node %s in graph
> %s",
> + SET_ERR_JMP(ENOENT, free, "Failed to find node %s in graph
> %s",
>   graph_node->node->name, graph->name);
>   cluster->nodes[cluster->nb_nodes++] = node;
> 
> @@ -183,6 +183,8 @@ stats_mem_populate(struct rte_graph_cluster_stats
> **stats_in,
>   *stats_in = stats;
> 
>   return 0;
> +free:
> + free(stats);
>  err:
>   return -rte_errno;
>  }
> --
> 2.7.4


Reviewed-by: Kiran Kumar K 



Re: [dpdk-dev] [EXT] [PATCH 2/2] graph: fix dereferencing null pointer

2021-04-22 Thread Kiran Kumar Kokkilagadda



> -Original Message-
> From: Min Hu (Connor) 
> Sent: Thursday, April 22, 2021 5:22 PM
> To: dev@dpdk.org
> Cc: ferruh.yi...@intel.com; Jerin Jacob Kollanukkaran ;
> Kiran Kumar Kokkilagadda 
> Subject: [EXT] [PATCH 2/2] graph: fix dereferencing null pointer
> 
> External Email
> 
> --
> From: HongBo Zheng 
> 
> In function 'stats_mem_init', pointer 'stats' should be confirmed not null 
> before
> memset it.
> 
> Fixes: af1ae8b6a32c ("graph: implement stats")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: HongBo Zheng 
> Signed-off-by: Min Hu (Connor) 
> ---
>  lib/librte_graph/graph_stats.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/librte_graph/graph_stats.c b/lib/librte_graph/graph_stats.c 
> index
> f698bb3..bdc8652 100644
> --- a/lib/librte_graph/graph_stats.c
> +++ b/lib/librte_graph/graph_stats.c
> @@ -119,8 +119,8 @@ stats_mem_init(struct cluster *cluster,
>   cluster_node_size = RTE_ALIGN(cluster_node_size,
> RTE_CACHE_LINE_SIZE);
> 
>   stats = realloc(NULL, sz);
> - memset(stats, 0, sz);
>   if (stats) {
> + memset(stats, 0, sz);
>   stats->fn = fn;
>   stats->cluster_node_size = cluster_node_size;
>   stats->max_nodes = 0;
> --
> 2.7.4

Reviewed-by: Kiran Kumar K 



RE: [EXTERNAL] [PATCH v6] graph: expose node context as pointers

2024-07-12 Thread Kiran Kumar Kokkilagadda



> -Original Message-
> From: Robin Jarry 
> Sent: Friday, July 5, 2024 8:23 PM
> To: dev@dpdk.org; Jerin Jacob ; Kiran Kumar
> Kokkilagadda ; Nithin Kumar Dabilpuram
> ; Zhirun Yan 
> Subject: [EXTERNAL] [PATCH v6] graph: expose node context as pointers
> 
> In some cases, the node context data is used to store two pointers because
> the data is larger than the reserved 16 bytes. Having to define intermediate
> structures just to be able to cast is tedious. And without intermediate
> structures, casting 
> In some cases, the node context data is used to store two pointers because
> the data is larger than the reserved 16 bytes. Having to define intermediate
> structures just to be able to cast is tedious. And without intermediate
> structures, casting to opaque pointers is hard without violating strict 
> aliasing
> rules.
> 
> Add an unnamed union to allow storing opaque pointers in the node
> context. Unfortunately, aligning an unnamed union that contains an array
> produces inconsistent results between C and C++. To preserve ABI/API
> compatibility in both C and C++, move all fast-path area fields into an
> unnamed struct which is itself cache aligned. Use __rte_cache_aligned to
> preserve existing alignment on architectures where cache lines are 128 bytes.
> 
> Add a static assert to ensure that the fast path area does not grow beyond a
> 64 bytes cache line.
> 
> Signed-off-by: Robin Jarry 
> ---

Acked-by: Kiran Kumar Kokkilagadda 

> 
> Notes:
> v6:
> 
> * Fix ABI breakage on arm64 (and all platforms that have
> RTE_CACHE_LINE_SIZE=128).
> * This patch will cause CI failures without libabigail 2.5. See this 
> commit
>   https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__sourceware.org_git_-3Fp-3Dlibabigail.git-3Ba-3Dcommitdiff-3Bh-
> 3Df821c2be3fff2047ef8fc436f6f02301812d166f&d=DwIDAg&c=nKjWec2b6R0m
> OyPaz7xtfQ&r=owEKckYY4FTmil1Z6oBURwkTThyuRbLAY9LdfiaT6HA&m=p2InA
> hlxVf3SXbWbwMoGbsA2ylexBEm_WKDY6mf88Lgp6hbAD5UNuKGkFiO0F8vV&
> s=mtRUGLkylM_33OiTJTBoxFQNDQh6p7xIyNwmDu9GgTk&e=
>   for more details.
> 
> v5:
> 
> * Helper functions to hide casting proved to be harder than expected.
>   Naive casting may even be impossible without breaking strict aliasing
>   rules. The only other option would be to use explicit memcpy calls.
> * Unnamed union tentative again. As suggested by Tyler (thank you!),
>   using an intermediate unnamed struct to carry the alignment produces
>   consistent ABI in C and C++.
> * Also, Tyler (thank you!) suggested that the fast path area alignment
>   size may be incorrect for architectures where the cache line is not 64
>   bytes. There will be a 64 bytes hole in the structure at the end of
>   the unnamed struct before the zero length next nodes array. Use
>   __rte_cache_min_aligned to preserve existing alignment.
> 
> v4:
> 
> * Replaced the unnamed union with helper inline functions.
> 
> v3:
> 
> * Added __extension__ to the unnamed struct inside the union.
> * Fixed C++ header checks.
> * Replaced alignas() with an explicit static_assert.
> 
>  lib/graph/rte_graph_worker_common.h | 29 +
>  1 file changed, 21 insertions(+), 8 deletions(-)
> 
> diff --git a/lib/graph/rte_graph_worker_common.h
> b/lib/graph/rte_graph_worker_common.h
> index 36d864e2c14e..8d8956fa 100644
> --- a/lib/graph/rte_graph_worker_common.h
> +++ b/lib/graph/rte_graph_worker_common.h
> @@ -12,7 +12,9 @@
>   * process, enqueue and move streams of objects to the next nodes.
>   */
> 
> +#include 
>  #include 
> +#include 
> 
>  #include 
>  #include 
> @@ -111,14 +113,21 @@ struct __rte_cache_aligned rte_node {
>   } dispatch;
>   };
>   /* Fast path area  */
> + __extension__ struct __rte_cache_aligned {
>  #define RTE_NODE_CTX_SZ 16
> - alignas(RTE_CACHE_LINE_SIZE) uint8_t ctx[RTE_NODE_CTX_SZ]; /**<
> Node Context. */
> - uint16_t size;  /**< Total number of objects available. */
> - uint16_t idx;   /**< Number of objects used. */
> - rte_graph_off_t off;/**< Offset of node in the graph reel. */
> - uint64_t total_cycles;  /**< Cycles spent in this node. */
> - uint64_t total_calls;   /**< Calls done to this node. */
> - uint64_t total_objs;/**< Objects processed by this node. */
> + union {
> + uint8_t ctx[RTE_NODE_CTX_SZ];
> + __extension__ struct {
> + void *ctx_ptr;
> + void *ctx_ptr2;
> +

RE: [PATCH v4 2/5] graph: add node fastpath error counters

2024-08-21 Thread Kiran Kumar Kokkilagadda



> -Original Message-
> From: pbhagavat...@marvell.com 
> Sent: Friday, August 16, 2024 8:39 PM
> To: Jerin Jacob ; Nithin Kumar Dabilpuram
> ; Kiran Kumar Kokkilagadda
> ; zhirun@intel.com; Zhirun Yan
> 
> Cc: dev@dpdk.org; Pavan Nikhilesh Bhagavatula 
> Subject: [PATCH v4 2/5] graph: add node fastpath error counters
> 
> From: Pavan Nikhilesh 
> 
> Add node fastpath error counters advertised during node registration.
> 
> Signed-off-by: Pavan Nikhilesh 
> ---
Acked-by: Kiran Kumar Kokkilagadda 

>  lib/graph/graph_populate.c  | 20 ++--
>  lib/graph/graph_private.h   |  2 ++
>  lib/graph/rte_graph_worker_common.h |  1 +
>  3 files changed, 21 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/graph/graph_populate.c b/lib/graph/graph_populate.c index
> ed596a7711..9c4c919e14 100644
> --- a/lib/graph/graph_populate.c
> +++ b/lib/graph/graph_populate.c
> @@ -39,6 +39,15 @@ graph_fp_mem_calc_size(struct graph *graph)
>   /* Pointer to next nodes(edges) */
>   sz += sizeof(struct rte_node *) * graph_node->node->nb_edges;
>   }
> + sz = RTE_ALIGN(sz, RTE_CACHE_LINE_SIZE);
> + graph->errors_start = sz;
> + /* For 0..N node objects with error counters */
> + STAILQ_FOREACH(graph_node, &graph->node_list, next) {
> + if (graph_node->node->errs == NULL)
> + continue;
> + sz = RTE_ALIGN(sz, RTE_CACHE_LINE_SIZE);
> + sz += sizeof(uint64_t) * graph_node->node->errs->nb_errors;
> + }
> 
>   graph->mem_sz = sz;
>   return sz;
> @@ -64,6 +73,7 @@ graph_header_popluate(struct graph *_graph)  static void
> graph_nodes_populate(struct graph *_graph)  {
> + rte_graph_off_t err_off = _graph->errors_start;
>   rte_graph_off_t off = _graph->nodes_start;
>   struct rte_graph *graph = _graph->graph;
>   struct graph_node *graph_node;
> @@ -99,6 +109,12 @@ graph_nodes_populate(struct graph *_graph)
>->adjacency_list[count]
>->node->name[0];
> 
> + if (graph_node->node->errs != NULL) {
> + node->err_off = err_off - off;
> + err_off += sizeof(uint64_t) * graph_node->node->errs-
> >nb_errors;
> + err_off = RTE_ALIGN(err_off, RTE_CACHE_LINE_SIZE);
> + }
> +
>   off += sizeof(struct rte_node *) * nb_edges;
>   off = RTE_ALIGN(off, RTE_CACHE_LINE_SIZE);
>   node->next = off;
> @@ -158,7 +174,7 @@ graph_node_nexts_populate(struct graph *_graph)  }
> 
>  static int
> -graph_src_nodes_populate(struct graph *_graph)
> +graph_src_nodes_offset_populate(struct graph *_graph)
>  {
>   struct rte_graph *graph = _graph->graph;
>   struct graph_node *graph_node;
> @@ -193,7 +209,7 @@ graph_fp_mem_populate(struct graph *graph)
>   graph_pcap_init(graph);
>   graph_nodes_populate(graph);
>   rc = graph_node_nexts_populate(graph);
> - rc |= graph_src_nodes_populate(graph);
> + rc |= graph_src_nodes_offset_populate(graph);
> 
>   return rc;
>  }
> diff --git a/lib/graph/graph_private.h b/lib/graph/graph_private.h index
> e663b04d8b..01921b254c 100644
> --- a/lib/graph/graph_private.h
> +++ b/lib/graph/graph_private.h
> @@ -103,6 +103,8 @@ struct graph {
>   /**< Memzone to store graph data. */
>   rte_graph_off_t nodes_start;
>   /**< Node memory start offset in graph reel. */
> + rte_graph_off_t errors_start;
> + /**< Node error memory start offset in graph reel. */
>   rte_node_t src_node_count;
>   /**< Number of source nodes in a graph. */
>   struct rte_graph *graph;
> diff --git a/lib/graph/rte_graph_worker_common.h
> b/lib/graph/rte_graph_worker_common.h
> index 36d864e2c1..fa59d40f57 100644
> --- a/lib/graph/rte_graph_worker_common.h
> +++ b/lib/graph/rte_graph_worker_common.h
> @@ -110,6 +110,7 @@ struct __rte_cache_aligned rte_node {
>   uint64_t total_sched_fail; /**< Number of scheduled
> failure. */
>   } dispatch;
>   };
> + rte_graph_off_t err_off; /**< Offset to error counters. */
>   /* Fast path area  */
>  #define RTE_NODE_CTX_SZ 16
>   alignas(RTE_CACHE_LINE_SIZE) uint8_t ctx[RTE_NODE_CTX_SZ]; /**<
> Node Context. */
> --
> 2.25.1



RE: [PATCH v4 3/5] graph: add stats for node specific errors

2024-08-21 Thread Kiran Kumar Kokkilagadda



> -Original Message-
> From: pbhagavat...@marvell.com 
> Sent: Friday, August 16, 2024 8:39 PM
> To: Jerin Jacob ; Nithin Kumar Dabilpuram
> ; Kiran Kumar Kokkilagadda
> ; zhirun@intel.com; Zhirun Yan
> 
> Cc: dev@dpdk.org; Pavan Nikhilesh Bhagavatula 
> Subject: [PATCH v4 3/5] graph: add stats for node specific errors
> 
> From: Pavan Nikhilesh 
> 
> Add support for retrieving/printing stats for node specific errors using
> rte_graph_cluster_stats_get().
> 
> Signed-off-by: Pavan Nikhilesh 
> ---
Acked-by: Kiran Kumar Kokkilagadda 

>  lib/graph/graph_stats.c | 79 -
>  lib/graph/rte_graph.h   |  4 +++
>  2 files changed, 82 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/graph/graph_stats.c b/lib/graph/graph_stats.c index
> d71451a17b..1ac0a6797f 100644
> --- a/lib/graph/graph_stats.c
> +++ b/lib/graph/graph_stats.c
> @@ -121,6 +121,25 @@ print_node(FILE *f, const struct
> rte_graph_cluster_node_stats *stat, bool dispat
>   }
>  }
> 
> +static inline void
> +print_err(FILE *f, const struct rte_graph_cluster_node_stats *stat,
> +bool dispatch) {
> + int i;
> +
> + if (dispatch) {
> + for (i = 0; i < stat->node_error_cntrs; i++)
> + fprintf(f,
> + "|\t%-24s|%15s|%-15" PRIu64
> "|%15s|%15s|%15s|%15s|%15s|%11.4s|\n",
> + stat->node_error_desc[i], "", stat-
> >node_error_count[i], "", "", "",
> + "", "", "");
> + } else {
> + for (i = 0; i < stat->node_error_cntrs; i++)
> + fprintf(f, "|\t%-24s|%15s|%-15" PRIu64
> "|%15s|%15.3s|%15.6s|%11.4s|\n",
> + stat->node_error_desc[i], "", stat-
> >node_error_count[i], "", "", "",
> + "");
> + }
> +}
> +
>  static int
>  graph_cluster_stats_cb(bool dispatch, bool is_first, bool is_last, void 
> *cookie,
>  const struct rte_graph_cluster_node_stats *stat) @@ 
> -129,8
> +148,11 @@ graph_cluster_stats_cb(bool dispatch, bool is_first, bool is_last, 
> void
> *cookie,
> 
>   if (unlikely(is_first))
>   print_banner(f, dispatch);
> - if (stat->objs)
> + if (stat->objs) {
>   print_node(f, stat, dispatch);
> + if (stat->node_error_cntrs)
> + print_err(f, stat, dispatch);
> + }
>   if (unlikely(is_last)) {
>   if (dispatch)
>   boarder_model_dispatch();
> @@ -203,6 +225,7 @@ stats_mem_populate(struct rte_graph_cluster_stats
> **stats_in,
>   struct cluster_node *cluster;
>   struct rte_node *node;
>   rte_node_t count;
> + uint8_t i;
> 
>   cluster = stats->clusters;
> 
> @@ -240,6 +263,36 @@ stats_mem_populate(struct rte_graph_cluster_stats
> **stats_in,
>   SET_ERR_JMP(ENOENT, free, "Failed to find node %s in graph
> %s",
>   graph_node->node->name, graph->name);
>   cluster->nodes[cluster->nb_nodes++] = node;
> + if (graph_node->node->errs) {
> + cluster->stat.node_error_cntrs = graph_node->node->errs-
> >nb_errors;
> + cluster->stat.node_error_count = rte_zmalloc_socket(
> + NULL, sizeof(uint64_t) * graph_node->node->errs-
> >nb_errors,
> + RTE_CACHE_LINE_SIZE, stats->socket_id);
> + if (cluster->stat.node_error_count == NULL)
> + SET_ERR_JMP(ENOMEM, free, "Failed to allocate
> memory node %s graph %s",
> + graph_node->node->name, graph->name);
> +
> + cluster->stat.node_error_desc = rte_zmalloc_socket(
> + NULL, sizeof(RTE_NODE_ERROR_DESC_SIZE) *
> graph_node->node->errs->nb_errors,
> + RTE_CACHE_LINE_SIZE, stats->socket_id);
> + if (cluster->stat.node_error_desc == NULL) {
> + rte_free(cluster->stat.node_error_count);
> + SET_ERR_JMP(ENOMEM, free, "Failed to allocate
> memory node %s graph %s",
> + graph_node->node->name, graph->name);
> + }
> +
> + for (i = 0; i < cluster->stat.node_error_cntrs; i++) {
> + if (rte_strscpy(cluster->stat.node_

RE: [PATCH v4 4/5] node: add error stats for ip4 lookup node

2024-08-21 Thread Kiran Kumar Kokkilagadda



> -Original Message-
> From: pbhagavat...@marvell.com 
> Sent: Friday, August 16, 2024 8:39 PM
> To: Jerin Jacob ; Nithin Kumar Dabilpuram
> ; Kiran Kumar Kokkilagadda
> ; zhirun@intel.com; Pavan Nikhilesh
> Bhagavatula ; Wathsala Vithanage
> ; Bruce Richardson
> ; Konstantin Ananyev
> 
> Cc: dev@dpdk.org
> Subject: [PATCH v4 4/5] node: add error stats for ip4 lookup node
> 
> From: Pavan Nikhilesh 
> 
> Add error counters for ip4 LPM lookup failures in ip4_lookup node.
> 
> Signed-off-by: Pavan Nikhilesh 
> ---
Acked-by: Kiran Kumar Kokkilagadda 

>  lib/node/ip4_lookup.c  | 9 +
>  lib/node/ip4_lookup_neon.h | 5 +
>  lib/node/ip4_lookup_sse.h  | 6 ++
>  lib/node/node_private.h| 8 
>  4 files changed, 28 insertions(+)
> 
> diff --git a/lib/node/ip4_lookup.c b/lib/node/ip4_lookup.c index
> 18955971f6..5a7921db75 100644
> --- a/lib/node/ip4_lookup.c
> +++ b/lib/node/ip4_lookup.c
> @@ -86,6 +86,7 @@ ip4_lookup_node_process_scalar(struct rte_graph *graph,
> struct rte_node *node,
>   rc = rte_lpm_lookup(lpm, rte_be_to_cpu_32(ipv4_hdr-
> >dst_addr),
>   &next_hop);
>   next_hop = (rc == 0) ? next_hop : drop_nh;
> + NODE_INCREMENT_ERROR_ID(node, 0, (rc != 0), 1);
> 
>   node_mbuf_priv1(mbuf, dyn)->nh = (uint16_t)next_hop;
>   next_hop = next_hop >> 16;
> @@ -219,11 +220,19 @@ ip4_lookup_node_init(const struct rte_graph *graph,
> struct rte_node *node)
>   return 0;
>  }
> 
> +static struct rte_node_errors ip4_lookup_errors = {
> + .nb_errors = 1,
> + .err_desc = {
> + [0] = "ip4_lookup_error",
> + },
> +};
> +
>  static struct rte_node_register ip4_lookup_node = {
>   .process = ip4_lookup_node_process_scalar,
>   .name = "ip4_lookup",
> 
>   .init = ip4_lookup_node_init,
> + .errs = &ip4_lookup_errors,
> 
>   .nb_edges = RTE_NODE_IP4_LOOKUP_NEXT_PKT_DROP + 1,
>   .next_nodes = {
> diff --git a/lib/node/ip4_lookup_neon.h b/lib/node/ip4_lookup_neon.h index
> d5c8da3719..907c7c955a 100644
> --- a/lib/node/ip4_lookup_neon.h
> +++ b/lib/node/ip4_lookup_neon.h
> @@ -116,6 +116,10 @@ ip4_lookup_node_process_vec(struct rte_graph *graph,
> struct rte_node *node,
>   priv01.u16[4] = result.u16[2];
>   priv23.u16[0] = result.u16[4];
>   priv23.u16[4] = result.u16[6];
> + NODE_INCREMENT_ERROR_ID(node, 0, result.u16[1] ==
> (drop_nh >> 16), 1);
> + NODE_INCREMENT_ERROR_ID(node, 0, result.u16[3] ==
> (drop_nh >> 16), 1);
> + NODE_INCREMENT_ERROR_ID(node, 0, result.u16[5] ==
> (drop_nh >> 16), 1);
> + NODE_INCREMENT_ERROR_ID(node, 0, result.u16[7] ==
> (drop_nh >> 16),
> +1);
> 
>   node_mbuf_priv1(mbuf0, dyn)->u = priv01.u64[0];
>   node_mbuf_priv1(mbuf1, dyn)->u = priv01.u64[1]; @@ -202,6
> +206,7 @@ ip4_lookup_node_process_vec(struct rte_graph *graph, struct
> rte_node *node,
>   &next_hop);
>   next_hop = (rc == 0) ? next_hop : drop_nh;
> 
> + NODE_INCREMENT_ERROR_ID(node, 0, (rc != 0), 1);
>   node_mbuf_priv1(mbuf0, dyn)->nh = (uint16_t)next_hop;
>   next_hop = next_hop >> 16;
>   next0 = (uint16_t)next_hop;
> diff --git a/lib/node/ip4_lookup_sse.h b/lib/node/ip4_lookup_sse.h index
> 74dbf97533..a38131e629 100644
> --- a/lib/node/ip4_lookup_sse.h
> +++ b/lib/node/ip4_lookup_sse.h
> @@ -115,6 +115,11 @@ ip4_lookup_node_process_vec(struct rte_graph *graph,
> struct rte_node *node,
>   /* Perform LPM lookup to get NH and next node */
>   rte_lpm_lookupx4(lpm, dip, dst.u32, drop_nh);
> 
> + NODE_INCREMENT_ERROR_ID(node, 0, dst.u16[1] == (drop_nh
> >> 16), 1);
> + NODE_INCREMENT_ERROR_ID(node, 0, dst.u16[3] == (drop_nh
> >> 16), 1);
> + NODE_INCREMENT_ERROR_ID(node, 0, dst.u16[5] == (drop_nh
> >> 16), 1);
> + NODE_INCREMENT_ERROR_ID(node, 0, dst.u16[7] == (drop_nh
> >> 16), 1);
> +
>   /* Extract next node id and NH */
>   node_mbuf_priv1(mbuf0, dyn)->nh = dst.u32[0] & 0x;
>   next0 = (dst.u32[0] >> 16);
> @@ -206,6 +211,7 @@ ip4_lookup_node_process_vec(struct rte_graph *graph,
> struct rte_node *node,
>   rc = rte_lpm_lookup(lpm, rte_be_to_cpu_32(ipv4_hdr-
> >dst_addr),
>   &next_hop);
>   next_hop = (rc =

RE: [PATCH v4 5/5] node: add error stats for ip4 reassembly node

2024-08-21 Thread Kiran Kumar Kokkilagadda


> -Original Message-
> From: pbhagavat...@marvell.com 
> Sent: Friday, August 16, 2024 8:39 PM
> To: Jerin Jacob ; Nithin Kumar Dabilpuram
> ; Kiran Kumar Kokkilagadda
> ; zhirun@intel.com; Pavan Nikhilesh
> Bhagavatula 
> Cc: dev@dpdk.org
> Subject: [PATCH v4 5/5] node: add error stats for ip4 reassembly node
> 
> From: Pavan Nikhilesh 
> 
> Add reassembly failure error counter for ip4 reassembly node.
> 
> Signed-off-by: Pavan Nikhilesh 
> ---
Acked-by: Kiran Kumar Kokkilagadda 

>  lib/node/ip4_reassembly.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/lib/node/ip4_reassembly.c b/lib/node/ip4_reassembly.c index
> 04823cc596..ab71ef1331 100644
> --- a/lib/node/ip4_reassembly.c
> +++ b/lib/node/ip4_reassembly.c
> @@ -120,6 +120,7 @@ ip4_reassembly_node_process(struct rte_graph *graph,
> struct rte_node *node, void
>   rte_node_next_stream_put(graph, node,
> RTE_NODE_IP4_REASSEMBLY_NEXT_PKT_DROP,
>dr->cnt);
>   idx += dr->cnt;
> + NODE_INCREMENT_ERROR_ID(node, 0, dr->cnt, dr->cnt);
>   dr->cnt = 0;
>   }
> 
> @@ -165,11 +166,19 @@ ip4_reassembly_node_init(const struct rte_graph
> *graph, struct rte_node *node)
>   return 0;
>  }
> 
> +static struct rte_node_errors ip4_reassembly_errors = {
> + .nb_errors = 1,
> + .err_desc = {
> + [0] = "ip4_reassembly_error",
> + },
> +};
> +
>  static struct rte_node_register ip4_reassembly_node = {
>   .process = ip4_reassembly_node_process,
>   .name = "ip4_reassembly",
> 
>   .init = ip4_reassembly_node_init,
> + .errs = &ip4_reassembly_errors,
> 
>   .nb_edges = RTE_NODE_IP4_REASSEMBLY_NEXT_PKT_DROP + 1,
>   .next_nodes = {
> --
> 2.25.1

<>

RE: [EXTERNAL] [PATCH dpdk] graph: make graphviz export more readable

2024-08-28 Thread Kiran Kumar Kokkilagadda



> -Original Message-
> From: Robin Jarry 
> Sent: Wednesday, August 28, 2024 7:12 PM
> To: dev@dpdk.org; Jerin Jacob ; Kiran Kumar Kokkilagadda
> ; Nithin Kumar Dabilpuram
> ; Zhirun Yan 
> Subject: [EXTERNAL] [PATCH dpdk] graph: make graphviz export more readable
> 
> Change the color of arrows leading to sink nodes to dark orange. Remove the
> node oval shape around the sink nodes and make their text dark orange. This
> results in a much more readable output for large graphs. See the link below 
> for an
> example. 
> Change the color of arrows leading to sink nodes to dark orange. Remove the
> node oval shape around the sink nodes and make their text dark orange. This
> results in a much more readable output for large graphs.
> See the link below for an example.
> 
> Link: https://urldefense.proofpoint.com/v2/url?u=https-3A__f.jarry.cc_rte-
> 2Dgraph-
> 2Ddot_ipv6.svg&d=DwIDAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=owEKckYY4FTmil1
> Z6oBURwkTThyuRbLAY9LdfiaT6HA&m=D41w8N-
> HiTO9kFbxr3kWwW4TVmWav2Zozr9byDbHSj7TRx6egfC1ut70K2HKJQ0y&s=0gZZ
> VRoev4w7I_KowoRkSn40vymIJgyxS8vBPgEk90c&e=
> Signed-off-by: Robin Jarry 
> ---

Acked-by: Kiran Kumar Kokkilagadda 

>  lib/graph/graph.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/graph/graph.c b/lib/graph/graph.c index
> d5b8c9f918cf..dff8e690a80d 100644
> --- a/lib/graph/graph.c
> +++ b/lib/graph/graph.c
> @@ -745,7 +745,7 @@ graph_to_dot(FILE *f, struct graph *graph)
>   if (rc < 0)
>   goto end;
>   } else if (graph_node->node->nb_edges == 0) {
> - rc = fprintf(f, " [color=darkorange]");
> + rc = fprintf(f, " [fontcolor=darkorange shape=plain]");
>   if (rc < 0)
>   goto end;
>   }
> @@ -753,9 +753,12 @@ graph_to_dot(FILE *f, struct graph *graph)
>   if (rc < 0)
>   goto end;
>   for (i = 0; i < graph_node->node->nb_edges; i++) {
> + const char *node_attrs = attrs;
> + if (graph_node->adjacency_list[i]->node->nb_edges ==
> 0)
> + node_attrs = " [color=darkorange]";
>   rc = fprintf(f, "\t\"%s\" -> \"%s\"%s;\n", node_name,
>graph_node->adjacency_list[i]->node-
> >name,
> -  attrs);
> +  node_attrs);
>   if (rc < 0)
>   goto end;
>   }
> --
> 2.46.0



Re: [dpdk-dev] [EXT] [PATCH v5 2/3] doc: add flow API features tables

2021-04-08 Thread Kiran Kumar Kokkilagadda



> -Original Message-
> From: Thomas Monjalon 
> Sent: Thursday, April 8, 2021 4:03 AM
> To: dev@dpdk.org
> Cc: ferruh.yi...@intel.com; andrew.rybche...@oktetlabs.ru; Asaf Penso
> ; Ajit Khaparde ; Somnath
> Kotur ; Rahul Lakkireddy
> ; Hemant Agrawal
> ; Sachin Saxena ;
> Jeff Guo ; Haiyue Wang ; John
> Daley ; Hyong Youb Kim ; Gaetan
> Rivet ; Ziyang Xuan ; Xiaoyun
> Wang ; Guoyang Zhou
> ; Min Hu (Connor) ;
> Yisen Zhuang ; Lijun Ou ;
> Beilei Xing ; Jingjing Wu ;
> Qiming Yang ; Qi Zhang ;
> Rosen Xu ; Matan Azrad ; Shahaf
> Shuler ; Viacheslav Ovsiienko ;
> Liron Himi ; Jerin Jacob Kollanukkaran
> ; Nithin Kumar Dabilpuram ;
> Kiran Kumar Kokkilagadda ; Rasesh Mody
> ; Devendra Singh Rawat ;
> Igor Russkikh ; Keith Wiles ;
> Jiawen Wu ; Jian Wang
> 
> Subject: [EXT] [PATCH v5 2/3] doc: add flow API features tables
> 
> External Email
> 
> --
> The NICs overview table lists all supported features per driver.
> There was a single row for "Flow API",
> although rte_flow is composed of many items and actions.
> 
> The row "Flow API" is replaced with two new tables for items and actions.
> 
> Also, since rte_flow is not implemented in all drivers, it would be ugly to 
> add
> empty sections in some files.
> That's why the error message for missing INI section is removed.
> 
> The lists are sorted alphabetically.
> The extra files for some VF and vectorized data paths are not filled.
> 
> Signed-off-by: Asaf Penso 
> Signed-off-by: Thomas Monjalon 

Acked-by: Kiran Kumar Kokkilagadda 

> ---
>  .gitignore |   2 +
>  doc/guides/conf.py |  18 ++--
>  doc/guides/nics/features.rst   |  11 --
>  doc/guides/nics/features/bnxt.ini  |  26 -
>  doc/guides/nics/features/cxgbe.ini |  31 +-
>  doc/guides/nics/features/default.ini   | 116 -
>  doc/guides/nics/features/dpaa2.ini |  19 +++-
>  doc/guides/nics/features/e1000.ini |  14 +++
>  doc/guides/nics/features/enic.ini  |  29 +-
>  doc/guides/nics/features/failsafe.ini  |   1 -
>  doc/guides/nics/features/hinic.ini |  16 ++-
>  doc/guides/nics/features/hns3.ini  |  23 +++-
>  doc/guides/nics/features/hns3_vf.ini   |   1 -
>  doc/guides/nics/features/i40e.ini  |  31 +-
>  doc/guides/nics/features/iavf.ini  |  29 +-
>  doc/guides/nics/features/ice.ini   |  33 +-
>  doc/guides/nics/features/ice_dcf.ini   |   1 -
>  doc/guides/nics/features/igb.ini   |   1 -
>  doc/guides/nics/features/igc.ini   |  12 ++-
>  doc/guides/nics/features/ipn3ke.ini|  15 ++-
>  doc/guides/nics/features/ixgbe.ini |  24 -
>  doc/guides/nics/features/mlx4.ini  |  13 ++-
>  doc/guides/nics/features/mlx5.ini  |  71 -
>  doc/guides/nics/features/mvpp2.ini |  14 +++
>  doc/guides/nics/features/octeontx2.ini |  42 +++-
>  doc/guides/nics/features/octeontx2_vec.ini |   1 -
>  doc/guides/nics/features/octeontx2_vf.ini  |   1 -
>  doc/guides/nics/features/qede.ini  |  11 +-
>  doc/guides/nics/features/sfc.ini   |  35 ++-
>  doc/guides/nics/features/tap.ini   |  15 ++-
>  doc/guides/nics/features/txgbe.ini |  24 -
>  doc/guides/nics/overview.rst   |   8 ++
>  32 files changed, 644 insertions(+), 44 deletions(-)
> 
> diff --git a/.gitignore b/.gitignore
> index f73d93ca53..b19c0717e6 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -3,6 +3,8 @@
> 
>  # ignore generated documentation tables  doc/guides/nics/overview_table.txt
> +doc/guides/nics/rte_flow_actions_table.txt
> +doc/guides/nics/rte_flow_items_table.txt
>  doc/guides/cryptodevs/overview_feature_table.txt
>  doc/guides/cryptodevs/overview_cipher_table.txt
>  doc/guides/cryptodevs/overview_auth_table.txt
> diff --git a/doc/guides/conf.py b/doc/guides/conf.py index
> ec59aeae7e..70213843c1 100644
> --- a/doc/guides/conf.py
> +++ b/doc/guides/conf.py
> @@ -216,14 +216,8 @@ def generate_overview_table(output_filename,
> table_id, section, table_name, titl
>  # Initialize the dict with the default.ini value.
>  ini_data[ini_filename] = valid_features.copy()
> 
> -# Check for a valid ini section.
> +# Check for a section.
>  if not config.has_section(section):
> -print("{}: File '{}' has no [{}] secton".format(warning,
> -ini_filename,
> -

Re: [dpdk-dev] [EXT] [PATCH v7 11/12] net/octeontx2: support port representor flow action

2021-10-19 Thread Kiran Kumar Kokkilagadda



> -Original Message-
> From: Ivan Malov 
> Sent: Wednesday, October 13, 2021 11:05 PM
> To: dev@dpdk.org
> Cc: Ferruh Yigit ; Thomas Monjalon
> ; Ori Kam ; Andrew Rybchenko
> ; Jerin Jacob Kollanukkaran
> ; Nithin Kumar Dabilpuram ;
> Kiran Kumar Kokkilagadda 
> Subject: [EXT] [PATCH v7 11/12] net/octeontx2: support port representor flow
> action
> 
> External Email
> 
> --
> From: Andrew Rybchenko 
> 
> Action PORT_ID implementation assumes ingress only. Its semantics suggests
> that support for equal action PORT_REPRESENTOR be added.
> 
> Signed-off-by: Andrew Rybchenko 


Acked-by: Kiran Kumar Kokkilagadda 


> ---
>  doc/guides/nics/features/octeontx2.ini  |  1 +
>  doc/guides/nics/octeontx2.rst   |  5 -
>  drivers/net/octeontx2/otx2_flow_parse.c | 16 
>  3 files changed, 17 insertions(+), 5 deletions(-)
> 
> diff --git a/doc/guides/nics/features/octeontx2.ini
> b/doc/guides/nics/features/octeontx2.ini
> index fa32bc7890..e0277988d4 100644
> --- a/doc/guides/nics/features/octeontx2.ini
> +++ b/doc/guides/nics/features/octeontx2.ini
> @@ -91,6 +91,7 @@ of_set_vlan_pcp  = Y
>  of_set_vlan_vid  = Y
>  pf   = Y
>  port_id  = Y
> +port_representor = Y
>  queue= Y
>  rss  = Y
>  security = Y
> diff --git a/doc/guides/nics/octeontx2.rst b/doc/guides/nics/octeontx2.rst 
> index
> e35c8116f7..eae32f0afe 100644
> --- a/doc/guides/nics/octeontx2.rst
> +++ b/doc/guides/nics/octeontx2.rst
> @@ -403,10 +403,13 @@ Actions:
> ++-+
> | 12 | RTE_FLOW_ACTION_TYPE_PORT_ID|
> ++-+
> +   | 13 | RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR   |
> +   ++-+
> 
>  .. note::
> 
> -   ``RTE_FLOW_ACTION_TYPE_PORT_ID`` is only supported between PF and its
> VFs.
> +   ``RTE_FLOW_ACTION_TYPE_PORT_ID``,
> ``RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR``
> +   are only supported between PF and its VFs.
> 
>  .. _table_octeontx2_supported_egress_action_types:
> 
> diff --git a/drivers/net/octeontx2/otx2_flow_parse.c
> b/drivers/net/octeontx2/otx2_flow_parse.c
> index 30a232f033..79b92fda8a 100644
> --- a/drivers/net/octeontx2/otx2_flow_parse.c
> +++ b/drivers/net/octeontx2/otx2_flow_parse.c
> @@ -900,7 +900,6 @@ otx2_flow_parse_actions(struct rte_eth_dev *dev,  {
>   struct otx2_eth_dev *hw = dev->data->dev_private;
>   struct otx2_npc_flow_info *npc = &hw->npc_flow;
> - const struct rte_flow_action_port_id *port_act;
>   const struct rte_flow_action_mark *act_mark;
>   const struct rte_flow_action_queue *act_q;
>   const struct rte_flow_action_vf *vf_act; @@ -977,9 +976,18 @@
> otx2_flow_parse_actions(struct rte_eth_dev *dev,
>   break;
> 
>   case RTE_FLOW_ACTION_TYPE_PORT_ID:
> - port_act = (const struct rte_flow_action_port_id *)
> - actions->conf;
> - port_id = port_act->id;
> + case RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR:
> + if (actions->type ==
> RTE_FLOW_ACTION_TYPE_PORT_ID) {
> + const struct rte_flow_action_port_id
> *port_act;
> +
> + port_act = actions->conf;
> + port_id = port_act->id;
> + } else {
> + const struct rte_flow_action_ethdev
> *ethdev_act;
> +
> + ethdev_act = actions->conf;
> + port_id = ethdev_act->port_id;
> + }
>   if (rte_eth_dev_get_name_by_port(port_id, if_name)) {
>   errmsg = "Name not found for output port id";
>   errcode = EINVAL;
> --
> 2.20.1



RE: [EXTERNAL] [PATCH v2] graph: fix does not return the unique id when create graph

2024-05-10 Thread Kiran Kumar Kokkilagadda



> -Original Message-
> From: Gongming Chen 
> Sent: Friday, May 10, 2024 12:26 PM
> To: Jerin Jacob ; Kiran Kumar Kokkilagadda
> ; Nithin Kumar Dabilpuram
> ; yanzhirun_...@163.com
> Cc: dev@dpdk.org; Gongming Chen ;
> sta...@dpdk.org; Fan Yin 
> Subject: [EXTERNAL] [PATCH v2] graph: fix does not return the unique id
> when create graph
> 
> Prioritize security for external emails: Confirm sender and content safety
> before clicking links or opening attachments
> 
> --
> From: Gongming Chen 
> 
> When the order of graph destroy is not the reverse order of create, that is,
> when it is destroyed at will, the newly created graph id will be the same as
> the existing graph id, which is not the expected unique graph id. This graph
> id incorrectly corresponds to multiple graphs.
> 
> Fixes: a91fecc19c5c ("graph: implement create and destroy")
> Cc: sta...@dpdk.org
> 
> Reported-by: Fan Yin 
> Signed-off-by: Gongming Chen 
> Signed-off-by: Fan Yin 
> ---

There is a similar patch from robin in review.
https://patchwork.dpdk.org/project/dpdk/patch/20240326154936.1132201-1-rja...@redhat.com/
I already Acked it. It is ready for merge.



>  lib/graph/graph.c | 163 ++
>  1 file changed, 94 insertions(+), 69 deletions(-)
> 
> diff --git a/lib/graph/graph.c b/lib/graph/graph.c index
> 26f0968a97..b8fecd9c6a 100644
> --- a/lib/graph/graph.c
> +++ b/lib/graph/graph.c
> @@ -19,9 +19,6 @@
> 
>  static struct graph_head graph_list = STAILQ_HEAD_INITIALIZER(graph_list);
>  static rte_spinlock_t graph_lock = RTE_SPINLOCK_INITIALIZER; -static
> rte_graph_t graph_id;
> -
> -#define GRAPH_ID_CHECK(id) ID_CHECK(id, graph_id)
> 
>  /* Private functions */
>  struct graph_head *
> @@ -217,6 +214,46 @@ graph_node_fini(struct graph *graph)
>  graph_node->node-
> >name));
>  }
> 
> +static struct graph *
> +graph_find_by_id(rte_graph_t id)
> +{
> + struct graph *graph;
> +
> + STAILQ_FOREACH(graph, &graph_list, next)
> + if (graph->id == id)
> + return graph;
> + return NULL;
> +}
> +
> +static struct graph *
> +graph_find_by_name(const char *name)
> +{
> + struct graph *graph;
> +
> + STAILQ_FOREACH(graph, &graph_list, next)
> + if (strncmp(graph->name, name, RTE_GRAPH_NAMESIZE) ==
> 0)
> + return graph;
> + return NULL;
> +}
> +
> +static rte_graph_t
> +graph_free_id_find(void)
> +{
> + static rte_graph_t graph_id;
> + if (graph_id == RTE_GRAPH_ID_INVALID)
> + graph_id++;
> +
> + rte_graph_t end_id = graph_id;
> + do {
> + if (!graph_find_by_id(graph_id))
> + return graph_id++;
> + if (++graph_id == RTE_GRAPH_ID_INVALID)
> + graph_id++;
> + } while (graph_id != end_id);
> +
> + return RTE_GRAPH_ID_INVALID;
> +}
> +
>  static struct rte_graph *
>  graph_mem_fixup_node_ctx(struct rte_graph *graph)  { @@ -279,13 +316,12
> @@ rte_graph_model_mcore_dispatch_core_bind(rte_graph_t id, int lcore)  {
>   struct graph *graph;
> 
> - GRAPH_ID_CHECK(id);
>   if (!rte_lcore_is_enabled(lcore))
>   SET_ERR_JMP(ENOLINK, fail, "lcore %d not enabled", lcore);
> 
> - STAILQ_FOREACH(graph, &graph_list, next)
> - if (graph->id == id)
> - break;
> + graph = graph_find_by_id(id);
> + if (!graph)
> + goto fail;
> 
>   if (graph->graph->model != RTE_GRAPH_MODEL_MCORE_DISPATCH)
>   goto fail;
> @@ -309,15 +345,12 @@
> rte_graph_model_mcore_dispatch_core_unbind(rte_graph_t id)  {
>   struct graph *graph;
> 
> - GRAPH_ID_CHECK(id);
> - STAILQ_FOREACH(graph, &graph_list, next)
> - if (graph->id == id)
> - break;
> + graph = graph_find_by_id(id);
> + if (!graph)
> + return;
> 
>   graph->lcore_id = RTE_MAX_LCORE;
>   graph->graph->dispatch.lcore_id = RTE_MAX_LCORE;
> -
> -fail:
>   return;
>  }
> 
> @@ -352,10 +385,8 @@ rte_graph_create(const char *name, struct
> rte_graph_param *prm)
>   SET_ERR_JMP(EINVAL, fail, "Graph name should not be
> NULL");
> 
>   /* Check for existence of duplicate graph */
> - STAILQ_FOREACH(graph, &graph_list, next)
> - if (strncmp(name, graph->name, RTE_GRAPH_NAMESIZE) ==

RE: [EXTERNAL] [PATCH v3] graph: avoid id collisions

2024-06-18 Thread Kiran Kumar Kokkilagadda


From: Robin Jarry 
Sent: Tuesday, June 18, 2024 2:53 PM
To: dev@dpdk.org; Jerin Jacob ; Kiran Kumar Kokkilagadda 
; Nithin Kumar Dabilpuram ; 
Zhirun Yan 
Subject: [EXTERNAL] [PATCH v3] graph: avoid id collisions

The graph id is determined based on a global variable that is incremented every 
time a graph is created, and decremented every time a graph is destroyed. This 
only works if graphs are destroyed in the reverse order in which they have been 
created. 


The graph id is determined based on a global variable that is

incremented every time a graph is created, and decremented every time

a graph is destroyed. This only works if graphs are destroyed in the

reverse order in which they have been created.



The following code produces duplicate graph IDs which can lead to

use-after-free bugs and other undefined behaviours:



  a = rte_graph_create(...); // id=0 graph_id=1

  b = rte_graph_create(...); // id=1 graph_id=2

  rte_graph_destroy(a);  // graph_id=1

  c = rte_graph_create(...); // id=1 graph_id=2 (duplicate with b)

  rte_graph_destroy(c);  // frees memory still used by b



Remove the global counter. Make sure that the graph list is always

ordered by increasing graph ids. When creating a new graph, pick a free

id which is not allocated.



Update unit tests to ensure it works as expected.



Signed-off-by: Robin Jarry mailto:rja...@redhat.com>>



Acked-by: Kiran Kumar Kokkilagadda 
kirankum...@marvell.com<mailto:kirankum...@marvell.com>



Notes:

v3:



* Fixed invalid logic in graph_insert_ordered.

* Updated unit test to ensure head/tail/middle insertion work (the test

  fails before fixing graph_insert_ordered).



 app/test/test_graph.c | 72 

 lib/graph/graph.c | 86 ++-

 2 files changed, 141 insertions(+), 17 deletions(-)



diff --git a/app/test/test_graph.c b/app/test/test_graph.c

index b8409bc60497..2840a25b13b7 100644

--- a/app/test/test_graph.c

+++ b/app/test/test_graph.c

@@ -696,6 +696,77 @@ test_graph_clone(void)

  return ret;

 }



+static int

+test_graph_id_collisions(void)

+{

+   static const char *node_patterns[] = {"test_node_source1", 
"test_node00"};

+   struct rte_graph_param gconf = {

+   .socket_id = SOCKET_ID_ANY,

+   .nb_node_patterns = 2,

+   .node_patterns = node_patterns,

+   };

+   rte_graph_t g1, g2, g3, g4;

+

+   g1 = rte_graph_create("worker1", &gconf);

+   if (g1 == RTE_GRAPH_ID_INVALID) {

+   printf("Graph 1 creation failed with error = %d\n", 
rte_errno);

+   return -1;

+   }

+   g2 = rte_graph_create("worker2", &gconf);

+   if (g2 == RTE_GRAPH_ID_INVALID) {

+   printf("Graph 2 creation failed with error = %d\n", 
rte_errno);

+   return -1;

+   }

+   g3 = rte_graph_create("worker3", &gconf);

+   if (g3 == RTE_GRAPH_ID_INVALID) {

+   printf("Graph 3 creation failed with error = %d\n", 
rte_errno);

+   return -1;

+   }

+   if (g1 == g2 || g2 == g3 || g1 == g3) {

+   printf("Graph ids should be different\n");

+   return -1;

+   }

+   if (rte_graph_destroy(g2) < 0) {

+   printf("Graph 2 suppression failed\n");

+   return -1;

+   }

+   g4 = rte_graph_create("worker4", &gconf);

+   if (g4 == RTE_GRAPH_ID_INVALID) {

+   printf("Graph 4 creation failed with error = %d\n", 
rte_errno);

+   return -1;

+   }

+   if (g1 == g3 || g1 == g4 || g3 == g4) {

+   printf("Graph ids should be different\n");

+   return -1;

+   }

+   g2 = rte_graph_clone(g1, "worker2", &gconf);

+   if (g2 == RTE_GRAPH_ID_INVALID) {

+   printf("Graph 4 creation failed with error = %d\n", 
rte_errno);

+   return -1;

+   }

+   if (g1 == g2 || g1 == g3 || g1 == g4 || g2 == g3 || g2 == g4 || g3 
== g4) {

+   printf("Graph ids should be different\n");

+   return -1;

+   }

+   if (rte_graph_destroy(g1) < 0) {

+   printf("Graph 1 suppression failed\n");

+   return -1;

+   }

+   if (rte_graph_destroy(g2) < 0) {

+  

RE: [EXTERNAL] [PATCH v2] app/graph: fix destination buffer too small

2024-06-24 Thread Kiran Kumar Kokkilagadda


From: Mahmoud Maatuq 
Sent: Tuesday, June 25, 2024 1:31 AM
To: Sunil Kumar Kori ; Rakesh Kudurumalla 
; Nithin Kumar Dabilpuram ; 
Jerin Jacob 
Cc: dev@dpdk.org; Mahmoud Maatuq 
Subject: [EXTERNAL] [PATCH v2] app/graph: fix destination buffer too small

as sizeof(config. rx. mempool_name) is < sizeof(res->mempool) we should copy at 
most sizeof(config. rx. mempool_name) and replace memcpy with strlcpy as 
mempool name is a null terminated string Coverity issue: 415430 Fixes: 
3850cb06ab9c ("app/graph: 


as sizeof(config.rx.mempool_name) is < sizeof(res->mempool) we should

copy at most sizeof(config.rx.mempool_name) and replace memcpy with

strlcpy as mempool name is a null terminated string



Coverity issue: 415430

Fixes: 3850cb06ab9c ("app/graph: add ethdev commands")

Cc: sk...@marvell.com



Signed-off-by: Mahmoud Maatuq 
mailto:mahmoudmatook...@gmail.com>>

---

v2:

* replaced memcpy with strlcpy

---

 app/graph/ethdev.c | 3 ++-

 1 file changed, 2 insertions(+), 1 deletion(-)



diff --git a/app/graph/ethdev.c b/app/graph/ethdev.c

index cfc1b18569..e7a02b40a9 100644

--- a/app/graph/ethdev.c

+++ b/app/graph/ethdev.c

@@ -16,6 +16,7 @@



 #include "ethdev_priv.h"

 #include "module_api.h"

+#include "rte_string_fns.h"



 static const char

 cmd_ethdev_mtu_help[] = "ethdev  mtu ";

@@ -671,7 +672,7 @@ cmd_ethdev_parsed(void *parsed_result, __rte_unused struct 
cmdline *cl, void *da

  memset(&config, 0, sizeof(struct ethdev_config));

  config.rx.n_queues = res->nb_rxq;

  config.rx.queue_size = ETHDEV_RX_DESC_DEFAULT;

-memcpy(config.rx.mempool_name, res->mempool, strlen(res->mempool));

+   strlcpy(config.rx.mempool_name, res->mempool, 
sizeof(config.rx.mempool_name));



Can be changed to strlcpy(config.rx.mempool_name, res->mempool->name, 
sizeof(config.rx.mempool_name)); ?



  config.tx.n_queues = res->nb_txq;

  config.tx.queue_size = ETHDEV_TX_DESC_DEFAULT;

--

2.43.0




RE: [EXTERNAL] [PATCH v2] app/graph: fix destination buffer too small

2024-06-26 Thread Kiran Kumar Kokkilagadda



> -Original Message-
> From: Mahmoud Matook 
> Sent: Thursday, June 27, 2024 1:49 AM
> To: Kiran Kumar Kokkilagadda 
> Cc: Sunil Kumar Kori ; Rakesh Kudurumalla
> ; Nithin Kumar Dabilpuram
> ; Jerin Jacob ;
> dev@dpdk.org
> Subject: Re: [EXTERNAL] [PATCH v2] app/graph: fix destination buffer too
> small
> 
> On 06/25, Kiran Kumar Kokkilagadda wrote: > > > From: Mahmoud Maatuq
>  > Sent: Tuesday, June 25, 2024 1: 31
> AM > To: Sunil Kumar Kori ; Rakesh Kudurumalla
> ; 
> On 06/25, Kiran Kumar Kokkilagadda wrote:
> 
> >
> >
> > From: Mahmoud Maatuq 
> > Sent: Tuesday, June 25, 2024 1:31 AM
> > To: Sunil Kumar Kori ; Rakesh Kudurumalla
> > ; Nithin Kumar Dabilpuram
> > ; Jerin Jacob 
> > Cc: dev@dpdk.org; Mahmoud Maatuq
> 
> > Subject: [EXTERNAL] [PATCH v2] app/graph: fix destination buffer too
> > small
> >
> > as sizeof(config. rx. mempool_name) is < sizeof(res->mempool) we
> > should copy at most sizeof(config. rx. mempool_name) and replace memcpy
> with strlcpy as mempool name is a null terminated string Coverity issue:
> 415430 Fixes: 3850cb06ab9c ("app/graph:
> >
> >
> > as sizeof(config.rx.mempool_name) is < sizeof(res->mempool) we should
> >
> > copy at most sizeof(config.rx.mempool_name) and replace memcpy with
> >
> > strlcpy as mempool name is a null terminated string
> >
> >
> >
> > Coverity issue: 415430
> >
> > Fixes: 3850cb06ab9c ("app/graph: add ethdev commands")
> >
> > Cc: sk...@marvell.com<mailto:sk...@marvell.com>
> >
> >
> >
> > Signed-off-by: Mahmoud Maatuq
> >
> mailto:mahmoudmatook...@gmail.co
> m>>
> >
> > ---

Acked-by: Kiran Kumar Kokkilagadda 


> >
> > v2:
> >
> > * replaced memcpy with strlcpy
> >
> > ---
> >
> >  app/graph/ethdev.c | 3 ++-
> >
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> >
> >
> > diff --git a/app/graph/ethdev.c b/app/graph/ethdev.c
> >
> > index cfc1b18569..e7a02b40a9 100644
> >
> > --- a/app/graph/ethdev.c
> >
> > +++ b/app/graph/ethdev.c
> >
> > @@ -16,6 +16,7 @@
> >
> >
> >
> >  #include "ethdev_priv.h"
> >
> >  #include "module_api.h"
> >
> > +#include "rte_string_fns.h"
> >
> >
> >
> >  static const char
> >
> >  cmd_ethdev_mtu_help[] = "ethdev  mtu ";
> >
> > @@ -671,7 +672,7 @@ cmd_ethdev_parsed(void *parsed_result,
> > __rte_unused struct cmdline *cl, void *da
> >
> >   memset(&config, 0, sizeof(struct ethdev_config));
> >
> >   config.rx.n_queues = res->nb_rxq;
> >
> >   config.rx.queue_size = ETHDEV_RX_DESC_DEFAULT;
> >
> > -memcpy(config.rx.mempool_name, res->mempool, strlen(res-
> >mempool));
> >
> > +   strlcpy(config.rx.mempool_name, res->mempool,
> > + sizeof(config.rx.mempool_name));
> >
> >
> >
> > Can be changed to strlcpy(config.rx.mempool_name, res->mempool-
> >name, sizeof(config.rx.mempool_name)); ?
> 
> mempool field is of type cmdline_fixed_string_t (array of char)
> 

Ok, I over looked the "res" type. 

> >
> >
> >
> >   config.tx.n_queues = res->nb_txq;
> >
> >   config.tx.queue_size = ETHDEV_TX_DESC_DEFAULT;
> >
> > --
> >
> > 2.43.0
> >
> >


RE: [EXTERNAL] [PATCH] graph: enhance export to graphviz

2024-03-22 Thread Kiran Kumar Kokkilagadda



> -Original Message-
> From: Robin Jarry 
> Sent: Wednesday, March 20, 2024 10:41 PM
> To: dev@dpdk.org; Jerin Jacob ; Kiran Kumar
> Kokkilagadda ; Nithin Kumar Dabilpuram
> ; Zhirun Yan 
> Subject: [EXTERNAL] [PATCH] graph: enhance export to graphviz
> 
> Prioritize security for external emails: Confirm sender and content safety
> before clicking links or opening attachments
> 
> --
> * Quote graph name to avoid parsing errors when it contains a dash.
> * Use fixed margin and smaller font for a more compact layout.
> * Use sans-serif font, the default is times new roman which is not the
>   best choice for a packet processing generated graph.
> * Force bold blue border and arrows for source nodes.
> * Force dark orange borders for sink nodes (nodes without next nodes).
> 
> Link: https://urldefense.proofpoint.com/v2/url?u=https-3A__f.jarry.cc_rte-
> 2Dgraph-
> 2Ddot_before.svg&d=DwIDAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=owEKckYY4FT
> mil1Z6oBURwkTThyuRbLAY9LdfiaT6HA&m=pyYDQxlqMplh30E36wiXH6LLReml
> Q19SXfdBaWFn9w76vzq1CZdH-
> MC9xnFF1F73&s=j08NkMjMiHpSAVfucSwMN7c769_JbCqmTlEv-O0LyeQ&e=
> Link: https://urldefense.proofpoint.com/v2/url?u=https-3A__f.jarry.cc_rte-
> 2Dgraph-
> 2Ddot_after.svg&d=DwIDAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=owEKckYY4FTmi
> l1Z6oBURwkTThyuRbLAY9LdfiaT6HA&m=pyYDQxlqMplh30E36wiXH6LLRemlQ1
> 9SXfdBaWFn9w76vzq1CZdH-MC9xnFF1F73&s=dQTT3aUgxo-
> oZVMsw0KJR1UT2Gn3oi9r50TAJdIgJLs&e=
> Signed-off-by: Robin Jarry 

Acked-by: Kiran Kumar Kokkilagadda 

> ---
>  lib/graph/graph.c | 32 +---
>  1 file changed, 25 insertions(+), 7 deletions(-)
> 
> diff --git a/lib/graph/graph.c b/lib/graph/graph.c index
> 26f0968a978d..147bc6c685c5 100644
> --- a/lib/graph/graph.c
> +++ b/lib/graph/graph.c
> @@ -674,25 +674,43 @@ __rte_node_stream_alloc_size(struct rte_graph
> *graph, struct rte_node *node,  static int  graph_to_dot(FILE *f, struct graph
> *graph)  {
> - const char *src_edge_color = " [color=blue]\n";
> - const char *edge_color = "\n";
>   struct graph_node *graph_node;
>   char *node_name;
>   rte_edge_t i;
>   int rc;
> 
> - rc = fprintf(f, "Digraph %s {\n\trankdir=LR;\n", graph->name);
> + rc = fprintf(f, "digraph \"%s\" {\n\trankdir=LR;\n", graph->name);
> + if (rc < 0)
> + goto end;
> +
> + rc = fprintf(f, "\tnode [margin=0.02 fontsize=11 fontname=sans];\n");
>   if (rc < 0)
>   goto end;
> 
>   STAILQ_FOREACH(graph_node, &graph->node_list, next) {
> + const char *attrs = "";
>   node_name = graph_node->node->name;
> +
> + rc = fprintf(f, "\t\"%s\"", node_name);
> + if (rc < 0)
> + goto end;
> + if (graph_node->node->flags & RTE_NODE_SOURCE_F) {
> + attrs = " [color=blue style=bold]";
> + rc = fprintf(f, "%s", attrs);
> + if (rc < 0)
> + goto end;
> + } else if (graph_node->node->nb_edges == 0) {
> + rc = fprintf(f, " [color=darkorange]");
> + if (rc < 0)
> + goto end;
> + }
> + rc = fprintf(f, ";\n");
> + if (rc < 0)
> + goto end;
>   for (i = 0; i < graph_node->node->nb_edges; i++) {
> - rc = fprintf(f, "\t\"%s\"->\"%s\"%s", node_name,
> + rc = fprintf(f, "\t\"%s\" -> \"%s\"%s;\n", node_name,
>graph_node->adjacency_list[i]->node-
> >name,
> -  graph_node->node->flags &
> RTE_NODE_SOURCE_F
> -  ? src_edge_color
> -  : edge_color);
> +  attrs);
>   if (rc < 0)
>   goto end;
>   }
> --
> 2.44.0



RE: [EXTERNAL] [PATCH v2] graph: avoid id collisions

2024-03-26 Thread Kiran Kumar Kokkilagadda



> -Original Message-
> From: Robin Jarry 
> Sent: Tuesday, March 26, 2024 9:20 PM
> To: dev@dpdk.org; Jerin Jacob ; Kiran Kumar
> Kokkilagadda ; Nithin Kumar Dabilpuram
> ; Zhirun Yan 
> Subject: [EXTERNAL] [PATCH v2] graph: avoid id collisions
> 
> Prioritize security for external emails: Confirm sender and content safety
> before clicking links or opening attachments
> 
> --
> The graph id is determined based on a global variable that is incremented
> every time a graph is created, and decremented every time a graph is
> destroyed. This only works if graphs are destroyed in the reverse order in
> which they have been created.
> 
> The following code produces duplicate graph IDs which can lead to use-after-
> free bugs and other undefined behaviours:
> 
>   a = rte_graph_create(...); // id=0 graph_id=1
>   b = rte_graph_create(...); // id=1 graph_id=2
>   rte_graph_destroy(a);  // graph_id=1
>   c = rte_graph_create(...); // id=1 graph_id=2 (duplicate with b)
>   rte_graph_destroy(c);  // frees memory still used by b
> 
> Remove the global counter. Make sure that the graph list is always ordered by
> increasing graph ids. When creating a new graph, pick a free id which is not
> allocated.
> 
> Update unit tests to ensure it works as expected.
> 
> Signed-off-by: Robin Jarry 
> ---

Acked-by: Kiran Kumar Kokkilagadda 

> 
> Notes:
> v2: Added unit test
> 
>  app/test/test_graph.c | 63 +++
>  lib/graph/graph.c | 86 ++-
>  2 files changed, 132 insertions(+), 17 deletions(-)
> 
> diff --git a/app/test/test_graph.c b/app/test/test_graph.c index
> b8409bc60497..c650ac4f57b7 100644
> --- a/app/test/test_graph.c
> +++ b/app/test/test_graph.c
> @@ -696,6 +696,68 @@ test_graph_clone(void)
>   return ret;
>  }
> 
> +static int
> +test_graph_id_collisions(void)
> +{
> + static const char *node_patterns[] = {"test_node_source1",
> "test_node00"};
> + struct rte_graph_param gconf = {
> + .socket_id = SOCKET_ID_ANY,
> + .nb_node_patterns = 2,
> + .node_patterns = node_patterns,
> + };
> + rte_graph_t g1, g2, g3;
> +
> + g1 = rte_graph_create("worker1", &gconf);
> + if (g1 == RTE_GRAPH_ID_INVALID) {
> + printf("Graph 1 creation failed with error = %d\n", rte_errno);
> + return -1;
> + }
> + g2 = rte_graph_create("worker2", &gconf);
> + if (g2 == RTE_GRAPH_ID_INVALID) {
> + printf("Graph 2 creation failed with error = %d\n", rte_errno);
> + return -1;
> + }
> + if (g1 == g2) {
> + printf("Graph ids should be different\n");
> + return -1;
> + }
> + if (rte_graph_destroy(g1) < 0) {
> + printf("Graph 1 suppression failed\n");
> + return -1;
> + }
> + g3 = rte_graph_create("worker3", &gconf);
> + if (g3 == RTE_GRAPH_ID_INVALID) {
> + printf("Graph 3 creation failed with error = %d\n", rte_errno);
> + return -1;
> + }
> + if (g3 == g2) {
> + printf("Graph ids should be different\n");
> + return -1;
> + }
> + g1 = rte_graph_clone(g2, "worker1", &gconf);
> + if (g1 == RTE_GRAPH_ID_INVALID) {
> + printf("Graph 2 clone failed with error = %d\n", rte_errno);
> + return -1;
> + }
> + if (g1 == g2 || g2 == g3 || g1 == g3) {
> + printf("Graph ids should be different\n");
> + return -1;
> + }
> + if (rte_graph_destroy(g1) < 0) {
> + printf("Graph 1 suppression failed\n");
> + return -1;
> + }
> + if (rte_graph_destroy(g2) < 0) {
> + printf("Graph 2 suppression failed\n");
> + return -1;
> + }
> + if (rte_graph_destroy(g3) < 0) {
> + printf("Graph 3 suppression failed\n");
> + return -1;
> + }
> + return 0;
> +}
> +
>  static int
>  test_graph_model_mcore_dispatch_node_lcore_affinity_set(void)
>  {
> @@ -977,6 +1039,7 @@ static struct unit_test_suite graph_testsuite = {
>   TEST_CASE(test_lookup_functions),
>   TEST_CASE(test_create_graph),
>   TEST_CASE(test_graph_clone),
> + TEST_CASE(test_graph_id_collisions),
> 
>   TEST_CASE(test_graph_model_

RE: [EXTERNAL] [PATCH] graph: avoid accessing graph list when getting stats

2024-03-29 Thread Kiran Kumar Kokkilagadda



> -Original Message-
> From: Robin Jarry 
> Sent: Monday, March 25, 2024 9:23 PM
> To: dev@dpdk.org; Jerin Jacob ; Kiran Kumar
> Kokkilagadda ; Nithin Kumar Dabilpuram
> ; Zhirun Yan 
> Subject: [EXTERNAL] [PATCH] graph: avoid accessing graph list when getting
> stats
> 
> Prioritize security for external emails: Confirm sender and content safety
> before clicking links or opening attachments
> 
> --
> In rte_graph_cluster_stats_get, the walk model of the first graph is checked
> to determine if multi-core dispatch specific counters should be updated or
> not. This global list is accessed without any locks.
> 
> If the global list is modified by another thread while
> rte_graph_cluster_stats_get is called, it can result in undefined behaviour.
> 
> Adding a lock would make it impossible to call rte_graph_cluster_stats_get in
> packet processing code paths. Avoid accessing the global list instead by
> storing a bool field in the private rte_graph_cluster_stats structure.
> 
> Also update the default callback to avoid accessing the global list and use a
> different default callback depending on the graph model.
> 
> Signed-off-by: Robin Jarry 
> ---
>  lib/graph/graph_stats.c | 60 ++---
>  1 file changed, 39 insertions(+), 21 deletions(-)
> 
> diff --git a/lib/graph/graph_stats.c b/lib/graph/graph_stats.c index
> 2fb808b21ec5..f8048e08be8a 100644
> --- a/lib/graph/graph_stats.c
> +++ b/lib/graph/graph_stats.c
> @@ -34,6 +34,7 @@ struct __rte_cache_aligned rte_graph_cluster_stats {
>   uint32_t cluster_node_size; /* Size of struct cluster_node */
>   rte_node_t max_nodes;
>   int socket_id;
> + bool dispatch;
>   void *cookie;
>   size_t sz;
> 
> @@ -74,17 +75,16 @@ print_banner_dispatch(FILE *f)  }
> 
>  static inline void
> -print_banner(FILE *f)
> +print_banner(FILE *f, bool dispatch)
>  {
> - if
> (rte_graph_worker_model_get(STAILQ_FIRST(graph_list_head_get())->graph)
> ==
> - RTE_GRAPH_MODEL_MCORE_DISPATCH)
> + if (dispatch)
>   print_banner_dispatch(f);
>   else
>   print_banner_default(f);
>  }
> 
>  static inline void
> -print_node(FILE *f, const struct rte_graph_cluster_node_stats *stat)
> +print_node(FILE *f, const struct rte_graph_cluster_node_stats *stat,
> +bool dispatch)
>  {
>   double objs_per_call, objs_per_sec, cycles_per_call, ts_per_hz;
>   const uint64_t prev_calls = stat->prev_calls; @@ -104,8 +104,7 @@
> print_node(FILE *f, const struct rte_graph_cluster_node_stats *stat)
>   objs_per_sec = ts_per_hz ? (objs - prev_objs) / ts_per_hz : 0;
>   objs_per_sec /= 100;
> 
> - if
> (rte_graph_worker_model_get(STAILQ_FIRST(graph_list_head_get())->graph)
> ==
> - RTE_GRAPH_MODEL_MCORE_DISPATCH) {
> + if (dispatch) {
>   fprintf(f,
>   "|%-31s|%-15" PRIu64 "|%-15" PRIu64 "|%-15" PRIu64
>   "|%-15" PRIu64 "|%-15" PRIu64
> @@ -123,20 +122,17 @@ print_node(FILE *f, const struct
> rte_graph_cluster_node_stats *stat)  }
> 
>  static int
> -graph_cluster_stats_cb(bool is_first, bool is_last, void *cookie,
> +graph_cluster_stats_cb(bool dispatch, bool is_first, bool is_last, void
> +*cookie,
>  const struct rte_graph_cluster_node_stats *stat)  {
>   FILE *f = cookie;
> - int model;
> -
> - model =
> rte_graph_worker_model_get(STAILQ_FIRST(graph_list_head_get())->graph);
> 
>   if (unlikely(is_first))
> - print_banner(f);
> + print_banner(f, dispatch);
>   if (stat->objs)
> - print_node(f, stat);
> + print_node(f, stat, dispatch);
>   if (unlikely(is_last)) {
> - if (model == RTE_GRAPH_MODEL_MCORE_DISPATCH)
> + if (dispatch)
>   boarder_model_dispatch();
>   else
>   boarder();
> @@ -145,6 +141,20 @@ graph_cluster_stats_cb(bool is_first, bool is_last,
> void *cookie,
>   return 0;
>  };
> 
> +static int
> +graph_cluster_stats_cb_rtc(bool is_first, bool is_last, void *cookie,
> +const struct rte_graph_cluster_node_stats *stat) {
> + return graph_cluster_stats_cb(false, is_first, is_last, cookie, stat);
> +};
> +
> +static int
> +graph_cluster_stats_cb_dispatch(bool is_first, bool is_last, void *cookie,
> + const struct rte_graph_cluster_node_stats
> *stat) {
> + return graph

RE: [EXTERNAL] [PATCH v2] graph: avoid accessing graph list when getting stats

2024-04-03 Thread Kiran Kumar Kokkilagadda



> -Original Message-
> From: Robin Jarry 
> Sent: Tuesday, April 2, 2024 2:07 AM
> To: dev@dpdk.org; Jerin Jacob ; Kiran Kumar
> Kokkilagadda ; Nithin Kumar Dabilpuram
> ; Zhirun Yan 
> Subject: [EXTERNAL] [PATCH v2] graph: avoid accessing graph list when getting
> stats
> 
> Prioritize security for external emails: Confirm sender and content safety
> before clicking links or opening attachments
> 
> --
> In rte_graph_cluster_stats_get, the walk model of the first graph is checked
> to determine if multi-core dispatch specific counters should be updated or
> not. This global list is accessed without any locks.
> 
> If the global list is modified by another thread while
> rte_graph_cluster_stats_get is called, it can result in undefined behaviour.
> 
> Adding a lock would make it impossible to call rte_graph_cluster_stats_get in
> packet processing code paths. Avoid accessing the global list instead by
> storing a bool field in the private rte_graph_cluster_stats structure.
> 
> Also update the default callback to avoid accessing the global list and use a
> different default callback depending on the graph model.
> 
> Signed-off-by: Robin Jarry 
> ---

Acked-by: Kiran Kumar Kokkilagadda 


> 
> Notes:
> v2:
> 
> * (kiran) removed unnecessary loop in stats_mem_init.
> 
>  lib/graph/graph_stats.c | 57 ++---
>  1 file changed, 36 insertions(+), 21 deletions(-)
> 
> diff --git a/lib/graph/graph_stats.c b/lib/graph/graph_stats.c index
> 2fb808b21ec5..d71451a17b95 100644
> --- a/lib/graph/graph_stats.c
> +++ b/lib/graph/graph_stats.c
> @@ -34,6 +34,7 @@ struct __rte_cache_aligned rte_graph_cluster_stats {
>   uint32_t cluster_node_size; /* Size of struct cluster_node */
>   rte_node_t max_nodes;
>   int socket_id;
> + bool dispatch;
>   void *cookie;
>   size_t sz;
> 
> @@ -74,17 +75,16 @@ print_banner_dispatch(FILE *f)  }
> 
>  static inline void
> -print_banner(FILE *f)
> +print_banner(FILE *f, bool dispatch)
>  {
> - if
> (rte_graph_worker_model_get(STAILQ_FIRST(graph_list_head_get())->graph)
> ==
> - RTE_GRAPH_MODEL_MCORE_DISPATCH)
> + if (dispatch)
>   print_banner_dispatch(f);
>   else
>   print_banner_default(f);
>  }
> 
>  static inline void
> -print_node(FILE *f, const struct rte_graph_cluster_node_stats *stat)
> +print_node(FILE *f, const struct rte_graph_cluster_node_stats *stat,
> +bool dispatch)
>  {
>   double objs_per_call, objs_per_sec, cycles_per_call, ts_per_hz;
>   const uint64_t prev_calls = stat->prev_calls; @@ -104,8 +104,7 @@
> print_node(FILE *f, const struct rte_graph_cluster_node_stats *stat)
>   objs_per_sec = ts_per_hz ? (objs - prev_objs) / ts_per_hz : 0;
>   objs_per_sec /= 100;
> 
> - if
> (rte_graph_worker_model_get(STAILQ_FIRST(graph_list_head_get())->graph)
> ==
> - RTE_GRAPH_MODEL_MCORE_DISPATCH) {
> + if (dispatch) {
>   fprintf(f,
>   "|%-31s|%-15" PRIu64 "|%-15" PRIu64 "|%-15" PRIu64
>   "|%-15" PRIu64 "|%-15" PRIu64
> @@ -123,20 +122,17 @@ print_node(FILE *f, const struct
> rte_graph_cluster_node_stats *stat)  }
> 
>  static int
> -graph_cluster_stats_cb(bool is_first, bool is_last, void *cookie,
> +graph_cluster_stats_cb(bool dispatch, bool is_first, bool is_last, void
> +*cookie,
>  const struct rte_graph_cluster_node_stats *stat)  {
>   FILE *f = cookie;
> - int model;
> -
> - model =
> rte_graph_worker_model_get(STAILQ_FIRST(graph_list_head_get())->graph);
> 
>   if (unlikely(is_first))
> - print_banner(f);
> + print_banner(f, dispatch);
>   if (stat->objs)
> - print_node(f, stat);
> + print_node(f, stat, dispatch);
>   if (unlikely(is_last)) {
> - if (model == RTE_GRAPH_MODEL_MCORE_DISPATCH)
> + if (dispatch)
>   boarder_model_dispatch();
>   else
>   boarder();
> @@ -145,6 +141,20 @@ graph_cluster_stats_cb(bool is_first, bool is_last,
> void *cookie,
>   return 0;
>  };
> 
> +static int
> +graph_cluster_stats_cb_rtc(bool is_first, bool is_last, void *cookie,
> +const struct rte_graph_cluster_node_stats *stat) {
> + return graph_cluster_stats_cb(false, is_first, is_last, cookie, stat);
> +};
> +
> +static int
> +graph_cluster_stats_cb_dispatch(bool is_first, bool is

Re: [dpdk-dev] [EXT] [PATCH v1 11/12] net/octeontx2: support ethdev flow action

2021-10-04 Thread Kiran Kumar Kokkilagadda



> -Original Message-
> From: Andrew Rybchenko 
> Sent: Friday, October 1, 2021 7:17 PM
> To: Jerin Jacob Kollanukkaran ; Nithin Kumar Dabilpuram
> ; Kiran Kumar Kokkilagadda
> 
> Cc: dev@dpdk.org; Ori Kam ; Thomas Monjalon
> ; Ferruh Yigit ; Ivan Malov
> 
> Subject: [EXT] [PATCH v1 11/12] net/octeontx2: support ethdev flow action
> 
> External Email
> 
> --
> PORT_ID action implementation works for ingress only and has the same
> semantics as ETHDEV action.

Please update the documentation also.


> 
> Signed-off-by: Andrew Rybchenko 
> ---
>  drivers/net/octeontx2/otx2_flow_parse.c | 16 
>  1 file changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/octeontx2/otx2_flow_parse.c
> b/drivers/net/octeontx2/otx2_flow_parse.c
> index 63a33142a5..5dd8464ec9 100644
> --- a/drivers/net/octeontx2/otx2_flow_parse.c
> +++ b/drivers/net/octeontx2/otx2_flow_parse.c
> @@ -900,7 +900,6 @@ otx2_flow_parse_actions(struct rte_eth_dev *dev,  {
>   struct otx2_eth_dev *hw = dev->data->dev_private;
>   struct otx2_npc_flow_info *npc = &hw->npc_flow;
> - const struct rte_flow_action_port_id *port_act;
>   const struct rte_flow_action_count *act_count;
>   const struct rte_flow_action_mark *act_mark;
>   const struct rte_flow_action_queue *act_q; @@ -987,9 +986,18 @@
> otx2_flow_parse_actions(struct rte_eth_dev *dev,
>   break;
> 
>   case RTE_FLOW_ACTION_TYPE_PORT_ID:
> - port_act = (const struct rte_flow_action_port_id *)
> - actions->conf;
> - port_id = port_act->id;
> + case RTE_FLOW_ACTION_TYPE_ETHDEV:
> + if (actions->type ==
> RTE_FLOW_ACTION_TYPE_PORT_ID) {
> + const struct rte_flow_action_port_id
> *port_act;
> +
> + port_act = actions->conf;
> + port_id = port_act->id;
> + } else {
> + const struct rte_flow_action_ethdev
> *ethdev_act;
> +
> + ethdev_act = actions->conf;
> + port_id = ethdev_act->id;
> + }
>   if (rte_eth_dev_get_name_by_port(port_id, if_name)) {
>   errmsg = "Name not found for output port id";
>   errcode = EINVAL;
> --
> 2.30.2



RE: [EXT] [PATCH v1 04/13] graph: add get/set graph worker model APIs

2022-12-05 Thread Kiran Kumar Kokkilagadda



> -Original Message-
> From: Zhirun Yan 
> Sent: 17 November 2022 10:39 AM
> To: dev@dpdk.org; Jerin Jacob Kollanukkaran ; Kiran
> Kumar Kokkilagadda ; Nithin Kumar Dabilpuram
> 
> Cc: cunming.li...@intel.com; haiyue.w...@intel.com; Zhirun Yan
> 
> Subject: [EXT] [PATCH v1 04/13] graph: add get/set graph worker model APIs
> 
> External Email
> 
> --
> Add new get/set APIs to configure graph worker model which is used to
> determine which model will be chosen.
> 
> Signed-off-by: Haiyue Wang 
> Signed-off-by: Cunming Liang 
> Signed-off-by: Zhirun Yan 
> ---
>  lib/graph/rte_graph_worker.h| 51 +
>  lib/graph/rte_graph_worker_common.h | 13 
>  lib/graph/version.map   |  3 ++
>  3 files changed, 67 insertions(+)
> 
> diff --git a/lib/graph/rte_graph_worker.h b/lib/graph/rte_graph_worker.h index
> 54d1390786..a0ea0df153 100644
> --- a/lib/graph/rte_graph_worker.h
> +++ b/lib/graph/rte_graph_worker.h
> @@ -1,5 +1,56 @@
>  #include "rte_graph_model_rtc.h"
> 
> +static enum rte_graph_worker_model worker_model =
> +RTE_GRAPH_MODEL_DEFAULT;
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change, or be removed, without prior
> +notice
> + * Set the graph worker model
> + *
> + * @note This function does not perform any locking, and is only safe to call
> + *before graph running.
> + *
> + * @param name
> + *   Name of the graph worker model.
> + *
> + * @return
> + *   0 on success, -1 otherwise.
> + */
> +__rte_experimental
> +static inline int
> +rte_graph_worker_model_set(enum rte_graph_worker_model model) {
> + if (model >= RTE_GRAPH_MODEL_MAX)
> + goto fail;
> +
> + worker_model = model;
> + return 0;
> +
> +fail:
> + worker_model = RTE_GRAPH_MODEL_DEFAULT;
> + return -1;
> +}
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change, or be removed, without prior
> +notice
> + *
> + * Get the graph worker model
> + *
> + * @param name
> + *   Name of the graph worker model.
> + *
> + * @return
> + *   Graph worker model on success.
> + */
> +__rte_experimental
> +static inline
> +enum rte_graph_worker_model
> +rte_graph_worker_model_get(void)
> +{
> + return worker_model;
> +}
> +
>  /**
>   * Perform graph walk on the circular buffer and invoke the process function
>   * of the nodes and collect the stats.
> diff --git a/lib/graph/rte_graph_worker_common.h
> b/lib/graph/rte_graph_worker_common.h
> index df33204336..507a344afd 100644
> --- a/lib/graph/rte_graph_worker_common.h
> +++ b/lib/graph/rte_graph_worker_common.h
> @@ -86,6 +86,19 @@ struct rte_node {
>   struct rte_node *nodes[] __rte_cache_min_aligned; /**< Next nodes.
> */  } __rte_cache_aligned;
> 
> +
> +
> +/** Graph worker models */
> +enum rte_graph_worker_model {
> +#define WORKER_MODEL_DEFAULT "default"
> + RTE_GRAPH_MODEL_DEFAULT = 0,
> +#define WORKER_MODEL_RTC "rtc"
> + RTE_GRAPH_MODEL_RTC,

Since default is RTC, do we need one more enum  for RTC? Can we just have 
default and generic and remove rtc?

> +#define WORKER_MODEL_GENERIC "generic"
> + RTE_GRAPH_MODEL_GENERIC,
> + RTE_GRAPH_MODEL_MAX,
> +};
> +
>  /**
>   * @internal
>   *
> diff --git a/lib/graph/version.map b/lib/graph/version.map index
> 13b838752d..eea73ec9ca 100644
> --- a/lib/graph/version.map
> +++ b/lib/graph/version.map
> @@ -43,5 +43,8 @@ EXPERIMENTAL {
>   rte_node_next_stream_put;
>   rte_node_next_stream_move;
> 
> + rte_graph_worker_model_set;
> + rte_graph_worker_model_get;
> +
>   local: *;
>  };
> --
> 2.25.1



RE: [dpdk-dev] [PATCH] net/cnxk: unify the file name

2022-02-17 Thread Kiran Kumar Kokkilagadda



> -Original Message-
> From: jer...@marvell.com 
> Sent: Wednesday, February 9, 2022 10:20 PM
> To: dev@dpdk.org; Nithin Kumar Dabilpuram ;
> Kiran Kumar Kokkilagadda ; Sunil Kumar Kori
> ; Satha Koteswara Rao Kottidi
> 
> Cc: ferruh.yi...@intel.com; Satheesh Paul ; Jerin
> Jacob Kollanukkaran 
> Subject: [dpdk-dev] [PATCH] net/cnxk: unify the file name
> 
> From: Jerin Jacob 
> 
> expect cn*_rte_flow* files, none of the other file has rte in the file name,
> remove the rte to unify the file name across the directory.
> 
> Signed-off-by: Jerin Jacob 

Acked-by: Kiran Kumar Kokkilagadda 

> ---
>  drivers/net/cnxk/cn10k_rte_flow.c | 2 +-
>  drivers/net/cnxk/cn9k_rte_flow.c  | 2 +-
>  drivers/net/cnxk/{cnxk_rte_flow.c => cnxk_flow.c} | 2 +-
> drivers/net/cnxk/{cnxk_rte_flow.h => cnxk_flow.h} | 0
>  drivers/net/cnxk/meson.build  | 2 +-
>  5 files changed, 4 insertions(+), 4 deletions(-)  rename
> drivers/net/cnxk/{cnxk_rte_flow.c => cnxk_flow.c} (99%)  rename
> drivers/net/cnxk/{cnxk_rte_flow.h => cnxk_flow.h} (100%)
> 
> diff --git a/drivers/net/cnxk/cn10k_rte_flow.c
> b/drivers/net/cnxk/cn10k_rte_flow.c
> index 529fb0e4b7..aed187c849 100644
> --- a/drivers/net/cnxk/cn10k_rte_flow.c
> +++ b/drivers/net/cnxk/cn10k_rte_flow.c
> @@ -1,7 +1,7 @@
>  /* SPDX-License-Identifier: BSD-3-Clause
>   * Copyright(C) 2020 Marvell.
>   */
> -#include 
> +#include 
>  #include "cn10k_rte_flow.h"
>  #include "cn10k_ethdev.h"
>  #include "cn10k_rx.h"
> diff --git a/drivers/net/cnxk/cn9k_rte_flow.c
> b/drivers/net/cnxk/cn9k_rte_flow.c
> index b94d29e547..6460672afa 100644
> --- a/drivers/net/cnxk/cn9k_rte_flow.c
> +++ b/drivers/net/cnxk/cn9k_rte_flow.c
> @@ -1,7 +1,7 @@
>  /* SPDX-License-Identifier: BSD-3-Clause
>   * Copyright(C) 2020 Marvell.
>   */
> -#include 
> +#include 
>  #include "cn9k_ethdev.h"
>  #include "cn9k_rte_flow.h"
>  #include "cn9k_rx.h"
> diff --git a/drivers/net/cnxk/cnxk_rte_flow.c b/drivers/net/cnxk/cnxk_flow.c
> similarity index 99% rename from drivers/net/cnxk/cnxk_rte_flow.c rename to
> drivers/net/cnxk/cnxk_flow.c index b08d7c34fa..8763ca63d6 100644
> --- a/drivers/net/cnxk/cnxk_rte_flow.c
> +++ b/drivers/net/cnxk/cnxk_flow.c
> @@ -1,7 +1,7 @@
>  /* SPDX-License-Identifier: BSD-3-Clause
>   * Copyright(C) 2021 Marvell.
>   */
> -#include 
> +#include 
> 
>  const struct cnxk_rte_flow_term_info term[] = {
>   [RTE_FLOW_ITEM_TYPE_ETH] = {ROC_NPC_ITEM_TYPE_ETH, diff --git
> a/drivers/net/cnxk/cnxk_rte_flow.h b/drivers/net/cnxk/cnxk_flow.h similarity
> index 100% rename from drivers/net/cnxk/cnxk_rte_flow.h rename to
> drivers/net/cnxk/cnxk_flow.h diff --git a/drivers/net/cnxk/meson.build
> b/drivers/net/cnxk/meson.build index cd8c13bd1c..af5e09dc65 100644
> --- a/drivers/net/cnxk/meson.build
> +++ b/drivers/net/cnxk/meson.build
> @@ -18,7 +18,7 @@ sources = files(
>  'cnxk_link.c',
>  'cnxk_lookup.c',
>  'cnxk_ptp.c',
> -'cnxk_rte_flow.c',
> +'cnxk_flow.c',
>  'cnxk_stats.c',
>  'cnxk_tm.c',
>  )
> --
> 2.35.1



RE: [RFC PATCH 1/3] graph: add feature arc support

2024-09-10 Thread Kiran Kumar Kokkilagadda



> -Original Message-
> From: Nitin Saxena 
> Sent: Saturday, September 7, 2024 1:01 PM
> To: Jerin Jacob ; Kiran Kumar Kokkilagadda
> ; Nithin Kumar Dabilpuram
> ; Zhirun Yan 
> Cc: dev@dpdk.org; Nitin Saxena 
> Subject: [RFC PATCH 1/3] graph: add feature arc support
> 
> add feature arc to allow dynamic steering of packets across graph nodes
> based on protocol features enabled on incoming or outgoing interface
> 
> Signed-off-by: Nitin Saxena 
> ---
>  lib/graph/graph_feature_arc.c| 959 +++
>  lib/graph/meson.build|   2 +
>  lib/graph/rte_graph_feature_arc.h| 373 +
>  lib/graph/rte_graph_feature_arc_worker.h | 548 +
>  lib/graph/version.map|  17 +
>  5 files changed, 1899 insertions(+)
>  create mode 100644 lib/graph/graph_feature_arc.c
>  create mode 100644 lib/graph/rte_graph_feature_arc.h
>  create mode 100644 lib/graph/rte_graph_feature_arc_worker.h
> 
> diff --git a/lib/graph/graph_feature_arc.c b/lib/graph/graph_feature_arc.c
> new file mode 100644
> index 00..3b05bac137
> --- /dev/null
> +++ b/lib/graph/graph_feature_arc.c
> @@ -0,0 +1,959 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(C) 2024 Marvell International Ltd.
> + */
> +
> +#include "graph_private.h"
> +#include 
> +#include 
> +
> +#define __RTE_GRAPH_FEATURE_ARC_MAX 32
> +
> +#define ARC_PASSIVE_LIST(arc) (arc->active_feature_list ^ 0x1)
> +
> +#define rte_graph_uint_cast(x) ((unsigned int)x)
> +#define feat_dbg graph_err
> +
> +rte_graph_feature_arc_main_t *__feature_arc_main;
> +
> +/* Make sure fast path cache line is compact */
> +_Static_assert((offsetof(struct rte_graph_feature_arc, slow_path_variables)
> + - offsetof(struct rte_graph_feature_arc, fast_path_variables))
> +<= RTE_CACHE_LINE_SIZE);
> +
> +
> +static int
> +feature_lookup(struct rte_graph_feature_arc *arc, const char *feat_name,
> +struct rte_graph_feature_node_list **ffinfo, uint32_t *slot)
> +{
> + struct rte_graph_feature_node_list *finfo = NULL;
> + const char *name;
> +
> + if (!feat_name)
> + return -1;
> +
> + if (slot)
> + *slot = 0;
> +
> + STAILQ_FOREACH(finfo, &arc->all_features, next_feature) {
> + RTE_VERIFY(finfo->feature_arc == arc);
> + name = rte_node_id_to_name(finfo->feature_node->id);
> + if (!strncmp(name, feat_name, RTE_GRAPH_NAMESIZE)) {
> + if (ffinfo)
> + *ffinfo = finfo;
> + return 0;
> + }
> + if (slot)
> + (*slot)++;
> + }
> + return -1;
> +}
> +
> +static int
> +feature_arc_node_info_lookup(struct rte_graph_feature_arc *arc, uint32_t
> feature_index,
> +  struct rte_graph_feature_node_list **ppfinfo)
> +{
> + struct rte_graph_feature_node_list *finfo = NULL;
> + uint32_t index = 0;
> +
> + if (!ppfinfo)
> + return -1;
> +
> + *ppfinfo = NULL;
> + STAILQ_FOREACH(finfo, &arc->all_features, next_feature) {
> + if (index == feature_index) {
> + if (finfo->node_index == feature_index)
> + return -1;
> + *ppfinfo = finfo;
> + }
> + index++;
> + }
> + if (feature_index && (index >= feature_index))
> + return -1;
> +
> + return 0;
> +}
> +
> +static void
> +prepare_feature_arc(struct rte_graph_feature_arc *arc)
> +{
> + struct rte_graph_feature_node_list *finfo = NULL;
> + uint32_t index = 0;
> +
> + STAILQ_FOREACH(finfo, &arc->all_features, next_feature) {
> + finfo->node_index = index;
> + index++;
> + }
> +}
> +
> +static int
> +feature_arc_lookup(rte_graph_feature_arc_t _arc)
> +{
> + struct rte_graph_feature_arc *arc = rte_graph_feature_arc_get(_arc);
> + rte_graph_feature_arc_main_t *dm = __feature_arc_main;
> + uint32_t iter;
> +
> + if (!__feature_arc_main)
> + return -1;
> +
> + for (iter = 0; iter < dm->max_feature_arcs; iter++) {
> + if (dm->feature_arcs[iter] ==
> RTE_GRAPH_FEATURE_ARC_INITIALIZER)
> + continue;
> +
> + if (arc == (rte_graph_feature_arc_get(dm-
> >feature_arcs[iter])))
> + return 0;
> + }
> + return -1;
> +}
> +
> +static int
> +get_exis

[dpdk-dev] [PATCH v2] kni: add IOVA va support for kni

2019-04-01 Thread Kiran Kumar Kokkilagadda
From: Kiran Kumar K 

With current KNI implementation kernel module will work only in
IOVA=PA mode. This patch will add support for kernel module to work
with IOVA=VA mode.

The idea is to maintain a mapping in KNI module between user pages and
kernel pages and in fast path perform a lookup in this table and get
the kernel virtual address for corresponding user virtual address.

In IOVA=VA mode, the memory allocated to the pool is physically
and virtually contiguous. We will take advantage of this and create a
mapping in the kernel.In kernel we need mapping for queues
(tx_q, rx_q,... slow path) and mbuf memory (fast path).

At the KNI init time, in slow path we will create a mapping for the
queues and mbuf using get_user_pages similar to af_xdp. Using pool
memory base address, we will create a page map table for the mbuf,
which we will use in the fast path for kernel page translation.

At KNI init time, we will pass the base address of the pool and size of
the pool to kernel. In kernel, using get_user_pages API, we will get
the pages with size PAGE_SIZE and store the mapping and start address
of user space in a table.

In fast path for any user address perform PAGE_SHIFT
(user_addr >> PAGE_SHIFT) and subtract the start address from this value,
we will get the index of the kernel page with in the page map table.
Adding offset to this kernel page address, we will get the kernel address
for this user virtual address.

For example user pool base address is X, and size is S that we passed to
kernel. In kernel we will create a mapping for this using get_user_pages.
Our page map table will look like [Y, Y+PAGE_SIZE, Y+(PAGE_SIZE*2) ]
and user start page will be U (we will get it from X >> PAGE_SHIFT).

For any user address Z we will get the index of the page map table using
((Z >> PAGE_SHIFT) - U). Adding offset (Z & (PAGE_SIZE - 1)) to this
address will give kernel virtual address.

Signed-off-by: Kiran Kumar K 
---

V2 changes:
* Fixed build issue with older kernel

 kernel/linux/kni/kni_dev.h|  37 +++
 kernel/linux/kni/kni_misc.c   | 215 +-
 kernel/linux/kni/kni_net.c| 114 --
 .../eal/include/exec-env/rte_kni_common.h |   8 +
 lib/librte_kni/rte_kni.c  |  21 ++
 5 files changed, 369 insertions(+), 26 deletions(-)

diff --git a/kernel/linux/kni/kni_dev.h b/kernel/linux/kni/kni_dev.h
index 688f574a4..055b8d59e 100644
--- a/kernel/linux/kni/kni_dev.h
+++ b/kernel/linux/kni/kni_dev.h
@@ -32,10 +32,47 @@
 /* Default carrier state for created KNI network interfaces */
 extern uint32_t dflt_carrier;

+struct iova_page_info {
+   /* User to kernel page table map, used for
+* fast path lookup
+*/
+   struct mbuf_page {
+   void *addr;
+   } *page_map;
+
+   /* Page mask */
+   u64 page_mask;
+
+   /* Start page for user address */
+   u64 start_page;
+
+   struct page_info {
+   /* Physical pages returned by get_user_pages */
+   struct page **pgs;
+
+   /* Number of Pages returned by get_user_pages */
+   u32 npgs;
+   } page_info;
+
+   /* Queue info */
+   struct page_info tx_q;
+   struct page_info rx_q;
+   struct page_info alloc_q;
+   struct page_info free_q;
+   struct page_info req_q;
+   struct page_info resp_q;
+   struct page_info sync_va;
+};
+
 /**
  * A structure describing the private information for a kni device.
  */
 struct kni_dev {
+   /* Page info for IOVA=VA mode */
+   struct iova_page_info va_info;
+   /* IOVA mode 0 = PA, 1 = VA */
+   uint8_t iova_mode;
+
/* kni list */
struct list_head list;

diff --git a/kernel/linux/kni/kni_misc.c b/kernel/linux/kni/kni_misc.c
index 04c78eb87..0be0e1dfd 100644
--- a/kernel/linux/kni/kni_misc.c
+++ b/kernel/linux/kni/kni_misc.c
@@ -201,6 +201,122 @@ kni_dev_remove(struct kni_dev *dev)
return 0;
 }

+static void
+kni_unpin_pages(struct page_info *mem)
+{
+   u32 i;
+
+   /* Set the user pages as dirty, so that these pages will not be
+* allocated to other applications until we release them.
+*/
+   for (i = 0; i < mem->npgs; i++) {
+   struct page *page = mem->pgs[i];
+
+   set_page_dirty_lock(page);
+   put_page(page);
+   }
+
+   kfree(mem->pgs);
+   mem->pgs = NULL;
+}
+
+static void
+kni_clean_queue(struct page_info *mem)
+{
+   if (mem->pgs) {
+   set_page_dirty_lock(mem->pgs[0]);
+   put_page(mem->pgs[0]);
+   kfree(mem->pgs);
+   mem->pgs = NULL;
+   }
+}
+
+static void
+kni_cleanup_iova(struct iova_page_info *mem)
+{
+   kni_unpin_pages(&mem->page_info);
+   kfree(mem->page_map);
+   mem->page_map = NULL;
+
+   kni_clean_queue(&mem->tx_q);
+ 

Re: [dpdk-dev] [EXT] Re: [PATCH v2] kni: add IOVA va support for kni

2019-04-05 Thread Kiran Kumar Kokkilagadda


> -Original Message-
> From: Ferruh Yigit 
> Sent: Wednesday, April 3, 2019 9:59 PM
> To: Kiran Kumar Kokkilagadda 
> Cc: dev@dpdk.org; Jerin Jacob 
> Subject: [EXT] Re: [dpdk-dev] [PATCH v2] kni: add IOVA va support for kni
> 
> External Email
> 
> --
> On 4/1/2019 10:51 AM, Kiran Kumar Kokkilagadda wrote:
> > From: Kiran Kumar K 
> >
> > With current KNI implementation kernel module will work only in
> > IOVA=PA mode. This patch will add support for kernel module to work
> > with IOVA=VA mode.
> 
> Thanks Kiran for removing the limitation, I have a few questions, can you 
> please
> help me understand.
> 
> And when this patch is ready, the restriction in 'linux/eal/eal.c', in 
> 'rte_eal_init'
> should be removed, perhaps with this patch. I assume you already doing it to 
> be
> able to test this patch.
> 

User can choose the mode by passing --iova-mode=. I will remove the 
rte_kni module restriction.
 

> >
> > The idea is to maintain a mapping in KNI module between user pages and
> > kernel pages and in fast path perform a lookup in this table and get
> > the kernel virtual address for corresponding user virtual address.
> >
> > In IOVA=VA mode, the memory allocated to the pool is physically and
> > virtually contiguous. We will take advantage of this and create a
> > mapping in the kernel.In kernel we need mapping for queues (tx_q,
> > rx_q,... slow path) and mbuf memory (fast path).
> 
> Is it?
> As far as I know mempool can have multiple chunks and they can be both
> virtually and physically separated.
> 
> And even for a single chunk, that will be virtually continuous, but will it be
> physically continuous?
> 

You are right, it need not have to be physically contiguous. Will change the 
description.
 

> >
> > At the KNI init time, in slow path we will create a mapping for the
> > queues and mbuf using get_user_pages similar to af_xdp. Using pool
> > memory base address, we will create a page map table for the mbuf,
> > which we will use in the fast path for kernel page translation.
> >
> > At KNI init time, we will pass the base address of the pool and size
> > of the pool to kernel. In kernel, using get_user_pages API, we will
> > get the pages with size PAGE_SIZE and store the mapping and start
> > address of user space in a table.
> >
> > In fast path for any user address perform PAGE_SHIFT (user_addr >>
> > PAGE_SHIFT) and subtract the start address from this value, we will
> > get the index of the kernel page with in the page map table.
> > Adding offset to this kernel page address, we will get the kernel
> > address for this user virtual address.
> >
> > For example user pool base address is X, and size is S that we passed
> > to kernel. In kernel we will create a mapping for this using get_user_pages.
> > Our page map table will look like [Y, Y+PAGE_SIZE, Y+(PAGE_SIZE*2)
> > ] and user start page will be U (we will get it from X >> PAGE_SHIFT).
> >
> > For any user address Z we will get the index of the page map table
> > using ((Z >> PAGE_SHIFT) - U). Adding offset (Z & (PAGE_SIZE - 1)) to
> > this address will give kernel virtual address.
> >
> > Signed-off-by: Kiran Kumar K 
> 
> <...>
> 
> > +int
> > +kni_pin_pages(void *address, size_t size, struct page_info *mem) {
> > +   unsigned int gup_flags = FOLL_WRITE;
> > +   long npgs;
> > +   int err;
> > +
> > +   /* Get at least one page */
> > +   if (size < PAGE_SIZE)
> > +   size = PAGE_SIZE;
> > +
> > +   /* Compute number of user pages based on page size */
> > +   mem->npgs = (size + PAGE_SIZE - 1) / PAGE_SIZE;
> > +
> > +   /* Allocate memory for the pages */
> > +   mem->pgs = kcalloc(mem->npgs, sizeof(*mem->pgs),
> > + GFP_KERNEL | __GFP_NOWARN);
> > +   if (!mem->pgs) {
> > +   pr_err("%s: -ENOMEM\n", __func__);
> > +   return -ENOMEM;
> > +   }
> > +
> > +   down_write(¤t->mm->mmap_sem);
> > +
> > +   /* Get the user pages from the user address*/ #if
> LINUX_VERSION_CODE
> > +>= KERNEL_VERSION(4,9,0)
> > +   npgs = get_user_pages((u64)address, mem->npgs,
> > +   gup_flags, &mem->pgs[0], NULL);
> > +#else
> > +   npgs = get_user_pages(current, current->mm, (u64)address, mem-
> >npgs,
> > +   gup_flags, 0, &mem->pgs[0], NUL

Re: [dpdk-dev] [EXT] Re: [PATCH] net/octeontx2: extend RSS supported offload types

2020-01-22 Thread Kiran Kumar Kokkilagadda


> -Original Message-
> From: Jerin Jacob 
> Sent: Wednesday, January 22, 2020 1:35 PM
> To: Kiran Kumar Kokkilagadda 
> Cc: Jerin Jacob Kollanukkaran ; Nithin Kumar Dabilpuram
> ; Vamsi Krishna Attunuru
> ; dpdk-dev 
> Subject: [EXT] Re: [dpdk-dev] [PATCH] net/octeontx2: extend RSS supported
> offload types
> 
> External Email
> 
> --
> On Wed, Jan 22, 2020 at 9:16 AM  wrote:
> >
> > From: Kiran Kumar K 
> >
> > Extend RSS offload types for octeontx2. Add support to select
> > L3 SRC, L3 DST, L4 SRC and L4 DST for RSS calculation.
> >
> > Add support to select L3 SRC or DST only, L4 SRC or DST only for RSS
> > calculation.
> >
> > With this requirement there will be following combinations,
> > IPV[4,6]_SRC_ONLY, IPV[4,6]_DST_ONLY, [TCP,UDP,SCTP]_SRC_ONLY,
> > [TCP,UDP,SCTP]_DST_ONLY. So, instead of creating a bit for each
> > combination, we are using upper 4 bits (31:28) in the flow_key_cfg to
> > represent the SRC, DST selection. 31 => L3_SRC, 30 => L3_DST,
> > 29 => L4_SRC, 28 => L4_DST. These won't be part of flow_cfg, so that
> > we don't need to change the existing ABI.
> >
> > Signed-off-by: Kiran Kumar K 
> > ---
> >
> >  struct nix_rss_flowkey_cfg_rsp {
> > diff --git a/drivers/net/octeontx2/otx2_rss.c
> > b/drivers/net/octeontx2/otx2_rss.c
> > index bc7b64387..7a8c8f3de 100644
> > --- a/drivers/net/octeontx2/otx2_rss.c
> > +++ b/drivers/net/octeontx2/otx2_rss.c
> > @@ -210,6 +210,18 @@ otx2_rss_ethdev_to_nix(struct otx2_eth_dev *dev,
> > uint64_t ethdev_rss,
> >
> > dev->rss_info.nix_rss = ethdev_rss;
> >
> 
> Should n't we update the struct
> rte_eth_dev_info::flow_type_rss_offloads to show this capability to the 
> driver.
> Please check other drivers.

Verified with testpmd. I need to update the supported RSS offloads. Will send 
V2.

> 
> 
> 
> > +   if (ethdev_rss & ETH_RSS_L3_SRC_ONLY)
> > +   flowkey_cfg |= FLOW_KEY_TYPE_L3_SRC;
> > +
> > +   if (ethdev_rss & ETH_RSS_L3_DST_ONLY)
> > +   flowkey_cfg |= FLOW_KEY_TYPE_L3_DST;
> > +
> > +   if (ethdev_rss & ETH_RSS_L4_SRC_ONLY)
> > +   flowkey_cfg |= FLOW_KEY_TYPE_L4_SRC;
> > +
> > +   if (ethdev_rss & ETH_RSS_L4_DST_ONLY)
> > +   flowkey_cfg |= FLOW_KEY_TYPE_L4_DST;
> > +
> > if (ethdev_rss & RSS_IPV4_ENABLE)
> > flowkey_cfg |=
> > flow_key_type[rss_level][RSS_IPV4_INDEX];
> >
> > --
> > 2.17.1
> >


Re: [dpdk-dev] [EXT] Re: [PATCH v2] test/graph: fix memory leak

2020-05-14 Thread Kiran Kumar Kokkilagadda


> -Original Message-
> From: David Marchand 
> Sent: Thursday, May 14, 2020 4:34 PM
> To: Kiran Kumar Kokkilagadda 
> Cc: Jerin Jacob Kollanukkaran ; Nithin Kumar Dabilpuram
> ; dev ; Mcnamara, John
> 
> Subject: [EXT] Re: [dpdk-dev] [PATCH v2] test/graph: fix memory leak
> 
> External Email
> 
> --
> On Thu, May 14, 2020 at 10:57 AM  wrote:
> >
> > From: Kiran Kumar K 
> >
> > Fix memory leaks reported by coverity.
> >
> > Coverity issue: 358439, 358451, 358448.
> 
> Please no '.' at the end of a tag (and sorting would not hurt).
> 


Will fix in V3.

> I wanted to get a look at those, but I can't find them in coverity webui.
> Maybe those issues have been closed, but then I can't look at them.. ?
> Any help would be appreciated.
> 
> 
> > Fixes: 6b89650418("test/graph: add functional tests")
> >
> > Signed-off-by: Kiran Kumar K 
> > ---
> > V2 changes:
> > * Added Coverity issue and Fixes info.
> >
> >  app/test/test_graph.c | 7 +--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/app/test/test_graph.c b/app/test/test_graph.c index
> > cf6df0744..ed69eda99 100644
> > --- a/app/test/test_graph.c
> > +++ b/app/test/test_graph.c
> > @@ -12,6 +12,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include "test.h"
> >
> > @@ -145,7 +146,7 @@ uint16_t
> >  test_node_worker_source(struct rte_graph *graph, struct rte_node *node,
> > void **objs, uint16_t nb_objs)  {
> > -   uint32_t obj_node0 = rand() % 100, obj_node1;
> > +   uint32_t obj_node0 = rte_rand() % 100, obj_node1;
> 
> The commitlog indicates memory leaks, I am a bit surprised to see this change.
> What is the rationale?
> 
Merged all the coverity issues to single patch. Will change the description in 
V3.

> 
> > test_main_t *tm = &test_main;
> > struct rte_mbuf *data;
> > void **next_stream;
> > @@ -193,7 +194,7 @@ test_node0_worker(struct rte_graph *graph, struct
> rte_node *node, void **objs,
> > test_main_t *tm = &test_main;
> >
> > if (*(uint32_t *)node->ctx == test_node0.id) {
> > -   uint32_t obj_node0 = rand() % 100, obj_node1;
> > +   uint32_t obj_node0 = rte_rand() % 100, obj_node1;
> 
> Idem.
> 
> 
> > struct rte_mbuf *data;
> > uint8_t second_pass = 0;
> > uint32_t count = 0;
> > @@ -496,6 +497,7 @@ test_lookup_functions(void)
> > printf("Test number of edges for node = %s failed 
> > Expected = %d,
> got %d\n",
> >tm->test_node[i].node.name,
> >tm->test_node[i].node.nb_edges, count);
> > +   free(next_edges);
> > return -1;
> > }
> >
> > @@ -505,6 +507,7 @@ test_lookup_functions(void)
> > printf("Edge name miss match, expected = %s 
> > got = %s\n",
> >tm->test_node[i].node.next_nodes[j],
> >next_edges[j]);
> > +   free(next_edges);
> > return -1;
> > }
> > }
> > --
> > 2.17.1
> >
> 
> 
> --
> David Marchand



Re: [dpdk-dev] [EXT] Re: [PATCH v4 03/29] graph: implement node operations

2020-04-06 Thread Kiran Kumar Kokkilagadda


> -Original Message-
> From: Andrzej Ostruszka 
> Sent: Monday, April 6, 2020 11:27 PM
> To: Jerin Jacob Kollanukkaran ; Kiran Kumar Kokkilagadda
> 
> Cc: dev@dpdk.org; tho...@monjalon.net; david.march...@redhat.com;
> m...@ashroe.eu; mattias.ronnb...@ericsson.com; Pavan Nikhilesh
> Bhagavatula ; Nithin Kumar Dabilpuram
> ; xiao.w.w...@intel.com
> Subject: [EXT] Re: [dpdk-dev] [PATCH v4 03/29] graph: implement node
> operations
> 
> External Email
> 
> --
> On 4/5/20 10:55 AM, jer...@marvell.com wrote:
> [...]
> > diff --git a/lib/librte_graph/node.c b/lib/librte_graph/node.c index
> > 336cd1c94..d04a0fce0 100644
> > --- a/lib/librte_graph/node.c
> > +++ b/lib/librte_graph/node.c
> [...]
> > +static rte_edge_t
> > +edge_update(struct node *node, struct node *prev, rte_edge_t from,
> > +   const char **next_nodes, rte_edge_t nb_edges) {
> > +   rte_edge_t i, max_edges, count = 0;
> > +   struct node *new_node;
> > +   bool need_realloc;
> > +   size_t sz;
> > +
> > +   if (from == RTE_EDGE_ID_INVALID)
> > +   from = node->nb_edges;
> > +
> > +   /* Don't create hole in next_nodes[] list */
> > +   if (from > node->nb_edges) {
> > +   rte_errno = ENOMEM;
> > +   goto fail;
> > +   }
> > +
> > +   /* Remove me from list */
> > +   STAILQ_REMOVE(&node_list, node, node, next);

This is where we will remove the node first unconditionally. Later we update 
the new node.

> > +
> > +   /* Allocate the storage space for new node if required */
> > +   max_edges = from + nb_edges;
> > +   need_realloc = max_edges > node->nb_edges;
> > +   if (need_realloc) {
> > +   sz = sizeof(struct node) + (max_edges * RTE_NODE_NAMESIZE);
> > +   new_node = realloc(node, sz);
> > +   if (new_node == NULL) {
> > +   rte_errno = ENOMEM;
> > +   goto restore;
> > +   } else {
> > +   node = new_node;
> > +   }
> > +   }
> > +
> > +   /* Update the new nodes name */
> > +   for (i = from; i < max_edges; i++, count++) {
> > +   if (rte_strscpy(node->next_nodes[i], next_nodes[count],
> > +   RTE_NODE_NAMESIZE) < 0) {
> > +   rte_errno = E2BIG;
> > +   goto restore;
> > +   }
> > +   }
> > +restore:
> > +   /* Update the linked list to point new node address in prev node */
> > +   if (prev)
> > +   STAILQ_INSERT_AFTER(&node_list, prev, node, next);
> > +   else
> > +   STAILQ_INSERT_HEAD(&node_list, node, next);
> 
> AFAIU node_list keeps the list of nodes - so I guess you wanted here "replace"
> the old node pointer with the new one.  I have not yet seen the usage of this
> function but it seems to me like you unconditionally insert the updated node -
> possibly having node pointer present doubly or with stale pointer.  I might be
> missing something here.
> 
See above.

> > +
> > +   if (need_realloc)
> > +   node->nb_edges += max_edges;
> 
> It looks to me like this should be simple '='.
> 
> > +
> > +fail:
> > +   return count;
> > +}
> [...]
> > +rte_edge_t
> > +rte_node_edge_update(rte_node_t id, rte_edge_t from, const char
> **next_nodes,
> > +uint16_t nb_edges)
> > +{
> > +   rte_edge_t rc = RTE_EDGE_ID_INVALID;
> > +   struct node *n, *prev;
> > +
> > +   NODE_ID_CHECK(id);
> > +   graph_spinlock_lock();
> > +
> > +   prev = NULL;
> > +   STAILQ_FOREACH(n, &node_list, next) {
> > +   if (n->id == id) {
> > +   rc = edge_update(n, prev, from, next_nodes,
> nb_edges);
> > +   break;
> > +   }
> > +   prev = n;
> > +   }
> 
> OK so in this context my comment above seems to be valid.  When we find the id
> we have: prev -> n, we call update() and in there we insert new_node after 
> prev
> so we end up with: prev -> n' -> n where n' might be new address for n or 
> just n
> when no realloc was performed.
> 
> Do I miss anything?
> 

See above.

> > +
> > +   graph_spinlock_unlock();
> > +fail:
> > +   return rc;
> > +}
> > +
> > +static rte_node_t
> > +node_copy_edges(struct node *node, char *next_nodes[]) {
> > +   rte_edge_t i;
> > +
> > +   

Re: [dpdk-dev] [PATCH v4 06/29] graph: populate fastpath memory for graph reel

2020-04-08 Thread Kiran Kumar Kokkilagadda


> -Original Message-
> From: dev  On Behalf Of Andrzej Ostruszka
> Sent: Wednesday, April 8, 2020 11:00 PM
> To: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v4 06/29] graph: populate fastpath memory for
> graph reel
> 
> On 4/5/20 10:55 AM, jer...@marvell.com wrote:
> > From: Jerin Jacob 
> [...]
> > diff --git a/lib/librte_graph/graph_populate.c
> > b/lib/librte_graph/graph_populate.c
> > new file mode 100644
> > index 0..093512efa
> > --- /dev/null
> > +++ b/lib/librte_graph/graph_populate.c
> > @@ -0,0 +1,234 @@
> > +/* SPDX-License-Identifier: BSD-3-Clause
> > + * Copyright(C) 2020 Marvell International Ltd.
> > + */
> > +
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "graph_private.h"
> > +
> > +static size_t
> > +graph_fp_mem_calc_size(struct graph *graph) {
> > +   struct graph_node *graph_node;
> > +   rte_node_t val;
> > +   size_t sz;
> > +
> > +   /* Graph header */
> > +   sz = sizeof(struct rte_graph);
> > +   /* Source nodes list */
> > +   sz += sizeof(rte_graph_off_t) * graph->src_node_count;
> > +   /* Circular buffer for pending streams of size number of nodes */
> > +   val = rte_align32pow2(graph->node_count * sizeof(rte_graph_off_t));
> > +   sz = RTE_ALIGN(sz, val);
> > +   graph->cir_start = sz;
> > +   graph->cir_mask = rte_align32pow2(graph->node_count) - 1;
> > +   sz += val;
> 
> Aren't here source nodes counted twice?  I'm trying now to wrap my head
> around how this all is structured and laid out in memory (thus the slowdown in
> review) so I am most probably missing something here.
> 

Yes, we are counting source nodes offset, 2 times in the circular buffer. In 
fact intentionally we are allocating the circular buffer more than the required 
size (rte_align32pow2).
By allocating circular buffer with more size, at least in some cases we can 
avoid wraparound.
Let me try to explain how this memory reel and graph walk works.
This is how memory reel looks like.

1. Graph_header---> 2. FENCE ---> 3. [Graph walk always starts from here] 
memory for source node object offsets ---> 4. [circular buffer starts] enqueued 
node object offset [ circular buffer end] --> 5. FENCE ---> 6. Memory for Node 
objects

3 and 4 will have the offset of their corresponding node object in the 6.

Initially before graph walk start we will populate the 3 (see 
graph_src_nodes_populate) and when the graph walk start first we will go over 3 
and based on the enqueues , we will populate the 4 and this is where we are 
creating circle (we will be keep walking in 4 till there are no more enqueues). 
So, circular buffer is actually walk the source nodes first then will create 
circle for enqueued nodes (4).

  
> > +   /* Fence */
> > +   sz += sizeof(RTE_GRAPH_FENCE);
> > +   sz = RTE_ALIGN(sz, RTE_CACHE_LINE_SIZE);
> > +   graph->nodes_start = sz;
> > +   /* For 0..N node objects with fence */
> > +   STAILQ_FOREACH(graph_node, &graph->node_list, next) {
> > +   sz = RTE_ALIGN(sz, RTE_CACHE_LINE_SIZE);
> > +   sz += sizeof(struct rte_node);
> > +   /* Pointer to next nodes(edges) */
> > +   sz += sizeof(struct rte_node *) * graph_node->node->nb_edges;
> > +   }
> > +
> > +   graph->mem_sz = sz;
> > +   return sz;
> > +}
> > +
> > +static void
> > +graph_header_popluate(struct graph *_graph) {
> > +   struct rte_graph *graph = _graph->graph;
> > +
> > +   graph->tail = 0;
> > +   graph->head = (int32_t)-_graph->src_node_count;
> > +   graph->cir_mask = _graph->cir_mask;
> > +   graph->nb_nodes = _graph->node_count;
> > +   graph->cir_start = RTE_PTR_ADD(graph, _graph->cir_start);
> > +   graph->nodes_start = _graph->nodes_start;
> > +   graph->socket = _graph->socket;
> > +   graph->id = _graph->id;
> > +   memcpy(graph->name, _graph->name, RTE_GRAPH_NAMESIZE);
> 
> As I've mentioned above I'm learning the structure of the lib/memory so quick
> question here.  My understanding is that rte_graph is a "view of the 'struct
> graph' sufficient for worker" so does it need both id & name?  Both of them
> seems to be used in error or dump/debug paths.  It probably doesn't matter 
> (e.g.
> for performance) - just asking because 'id' seems to be used only in one place
> (where name could replace it probably).
> 

User will have access to the node info both ways using either name or ID. These 
are used in slow path. 
It is up to the user how he wants to use it.  


> > +   graph->fence = RTE_GRAPH_FENCE;
> > +}
> > +
> > +static void
> > +graph_nodes_populate(struct graph *_graph) {
> > +   rte_graph_off_t off = _graph->nodes_start;
> > +   struct rte_graph *graph = _graph->graph;
> > +   struct graph_node *graph_node;
> > +   rte_edge_t count, nb_edges;
> > +   const char *parent;
> > +   rte_node_t pid;
> > +
> > +   STAILQ_FOREACH(graph_node, &_graph->node_list, next) {
> > +   struct rte_node *node = RTE_PTR_ADD(graph, off);
> > +   memset(node, 0, sizeof(*node));
> > +

Re: [dpdk-dev] [PATCH] ethdev: add DBDF action to RTE Flow

2020-03-17 Thread Kiran Kumar Kokkilagadda
Hi Ori,



> -Original Message-
> From: Ori Kam 
> Sent: Monday, March 16, 2020 7:04 PM
> To: Kiran Kumar Kokkilagadda ; Wenzhuo Lu
> ; Jingjing Wu ; Bernard
> Iremonger ; John McNamara
> ; Marko Kovacevic ;
> Thomas Monjalon ; Ferruh Yigit
> ; Andrew Rybchenko 
> Cc: dev@dpdk.org
> Subject: [EXT] RE: [dpdk-dev] [PATCH] ethdev: add DBDF action to RTE Flow
> 
> External Email
> 
> --
> Hi Kiran,
> 
> 
> > -Original Message-
> > From: kirankum...@marvell.com 
> > Sent: Tuesday, March 10, 2020 6:06 PM
> > To: Ori Kam ; Wenzhuo Lu ;
> > Jingjing Wu ; Bernard Iremonger
> > ; John McNamara
> > ; Marko Kovacevic
> > ; Thomas Monjalon ;
> > Ferruh Yigit ; Andrew Rybchenko
> > 
> > Cc: dev@dpdk.org; Kiran Kumar K 
> > Subject: [dpdk-dev] [PATCH] ethdev: add DBDF action to RTE Flow
> >
> > From: Kiran Kumar K 
> >
> > Adding suuport to DBDF action in the RTE Flow.
> > Application can specify the dbdf value using rte_flow_action_dbdf.
> > Matched traffic will be sent to specified PCI DBDF device.
> >
> I would like to see more detail use case, for example to which device / device
> type will the traffic be routed to?
> 

We have the following use case.
We have 2 PF's pf0, pf1 and corresponding VF's pf0_vf0 , pf1_vf0. And we have 3 
applications running.
1st application on pf0 and pf1
2nd application on pf0_vf0
3rd application on pf1_vf0.
We want to direct the traffic matching condition1 from application 1 (traffic  
from both pf0 & pf1) needs to send to  application 2 (pf0_vf0)
And matching condition2 from application 1 (traffic from both pf0 & pf1) needs 
to send to application 3 (pf1_vf0).
To summarize, we need to send traffic from pf0 to pf1_vf0 and traffic from pf1 
to pf0_vf0. In this case This DBDF action will be useful.


> > Signed-off-by: Kiran Kumar K 
> > ---
> >  app/test-pmd/cmdline_flow.c| 64 ++
> >  doc/guides/prog_guide/rte_flow.rst | 19 +
> >  lib/librte_ethdev/rte_flow.c   |  1 +
> >  lib/librte_ethdev/rte_flow.h   | 16 
> >  4 files changed, 100 insertions(+)
> >
> > diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
> > index a78154502..c318b4a27 100644
> > --- a/app/test-pmd/cmdline_flow.c
> > +++ b/app/test-pmd/cmdline_flow.c
> > @@ -342,8 +342,17 @@ enum index {
> > ACTION_SET_IPV4_DSCP_VALUE,
> > ACTION_SET_IPV6_DSCP,
> > ACTION_SET_IPV6_DSCP_VALUE,
> > +   ACTION_DBDF,
> >  };
> >
> > +#define DBDF_KEY_LENGTH 20
> > +
> > +struct action_dbdf_data {
> > +   struct rte_flow_action_dbdf conf;
> > +   uint8_t dbdf_value[DBDF_KEY_LENGTH]; };
> > +
> > +
> >  /** Maximum size for pattern in struct rte_flow_item_raw. */  #define
> > ITEM_RAW_PATTERN_SIZE 40
> >
> > @@ -1144,6 +1153,7 @@ static const enum index next_action[] = {
> > ACTION_SET_META,
> > ACTION_SET_IPV4_DSCP,
> > ACTION_SET_IPV6_DSCP,
> > +   ACTION_DBDF,
> > ZERO,
> >  };
> >
> > @@ -1369,6 +1379,11 @@ static const enum index action_set_ipv6_dscp[] = {
> > ZERO,
> >  };
> >
> > +static const enum index action_dbdf[] = {
> > +   ACTION_NEXT,
> > +   ZERO,
> > +};
> > +
> >  static int parse_set_raw_encap_decap(struct context *, const struct token 
> > *,
> >  const char *, unsigned int,
> >  void *, unsigned int);
> > @@ -1421,6 +1436,9 @@ static int parse_vc_action_mplsoudp_encap(struct
> > context *,
> >  static int parse_vc_action_mplsoudp_decap(struct context *,
> >   const struct token *, const char *,
> >   unsigned int, void *, unsigned int);
> > +static int parse_vc_action_dbdf_value(struct context *,
> > +const struct token *, const char *,
> > +unsigned int, void *, unsigned int);
> >  static int parse_vc_action_raw_encap(struct context *,
> >  const struct token *, const char *,
> >  unsigned int, void *, unsigned int); @@ -
> 3684,6 +3702,18 @@
> > static const struct token token_list[] = {
> >  (struct rte_flow_action_set_dscp, dscp)),
> > .call = parse_vc_conf,
> > },
> > +   [ACTION_DBDF] = {
> > +   .name = "dbdf",
&g

Re: [dpdk-dev] [PATCH] ethdev: add DBDF action to RTE Flow

2020-03-19 Thread Kiran Kumar Kokkilagadda
Hi Ori,


> -Original Message-
> From: dev  On Behalf Of Ori Kam
> Sent: Tuesday, March 17, 2020 6:56 PM
> To: Kiran Kumar Kokkilagadda ; Wenzhuo Lu
> ; Jingjing Wu ; Bernard
> Iremonger ; John McNamara
> ; Marko Kovacevic ;
> Thomas Monjalon ; Ferruh Yigit
> ; Andrew Rybchenko 
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] ethdev: add DBDF action to RTE Flow
> 
> HI Kiran,
> 
> > -Original Message-
> > From: Kiran Kumar Kokkilagadda 
> > Sent: Tuesday, March 17, 2020 12:34 PM
> > To: Ori Kam ; Wenzhuo Lu ;
> > Jingjing Wu ; Bernard Iremonger
> > ; John McNamara
> > ; Marko Kovacevic
> > ; Thomas Monjalon ;
> > Ferruh Yigit ; Andrew Rybchenko
> > 
> > Cc: dev@dpdk.org
> > Subject: RE: [dpdk-dev] [PATCH] ethdev: add DBDF action to RTE Flow
> >
> > Hi Ori,
> >
> >
> >
> > > -Original Message-
> > > From: Ori Kam 
> > > Sent: Monday, March 16, 2020 7:04 PM
> > > To: Kiran Kumar Kokkilagadda ; Wenzhuo Lu
> > > ; Jingjing Wu ; Bernard
> > > Iremonger ; John McNamara
> > > ; Marko Kovacevic
> > ;
> > > Thomas Monjalon ; Ferruh Yigit
> > > ; Andrew Rybchenko
> > > 
> > > Cc: dev@dpdk.org
> > > Subject: [EXT] RE: [dpdk-dev] [PATCH] ethdev: add DBDF action to RTE
> > > Flow
> > >
> > > External Email
> > >
> > > 
> > > --
> > > Hi Kiran,
> > >
> > >
> > > > -----Original Message-
> > > > From: kirankum...@marvell.com 
> > > > Sent: Tuesday, March 10, 2020 6:06 PM
> > > > To: Ori Kam ; Wenzhuo Lu
> > ;
> > > > Jingjing Wu ; Bernard Iremonger
> > > > ; John McNamara
> > > > ; Marko Kovacevic
> > > > ; Thomas Monjalon
> > ;
> > > > Ferruh Yigit ; Andrew Rybchenko
> > > > 
> > > > Cc: dev@dpdk.org; Kiran Kumar K 
> > > > Subject: [dpdk-dev] [PATCH] ethdev: add DBDF action to RTE Flow
> > > >
> > > > From: Kiran Kumar K 
> > > >
> > > > Adding suuport to DBDF action in the RTE Flow.
> > > > Application can specify the dbdf value using rte_flow_action_dbdf.
> > > > Matched traffic will be sent to specified PCI DBDF device.
> > > >
> > > I would like to see more detail use case, for example to which
> > > device / device type will the traffic be routed to?
> > >
> >
> > We have the following use case.
> > We have 2 PF's pf0, pf1 and corresponding VF's pf0_vf0 , pf1_vf0. And
> > we have
> > 3 applications running.
> > 1st application on pf0 and pf1
> > 2nd application on pf0_vf0
> > 3rd application on pf1_vf0.
> > We want to direct the traffic matching condition1 from application 1
> > (traffic from both pf0 & pf1) needs to send to  application 2
> > (pf0_vf0) And matching condition2 from application 1 (traffic from
> > both pf0 & pf1) needs to send to application 3 (pf1_vf0).
> > To summarize, we need to send traffic from pf0 to pf1_vf0 and traffic
> > from pf1 to pf0_vf0. In this case This DBDF action will be useful.
> >
> 
> It seems that what you are describing it the port action with representors, 
> or any
> other way you wish to implement it.

Let's say we have a VF with kernel and we want to send the traffic to that VF, 
then we can't
Use port action. This will be useful in those scenarios.


> 
> >
> > > > Signed-off-by: Kiran Kumar K 
> > > > ---
> > > >  app/test-pmd/cmdline_flow.c| 64
> > ++
> > > >  doc/guides/prog_guide/rte_flow.rst | 19 +
> > > >  lib/librte_ethdev/rte_flow.c   |  1 +
> > > >  lib/librte_ethdev/rte_flow.h   | 16 
> > > >  4 files changed, 100 insertions(+)
> > > >
> > > > diff --git a/app/test-pmd/cmdline_flow.c
> > > > b/app/test-pmd/cmdline_flow.c index a78154502..c318b4a27 100644
> > > > --- a/app/test-pmd/cmdline_flow.c
> > > > +++ b/app/test-pmd/cmdline_flow.c
> > > > @@ -342,8 +342,17 @@ enum index {
> > > > ACTION_SET_IPV4_DSCP_VALUE,
> > > > ACTION_SET_IPV6_DSCP,
> > > > ACTION_SET_IPV6_DSCP_VALUE,
> > > > +   ACTION_DBDF,
> > > >  };
> > > >
> > > > +#define DBDF_KEY_LENGTH 20
> > > > +
> >

Re: [dpdk-dev] [EXT] Re: [PATCH v5] ethdev: add HIGIG2 key field to flow API

2019-10-18 Thread Kiran Kumar Kokkilagadda


> -Original Message-
> From: Ferruh Yigit 
> Sent: Friday, October 18, 2019 11:06 PM
> To: Kiran Kumar Kokkilagadda ; Adrien Mazarguil
> ; Wenzhuo Lu ;
> Jingjing Wu ; Bernard Iremonger
> ; John McNamara
> ; Marko Kovacevic ;
> Thomas Monjalon ; Andrew Rybchenko
> ; Olivier Matz 
> Cc: dev@dpdk.org; ajit.khapa...@broadcom.com
> Subject: [EXT] Re: [dpdk-dev] [PATCH v5] ethdev: add HIGIG2 key field to flow
> API
> 
> External Email
> 
> --
> On 10/18/2019 5:13 AM, kirankum...@marvell.com wrote:
> 
> > From: Kiran Kumar K 
> 
> >
> 
> > Add new rte_flow_item_higig2_hdr in order to match higig2 header.
> 
> > It is a layer 2.5 protocol and used in Broadcom switches.
> 
> > Header format is based on the following document.
> 
> > https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__read.pudn.com_downloads558_doc_comm_2301468_HiGig-
> 5Fprotocol.pdf&d=DwIDaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=owEKckYY4FTmil
> 1Z6oBURwkTThyuRbLAY9LdfiaT6HA&m=QfogB8qcVeClwPxCAkPab3S-
> eGGVwAH1QH3LGdaNa4U&s=8ADdrFBPBhaij7nUt6QRpmlHoVBc2sPtE8egdS58d
> w8&e=
> 
> 
> 
> +1 to have protocol documentation, but what is 'pudn.com'? Is it kind of
> 
> download site? Isn't there any official web site for the protocol?
> 
> 
There is no official doc available for this protocol. This is the only place we 
find the public doc.
> 
> >
> 
> > Signed-off-by: Kiran Kumar K 
> 
> > ---
> 
> > V5 changes:
> 
> > * Changed broadcom to Broadcom
> 
> > * Changed RTE_HIGIG2_H to RTE_HIGIG_H
> 
> > * Fixed meson build
> 
> >
> 
> > V4 Changes:
> 
> > * Removed packed attribute
> 
> >
> 
> > V3 Changes:
> 
> > * Fixed Copyright header
> 
> > * Fixed version info in the subject
> 
> >
> 
> > V2 Changes:
> 
> > * Added support in testpmd to parse the higig2 item
> 
> > * Moved the higig2 header to new file
> 
> > * Added indentation in doc
> 
> >
> 
> >  app/test-pmd/cmdline_flow.c|  33 +++
> 
> >  doc/guides/prog_guide/rte_flow.rst |   8 ++
> 
> >  lib/librte_ethdev/rte_flow.c   |   1 +
> 
> >  lib/librte_ethdev/rte_flow.h   |   7 ++
> 
> >  lib/librte_net/Makefile|   2 +-
> 
> >  lib/librte_net/meson.build |   3 +-
> 
> >  lib/librte_net/rte_higig.h | 138 +
> 
> 
> 
> 'lib/librte_net/' maintainer is Olivier, so by default new file maintainer 
> will
> 
> be Olivier, it is good to get his ack to confirm this before merging patch.
> 
> 
> 
> Also can you please update "doc/api/doxy-api-index.md" to add new
> 'rte_higig.h'
> 
> file so that it can be part of our API documentation.
> 
Will update and send v6.
> 
> 
> btw, 'rte_gre.h' & 'rte_mpls.h' are seems missing in API documentation, 
> another
> 
> patch to add them would be nice if possible.



Re: [dpdk-dev] [EXT] Re: [PATCH v10] ethdev: add HIGIG2 key field to flow API

2019-10-23 Thread Kiran Kumar Kokkilagadda
> -Original Message-
> From: Olivier Matz 
> Sent: Wednesday, October 23, 2019 5:09 PM
> To: Raslan Darawsheh 
> Cc: Ferruh Yigit ; Kiran Kumar Kokkilagadda
> ; Adrien Mazarguil
> ; Wenzhuo Lu ;
> Jingjing Wu ; Bernard Iremonger
> ; John McNamara
> ; Marko Kovacevic ;
> Thomas Monjalon ; Andrew Rybchenko
> ; dev@dpdk.org; ajit.khapa...@broadcom.com
> Subject: [EXT] Re: [dpdk-dev] [PATCH v10] ethdev: add HIGIG2 key field to flow
> API
> 
> External Email
> 
> --
> Hi,
> 
> 
> 
> On Wed, Oct 23, 2019 at 10:50:52AM +, Raslan Darawsheh wrote:
> 
> > Hi,
> 
> >
> 
> > This patch broke the compilation of MLX5 PMD in debug mode:
> 
> >
> 
> >  from /root/dpdk/x86_64-native-linux-
> gcc/include/rte_ethdev_driver.h:18,
> 
> >  from /root/dpdk/drivers/net/mlx5/mlx5_mp.c:11:
> 
> > /root/dpdk/x86_64-native-linux-gcc/include/rte_higig.h:112:2: error: type of
> bit-field 'opcode' is a GCC extension [-Werror=pedantic]
> 
> >   uint16_t opcode:3;
> 
> >   ^
> 
> > /root/dpdk/x86_64-native-linux-gcc/include/rte_higig.h:113:2: error: type of
> bit-field 'resv1' is a GCC extension [-Werror=pedantic]
> 
> >   uint16_t resv1:2;
> 
> >   ^
> 
> > /root/dpdk/x86_64-native-linux-gcc/include/rte_higig.h:114:2: error: type of
> bit-field 'src_t' is a GCC extension [-Werror=pedantic]
> 
> >   uint16_t src_t:1;
> 
> >   ^
> 
> > /root/dpdk/x86_64-native-linux-gcc/include/rte_higig.h:115:2: error: type of
> bit-field 'pfm' is a GCC extension [-Werror=pedantic]
> 
> >   uint16_t pfm:2;
> 
> >   ^
> 
> > /root/dpdk/x86_64-native-linux-gcc/include/rte_higig.h:116:2: error: type of
> bit-field 'resv2' is a GCC extension [-Werror=pedantic]
> 
> >   uint16_t resv2:5;
> 
> >   ^
> 
> > /root/dpdk/x86_64-native-linux-gcc/include/rte_higig.h:117:2: error: type of
> bit-field 'hdr_ext_len' is a GCC extension [-Werror=pedantic]
> 
> >   uint16_t hdr_ext_len:3;
> 
> >
> 
> > and this is with gcc 4.8.5
> 
> 
> 
> From https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__stackoverflow.com_questions_10906238_warning-2Dwhen-2Dusing-
> 2Dbitfield-2Dwith-2Dunsigned-
> 2Dchar&d=DwIBAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=owEKckYY4FTmil1Z6oBUR
> wkTThyuRbLAY9LdfiaT6HA&m=GZ-
> 6cngPycaUlGJT20VEOf9oTcp5PMwk7j1JV1vAQfs&s=SCg5yVPS4zZa8GSn9bl_eUtI
> vBmoDzi35PspWUttIUY&e=
> 
> it seems that it is allowed in c99, so I guess it's a gcc 4.8 bug.
> 
> 
> 
> Adding __extension__ above the struct solves the warnings, I suggest to
> 
> add it.

/**
 *
 * higig2 ppt type1 header.
 */
RTE_STD_C11
struct rte_higig2_ppt_type1 {
uint16_t classification;
uint16_t resv;
uint16_t vid;
#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
uint16_t opcode:3;
uint16_t resv1:2;
uint16_t src_t:1;
uint16_t pfm:2;
uint16_t resv2:5;
uint16_t hdr_ext_len:3;
#elif RTE_BYTE_ORDER == RTE_BIG_ENDIAN
uint16_t pfm:2;
uint16_t src_t:1;
uint16_t resv1:2;
uint16_t opcode:3;
uint16_t hdr_ext_len:3;
uint16_t resv2:5;
#endif
};

I have already added it. RTE_STD_C11 , this is a macro for __extension__. 
/** C extension macro for environments lacking C11 features. */
#if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 201112L
#define RTE_STD_C11 __extension__
#else
#define RTE_STD_C11
#endif

> 
> 
> 
> 
> 
> Olivier



Re: [dpdk-dev] [EXT] Re: [PATCH] ethdev: add HIGIG2 key field to flow API

2019-10-14 Thread Kiran Kumar Kokkilagadda


-Original Message-
From: Andrew Rybchenko  
Sent: Monday, October 14, 2019 12:38 PM
To: Kiran Kumar Kokkilagadda ; Adrien Mazarguil 
; John McNamara ; Marko 
Kovacevic ; Thomas Monjalon ; 
Ferruh Yigit 
Cc: dev@dpdk.org; ajit.khapa...@broadcom.com
Subject: [EXT] Re: [dpdk-dev] [PATCH] ethdev: add HIGIG2 key field to flow API

External Email

--
On 10/14/19 7:29 AM, kirankum...@marvell.com wrote:

> From: Kiran Kumar K 

>

> Add new rte_flow_item_higig2_hdr in order to match higig2 header.

> It is a layer 2.5 protocol and used in broadcom switches.

> Header format is based on the following document.

> https://urldefense.proofpoint.com/v2/url?u=http-3A__read.pudn.com_downloads558_doc_comm_2301468_HiGig-5Fprotocol.pdf&d=DwICaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=owEKckYY4FTmil1Z6oBURwkTThyuRbLAY9LdfiaT6HA&m=E--ycNQdWbQ_5bNBEDLQHwLS3axpOnsTIAtUe290BPU&s=IDtfzPnjppslgp0Wrkv_TGxl1wIqDspU6jNzC3LKciM&e=
>  

>

> Signed-off-by: Kiran Kumar K 

> ---

>   doc/guides/prog_guide/rte_flow.rst |  8 

>   lib/librte_ethdev/rte_flow.c   |  1 +

>   lib/librte_ethdev/rte_flow.h   | 77 ++



As far as I remember support in testpmd is a must requirement

to add new RTE flow API feature.

>> Will add support to parse this item in testpmd, Will be adding basic fields/ 
>> non bitmap fields to parse, like classification and vid. 

>   3 files changed, 86 insertions(+)

>

> diff --git a/doc/guides/prog_guide/rte_flow.rst 
> b/doc/guides/prog_guide/rte_flow.rst

> index 1c837ff13..71365b159 100644

> --- a/doc/guides/prog_guide/rte_flow.rst

> +++ b/doc/guides/prog_guide/rte_flow.rst

> @@ -1290,6 +1290,14 @@ Matches a IP Authentication Header (RFC 4302).

>   - Default ``mask`` matches spi.

>   

>   

> +Item: ``HIGIG2``

> +^

> +

> +Matches a HIGIG2 header field. It is layer 2.5 protocol and used in

> +broadcom switches.

> +

> +- Default ``mask`` matches classification and vlan.

> +





Right now there is one empty line between items and two between

the last item and actions. It should be preserved.

>> Ack, Will add this change.


>   Actions

>   ~~~

>   

> diff --git a/lib/librte_ethdev/rte_flow.c b/lib/librte_ethdev/rte_flow.c

> index 81a85b995..ca0f68016 100644

> --- a/lib/librte_ethdev/rte_flow.c

> +++ b/lib/librte_ethdev/rte_flow.c

> @@ -83,6 +83,7 @@ static const struct rte_flow_desc_data rte_flow_desc_item[] 
> = {

>   MK_FLOW_ITEM(NSH, sizeof(struct rte_flow_item_nsh)),

>   MK_FLOW_ITEM(IGMP, sizeof(struct rte_flow_item_igmp)),

>   MK_FLOW_ITEM(AH, sizeof(struct rte_flow_item_ah)),

> + MK_FLOW_ITEM(HIGIG2, sizeof(struct rte_flow_item_higig2_hdr)),

>   };

>   

>   /** Generate flow_action[] entry. */

> diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h

> index bcfc06cdc..59e37f714 100644

> --- a/lib/librte_ethdev/rte_flow.h

> +++ b/lib/librte_ethdev/rte_flow.h

> @@ -491,6 +491,12 @@ enum rte_flow_item_type {

>*

>*/

>   RTE_FLOW_ITEM_TYPE_AH,

> +

> + /**

> +  * Matches a HIGIG header.

> +  * see struct rte_flow_item_higig2_hdr.

> +  */

> + RTE_FLOW_ITEM_TYPE_HIGIG2,

>   };

>   

>   /**

> @@ -515,6 +521,77 @@ static const struct rte_flow_item_any 
> rte_flow_item_any_mask = {

>   };

>   #endif

>   

> +/**

> + * RTE_FLOW_ITEM_TYPE_HIGIG2

> + * Matches higig2 header.

> + */

> +struct rte_higig2_frc {

> + uint32_t ksop:8;

> + uint32_t resv:3;

> + uint32_t mcst:1;

> + uint32_t tc:4;

> + uint32_t dst_modid:8;

> + uint32_t dst_pid:8;

> + uint32_t src_modid:8;

> + uint32_t src_pid:8;

> + uint32_t lbid:8;

> + uint32_t dp:2;

> + uint32_t resv1:3;

> + uint32_t ppd_type:3;

> +} __attribute__((packed));

> +

> +struct rte_higig2_ppt_type0 {

> + uint32_t dst_t:1;

> + uint32_t dst_tgid:3;

> + uint32_t ingress_tagged:1;

> + uint32_t mirror_only:1;

> + uint32_t mirror_done:1;

> + uint32_t mirror:1;

> + uint32_t res:2;

> + uint32_t l3:1;

> + uint32_t label_present:1;

> + uint32_t vc_label2:4;

> + uint32_t vc_label1:8;

> + uint32_t vc_label0:8;

> + uint32_t vid_high:8;

> + uint32_t vid_low:8;

> + uint32_t pfm:2;

> + uint32_t src_t:1;

> + uint32_t res1:2;

> + uint32_t opcode:3;

> + uint32_t hdr_ext_len:3;

> + uint32_t res2:5;

> +} __attribute__((packed));

> +

> +struct rte_higig2_ppt_type1 {

> + uint32_t classification:16;

> + 

Re: [dpdk-dev] [EXT] Re: [PATCH] ethdev: add HIGIG2 key field to flow API

2019-10-14 Thread Kiran Kumar Kokkilagadda


> -Original Message-
> From: Jerin Jacob 
> Sent: Tuesday, October 15, 2019 11:57 AM
> To: Kiran Kumar Kokkilagadda 
> Cc: Adrien Mazarguil ; Wenzhuo Lu
> ; Jingjing Wu ; Bernard
> Iremonger ; John McNamara
> ; Marko Kovacevic ;
> Thomas Monjalon ; Ferruh Yigit
> ; Andrew Rybchenko ;
> Olivier Matz ; dpdk-dev ; Ajit
> Khaparde 
> Subject: [EXT] Re: [dpdk-dev] [PATCH] ethdev: add HIGIG2 key field to flow API
> 
> External Email
> 
> --
> On Tue, Oct 15, 2019 at 11:51 AM  wrote:
> 
> >
> 
> > From: Kiran Kumar K 
> 
> >
> 
> > Add new rte_flow_item_higig2_hdr in order to match higig2 header.
> 
> > It is a layer 2.5 protocol and used in broadcom switches.
> 
> > Header format is based on the following document.
> 
> > https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__read.pudn.com_downloads558_doc_comm_2301468_HiGig-
> 5Fprotocol.pdf&d=DwIBaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=owEKckYY4FTmil1
> Z6oBURwkTThyuRbLAY9LdfiaT6HA&m=kbv0TGqV_dyrvJzNCIfrjTjIAgmu6mgNlOL
> jUHoUDtk&s=2HV-LJRoSlEnhpQ2fYyq0qul2PeVtgHyWI3H75vbrbc&e=
> 
> >
> 
> > Signed-off-by: Kiran Kumar K 
> 
> > ---
> 
> >
> 
> > V2 Changes:
> 
> > * Added support in testpmd to parse the higig2 item
> 
> > * Moved the higig2 header to new file
> 
> > * Added indentation in doc
> 
> >
> 
> 
> 
> >
> 
> >  include $(RTE_SDK)/mk/rte.lib.mk
> 
> > diff --git a/lib/librte_net/rte_higig.h b/lib/librte_net/rte_higig.h
> 
> > new file mode 100644
> 
> > index 0..121c0a850
> 
> > --- /dev/null
> 
> > +++ b/lib/librte_net/rte_higig.h
> 
> > @@ -0,0 +1,138 @@
> 
> > +
> 
> > +/* SPDX-License-Identifier: BSD-3-Clause
> 
> > + * Copyright 2016 6WIND S.A.
> 
> 
> 
> Copy and paste error.

Will fix in V3.




Re: [dpdk-dev] [EXT] Re: [PATCH] ethdev: add HIGIG2 key field to flow API

2019-10-15 Thread Kiran Kumar Kokkilagadda



> -Original Message-
> From: Stephen Hemminger 
> Sent: Tuesday, October 15, 2019 10:17 PM
> To: Kiran Kumar Kokkilagadda 
> Cc: Adrien Mazarguil ; John McNamara
> ; Marko Kovacevic ;
> Thomas Monjalon ; Ferruh Yigit
> ; Andrew Rybchenko ;
> dev@dpdk.org; ajit.khapa...@broadcom.com
> Subject: [EXT] Re: [dpdk-dev] [PATCH] ethdev: add HIGIG2 key field to flow API
> 
> External Email
> 
> --
> On Mon, 14 Oct 2019 09:59:56 +0530
>  wrote:
> 
> > +/**
> > + * RTE_FLOW_ITEM_TYPE_HIGIG2
> > + * Matches higig2 header.
> > + */
> > +struct rte_higig2_frc {
> > +   uint32_t ksop:8;
> > +   uint32_t resv:3;
> > +   uint32_t mcst:1;
> > +   uint32_t tc:4;
> > +   uint32_t dst_modid:8;
> > +   uint32_t dst_pid:8;
> > +   uint32_t src_modid:8;
> > +   uint32_t src_pid:8;
> > +   uint32_t lbid:8;
> > +   uint32_t dp:2;
> > +   uint32_t resv1:3;
> > +   uint32_t ppd_type:3;
> > +} __attribute__((packed));
> > +
> > +struct rte_higig2_ppt_type0 {
> > +   uint32_t dst_t:1;
> > +   uint32_t dst_tgid:3;
> > +   uint32_t ingress_tagged:1;
> > +   uint32_t mirror_only:1;
> > +   uint32_t mirror_done:1;
> > +   uint32_t mirror:1;
> > +   uint32_t res:2;
> > +   uint32_t l3:1;
> > +   uint32_t label_present:1;
> > +   uint32_t vc_label2:4;
> > +   uint32_t vc_label1:8;
> > +   uint32_t vc_label0:8;
> > +   uint32_t vid_high:8;
> > +   uint32_t vid_low:8;
> > +   uint32_t pfm:2;
> > +   uint32_t src_t:1;
> > +   uint32_t res1:2;
> > +   uint32_t opcode:3;
> > +   uint32_t hdr_ext_len:3;
> > +   uint32_t res2:5;
> > +} __attribute__((packed));
> > +
> > +struct rte_higig2_ppt_type1 {
> > +   uint32_t classification:16;
> > +   uint32_t resv:16;
> > +   uint32_t vid:16;
> > +   uint32_t pfm:2;
> > +   uint32_t src_t:1;
> > +   uint32_t resv1:2;
> > +   uint32_t opcode:3;
> > +   uint32_t hdr_ext_len:3;
> > +   uint32_t resv2:5;
> > +} __attribute__((packed));
> > +
> > +RTE_STD_C11
> > +struct rte_flow_item_higig2_hdr {
> > +   struct rte_higig2_frc fcr;
> > +   union {
> > +   struct rte_higig2_ppt_type0 ppt0;
> > +   struct rte_higig2_ppt_type1 ppt1;
> > +   };
> > +} __attribute__((packed));
> > +
> > +/** Default mask for RTE_FLOW_ITEM_TYPE_HIGIG2. */ #ifndef
> > +__cplusplus static const struct rte_flow_item_higig2_hdr
> > +rte_flow_item_higig2_hdr_mask = {
> > +   .ppt1.classification = 0x,
> > +   .ppt1.vid = 0xfff,
> > +};
> > +#endif
> > +
> 
> Why do all these structures have to be packed. They are all uint32.
Will fix in V4.



[dpdk-dev] Clarification on RTE Flow action

2019-09-25 Thread Kiran Kumar Kokkilagadda
Hi,
    We have the following use case and need clarification on which RTE Flow 
action suits the requirement (ACTION_VF and ACTION_PORT_ID, ..).

We have 2 PF's (pf0, pf1) and corresponding VF's (pf0_vf0 , pf1_vf0). And we 
have 3 applications running.
1st application on pf0 and pf1
2nd application on pf0_vf0
3rd application on pf1_vf0.

We want to direct the traffic matching condition1 from application 1 (traffic  
from both pf0 & pf1) needs to send to  application 2 (pf0_vf0)
And matching condition2 from application 1 (traffic from both pf0 & pf1) needs 
to send to application 3 (pf1_vf0).

To summarize, we need to send traffic from pf0 to pf1_vf0 and traffic from pf1 
to pf0_vf0.
If we use ACTION_VF, it is not possible to send the traffic across PF. 
If we use ACTION_PORT_ID and if we have multiple applications running, then 
port id starts with 0 on multiple applications. So, we can't use it.

So, is there any other action we can use to accommodate this behavior? Or can 
we add new action ?
And if we don't want to add new action, is there any suggestion on how to 
handle this case?



Thanks,
Kiran Kumar





Re: [dpdk-dev] [EXT] Re: [PATCH v2 1/2] ethdev: add level support for RSS offload types

2020-08-13 Thread Kiran Kumar Kokkilagadda


From: Ajit Khaparde 
Sent: Saturday, August 8, 2020 8:10 PM
To: Kiran Kumar Kokkilagadda 
Cc: Andrew Rybchenko ; Ferruh Yigit 
; Thomas Monjalon ; 
beilei.x...@intel.com; ch...@att.com; cloud.wangxiao...@huawei.com; 
cristian.dumitre...@intel.com; dev@dpdk.org; gr...@u256.net; 
hemant.agra...@nxp.com; humi...@huawei.com; hyon...@cisco.com; 
jasvinder.si...@intel.com; Jerin Jacob Kollanukkaran ; 
jia@intel.com; jingjing...@intel.com; johnd...@cisco.com; 
keith.wi...@intel.com; Liron Himi ; ma...@mellanox.com; 
Nithin Kumar Dabilpuram ; or...@mellanox.com; 
qi.z.zh...@intel.com; qiming.y...@intel.com; rahul.lakkire...@chelsio.com; 
Rasesh Mody ; rosen...@intel.com; sachin.sax...@nxp.com; 
shah...@mellanox.com; Shahed Shaikh ; 
somnath.ko...@broadcom.com; viachesl...@mellanox.com; wei.zh...@intel.com; 
xavier.hu...@huawei.com; xuanziya...@huawei.com; yisen.zhu...@huawei.com; 
zhouguoy...@huawei.com
Subject: [EXT] Re: [dpdk-dev][PATCH v2 1/2] ethdev: add level support for RSS 
offload types

External Email

On Sat, Aug 8, 2020 at 7:36 AM 
mailto:kirankum...@marvell.com>> wrote:
From: Kiran Kumar K mailto:kirankum...@marvell.com>>

This patch reserves 2 bits as input selection to select Inner and
outer layers for RSS computation. It is combined with existing
ETH_RSS_* to choose Inner or outer layers for L2, L3 and L4.
How do you plan to use this? Do you need to make any changes to testpmd?

I will update in the next version.


This functionality already exists in rte_flow through level parameter in
RSS action configuration rte_flow_action_rss.

Signed-off-by: Kiran Kumar K 
mailto:kirankum...@marvell.com>>
---
v2 changes:
* Reserved bit 50 & 51

 lib/librte_ethdev/rte_ethdev.h | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index d29930fd8..28184cc85 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -552,6 +552,33 @@ struct rte_eth_rss_conf {
 #define RTE_ETH_RSS_L3_PRE64  (1ULL << 53)
 #define RTE_ETH_RSS_L3_PRE96  (1ULL << 52)

+/*
+ * We use the following macros to combine with the above layers to choose
+ * inner and outer layers or both for RSS computation.
+ * Note: Default is 0: inner layers, 1: outer layers, 2: both
+ * bit 50 and 51 are reserved for this.
+ */
+
+/**
+ * Level 0, It basically stands for the innermost encapsulation level RSS
+ * can be performed on according to PMD and device capabilities.
+ */
+#define ETH_RSS_LEVEL_INNER(0ULL << 50)
+/**
+ * Level 1, It basically stands for the outermost encapsulation level RSS
+ * can be performed on according to PMD and device capabilities.
+ */
+#define ETH_RSS_LEVEL_OUTER(1ULL << 50)
+/**
+ * Level 2, It basically stands for the both inner and outermost
+ * encapsulation level RSS can be performed on according to PMD and
+ * device capabilities.
+ */
+#define ETH_RSS_LEVEL_INNER_OUTER  (2ULL << 50)
+#define ETH_RSS_LEVEL_MASK(3ULL << 50)
+
+#define ETH_RSS_LEVEL(rss_hf) ((rss_hf & ETH_RSS_LEVEL_MASK) >> 50)
+
 /**
  * For input set change of hash filter, if SRC_ONLY and DST_ONLY of
  * the same level are used simultaneously, it is the same case as
--
2.25.1


Re: [dpdk-dev] [EXT] Re: [PATCH v3 2/2] net/octeontx2: add rss hash level support

2020-08-18 Thread Kiran Kumar Kokkilagadda


> -Original Message-
> From: Jerin Jacob 
> Sent: Tuesday, August 18, 2020 3:34 PM
> To: Kiran Kumar Kokkilagadda 
> Cc: Jerin Jacob Kollanukkaran ; Nithin Kumar Dabilpuram
> ; dpdk-dev ; Thomas Monjalon
> ; Ferruh Yigit ; Andrew
> Rybchenko ; Ori Kam ;
> Ziyang Xuan ; Xiaoyun Wang
> ; Guoyang Zhou
> ; Rosen Xu ; Beilei Xing
> ; jia@intel.com; Rasesh Mody
> ; Shahed Shaikh ; Qiming Yang
> ; Qi Zhang ; Wiles, Keith
> ; Hemant Agrawal ;
> Sachin Saxena ; Zhao1, Wei ;
> John Daley ; Hyong Youb Kim ;
> Chas Williams ; Matan Azrad ;
> Shahaf Shuler ; Slava Ovsiienko
> ; Rahul Lakkireddy
> ; Gaetan Rivet ; Liron Himi
> ; Jingjing Wu ; Wei Hu (Xavier
> ; Min Hu (Connor ; Yisen
> Zhuang ; Ajit Khaparde
> ; Somnath Kotur
> ; Jasvinder Singh
> ; Cristian Dumitrescu
> 
> Subject: [EXT] Re: [dpdk-dev] [PATCH v3 2/2] net/octeontx2: add rss hash level
> support
> 
> External Email
> 
> ------
> On Tue, Aug 18, 2020 at 12:52 PM  wrote:
> >
> > From: Kiran Kumar K 
> >
> > Add support to choose rss hash level from ethdev rss config.
> >
> > Signed-off-by: Kiran Kumar K 
> > ---
> >  drivers/net/octeontx2/otx2_ethdev.h | 4 +++-
> >  drivers/net/octeontx2/otx2_rss.c| 9 +++--
> >  2 files changed, 10 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/net/octeontx2/otx2_ethdev.h
> > b/drivers/net/octeontx2/otx2_ethdev.h
> > index e9efe52bb..953445ecb 100644
> > --- a/drivers/net/octeontx2/otx2_ethdev.h
> > +++ b/drivers/net/octeontx2/otx2_ethdev.h
> > @@ -119,7 +119,9 @@
> >  #define NIX_RSS_OFFLOAD(ETH_RSS_PORT | ETH_RSS_IP |
> ETH_RSS_UDP |\
> >  ETH_RSS_TCP | ETH_RSS_SCTP | \
> >  ETH_RSS_TUNNEL | ETH_RSS_L2_PAYLOAD | \
> > -NIX_RSS_L3_L4_SRC_DST)
> > +NIX_RSS_L3_L4_SRC_DST | 
> > ETH_RSS_LEVEL_INNER | \
> > +ETH_RSS_LEVEL_OUTER | \
> > +ETH_RSS_LEVEL_INNER_OUTER)
> 
> Since it is value 1 and 2, for bitmask purpose, shouldn't be
> ETH_RSS_LEVEL_MASK  instead of ETH_RSS_LEVEL_OUTER |
> ETH_RSS_LEVEL_INNER_OUTER


Will update in V4.



Re: [dpdk-dev] [EXT] Re: [PATCH v4 1/2] ethdev: add level support for RSS offload types

2020-08-18 Thread Kiran Kumar Kokkilagadda
Hi Jeff,


> -Original Message-
> From: Jeff Guo 
> Sent: Tuesday, August 18, 2020 4:22 PM
> To: Kiran Kumar Kokkilagadda ; Wenzhuo Lu
> ; Beilei Xing ; Bernard
> Iremonger ; Thomas Monjalon
> ; Ferruh Yigit ; Andrew
> Rybchenko 
> Cc: dev@dpdk.org; Jerin Jacob Kollanukkaran ;
> or...@mellanox.com; xuanziya...@huawei.com;
> cloud.wangxiao...@huawei.com; zhouguoy...@huawei.com;
> rosen...@intel.com; Rasesh Mody ; Shahed Shaikh
> ; Nithin Kumar Dabilpuram
> ; qiming.y...@intel.com; qi.z.zh...@intel.com;
> keith.wi...@intel.com; hemant.agra...@nxp.com; sachin.sax...@nxp.com;
> wei.zh...@intel.com; johnd...@cisco.com; hyon...@cisco.com;
> ch...@att.com; ma...@mellanox.com; shah...@mellanox.com;
> viachesl...@mellanox.com; rahul.lakkire...@chelsio.com; gr...@u256.net;
> Liron Himi ; jingjing...@intel.com;
> xavier.hu...@huawei.com; humi...@huawei.com;
> yisen.zhu...@huawei.com; ajit.khapa...@broadcom.com;
> somnath.ko...@broadcom.com; jasvinder.si...@intel.com;
> cristian.dumitre...@intel.com
> Subject: [EXT] Re: [dpdk-dev][PATCH v4 1/2] ethdev: add level support for RSS
> offload types
> 
> External Email
> 
> --
> hi, kiran
> 
> On 8/18/2020 6:31 PM, kirankum...@marvell.com wrote:
> > From: Kiran Kumar K 
> >
> > This patch reserves 2 bits as input selection to select Inner and
> > outer layers for RSS computation. It is combined with existing
> > ETH_RSS_* to choose Inner or outer layers for L2, L3 and L4.
> > This functionality already exists in rte_flow through level parameter
> > in RSS action configuration rte_flow_action_rss.
> >
> > Signed-off-by: Kiran Kumar K 
> > ---
> >   app/test-pmd/parameters.c  |  6 ++
> >   lib/librte_ethdev/rte_ethdev.h | 27 +++
> >   2 files changed, 33 insertions(+)
> >
> > diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
> > index 7cb0e3d6e..5f669ff24 100644
> > --- a/app/test-pmd/parameters.c
> > +++ b/app/test-pmd/parameters.c
> > @@ -632,6 +632,8 @@ launch_args_parse(int argc, char** argv)
> > { "forward-mode",   1, 0, 0 },
> > { "rss-ip", 0, 0, 0 },
> > { "rss-udp",0, 0, 0 },
> > +   { "rss-outer",  0, 0, 0 },
> > +   { "rss-inner-outer",0, 0, 0 },
> > { "rxq",1, 0, 0 },
> > { "txq",1, 0, 0 },
> > { "rxd",1, 0, 0 },
> > @@ -1051,6 +1053,10 @@ launch_args_parse(int argc, char** argv)
> > rss_hf = ETH_RSS_IP;
> > if (!strcmp(lgopts[opt_idx].name, "rss-udp"))
> > rss_hf = ETH_RSS_UDP;
> > +   if (!strcmp(lgopts[opt_idx].name, "rss-outer"))
> > +   rss_hf |= ETH_RSS_LEVEL_OUTER;
> > +   if (!strcmp(lgopts[opt_idx].name, "rss-inner-outer"))
> > +   rss_hf |= ETH_RSS_LEVEL_INNER_OUTER;
> > if (!strcmp(lgopts[opt_idx].name, "rxq")) {
> > n = atoi(optarg);
> > if (n >= 0 && check_nb_rxq((queueid_t)n) == 0)
> diff --git
> > a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
> > index d29930fd8..28184cc85 100644
> > --- a/lib/librte_ethdev/rte_ethdev.h
> > +++ b/lib/librte_ethdev/rte_ethdev.h
> > @@ -552,6 +552,33 @@ struct rte_eth_rss_conf {
> >   #define RTE_ETH_RSS_L3_PRE64 (1ULL << 53)
> >   #define RTE_ETH_RSS_L3_PRE96 (1ULL << 52)
> >
> > +/*
> > + * We use the following macros to combine with the above layers to
> > +choose
> > + * inner and outer layers or both for RSS computation.
> > + * Note: Default is 0: inner layers, 1: outer layers, 2: both
> > + * bit 50 and 51 are reserved for this.
> 
> 
> Why not define outermost layer to 0, and the inner layer is on the same
> direction to increase?
> 
> Do you think it would be good to default set outer hash?
> 

Added Inner as default to keep it in sync with rte_flow_rss_action level.
* - @p 0 requests the default behavior. Depending on the packet
 *   type, it can mean outermost, innermost, anything in between or
 *   even no RSS.
 *
 *   It basically stands for the innermost encapsulation level RSS

Re: [dpdk-dev] [EXT] Re: [PATCH v3 1/2] ethdev: add level support for RSS offload types

2020-08-18 Thread Kiran Kumar Kokkilagadda


From: Ajit Khaparde 
Sent: Tuesday, August 18, 2020 11:09 PM
To: Kiran Kumar Kokkilagadda 
Cc: Wenzhuo Lu ; Beilei Xing ; 
Bernard Iremonger ; Thomas Monjalon 
; Ferruh Yigit ; Andrew Rybchenko 
; dpdk-dev ; Jerin Jacob Kollanukkaran 
; Ori Kam ; Ziyang Xuan 
; Xiaoyun Wang ; Guoyang 
Zhou ; Rosen Xu ; 
jia@intel.com; Rasesh Mody ; Shahed Shaikh 
; Nithin Kumar Dabilpuram ; 
Qiming Yang ; Qi Zhang ; Wiles, 
Keith ; Hemant Agrawal ; Sachin 
Saxena ; Zhao1, Wei ; John Daley 
; Hyong Youb Kim ; Chas Williams 
; Matan Azrad ; Shahaf Shuler 
; Viacheslav Ovsiienko ; Rahul 
Lakkireddy ; Gaetan Rivet ; Liron 
Himi ; Jingjing Wu ; Wei Hu (Xavier 
; humi...@huawei.com; yisen.zhu...@huawei.com; Somnath 
Kotur ; Singh, Jasvinder 
; Dumitrescu, Cristian 

Subject: [EXT] Re: [dpdk-dev][PATCH v3 1/2] ethdev: add level support for RSS 
offload types

External Email



On Tue, Aug 18, 2020 at 12:22 AM 
mailto:kirankum...@marvell.com>> wrote:
From: Kiran Kumar K mailto:kirankum...@marvell.com>>

This patch reserves 2 bits as input selection to select Inner and
outer layers for RSS computation. It is combined with existing
ETH_RSS_* to choose Inner or outer layers for L2, L3 and L4.
This functionality already exists in rte_flow through level parameter in
RSS action configuration rte_flow_action_rss.

Signed-off-by: Kiran Kumar K 
mailto:kirankum...@marvell.com>>
---
V3 Changes:
* Added testpmd support.

 app/test-pmd/parameters.c  |  6 ++
 lib/librte_ethdev/rte_ethdev.h | 27 +++
 2 files changed, 33 insertions(+)

diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
index 7cb0e3d6e..5f669ff24 100644
--- a/app/test-pmd/parameters.c
+++ b/app/test-pmd/parameters.c
@@ -632,6 +632,8 @@ launch_args_parse(int argc, char** argv)
{ "forward-mode",   1, 0, 0 },
{ "rss-ip", 0, 0, 0 },
{ "rss-udp",0, 0, 0 },
+   { "rss-outer",  0, 0, 0 },
+   { "rss-inner-outer",0, 0, 0 },

If we don't specify any of these two, it is inner RSS?
Yes, that is correct.

If I configure rss-outer, how do I switch to inner RSS?
Will add support to config/reset using port config in the next version.

Thanks

{ "rxq",1, 0, 0 },
{ "txq",1, 0, 0 },
{ "rxd",1, 0, 0 },
@@ -1051,6 +1053,10 @@ launch_args_parse(int argc, char** argv)
rss_hf = ETH_RSS_IP;
if (!strcmp(lgopts[opt_idx].name, "rss-udp"))
rss_hf = ETH_RSS_UDP;
+   if (!strcmp(lgopts[opt_idx].name, "rss-outer"))
+   rss_hf |= ETH_RSS_LEVEL_OUTER;
+   if (!strcmp(lgopts[opt_idx].name, "rss-inner-outer"))
+   rss_hf |= ETH_RSS_LEVEL_INNER_OUTER;
if (!strcmp(lgopts[opt_idx].name, "rxq")) {
n = atoi(optarg);
if (n >= 0 && check_nb_rxq((queueid_t)n) == 0)
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index d29930fd8..28184cc85 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -552,6 +552,33 @@ struct rte_eth_rss_conf {
 #define RTE_ETH_RSS_L3_PRE64  (1ULL << 53)
 #define RTE_ETH_RSS_L3_PRE96  (1ULL << 52)

+/*
+ * We use the following macros to combine with the above layers to choose
+ * inner and outer layers or both for RSS computation.
+ * Note: Default is 0: inner layers, 1: outer layers, 2: both
+ * bit 50 and 51 are reserved for this.
+ */
+
+/**
+ * Level 0, It basically stands for the innermost encapsulation level RSS
+ * can be performed on according to PMD and device capabilities.
+ */
+#define ETH_RSS_LEVEL_INNER(0ULL << 50)
+/**
+ * Level 1, It basically stands for the outermost encapsulation level RSS
+ * can be performed on according to PMD and device capabilities.
+ */
+#define ETH_RSS_LEVEL_OUTER(1ULL << 50)
+/**
+ * Level 2, It basically stands for the both inner and outermost
+ * encapsulation level RSS can be performed on according to PMD and
+ * device capabilities.
+ */
+#define ETH_RSS_LEVEL_INNER_OUTER  (2ULL << 50)
+#define ETH_RSS_LEVEL_MASK(3ULL << 50)
+
+#define ETH_RSS_LEVEL(rss_hf) ((rss_hf & ETH_RSS_LEVEL_MASK) >> 50)
+
 /**
  * For input set change of hash filter, if SRC_ONLY and DST_ONLY of
  * the same level are used simultaneously, it is the same case as
--
2.25.1


Re: [dpdk-dev] [EXT] Re: [PATCH v5 1/2] ethdev: add level support for RSS offload types

2020-08-21 Thread Kiran Kumar Kokkilagadda


From: Ajit Khaparde 
Sent: Thursday, August 20, 2020 8:49 AM
To: Kiran Kumar Kokkilagadda 
Cc: Wenzhuo Lu ; Beilei Xing ; 
Bernard Iremonger ; Thomas Monjalon 
; Ferruh Yigit ; Andrew Rybchenko 
; dpdk-dev ; Jerin Jacob Kollanukkaran 
; Ori Kam ; Ziyang Xuan 
; Xiaoyun Wang ; Guoyang 
Zhou ; Rosen Xu ; 
jia@intel.com; Rasesh Mody ; Shahed Shaikh 
; Nithin Kumar Dabilpuram ; 
Qiming Yang ; Qi Zhang ; Wiles, 
Keith ; Hemant Agrawal ; Sachin 
Saxena ; Zhao1, Wei ; John Daley 
; Hyong Youb Kim ; Chas Williams 
; Matan Azrad ; Shahaf Shuler 
; Viacheslav Ovsiienko ; Rahul 
Lakkireddy ; Gaetan Rivet ; Liron 
Himi ; Jingjing Wu ; Wei Hu (Xavier 
; humi...@huawei.com; yisen.zhu...@huawei.com; Somnath 
Kotur ; Singh, Jasvinder 
; Dumitrescu, Cristian 

Subject: [EXT] Re: [dpdk-dev][PATCH v5 1/2] ethdev: add level support for RSS 
offload types

External Email



On Tue, Aug 18, 2020 at 11:05 PM 
mailto:kirankum...@marvell.com>> wrote:
From: Kiran Kumar K mailto:kirankum...@marvell.com>>

This patch reserves 2 bits as input selection to select Inner and
outer layers for RSS computation. It is combined with existing
ETH_RSS_* to choose Inner or outer layers for L2, L3 and L4.
This functionality already exists in rte_flow through level parameter in
RSS action configuration rte_flow_action_rss.

Signed-off-by: Kiran Kumar K 
mailto:kirankum...@marvell.com>>
---
V5 Changes:
* Added support to set rss level type from port config in testpmd

 app/test-pmd/cmdline.c | 11 ++-
 app/test-pmd/parameters.c  |  6 ++
Can you split this into testpmd and ethdev patches.
Becomes easy to reference, fix.

Will send V6.

 lib/librte_ethdev/rte_ethdev.h | 27 +++
 3 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 0a6ed85f3..4eafee8c8 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -2334,7 +2334,16 @@ cmd_config_rss_parsed(void *parsed_result,
rss_conf.rss_hf = ETH_RSS_GTPU;
else if (!strcmp(res->value, "none"))
rss_conf.rss_hf = 0;
-   else if (!strcmp(res->value, "default"))
+   else if (!strcmp(res->value, "level-inner")) {
+   rss_hf &= (~ETH_RSS_LEVEL_MASK);
+   rss_conf.rss_hf = (rss_hf | ETH_RSS_LEVEL_INNER);
+   } else if (!strcmp(res->value, "level-outer")) {
+   rss_hf &= (~ETH_RSS_LEVEL_MASK);
+   rss_conf.rss_hf = (rss_hf | ETH_RSS_LEVEL_OUTER);
+   } else if (!strcmp(res->value, "level-inner-outer")) {
+   rss_hf &= (~ETH_RSS_LEVEL_MASK);
+   rss_conf.rss_hf = (rss_hf | ETH_RSS_LEVEL_INNER_OUTER);
+   } else if (!strcmp(res->value, "default"))
use_default = 1;
else if (isdigit(res->value[0]) && atoi(res->value) > 0 &&
atoi(res->value) < 64)
diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
index 7cb0e3d6e..5f669ff24 100644
--- a/app/test-pmd/parameters.c
+++ b/app/test-pmd/parameters.c
@@ -632,6 +632,8 @@ launch_args_parse(int argc, char** argv)
{ "forward-mode",   1, 0, 0 },
{ "rss-ip", 0, 0, 0 },
{ "rss-udp",0, 0, 0 },
+   { "rss-outer",  0, 0, 0 },
+   { "rss-inner-outer",0, 0, 0 },
{ "rxq",1, 0, 0 },
{ "txq",1, 0, 0 },
{ "rxd",1, 0, 0 },
@@ -1051,6 +1053,10 @@ launch_args_parse(int argc, char** argv)
rss_hf = ETH_RSS_IP;
if (!strcmp(lgopts[opt_idx].name, "rss-udp"))
rss_hf = ETH_RSS_UDP;
+   if (!strcmp(lgopts[opt_idx].name, "rss-outer"))
+   rss_hf |= ETH_RSS_LEVEL_OUTER;
+   if (!strcmp(lgopts[opt_idx].name, "rss-inner-outer"))
+   rss_hf |= ETH_RSS_LEVEL_INNER_OUTER;
if (!strcmp(lgopts[opt_idx].name, "rxq")) {
n = atoi(optarg);
if (n >= 0 && check_nb_rxq((queueid_t)n) == 0)
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index d29930fd8..28184cc85 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -552,6 +552,33 @@ struct rte_eth_rss_conf {
 #define RTE_ETH_RSS_L3_PRE64  (1ULL << 53)
 #define RTE_ETH_RSS_L3_PRE96  (1ULL << 52)

+/*
+ * We use the 

Re: [dpdk-dev] [EXT] Re: [PATCH v7 1/3] ethdev: add level support for RSS offload types

2020-09-01 Thread Kiran Kumar Kokkilagadda


> -Original Message-
> From: Ferruh Yigit 
> Sent: Tuesday, September 1, 2020 7:08 PM
> To: Kiran Kumar Kokkilagadda ; Thomas Monjalon
> ; Andrew Rybchenko 
> Cc: dev@dpdk.org; Jerin Jacob Kollanukkaran ;
> or...@mellanox.com; xuanziya...@huawei.com;
> cloud.wangxiao...@huawei.com; zhouguoy...@huawei.com;
> rosen...@intel.com; beilei.x...@intel.com; jia@intel.com; Rasesh Mody
> ; Shahed Shaikh ; Nithin Kumar
> Dabilpuram ; qiming.y...@intel.com;
> qi.z.zh...@intel.com; keith.wi...@intel.com; hemant.agra...@nxp.com;
> sachin.sax...@nxp.com; wei.zh...@intel.com; johnd...@cisco.com;
> hyon...@cisco.com; ch...@att.com; ma...@mellanox.com;
> shah...@mellanox.com; viachesl...@mellanox.com;
> rahul.lakkire...@chelsio.com; gr...@u256.net; Liron Himi
> ; jingjing...@intel.com; xavier.hu...@huawei.com;
> humi...@huawei.com; yisen.zhu...@huawei.com;
> ajit.khapa...@broadcom.com; somnath.ko...@broadcom.com;
> jasvinder.si...@intel.com; cristian.dumitre...@intel.com
> Subject: [EXT] Re: [dpdk-dev][PATCH v7 1/3] ethdev: add level support for RSS
> offload types
> 
> External Email
> 
> ------
> On 9/1/2020 4:27 AM, kirankum...@marvell.com wrote:
> > From: Kiran Kumar K 
> >
> > This patch reserves 2 bits as input selection to select Inner and
> > outer encapsulation level for RSS computation. It is combined with
> > existing
> > ETH_RSS_* to choose Inner or outer layers.
> > This functionality already exists in rte_flow through level parameter
> > in RSS action configuration rte_flow_action_rss.
> >
> > Signed-off-by: Kiran Kumar K 
> > ---
> > V7 Changes:
> > * Re-worked to keep it in sync with rte_flow_action_rss and support
> > upto
> > 3 levels.
> > * Addressed testpmd review comments.
> >
> >   lib/librte_ethdev/rte_ethdev.h | 27 +++
> >   1 file changed, 27 insertions(+)
> >
> > diff --git a/lib/librte_ethdev/rte_ethdev.h
> > b/lib/librte_ethdev/rte_ethdev.h index 70295d7ab..13e49bbd7 100644
> > --- a/lib/librte_ethdev/rte_ethdev.h
> > +++ b/lib/librte_ethdev/rte_ethdev.h
> > @@ -552,6 +552,33 @@ struct rte_eth_rss_conf {
> >   #define RTE_ETH_RSS_L3_PRE64 (1ULL << 53)
> >   #define RTE_ETH_RSS_L3_PRE96 (1ULL << 52)
> >
> > +/*
> > + * We use the following macros to combine with the above layers to
> > +choose
> > + * inner and outer layers or both for RSS computation.
> > + * bit 50 and 51 are reserved for this.
> > + */
> > +
> > +/** level 0, requests the default behavior. Depending on the packet
> > + * type, it can mean outermost, innermost, anything in between or even no
> RSS.
> > + * It basically stands for the innermost encapsulation level RSS
> > + * can be performed on according to PMD and device capabilities.
> > + */
> > +#define ETH_RSS_LEVEL_0 (0ULL << 50)
> 
> I can see from history how this is involved, but the 'ETH_RSS_LEVEL_0' naming 
> is
> not really clear what it is, the naming in v6 is more clear.
> 
> What about following one:
> 0 -> LEVEL_PMD_DEFAULT
> 1 -> LEVEL_OUTER
> 2 -> LEVEL_INNER
> 3 -> LEVEL_INNER_OUTER
> 
> This doesn't exactly match to rte_flow one, but closer than v6 one. This ends
> with max level 2. And defines a way to say both inner and outer.

This one looks good to me. If everyone is ok with the proposed changes, I will 
send V8.

> 
> > +
> > +/** level 1,  requests RSS to be performed on the outermost packet
> > + * encapsulation level.
> > + */
> > +#define ETH_RSS_LEVEL_1 (1ULL << 50)
> > +
> > +/** level 2,  requests RSS to be performed on the
> > + * specified inner packet encapsulation level, from outermost to
> > + * innermost (lower to higher values).
> > + */
> > +#define ETH_RSS_LEVEL_2(2ULL << 50)
> 
> I can see you are trying to copy rte_flow usage, but this doesn't really makes
> sense here. Where the value of the level is defined in this case? If not 
> defined
> how the PMD knows which level to use?
> 
> > +#define ETH_RSS_LEVEL_MASK (3ULL << 50)
> > +
> > +#define ETH_RSS_LEVEL(rss_hf) ((rss_hf & ETH_RSS_LEVEL_MASK) >> 50)
> > +
> >   /**
> >* For input set change of hash filter, if SRC_ONLY and DST_ONLY of
> >* the same level are used simultaneously, it is the same case as
> > --
> > 2.25.1
> >



Re: [dpdk-dev] [EXT] Re: [PATCH v7 1/3] ethdev: add level support for RSS offload types

2020-09-03 Thread Kiran Kumar Kokkilagadda


From: Ajit Khaparde 
Sent: Tuesday, September 1, 2020 10:42 PM
To: Kiran Kumar Kokkilagadda 
Cc: Ferruh Yigit ; Thomas Monjalon 
; Andrew Rybchenko ; 
dev@dpdk.org; Jerin Jacob Kollanukkaran ; 
or...@mellanox.com; xuanziya...@huawei.com; cloud.wangxiao...@huawei.com; 
zhouguoy...@huawei.com; rosen...@intel.com; beilei.x...@intel.com; 
jia@intel.com; Rasesh Mody ; Shahed Shaikh 
; Nithin Kumar Dabilpuram ; 
qiming.y...@intel.com; qi.z.zh...@intel.com; keith.wi...@intel.com; 
hemant.agra...@nxp.com; sachin.sax...@nxp.com; wei.zh...@intel.com; 
johnd...@cisco.com; hyon...@cisco.com; ch...@att.com; ma...@mellanox.com; 
shah...@mellanox.com; viachesl...@mellanox.com; rahul.lakkire...@chelsio.com; 
gr...@u256.net; Liron Himi ; jingjing...@intel.com; 
xavier.hu...@huawei.com; humi...@huawei.com; yisen.zhu...@huawei.com; 
somnath.ko...@broadcom.com; jasvinder.si...@intel.com; 
cristian.dumitre...@intel.com
Subject: Re: [EXT] Re: [dpdk-dev][PATCH v7 1/3] ethdev: add level support for 
RSS offload types



On Tue, Sep 1, 2020 at 7:27 AM Kiran Kumar Kokkilagadda 
mailto:kirankum...@marvell.com>> wrote:


> -Original Message-
> From: Ferruh Yigit mailto:ferruh.yi...@intel.com>>
> Sent: Tuesday, September 1, 2020 7:08 PM
> To: Kiran Kumar Kokkilagadda 
> mailto:kirankum...@marvell.com>>; Thomas Monjalon
> mailto:tho...@monjalon.net>>; Andrew Rybchenko 
> mailto:arybche...@solarflare.com>>
> Cc: dev@dpdk.org<mailto:dev@dpdk.org>; Jerin Jacob Kollanukkaran 
> mailto:jer...@marvell.com>>;
> or...@mellanox.com<mailto:or...@mellanox.com>; 
> xuanziya...@huawei.com<mailto:xuanziya...@huawei.com>;
> cloud.wangxiao...@huawei.com<mailto:cloud.wangxiao...@huawei.com>; 
> zhouguoy...@huawei.com<mailto:zhouguoy...@huawei.com>;
> rosen...@intel.com<mailto:rosen...@intel.com>; 
> beilei.x...@intel.com<mailto:beilei.x...@intel.com>; 
> jia@intel.com<mailto:jia@intel.com>; Rasesh Mody
> mailto:rm...@marvell.com>>; Shahed Shaikh 
> mailto:shsha...@marvell.com>>; Nithin Kumar
> Dabilpuram mailto:ndabilpu...@marvell.com>>; 
> qiming.y...@intel.com<mailto:qiming.y...@intel.com>;
> qi.z.zh...@intel.com<mailto:qi.z.zh...@intel.com>; 
> keith.wi...@intel.com<mailto:keith.wi...@intel.com>; 
> hemant.agra...@nxp.com<mailto:hemant.agra...@nxp.com>;
> sachin.sax...@nxp.com<mailto:sachin.sax...@nxp.com>; 
> wei.zh...@intel.com<mailto:wei.zh...@intel.com>; 
> johnd...@cisco.com<mailto:johnd...@cisco.com>;
> hyon...@cisco.com<mailto:hyon...@cisco.com>; 
> ch...@att.com<mailto:ch...@att.com>; 
> ma...@mellanox.com<mailto:ma...@mellanox.com>;
> shah...@mellanox.com<mailto:shah...@mellanox.com>; 
> viachesl...@mellanox.com<mailto:viachesl...@mellanox.com>;
> rahul.lakkire...@chelsio.com<mailto:rahul.lakkire...@chelsio.com>; 
> gr...@u256.net<mailto:gr...@u256.net>; Liron Himi
> mailto:lir...@marvell.com>>; 
> jingjing...@intel.com<mailto:jingjing...@intel.com>; 
> xavier.hu...@huawei.com<mailto:xavier.hu...@huawei.com>;
> humi...@huawei.com<mailto:humi...@huawei.com>; 
> yisen.zhu...@huawei.com<mailto:yisen.zhu...@huawei.com>;
> ajit.khapa...@broadcom.com<mailto:ajit.khapa...@broadcom.com>; 
> somnath.ko...@broadcom.com<mailto:somnath.ko...@broadcom.com>;
> jasvinder.si...@intel.com<mailto:jasvinder.si...@intel.com>; 
> cristian.dumitre...@intel.com<mailto:cristian.dumitre...@intel.com>
> Subject: [EXT] Re: [dpdk-dev][PATCH v7 1/3] ethdev: add level support for RSS
> offload types
>
> External Email
>
> --
> On 9/1/2020 4:27 AM, kirankum...@marvell.com<mailto:kirankum...@marvell.com> 
> wrote:
> > From: Kiran Kumar K 
> > mailto:kirankum...@marvell.com>>
> >
> > This patch reserves 2 bits as input selection to select Inner and
> > outer encapsulation level for RSS computation. It is combined with
> > existing
> > ETH_RSS_* to choose Inner or outer layers.
> > This functionality already exists in rte_flow through level parameter
> > in RSS action configuration rte_flow_action_rss.
> >
> > Signed-off-by: Kiran Kumar K 
> > mailto:kirankum...@marvell.com>>
> > ---
> > V7 Changes:
> > * Re-worked to keep it in sync with rte_flow_action_rss and support
> > upto
> > 3 levels.
> > * Addressed testpmd review comments.
> >
> >   lib/librte_ethdev/rte_ethdev.h | 27 +++
> >   1 file changed, 27 insertions(+)
> >
> > diff --git a/lib/librte_ethdev/rte_ethdev.h
> > b/lib/librte_ethdev/rte_ethdev.h index 70

RE: [EXTERNAL] [PATCH] test/graph: fix graph autotest second test failure

2024-10-22 Thread Kiran Kumar Kokkilagadda


From: Huichao cai 
Sent: Tuesday, October 22, 2024 4:58 PM
To: Jerin Jacob ; Kiran Kumar Kokkilagadda 
; Nithin Kumar Dabilpuram ; 
yanzhirun_...@163.com
Cc: dev@dpdk.org
Subject: [EXTERNAL] [PATCH] test/graph: fix graph autotest second test failure

Start dpdk-test, execute the graph_autotest test command for the first time, 
the result is successful, and then test again, the result is always failing, 
modify this problem to make this test command idempotent. Signed-off-by: 
Huichao cai 


Start dpdk-test, execute the graph_autotest test command for

the first time, the result is successful, and then test again,

the result is always failing, modify this problem to make this

test command idempotent.



Signed-off-by: Huichao cai mailto:chcch...@163.com>>

---

 app/test/test_graph.c | 21 -

 1 file changed, 12 insertions(+), 9 deletions(-)



diff --git a/app/test/test_graph.c b/app/test/test_graph.c

index 2840a25..16a1a90 100644

--- a/app/test/test_graph.c

+++ b/app/test/test_graph.c

@@ -552,7 +552,7 @@ struct test_node_register {

  tm->test_node[0].idx = node_id;



  dummy_id = rte_node_clone(node_id, "test_node00");

-if (rte_node_is_invalid(dummy_id)) {

+   if (rte_node_is_invalid(dummy_id) && (rte_errno != EEXIST)) {

 printf("Got invalid id when clone, Expecting 
fail\n");

 return -1;

  }



I think cloned nodes are not being added to any graph, so, not being freed. So, 
we are seeing this issue.

Instead of suppressing the errors, could you create a dummy graph and add the 
nodes to graph and call graph destroy.

This will free the cloned nodes and we don’t see this problem.







@@ -565,12 +565,14 @@ struct test_node_register {

  }



  for (i = 1; i < MAX_NODES; i++) {

-tm->test_node[i].idx =

-   rte_node_clone(node_id, 
tm->test_node[i].node.name);

-if (rte_node_is_invalid(tm->test_node[i].idx)) {

+   dummy_id = rte_node_clone(node_id, 
tm->test_node[i].node.name);

+   if (rte_node_is_invalid(dummy_id) && (rte_errno != 
EEXIST)) {

printf("Got invalid node id\n");

return -1;

 }

+

+   if (!rte_node_is_invalid(dummy_id))

+  tm->test_node[i].idx = dummy_id;

  }



  /* Clone from cloned node should fail */

@@ -640,7 +642,7 @@ struct test_node_register {



  node_id = rte_node_from_name("test_node00");

  dummy_node_id = rte_node_clone(node_id, "dummy_node");

-if (rte_node_is_invalid(dummy_node_id)) {

+   if (rte_node_is_invalid(dummy_node_id) && (rte_errno != EEXIST)) {

 printf("Got invalid node id\n");

 return -1;

  }

@@ -672,7 +674,7 @@ struct test_node_register {

  main_graph_id = rte_graph_from_name("worker0");

  if (main_graph_id == RTE_GRAPH_ID_INVALID) {

 printf("Must create main graph first\n");

-ret = -1;

+   return -1;

  }



  graph_conf.dispatch.mp_capacity = 1024;

@@ -682,7 +684,7 @@ struct test_node_register {



  if (cloned_graph_id == RTE_GRAPH_ID_INVALID) {

 printf("Graph creation failed with error = %d\n", 
rte_errno);

-ret = -1;

+   return -1;

  }



  if (strcmp(rte_graph_id_to_name(cloned_graph_id), 
"worker0-cloned-test0")) {

@@ -787,7 +789,7 @@ struct test_node_register {

  cloned_graph_id = rte_graph_clone(graph_id, "cloned-test1", 
&graph_conf);

  node = rte_graph_node_get(cloned_graph_id, nid);



-if (node->dispatch.lcore_id != worker_lcore) {

+   if (!node || node->dispatch.lcore_id != worker_lcore) {

 printf("set node affinity failed\n");

 ret = -1;

  }

@@ -859,7 +861,8 @@ struct test_node_register {

  }



  graph = rte_graph_lookup("worker0-cloned-test3");

-if (rte_graph_worker_model_get(graph) != 
RTE_GRAPH_MODEL_MCORE_DISPATCH) {

+   if (!graph || rte_graph_worker_model_get(graph) !=

+   RTE_GRAPH_MODEL_MCORE_DISPATCH) {

 printf("Get graph worker model failed\n");

 ret = -1;

  }

--

1.8.3.1




RE: [EXTERNAL] [PATCH] graph: add some print to the node dump

2024-10-22 Thread Kiran Kumar Kokkilagadda



> -Original Message-
> From: Huichao cai 
> Sent: Tuesday, October 22, 2024 5:58 PM
> To: Jerin Jacob ; Kiran Kumar Kokkilagadda
> ; Nithin Kumar Dabilpuram
> ; yanzhirun_...@163.com
> Cc: dev@dpdk.org
> Subject: [EXTERNAL] [PATCH] graph: add some print to the node dump
> 
> The function node_dump add some printing of node information. Signed-off-
> by: Huichao cai  --- lib/graph/graph_debug. c | 11
> ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git
> a/lib/graph/graph_debug. c 
> The function node_dump add some printing of node information.
> 
> Signed-off-by: Huichao cai 
> ---
Acked-by: Kiran Kumar Kokkilagadda 


>  lib/graph/graph_debug.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/graph/graph_debug.c b/lib/graph/graph_debug.c index
> 9def306..37088ce 100644
> --- a/lib/graph/graph_debug.c
> +++ b/lib/graph/graph_debug.c
> @@ -35,8 +35,17 @@
>   fprintf(f, "  flags=0x%" PRIx64 "\n", n->flags);
>   fprintf(f, "  addr=%p\n", n);
>   fprintf(f, "  process=%p\n", n->process);
> + if (n->parent_id == RTE_NODE_ID_INVALID)
> + fprintf(f, "  parent_id=RTE_NODE_ID_INVALID\n");
> + else
> + fprintf(f, "  parent_id=%" PRIu32 "\n", n->parent_id);
> + fprintf(f, "  init=%p\n", n->init);
> + fprintf(f, "  fini=%p\n", n->fini);
> + fprintf(f, "  xstats=%p\n", n->xstats);
> + fprintf(f, "  next node addr=%p\n", STAILQ_NEXT(n, next));
> + if (STAILQ_NEXT(n, next))
> + fprintf(f, "  next node name=%s\n", STAILQ_NEXT(n, next)-
> >name);
>   fprintf(f, "  nb_edges=%d\n", n->nb_edges);
> -
>   for (i = 0; i < n->nb_edges; i++)
>   fprintf(f, " edge[%d] <%s>\n", i, n->next_nodes[i]);
>  }
> --
> 1.8.3.1



RE: [PATCH v2] graph: fix memory leak in node clone

2024-11-05 Thread Kiran Kumar Kokkilagadda



> -Original Message-
> From: pbhagavat...@marvell.com 
> Sent: Friday, November 1, 2024 1:08 PM
> To: Jerin Jacob ; chcch...@163.com; Kiran Kumar
> Kokkilagadda ; Nithin Kumar Dabilpuram
> ; Zhirun Yan 
> Cc: dev@dpdk.org; Pavan Nikhilesh Bhagavatula
> 
> Subject: [PATCH v2] graph: fix memory leak in node clone
> 
> From: Pavan Nikhilesh 
> 
> Free memory allocated for the node when xstats memory allocation fails.
> 
> Coverity issue: 445529
> Fixes: 070db97e017b ("graph: support node xstats")
> 
> Signed-off-by: Pavan Nikhilesh 
> ---

Acked-by: Kiran Kumar Kokkilagadda 



> v2 Changes:
> - Fix one more leak. (Huichao cai)
> 
>  lib/graph/node.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/graph/node.c b/lib/graph/node.c index
> f15922892e..63db629da8 100644
> --- a/lib/graph/node.c
> +++ b/lib/graph/node.c
> @@ -156,7 +156,7 @@ node_clone(struct node *node, const char *name)
>(node->xstats->nb_xstats *
> RTE_NODE_XSTAT_DESC_SIZE));
>   if (reg->xstats == NULL) {
>   rte_errno = ENOMEM;
> - goto fail;
> + goto free;
>   }
> 
>   for (i = 0; i < node->xstats->nb_xstats; i++) @@ -178,7 +178,7
> @@ node_clone(struct node *node, const char *name)
> 
>   /* Naming ceremony of the new node. name is node->name + "-" +
> name */
>   if (clone_name(reg->name, node->name, name))
> - goto free;
> + goto free_xstat;
> 
>   rc = __rte_node_register(reg);
>  free_xstat:
> --
> 2.25.1



RE: Re:RE: Re:RE: Re:RE: [EXTERNAL] [PATCH] test/graph: fix graph autotest second test failure

2024-10-28 Thread Kiran Kumar Kokkilagadda



> -Original Message-
> From: Huichao Cai 
> Sent: Friday, October 25, 2024 3:01 PM
> To: Kiran Kumar Kokkilagadda 
> Cc: Jerin Jacob ; Nithin Kumar Dabilpuram
> ; yanzhirun_...@163.com; dev@dpdk.org
> Subject: Re:RE: Re:RE: Re:RE: [EXTERNAL] [PATCH] test/graph: fix graph
> autotest second test failure
> 
> >We can fix this node id issue also. Something similar to this has been
> >fixed for graph id >Recently. We can do the same thing for node id as
> >well. >https: //patches. dpdk. org/project/dpdk/patch/20240618092324. 
> >54166-2-rjarry@ redhat. com/
> 
> 
> >We can fix this node id issue also. Something similar to this has been
> >fixed for graph id
> 
> >Recently. We can do the same thing for node id as well.
> >https://patches.dpdk.org/project/dpdk/patch/20240618092324.54166-2-
> rjar
> >r...@redhat.com/
> <https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__patches.dpdk.org_project_dpdk_patch_20240618092324.54166-2D2-
> 2Drjarry-
> 40redhat.com_&d=DwMGbg&c=nKjWec2b6R0mOyPaz7xtfQ&r=owEKckYY4F
> Tmil1Z6oBURwkTThyuRbLAY9LdfiaT6HA&m=N5-
> YM0oCO9qVUeRP5PqmCAjW9r9TbYSfnXQ8l906YZtptnm-QEfFtR-
> OBexfJrCS&s=BXf1fzz1sKd-xvzRjpjEjVrnxPKyhu-Plzk0I90s0XI&e=>
> 
> So will you be able to complete this change in the near future?

I Will send a patch sometime next week.



RE: Re:RE: Re:RE: [EXTERNAL] [PATCH] test/graph: fix graph autotest second test failure

2024-10-25 Thread Kiran Kumar Kokkilagadda



> -Original Message-
> From: Huichao Cai 
> Sent: Thursday, October 24, 2024 12:17 PM
> To: Kiran Kumar Kokkilagadda 
> Cc: Jerin Jacob ; Nithin Kumar Dabilpuram
> ; yanzhirun_...@163.com; dev@dpdk.org
> Subject: Re:RE: Re:RE: [EXTERNAL] [PATCH] test/graph: fix graph autotest
> second test failure
> 
> There is a problem with deleting static nodes: the node ID is recorded using 
> the
> global variable node_id, which is continuously increasing. If an intermediate
> node is deleted, the node ID will appear empty, which can introduce some
> problems, 
> 
> There is a problem with deleting static nodes: the node ID is recorded using 
> the
> global variable node_id,
> 
> which is continuously increasing. If an intermediate node is deleted, the node
> ID will appear empty, which
> 
> can introduce some problems, such as how to choose the node ID for cloning
> later?

We can fix this node id issue also. Something similar to this has been fixed 
for graph id 
Recently. We can do the same thing for node id as well.
https://patches.dpdk.org/project/dpdk/patch/20240618092324.54166-2-rja...@redhat.com/




RE: Re:RE: [EXTERNAL] [PATCH] test/graph: fix graph autotest second test failure

2024-10-23 Thread Kiran Kumar Kokkilagadda



> -Original Message-
> From: Huichao Cai 
> Sent: Wednesday, October 23, 2024 8:15 AM
> To: Kiran Kumar Kokkilagadda 
> Cc: Jerin Jacob ; Nithin Kumar Dabilpuram
> ; yanzhirun_...@163.com; dev@dpdk.org
> Subject: Re:RE: [EXTERNAL] [PATCH] test/graph: fix graph autotest second test
> failure
> 
> At present rte_graph_destroy will only clean up the struct rte_node and struct
> graph_node, not the struct node, rte_node_clone creates the struct node,
> inserts the global node_list linked list, there is no function to clean up the
> node_list 
> 
> At present rte_graph_destroy will only clean up the struct rte_node and struct
> graph_node,
> 
> not the struct node, rte_node_clone creates the struct node, inserts the 
> global
> node_list linked list,
> 
> there is no function to clean up the node_list linked list, if you want to 
> clean up
> the node
> 
> created by rte_node_clone, Perhaps a new function needs to be added to
> clean up node_list linked lists.
> 
> Or write a test case function to clean up the nodes that are cloned by this 
> test
> case.

It makes sense to have an API to clean up the nodes. Are you planning to add 
this?
If not, we can plan and add new API.






RE: [RFC PATCH 0/3] add featur arc in rte_graph

2024-09-17 Thread Kiran Kumar Kokkilagadda



> -Original Message-
> From: Nitin Saxena 
> Sent: Saturday, September 7, 2024 12:35 PM
> To: Jerin Jacob ; Kiran Kumar Kokkilagadda
> ; Nithin Kumar Dabilpuram
> ; Zhirun Yan 
> Cc: dev@dpdk.org
> Subject: [RFC PATCH 0/3] add featur arc in rte_graph
> 
> Feature arc represents an ordered list of features/protocols at a given
> networking layer. It is a high level abstraction to connect various rte_graph
> nodes, as feature nodes, and allow packets steering across these nodes in a
> generic manner.
> 
> Features (or feature nodes) are nodes which handles partial or complete
> handling of a protocol in fast path. Like ipv4-rewrite node, which adds 
> rewrite
> data to an outgoing IPv4 packet.
> 
> However in above example, outgoing interface(say "eth0") may have
> outbound IPsec policy enabled, hence packets must be steered from ipv4-
> rewrite node to ipsec-outbound-policy node for outbound IPsec policy
> lookup. On the other hand, packets routed to another interface
> (eth1) will not be sent to ipsec-outbound-policy node as IPsec feature is
> disabled on eth1. Feature-arc allows rte_graph applications to manage such
> constraints easily
> 
> Feature arc abstraction allows rte_graph based application to
> 
> 1. Seamlessly steer packets across feature nodes based on wheter feature is
> enabled or disabled on an interface. Features enabled on one interface may
> not be enabled on another interface with in a same feature arc.
> 
> 2. Allow enabling/disabling of features on an interface at runtime, so that 
> if a
> feature is disabled, packets associated with that interface won't be steered 
> to
> corresponding feature node.
> 
> 3. Provides mechanism to hook custom/user-defined nodes to a feature node
> and allow packet steering from feature node to custom node without changing
> former's fast path function
> 
> 4. Allow expressing features in a particular sequential order so that packets 
> are
> steered in an ordered way across nodes in fast path. For
> eg: if IPsec and IPv4 features are enabled on an ingress interface, packets 
> must
> be sent to IPsec inbound policy node first and then to ipv4 lookup node.
> 
> This patch series adds feature arc library in rte_graph and also adds "ipv4-
> output" feature arc handling in "ipv4-rewrite" node.
> 
> Nitin Saxena (3):
>   graph: add feature arc support
>   graph: add feature arc option in graph create
>   graph: add IPv4 output feature arc
> 
>  lib/graph/graph.c|   1 +
>  lib/graph/graph_feature_arc.c| 959 +++
>  lib/graph/graph_populate.c   |   7 +-
>  lib/graph/graph_private.h|   3 +
>  lib/graph/meson.build|   2 +
>  lib/graph/node.c |   2 +
>  lib/graph/rte_graph.h|   3 +
>  lib/graph/rte_graph_feature_arc.h| 373 +
>  lib/graph/rte_graph_feature_arc_worker.h | 548 +
>  lib/graph/version.map|  17 +
>  lib/node/ip4_rewrite.c   | 476 ---
>  lib/node/ip4_rewrite_priv.h  |   9 +-
>  lib/node/node_private.h  |  19 +-
>  lib/node/rte_node_ip4_api.h  |   3 +
>  14 files changed, 2325 insertions(+), 97 deletions(-)  create mode 100644
> lib/graph/graph_feature_arc.c  create mode 100644
> lib/graph/rte_graph_feature_arc.h  create mode 100644
> lib/graph/rte_graph_feature_arc_worker.h

Could you add unit test for these new APIs?

> 
> --
> 2.43.0



RE: [EXTERNAL] [PATCH v8] graph: mcore: optimize graph search

2025-02-21 Thread Kiran Kumar Kokkilagadda



> -Original Message-
> From: Huichao Cai 
> Sent: Friday, February 7, 2025 7:10 AM
> To: Jerin Jacob ; Kiran Kumar Kokkilagadda
> ; Nithin Kumar Dabilpuram
> ; yanzhirun_...@163.com
> Cc: dev@dpdk.org
> Subject: [EXTERNAL] [PATCH v8] graph: mcore: optimize graph search
> 
> In the function __rte_graph_mcore_dispatch_sched_node_enqueue, use a
> slower loop to search for the graph, modify the search logic to record the
> result of the first search, and use this record for subsequent searches to
> improve search speed. 
> In the function __rte_graph_mcore_dispatch_sched_node_enqueue,
> use a slower loop to search for the graph, modify the search logic to record 
> the
> result of the first search, and use this record for subsequent searches to
> improve search speed.
> 
> Signed-off-by: Huichao Cai 
> ---

Acked-by: Kiran Kumar Kokkilagadda 



>  devtools/libabigail.abignore   |  5 +
>  doc/guides/rel_notes/release_25_03.rst |  1 +
>  lib/graph/rte_graph_model_mcore_dispatch.c | 11 +++
>  lib/graph/rte_graph_worker_common.h|  1 +
>  4 files changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore index
> 21b8cd6113..8876aaee2e 100644
> --- a/devtools/libabigail.abignore
> +++ b/devtools/libabigail.abignore
> @@ -33,3 +33,8 @@
>  
>  ; Temporary exceptions till next major ABI version ;
> 
> +[suppress_type]
> +name = rte_node
> +has_size_change = no
> +has_data_member_inserted_between =
> +{offset_after(original_process), offset_of(xstat_off)}
> \ No newline at end of file
> diff --git a/doc/guides/rel_notes/release_25_03.rst
> b/doc/guides/rel_notes/release_25_03.rst
> index 269ab6f68a..16a888fd19 100644
> --- a/doc/guides/rel_notes/release_25_03.rst
> +++ b/doc/guides/rel_notes/release_25_03.rst
> @@ -150,6 +150,7 @@ ABI Changes
> 
>  * No ABI change that would break compatibility with 24.11.
> 
> +* graph: Added ``graph`` field to the ``dispatch`` structure in the 
> ``rte_node``
> structure.
> 
>  Known Issues
>  
> diff --git a/lib/graph/rte_graph_model_mcore_dispatch.c
> b/lib/graph/rte_graph_model_mcore_dispatch.c
> index a590fc9497..a81d338227 100644
> --- a/lib/graph/rte_graph_model_mcore_dispatch.c
> +++ b/lib/graph/rte_graph_model_mcore_dispatch.c
> @@ -118,11 +118,14 @@
> __rte_graph_mcore_dispatch_sched_node_enqueue(struct rte_node *node,
> struct rte_graph_rq_head *rq)  {
>   const unsigned int lcore_id = node->dispatch.lcore_id;
> - struct rte_graph *graph;
> + struct rte_graph *graph = node->dispatch.graph;
> 
> - SLIST_FOREACH(graph, rq, next)
> - if (graph->dispatch.lcore_id == lcore_id)
> - break;
> + if (unlikely((!graph) || (graph->dispatch.lcore_id != lcore_id))) {
> + SLIST_FOREACH(graph, rq, next)
> + if (graph->dispatch.lcore_id == lcore_id)
> + break;
> + node->dispatch.graph = graph;
> + }
> 
>   return graph != NULL ? __graph_sched_node_enqueue(node, graph) :
> false;  } diff --git a/lib/graph/rte_graph_worker_common.h
> b/lib/graph/rte_graph_worker_common.h
> index d3ec88519d..aef0f65673 100644
> --- a/lib/graph/rte_graph_worker_common.h
> +++ b/lib/graph/rte_graph_worker_common.h
> @@ -110,6 +110,7 @@ struct __rte_cache_aligned rte_node {
>   unsigned int lcore_id;  /**< Node running lcore. */
>   uint64_t total_sched_objs; /**< Number of objects
> scheduled. */
>   uint64_t total_sched_fail; /**< Number of scheduled
> failure. */
> + struct rte_graph *graph;  /**< Graph corresponding to
> lcore_id. */
>   } dispatch;
>   };
> 
> --
> 2.33.0