DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Huang, Wei" <wei.huang@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"david.marchand@redhat.com" <david.marchand@redhat.com>,
	"stable@dpdk.org" <stable@dpdk.org>,
	"Xu, Rosen" <rosen.xu@intel.com>,
	"Zhang, Tianfei" <tianfei.zhang@intel.com>,
	"Zhang, Qi Z" <qi.z.zhang@intel.com>
Subject: RE: [PATCH v1] raw/ifpga: remove virtual device unplug operation
Date: Thu, 23 Mar 2023 03:26:06 +0000	[thread overview]
Message-ID: <DM6PR11MB3530C1DC22B323BC60D74CF5EF879@DM6PR11MB3530.namprd11.prod.outlook.com> (raw)
In-Reply-To: <5367342.29KlJPOoH8@thomas>



> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Wednesday, March 22, 2023 19:54
> To: Huang, Wei <wei.huang@intel.com>
> Cc: dev@dpdk.org; david.marchand@redhat.com; stable@dpdk.org; Xu,
> Rosen <rosen.xu@intel.com>; Zhang, Tianfei <tianfei.zhang@intel.com>;
> Zhang, Qi Z <qi.z.zhang@intel.com>
> Subject: Re: [PATCH v1] raw/ifpga: remove virtual device unplug operation
> 
> 22/03/2023 02:26, Huang, Wei:
> > From: Thomas Monjalon <thomas@monjalon.net>
> > > 21/03/2023 09:41, Huang, Wei:
> > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > 21/03/2023 01:11, Huang, Wei:
> > > > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > > > 16/03/2023 21:44, Wei Huang:
> > > > > > > > VDEV bus has implemented cleanup() function to perform
> > > > > > > > cleanup for devices on the bus during eal_cleanup(), so
> > > > > > > > there is no need for ifpga driver to record virtual devices and
> unplug them.
> > > > > > >
> > > > > > > Why no need?
> > > > > > > If the application wants to explicitly remove a device, what
> happens?
> > > > > > >
> > > > > > >
> > > > > > EAL will output an error information "Cannot find plugged device
> (%s)".
> > > > >
> > > > > It does not look what we expect.
> > > > >
> > > > Let me clear it.
> > > > With this patch, no error information will be outputted.
> > > > Without this patch, error information will be outputted.
> > > > Because bus cleanup action will unplug virtual device, then ifpga
> > > > PMD unplug the virtual device which is already be cleanup,
> > >
> > > Why ipfga unplug the device after the bus cleanup?
> > > I'm not following.
> > >
> > The virtual device is created upon ifpga, if VDEV bus doesn't perform
> > cleanup, ifpga has the responsibility to unplug these virtual devices.
> 
> Really I don't understand the flow.
> Are you talking about EAL cleanup case?
Yes, it's about EAL cleanup.
> What happens first? Do you need ifpga to be called first?
The cleanup flow is rte_eal_cleanup() -> eal_bus_cleanup()
eal_bus_cleanup() will call each bus's cleanup method to complete cleanup work.  
There are three types of device related to ifpga PMD: PCI device, VDEV device and AFU device.
VDEV device is created on PCI device, it's a mediate device which purpose is to plug a AFU device on IFPGA bus.
Before eal_bus_cleanup() is implemented, application will call rte_pmd_ifpga_cleanup() to remove PCI device, VDEV device will be removed when PCI device is removed, AFU device will be removed when VDEV device is removed, it works fine.
Now eal_bus_cleanup() takes the job, application has no need to call rte_pmd_ifpga_cleanup(), ifpga PCI device has no need to remove ifpga VDEV device and ifpga VDEV device has no need to remove ifpga AFU device.
> I think you need the correct checks to allow any order of cleanup.
When this patch is committed, no order dependent on cleanup.

> > > > bus->find_device() returns NULL,
> > > > EAL output "Cannot find plugged device (%s)\n" at line 302 in
> > > > eal_common_dev.c
> > >
> > > Anyway, the good answer is not to completely remove the "remove"
> > > operation.
> > >
> > If not to completely remove the "remove", the same virtual device will be
> unplug twice, is it reasonable?
> 
> You need to add a check to not unplug something already unplugged.
> But you must allow the user calling "remove" directly.
> 
rte_pmd_ifpga_cleanup() is the only one interface for user to calling "remove" directly, when this patch is committed, VDEV and AFU device will not be unplugged twice.
For PCI device, the implementation of rte_pmd_ifpga_cleanup() is like below
	for (i = 0; i < IFPGA_RAWDEV_NUM; i++) {
		dev = &ifpga_rawdevices[i];
		if (dev->rawdev) {
			rte_rawdev_pmd_release(dev->rawdev);
			dev->rawdev = NULL;
		}
	}
If ifpga PCI device is already removed, dev->rawdev is NULL, it will not be unplugged again.


  reply	other threads:[~2023-03-23  3:26 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-16 20:44 Wei Huang
2023-03-20  6:51 ` Xu, Rosen
2023-03-20 12:58   ` Zhang, Qi Z
2023-03-20 13:00     ` Zhang, Qi Z
2023-03-20 16:06 ` Thomas Monjalon
2023-03-21  0:11   ` Huang, Wei
2023-03-21  8:14     ` Thomas Monjalon
2023-03-21  8:41       ` Huang, Wei
2023-03-21 10:30         ` Thomas Monjalon
2023-03-22  1:26           ` Huang, Wei
2023-03-22 11:54             ` Thomas Monjalon
2023-03-23  3:26               ` Huang, Wei [this message]
2023-03-23  8:52                 ` Thomas Monjalon
2023-03-24  1:27                   ` Huang, Wei

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=DM6PR11MB3530C1DC22B323BC60D74CF5EF879@DM6PR11MB3530.namprd11.prod.outlook.com \
    --to=wei.huang@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=qi.z.zhang@intel.com \
    --cc=rosen.xu@intel.com \
    --cc=stable@dpdk.org \
    --cc=thomas@monjalon.net \
    --cc=tianfei.zhang@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).