DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: dev@dpdk.org
Cc: gaetan.rivet@6wind.com, matan@mellanox.com
Subject: [dpdk-dev] new ethdev API proposal for port ownership
Date: Wed, 06 Sep 2017 12:17:48 +0200	[thread overview]
Message-ID: <1702878.F75W0GzqAz@xps> (raw)

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?

             reply	other threads:[~2017-09-06 10:17 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-06 10:17 Thomas Monjalon [this message]
2017-09-06 12:36 ` Adrien Mazarguil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1702878.F75W0GzqAz@xps \
    --to=thomas@monjalon.net \
    --cc=dev@dpdk.org \
    --cc=gaetan.rivet@6wind.com \
    --cc=matan@mellanox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).