> > 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. > > > 5) Need a maintainer for maintaining the regex subsystem > > > We wish to maintain it if you agree. Yes. Please. > > > > > > One more thing, regarding the ops structure, I think it is better to > > > split it to 2 > > different > > > structures one enque and one for dequeue, since there are no real shared > > data and we will > > > 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); > > > 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.
