2018-01-29 14:11:25 +01:00
|
|
|
/* SPDX-License-Identifier: BSD-3-Clause
|
|
|
|
* Copyright(c) 2014 6WIND S.A.
|
2013-09-18 12:00:00 +02:00
|
|
|
*/
|
|
|
|
|
2014-04-21 10:59:31 -04:00
|
|
|
#ifndef _RTE_DEV_H_
|
|
|
|
#define _RTE_DEV_H_
|
2014-04-11 09:36:52 +02:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @file
|
|
|
|
*
|
2014-04-21 10:59:31 -04:00
|
|
|
* RTE PMD Driver Registration Interface
|
2014-04-11 09:36:52 +02:00
|
|
|
*
|
2014-04-21 10:59:31 -04:00
|
|
|
* This file manages the list of device drivers.
|
2014-04-11 09:36:52 +02:00
|
|
|
*/
|
2013-09-18 12:00:00 +02:00
|
|
|
|
|
|
|
#ifdef __cplusplus
|
|
|
|
extern "C" {
|
|
|
|
#endif
|
|
|
|
|
2015-11-25 13:25:09 +00:00
|
|
|
#include <stdio.h>
|
2016-07-07 16:59:14 +02:00
|
|
|
|
2017-12-21 14:00:04 +01:00
|
|
|
#include <rte_config.h>
|
2018-01-21 20:48:06 -05:00
|
|
|
#include <rte_compat.h>
|
2015-11-25 13:25:09 +00:00
|
|
|
#include <rte_log.h>
|
|
|
|
|
2018-04-13 16:30:38 +08:00
|
|
|
/**
|
|
|
|
* The device event type.
|
|
|
|
*/
|
|
|
|
enum rte_dev_event_type {
|
|
|
|
RTE_DEV_EVENT_ADD, /**< device being added */
|
|
|
|
RTE_DEV_EVENT_REMOVE, /**< device being removed */
|
|
|
|
RTE_DEV_EVENT_MAX /**< max value of this enum */
|
|
|
|
};
|
|
|
|
|
2018-10-04 14:44:41 +08:00
|
|
|
typedef void (*rte_dev_event_cb_fn)(const char *device_name,
|
2018-04-13 16:30:38 +08:00
|
|
|
enum rte_dev_event_type event,
|
|
|
|
void *cb_arg);
|
|
|
|
|
2015-11-25 13:25:09 +00:00
|
|
|
/* Macros to check for invalid function pointers */
|
|
|
|
#define RTE_FUNC_PTR_OR_ERR_RET(func, retval) do { \
|
2019-02-26 13:34:23 -08:00
|
|
|
if ((func) == NULL) \
|
2015-11-25 13:25:09 +00:00
|
|
|
return retval; \
|
|
|
|
} while (0)
|
|
|
|
|
|
|
|
#define RTE_FUNC_PTR_OR_RET(func) do { \
|
2019-02-26 13:34:23 -08:00
|
|
|
if ((func) == NULL) \
|
2015-11-25 13:25:09 +00:00
|
|
|
return; \
|
|
|
|
} while (0)
|
|
|
|
|
2017-07-15 19:59:27 +02:00
|
|
|
/**
|
|
|
|
* Device policies.
|
|
|
|
*/
|
|
|
|
enum rte_dev_policy {
|
2020-11-10 14:55:38 -08:00
|
|
|
RTE_DEV_ALLOWED,
|
|
|
|
RTE_DEV_BLOCKED,
|
2017-07-15 19:59:27 +02:00
|
|
|
};
|
|
|
|
|
2016-09-20 18:11:32 +05:30
|
|
|
/**
|
|
|
|
* A generic memory resource representation.
|
|
|
|
*/
|
|
|
|
struct rte_mem_resource {
|
|
|
|
uint64_t phys_addr; /**< Physical address, 0 if not resource. */
|
|
|
|
uint64_t len; /**< Length of the resource. */
|
|
|
|
void *addr; /**< Virtual address, NULL when not mapped. */
|
|
|
|
};
|
2015-11-25 13:25:09 +00:00
|
|
|
|
2017-05-04 17:44:38 +02:00
|
|
|
/**
|
|
|
|
* A structure describing a device driver.
|
|
|
|
*/
|
|
|
|
struct rte_driver {
|
eal: remove sys/queue.h from public headers
Currently there are some public headers that include 'sys/queue.h', which
is not POSIX, but usually provided by the Linux/BSD system library.
(Not in POSIX.1, POSIX.1-2001, or POSIX.1-2008. Present on the BSDs.)
The file is missing on Windows. During the Windows build, DPDK uses a
bundled copy, so building a DPDK library works fine. But when OVS or other
applications use DPDK as a library, because some DPDK public headers
include 'sys/queue.h', on Windows, it triggers an error due to no such
file.
One solution is to install the 'lib/eal/windows/include/sys/queue.h' into
Windows environment, such as [1]. However, this means DPDK exports the
functionalities of 'sys/queue.h' into the environment, which might cause
symbols, macros, headers clashing with other applications.
The patch fixes it by removing the "#include <sys/queue.h>" from
DPDK public headers, so programs including DPDK headers don't depend
on the system to provide 'sys/queue.h'. When these public headers use
macros such as TAILQ_xxx, we replace it by the ones with RTE_ prefix.
For Windows, we copy the definitions from <sys/queue.h> to rte_os.h
in Windows EAL. Note that these RTE_ macros are compatible with
<sys/queue.h>, both at the level of API (to use with <sys/queue.h>
macros in C files) and ABI (to avoid breaking it).
Additionally, the TAILQ_FOREACH_SAFE is not part of <sys/queue.h>,
the patch replaces it with RTE_TAILQ_FOREACH_SAFE.
[1] http://mails.dpdk.org/archives/dev/2021-August/216304.html
Suggested-by: Nick Connolly <nick.connolly@mayadata.io>
Suggested-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Signed-off-by: William Tu <u9012063@gmail.com>
Acked-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Acked-by: Narcisa Vasile <navasile@linux.microsoft.com>
2021-08-24 16:21:03 +00:00
|
|
|
RTE_TAILQ_ENTRY(rte_driver) next; /**< Next in list. */
|
2017-05-04 17:44:38 +02:00
|
|
|
const char *name; /**< Driver name. */
|
|
|
|
const char *alias; /**< Driver alias. */
|
|
|
|
};
|
2016-09-20 18:11:35 +05:30
|
|
|
|
2017-09-27 10:23:20 +01:00
|
|
|
/*
|
|
|
|
* Internal identifier length
|
|
|
|
* Sufficiently large to allow for UUID or PCI address
|
|
|
|
*/
|
|
|
|
#define RTE_DEV_NAME_MAX_LEN 64
|
2017-06-09 19:36:04 +01:00
|
|
|
|
2016-09-20 18:11:35 +05:30
|
|
|
/**
|
|
|
|
* A structure describing a generic device.
|
|
|
|
*/
|
|
|
|
struct rte_device {
|
eal: remove sys/queue.h from public headers
Currently there are some public headers that include 'sys/queue.h', which
is not POSIX, but usually provided by the Linux/BSD system library.
(Not in POSIX.1, POSIX.1-2001, or POSIX.1-2008. Present on the BSDs.)
The file is missing on Windows. During the Windows build, DPDK uses a
bundled copy, so building a DPDK library works fine. But when OVS or other
applications use DPDK as a library, because some DPDK public headers
include 'sys/queue.h', on Windows, it triggers an error due to no such
file.
One solution is to install the 'lib/eal/windows/include/sys/queue.h' into
Windows environment, such as [1]. However, this means DPDK exports the
functionalities of 'sys/queue.h' into the environment, which might cause
symbols, macros, headers clashing with other applications.
The patch fixes it by removing the "#include <sys/queue.h>" from
DPDK public headers, so programs including DPDK headers don't depend
on the system to provide 'sys/queue.h'. When these public headers use
macros such as TAILQ_xxx, we replace it by the ones with RTE_ prefix.
For Windows, we copy the definitions from <sys/queue.h> to rte_os.h
in Windows EAL. Note that these RTE_ macros are compatible with
<sys/queue.h>, both at the level of API (to use with <sys/queue.h>
macros in C files) and ABI (to avoid breaking it).
Additionally, the TAILQ_FOREACH_SAFE is not part of <sys/queue.h>,
the patch replaces it with RTE_TAILQ_FOREACH_SAFE.
[1] http://mails.dpdk.org/archives/dev/2021-August/216304.html
Suggested-by: Nick Connolly <nick.connolly@mayadata.io>
Suggested-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Signed-off-by: William Tu <u9012063@gmail.com>
Acked-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Acked-by: Narcisa Vasile <navasile@linux.microsoft.com>
2021-08-24 16:21:03 +00:00
|
|
|
RTE_TAILQ_ENTRY(rte_device) next; /**< Next device */
|
2017-04-11 17:44:08 +02:00
|
|
|
const char *name; /**< Device name */
|
2018-09-25 22:55:27 +02:00
|
|
|
const struct rte_driver *driver; /**< Driver assigned after probing */
|
2018-10-03 00:25:06 +02:00
|
|
|
const struct rte_bus *bus; /**< Bus handle assigned on scan */
|
2016-09-20 18:11:35 +05:30
|
|
|
int numa_node; /**< NUMA node connection */
|
eal: allow probing a device again
In the devargs syntax for device representors, it is possible to add
several devices at once: -w dbdf,representor=[0-3]
It will become a more frequent case when introducing wildcards
and ranges in the new devargs syntax.
If a devargs string is provided for probing, and updated with a bigger
range for a new probing, then we do not want it to fail because
part of this range was already probed previously.
There can be new ports to create from an existing rte_device.
That's why the check for an already probed device
is moved as bus responsibility.
In the case of vdev, a global check is kept in insert_vdev(),
assuming that a vdev will always have only one port.
In the case of ifpga and vmbus, already probed devices are checked.
In the case of NXP buses, the probing is done only once (no hotplug),
though a check is added at bus level for consistency.
In the case of PCI, a driver flag is added to allow PMD probing again.
Only the PMD knows the ports attached to one rte_device.
As another consequence of being able to probe in several steps,
the field rte_device.devargs must not be considered as a full
representation of the rte_device, but only the latest probing args.
Anyway, the field rte_device.devargs is used only for probing.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Reviewed-by: Andrew Rybchenko <arybchenko@solarflare.com>
Tested-by: Andrew Rybchenko <arybchenko@solarflare.com>
Acked-by: Shreyansh Jain <shreyansh.jain@nxp.com>
2018-09-20 01:37:14 +02:00
|
|
|
struct rte_devargs *devargs; /**< Arguments for latest probing */
|
2016-09-20 18:11:35 +05:30
|
|
|
};
|
|
|
|
|
2018-09-25 22:55:27 +02:00
|
|
|
/**
|
|
|
|
* Query status of a device.
|
|
|
|
*
|
|
|
|
* @param dev
|
|
|
|
* Generic device pointer.
|
|
|
|
* @return
|
|
|
|
* (int)true if already probed successfully, 0 otherwise.
|
|
|
|
*/
|
|
|
|
int rte_dev_is_probed(const struct rte_device *dev);
|
|
|
|
|
2017-06-30 20:19:41 +02:00
|
|
|
/**
|
|
|
|
* Hotplug add a given device to a specific bus.
|
|
|
|
*
|
2018-10-16 08:16:28 +08:00
|
|
|
* In multi-process, it will request other processes to add the same device.
|
|
|
|
* A failure, in any process, will rollback the action
|
|
|
|
*
|
2017-06-30 20:19:41 +02:00
|
|
|
* @param busname
|
|
|
|
* The bus name the device is added to.
|
|
|
|
* @param devname
|
|
|
|
* The device name. Based on this device name, eal will identify a driver
|
|
|
|
* capable of handling it and pass it to the driver probing function.
|
2018-09-08 00:27:27 +02:00
|
|
|
* @param drvargs
|
2017-06-30 20:19:41 +02:00
|
|
|
* Device arguments to be passed to the driver.
|
|
|
|
* @return
|
|
|
|
* 0 on success, negative on error.
|
|
|
|
*/
|
2018-09-26 23:22:27 +02:00
|
|
|
int rte_eal_hotplug_add(const char *busname, const char *devname,
|
2018-09-08 00:27:27 +02:00
|
|
|
const char *drvargs);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Add matching devices.
|
|
|
|
*
|
2018-10-16 08:16:28 +08:00
|
|
|
* In multi-process, it will request other processes to add the same device.
|
|
|
|
* A failure, in any process, will rollback the action
|
|
|
|
*
|
2018-09-08 00:27:27 +02:00
|
|
|
* @param devargs
|
|
|
|
* Device arguments including bus, class and driver properties.
|
|
|
|
* @return
|
|
|
|
* 0 on success, negative on error.
|
|
|
|
*/
|
2018-11-01 15:46:32 +01:00
|
|
|
int rte_dev_probe(const char *devargs);
|
2017-06-30 20:19:41 +02:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Hotplug remove a given device from a specific bus.
|
|
|
|
*
|
2018-10-16 08:16:28 +08:00
|
|
|
* In multi-process, it will request other processes to remove the same device.
|
|
|
|
* A failure, in any process, will rollback the action
|
|
|
|
*
|
2017-06-30 20:19:41 +02:00
|
|
|
* @param busname
|
|
|
|
* The bus name the device is removed from.
|
|
|
|
* @param devname
|
|
|
|
* The device name being removed.
|
|
|
|
* @return
|
|
|
|
* 0 on success, negative on error.
|
|
|
|
*/
|
2018-09-26 23:22:27 +02:00
|
|
|
int rte_eal_hotplug_remove(const char *busname, const char *devname);
|
2017-06-30 20:19:41 +02:00
|
|
|
|
2018-09-08 00:27:27 +02:00
|
|
|
/**
|
|
|
|
* Remove one device.
|
|
|
|
*
|
2018-10-16 08:16:28 +08:00
|
|
|
* In multi-process, it will request other processes to remove the same device.
|
|
|
|
* A failure, in any process, will rollback the action
|
|
|
|
*
|
2018-09-08 00:27:27 +02:00
|
|
|
* @param dev
|
|
|
|
* Data structure of the device to remove.
|
|
|
|
* @return
|
|
|
|
* 0 on success, negative on error.
|
|
|
|
*/
|
2018-11-01 15:46:32 +01:00
|
|
|
int rte_dev_remove(struct rte_device *dev);
|
2018-09-08 00:27:27 +02:00
|
|
|
|
2017-06-30 20:19:31 +02:00
|
|
|
/**
|
|
|
|
* Device comparison function.
|
|
|
|
*
|
|
|
|
* This type of function is used to compare an rte_device with arbitrary
|
|
|
|
* data.
|
|
|
|
*
|
|
|
|
* @param dev
|
|
|
|
* Device handle.
|
|
|
|
*
|
|
|
|
* @param data
|
|
|
|
* Data to compare against. The type of this parameter is determined by
|
|
|
|
* the kind of comparison performed by the function.
|
|
|
|
*
|
|
|
|
* @return
|
|
|
|
* 0 if the device matches the data.
|
|
|
|
* !0 if the device does not match.
|
|
|
|
* <0 if ordering is possible and the device is lower than the data.
|
|
|
|
* >0 if ordering is possible and the device is greater than the data.
|
|
|
|
*/
|
|
|
|
typedef int (*rte_dev_cmp_t)(const struct rte_device *dev, const void *data);
|
|
|
|
|
2016-10-10 11:13:15 +05:30
|
|
|
#define RTE_PMD_EXPORT_NAME_ARRAY(n, idx) n##idx[]
|
2016-06-17 14:46:21 -04:00
|
|
|
|
2016-10-10 11:13:15 +05:30
|
|
|
#define RTE_PMD_EXPORT_NAME(name, idx) \
|
|
|
|
static const char RTE_PMD_EXPORT_NAME_ARRAY(this_pmd_name, idx) \
|
2020-02-09 20:43:11 +01:00
|
|
|
__rte_used = RTE_STR(name)
|
2016-06-17 14:46:21 -04:00
|
|
|
|
|
|
|
#define DRV_EXP_TAG(name, tag) __##name##_##tag
|
|
|
|
|
2016-10-10 11:13:15 +05:30
|
|
|
#define RTE_PMD_REGISTER_PCI_TABLE(name, table) \
|
2020-02-09 20:43:11 +01:00
|
|
|
static const char DRV_EXP_TAG(name, pci_tbl_export)[] __rte_used = \
|
2016-06-17 14:46:21 -04:00
|
|
|
RTE_STR(table)
|
|
|
|
|
2016-10-10 11:13:15 +05:30
|
|
|
#define RTE_PMD_REGISTER_PARAM_STRING(name, str) \
|
2016-06-17 14:46:21 -04:00
|
|
|
static const char DRV_EXP_TAG(name, param_string_export)[] \
|
2020-02-09 20:43:11 +01:00
|
|
|
__rte_used = str
|
2014-04-21 10:59:27 -04:00
|
|
|
|
2016-12-15 14:46:39 +01:00
|
|
|
/**
|
|
|
|
* Advertise the list of kernel modules required to run this driver
|
|
|
|
*
|
|
|
|
* This string lists the kernel modules required for the devices
|
|
|
|
* associated to a PMD. The format of each line of the string is:
|
|
|
|
* "<device-pattern> <kmod-expression>".
|
|
|
|
*
|
|
|
|
* The possible formats for the device pattern are:
|
|
|
|
* "*" all devices supported by this driver
|
|
|
|
* "pci:*" all PCI devices supported by this driver
|
|
|
|
* "pci:v8086:d*:sv*:sd*" all PCI devices supported by this driver
|
|
|
|
* whose vendor id is 0x8086.
|
|
|
|
*
|
2019-11-13 16:10:15 +00:00
|
|
|
* The format of the kernel modules list is a parenthesized expression
|
2016-12-15 14:46:39 +01:00
|
|
|
* containing logical-and (&) and logical-or (|).
|
|
|
|
*
|
|
|
|
* The device pattern and the kmod expression are separated by a space.
|
|
|
|
*
|
|
|
|
* Example:
|
|
|
|
* - "* igb_uio | uio_pci_generic | vfio"
|
|
|
|
*/
|
|
|
|
#define RTE_PMD_REGISTER_KMOD_DEP(name, str) \
|
|
|
|
static const char DRV_EXP_TAG(name, kmod_dep_export)[] \
|
2020-02-09 20:43:11 +01:00
|
|
|
__rte_used = str
|
2016-12-15 14:46:39 +01:00
|
|
|
|
2018-07-11 23:44:59 +02:00
|
|
|
/**
|
|
|
|
* Iteration context.
|
|
|
|
*
|
|
|
|
* This context carries over the current iteration state.
|
|
|
|
*/
|
|
|
|
struct rte_dev_iterator {
|
|
|
|
const char *dev_str; /**< device string. */
|
|
|
|
const char *bus_str; /**< bus-related part of device string. */
|
|
|
|
const char *cls_str; /**< class-related part of device string. */
|
|
|
|
struct rte_bus *bus; /**< bus handle. */
|
|
|
|
struct rte_class *cls; /**< class handle. */
|
|
|
|
struct rte_device *device; /**< current position. */
|
|
|
|
void *class_device; /**< additional specialized context. */
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Device iteration function.
|
|
|
|
*
|
|
|
|
* Find the next device matching properties passed in parameters.
|
|
|
|
* The function takes an additional ``start`` parameter, that is
|
|
|
|
* used as starting context when relevant.
|
|
|
|
*
|
|
|
|
* The function returns the current element in the iteration.
|
|
|
|
* This return value will potentially be used as a start parameter
|
|
|
|
* in subsequent calls to the function.
|
|
|
|
*
|
|
|
|
* The additional iterator parameter is only there if a specific
|
|
|
|
* implementation needs additional context. It must not be modified by
|
|
|
|
* the iteration function itself.
|
|
|
|
*
|
|
|
|
* @param start
|
|
|
|
* Starting iteration context.
|
|
|
|
*
|
|
|
|
* @param devstr
|
|
|
|
* Device description string.
|
|
|
|
*
|
|
|
|
* @param it
|
|
|
|
* Device iterator.
|
|
|
|
*
|
|
|
|
* @return
|
|
|
|
* The address of the current element matching the device description
|
|
|
|
* string.
|
|
|
|
*/
|
|
|
|
typedef void *(*rte_dev_iterate_t)(const void *start,
|
|
|
|
const char *devstr,
|
|
|
|
const struct rte_dev_iterator *it);
|
|
|
|
|
2018-07-11 23:45:00 +02:00
|
|
|
/**
|
|
|
|
* Initializes a device iterator.
|
|
|
|
*
|
|
|
|
* This iterator allows accessing a list of devices matching a criteria.
|
|
|
|
* The device matching is made among all buses and classes currently registered,
|
|
|
|
* filtered by the device description given as parameter.
|
|
|
|
*
|
|
|
|
* This function will not allocate any memory. It is safe to stop the
|
|
|
|
* iteration at any moment and let the iterator go out of context.
|
|
|
|
*
|
|
|
|
* @param it
|
|
|
|
* Device iterator handle.
|
|
|
|
*
|
|
|
|
* @param str
|
|
|
|
* Device description string.
|
|
|
|
*
|
|
|
|
* @return
|
|
|
|
* 0 on successful initialization.
|
|
|
|
* <0 on error.
|
|
|
|
*/
|
|
|
|
__rte_experimental
|
|
|
|
int
|
|
|
|
rte_dev_iterator_init(struct rte_dev_iterator *it, const char *str);
|
|
|
|
|
2018-07-11 23:45:01 +02:00
|
|
|
/**
|
|
|
|
* Iterates on a device iterator.
|
|
|
|
*
|
|
|
|
* Generates a new rte_device handle corresponding to the next element
|
|
|
|
* in the list described in comprehension by the iterator.
|
|
|
|
*
|
|
|
|
* The next object is returned, and the iterator is updated.
|
|
|
|
*
|
|
|
|
* @param it
|
|
|
|
* Device iterator handle.
|
|
|
|
*
|
|
|
|
* @return
|
|
|
|
* An rte_device handle if found.
|
|
|
|
* NULL if an error occurred (rte_errno is set).
|
|
|
|
* NULL if no device could be found (rte_errno is not set).
|
|
|
|
*/
|
|
|
|
__rte_experimental
|
|
|
|
struct rte_device *
|
|
|
|
rte_dev_iterator_next(struct rte_dev_iterator *it);
|
|
|
|
|
|
|
|
#define RTE_DEV_FOREACH(dev, devstr, it) \
|
|
|
|
for (rte_dev_iterator_init(it, devstr), \
|
|
|
|
dev = rte_dev_iterator_next(it); \
|
|
|
|
dev != NULL; \
|
|
|
|
dev = rte_dev_iterator_next(it))
|
|
|
|
|
2013-09-18 12:00:00 +02:00
|
|
|
#ifdef __cplusplus
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2018-04-13 16:30:38 +08:00
|
|
|
/**
|
|
|
|
* @warning
|
|
|
|
* @b EXPERIMENTAL: this API may change without prior notice
|
|
|
|
*
|
|
|
|
* It registers the callback for the specific device.
|
2019-06-04 11:21:26 +02:00
|
|
|
* Multiple callbacks can be registered at the same time.
|
2018-04-13 16:30:38 +08:00
|
|
|
*
|
|
|
|
* @param device_name
|
|
|
|
* The device name, that is the param name of the struct rte_device,
|
|
|
|
* null value means for all devices.
|
|
|
|
* @param cb_fn
|
|
|
|
* callback address.
|
|
|
|
* @param cb_arg
|
|
|
|
* address of parameter for callback.
|
|
|
|
*
|
|
|
|
* @return
|
|
|
|
* - On success, zero.
|
|
|
|
* - On failure, a negative value.
|
|
|
|
*/
|
2019-06-29 13:58:53 +02:00
|
|
|
__rte_experimental
|
|
|
|
int
|
2018-04-13 16:30:38 +08:00
|
|
|
rte_dev_event_callback_register(const char *device_name,
|
|
|
|
rte_dev_event_cb_fn cb_fn,
|
|
|
|
void *cb_arg);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @warning
|
|
|
|
* @b EXPERIMENTAL: this API may change without prior notice
|
|
|
|
*
|
|
|
|
* It unregisters the callback according to the specified device.
|
|
|
|
*
|
|
|
|
* @param device_name
|
|
|
|
* The device name, that is the param name of the struct rte_device,
|
|
|
|
* null value means for all devices and their callbacks.
|
|
|
|
* @param cb_fn
|
|
|
|
* callback address.
|
|
|
|
* @param cb_arg
|
|
|
|
* address of parameter for callback, (void *)-1 means to remove all
|
|
|
|
* registered which has the same callback address.
|
|
|
|
*
|
|
|
|
* @return
|
|
|
|
* - On success, return the number of callback entities removed.
|
|
|
|
* - On failure, a negative value.
|
|
|
|
*/
|
2019-06-29 13:58:53 +02:00
|
|
|
__rte_experimental
|
|
|
|
int
|
2018-04-13 16:30:38 +08:00
|
|
|
rte_dev_event_callback_unregister(const char *device_name,
|
|
|
|
rte_dev_event_cb_fn cb_fn,
|
|
|
|
void *cb_arg);
|
|
|
|
|
2018-10-04 14:44:41 +08:00
|
|
|
/**
|
|
|
|
* @warning
|
|
|
|
* @b EXPERIMENTAL: this API may change without prior notice
|
|
|
|
*
|
|
|
|
* Executes all the user application registered callbacks for
|
|
|
|
* the specific device.
|
|
|
|
*
|
|
|
|
* @param device_name
|
|
|
|
* The device name.
|
|
|
|
* @param event
|
|
|
|
* the device event type.
|
|
|
|
*/
|
2019-06-29 13:58:53 +02:00
|
|
|
__rte_experimental
|
|
|
|
void
|
2018-10-04 14:44:41 +08:00
|
|
|
rte_dev_event_callback_process(const char *device_name,
|
|
|
|
enum rte_dev_event_type event);
|
|
|
|
|
2018-04-13 16:30:38 +08:00
|
|
|
/**
|
|
|
|
* @warning
|
|
|
|
* @b EXPERIMENTAL: this API may change without prior notice
|
|
|
|
*
|
|
|
|
* Start the device event monitoring.
|
|
|
|
*
|
|
|
|
* @return
|
|
|
|
* - On success, zero.
|
|
|
|
* - On failure, a negative value.
|
|
|
|
*/
|
2019-06-29 13:58:53 +02:00
|
|
|
__rte_experimental
|
|
|
|
int
|
2018-04-13 16:30:38 +08:00
|
|
|
rte_dev_event_monitor_start(void);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @warning
|
|
|
|
* @b EXPERIMENTAL: this API may change without prior notice
|
|
|
|
*
|
|
|
|
* Stop the device event monitoring.
|
|
|
|
*
|
|
|
|
* @return
|
|
|
|
* - On success, zero.
|
|
|
|
* - On failure, a negative value.
|
|
|
|
*/
|
2019-06-29 13:58:53 +02:00
|
|
|
__rte_experimental
|
|
|
|
int
|
2018-04-13 16:30:38 +08:00
|
|
|
rte_dev_event_monitor_stop(void);
|
|
|
|
|
2018-10-15 19:27:26 +08:00
|
|
|
/**
|
|
|
|
* @warning
|
|
|
|
* @b EXPERIMENTAL: this API may change without prior notice
|
|
|
|
*
|
|
|
|
* Enable hotplug handling for devices.
|
|
|
|
*
|
|
|
|
* @return
|
|
|
|
* - On success, zero.
|
|
|
|
* - On failure, a negative value.
|
|
|
|
*/
|
2019-06-29 13:58:53 +02:00
|
|
|
__rte_experimental
|
|
|
|
int
|
2018-10-15 19:27:26 +08:00
|
|
|
rte_dev_hotplug_handle_enable(void);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @warning
|
|
|
|
* @b EXPERIMENTAL: this API may change without prior notice
|
|
|
|
*
|
|
|
|
* Disable hotplug handling for devices.
|
|
|
|
*
|
|
|
|
* @return
|
|
|
|
* - On success, zero.
|
|
|
|
* - On failure, a negative value.
|
|
|
|
*/
|
2019-06-29 13:58:53 +02:00
|
|
|
__rte_experimental
|
|
|
|
int
|
2018-10-15 19:27:26 +08:00
|
|
|
rte_dev_hotplug_handle_disable(void);
|
|
|
|
|
bus: introduce device level DMA memory mapping
The DPDK APIs expose 3 different modes to work with memory used for DMA:
1. Use the DPDK owned memory (backed by the DPDK provided hugepages).
This memory is allocated by the DPDK libraries, included in the DPDK
memory system (memseg lists) and automatically DMA mapped by the DPDK
layers.
2. Use memory allocated by the user and register to the DPDK memory
systems. Upon registration of memory, the DPDK layers will DMA map it
to all needed devices. After registration, allocation of this memory
will be done with rte_*malloc APIs.
3. Use memory allocated by the user and not registered to the DPDK memory
system. This is for users who wants to have tight control on this
memory (e.g. avoid the rte_malloc header).
The user should create a memory, register it through rte_extmem_register
API, and call DMA map function in order to register such memory to
the different devices.
The scope of the patch focus on #3 above.
Currently the only way to map external memory is through VFIO
(rte_vfio_dma_map). While VFIO is common, there are other vendors
which use different ways to map memory (e.g. Mellanox and NXP).
The work in this patch moves the DMA mapping to vendor agnostic APIs.
Device level DMA map and unmap APIs were added. Implementation of those
APIs was done currently only for PCI devices.
For PCI bus devices, the pci driver can expose its own map and unmap
functions to be used for the mapping. In case the driver doesn't provide
any, the memory will be mapped, if possible, to IOMMU through VFIO APIs.
Application usage with those APIs is quite simple:
* allocate memory
* call rte_extmem_register on the memory chunk.
* take a device, and query its rte_device.
* call the device specific mapping function for this device.
Future work will deprecate the rte_vfio_dma_map and rte_vfio_dma_unmap
APIs, leaving the rte device APIs as the preferred option for the user.
Signed-off-by: Shahaf Shuler <shahafs@mellanox.com>
Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Gaetan Rivet <gaetan.rivet@6wind.com>
2019-03-10 10:28:00 +02:00
|
|
|
/**
|
|
|
|
* Device level DMA map function.
|
|
|
|
* After a successful call, the memory segment will be mapped to the
|
|
|
|
* given device.
|
|
|
|
*
|
|
|
|
* @note: Memory must be registered in advance using rte_extmem_* APIs.
|
|
|
|
*
|
|
|
|
* @param dev
|
|
|
|
* Device pointer.
|
|
|
|
* @param addr
|
|
|
|
* Virtual address to map.
|
|
|
|
* @param iova
|
|
|
|
* IOVA address to map.
|
|
|
|
* @param len
|
|
|
|
* Length of the memory segment being mapped.
|
|
|
|
*
|
|
|
|
* @return
|
|
|
|
* 0 if mapping was successful.
|
|
|
|
* Negative value and rte_errno is set otherwise.
|
|
|
|
*/
|
2019-06-29 13:58:53 +02:00
|
|
|
__rte_experimental
|
|
|
|
int
|
bus: introduce device level DMA memory mapping
The DPDK APIs expose 3 different modes to work with memory used for DMA:
1. Use the DPDK owned memory (backed by the DPDK provided hugepages).
This memory is allocated by the DPDK libraries, included in the DPDK
memory system (memseg lists) and automatically DMA mapped by the DPDK
layers.
2. Use memory allocated by the user and register to the DPDK memory
systems. Upon registration of memory, the DPDK layers will DMA map it
to all needed devices. After registration, allocation of this memory
will be done with rte_*malloc APIs.
3. Use memory allocated by the user and not registered to the DPDK memory
system. This is for users who wants to have tight control on this
memory (e.g. avoid the rte_malloc header).
The user should create a memory, register it through rte_extmem_register
API, and call DMA map function in order to register such memory to
the different devices.
The scope of the patch focus on #3 above.
Currently the only way to map external memory is through VFIO
(rte_vfio_dma_map). While VFIO is common, there are other vendors
which use different ways to map memory (e.g. Mellanox and NXP).
The work in this patch moves the DMA mapping to vendor agnostic APIs.
Device level DMA map and unmap APIs were added. Implementation of those
APIs was done currently only for PCI devices.
For PCI bus devices, the pci driver can expose its own map and unmap
functions to be used for the mapping. In case the driver doesn't provide
any, the memory will be mapped, if possible, to IOMMU through VFIO APIs.
Application usage with those APIs is quite simple:
* allocate memory
* call rte_extmem_register on the memory chunk.
* take a device, and query its rte_device.
* call the device specific mapping function for this device.
Future work will deprecate the rte_vfio_dma_map and rte_vfio_dma_unmap
APIs, leaving the rte device APIs as the preferred option for the user.
Signed-off-by: Shahaf Shuler <shahafs@mellanox.com>
Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Gaetan Rivet <gaetan.rivet@6wind.com>
2019-03-10 10:28:00 +02:00
|
|
|
rte_dev_dma_map(struct rte_device *dev, void *addr, uint64_t iova, size_t len);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Device level DMA unmap function.
|
|
|
|
* After a successful call, the memory segment will no longer be
|
|
|
|
* accessible by the given device.
|
|
|
|
*
|
|
|
|
* @note: Memory must be registered in advance using rte_extmem_* APIs.
|
|
|
|
*
|
|
|
|
* @param dev
|
|
|
|
* Device pointer.
|
|
|
|
* @param addr
|
|
|
|
* Virtual address to unmap.
|
|
|
|
* @param iova
|
|
|
|
* IOVA address to unmap.
|
|
|
|
* @param len
|
|
|
|
* Length of the memory segment being mapped.
|
|
|
|
*
|
|
|
|
* @return
|
|
|
|
* 0 if un-mapping was successful.
|
|
|
|
* Negative value and rte_errno is set otherwise.
|
|
|
|
*/
|
2019-06-29 13:58:53 +02:00
|
|
|
__rte_experimental
|
|
|
|
int
|
bus: introduce device level DMA memory mapping
The DPDK APIs expose 3 different modes to work with memory used for DMA:
1. Use the DPDK owned memory (backed by the DPDK provided hugepages).
This memory is allocated by the DPDK libraries, included in the DPDK
memory system (memseg lists) and automatically DMA mapped by the DPDK
layers.
2. Use memory allocated by the user and register to the DPDK memory
systems. Upon registration of memory, the DPDK layers will DMA map it
to all needed devices. After registration, allocation of this memory
will be done with rte_*malloc APIs.
3. Use memory allocated by the user and not registered to the DPDK memory
system. This is for users who wants to have tight control on this
memory (e.g. avoid the rte_malloc header).
The user should create a memory, register it through rte_extmem_register
API, and call DMA map function in order to register such memory to
the different devices.
The scope of the patch focus on #3 above.
Currently the only way to map external memory is through VFIO
(rte_vfio_dma_map). While VFIO is common, there are other vendors
which use different ways to map memory (e.g. Mellanox and NXP).
The work in this patch moves the DMA mapping to vendor agnostic APIs.
Device level DMA map and unmap APIs were added. Implementation of those
APIs was done currently only for PCI devices.
For PCI bus devices, the pci driver can expose its own map and unmap
functions to be used for the mapping. In case the driver doesn't provide
any, the memory will be mapped, if possible, to IOMMU through VFIO APIs.
Application usage with those APIs is quite simple:
* allocate memory
* call rte_extmem_register on the memory chunk.
* take a device, and query its rte_device.
* call the device specific mapping function for this device.
Future work will deprecate the rte_vfio_dma_map and rte_vfio_dma_unmap
APIs, leaving the rte device APIs as the preferred option for the user.
Signed-off-by: Shahaf Shuler <shahafs@mellanox.com>
Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Gaetan Rivet <gaetan.rivet@6wind.com>
2019-03-10 10:28:00 +02:00
|
|
|
rte_dev_dma_unmap(struct rte_device *dev, void *addr, uint64_t iova,
|
|
|
|
size_t len);
|
|
|
|
|
2017-11-07 06:54:21 +00:00
|
|
|
#endif /* _RTE_DEV_H_ */
|