MLX5DV_DEVX_DESTROY_CMD_COMP(3)

💅 mlx5dv_devx_create_cmd_comp, mlx5dv_devx_destroy_cmd_comp, mlx5dv_devx_get_async_cmd_comp — mlx5dv_devx_crea..._comp, get_async(3) ✨

okay so bestie, you're in the mlx5dv_devx_crea..._comp, get_async(3) corner of the manual (yes the name is literally truncated with ... in the header, that's just how it is, iconic honestly) and we're talking about DEVX async command completions. buckle up, it's giving "non-blocking but make it RDMA" 🦋

---

🌸 NAME 🌸

• mlx5dv_devx_create_cmd_comp — creates a command completion, which you then use for DEVX asynchronous commands ✨
• mlx5dv_devx_destroy_cmd_comp — destroys a devx command completion 💅
• mlx5dv_devx_get_async_cmd_comp — gets an asynchronous command completion 🎀

---

⭐ SYNOPSIS ⭐

#include <infiniband/mlx5dv.h>

struct mlx5dv_devx_cmd_comp {
    int fd;
};

struct mlx5dv_devx_cmd_comp *
mlx5dv_devx_create_cmd_comp(struct ibv_context *context)

void mlx5dv_devx_destroy_cmd_comp(struct mlx5dv_devx_cmd_comp *cmd_comp)

struct mlx5dv_devx_async_cmd_hdr {
    uint64_t    wr_id;
    uint8_t     out_data[];
};

int mlx5dv_devx_get_async_cmd_comp(struct mlx5dv_devx_cmd_comp *cmd_comp,
                               struct mlx5dv_devx_async_cmd_hdr *cmd_resp,
                               size_t cmd_resp_len)

---

🦋 DESCRIPTION 🦋

So basically you either create or destroy a command completion, and that thing is what you use for DEVX asynchronous commands. periodt.

The create verb hands you back an mlx5dv_devx_cmd_comp object, and that object is exactly what you plug into asynchronous DEVX commands. the whole point? your application gets to run asynchronously — no blocking, no waiting around like a lost lamb 😭 — and then, once the response is actually ready, you read it out of this object. main character energy tbh ✨

You read that response with the mlx5dv_devx_get_async_cmd_comp() API. when the response lands, the wr_id you supplied when you fired off the asynchronous command comes back to you, and out_data contains the data itself. 🎁

⚠️ okay important one, do not skip: the application must supply a large enough buffer to match any command that was issued on the cmd_comp. the size of that buffer is given by the input cmd_resp_len parameter. too small = bad vibes, so size it right fr fr 💀

---

💖 ARGUMENTS 💖

• context — the RDMA device context you're creating the action on 🫶
• cmd_comp — the command completion object itself
• cmd_resp — the output data from the asynchronous command ✨
• cmd_resp_len — the output buffer size, i.e. how much room you're giving it to hold the response 🎀

---

🔥 RETURN VALUE 🔥

On success, mlx5dv_devx_create_cmd_comp returns a brand new struct mlx5dv_devx_cmd_comp object. on error it returns NULL and errno gets set. 😭

On success, mlx5dv_devx_get_async_cmd_comp returns 0. otherwise, errno is returned.

---

🌈 SEE ALSO 🌈

• mlx5dv_open_device(3)
• mlx5dv_devx_obj_create(3)

---

👑 AUTHOR 👑

Yishai Hadas <yishaih@mellanox.com> 🫶

---

and that's the whole page bestie 💜 this one lives in the mlx5dv_devx_crea..._comp, get_async(3) manual — same truncated name up top and down at the bottom, no cap — and yeah, the name really does get cut off with ... in both spots, iykyk 🧚