From: "Tan, Jianfeng" <jianfeng.tan@intel.com>
To: "dev@dpdk.org" <dev@dpdk.org>
Cc: Thomas Monjalon <thomas.monjalon@6wind.com>,
"Richardson, Bruce" <bruce.richardson@intel.com>,
"Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
Stephen Hemminger <stephen@networkplumber.org>,
Yuanhan Liu <yuanhan.liu@linux.intel.com>,
Ferruh Yigit <ferruh.yigit@intel.com>,
"Yang, Zhiyong" <zhiyong.yang@intel.com>,
huanghuai@meituan.com
Subject: [dpdk-dev] [RFC] Enable primary/secondary model for vdev
Date: Thu, 11 May 2017 14:20:29 +0800 [thread overview]
Message-ID: <9ec37184-ef14-8377-d913-8ee8fda11c5e@intel.com> (raw)
Hi,
Status quo:
Almost none of vdev supports primary/secondary model. Two exceptions are
rte_ring, virtio-user (limited support). Two problems facing this issue.
P1: How to attach vdev in secondary process?
Previous discussion: http://dpdk.org/ml/archives/dev/2017-April/063370.html
According current implementation, vdev can be recognized on vdev bus
only if it is explicitly assigned in the parameters, or invokes call
rte_eal_vdev_init() to create one. Assigning --vdev parameter explicitly
on secondary process is not the optimal way. Instead, we can iterate
rte_eth_dev_data array to discover/obtain all devices, which seems a
more unified solution with PCI devices.
If we only need to obtain the statistics of vdev in secondary process
(like what dpdk-procinfo does), solving above issue is enough, but if we
need to Rx/Tx packets in secondary process for vdev, we need to solve
the following problem too.
P2: How to share dev-specific FDs to secondary process?
We need to share the FDs which are opened at primary process, for
example, the socket file of pcap, the char device of tap, the QEMU
memory region fds of vhost-user, etc. The only (as far as we know) way
to share FD between processes in Linux is to use ancillary data of
sendmsg/recvmsg on unix socket. That means we propose a new socket file
created for each primary proess, and secondary processes will connect
with this unix socket; and for simplicity, we also propose a new API to
share FD, so that vdev can make use of it to share FDs.
Another problem I'd like to make clear is: can secondary processes own
ports that does not belong to primary?
Besides, there are two errors in documents: (1) rte_ring supports
primary/secondary model but the document does not state that; (2) pcap
does not support primary/secondary model but the document states it
supports.
Thanks,
Jianfeng
next reply other threads:[~2017-05-11 6:20 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-11 6:20 Tan, Jianfeng [this message]
2017-05-18 1:57 ` Tan, Jianfeng
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=9ec37184-ef14-8377-d913-8ee8fda11c5e@intel.com \
--to=jianfeng.tan@intel.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=huanghuai@meituan.com \
--cc=konstantin.ananyev@intel.com \
--cc=stephen@networkplumber.org \
--cc=thomas.monjalon@6wind.com \
--cc=yuanhan.liu@linux.intel.com \
--cc=zhiyong.yang@intel.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).