[v3,1/2] ethdev: define a function to get eth dev structure
Checks
Commit Message
From: Kumara Parameshwaran <kparameshwar@vmware.com>
The PMDs would need a function to access the rte_eth_devices
global array
Cc: stable@dpdk.org
Signed-off-by: Kumara Parameshwaran <kparameshwar@vmware.com>
---
lib/ethdev/ethdev_driver.h | 18 ++++++++++++++++++
lib/ethdev/rte_ethdev.c | 11 +++++++++++
lib/ethdev/version.map | 1 +
3 files changed, 30 insertions(+)
Comments
On 1/31/2022 2:32 PM, Kumara Parameshwaran wrote:
> From: Kumara Parameshwaran <kparameshwar@vmware.com>
>
> The PMDs would need a function to access the rte_eth_devices
> global array
>
> Cc: stable@dpdk.org
>
Not sure if this patch is suitable for backport, since it introduces
new internal API.
But since API is internal, perhaps it is OK to get it, specially because
it is required for next patch that is a fix. Keeping the tag and leaving
the decision to LTS maintainers.
> Signed-off-by: Kumara Parameshwaran <kparameshwar@vmware.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
On 2/1/2022 4:56 PM, Ferruh Yigit wrote:
> On 1/31/2022 2:32 PM, Kumara Parameshwaran wrote:
>> From: Kumara Parameshwaran <kparameshwar@vmware.com>
>>
>> The PMDs would need a function to access the rte_eth_devices
>> global array
>>
>> Cc: stable@dpdk.org
>>
>
> Not sure if this patch is suitable for backport, since it introduces
> new internal API.
> But since API is internal, perhaps it is OK to get it, specially because
> it is required for next patch that is a fix. Keeping the tag and leaving
> the decision to LTS maintainers.
>
>> Signed-off-by: Kumara Parameshwaran <kparameshwar@vmware.com>
>
> Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
Hi Kumara,
There are some instances in the existing code that can benefit from new API [1],
do you have any bandwidth to make a patch to replace 'rte_eth_dev_get_port_by_name()'
with new 'rte_eth_dev_get_by_name()'?
(For the cases 'port_id' is used to get eth_dev)
Thanks,
ferruh
[1]
$ git grep rte_eth_dev_get_port_by_name drivers/net/
drivers/net/bonding/rte_eth_bond_api.c: ret = rte_eth_dev_get_port_by_name(name, &port_id);
drivers/net/ipn3ke/ipn3ke_ethdev.c: retval = rte_eth_dev_get_port_by_name(fvl_bdf,
drivers/net/memif/rte_eth_memif.c: ret = rte_eth_dev_get_port_by_name(msg_param->port_name, &port_id);
drivers/net/mlx5/linux/mlx5_os.c: if (rte_eth_dev_get_port_by_name(name, &port_id) == 0) {
drivers/net/mlx5/windows/mlx5_os.c: if (rte_eth_dev_get_port_by_name(name, &port_id) == 0) {
drivers/net/ring/rte_eth_ring.c: ret = rte_eth_dev_get_port_by_name(ring_name, &port_id);
drivers/net/softnic/rte_eth_softnic_cli.c: status = rte_eth_dev_get_port_by_name(softnic->params.name, &port_id);
drivers/net/softnic/rte_eth_softnic_cli.c: status = rte_eth_dev_get_port_by_name(softnic->params.name, &port_id);
drivers/net/softnic/rte_eth_softnic_cli.c: status = rte_eth_dev_get_port_by_name(softnic->params.name, &port_id);
drivers/net/softnic/rte_eth_softnic_cli.c: status = rte_eth_dev_get_port_by_name(softnic->params.name, &port_id);
drivers/net/softnic/rte_eth_softnic_cli.c: status = rte_eth_dev_get_port_by_name(softnic->params.name, &port_id);
drivers/net/softnic/rte_eth_softnic_internals.h: status = rte_eth_dev_get_port_by_name(softnic->params.name, &port_id);
drivers/net/softnic/rte_eth_softnic_link.c: status = rte_eth_dev_get_port_by_name(params->dev_name,
drivers/net/softnic/rte_eth_softnic_thread.c: status = rte_eth_dev_get_port_by_name(softnic->params.name, &port_id);
drivers/net/tap/rte_eth_tap.c: ret = rte_eth_dev_get_port_by_name(request_param->port_name, &port_id);
On 2/1/2022 4:56 PM, Ferruh Yigit wrote:
> On 1/31/2022 2:32 PM, Kumara Parameshwaran wrote:
>> From: Kumara Parameshwaran <kparameshwar@vmware.com>
>>
>> The PMDs would need a function to access the rte_eth_devices
>> global array
>>
>> Cc: stable@dpdk.org
>>
>
> Not sure if this patch is suitable for backport, since it introduces
> new internal API.
> But since API is internal, perhaps it is OK to get it, specially because
> it is required for next patch that is a fix. Keeping the tag and leaving
> the decision to LTS maintainers.
>
>> Signed-off-by: Kumara Parameshwaran <kparameshwar@vmware.com>
>
> Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
Series applied to dpdk-next-net/main, thanks.
@@ -1629,6 +1629,24 @@ rte_eth_hairpin_queue_peer_bind(uint16_t cur_port, uint16_t cur_queue,
struct rte_hairpin_peer_info *peer_info,
uint32_t direction);
+/**
+ * @internal
+ * Get rte_eth_dev from device name. The device name should be specified
+ * as below:
+ * - PCIe address (Domain:Bus:Device.Function), for example- 0000:2:00.0
+ * - SoC device name, for example- fsl-gmac0
+ * - vdev dpdk name, for example- net_[pcap0|null0|tap0]
+ *
+ * @param name
+ * pci address or name of the device
+ * @return
+ * - rte_eth_dev if successful
+ * - NULL on failure
+ */
+__rte_internal
+struct rte_eth_dev*
+rte_eth_dev_get_by_name(const char *name);
+
/**
* @internal
* Reset the current queue state and configuration to disconnect (unbind) it
@@ -894,6 +894,17 @@ rte_eth_dev_get_port_by_name(const char *name, uint16_t *port_id)
return -ENODEV;
}
+struct rte_eth_dev *
+rte_eth_dev_get_by_name(const char *name)
+{
+ uint16_t pid;
+
+ if (rte_eth_dev_get_port_by_name(name, &pid))
+ return NULL;
+
+ return &rte_eth_devices[pid];
+}
+
static int
eth_err(uint16_t port_id, int ret)
{
@@ -267,6 +267,7 @@ INTERNAL {
rte_eth_dev_callback_process;
rte_eth_dev_create;
rte_eth_dev_destroy;
+ rte_eth_dev_get_by_name;
rte_eth_dev_is_rx_hairpin_queue;
rte_eth_dev_is_tx_hairpin_queue;
rte_eth_dev_probing_finish;