On 2023/2/2 21:07, Konstantin Ananyev wrote:
31/01/2023 02:28, Jie Hai пишет:
This patch supports dump of the info of ring by its name.
An example using this command is shown below:
--> /ring/info,MP_mb_pool_0
{
"/ring/info": {
"name": "MP_mb_pool_0",
"socket": 0,
"flags": 0,
"producer_type": "MP",
"consumer_type": "MC",
"size": 262144,
"mask": 262143,
"capacity": 262143,
"used_count": 147173,
"consumer_tail": 8283,
"consumer_head": 8283,
"producer_tail": 155456,
"producer_head": 155456,
"mz_name": "RG_MP_mb_pool_0",
"mz_len": 2097920,
"mz_hugepage_sz": 1073741824,
"mz_socket_id": 0,
"mz_flags": 0
}
}
Signed-off-by: Jie Hai <haij...@huawei.com>
+static int
+ring_handle_info(const char *cmd __rte_unused, const char *params,
+ struct rte_tel_data *d)
+{
+ const struct rte_memzone *mz;
+ struct rte_ring *r;
+
+ if (params == NULL || strlen(params) == 0 ||
+ strlen(params) >= RTE_RING_NAMESIZE)
+ return -EINVAL;
+
+ r = rte_ring_lookup(params);
+ if (r == NULL)
+ return -EINVAL;
thanks for the update, but I think there still a potential problem here:
as we release tailq_lock inside ring_lookup() and then grab it after again.
Between these two points we have sort of race condition.
We need a way not to release it in between.
Probably the simplest way - make this function to use ring_walk()
that you introduced in previous patch, instead of ring_lookup().
Similar to what mempool_handle_info() is doing.
Thanks for your comments, and I have learned a lot from it. That will be
corrected in v4.
.
