quoted

4) app/test/test_regexdev.c like app/test/test_eventdev.c

We started to create a super basic app, after the API will be finalized and we will have HW
we can push it. (if you need it faster than feel free)

A simple Unit test case needs to be present for the APIs. On the
course of developing common code,
it can be developed to test the common code with dummy/skeleton driver.

quoted

5) Need a maintainer for maintaining the regex subsystem

We wish to maintain it if you agree.

Yes. Please.

quoted

quoted

One more thing, regarding the ops structure, I think it is better to split it to 2

different

quoted

structures one enque and one for dequeue, since there are no real shared

data and we will

quoted

be able to save memory, what do you think?

Ops are allocated from mempool so it will be overhead to manage both.
moreover, some
of the fields added in req can be used for resp as info. cryptodev
follows the similar concept,
I think, we can have symmetry with cryptodev wherever is possible to avoid
end-user to learn new API models.

True that there will be overhead with 2 mempools (small one)
but lets assume 255 results. This means that the buffer should be 255 * sizeof(rte_regex_match) = 2K
also this will enable us to replace groupX with group[] which will allow even more groups.
In addition don't think that crypto is a good example.
The main difference is that in RegEx the output is different format then the input.

# IMO, Some of the fields may be useful for a response as well. I
think application may be interested in following
req filed in the response.
a) buf_addr
b) scan_size
c) user_id (This would be main one)

# Having two mempools adds overhead per lcore L1 cache usage and extra
complexity to the application.

# IMO, From a performance perspective, one mempool is good due to less
stress on the cache and it is costly to
add new mempool for HW mempool implementations.

# I think, group[] use case we can add it when it required by
introducing "matches_start_offset" field, which will
tell the req, where is the end of group[] and where "matches" start
with single mempool scheme also.

# I think, one of the other use case for "matches_start_offset" that,
It may possible to put vendor-specific
opaque data. It will be filled by driver on response. The application
can reference the matches as

struct rte_regex_match *matches = RTE_PTR_ADD(ops, ops->matches_start_offset);

quoted

I assume you will send the v4 with these comments. I think, with v4 we
can start implementing common library code.

Just need to agree on the split (one more iteration )
and I will start working on the common code.

Ack.