rte_regexdev.h(3)

📦
version 25.11.3 · 10 versions
, in ubuntu resolute, ubuntu stonking

okay bestie, sit down, hydrate, because this is rte_regexdev.h — that's the regex device library, and yes it's in section 3 of the Library Functions Manual. it's giving "hardware does regex for you and it goes brrr" and honestly? iconic. this is part 1 of a long one, so we're doing the NAME and the whole SYNOPSIS, no skips 💖

🎀 NAME 🎀

rte_regexdev.h

✨ SYNOPSIS ✨

first things first, bestie — you gotta pull in the headers. all of them. no skipping, the compiler will literally end you:

#include <rte_compat.h>
#include <rte_common.h>
#include <rte_dev.h>
#include <rte_mbuf.h>
#include 'rte_regexdev_core.h'

(yeah that last one is in single quotes in the source, don't @ me, I'm just the messenger 🫶)

🌈 Data Structures 🌈

the lil cast of characters you'll be passing around:

  • struct rte_regexdev_info
  • struct rte_regexdev_config
  • struct rte_regexdev_qp_conf
  • struct rte_regexdev_rule
  • struct rte_regexdev_xstats_map
  • struct rte_regexdev_match
  • struct rte_regex_ops

💅 Macros 💅

okay so this is the big one. grab a snack. these are all the flags, and the vibes are immaculate but the list is LONG. going in order, fr fr:

the capability flags — what your device can allegedly do:

  • RTE_REGEXDEV_CAPA_RUNTIME_COMPILATION_F — (1ULL << 0)
  • RTE_REGEXDEV_CAPA_SUPP_PCRE_START_ANCHOR_F — (1ULL << 1)
  • RTE_REGEXDEV_CAPA_SUPP_PCRE_ATOMIC_GROUPING_F — (1ULL << 2)
  • RTE_REGEXDEV_SUPP_PCRE_BACKTRACKING_CTRL_F — (1ULL << 3)
  • RTE_REGEXDEV_SUPP_PCRE_CALLOUTS_F — (1ULL << 4)
  • RTE_REGEXDEV_SUPP_PCRE_BACKREFERENCE_F — (1ULL << 5)
  • RTE_REGEXDEV_SUPP_PCRE_GREEDY_F — (1ULL << 6)
  • RTE_REGEXDEV_SUPP_PCRE_MATCH_ALL_F — (1ULL << 7)
  • RTE_REGEXDEV_SUPP_PCRE_LOOKAROUND_ASRT_F — (1ULL << 8)
  • RTE_REGEXDEV_SUPP_PCRE_MATCH_POINT_RST_F — (1ULL << 9)
  • RTE_REGEXDEV_SUPP_NEWLINE_CONVENTIONS_F — (1ULL << 10)
  • RTE_REGEXDEV_SUPP_PCRE_NEWLINE_SEQ_F — (1ULL << 11)
  • RTE_REGEXDEV_SUPP_PCRE_POSSESSIVE_QUALIFIERS_F — (1ULL << 12)
  • RTE_REGEXDEV_SUPP_PCRE_SUBROUTINE_REFERENCES_F — (1ULL << 13)
  • RTE_REGEXDEV_SUPP_PCRE_UTF_8_F — (1ULL << 14)
  • RTE_REGEXDEV_SUPP_PCRE_UTF_16_F — (1ULL << 15)
  • RTE_REGEXDEV_SUPP_PCRE_UTF_32_F — (1ULL << 16)
  • RTE_REGEXDEV_SUPP_PCRE_WORD_BOUNDARY_F — (1ULL << 17)
  • RTE_REGEXDEV_SUPP_PCRE_FORWARD_REFERENCES_F — (1ULL << 18)
  • RTE_REGEXDEV_SUPP_MATCH_AS_END_F — (1ULL << 19)
  • RTE_REGEXDEV_SUPP_CROSS_BUFFER_F — (1ULL << 20)
  • RTE_REGEXDEV_SUPP_MATCH_ALL_F — (1ULL << 21)
  • RTE_REGEXDEV_CAPA_QUEUE_PAIR_OOS_F — (1ULL << 22)

then the PCRE rule flags, for blessing your rules with extra behaviour:

  • RTE_REGEX_PCRE_RULE_ALLOW_EMPTY_F — (1ULL << 0)
  • RTE_REGEX_PCRE_RULE_ANCHORED_F — (1ULL << 1)
  • RTE_REGEX_PCRE_RULE_CASELESS_F — (1ULL << 2)
  • RTE_REGEX_PCRE_RULE_DOTALL_F — (1ULL << 3)
  • RTE_REGEX_PCRE_RULE_DUPNAMES_F — (1ULL << 4)
  • RTE_REGEX_PCRE_RULE_EXTENDED_F — (1ULL << 5)
  • RTE_REGEX_PCRE_RULE_MATCH_UNSET_BACKREF_F — (1ULL << 6)
  • RTE_REGEX_PCRE_RULE_MULTILINE_F — (1ULL << 7)
  • RTE_REGEX_PCRE_RULE_NO_AUTO_CAPTURE_F — (1ULL << 8)
  • RTE_REGEX_PCRE_RULE_UCP_F — (1ULL << 9)
  • RTE_REGEX_PCRE_RULE_UNGREEDY_F — (1ULL << 10)
  • RTE_REGEX_PCRE_RULE_UTF_F — (1ULL << 11)
  • RTE_REGEX_PCRE_RULE_NEVER_BACKSLASH_C_F — (1ULL << 12)

config flags, for ✨setting things up your way✨:

  • RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F — (1ULL << 0)
  • RTE_REGEXDEV_CFG_MATCH_AS_END_F — (1ULL << 1)
  • RTE_REGEXDEV_CFG_MATCH_ALL_F — (1ULL << 2)

queue pair config flag, the solo icon:

  • RTE_REGEX_QUEUE_PAIR_CFG_OOS_F — (1ULL << 0)

the xstats name size, for when names need a lil room to breathe:

  • RTE_REGEXDEV_XSTATS_NAME_SIZE — 64

ops request flags (everything you're ASKING for):

  • RTE_REGEX_OPS_REQ_GROUP_ID0_VALID_F — (1 << 0)
  • RTE_REGEX_OPS_REQ_GROUP_ID1_VALID_F — (1 << 1)
  • RTE_REGEX_OPS_REQ_GROUP_ID2_VALID_F — (1 << 2)
  • RTE_REGEX_OPS_REQ_GROUP_ID3_VALID_F — (1 << 3)
  • RTE_REGEX_OPS_REQ_STOP_ON_MATCH_F — (1 << 4)
  • RTE_REGEX_OPS_REQ_MATCH_HIGH_PRIORITY_F — (1 << 5)

and ops response flags (everything you're GETTING BACK):

  • RTE_REGEX_OPS_RSP_PMI_SOJ_F — (1 << 0)
  • RTE_REGEX_OPS_RSP_PMI_EOJ_F — (1 << 1)
  • RTE_REGEX_OPS_RSP_MAX_SCAN_TIMEOUT_F — (1 << 2)
  • RTE_REGEX_OPS_RSP_MAX_MATCH_F — (1 << 3)
  • RTE_REGEX_OPS_RSP_MAX_PREFIX_F — (1 << 4)
  • RTE_REGEX_OPS_RSP_RESOURCE_LIMIT_REACHED_F — (1 << 4)
⚠️ observant bestie check: yes, RTE_REGEX_OPS_RSP_MAX_PREFIX_F and RTE_REGEX_OPS_RSP_RESOURCE_LIMIT_REACHED_F both got handed (1 << 4). that is literally what the page says. not my business. not my problem. I don't make the macros, I just report them 💀

🧚 Typedefs 🧚

one single typedef and it's a callback, naturally:

typedef void(* regexdev_stop_flush_t) (uint8_t dev_id, uint16_t qp_id,
    struct rte_regex_ops *op)

🦋 Enumerations 🦋

two enums, both giving very "pick an attribute, pick an operation" energy:

enum rte_regexdev_attr_id { RTE_REGEXDEV_ATTR_SOCKET_ID,
    RTE_REGEXDEV_ATTR_MAX_MATCHES, RTE_REGEXDEV_ATTR_MAX_SCAN_TIMEOUT,
    RTE_REGEXDEV_ATTR_MAX_PREFIX }
enum rte_regexdev_rule_op { RTE_REGEX_RULE_OP_ADD,
    RTE_REGEX_RULE_OP_REMOVE }

👑 Functions 👑

and now the functions, in all their __rte_experimental glory — every single one, no cuts:

  • __rte_experimental int rte_regexdev_is_valid_dev (uint16_t dev_id)
  • __rte_experimental uint8_t rte_regexdev_count (void)
  • __rte_experimental int rte_regexdev_get_dev_id (const char *name)
  • __rte_experimental int rte_regexdev_info_get (uint8_t dev_id, struct rte_regexdev_info *dev_info)
  • __rte_experimental int rte_regexdev_configure (uint8_t dev_id, const struct rte_regexdev_config *cfg)
  • __rte_experimental int rte_regexdev_queue_pair_setup (uint8_t dev_id, uint16_t queue_pair_id, const struct rte_regexdev_qp_conf *qp_conf)
  • __rte_experimental int rte_regexdev_start (uint8_t dev_id)
  • __rte_experimental int rte_regexdev_stop (uint8_t dev_id)
  • __rte_experimental int rte_regexdev_close (uint8_t dev_id)
  • __rte_experimental int rte_regexdev_attr_get (uint8_t dev_id, enum rte_regexdev_attr_id attr_id, void *attr_value)
  • __rte_experimental int rte_regexdev_attr_set (uint8_t dev_id, enum rte_regexdev_attr_id attr_id, const void *attr_value)
  • __rte_experimental int rte_regexdev_rule_db_update (uint8_t dev_id, const struct rte_regexdev_rule *rules, uint32_t nb_rules)
  • __rte_experimental int rte_regexdev_rule_db_compile_activate (uint8_t dev_id)
  • __rte_experimental int rte_regexdev_rule_db_import (uint8_t dev_id, const char *rule_db, uint32_t rule_db_len)
  • __rte_experimental int rte_regexdev_rule_db_export (uint8_t dev_id, char *rule_db)
  • __rte_experimental int rte_regexdev_xstats_names_get (uint8_t dev_id, struct rte_regexdev_xstats_map *xstats_map)
  • __rte_experimental int rte_regexdev_xstats_get (uint8_t dev_id, const uint16_t *ids, uint64_t *values, uint16_t nb_values)
  • __rte_experimental int rte_regexdev_xstats_by_name_get (uint8_t dev_id, const char *name, uint16_t *id, uint64_t *value)
  • __rte_experimental int rte_regexdev_xstats_reset (uint8_t dev_id, const uint16_t *ids, uint16_t nb_ids)
  • __rte_experimental int rte_regexdev_selftest (uint8_t dev_id)
  • __rte_experimental int rte_regexdev_dump (uint8_t dev_id, FILE *f)
  • static __rte_experimental uint16_t rte_regexdev_enqueue_burst (uint8_t dev_id, uint16_t qp_id, struct rte_regex_ops **ops, uint16_t nb_ops)
  • static __rte_experimental uint16_t rte_regexdev_dequeue_burst (uint8_t dev_id, uint16_t qp_id, struct rte_regex_ops **ops, uint16_t nb_ops)

okay and that is literally just the synopsis, bestie — the actual tea (description, all the options, all the lore) is coming next, and there's a LOT of it, so stay hydrated 🌸

💖 Detailed Description 💖

✨ RTE RegEx Device API ✨

okay bestie so this is the whole RTE RegEx Device API — it defines the APIs for RegEx operations and the provisioning that goes with them. Two whole parts, no cap:

  • The application-oriented RegEx API — all the functions to set up a RegEx device (configure it, set up its queue pairs, start it), update the rule database, and literally everything else. 🛠️
  • The driver-oriented RegEx API — one function that lets a RegEx Poll Mode Driver (PMD) register itself as a RegEx device driver. So it's matching itself with itself, iconic behavior. 💅

Here's the whole RegEx device components-and-definitions situation, and yes I am showing you the diagram because it eats:

+-----------------+
|                 |
|                 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()
+-----------------+

Now the glossary bestie, because there are words here and you need to know them:

RegEx: a regular expression is a cute, concise, flexible way to match strings of text — specific characters, words, or patterns of characters. Everyone shortens it to “RegEx”. 🎀

RegEx device: a hardware or software implementation of the RegEx device API for PCRE-based pattern matching syntax and semantics. Software girlies and hardware girlies both welcome. 🫶

PCRE RegEx syntax and semantics specification: http://regexkit.sourceforge.net/Documentation/pcre/pcrepattern.html

RegEx queue pair: every RegEx device should have one or more queue pairs, so it can transmit a burst of pattern matching requests and receive a burst of pattern matching responses. All of that request/response goodness is embedded in the rte_regex_ops structure. 🌸

Rule: a pattern matching rule expressed in PCRE RegEx syntax, plus a Match ID and a Group ID so the app can identify the rule when it matches. 👑

Rule database: the RegEx device takes your regular expressions and converts them into a compiled rule database, which it can then use to scan data. Compilation lets the device analyze the given pattern(s) and pre-determine how to scan for them in an optimized way that would be way too expensive to compute at run-time. A rule database holds a set of rules compiled into device-specific binary form. ✨

Match ID or Rule ID: a unique identifier you hand over at rule creation time so your app can identify the rule upon a match. 🦋

Group ID: rules can be grouped under one group ID to enable rule isolation and effective pattern matching. Also a unique group identifier, also provided at rule creation time, also so the app can identify the rule upon match. 💜

Scan: a pattern matching request sent through the enqueue API. That's it, that's the whole thing.

Real talk though: a given RegEx device might not support all the PCRE features, and it is entirely possible. Your app can probe for unsupported features through struct rte_regexdev_info::pcre_unsup_flags. 🔍

By default, every function of the RegEx Device API exported by a PMD is a lock-free function, and they all assume they are not being invoked in parallel on different logical cores working on the same target object. For instance, the dequeue function of a PMD cannot be invoked in parallel on two logical cores to operate on the same RegEx queue pair. Obviously though, it can be invoked in parallel by different logical cores on different queue pairs. Enforcing this rule? That's on the upper level application, bestie. Sort your own life. 😌

Not me calling out concurrency bugs in the description but go off 💀

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 is resetting the hardware or software RegEx driver implementations. That's it.

If the device init operation is successful, the correspondence between the device identifier assigned to the new device and its associated rte_regexdev structure gets effectively registered. If it's not successful, both the rte_regexdev structure and the device identifier are freed. No leftovers, we love a clean exit. 🧚

The functions exported by the application RegEx API to set up a device designated by its device identifier must be invoked in this exact order, no shuffling:

  1. rte_regexdev_configure()
  2. rte_regexdev_queue_pair_setup()
  3. rte_regexdev_start()

Then, the application can invoke, in any order, the functions exported by the RegEx API to enqueue a pattern matching job, dequeue a pattern matching response, get the stats, update the rule database, get/set device attributes, and so on. Free-for-all era. 🔥

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. Do not do it. I'm looking at you. 👀

Finally, an application can close a RegEx device by invoking the rte_regexdev_close() function. Bye bestie 💖

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. Keep up, we're going in circles but it's a cute circle. 🔄

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. Indirect girlypop behavior.

For performance reasons, the address of the fast-path functions of the RegEx driver is not contained in the regexdev_ops structure. Instead, they're directly stored at the beginning of the rte_regexdev structure, to avoid an extra indirect memory access during their invocation. We skip the middleman, we save the cache miss. ⚡

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. Polling nation rise up 🌈

The enqueue operation submits a burst of RegEx pattern matching requests to the RegEx device, and the dequeue operation gets a burst of pattern matching responses for the ones submitted through enqueue. Delulu? No. Just a burst-based relationship. 😭

A typical application utilisation of the RegEx device API will follow this programming flow, and this is the part you screenshot:

  • rte_regexdev_configure()
  • rte_regexdev_queue_pair_setup()
  • rte_regexdev_rule_db_update() — needs to be invoked if a precompiled rule database is not provided in rte_regexdev_config::rule_db for rte_regexdev_configure() and/or the application needs to update the rule database.
  • rte_regexdev_rule_db_compile_activate() — needs to be invoked if the rte_regexdev_rule_db_update function was used.
  • Create or reuse an existing mempool for rte_regex_ops objects.
  • rte_regexdev_start()
  • rte_regexdev_enqueue_burst()
  • rte_regexdev_dequeue_burst()

Definition in file rte_regexdev.h. 📄

🌟 Macro Definition Documentation 🌟

💫 #define RTE_REGEXDEV_CAPA_RUNTIME_COMPILATION_F (1ULL << 0)

So this flag means the RegEx device does support compiling the rules at runtime — unlike just loading only the pre-built rule database using struct rte_regexdev_config::rule_db in rte_regexdev_configure(). Runtime compilation girlies we see you 💅

See also

  • struct rte_regexdev_config::rule_db, rte_regexdev_configure()
  • struct rte_regexdev_info::regexdev_capa

Definition at line 273 of file rte_regexdev.h.

💫 #define RTE_REGEXDEV_CAPA_SUPP_PCRE_START_ANCHOR_F (1ULL << 1)

This one means the RegEx device supports the PCRE Anchor to start of match flag. Example RegEx is /\Gfoo\d/. Here \G asserts the position at the end of the previous match, or the start of the string for the first match. That position changes every single time the RegEx is applied to the subject string, with the drama of it all. So if the RegEx is applied to foo1foo2Zfoo3, the first two matches will be successful for foo1foo2 and fail for Zfoo3. Slay for the first two, embarrassing for the third 💀

See also

  • struct rte_regexdev_info::regexdev_capa

Definition at line 282 of file rte_regexdev.h.

💫 #define RTE_REGEXDEV_CAPA_SUPP_PCRE_ATOMIC_GROUPING_F (1ULL << 2)

The RegEx device supports PCRE Atomic grouping. Atomic groups are represented by (?>). An atomic group is a group that, when the RegEx engine exits from it, automatically throws away all backtracking positions remembered by any tokens inside the group. It simply refuses to look back. Example RegEx is a(?>bc|b)c — if the given patterns are abc and abcc, then a(bc|b)c matches both, whereas a(?>bc|b)c matches only abcc, because atomic groups don't allow backtracking back to b. Petty and efficient, we stan. ✨

See also

  • struct rte_regexdev_info::regexdev_capa

Definition at line 293 of file rte_regexdev.h.

💫 #define RTE_REGEXDEV_SUPP_PCRE_BACKTRACKING_CTRL_F (1ULL << 3)

The RegEx device supports PCRE backtracking control verbs. Some examples of backtracking verbs are (*COMMIT), (*ACCEPT), (*FAIL), (*SKIP), (*PRUNE). Verbs! For your regex! Grammar coming for us 🌸

See also

  • struct rte_regexdev_info::regexdev_capa

Definition at line 305 of file rte_regexdev.h.

RTE_REGEXDEV_SUPP_PCRE_CALLOUTS_F

#define RTE_REGEXDEV_SUPP_PCRE_CALLOUTS_F   (1ULL << 4)

bestie, this bit means the RegEx device supports PCRE callouts 💖. PCRE lets you call an external function in between matches by using (?C). Example: RegEx ABC(?C)D — if a given pattern is ABCD, then the RegEx engine will parse ABC, perform a user-defined callout, and return a successful match at D. literally pausing mid-match to go do a side quest ✨

See also

  • struct rte_regexdev_info::regexdev_capa

Definition at line 313 of file rte_regexdev.h.

RTE_REGEXDEV_SUPP_PCRE_BACKREFERENCE_F

#define RTE_REGEXDEV_SUPP_PCRE_BACKREFERENCE_F   (1ULL << 5)

RegEx device supports PCRE backreference 🎀. Example RegEx is (\2ABC|(GHI))+\2, which matches the same text as most recently matched by the 2nd capturing group, i.e. GHI. it's giving "hey remember what you just said? yeah say it again" 💅

See also

  • struct rte_regexdev_info::regexdev_capa

Definition at line 323 of file rte_regexdev.h.

RTE_REGEXDEV_SUPP_PCRE_GREEDY_F

#define RTE_REGEXDEV_SUPP_PCRE_GREEDY_F   (1ULL << 6)

RegEx device supports PCRE Greedy mode 🫶. For example, if the RegEx is AB\d*? then *? represents zero or unlimited matches. In greedy mode the pattern AB12345 will be matched completely, whereas the ungreedy mode AB will be returned as the match. greedy mode said "no crumbs left" 😤

See also

  • struct rte_regexdev_info::regexdev_capa

Definition at line 331 of file rte_regexdev.h.

RTE_REGEXDEV_SUPP_PCRE_MATCH_ALL_F

#define RTE_REGEXDEV_SUPP_PCRE_MATCH_ALL_F   (1ULL << 7)

RegEx device supports match all mode 🌈. For example, if the RegEx is AB\d*? then *? represents zero or unlimited matches. In match all mode, the pattern AB12345 will return 6 matches: AB, AB1, AB12, AB123, AB1234, AB12345. not just one match bestie, she's collecting them all like Pokémon 💀

See also

  • struct rte_regexdev_info::regexdev_capa

Definition at line 340 of file rte_regexdev.h.

RTE_REGEXDEV_SUPP_PCRE_LOOKAROUND_ASRT_F

#define RTE_REGEXDEV_SUPP_PCRE_LOOKAROUND_ASRT_F   (1ULL << 8)

RegEx device supports PCRE Lookaround assertions (Zero-width assertions) 👀. Example RegEx is [a-z]+\d+(?=!{3,}) — if the given pattern is dwad1234! the RegEx engine doesn't report any matches because the assert (?=!{3,}) fails. The pattern dwad123!!! would return a successful match. so it's checking over its shoulder before committing, iconic behavior ✨

See also

  • struct rte_regexdev_info::regexdev_capa

Definition at line 349 of file rte_regexdev.h.

RTE_REGEXDEV_SUPP_PCRE_MATCH_POINT_RST_F

#define RTE_REGEXDEV_SUPP_PCRE_MATCH_POINT_RST_F   (1ULL << 9)

RegEx device doesn't support the PCRE match point reset directive 🙈. Example RegEx is [a-z]+\K\d+ — if the pattern is dwad123 then even though the entire pattern matches, only 123 is reported as a match. yeah she said "forget everything before this point, we're starting fresh" 💅

See also

  • struct rte_regexdev_info::regexdev_capa

Definition at line 359 of file rte_regexdev.h.

RTE_REGEXDEV_SUPP_NEWLINE_CONVENTIONS_F

#define RTE_REGEXDEV_SUPP_NEWLINE_CONVENTIONS_F   (1ULL << 10)

RegEx supports PCRE newline convention 🌸. Newline conventions are represented as follows:

  • (*CR) carriage return
  • (*LF) linefeed
  • (*CRLF) carriage return, followed by linefeed
  • (*ANYCRLF) any of the three above
  • (*ANY) all Unicode newline sequences

See also

  • struct rte_regexdev_info::regexdev_capa

Definition at line 368 of file rte_regexdev.h.

RTE_REGEXDEV_SUPP_PCRE_NEWLINE_SEQ_F

#define RTE_REGEXDEV_SUPP_PCRE_NEWLINE_SEQ_F   (1ULL << 11)

RegEx device supports PCRE newline sequence 🦋. The escape sequence \R will match any newline sequence. It is equivalent to: (?>\r\n|\n|\x0b|\f|\r|\x85).

See also

  • struct rte_regexdev_info::regexdev_capa

Definition at line 380 of file rte_regexdev.h.

RTE_REGEXDEV_SUPP_PCRE_POSSESSIVE_QUALIFIERS_F

#define RTE_REGEXDEV_SUPP_PCRE_POSSESSIVE_QUALIFIERS_F   (1ULL << 12)

RegEx device supports PCRE possessive qualifiers 👑. Example RegEx possessive qualifiers: *+, ++, ?+, {m,n}+. A possessive quantifier repeats the token as many times as possible and it does not give up matches as the engine backtracks. With a possessive quantifier, the deal is all or nothing 😤 no takebacks, periodt.

See also

  • struct rte_regexdev_info::regexdev_capa

Definition at line 388 of file rte_regexdev.h.

RTE_REGEXDEV_SUPP_PCRE_SUBROUTINE_REFERENCES_F

#define RTE_REGEXDEV_SUPP_PCRE_SUBROUTINE_REFERENCES_F   (1ULL << 13)

RegEx device supports PCRE Subroutine references 🎀. PCRE Subroutine references allow for sub patterns to be assessed as part of the RegEx. Example RegEx is (foo|fuzz)\g<1>+bar, which matches the pattern foofoofuzzfoofuzzbar. it's giving "run that back, but as part of the main thing" ✨

See also

  • struct rte_regexdev_info::regexdev_capa

Definition at line 398 of file rte_regexdev.h.

RTE_REGEXDEV_SUPP_PCRE_UTF_8_F

#define RTE_REGEXDEV_SUPP_PCRE_UTF_8_F   (1ULL << 14)

RegEx device supports UTF-8 character encoding 💜. eight whole bits of vibes, slay.

See also

  • struct rte_regexdev_info::pcre_unsup_flags

Definition at line 407 of file rte_regexdev.h.

RTE_REGEXDEV_SUPP_PCRE_UTF_16_F

#define RTE_REGEXDEV_SUPP_PCRE_UTF_16_F   (1ULL << 15)

RegEx device supports UTF-16 character encoding 💜. yes bestie they doubled it, main character energy.

See also

  • struct rte_regexdev_info::regexdev_capa

Definition at line 413 of file rte_regexdev.h.

RTE_REGEXDEV_SUPP_PCRE_UTF_32_F

#define RTE_REGEXDEV_SUPP_PCRE_UTF_32_F   (1ULL << 16)

RegEx device supports UTF-32 character encoding 💜. quadruple the bits, quadruple the drama.

See also

  • struct rte_regexdev_info::regexdev_capa

Definition at line 419 of file rte_regexdev.h.

RTE_REGEXDEV_SUPP_PCRE_WORD_BOUNDARY_F

#define RTE_REGEXDEV_SUPP_PCRE_WORD_BOUNDARY_F   (1ULL << 17)

RegEx device supports word boundaries 🌸. The meta character \b represents the word boundary anchor. tell the word where it starts and where it ends, we love a firm boundary 🫶

See also

  • struct rte_regexdev_info::regexdev_capa

Definition at line 425 of file rte_regexdev.h.

RTE_REGEXDEV_SUPP_PCRE_FORWARD_REFERENCES_F

#define RTE_REGEXDEV_SUPP_PCRE_FORWARD_REFERENCES_F   (1ULL << 18)

RegEx device supports Forward references 🔥. Forward references allow you to use a back reference to a group that appears later in the RegEx. Example RegEx is (\3ABC|(DEF|(GHI)))+, which matches the following string GHIGHIABCDEF. referencing something that hasn't even shown up yet? that's manifesting, bestie ✨

See also

  • struct rte_regexdev_info::regexdev_capa

Definition at line 432 of file rte_regexdev.h.

RTE_REGEXDEV_SUPP_MATCH_AS_END_F

#define RTE_REGEXDEV_SUPP_MATCH_AS_END_F   (1ULL << 19)

RegEx device supports match as end 🎀. Match as end means that the match result holds the end offset of the detected match. No len value is set. If the device doesn't support this feature, it means the match result holds the starting position of the match and the length of the match. so basically: end-only girlies vs. start-plus-length girlies, no in between 💅

See also

  • struct rte_regexdev_info::regexdev_capa

Definition at line 441 of file rte_regexdev.h.

RTE_REGEXDEV_SUPP_CROSS_BUFFER_F

#define RTE_REGEXDEV_SUPP_CROSS_BUFFER_F   (1ULL << 20)

RegEx device supports cross buffer match 🌈. Cross buffer matching means that the match can be detected even if the string was started in a previous buffer. In case the device is configured as RTE_REGEXDEV_CFG_MATCH_AS_END, the end offset will be relative for the first packet. For example, RegEx is ABC, the first buffer is xxxx, the second buffer is yyyA, and the last buffer is BCzz. In case the match as end is configured, the end offset will be 10. she's finishing the sentence someone else started, and she's keeping receipts across all three buffers 💀

See also

  • RTE_REGEXDEV_CFG_MATCH_AS_END_F
  • RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F
  • RTE_REGEX_OPS_RSP_PMI_SOJ_F
  • RTE_REGEX_OPS_RSP_PMI_EOJ_F

Definition at line 451 of file rte_regexdev.h.

RTE_REGEXDEV_SUPP_MATCH_ALL_F

#define RTE_REGEXDEV_SUPP_MATCH_ALL_F   (1ULL << 21)

RegEx device supports match all ⭐. Match all means that the RegEx engine will return all possible matches. For example, assume the RegEx is A+b, given the input AAAb the returned matches will be: Ab, AAb and AAAb. every possible interpretation gets a moment in the spotlight, as she deserves 👑

See also

  • RTE_REGEXDEV_CFG_MATCH_ALL_F

Definition at line 467 of file rte_regexdev.h.

RTE_REGEXDEV_CAPA_QUEUE_PAIR_OOS_F

#define RTE_REGEXDEV_CAPA_QUEUE_PAIR_OOS_F   (1ULL << 22)

RegEx device supports out of order scan 💅. Out of order scan means the response of a specific job can be returned as soon as it is ready, even if previous jobs on the same queue didn't complete. no waiting in line bestie, she answers when she's ready and honestly? respect 🫶

See also

  • RTE_REGEX_QUEUE_PAIR_CFG_OOS_F
  • struct rte_regexdev_info::regexdev_capa

Definition at line 476 of file rte_regexdev.h.

RTE_REGEX_PCRE_RULE_ALLOW_EMPTY_F

#define RTE_REGEX_PCRE_RULE_ALLOW_EMPTY_F   (1ULL << 0)

When this flag is set, the pattern that can match against an empty string — such as .* — are allowed 🎀. yes you may match absolutely nothing, and honestly sometimes that's the mood.

See also

  • struct rte_regexdev_info::rule_flags
  • struct rte_regexdev_rule::rule_flags

Definition at line 486 of file rte_regexdev.h.

RTE_REGEX_PCRE_RULE_ANCHORED_F

#define RTE_REGEX_PCRE_RULE_ANCHORED_F   (1ULL << 1)

When this flag is set, the pattern is forced to be "anchored" — that is, it is constrained to match only at the first matching point in the string that is being searched. Similar to ^ and represented by \A. she said "we start HERE, nowhere else" 😤

See also

  • struct rte_regexdev_info::rule_flags
  • struct rte_regexdev_rule::rule_flags

Definition at line 494 of file rte_regexdev.h.

RTE_REGEX_PCRE_RULE_CASELESS_F

#define RTE_REGEX_PCRE_RULE_CASELESS_F   (1ULL << 2)

When this flag is set, letters in the pattern match both upper and lower case letters in the subject 🌸. caps lock erasure, we love to see it.

See also

  • struct rte_regexdev_info::rule_flags
  • struct rte_regexdev_rule::rule_flags

Definition at line 503 of file rte_regexdev.h.

RTE_REGEX_PCRE_RULE_DOTALL_F

#define RTE_REGEX_PCRE_RULE_DOTALL_F   (1ULL << 3)

When this flag is set, a dot metacharacter in the pattern matches any character, including one that indicates a newline 🦋. the . said "i don't see lines, i see possibilities" ✨

See also

  • struct rte_regexdev_info::rule_flags
  • struct rte_regexdev_rule::rule_flags

Definition at line 511 of file rte_regexdev.h.

RTE_REGEX_PCRE_RULE_DUPNAMES_F

#define RTE_REGEX_PCRE_RULE_DUPNAMES_F   (1ULL << 4)

When this flag is set, the names used to identify capture groups need not be unique 👯. two groups can share a name and honestly that's just collaboration.

See also

  • struct rte_regexdev_info::rule_flags
  • struct rte_regexdev_rule::rule_flags

Definition at line 519 of file rte_regexdev.h.

RTE_REGEX_PCRE_RULE_EXTENDED_F

#define RTE_REGEX_PCRE_RULE_EXTENDED_F   (1ULL << 5)

When this flag is set, most white space characters in the pattern are totally ignored — except when escaped or inside a character class 💅. finally, a flag that lets the pattern breathe.

See also

  • struct rte_regexdev_info::rule_flags
  • struct rte_regexdev_rule::rule_flags

Definition at line 527 of file rte_regexdev.h.

RTE_REGEX_PCRE_RULE_MATCH_UNSET_BACKREF_F

#define RTE_REGEX_PCRE_RULE_MATCH_UNSET_BACKREF_F   (1ULL << 6)

When this flag is set, a backreference to an unset capture group matches an empty string 🫶. nothing there? cool, we'll match the nothing, no drama.

See also

  • struct rte_regexdev_info::rule_flags
  • struct rte_regexdev_rule::rule_flags

Definition at line 535 of file rte_regexdev.h.

RTE_REGEX_PCRE_RULE_MULTILINE_F

#define RTE_REGEX_PCRE_RULE_MULTILINE_F   (1ULL << 7)

When this flag is set, the ^ and $ constructs match immediately following or immediately before internal newlines in the subject string, respectively, as well as at the very start and end 🌈. every line is a main character now, not just the first and last.

See also

  • struct rte_regexdev_info::rule_flags
  • struct rte_regexdev_rule::rule_flags

Definition at line 543 of file rte_regexdev.h.

RTE_REGEX_PCRE_RULE_NO_AUTO_CAPTURE_F

#define RTE_REGEX_PCRE_RULE_NO_AUTO_CAPTURE_F   (1ULL << 8)

When this Flag is set, it disables the use of numbered capturing parentheses in the pattern 💀. References to capture groups (backreferences or recursion/subroutine calls) may only refer to named groups, though the reference can be by name or by number. so: name your groups or they simply do not exist, bestie.

See also

  • struct rte_regexdev_info::rule_flags
  • struct rte_regexdev_rule::rule_flags

Definition at line 552 of file rte_regexdev.h.

RTE_REGEX_PCRE_RULE_UCP_F

#define RTE_REGEX_PCRE_RULE_UCP_F   (1ULL << 9)

By default, only ASCII characters are recognized. When this flag is set, Unicode properties are used instead to classify characters 🌍✨. ASCII said "i'm the default" and Unicode said "hold my boba".

See also

  • struct rte_regexdev_info::rule_flags
  • struct rte_regexdev_rule::rule_flags

Definition at line 562 of file rte_regexdev.h.

💅 RTE_REGEX_PCRE_RULE_UNGREEDY_F

Value: (1ULL << 10). Set this flag and the whole "greediness" of your quantifiers gets flipped — they are not greedy by default anymore, and they only become greedy when they're followed by a ?. Iconic behaviour honestly.

See also

  • struct rte_regexdev_info::rule_flags
  • struct rte_regexdev_rule::rule_flags

Definition at line 570 of file rte_regexdev.h.

🦋 RTE_REGEX_PCRE_RULE_UTF_F

Value: (1ULL << 11). With this flag set, the RegEx engine has to treat both the pattern and the subject strings that get processed afterwards as strings of UTF characters instead of single-code-unit strings. hello unicode bestie 💜

See also

  • struct rte_regexdev_info::rule_flags
  • struct rte_regexdev_rule::rule_flags

Definition at line 579 of file rte_regexdev.h.

🚫 RTE_REGEX_PCRE_RULE_NEVER_BACKSLASH_C_F

Value: (1ULL << 12). This flag locks out the use of \C in the pattern that's being compiled. Why would you do that? Because that escape matches one data unit, even in UTF mode, and that can cause unpredictable behavior in UTF-8 or UTF-16 modes — it may leave the current matching point in the mi:set hlsearchddle of a multi-code-unit character 💀 so yeah, this flag said "not on my watch".

See also

  • struct rte_regexdev_info::rule_flags
  • struct rte_regexdev_rule::rule_flags

Definition at line 588 of file rte_regexdev.h.

🌈 RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F

Value: (1ULL << 0). Okay so cross buffer scan is the ability to detect matches that happen across buffer boundaries, when those buffers are related to each other in some way. Turn this flag on when you need to scan a payload size greater than struct rte_regexdev_info::max_payload_size, and/or when matches can show up across scan buffer boundaries. It's giving "one match, two buffers" energy ✨

See also

  • struct rte_regexdev_info::max_payload_size
  • struct rte_regexdev_config::dev_cfg_flags, rte_regexdev_configure()
  • RTE_REGEX_OPS_RSP_PMI_SOJ_F
  • RTE_REGEX_OPS_RSP_PMI_EOJ_F

Definition at line 649 of file rte_regexdev.h.

🎯 RTE_REGEXDEV_CFG_MATCH_AS_END_F

Value: (1ULL << 1). Match as end means the device can hand you the result as an ending offset. Set this flag and every match result will carry the ending offset of the match in end_offset. Leave it unset and the match result holds the starting offset in start_offset plus the length of the match in len. Pick your fighter, bestie.

See also

  • RTE_REGEXDEV_SUPP_MATCH_AS_END_F

Definition at line 662 of file rte_regexdev.h.

👑 RTE_REGEXDEV_CFG_MATCH_ALL_F

Value: (1ULL << 2). Match all is exactly what it sounds like: the ability to return all possible results. No crumbs left behind, we eating the whole plate 🍓

See also

  • RTE_REGEXDEV_SUPP_MATCH_ALL_F

Definition at line 672 of file rte_regexdev.h.

🔀 RTE_REGEX_QUEUE_PAIR_CFG_OOS_F

Value: (1ULL << 0). Out of order scan, a.k.a. living your life unbothered. If this flag is not set, a scan must retire only after previously issued in-order scans to this queue pair have retired. If it is set, the scan can retire the moment the device returns completion. Heads up though: if you actually need to maintain the ingress order of scan requests, do not set this out of order scan flag. Rules are rules.

See also

  • struct rte_regexdev_qp_conf::qp_conf_flags
  • rte_regexdev_queue_pair_setup()

Definition at line 748 of file rte_regexdev.h.

📏 RTE_REGEXDEV_XSTATS_NAME_SIZE

Value: 64. That's the maximum name length for extended statistics counters. Keep your stat names cute but concise 💅

Definition at line 1086 of file rte_regexdev.h.

🌸 RTE_REGEX_OPS_REQ_GROUP_ID0_VALID_F

Value: (1 << 0). Set when struct rte_regexdev_rule::group_id0 is valid.

Definition at line 1273 of file rte_regexdev.h.

🌸 RTE_REGEX_OPS_REQ_GROUP_ID1_VALID_F

Value: (1 << 1). Set when struct rte_regexdev_rule::group_id1 is valid.

Definition at line 1276 of file rte_regexdev.h.

🌸 RTE_REGEX_OPS_REQ_GROUP_ID2_VALID_F

Value: (1 << 2). Set when struct rte_regexdev_rule::group_id2 is valid.

Definition at line 1279 of file rte_regexdev.h.

🌸 RTE_REGEX_OPS_REQ_GROUP_ID3_VALID_F

Value: (1 << 3). Set when struct rte_regexdev_rule::group_id3 is valid.

Definition at line 1282 of file rte_regexdev.h.

✋ RTE_REGEX_OPS_REQ_STOP_ON_MATCH_F

Value: (1 << 4). The RegEx engine will stop scanning and return the first match. First one in, no further questions, we're done here 🔥

Definition at line 1285 of file rte_regexdev.h.

⭐ RTE_REGEX_OPS_REQ_MATCH_HIGH_PRIORITY_F

Value: (1 << 5). In High Priority mode, a maximum of one match will be returned per scan, which cuts down the post-processing your application has to do. Which match wins? The one with the lowest Rule id, then the lowest start pointer, then the lowest match length. main character selection process, honestly 👑

See also

  • struct rte_regex_ops::nb_actual_matches
  • struct rte_regex_ops::nb_matches

Definition at line 1288 of file rte_regexdev.h.

🫧 RTE_REGEX_OPS_RSP_PMI_SOJ_F

Value: (1 << 0). Indicates that the RegEx device has hit a partial match at the start of scan in the given buffer.

See also

  • RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F

Definition at line 1300 of file rte_regexdev.h.

🫧 RTE_REGEX_OPS_RSP_PMI_EOJ_F

Value: (1 << 1). Indicates that the RegEx device has hit a partial match at the end of scan in the given buffer.

See also

  • RTE_REGEXDEV_CFG_CROSS_BUFFER_SCAN_F

Definition at line 1307 of file rte_regexdev.h.

⏰ RTE_REGEX_OPS_RSP_MAX_SCAN_TIMEOUT_F

Value: (1 << 2). Indicates that the RegEx device exceeded the max timeout while scanning the given buffer. It really said "I'm tired your honor" 😭

See also

  • RTE_REGEXDEV_ATTR_MAX_SCAN_TIMEOUT

Definition at line 1314 of file rte_regexdev.h.

🧮 RTE_REGEX_OPS_RSP_MAX_MATCH_F

Value: (1 << 3). Indicates that the RegEx device exceeded the max matches while scanning the given buffer. Too many matches, not enough slots.

See also

  • RTE_REGEXDEV_ATTR_MAX_MATCHES

Definition at line 1321 of file rte_regexdev.h.

🎀 RTE_REGEX_OPS_RSP_MAX_PREFIX_F

Value: (1 << 4). Indicates that the RegEx device reached the max allowed prefix length while scanning the given buffer.

See also

  • RTE_REGEXDEV_ATTR_MAX_PREFIX

Definition at line 1328 of file rte_regexdev.h.

🚨 RTE_REGEX_OPS_RSP_RESOURCE_LIMIT_REACHED_F

Value: (1 << 4). Indicates that the RegEx device reached the max allowed resource allowed while scanning the given buffer.

Definition at line 1335 of file rte_regexdev.h.

🫶 Typedef Documentation

regexdev_stop_flush_t

typedef void(* regexdev_stop_flush_t) (uint8_t dev_id, uint16_t qp_id, struct rte_regex_ops *op)

It's a callback function called during rte_regexdev_stop(), and it gets invoked once per flushed RegEx op. One call, one op, every time 🧚

Definition at line 759 of file rte_regexdev.h.

🔮 Enumeration Type Documentation

enum rte_regexdev_attr_id

Enumerates RegEx device attribute identifier ✨

Enumerator

  • RTE_REGEXDEV_ATTR_SOCKET_ID — The NUMA socket id to which the device is connected, or a default of zero if the socket could not be determined. datatype: int operation: get
  • RTE_REGEXDEV_ATTR_MAX_MATCHES — Maximum number of matches per scan. datatype: uint8_t operation: get and set

See also

  • RTE_REGEX_OPS_RSP_MAX_MATCH_F
  • RTE_REGEXDEV_ATTR_MAX_SCAN_TIMEOUT — Upper bound scan time in ns. datatype: uint16_t operation: get and set

See also

  • RTE_REGEX_OPS_RSP_MAX_SCAN_TIMEOUT_F
  • RTE_REGEXDEV_ATTR_MAX_PREFIX — Maximum number of prefix detected per scan. This would be useful for denial of service detection. datatype: uint16_t operation: get and set

See also

  • RTE_REGEX_OPS_RSP_MAX_PREFIX_F

Definition at line 868 of file rte_regexdev.h.

enum rte_regexdev_rule_op

Enumerates RegEx rule operation.

Enumerator

  • RTE_REGEX_RULE_OP_ADD — Add RegEx rule to rule database. ➕
  • RTE_REGEX_RULE_OP_REMOVE — Remove RegEx rule from rule database. ➖

Definition at line 946 of file rte_regexdev.h.

✨ Function Documentation

rte_regexdev_is_valid_dev()

__rte_experimental int rte_regexdev_is_valid_dev (uint16_t dev_id)
⚠️ Warning: EXPERIMENTAL: this API may change without prior notice.

Check if dev_id is ready. Vibe check, but for a device 🫧

Parameters

  • dev_id — The dev identifier of the RegEx device.

Returns

  • 0 if device state is not in ready state.
  • 1 if device state is ready state.

rte_regexdev_count()

__rte_experimental uint8_t rte_regexdev_count (void )
⚠️ Warning: EXPERIMENTAL: this API may change without prior notice.

Get the total number of RegEx devices that have been successfully initialised. Roll call, everybody who made it 📣

Returns The total number of usable RegEx devices.

rte_regexdev_get_dev_id()

__rte_experimental int rte_regexdev_get_dev_id (const char * name)
⚠️ Warning: EXPERIMENTAL: this API may change without prior notice.

Get the device identifier for the named RegEx device.

Parameters

  • name — RegEx device name to select the RegEx device identifier.

Returns Returns RegEx device identifier on success.

  • <0: Failure to find named RegEx device.

rte_regexdev_info_get()

__rte_experimental int rte_regexdev_info_get (uint8_t dev_id, struct rte_regexdev_info * dev_info)
⚠️ Warning: EXPERIMENTAL: this API may change without prior notice.

Retrieve the contextual information of a RegEx device. It's giving "tell me everything about yourself" 💅

Parameters

  • dev_id — The identifier of the device.
  • dev_info — A pointer to a structure of type rte_regexdev_info to be filled with the contextual information of the device.

Returns

  • 0: Success, driver updates the contextual information of the RegEx device
  • <0: Error code returned by the driver info get function.

rte_regexdev_configure()

__rte_experimental int rte_regexdev_configure (uint8_t dev_id, const struct rte_regexdev_config * cfg)
⚠️ Warning: EXPERIMENTAL: this API may change without prior notice.

Configure a RegEx device. Slay ✨

📌 This function must be invoked first, before any other function in the API. It can also be re-invoked when a device is in the stopped state.

The caller may use rte_regexdev_info_get() to get the capability of each resources available for this regex device.

Parameters

  • dev_id — The identifier of the device to configure.
  • cfg — The RegEx device configuration structure.

Returns

  • 0: Success, device configured. Otherwise negative errno is returned.

rte_regexdev_queue_pair_setup()

__rte_experimental int rte_regexdev_queue_pair_setup (uint8_t dev_id, uint16_t queue_pair_id, const struct rte_regexdev_qp_conf * qp_conf)
⚠️ Warning: EXPERIMENTAL: this API may change without prior notice.

Allocate and set up a RegEx queue pair for a RegEx device. Matchmaking, but make it infrastructure 🎀

Parameters

  • dev_id — The identifier of the device.
  • queue_pair_id — The index of the RegEx queue pair to setup. The value must be in the range [0, nb_queue_pairs - 1] previously supplied to rte_regexdev_configure().
  • qp_conf — The pointer to the configuration data to be used for the RegEx queue pair. NULL value is allowed, in which case default configuration used.

Returns 0 on success. Otherwise negative errno is returned.

rte_regexdev_start()

__rte_experimental int rte_regexdev_start (uint8_t dev_id)
⚠️ Warning: EXPERIMENTAL: this API may change without prior notice.

Start a RegEx device.

The device start step is the last one and consists of setting the RegEx queues to start accepting the pattern matching scan requests. 💅

Once that lands, all the basic functions the API exports (RegEx enqueue, RegEx dequeue and so on) can be invoked. basically the whole playground unlocks 🎉

Parameters

  • dev_id — RegEx device identifier.

Returns 0 on success. Otherwise negative errno is returned.

__rte_experimental int rte_regexdev_stop (uint8_t dev_id)

⚠️ Warning EXPERIMENTAL: this API may change without prior notice. 💀

Stop a RegEx device.

Stop a RegEx device. bestie, it can be restarted later with a call to rte_regexdev_start(). so it's a nap, not a funeral 🛌

This function causes all queued response regex ops to be drained in the response queue. While draining ops out of the device, struct rte_regexdev_qp_conf::cb will be invoked for each ops.

Parameters

  • dev_id — RegEx device identifier.

Returns 0 on success. Otherwise negative errno is returned.

__rte_experimental int rte_regexdev_close (uint8_t dev_id)

⚠️ Warning EXPERIMENTAL: this API may change without prior notice. 💀

Close a RegEx device. The device cannot be restarted! like, it's over over. no coming back from this one 😭

Parameters

  • dev_id — RegEx device identifier

Returns 0 on success. Otherwise negative errno is returned.

__rte_experimental int rte_regexdev_attr_get (uint8_t dev_id, enum rte_regexdev_attr_id attr_id, void * attr_value)

⚠️ Warning EXPERIMENTAL: this API may change without prior notice. 💀

Get an attribute from a RegEx device.

Parameters

  • dev_id — RegEx device identifier.
  • attr_id — The attribute ID to retrieve.
  • attr_value — A pointer that will be filled in with the attribute value if successful.

Returns

  • 0: Successfully retrieved attribute value.
  • -EINVAL: Invalid device or attr_id provided, or attr_value is NULL.
  • -ENOTSUP: if the device doesn't support specific attr_id.

__rte_experimental int rte_regexdev_attr_set (uint8_t dev_id, enum rte_regexdev_attr_id attr_id, const void * attr_value)

⚠️ Warning EXPERIMENTAL: this API may change without prior notice. 💀

Set an attribute to a RegEx device.

Parameters

  • dev_id — RegEx device identifier.
  • attr_id — The attribute ID to retrieve.
  • attr_value — Pointer that will be filled in with the attribute value by the application.

Returns

  • 0: Successfully applied the attribute value.
  • -EINVAL: Invalid device or attr_id provided, or attr_value is NULL.
  • -ENOTSUP: if the device doesn't support specific attr_id.

__rte_experimental int rte_regexdev_rule_db_update (uint8_t dev_id, const struct rte_regexdev_rule * rules, uint32_t nb_rules)

⚠️ Warning EXPERIMENTAL: this API may change without prior notice. 💀

Update the local rule set. 🛠️ heads up tho: this function only modifies the rule set in memory. For the changes to actually take effect, the function rte_regexdev_rule_db_compile_active must be called. so it's giving "edited the doc but didn't hit save" energy until you do that ✨

Parameters

  • dev_id — RegEx device identifier.
  • rules — Points to an array of nb_rules objects of type rte_regexdev_rule structure which contain the regex rules attributes to be updated in rule database.
  • nb_rules — The number of PCRE rules to update the rule database.

Returns The number of regex rules actually updated on the regex device's rule database. The return value can be less than the value of the nb_rules parameter when the regex devices fails to update the rule database or if invalid parameters are specified in a rte_regexdev_rule. If the return value is less than nb_rules, the remaining PCRE rules at the end of rules are not consumed and the caller has to take care of them and rte_errno is set accordingly. Possible errno values include:

  • -EINVAL: Invalid device ID or rules is NULL
  • -ENOTSUP: The last processed rule is not supported on this device.
  • -ENOSPC: No space available in rule database.

See also rte_regexdev_rule_db_import(), rte_regexdev_rule_db_export(), rte_regexdev_rule_db_compile_activate()

__rte_experimental int rte_regexdev_rule_db_compile_activate (uint8_t dev_id)

⚠️ Warning EXPERIMENTAL: this API may change without prior notice. 💀

Compile local rule set and burn the complied result to the RegEx device. 🔥 that's the "hit save" step, babe.

Parameters

  • dev_id — RegEx device identifier.

Returns 0 on success, otherwise negative errno.

See also rte_regexdev_rule_db_import(), rte_regexdev_rule_db_export(), rte_regexdev_rule_db_update()

__rte_experimental int rte_regexdev_rule_db_import (uint8_t dev_id, const char * rule_db, uint32_t rule_db_len)

⚠️ Warning EXPERIMENTAL: this API may change without prior notice. 💀

Import a prebuilt rule database from a buffer to a RegEx device. 📥 plug it straight in, no assembling required.

Parameters

  • dev_id — RegEx device identifier.
  • rule_db — Points to prebuilt rule database.
  • rule_db_len — Length of the rule database.

Returns

  • 0: Successfully updated the prebuilt rule database.
  • -EINVAL: Invalid device ID or rule_db is NULL
  • -ENOTSUP: Rule database import is not supported on this device.
  • -ENOSPC: No space available in rule database.

See also rte_regexdev_rule_db_update(), rte_regexdev_rule_db_export()

__rte_experimental int rte_regexdev_rule_db_export (uint8_t dev_id, char * rule_db)

⚠️ Warning EXPERIMENTAL: this API may change without prior notice. 💀

Export the prebuilt rule database from a RegEx device to the buffer. 📤 taking it out of the device's hands and into yours.

Parameters

  • dev_id — RegEx device identifier.
  • rule_db — Block of memory to insert the rule database. Must be at least size in capacity. If set to NULL, function returns required capacity.

Returns

  • 0: Successfully exported the prebuilt rule database.
  • size: If rule_db set to NULL then required capacity for rule_db
  • -EINVAL: Invalid device ID
  • -ENOTSUP: Rule database export is not supported on this device.

See also rte_regexdev_rule_db_update(), rte_regexdev_rule_db_import()

__rte_experimental int rte_regexdev_xstats_names_get (uint8_t dev_id, struct rte_regexdev_xstats_map * xstats_map)

⚠️ Warning EXPERIMENTAL: this API may change without prior notice. 💀

Retrieve names of extended statistics of a regex device. 📊 gotta know what you're even looking at, iykyk.

Parameters

  • dev_id — The identifier of the regex device.
  • xstats_map — Block of memory to insert id and names into. Must be at least size in capacity. If set to NULL, function returns required capacity.

Returns

  • Positive value on success: -The return value is the number of entries filled in the stats map. -If xstats_map set to NULL then required capacity for xstats_map.
  • Negative value on error: -ENODEV for invalid dev_id -ENOTSUP if the device doesn't support this function.

__rte_experimental int rte_regexdev_xstats_get (uint8_t dev_id, const uint16_t * ids, uint64_t * values, uint16_t nb_values)

⚠️ Warning EXPERIMENTAL: this API may change without prior notice. 💀

Retrieve extended statistics of an regex device. 📈 the numbers, bestie, gimme the numbers.

Parameters

  • dev_id — The identifier of the device.
  • ids — The id numbers of the stats to get. The ids can be got from the stat position in the stat list from rte_regexdev_xstats_names_get(), or by using rte_regexdev_xstats_by_name_get().
  • values — The values for each stats request by ID.
  • nb_values — The number of stats requested.

Returns

  • Positive value: number of stat entries filled into the values array
  • Negative value on error: -ENODEV for invalid dev_id -ENOTSUP if the device doesn't support this function.

__rte_experimental int rte_regexdev_xstats_by_name_get (uint8_t dev_id, const char * name, uint16_t * id, uint64_t * value)

⚠️ Warning EXPERIMENTAL: this API may change without prior notice. 💀

Retrieve the value of a single stat by requesting it by name. 🔎 just say the name and it shall appear.

Parameters

  • dev_id — The identifier of the device.
  • name — The stat name to retrieve.
  • id — If non-NULL, the numerical id of the stat will be returned, so that further requests for the stat can be got using rte_regexdev_xstats_get, which will be faster as it doesn't need to scan a list of names for the stat.
  • value — Must be non-NULL, retrieved xstat value will be stored in this address.

Returns

  • 0: Successfully retrieved xstat value.
  • -EINVAL: invalid parameters
  • -ENOTSUP: if not supported.

__rte_experimental int rte_regexdev_xstats_reset (uint8_t dev_id, const uint16_t * ids, uint16_t nb_ids)

⚠️ Warning EXPERIMENTAL: this API may change without prior notice. 💀

Reset the values of the xstats of the selected component in the device. 🧼 clean slate, we love to see it.

Parameters

  • dev_id — The identifier of the device.
  • ids — Selects specific statistics to be reset. When NULL, all statistics will be reset. If non-NULL, must point to array of at least nb_ids size.
  • nb_ids — The number of ids available from the ids array. Ignored when ids is NULL.

Returns

  • 0: Successfully reset the statistics to zero.
  • -EINVAL: invalid parameters.
  • -ENOTSUP: if not supported.

__rte_experimental int rte_regexdev_selftest (uint8_t dev_id)

⚠️ Warning EXPERIMENTAL: this API may change without prior notice. 💀

Trigger the RegEx device self test. 🧪 the device checks itself before it wrecks itself.

Parameters

  • dev_id — The identifier of the device.

Returns

  • 0: Selftest successful.
  • -ENOTSUP if the device doesn't support selftest.
  • other values < 0 on failure.

__rte_experimental int rte_regexdev_dump (uint8_t dev_id, FILE * f)

⚠️ Warning EXPERIMENTAL: this API may change without prior notice. 💀

Dump internal information about dev_id to the FILE* provided in f. 🗑️ spilling all the internal tea, respectfully.

Parameters

  • dev_id — The identifier of the device.
  • f — A pointer to a file for output.

Returns 0 on success, negative errno on failure.

__rte_experimental uint16_t rte_regexdev_enqueue_burst (uint8_t dev_id, uint16_t qp_id, struct rte_regex_ops ** ops, uint16_t nb_ops) [inline], [static]

⚠️ Warning EXPERIMENTAL: this API may change without prior notice. 💀

Enqueue a burst of scan request on a RegEx device. 🚀 sending the whole squad at once.

The rte_regexdev_enqueue_burst() function is invoked to place regex operations on the queue qp_id of the device designated by its dev_id.

The nb_ops parameter is the number of operations to process which are supplied in the ops array of rte_regexdev_op structures.

The rte_regexdev_enqueue_burst() function returns the number of operations it actually enqueued for processing. A return value equal to nb_ops means that all packets have been enqueued. ✨

Parameters

okay so for this burst-enqueue function, the parameters are giving structured, bestie:

  • dev_id — the identifier of the device 💅
  • qp_id — the index of the queue pair which packets are to be enqueued for processing. The value must be in the range [0, nb_queue_pairs - 1] previously supplied to rte_regexdev_configure().
  • ops — the address of an array of nb_ops pointers to rte_regexdev_op structures which contain the regex operations to be processed.
  • nb_ops — the number of operations to process.

Returns

The number of operations actually enqueued on the regex device. The return value can be less than the value of the nb_ops parameter when the regex devices queue is full or if invalid parameters are specified in a rte_regexdev_op. If the return value is less than nb_ops, the remaining ops at the end of ops are not consumed and the caller has to take care of them. like, you gotta handle your own leftovers, no cap.

Definition at line 1470 of file rte_regexdev.h.

✨ rte_regexdev_dequeue_burst ✨

next up, the dequeue bestie, and she's experimental so don't get too attached 😭

Warning — EXPERIMENTAL: this API may change without prior notice.
__rte_experimental uint16_t rte_regexdev_dequeue_burst (uint8_t dev_id,
    uint16_t qp_id, struct rte_regex_ops ** ops, uint16_t nb_ops) [inline],
    [static]

Dequeue a burst of scan response from a queue on the RegEx device. The dequeued operations are stored in rte_regexdev_op structures whose pointers are supplied in the ops array. obsessed with this retrieval moment.

The rte_regexdev_dequeue_burst() function returns the number of ops actually dequeued, which is the number of rte_regexdev_op data structures effectively supplied into the ops array.

A return value equal to nb_ops indicates that the queue contained at least nb_ops operations, and this is likely to signify that other processed operations remain in the devices output queue. Applications implementing a "retrieve as many processed operations as possible" policy can check this specific case and keep invoking the rte_regexdev_dequeue_burst() function until a value less than nb_ops is returned. the way that queue keeps giving… keep calling till she taps out, periodt.

The rte_regexdev_dequeue_burst() function does not provide any error notification to avoid the corresponding overhead. no error notes, just vibes and speed.

Parameters

  • dev_id — The RegEx device identifier
  • qp_id — The index of the queue pair from which to retrieve processed packets. The value must be in the range [0, nb_queue_pairs - 1] previously supplied to rte_regexdev_configure().
  • ops — The address of an array of pointers to rte_regexdev_op structures that must be large enough to store nb_ops pointers in it.
  • nb_ops — The maximum number of operations to dequeue.

Returns

The number of operations actually dequeued, which is the number of pointers to rte_regexdev_op structures effectively supplied to the ops array. If the return value is less than nb_ops, the remaining ops at the end of ops are not consumed and the caller has to take care of them.

Definition at line 1530 of file rte_regexdev.h.

🎀 AUTHOR 🎀

Generated automatically by Doxygen for DPDK from the source code. iconic autogeneration behavior.

and that's a wrap, bestie! this page is DPDK Version 25.11.3, rte_regexdev.h(3), with Doxygen's date stamp — autogenerated, slay, no cap. 💅✨

📦 where this page comes from