[dpdk-dev] new ethdev API proposal for port ownership

Thomas Monjalon thomas at monjalon.net
Wed Sep 6 12:17:48 CEST 2017


Hi all,

A DPDK queue is designed to be polled by only one thread.
And the port settings must be managed by only one entity/thread.
These assumptions come from lockless design and management logic.
	- thank you Captain Obvious ;)
That's why we can say that an ethdev port is owned by one entity.
Note that this discussion can also apply to cryptodev or eventdev.

The ownership of a port is implicit in DPDK.
I propose to make it explicit for several reasons I explain below.

0/ Explicit is better than implicit

1/ It may be convenient for multi-process applications to know which
process is in charge of a port.

2/ A library could work on top of a port.

3/ A port can work on top of another port (failsafe design).
In the failsafe case, an issue has been met in testpmd.
We need to check that the user is not trying to use a port
which is already managed by failsafe:
	http://dpdk.org/ml/archives/dev/2017-September/074253.html

Now let's discuss how to implement the port ownership.

When failsafe has been introduced, the need of skipping owned ports
has been adressed with a new "deferred" state:
	http://dpdk.org/commit/cb894d99ec
	http://dpdk.org/commit/5588909af2
It allows to iterate over "free" ports but not to check one port.
Moreover this new state is weak. It does not say who owns the port.

I suggest to replace RTE_ETH_DEV_DEFERRED state by an owner string.
The owner could be printed or compared with known values.
The failsafe PMD would set "failsafe" as owner of its sub-devices.
It could also be used by applications to record which ports are used.
For instance, testpmd would set the owner as "testpmd" for polled ports.
It would bring a new information to DPDK entities: some ports are free.
And in the case of multi-process, the PID could be part of the string.

About iterating over ports with the macro RTE_ETH_FOREACH_DEV,
we should add a string parameter to compare the owner of the ports.
The empty string would be an acceptable value to find ports not owned.
Note that applications are not forced to make explicit their ownership.
We could use the NULL pointer to iterate over all existing ports if needed.

I suggest to add two new functions:
	- rte_eth_dev_owner_set(id, owner)
	- rte_eth_dev_owner_get(id)

Opinions, comments?


More information about the dev mailing list