[RFC] eal: add bus cleanup to eal cleanup

Message ID 20220419161438.1837860-1-kevin.laatz@intel.com (mailing list archive)
State Superseded, archived
Delegated to: Thomas Monjalon
Headers
Series [RFC] eal: add bus cleanup to eal cleanup |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/Intel-compilation success Compilation OK
ci/intel-Testing success Testing PASS

Commit Message

Kevin Laatz April 19, 2022, 4:14 p.m. UTC
  During EAL init, all buses are probed and the devices found are
initialized. On eal_cleanup(), the inverse does not happen, meaning any
allocated memory and other configuration will not be cleaned up
appropriately on exit.

Currently, in order for device cleanup to take place, applications must
call the driver-relevant functions to ensure proper cleanup is done before
the application exits. Since initialization occurs for all devices on the
bus, not just the devices used by an application, it requires a)
application awareness of all bus devices that could have been probed on the
system, and b) code duplication across applications to ensure cleanup is
performed. An example of this is rte_eth_dev_close() which is commonly used
across the example applications.

This RFC proposes adding bus cleanup to the eal_cleanup() to make EAL's
init/exit more symmetrical, ensuring all bus devices are cleaned up
appropriately without the application needing to be aware of all bus types
that may have been probed during initialization.

Contained in this RFC are the changes required to perform cleanup for
devices on the PCI bus during eal_cleanup(). This can be expanded in
subsequent versions if these changes are desired. There would be an ask for
bus maintainers to add the relevant cleanup for their buses since they have
the domain expertise.

Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
---
 drivers/bus/pci/pci_common.c    | 29 +++++++++++++++++++++++++++++
 lib/eal/common/eal_common_bus.c | 18 ++++++++++++++++++
 lib/eal/include/rte_bus.h       | 23 +++++++++++++++++++++++
 lib/eal/linux/eal.c             |  1 +
 4 files changed, 71 insertions(+)
  

Comments

Stephen Hemminger April 19, 2022, 4:36 p.m. UTC | #1
On Tue, 19 Apr 2022 17:14:38 +0100
Kevin Laatz <kevin.laatz@intel.com> wrote:

> +		RTE_LOG(INFO, EAL,
> +				"Clean up PCI driver: %s (%x:%x) device: "PCI_PRI_FMT" (socket %i)\n",
> +				drv->driver.name, dev->id.vendor_id, dev->id.device_id,
> +				loc->domain, loc->bus, loc->devid, loc->function,
> +				dev->device.numa_node);
> +

Looks like a debug message, do we really need more log spam?
  
Morten Brørup April 20, 2022, 6:55 a.m. UTC | #2
> From: Kevin Laatz [mailto:kevin.laatz@intel.com]
> Sent: Tuesday, 19 April 2022 18.15
> 
> During EAL init, all buses are probed and the devices found are
> initialized. On eal_cleanup(), the inverse does not happen, meaning any
> allocated memory and other configuration will not be cleaned up
> appropriately on exit.
> 
> Currently, in order for device cleanup to take place, applications must
> call the driver-relevant functions to ensure proper cleanup is done
> before
> the application exits. Since initialization occurs for all devices on
> the
> bus, not just the devices used by an application, it requires a)
> application awareness of all bus devices that could have been probed on
> the
> system, and b) code duplication across applications to ensure cleanup
> is
> performed. An example of this is rte_eth_dev_close() which is commonly
> used
> across the example applications.
> 
> This RFC proposes adding bus cleanup to the eal_cleanup() to make EAL's
> init/exit more symmetrical, ensuring all bus devices are cleaned up
> appropriately without the application needing to be aware of all bus
> types
> that may have been probed during initialization.
> 
> Contained in this RFC are the changes required to perform cleanup for
> devices on the PCI bus during eal_cleanup(). This can be expanded in
> subsequent versions if these changes are desired. There would be an ask
> for
> bus maintainers to add the relevant cleanup for their buses since they
> have
> the domain expertise.
> 
> Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
> ---

[...]

> +		RTE_LOG(INFO, EAL,
> +				"Clean up PCI driver: %s (%x:%x) device:
> "PCI_PRI_FMT" (socket %i)\n",
> +				drv->driver.name, dev->id.vendor_id, dev-
> >id.device_id,
> +				loc->domain, loc->bus, loc->devid, loc-
> >function,
> +				dev->device.numa_node);

I agree with Stephen, this message might as well be DEBUG level. You could argue for symmetry: If the "alloc" message during startup is INFO level, it makes sense using INFO level for the "free" message during cleanup too. However, the message probably has far lower information value during cleanup (because this driver cleanup is expected to happen), so I would degrade it to DEBUG level. Symmetry is not always the strongest argument. I have no strong preference, so I'll leave it up to you, Kevin.

[...]

> @@ -263,6 +275,7 @@ struct rte_bus {
>  	const char *name;            /**< Name of the bus */
>  	rte_bus_scan_t scan;         /**< Scan for devices attached to
> bus */
>  	rte_bus_probe_t probe;       /**< Probe devices on bus */
> +	rte_bus_cleanup_t cleanup;   /**< Cleanup devices on bus */
>  	rte_bus_find_device_t find_device; /**< Find a device on the bus
> */
>  	rte_bus_plug_t plug;         /**< Probe single device for drivers
> */
>  	rte_bus_unplug_t unplug;     /**< Remove single device from
> driver */

Have you considered if modifying the rte_bus structure in /lib/eal/include/rte_bus.h breaks the ABI or not?


Overall, this patch is certainly a good idea!

On the condition that modifying the rte_bus structure does not break the ABI...

Acked-by: Morten Brørup <mb@smartsharesystems.com>
  
Kevin Laatz April 22, 2022, 9:18 a.m. UTC | #3
On 20/04/2022 07:55, Morten Brørup wrote:
>> From: Kevin Laatz [mailto:kevin.laatz@intel.com]
>> Sent: Tuesday, 19 April 2022 18.15
>>
>> During EAL init, all buses are probed and the devices found are
>> initialized. On eal_cleanup(), the inverse does not happen, meaning any
>> allocated memory and other configuration will not be cleaned up
>> appropriately on exit.
>>
>> Currently, in order for device cleanup to take place, applications must
>> call the driver-relevant functions to ensure proper cleanup is done
>> before
>> the application exits. Since initialization occurs for all devices on
>> the
>> bus, not just the devices used by an application, it requires a)
>> application awareness of all bus devices that could have been probed on
>> the
>> system, and b) code duplication across applications to ensure cleanup
>> is
>> performed. An example of this is rte_eth_dev_close() which is commonly
>> used
>> across the example applications.
>>
>> This RFC proposes adding bus cleanup to the eal_cleanup() to make EAL's
>> init/exit more symmetrical, ensuring all bus devices are cleaned up
>> appropriately without the application needing to be aware of all bus
>> types
>> that may have been probed during initialization.
>>
>> Contained in this RFC are the changes required to perform cleanup for
>> devices on the PCI bus during eal_cleanup(). This can be expanded in
>> subsequent versions if these changes are desired. There would be an ask
>> for
>> bus maintainers to add the relevant cleanup for their buses since they
>> have
>> the domain expertise.
>>
>> Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
>> ---
> [...]
>
>> +		RTE_LOG(INFO, EAL,
>> +				"Clean up PCI driver: %s (%x:%x) device:
>> "PCI_PRI_FMT" (socket %i)\n",
>> +				drv->driver.name, dev->id.vendor_id, dev-
>>> id.device_id,
>> +				loc->domain, loc->bus, loc->devid, loc-
>>> function,
>> +				dev->device.numa_node);
> I agree with Stephen, this message might as well be DEBUG level. You could argue for symmetry: If the "alloc" message during startup is INFO level, it makes sense using INFO level for the "free" message during cleanup too. However, the message probably has far lower information value during cleanup (because this driver cleanup is expected to happen), so I would degrade it to DEBUG level. Symmetry is not always the strongest argument. I have no strong preference, so I'll leave it up to you, Kevin.

Thanks for the feedback.

+1, will change to debug for v2.


>
> [...]
>
>> @@ -263,6 +275,7 @@ struct rte_bus {
>>   	const char *name;            /**< Name of the bus */
>>   	rte_bus_scan_t scan;         /**< Scan for devices attached to
>> bus */
>>   	rte_bus_probe_t probe;       /**< Probe devices on bus */
>> +	rte_bus_cleanup_t cleanup;   /**< Cleanup devices on bus */
>>   	rte_bus_find_device_t find_device; /**< Find a device on the bus
>> */
>>   	rte_bus_plug_t plug;         /**< Probe single device for drivers
>> */
>>   	rte_bus_unplug_t unplug;     /**< Remove single device from
>> driver */
> Have you considered if modifying the rte_bus structure in /lib/eal/include/rte_bus.h breaks the ABI or not?

I've looked into this and have run test-meson-builds with ABI checks 
enabled.

The output of those checks flagged some potential breaks, however I 
believe these are false positives. The output indicated 2 potential 
breaks (in multiple places, but the root is the same)

1. Member has been added to the rte_bus struct. This is flagged as a 
sub-type change, however since rte_bus is only ever reference by 
pointer, it is not a break.

2. Offset of members changes in 'rte_pci_bus' and 'rte_vmbus_bus' 
structs. These structs are only used internally so also do no break ABI.


Since the ABI checks do flag the addition, I will add an entry to the 
abignore for the v2.


>
>
> Overall, this patch is certainly a good idea!
>
> On the condition that modifying the rte_bus structure does not break the ABI...
>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
>
  
Morten Brørup April 22, 2022, 12:14 p.m. UTC | #4
> From: Kevin Laatz [mailto:kevin.laatz@intel.com]
> Sent: Friday, 22 April 2022 11.18
> 
> On 20/04/2022 07:55, Morten Brørup wrote:
> >> From: Kevin Laatz [mailto:kevin.laatz@intel.com]
> >> Sent: Tuesday, 19 April 2022 18.15
> >>
> >> During EAL init, all buses are probed and the devices found are
> >> initialized. On eal_cleanup(), the inverse does not happen, meaning
> any
> >> allocated memory and other configuration will not be cleaned up
> >> appropriately on exit.
> >>
> >> Currently, in order for device cleanup to take place, applications
> must
> >> call the driver-relevant functions to ensure proper cleanup is done
> >> before
> >> the application exits. Since initialization occurs for all devices
> on
> >> the
> >> bus, not just the devices used by an application, it requires a)
> >> application awareness of all bus devices that could have been probed
> on
> >> the
> >> system, and b) code duplication across applications to ensure
> cleanup
> >> is
> >> performed. An example of this is rte_eth_dev_close() which is
> commonly
> >> used
> >> across the example applications.
> >>
> >> This RFC proposes adding bus cleanup to the eal_cleanup() to make
> EAL's
> >> init/exit more symmetrical, ensuring all bus devices are cleaned up
> >> appropriately without the application needing to be aware of all bus
> >> types
> >> that may have been probed during initialization.
> >>
> >> Contained in this RFC are the changes required to perform cleanup
> for
> >> devices on the PCI bus during eal_cleanup(). This can be expanded in
> >> subsequent versions if these changes are desired. There would be an
> ask
> >> for
> >> bus maintainers to add the relevant cleanup for their buses since
> they
> >> have
> >> the domain expertise.
> >>
> >> Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
> >> ---
> > [...]
> >
> >> +		RTE_LOG(INFO, EAL,
> >> +				"Clean up PCI driver: %s (%x:%x) device:
> >> "PCI_PRI_FMT" (socket %i)\n",
> >> +				drv->driver.name, dev->id.vendor_id, dev-
> >>> id.device_id,
> >> +				loc->domain, loc->bus, loc->devid, loc-
> >>> function,
> >> +				dev->device.numa_node);
> > I agree with Stephen, this message might as well be DEBUG level. You
> could argue for symmetry: If the "alloc" message during startup is INFO
> level, it makes sense using INFO level for the "free" message during
> cleanup too. However, the message probably has far lower information
> value during cleanup (because this driver cleanup is expected to
> happen), so I would degrade it to DEBUG level. Symmetry is not always
> the strongest argument. I have no strong preference, so I'll leave it
> up to you, Kevin.
> 
> Thanks for the feedback.
> 
> +1, will change to debug for v2.
> 
> 
> >
> > [...]
> >
> >> @@ -263,6 +275,7 @@ struct rte_bus {
> >>   	const char *name;            /**< Name of the bus */
> >>   	rte_bus_scan_t scan;         /**< Scan for devices attached to
> >> bus */
> >>   	rte_bus_probe_t probe;       /**< Probe devices on bus */
> >> +	rte_bus_cleanup_t cleanup;   /**< Cleanup devices on bus */
> >>   	rte_bus_find_device_t find_device; /**< Find a device on the bus
> >> */
> >>   	rte_bus_plug_t plug;         /**< Probe single device for drivers
> >> */
> >>   	rte_bus_unplug_t unplug;     /**< Remove single device from
> >> driver */
> > Have you considered if modifying the rte_bus structure in
> /lib/eal/include/rte_bus.h breaks the ABI or not?
> 
> I've looked into this and have run test-meson-builds with ABI checks
> enabled.
> 
> The output of those checks flagged some potential breaks, however I
> believe these are false positives. The output indicated 2 potential
> breaks (in multiple places, but the root is the same)
> 
> 1. Member has been added to the rte_bus struct. This is flagged as a
> sub-type change, however since rte_bus is only ever reference by
> pointer, it is not a break.
> 
> 2. Offset of members changes in 'rte_pci_bus' and 'rte_vmbus_bus'
> structs. These structs are only used internally so also do no break
> ABI.
> 

Sounds good! Then there should be no more worries. :-)

> 
> Since the ABI checks do flag the addition, I will add an entry to the
> abignore for the v2.
> 
> 
> >
> >
> > Overall, this patch is certainly a good idea!
> >
> > On the condition that modifying the rte_bus structure does not break
> the ABI...
> >
> > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> >
  

Patch

diff --git a/drivers/bus/pci/pci_common.c b/drivers/bus/pci/pci_common.c
index 37ab879779..ee6cce8fc6 100644
--- a/drivers/bus/pci/pci_common.c
+++ b/drivers/bus/pci/pci_common.c
@@ -394,6 +394,34 @@  pci_probe(void)
 	return (probed && probed == failed) ? -1 : 0;
 }
 
+static int
+pci_cleanup(void)
+{
+	struct rte_pci_device *dev = NULL;
+	int ret = 0;
+
+	FOREACH_DEVICE_ON_PCIBUS(dev) {
+		struct rte_pci_addr *loc = &dev->addr;
+		struct rte_pci_driver *drv = dev->driver;
+
+		RTE_LOG(INFO, EAL,
+				"Clean up PCI driver: %s (%x:%x) device: "PCI_PRI_FMT" (socket %i)\n",
+				drv->driver.name, dev->id.vendor_id, dev->id.device_id,
+				loc->domain, loc->bus, loc->devid, loc->function,
+				dev->device.numa_node);
+
+		ret = drv->remove(dev);
+		if (ret < 0) {
+			RTE_LOG(ERR, EAL, "Cleanup for device "PCI_PRI_FMT" failed\n",
+					dev->addr.domain, dev->addr.bus, dev->addr.devid,
+					dev->addr.function);
+			rte_errno = errno;
+		}
+	}
+
+	return ret;
+}
+
 /* dump one device */
 static int
 pci_dump_one_device(FILE *f, struct rte_pci_device *dev)
@@ -813,6 +841,7 @@  struct rte_pci_bus rte_pci_bus = {
 	.bus = {
 		.scan = rte_pci_scan,
 		.probe = pci_probe,
+		.cleanup = pci_cleanup,
 		.find_device = pci_find_device,
 		.plug = pci_plug,
 		.unplug = pci_unplug,
diff --git a/lib/eal/common/eal_common_bus.c b/lib/eal/common/eal_common_bus.c
index baa5b532af..046a06a2bf 100644
--- a/lib/eal/common/eal_common_bus.c
+++ b/lib/eal/common/eal_common_bus.c
@@ -85,6 +85,24 @@  rte_bus_probe(void)
 	return 0;
 }
 
+/* Clean up all devices of all buses */
+int
+rte_bus_cleanup(void)
+{
+	int ret;
+	struct rte_bus *bus;
+
+	TAILQ_FOREACH(bus, &rte_bus_list, next) {
+		if (bus->cleanup == NULL)
+			continue;
+		ret = bus->cleanup();
+		if (ret)
+			RTE_LOG(ERR, EAL, "Bus (%s) cleanup failed.\n", bus->name);
+	}
+
+	return 0;
+}
+
 /* Dump information of a single bus */
 static int
 bus_dump_one(FILE *f, struct rte_bus *bus)
diff --git a/lib/eal/include/rte_bus.h b/lib/eal/include/rte_bus.h
index bbbb6efd28..7dbc398408 100644
--- a/lib/eal/include/rte_bus.h
+++ b/lib/eal/include/rte_bus.h
@@ -66,6 +66,18 @@  typedef int (*rte_bus_scan_t)(void);
  */
 typedef int (*rte_bus_probe_t)(void);
 
+/**
+ * Implementation specific cleanup function which is responsible for cleaning up
+ * devices on that bus with applicable drivers.
+ *
+ * This is called while iterating over each registered bus.
+ *
+ * @return
+ * 0 for successful cleanup
+ * !0 for any error during cleanup
+ */
+typedef int (*rte_bus_cleanup_t)(void);
+
 /**
  * Device iterator to find a device on a bus.
  *
@@ -263,6 +275,7 @@  struct rte_bus {
 	const char *name;            /**< Name of the bus */
 	rte_bus_scan_t scan;         /**< Scan for devices attached to bus */
 	rte_bus_probe_t probe;       /**< Probe devices on bus */
+	rte_bus_cleanup_t cleanup;   /**< Cleanup devices on bus */
 	rte_bus_find_device_t find_device; /**< Find a device on the bus */
 	rte_bus_plug_t plug;         /**< Probe single device for drivers */
 	rte_bus_unplug_t unplug;     /**< Remove single device from driver */
@@ -317,6 +330,16 @@  int rte_bus_scan(void);
  */
 int rte_bus_probe(void);
 
+/**
+ * For each device on the buses, perform a driver 'match' and call the
+ * driver-specific function for device cleanup.
+ *
+ * @return
+ * 0 for successful match/cleanup
+ * !0 otherwise
+ */
+int rte_bus_cleanup(void);
+
 /**
  * Dump information of all the buses registered with EAL.
  *
diff --git a/lib/eal/linux/eal.c b/lib/eal/linux/eal.c
index 025e5cc10d..37983b98c0 100644
--- a/lib/eal/linux/eal.c
+++ b/lib/eal/linux/eal.c
@@ -1268,6 +1268,7 @@  rte_eal_cleanup(void)
 	vfio_mp_sync_cleanup();
 #endif
 	rte_mp_channel_cleanup();
+	rte_bus_cleanup();
 	/* after this point, any DPDK pointers will become dangling */
 	rte_eal_memory_detach();
 	eal_mp_dev_hotplug_cleanup();