2020-05-20 15:33:43 +02:00
|
|
|
API
|
2013-04-19 12:34:40 +02:00
|
|
|
===
|
|
|
|
|
|
|
|
|
|
<!--
|
2018-04-04 16:51:06 -05:00
|
|
|
SPDX-License-Identifier: BSD-3-Clause
|
|
|
|
|
Copyright(c) 2013-2017 6WIND S.A.
|
2013-04-19 12:34:40 +02:00
|
|
|
-->
|
|
|
|
|
|
2017-07-14 16:45:25 +02:00
|
|
|
The public API headers are grouped by topics:
|
2013-04-19 12:34:40 +02:00
|
|
|
|
|
|
|
|
- **device**:
|
2015-08-11 18:09:44 +02:00
|
|
|
[dev] (@ref rte_dev.h),
|
2013-04-19 12:34:40 +02:00
|
|
|
[ethdev] (@ref rte_ethdev.h),
|
2015-08-11 18:09:44 +02:00
|
|
|
[ethctrl] (@ref rte_eth_ctrl.h),
|
2016-12-21 15:51:17 +01:00
|
|
|
[rte_flow] (@ref rte_flow.h),
|
ethdev: add traffic management API
This patch introduces the generic ethdev API for the traffic manager
capability, which includes: hierarchical scheduling, traffic shaping,
congestion management, packet marking.
Main features:
- Exposed as ethdev plugin capability (similar to rte_flow)
- Capability query API per port, per level and per node
- Scheduling algorithms: Strict Priority (SP), Weighed Fair Queuing (WFQ)
- Traffic shaping: single/dual rate, private (per node) and shared (by
multiple nodes) shapers
- Congestion management for hierarchy leaf nodes: algorithms of tail drop,
head drop, WRED; private (per node) and shared (by multiple nodes) WRED
contexts
- Packet marking: IEEE 802.1q (VLAN DEI), IETF RFC 3168 (IPv4/IPv6 ECN for
TCP and SCTP), IETF RFC 2597 (IPv4 / IPv6 DSCP)
Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Acked-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Acked-by: Balasubramanian Manoharan <balasubramanian.manoharan@caviumnetworks.com>
Acked-by: Hemant Agrawal <hemant.agrawal@nxp.com>
2017-06-12 14:35:39 +01:00
|
|
|
[rte_tm] (@ref rte_tm.h),
|
2017-10-13 13:22:16 +01:00
|
|
|
[rte_mtr] (@ref rte_mtr.h),
|
2018-01-11 19:23:18 +00:00
|
|
|
[bbdev] (@ref rte_bbdev.h),
|
2015-11-25 13:25:12 +00:00
|
|
|
[cryptodev] (@ref rte_cryptodev.h),
|
2017-10-25 20:37:23 +05:30
|
|
|
[security] (@ref rte_security.h),
|
2018-04-27 14:23:54 +01:00
|
|
|
[compressdev] (@ref rte_compressdev.h),
|
2018-04-27 14:23:56 +01:00
|
|
|
[compress] (@ref rte_comp.h),
|
regexdev: introduce API
As RegEx usage become more used by DPDK applications, for example:
* Next Generation Firewalls (NGFW)
* Deep Packet and Flow Inspection (DPI)
* Intrusion Prevention Systems (IPS)
* DDoS Mitigation
* Network Monitoring
* Data Loss Prevention (DLP)
* Smart NICs
* Grammar based content processing
* URL, spam and adware filtering
* Advanced auditing and policing of user/application security policies
* Financial data mining - parsing of streamed financial feeds
* Application recognition.
* Dmemory introspection.
* Natural Language Processing (NLP)
* Sentiment Analysis.
* Big data database acceleration.
* Computational storage.
Number of PMD providers started to work on HW implementation,
along side with SW implementations.
This lib adds the support for those kind of devices.
The RegEx Device API is composed of two parts:
- The application-oriented RegEx API that includes functions to setup
a RegEx device (configure it, setup its queue pairs and start it),
update the rule database and so on.
- The driver-oriented RegEx API that exports a function allowing
a RegEx poll Mode Driver (PMD) to simultaneously register itself as
a RegEx device driver.
RegEx device components and definitions:
+-----------------+
| |
| o---------+ rte_regexdev_[en|de]queue_burst()
| PCRE based o------+ | |
| RegEx pattern | | | +--------+ |
| matching engine o------+--+--o | | +------+
| | | | | queue |<==o===>|Core 0|
| o----+ | | | pair 0 | | |
| | | | | +--------+ +------+
+-----------------+ | | |
^ | | | +--------+
| | | | | | +------+
| | +--+--o queue |<======>|Core 1|
Rule|Database | | | pair 1 | | |
+------+----------+ | | +--------+ +------+
| Group 0 | | |
| +-------------+ | | | +--------+ +------+
| | Rules 0..n | | | | | | |Core 2|
| +-------------+ | | +--o queue |<======>| |
| Group 1 | | | pair 2 | +------+
| +-------------+ | | +--------+
| | Rules 0..n | | |
| +-------------+ | | +--------+
| Group 2 | | | | +------+
| +-------------+ | | | queue |<======>|Core n|
| | Rules 0..n | | +-------o pair n | | |
| +-------------+ | +--------+ +------+
| Group n |
| +-------------+ |<-------rte_regexdev_rule_db_update()
| | | |<-------rte_regexdev_rule_db_compile_activate()
| | Rules 0..n | |<-------rte_regexdev_rule_db_import()
| +-------------+ |------->rte_regexdev_rule_db_export()
+-----------------+
RegEx: A regular expression is a concise and flexible means for matching
strings of text, such as particular characters, words, or patterns of
characters. A common abbreviation for this is â~@~\RegExâ~@~].
RegEx device: A hardware or software-based implementation of RegEx
device API for PCRE based pattern matching syntax and semantics.
PCRE RegEx syntax and semantics specification:
http://regexkit.sourceforge.net/Documentation/pcre/pcrepattern.html
RegEx queue pair: Each RegEx device should have one or more queue pair to
transmit a burst of pattern matching request and receive a burst of
receive the pattern matching response. The pattern matching
request/response embedded in *rte_regex_ops* structure.
Rule: A pattern matching rule expressed in PCRE RegEx syntax along with
Match ID and Group ID to identify the rule upon the match.
Rule database: The RegEx device accepts regular expressions and converts
them into a compiled rule database that can then be used to scan data.
Compilation allows the device to analyze the given pattern(s) and
pre-determine how to scan for these patterns in an optimized fashion that
would be far too expensive to compute at run-time. A rule database
contains a set of rules that compiled in device specific binary form.
Match ID or Rule ID: A unique identifier provided at the time of rule
creation for the application to identify the rule upon match.
Group ID: Group of rules can be grouped under one group ID to enable
rule isolation and effective pattern matching. A unique group identifier
provided at the time of rule creation for the application to identify
the rule upon match.
Scan: A pattern matching request through *enqueue* API.
It may possible that a given RegEx device may not support all the
features
of PCRE. The application may probe unsupported features through
struct rte_regexdev_info::pcre_unsup_flags
By default, all the functions of the RegEx Device API exported by a PMD
are lock-free functions which assume to not be invoked in parallel on
different logical cores to work on the same target object. For instance,
the dequeue function of a PMD cannot be invoked in parallel on two logical
cores to operates on same RegEx queue pair. Of course, this function
can be invoked in parallel by different logical core on different queue
pair. It is the responsibility of the upper level application to
enforce this rule.
In all functions of the RegEx API, the RegEx device is
designated by an integer >= 0 named the device identifier *dev_id*
At the RegEx driver level, RegEx devices are represented by a generic
data structure of type *rte_regexdev*.
RegEx devices are dynamically registered during the PCI/SoC device
probing phase performed at EAL initialization time.
When a RegEx device is being probed, a *rte_regexdev* structure and
a new device identifier are allocated for that device. Then, the
regexdev_init() function supplied by the RegEx driver matching the
probed device is invoked to properly initialize the device.
The role of the device init function consists of resetting the hardware
or software RegEx driver implementations.
If the device init operation is successful, the correspondence between
the device identifier assigned to the new device and its associated
*rte_regexdev* structure is effectively registered.
Otherwise, both the *rte_regexdev* structure and the device identifier
are freed.
The functions exported by the application RegEx API to setup a device
designated by its device identifier must be invoked in the following
order:
- rte_regexdev_configure()
- rte_regexdev_queue_pair_setup()
- rte_regexdev_start()
Then, the application can invoke, in any order, the functions
exported by the RegEx API to enqueue pattern matching job, dequeue
pattern matching response, get the stats, update the rule database,
get/set device attributes and so on
If the application wants to change the configuration (i.e. call
rte_regexdev_configure() or rte_regexdev_queue_pair_setup()), it must
call rte_regexdev_stop() first to stop the device and then do the
reconfiguration before calling rte_regexdev_start() again. The enqueue and
dequeue functions should not be invoked when the device is stopped.
Finally, an application can close a RegEx device by invoking the
rte_regexdev_close() function.
Each function of the application RegEx API invokes a specific function
of the PMD that controls the target device designated by its device
identifier.
For this purpose, all device-specific functions of a RegEx driver are
supplied through a set of pointers contained in a generic structure of
type *regexdev_ops*.
The address of the *regexdev_ops* structure is stored in the
*rte_regexdev* structure by the device init function of the RegEx driver,
which is invoked during the PCI/SoC device probing phase, as explained
earlier.
In other words, each function of the RegEx API simply retrieves the
*rte_regexdev* structure associated with the device identifier and
performs an indirect invocation of the corresponding driver function
supplied in the *regexdev_ops* structure of the *rte_regexdev*
structure.
For performance reasons, the address of the fast-path functions of the
RegEx driver is not contained in the *regexdev_ops* structure.
Instead, they are directly stored at the beginning of the *rte_regexdev*
structure to avoid an extra indirect memory access during their
invocation.
RTE RegEx device drivers do not use interrupts for enqueue or dequeue
operation. Instead, RegEx drivers export Poll-Mode enqueue and dequeue
functions to applications.
The *enqueue* operation submits a burst of RegEx pattern matching
request to the RegEx device and the *dequeue* operation gets a burst of
pattern matching response for the ones submitted through *enqueue*
operation.
Typical application utilisation of the RegEx device API will follow the
following programming flow.
- rte_regexdev_configure()
- rte_regexdev_queue_pair_setup()
- rte_regexdev_rule_db_update() Needs to invoke if precompiled rule
database not
provided in rte_regexdev_config::rule_db for rte_regexdev_configure()
and/or application needs to update rule database.
- rte_regexdev_rule_db_compile_activate() Needs to invoke if
rte_regexdev_rule_db_update function was used.
- Create or reuse exiting mempool for *rte_regex_ops* objects.
- rte_regexdev_start()
- rte_regexdev_enqueue_burst()
- rte_regexdev_dequeue_burst()
Signed-off-by: Jerin Jacob <jerinj@marvell.com>
Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
Signed-off-by: Ori Kam <orika@mellanox.com>
2020-07-06 17:36:46 +00:00
|
|
|
[regexdev] (@ref rte_regexdev.h),
|
2016-11-18 07:30:38 +05:30
|
|
|
[eventdev] (@ref rte_eventdev.h),
|
2017-10-11 03:51:34 +05:30
|
|
|
[event_eth_rx_adapter] (@ref rte_event_eth_rx_adapter.h),
|
2018-09-20 23:11:12 +05:30
|
|
|
[event_eth_tx_adapter] (@ref rte_event_eth_tx_adapter.h),
|
2018-04-04 16:51:06 -05:00
|
|
|
[event_timer_adapter] (@ref rte_event_timer_adapter.h),
|
2018-05-09 13:47:57 +05:30
|
|
|
[event_crypto_adapter] (@ref rte_event_crypto_adapter.h),
|
2018-01-31 14:43:18 +05:30
|
|
|
[rawdev] (@ref rte_rawdev.h),
|
2017-07-16 20:10:56 +02:00
|
|
|
[metrics] (@ref rte_metrics.h),
|
|
|
|
|
[bitrate] (@ref rte_bitrate.h),
|
|
|
|
|
[latency] (@ref rte_latencystats.h),
|
2014-04-10 16:15:28 +02:00
|
|
|
[devargs] (@ref rte_devargs.h),
|
2018-04-12 11:53:36 +05:30
|
|
|
[PCI] (@ref rte_pci.h),
|
2019-06-26 16:20:55 +01:00
|
|
|
[vdev] (@ref rte_bus_vdev.h),
|
2018-04-12 11:53:36 +05:30
|
|
|
[vfio] (@ref rte_vfio.h)
|
2017-01-30 18:27:25 +00:00
|
|
|
|
|
|
|
|
- **device specific**:
|
2017-10-10 11:18:14 +01:00
|
|
|
[softnic] (@ref rte_eth_softnic.h),
|
2014-06-25 21:07:43 +01:00
|
|
|
[bond] (@ref rte_eth_bond.h),
|
2017-04-01 15:22:57 +08:00
|
|
|
[vhost] (@ref rte_vhost.h),
|
2018-10-12 16:52:21 +08:00
|
|
|
[vdpa] (@ref rte_vdpa.h),
|
2013-04-19 12:34:40 +02:00
|
|
|
[KNI] (@ref rte_kni.h),
|
2017-01-30 18:27:25 +00:00
|
|
|
[ixgbe] (@ref rte_pmd_ixgbe.h),
|
2017-04-18 12:33:15 +01:00
|
|
|
[i40e] (@ref rte_pmd_i40e.h),
|
2019-11-08 23:44:35 +08:00
|
|
|
[ice] (@ref rte_pmd_ice.h),
|
2020-10-08 10:51:09 +01:00
|
|
|
[ioat] (@ref rte_ioat_rawdev.h),
|
2017-09-11 17:33:35 +01:00
|
|
|
[bnxt] (@ref rte_pmd_bnxt.h),
|
2018-01-10 16:16:37 +05:30
|
|
|
[dpaa] (@ref rte_pmd_dpaa.h),
|
2019-01-11 12:24:30 +00:00
|
|
|
[dpaa2] (@ref rte_pmd_dpaa2.h),
|
2018-05-04 15:41:23 +05:30
|
|
|
[dpaa2_mempool] (@ref rte_dpaa2_mempool.h),
|
2018-05-04 15:41:28 +05:30
|
|
|
[dpaa2_cmdif] (@ref rte_pmd_dpaa2_cmdif.h),
|
2018-05-03 21:36:08 +05:30
|
|
|
[dpaa2_qdma] (@ref rte_pmd_dpaa2_qdma.h),
|
2017-04-18 12:33:15 +01:00
|
|
|
[crypto_scheduler] (@ref rte_cryptodev_scheduler.h)
|
2013-04-19 12:34:40 +02:00
|
|
|
|
|
|
|
|
- **memory**:
|
|
|
|
|
[memseg] (@ref rte_memory.h),
|
|
|
|
|
[memzone] (@ref rte_memzone.h),
|
|
|
|
|
[mempool] (@ref rte_mempool.h),
|
|
|
|
|
[malloc] (@ref rte_malloc.h),
|
|
|
|
|
[memcpy] (@ref rte_memcpy.h)
|
|
|
|
|
|
|
|
|
|
- **timers**:
|
|
|
|
|
[cycles] (@ref rte_cycles.h),
|
|
|
|
|
[timer] (@ref rte_timer.h),
|
|
|
|
|
[alarm] (@ref rte_alarm.h)
|
|
|
|
|
|
|
|
|
|
- **locks**:
|
|
|
|
|
[atomic] (@ref rte_atomic.h),
|
2019-07-05 18:27:06 +08:00
|
|
|
[mcslock] (@ref rte_mcslock.h),
|
2013-04-19 12:34:40 +02:00
|
|
|
[rwlock] (@ref rte_rwlock.h),
|
2019-04-30 22:54:16 -05:00
|
|
|
[spinlock] (@ref rte_spinlock.h),
|
|
|
|
|
[ticketlock] (@ref rte_ticketlock.h),
|
|
|
|
|
[RCU] (@ref rte_rcu_qsbr.h)
|
2013-04-19 12:34:40 +02:00
|
|
|
|
|
|
|
|
- **CPU arch**:
|
|
|
|
|
[branch prediction] (@ref rte_branch_prediction.h),
|
|
|
|
|
[cache prefetch] (@ref rte_prefetch.h),
|
2016-11-16 16:20:38 +01:00
|
|
|
[SIMD] (@ref rte_vect.h),
|
2013-04-19 12:34:40 +02:00
|
|
|
[byte order] (@ref rte_byteorder.h),
|
2017-01-18 06:51:23 +05:30
|
|
|
[CPU flags] (@ref rte_cpuflags.h),
|
2017-06-05 14:28:38 +05:30
|
|
|
[CPU pause] (@ref rte_pause.h),
|
2017-01-18 06:51:23 +05:30
|
|
|
[I/O access] (@ref rte_io.h)
|
2013-04-19 12:34:40 +02:00
|
|
|
|
|
|
|
|
- **CPU multicore**:
|
|
|
|
|
[interrupts] (@ref rte_interrupts.h),
|
|
|
|
|
[launch] (@ref rte_launch.h),
|
|
|
|
|
[lcore] (@ref rte_lcore.h),
|
|
|
|
|
[per-lcore] (@ref rte_per_lcore.h),
|
2017-07-11 15:19:27 +01:00
|
|
|
[service cores] (@ref rte_service.h),
|
2017-07-16 19:57:07 +02:00
|
|
|
[keepalive] (@ref rte_keepalive.h),
|
2013-04-19 12:34:40 +02:00
|
|
|
[power/freq] (@ref rte_power.h)
|
|
|
|
|
|
|
|
|
|
- **layers**:
|
|
|
|
|
[ethernet] (@ref rte_ether.h),
|
2015-08-11 18:09:44 +02:00
|
|
|
[ARP] (@ref rte_arp.h),
|
2019-10-22 09:46:48 +05:30
|
|
|
[HIGIG] (@ref rte_higig.h),
|
2015-08-11 18:09:44 +02:00
|
|
|
[ICMP] (@ref rte_icmp.h),
|
2017-10-25 20:37:19 +05:30
|
|
|
[ESP] (@ref rte_esp.h),
|
2019-10-10 17:52:14 +01:00
|
|
|
[IPsec] (@ref rte_ipsec.h),
|
|
|
|
|
[IPsec group] (@ref rte_ipsec_group.h),
|
|
|
|
|
[IPsec SA] (@ref rte_ipsec_sa.h),
|
|
|
|
|
[IPsec SAD] (@ref rte_ipsec_sad.h),
|
2013-04-19 12:34:40 +02:00
|
|
|
[IP] (@ref rte_ip.h),
|
|
|
|
|
[SCTP] (@ref rte_sctp.h),
|
|
|
|
|
[TCP] (@ref rte_tcp.h),
|
|
|
|
|
[UDP] (@ref rte_udp.h),
|
2019-10-22 16:26:36 +00:00
|
|
|
[GTP] (@ref rte_gtp.h),
|
lib/gro: add Generic Receive Offload API framework
Generic Receive Offload (GRO) is a widely used SW-based offloading
technique to reduce per-packet processing overhead. It gains
performance by reassembling small packets into large ones. This
patchset is to support GRO in DPDK. To support GRO, this patch
implements a GRO API framework.
To enable more flexibility to applications, DPDK GRO is implemented as
a user library. Applications explicitly use the GRO library to merge
small packets into large ones. DPDK GRO provides two reassembly modes.
One is called lightweight mode, the other is called heavyweight mode.
If applications want to merge packets in a simple way and the number
of packets is relatively small, they can use the lightweight mode.
If applications need more fine-grained controls, they can choose the
heavyweight mode.
rte_gro_reassemble_burst is the main reassembly API which is used in
lightweight mode and processes N packets at a time. For applications,
performing GRO in lightweight mode is simple. They just need to invoke
rte_gro_reassemble_burst. Applications can get GROed packets as soon as
rte_gro_reassemble_burst returns.
rte_gro_reassemble is the main reassembly API which is used in
heavyweight mode and tries to merge N inputted packets with the packets
in GRO reassembly tables. For applications, performing GRO in heavyweight
mode is relatively complicated. Before performing GRO, applications need
to create a GRO context object, which keeps reassembly tables of
desired GRO types, by rte_gro_ctx_create. Then applications can use
rte_gro_reassemble to merge packets. The GROed packets are in the
reassembly tables of the GRO context object. If applications want to get
them, applications need to manually flush them by flush API.
Signed-off-by: Jiayu Hu <jiayu.hu@intel.com>
Reviewed-by: Jianfeng Tan <jianfeng.tan@intel.com>
2017-07-09 13:46:44 +08:00
|
|
|
[GRO] (@ref rte_gro.h),
|
gso: add Generic Segmentation Offload API framework
Generic Segmentation Offload (GSO) is a SW technique to split large
packets into small ones. Akin to TSO, GSO enables applications to
operate on large packets, thus reducing per-packet processing overhead.
To enable more flexibility to applications, DPDK GSO is implemented
as a standalone library. Applications explicitly use the GSO library
to segment packets. To segment a packet requires two steps. The first
is to set proper flags to mbuf->ol_flags, where the flags are the same
as that of TSO. The second is to call the segmentation API,
rte_gso_segment(). This patch introduces the GSO API framework to DPDK.
rte_gso_segment() splits an input packet into small ones in each
invocation. The GSO library refers to these small packets generated
by rte_gso_segment() as GSO segments. Each of the newly-created GSO
segments is organized as a two-segment MBUF, where the first segment is a
standard MBUF, which stores a copy of packet header, and the second is an
indirect MBUF which points to a section of data in the input packet.
rte_gso_segment() reduces the refcnt of the input packet by 1. Therefore,
when all GSO segments are freed, the input packet is freed automatically.
Additionally, since each GSO segment has multiple MBUFs (i.e. 2 MBUFs),
the driver of the interface which the GSO segments are sent to should
support to transmit multi-segment packets.
The GSO framework clears the PKT_TX_TCP_SEG flag for both the input
packet, and all produced GSO segments in the event of success, since
segmentation in hardware is no longer required at that point.
Signed-off-by: Jiayu Hu <jiayu.hu@intel.com>
Signed-off-by: Mark Kavanagh <mark.b.kavanagh@intel.com>
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
2017-10-07 22:56:39 +08:00
|
|
|
[GSO] (@ref rte_gso.h),
|
2014-05-28 18:32:36 +01:00
|
|
|
[frag/reass] (@ref rte_ip_frag.h),
|
2019-10-23 14:19:27 +01:00
|
|
|
[VXLAN] (@ref rte_vxlan.h)
|
2013-04-19 12:34:40 +02:00
|
|
|
|
|
|
|
|
- **QoS**:
|
|
|
|
|
[metering] (@ref rte_meter.h),
|
|
|
|
|
[scheduler] (@ref rte_sched.h),
|
|
|
|
|
[RED congestion] (@ref rte_red.h)
|
|
|
|
|
|
2020-07-08 19:31:27 +01:00
|
|
|
- **routing**:
|
|
|
|
|
[LPM IPv4 route] (@ref rte_lpm.h),
|
|
|
|
|
[LPM IPv6 route] (@ref rte_lpm6.h),
|
|
|
|
|
[RIB IPv4] (@ref rte_rib.h),
|
|
|
|
|
[RIB IPv6] (@ref rte_rib6.h),
|
|
|
|
|
[FIB IPv4] (@ref rte_fib.h),
|
|
|
|
|
[FIB IPv6] (@ref rte_fib6.h)
|
|
|
|
|
|
2013-04-19 12:34:40 +02:00
|
|
|
- **hashes**:
|
|
|
|
|
[hash] (@ref rte_hash.h),
|
|
|
|
|
[jhash] (@ref rte_jhash.h),
|
2015-08-11 18:09:44 +02:00
|
|
|
[thash] (@ref rte_thash.h),
|
2013-04-19 12:34:40 +02:00
|
|
|
[FBK hash] (@ref rte_fbk_hash.h),
|
2017-10-25 17:18:52 +02:00
|
|
|
[CRC hash] (@ref rte_hash_crc.h)
|
2017-10-20 12:26:30 +02:00
|
|
|
|
|
|
|
|
- **classification**
|
|
|
|
|
[reorder] (@ref rte_reorder.h),
|
|
|
|
|
[distributor] (@ref rte_distributor.h),
|
|
|
|
|
[EFD] (@ref rte_efd.h),
|
|
|
|
|
[ACL] (@ref rte_acl.h),
|
2017-10-24 18:28:00 +01:00
|
|
|
[member] (@ref rte_member.h),
|
2018-05-10 11:23:03 +01:00
|
|
|
[flow classify] (@ref rte_flow_classify.h),
|
|
|
|
|
[BPF] (@ref rte_bpf.h)
|
2013-04-19 12:34:40 +02:00
|
|
|
|
|
|
|
|
- **containers**:
|
|
|
|
|
[mbuf] (@ref rte_mbuf.h),
|
2018-01-29 13:40:45 +05:30
|
|
|
[mbuf pool ops] (@ref rte_mbuf_pool_ops.h),
|
2013-04-19 12:34:40 +02:00
|
|
|
[ring] (@ref rte_ring.h),
|
2019-04-03 18:20:13 -05:00
|
|
|
[stack] (@ref rte_stack.h),
|
2013-04-19 12:34:40 +02:00
|
|
|
[tailq] (@ref rte_tailq.h),
|
2017-10-25 17:18:52 +02:00
|
|
|
[bitmap] (@ref rte_bitmap.h)
|
2013-04-19 12:34:40 +02:00
|
|
|
|
2014-06-04 19:08:19 +01:00
|
|
|
- **packet framework**:
|
|
|
|
|
* [port] (@ref rte_port.h):
|
2014-06-04 19:08:20 +01:00
|
|
|
[ethdev] (@ref rte_port_ethdev.h),
|
2014-06-04 19:08:21 +01:00
|
|
|
[ring] (@ref rte_port_ring.h),
|
2014-06-04 19:08:22 +01:00
|
|
|
[frag] (@ref rte_port_frag.h),
|
2014-06-04 19:08:23 +01:00
|
|
|
[reass] (@ref rte_port_ras.h),
|
2014-06-04 19:08:24 +01:00
|
|
|
[sched] (@ref rte_port_sched.h),
|
2016-06-21 18:55:52 +08:00
|
|
|
[kni] (@ref rte_port_kni.h),
|
2014-06-04 19:08:25 +01:00
|
|
|
[src/sink] (@ref rte_port_source_sink.h)
|
2014-06-04 19:08:27 +01:00
|
|
|
* [table] (@ref rte_table.h):
|
2014-06-04 19:08:28 +01:00
|
|
|
[lpm IPv4] (@ref rte_table_lpm.h),
|
2014-06-04 19:08:29 +01:00
|
|
|
[lpm IPv6] (@ref rte_table_lpm_ipv6.h),
|
2014-06-04 19:08:30 +01:00
|
|
|
[ACL] (@ref rte_table_acl.h),
|
2014-06-04 19:08:31 +01:00
|
|
|
[hash] (@ref rte_table_hash.h),
|
2014-06-04 19:08:32 +01:00
|
|
|
[array] (@ref rte_table_array.h),
|
2014-06-04 19:08:33 +01:00
|
|
|
[stub] (@ref rte_table_stub.h)
|
2014-06-04 19:08:35 +01:00
|
|
|
* [pipeline] (@ref rte_pipeline.h)
|
2018-03-29 19:31:30 +01:00
|
|
|
[port_in_action] (@ref rte_port_in_action.h)
|
2018-03-29 19:31:20 +01:00
|
|
|
[table_action] (@ref rte_table_action.h)
|
2020-10-01 11:19:29 +01:00
|
|
|
* SWX pipeline:
|
2020-10-01 11:19:35 +01:00
|
|
|
[control] (@ref rte_swx_ctl.h),
|
2020-10-01 11:19:33 +01:00
|
|
|
[extern] (@ref rte_swx_extern.h),
|
2020-10-01 11:19:29 +01:00
|
|
|
[pipeline] (@ref rte_swx_pipeline.h)
|
2020-10-01 11:19:30 +01:00
|
|
|
* SWX port:
|
2020-10-01 11:20:01 +01:00
|
|
|
[port] (@ref rte_swx_port.h),
|
2020-10-01 11:20:02 +01:00
|
|
|
[ethdev] (@ref rte_swx_port_ethdev.h),
|
|
|
|
|
[src/sink] (@ref rte_swx_port_source_sink.h)
|
2020-10-01 11:19:35 +01:00
|
|
|
* SWX table:
|
2020-10-01 11:20:03 +01:00
|
|
|
[table] (@ref rte_swx_table.h),
|
|
|
|
|
[table_em] (@ref rte_swx_table_em.h)
|
2020-04-11 19:44:00 +05:30
|
|
|
* [graph] (@ref rte_graph.h):
|
2020-04-11 19:44:11 +05:30
|
|
|
[graph_worker] (@ref rte_graph_worker.h)
|
2020-04-11 19:44:17 +05:30
|
|
|
* graph_nodes:
|
|
|
|
|
[eth_node] (@ref rte_node_eth_api.h),
|
2020-04-11 19:44:18 +05:30
|
|
|
[ip4_node] (@ref rte_node_ip4_api.h)
|
2014-06-04 19:08:19 +01:00
|
|
|
|
2014-02-04 16:11:12 +01:00
|
|
|
- **basic**:
|
2020-04-27 15:58:51 +08:00
|
|
|
[bitops] (@ref rte_bitops.h),
|
2014-02-04 16:11:12 +01:00
|
|
|
[approx fraction] (@ref rte_approx.h),
|
|
|
|
|
[random] (@ref rte_random.h),
|
2015-08-11 18:09:44 +02:00
|
|
|
[config file] (@ref rte_cfgfile.h),
|
2014-02-04 16:11:12 +01:00
|
|
|
[key/value args] (@ref rte_kvargs.h),
|
2014-07-04 11:12:31 +02:00
|
|
|
[string] (@ref rte_string_fns.h)
|
2014-02-04 16:11:12 +01:00
|
|
|
|
2013-04-19 12:34:40 +02:00
|
|
|
- **debug**:
|
2015-08-11 18:09:44 +02:00
|
|
|
[jobstats] (@ref rte_jobstats.h),
|
2018-10-27 10:17:41 +01:00
|
|
|
[telemetry] (@ref rte_telemetry.h),
|
2016-12-01 11:02:10 +00:00
|
|
|
[pdump] (@ref rte_pdump.h),
|
2015-08-11 18:09:44 +02:00
|
|
|
[hexdump] (@ref rte_hexdump.h),
|
2013-04-19 12:34:40 +02:00
|
|
|
[debug] (@ref rte_debug.h),
|
|
|
|
|
[log] (@ref rte_log.h),
|
2020-04-23 00:33:19 +05:30
|
|
|
[errno] (@ref rte_errno.h),
|
|
|
|
|
[trace] (@ref rte_trace.h),
|
|
|
|
|
[trace_point] (@ref rte_trace_point.h)
|
2013-04-19 12:34:40 +02:00
|
|
|
|
|
|
|
|
- **misc**:
|
|
|
|
|
[EAL config] (@ref rte_eal.h),
|
|
|
|
|
[common] (@ref rte_common.h),
|
2019-10-07 16:45:49 +01:00
|
|
|
[experimental APIs] (@ref rte_compat.h),
|
|
|
|
|
[ABI versioning] (@ref rte_function_versioning.h),
|
2013-04-19 12:34:40 +02:00
|
|
|
[version] (@ref rte_version.h)
|
