Re: [PATCH] net/tap: Bug fix to populate fds in secondary process

[Kumara Parameshwaran <kparameshwar@vmware.com>]

[-- Attachment #1: Type: text/plain, Size: 1577 bytes --]

@Stephen Hemminger<mailto:stephen@networkplumber.org> This is process private as the tap fds are maintained in per process data structures. In existing scheme, the fds are opened by the primary during queue setup and exchanged to during secondary probe where the send_msg using SOL_SOCKET and SCM_RIGHTS would remap the corresponding fds to the secondary process. If the secondary process is coming up once the primary is initialised things would work fine, but it's a problem during hotplug of the tap device.

Thanks,
Param.
________________________________
From: Stephen Hemminger <stephen@networkplumber.org>
Sent: 18 January 2022 03:46
To: Kumara Parameshwaran <kumaraparamesh92@gmail.com>
Cc: keith.wiles@intel.com <keith.wiles@intel.com>; dev@dpdk.org <dev@dpdk.org>; Kumara Parameshwaran <kparameshwar@vmware.com>
Subject: Re: [PATCH] net/tap: Bug fix to populate fds in secondary process

On Fri, 26 Nov 2021 09:45:15 +0530
Kumara Parameshwaran <kumaraparamesh92@gmail.com> wrote:

> +     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];
> +     process_private = dev->process_private;
> +     dev->data->nb_rx_queues = request_param->rxq_count;
> +     dev->data->nb_tx_queues = request_param->txq_count;

Why is this necessary?  dev->data is already in memory shared between primary
and secondary process.

[-- Attachment #2: Type: text/html, Size: 3278 bytes --]