From: "Wu, Jingjing" <jingjing.wu@intel.com>
To: "Gaëtan Rivet" <gaetan.rivet@6wind.com>,
"Yigit, Ferruh" <ferruh.yigit@intel.com>
Cc: Raslan Darawsheh <rasland@mellanox.com>,
"thomas@monjalon.net" <thomas@monjalon.net>,
"dev@dpdk.org" <dev@dpdk.org>,
"salehals@mellanox.com" <salehals@mellanox.com>
Subject: Re: [dpdk-dev] [PATCH] app/testpmd: app/testpmd: add device removal command
Date: Thu, 7 Sep 2017 08:17:33 +0000 [thread overview]
Message-ID: <9BB6961774997848B5B42BEC655768F810E4255C@SHSMSX103.ccr.corp.intel.com> (raw)
In-Reply-To: <20170828111240.GF8124@bidouze.vm.6wind.com>
> >
> > Since dealing with device is kind of new, it can be OK to create new
> > command tree, but there are already hotplug commands per port:
> > "port attach #PCI|#VDEV_NAME"
> > "port detach #P"
> >
>
> Those two commands deal with the etherdev hotplug API.
> The new command should test the rte_dev one.
>
I was confused. The forwarding in testpmd setup is based on port id, right?
And all the devices listed in testpmd is etherdev, and all functional testings are all based on port id, right?
Then what is the difference to use port id or device name in testpmd?
And if no difference, what is the difference between detach and remove?
The only difference here I think is
Remove command is using rte_bus hotplug framework.
Attach/detach is using rte_eth_dev_detach API.
I think remove command should be an important command, and should not have ambiguity.
At least we need to doc it clearly.
> As Thomas pointed out, the etherdev one deals only with eth ports, while
> hotplug could be generalized to other devices, such as cryptodev.
>
> > perhaps it can be good to keep "attach", "detach" keywords for device to
> > be consistent?
> >
> > "device attach #name"
> > "device detach #name"
> >
>
> I made a point of naming the hotplug operations in rte_bus plug/unplug
> to avoid the confusion with the etherdev API. hotplug_add /
> hotplug_remove also marks the distinction.
>
> I don't know if it would be helpful for a developer writing a PMD,
> searching for a way to test a functionality to have an API name
> mismatch.
>
> > Also a show equivalent can be added to work in device level:
> > "show device info"
> >
>
> I think it would be useful.
>
> >
> > [1]
> > http://dpdk.org/ml/archives/dev/2017-August/072764.html
> >
> >
>
> --
> Gaëtan Rivet
> 6WIND
next prev parent reply other threads:[~2017-09-07 8:17 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-23 14:37 Raslan Darawsheh
2017-08-23 15:09 ` Gaëtan Rivet
2017-08-23 16:18 ` Thomas Monjalon
2017-08-25 7:53 ` Gaëtan Rivet
2017-08-25 8:55 ` Thomas Monjalon
2017-08-28 9:55 ` Gaëtan Rivet
2017-08-28 10:30 ` Ferruh Yigit
2017-08-28 11:00 ` Thomas Monjalon
2017-08-28 11:12 ` Gaëtan Rivet
2017-09-07 8:17 ` Wu, Jingjing [this message]
2017-11-28 22:02 ` Ferruh Yigit
2017-12-03 9:32 ` Raslan Darawsheh
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=9BB6961774997848B5B42BEC655768F810E4255C@SHSMSX103.ccr.corp.intel.com \
--to=jingjing.wu@intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=gaetan.rivet@6wind.com \
--cc=rasland@mellanox.com \
--cc=salehals@mellanox.com \
--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).