Bug analysis of regexdev library

Since nobody uses it, thought I would test AI review of regexdev library.

It found many things, and not to mention there are no regression tests for the library. Is anyone using or maintaining this? Can it be deprecated in 26.07 and removed in 26.11?

Here's a thorough bug analysis of the DPDK regexdev library:

## Critical Bugs

**1. Wrong comparison operator in rte_regexdev_get_dev_id()** (rte_regexdev.c)

This is the most serious bug. The function uses strcmp() without negation, so it matches on names that are *different* rather than equal:

```c
if (strcmp(name, rte_regex_devices[i].data->dev_name)) {
    id = rte_regex_devices[i].data->dev_id;
    break;
}
```

strcmp() returns 0 (falsy) on match. This should be !strcmp(...) or strcmp(...) == 0, exactly as done correctly in regexdev_allocated(). As written, this returns the ID of the first device whose name *doesn't* match.

**2. Wrong memset value on re-registration** (rte_regexdev.c, rte_regexdev_register())

```c
if (dev->data == NULL)
    dev->data = &rte_regexdev_shared_data->data[dev_id];
else
    memset(dev->data, 1, sizeof(*dev->data));
```

The else branch fills the data structure with byte value 1 (0x01 repeating), not zero. This is almost certainly meant to be memset(dev->data, 0, ...). A fill value of 1 corrupts every field: dev_id becomes garbage, dev_name becomes non-NUL junk, dev_started becomes 1 (true), etc. The if branch also has a problem — newly assigned data from the shared array is never zeroed, so it relies on the one-time memset in regexdev_shared_data_prepare().

**3. rte_regexdev_stop() ignores driver return value** (rte_regexdev.c)

```c
dev->dev_ops->dev_stop(dev);
dev->data->dev_started = 0;
return 0;
```

The dev_stop callback returns int, but the return value is discarded. If the driver fails to stop, the library unconditionally marks the device as stopped and returns success. Compare with dev_start, which correctly checks the return value before updating state.

## Moderate Bugs

**4. rte_regexdev_close() doesn't check driver return** (rte_regexdev.c)

Same pattern as stop — dev_close() return is ignored, and the device is unconditionally marked UNUSED and dev_started = 0 regardless of whether the driver succeeded.

**5. Duplicate dev_started check in rte_regexdev_queue_pair_setup()** (rte_regexdev.c)

The dev->data->dev_started check appears twice, identically:

```c
if (dev->data->dev_started) {  // first check
    ...
    return -EBUSY;
}
if (queue_pair_id >= dev->data->dev_conf.nb_queue_pairs) {
    ...
}
if (dev->data->dev_started) {  // redundant duplicate
    ...
    return -EBUSY;
}
```

This is dead code — the second check is unreachable unless there's a concurrent modification, and the library explicitly states it's not thread-safe.

**6. rte_regexdev_configure() allows nb_max_matches == 0 despite doc** (rte_regexdev.h vs .c)

The header comment for rte_regexdev_config::nb_max_matches says "The value 0 is allowed, in which case, value 1 used." But the implementation explicitly rejects zero:

```c
if (cfg->nb_max_matches == 0) {
    RTE_REGEXDEV_LOG_LINE(ERR, "Dev %u num of matches must be > 0", dev_id);
    return -EINVAL;
}
```

Either the doc or the code is wrong.

**7. Similarly, nb_rules_per_group == 0 rejection contradicts doc**

The header says "The value 0 is allowed, in which case, max_rules_per_group used." But the code rejects it with -EINVAL.

## Design / Robustness Issues

**8. rte_regexdev_xstats_names_get() rejects NULL but API says NULL returns capacity**

The header states: "If set to NULL, function returns required capacity." But the implementation returns -EINVAL on NULL, making it impossible to query the required size.

**9. rte_regexdev_xstats_reset() rejects NULL ids but API says NULL resets all**

The header says: "When NULL, all statistics will be reset." The implementation returns -EINVAL on NULL.

**10. Missing #include <stdio.h> dependency** (rte_regexdev_core.h)

The regexdev_dump_t typedef uses FILE *f but the header doesn't include <stdio.h>. It works by accident through transitive includes, but it's technically a missing dependency.

**11. Type mismatch on nb_rules**

In rte_regexdev.h, rte_regexdev_rule_db_update() declares nb_rules as uint32_t. In rte_regexdev_core.h, the callback typedef regexdev_rule_db_update_t declares it as uint16_t. This silently truncates rule counts above 65535.

**12. regexdev_capa field is uint32_t but capability flags can exceed 32 bits**

Capability RTE_REGEXDEV_CAPA_QUEUE_PAIR_OOS_F is defined as (1ULL << 22) with ULL suffix suggesting 64-bit intent, yet struct rte_regexdev_info::regexdev_capa is uint32_t. Currently the highest bit is 22, so it fits, but the ULL suffix signals the original developers may have intended a 64-bit field, and any future flag at bit 32+ would be silently dropped.

---

The strcmp inversion (bug #1) and the memset(..., 1, ...) (bug #2) are the most impactful — one breaks device lookup by name entirely, the other corrupts device state on re-registration. The xstats NULL-handling mismatches (#8, #9) and the nb_rules type mismatch (#11) are likely to bite real driver consumers.