DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Zhang, Qi Z" <qi.z.zhang@intel.com>
To: "Gaëtan Rivet" <gaetan.rivet@6wind.com>,
	"Thomas Monjalon" <thomas@monjalon.net>
Cc: "dev@dpdk.org" <dev@dpdk.org>, "Yigit, Ferruh" <ferruh.yigit@intel.com>
Subject: Re: [dpdk-dev] [PATCH] bus/vdev: fix probe same device twice
Date: Wed, 7 Nov 2018 16:53:50 +0000	[thread overview]
Message-ID: <039ED4275CED7440929022BC67E70611532E0AC3@SHSMSX103.ccr.corp.intel.com> (raw)
In-Reply-To: <20181106233352.qhe7kuhgiexpvpih@bidouze.vm.6wind.com>



> -----Original Message-----
> From: Gaëtan Rivet [mailto:gaetan.rivet@6wind.com]
> Sent: Tuesday, November 6, 2018 4:34 PM
> To: Thomas Monjalon <thomas@monjalon.net>
> Cc: Zhang, Qi Z <qi.z.zhang@intel.com>; dev@dpdk.org; Yigit, Ferruh
> <ferruh.yigit@intel.com>
> Subject: Re: [dpdk-dev] [PATCH] bus/vdev: fix probe same device twice
> 
> On Tue, Nov 06, 2018 at 09:36:22PM +0100, Thomas Monjalon wrote:
> > 06/11/2018 16:46, Zhang, Qi Z:
> > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > >
> > > > Hi,
> > > >
> > > > 06/11/2018 01:31, Qi Zhang:
> > > > > When probe the same device at second time
> > > >
> > > > Sorry I stop on this first sentence.
> > > > How and why do you probe a vdev twice?
> > >
> > > if we do rte_dev_hotplug_add or rte_dev_proble on a probed device.
> > > (yes, this is not usually what an application want, but it can
> > > happen by miss-operation, and this is covered by our test case, it
> > > make sense to me that hotplug API should be robust enough to handle
> > > that situation.)
> >
> > Yes I agree we must handle this situation.
> >
> > > we will failed at the second time as expected, but will not able to
> > > detach the device any more, since during the second scan, original
> vdev->device.devargs is corrupted.
> >
> > The root cause is we remove a devargs which was referenced.
> > Could we overwrite the first devargs instead of removing it?
> >
> >
> 
> It's also possible to add a back-reference to an rte_device in [1], but that can
> only work if only one rte_device references a devargs.
> It seems to be the case now, but it might be good to enforce explicitly that
> when a bus scans its devices, it should do a 1-to-1 map to devargs.
> 
> If mapping rte_device to rte_devargs needs to respect rules, it could help bus
> developpers to have a function that will do the job: verify that the devargs is
> not currently used, add the back-reference to the rte_device.
> 
> With the proper back-reference, it is possible to clean-up the device when
> removing the devargs 

This may still not work for vdev, since the old reference is used in vdev_find to find a exist device by name during scan.
(For PCI device, we have pci_addr, but vdev we use devargs->name to identify device, anyway this can be fixed in vdev, but that required a clone on the device name also break the coupling somehow.)
I just don't understand "why we must tight the tighten the device -> devargs coupling, not loosen it"

(and also to add the rte_devargs_extract() function
> that would allow keeping the original devargs and insert it back if the hotplug
> fails, then the mapping must be restored).

> 
> [1]: https://mails.dpdk.org/archives/dev/2018-November/118274.html
> 
> --
> Gaëtan Rivet
> 6WIND

  reply	other threads:[~2018-11-07 16:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-06  0:31 Qi Zhang
2018-11-06  8:53 ` Gaëtan Rivet
2018-11-06  9:00 ` Thomas Monjalon
2018-11-06 15:46   ` Zhang, Qi Z
2018-11-06 20:36     ` Thomas Monjalon
2018-11-06 23:33       ` Gaëtan Rivet
2018-11-07 16:53         ` Zhang, Qi Z [this message]
2018-11-07 17:15           ` Gaëtan Rivet
2018-11-07 17:46             ` Zhang, Qi Z
2018-11-12  0:50               ` Thomas Monjalon

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=039ED4275CED7440929022BC67E70611532E0AC3@SHSMSX103.ccr.corp.intel.com \
    --to=qi.z.zhang@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=gaetan.rivet@6wind.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).