Re: add one example of DPI ?

[fengchengwen <fengchengwen@huawei.com>]

On 2025/4/28 23:49, Stephen Hemminger wrote:
> On Mon, 28 Apr 2025 16:20:22 +0800
> fengchengwen <fengchengwen@huawei.com> wrote:
> 
>> Hi all,
>>
>> Currently, we supported several DPI application scenarios performance tuning,
>> in these scenarios, the DPDK library ethdev, ring, mbuf and hash APIs are used.
>>
>> One of the scenarios is:
>>
>>     ------------------------                           -------------------------
>>     |                      |       rte_ring-0          |                       |
>>     |  packet-recv-process | ===>  rte_ring-1  ===>    | packet-detect-process |
>>     |                      |         ...               |                       |
>>     |                      |       rte_ring-n          |                       |
>>     ------------------------                           -------------------------
>>
>>     packet-recv-process dispatch flow to different rings by such 'rte_hash_crc' function.
>>     packet-detect-process build flow context based on rte_hash library.
>>
>> I think it is necessary to add a DPI example to show that DPDK has the basic
>> capability of building DPI applications and provides best performance practices.
>>
>> Hope to listen to the community's opinions.
>>
>> Thanks
>>
> 
> Did you consider the impact of CPU cache on this scenario.
> When you process the packet in two different threads, it ends up adding
> an additional data cache miss which can cut performance in half.

Yes, this model has the cache problem (it did has performance loss, but not so much). Let assume that this model is A.

Another scenarios (this model is cache friendly) is:
     --------------------------
     |                        |
     |  packet-detect-process |
     |                        |
     |  packet-recv-process   |
     |                        |
     --------------------------
         |  multi-queues  |
     --------------------------
     |   hardware-RSS         |
     --------------------------
   The NIC hardware dispatch flow to different hardware queues by RSS.
   Each threads in the process then receive and detect.
   Let assume this model is B.

Currently, there are many traffic encapsulation formats, but the NIC RSS hash always very simple (more complex
can be implemented throught flow matching, but many NICs do not support this feature). In this case, the model
A could be used, the software could dispatch flow by user-defined.

I think this example could both support the above two model.