From: "Tan, Jianfeng" <jianfeng.tan@intel.com>
To: Kyle Larose <klarose@sandvine.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: Matthew Coppola <mcoppola@sandvine.com>
Subject: Re: [dpdk-dev] [PATCH] bus/vdev: scan and probe vdev in secondary processes
Date: Fri, 1 Dec 2017 13:59:27 +0800 [thread overview]
Message-ID: <ae4e1255-b432-076d-e2af-3ebaf0338725@intel.com> (raw)
In-Reply-To: <26d38eefe9814bfcb29b058b8922dc8c@sandvine.com>
Hi Kyle,
On 12/1/2017 6:27 AM, Kyle Larose wrote:
> Hey Jianfeng,
>
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jianfeng Tan
>> Sent: Thursday, November 30, 2017 1:59 PM
>> To: dev@dpdk.org
>> Cc: Jianfeng Tan
>> Subject: [dpdk-dev] [PATCH] bus/vdev: scan and probe vdev in
>> secondary processes
>>
>> Base on primary/secondary communication channel [1], we add vdev
>> action to scan virtual devices in secondary processes.
>>
>> [1] http://dpdk.org/dev/patchwork/patch/31838/
>>
>> Signed-off-by: Jianfeng Tan <jianfeng.tan@intel.com>
>> ---
>> drivers/bus/vdev/vdev.c | 104
>> ++++++++++++++++++++++++++++++++++++++++++++++--
>> 1 file changed, 100 insertions(+), 4 deletions(-)
>>
>
>
> We recently stumbled across a problem where running dpdk-pdump against
> a primary which had an rte_eth_bond virtual device would lead to a crash.
>
> We realized this was happening because the vdev bus wasn't being built
> properly on the secondary, leading to it corrupting the ethdev structures
> for the eth_bond device on the primary. This corruption occurred because pdump
> used what it thought was the first free dpdk port id for its pcap_pmd. That
> port id collided with the eth_bond pmd, causing the problem.
>
> My feeling is that this patch will fix that problem, since probing the virtual
> bus from the primary, rather than just from the eal cmdline arguments, will
> allow the secondary to choose an used port id. Am I correct in my understanding?
Yes, that's an issue we want to address in this patch set: those portid
(either physical port or virtual port) will be synchronized to
secondary, if the secondary wants to add port (private to the
secondary), it will use unused portid.
But we still not address the problem that, both the primary and the
secondary are allocating new devices which needs a centralized portid
management mechanism.
Thanks,
Jianfeng
>
> Thanks,
>
> Kyle
>
>
prev parent reply other threads:[~2017-12-01 5:59 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-30 18:58 Jianfeng Tan
2017-11-30 22:27 ` Kyle Larose
2017-12-01 5:59 ` Tan, Jianfeng [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=ae4e1255-b432-076d-e2af-3ebaf0338725@intel.com \
--to=jianfeng.tan@intel.com \
--cc=dev@dpdk.org \
--cc=klarose@sandvine.com \
--cc=mcoppola@sandvine.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).