On 1/17/2022 6:33 PM, Thomas Monjalon wrote:
17/01/2022 19:28, Ferruh Yigit:
+ 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?
It looks similar to rte_eth_dev_get_port_by_name() which returns a port_id.
Exactly, but get eth_dev directly for drivers. For drivers no need to work with
port_id
handler, they can use eth_dev directly.
Another solution can be an getter function for drivers, which gets port_id and
returns
the eth_dev.
It is a bit strange for an ethdev driver to not have access to its own ethdev
struct.
Isn't there something broken in the logic?
This is callback function between primary and secondary applications sync. So
port name
will be same for both, but eth_dev will be different and port_id may be
different.
Driver finds its own eth_dev from the shared port name.
