From: Tom Barbette <barbette@kth.se>
To: Ferruh Yigit <ferruh.yigit@intel.com>,
Alejandro Lucero <alejandro.lucero@netronome.com>,
"dev@dpdk.org" <dev@dpdk.org>
Cc: Thomas Monjalon <thomas@monjalon.net>,
Andrew Rybchenko <arybchenko@solarflare.com>,
Anatoly Burakov <anatoly.burakov@intel.com>,
Bruce Richardson <bruce.richardson@intel.com>,
John Daley <johndale@cisco.com>,
Shahaf Shuler <shahafs@mellanox.com>,
Adrien Mazarguil <adrien.mazarguil@6wind.com>,
Konstantin Ananyev <konstantin.ananyev@intel.com>,
Stephen Hemminger <stephen@networkplumber.org>,
Qi Zhang <qi.z.zhang@intel.com>,
Jerin Jacob <jerin.jacob@caviumnetworks.com>
Subject: Re: [dpdk-dev] [PATCH] net/nfp: add multiprocess support
Date: Thu, 29 Nov 2018 14:43:20 +0000 [thread overview]
Message-ID: <1543502600032.88549@kth.se> (raw)
In-Reply-To: <56a0dbab-20e1-9a46-bbfe-3081dea0744d@intel.com>
Ferruh Yigit wrote:
> According my understanding,
> Only *one* DPDK application (primary or secondary) should control a device.
> There is no restriction in DPDK for it, this responsibility is pushed to
> application, application should manage it.
...
> Device initialization (probe()) done only by primary application.
I'm jumping in the thread because this is not clear actually. As a somehow long-standing DPDK multiprocess user, I think it would be good to take the occasion to make clarifications (in the docs and not only on the mailing list) about what can be done between processes.
Eg following your thought, a master/slave approach is not allowed by DPDK.
Example : currently changing the RETA table with mlx5 will crash all slaves currently reading packets from the target device. So much for dynamically scaling.
Can we let calling all this set of (undocumented) functions that should not be called between processes be "the fault of the user" if it crashes?
Tom
prev parent reply other threads:[~2018-11-29 14:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-28 11:32 Alejandro Lucero
2018-11-28 17:28 ` Ferruh Yigit
2018-11-28 18:05 ` Alejandro Lucero
2018-11-29 14:05 ` Ferruh Yigit
2018-11-29 14:43 ` Tom Barbette [this message]
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=1543502600032.88549@kth.se \
--to=barbette@kth.se \
--cc=adrien.mazarguil@6wind.com \
--cc=alejandro.lucero@netronome.com \
--cc=anatoly.burakov@intel.com \
--cc=arybchenko@solarflare.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=jerin.jacob@caviumnetworks.com \
--cc=johndale@cisco.com \
--cc=konstantin.ananyev@intel.com \
--cc=qi.z.zhang@intel.com \
--cc=shahafs@mellanox.com \
--cc=stephen@networkplumber.org \
--cc=thomas@monjalon.net \
/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).