On 11/26/2021 4:15 AM, Kumara Parameshwaran wrote:
From: Kumara Parameshwaran <kparamesh...@vmware.com>
When a tap device is hotplugged to primary process which in turn
adds the device to all secondary process, the secondary process
does a tap_mp_attach_queues, but the fds are not populated in
the primary during the probe they are populated during the queue_setup,
added a fix to sync the queues during rte_eth_dev_start
Signed-off-by: Kumara Parameshwaran <kparamesh...@vmware.com>
<...>
+static int
+tap_mp_req_start_rxtx(const struct rte_mp_msg *request, __rte_unused const
void *peer)
+{
+ struct rte_eth_dev *dev;
+ int ret;
+ uint16_t port_id;
+ const struct ipc_queues *request_param =
+ (const struct ipc_queues *)request->param;
+ int fd_iterator;
+ int queue;
+ struct pmd_process_private *process_private;
+
+ ret = rte_eth_dev_get_port_by_name(request_param->port_name, &port_id);
+ if (ret) {
+ TAP_LOG(ERR, "Failed to get port id for %s",
+ request_param->port_name);
+ return -1;
+ }
+ dev = &rte_eth_devices[port_id];
Since this is not really related with your patch, I want to have a separate
thread for it.
It is not good to access the 'rte_eth_devices' global variable directly from a
driver, that
is error prone.
Btw, what 'peer' supposed to contain?
It can be solved by adding an internal API, only for drivers to get eth_dev
from the name,
like: 'rte_eth_dev_get_by_name()'.
This way a few other usage can be converted to this API.
@Thomas and @Andrew what do you think about the new API proposal?
