[New feature suggestion] Capture custom ethernet packets about trex-core HOT 22 CLOSED

Could we have a short meeting about this?

from trex-core.

Ok, I sent email to your gmail id.

from trex-core.

from trex-core.

Ok,
I have available time slot on 19-Jun and 20-Jun.

from trex-core.

from trex-core.

Ok,
I sent invitation email.

from trex-core.

Let me summarize our discussion:
There are two ways to solve this

1. Add hardware filters
2. Move to software model which is more flexible, but has less performance

Decided to start with #2
The tasks:

1. Counters Engine:
   Use the current array of BPF-JIT with the action of counters or capture (we could add more action in the future)
   for example:
   1: (ip.src= 10.0.0.1 or tcp.dport =80), action= counter 1
   2: (ip.tos=7), action = capture

BPF does not support callbacks-actions (it is only a binary match/no match, only eBPF can do that)
From a performance perspective it would be beneficial to merge the rules
for example
rule1 (ip.src= 10.0.0.1), action ,counter =1
rule2 (tcp.dport =80), action ,counter =2

rule2 will repeat the eth(0x0800)/ip (skip) of rule#1 while we could have one tree with many exit points. But it is not supported.

Optimization:

1. we could add a way for fast skip (merge all the rules and if it does not match, do not continue to run all the rules)
2. Consider moving to eBPF (https://github.com/iovisor/ubpf) which support actions callback and hash (beneficial in case that we have scale of the same rules type
   ip=10.0.0.1 cnt=1,
   ip=10.0.0.2 cnt=2,
   ip=10.0.0.7 cnt=3,
   ip=10.0.0.11 cnt=4,
   etc)

2. Scale of Rx
   --software switch will run with multiple cores using RSS (like we do in ASTF mode) each DP core will run the BPF-Engine (counters in the first phase) and CP will sum the counters from all the cores and export it

I would start with Python API and running it on Rx core them move to scale/performance/eBPF
any thought?

from trex-core.

Hi Hanoh,
There is issue on this approach.
The problem is that current H/W filters drops all ethernet packets except IP packets.
Therefore, these packets(custom header packet) will not input to BPF filter.

Currently 4 kinds of H/W filter drivers(1G,10G,40G,82559) to modify and these are done by DPDK APIs.

from trex-core.

The idea of "Scale of Rx" task that there would be a different way to load the server.
In this mode all the packets will be seen by DP cores. in case there are no rules, DP cores will just drop the packet.

Another alternative is to use the pass-all filter (implemented) that will work in conjunction of RSS configuration.
The last mode will be backward compatible to what the current way STL is working

from trex-core.

Ok, I see.
"--software" option requires restart of TRex server, it's really inconvenient for users.
Capturing is not the normal case, it's special debug case, it should not impact on normal cases.
And "Scale of Rx" requires more total CPU resource and it's additional cost in user point view.
Let's think of how tcpdump works.
tcpdump enables promiscous mode when start and disable it when exit.
Like tcpdump.
I think it's better do it when capture start.

1. Enable pass-all filter when capture start, it's not enabled by default and disable it when capture stop.
2. Custom header need to be captured by BPF filter(e.g "ether proto 0x0800"), no need feature needed.
   I'm not sure upgrade BPF to eBPF is needed or not.

How about your opinion?

from trex-core.

As I said another option is:
"Another alternative is to use the pass-all filter (implemented) that will work in conjunction of RSS configuration.
The last mode will be backward compatible to what the current way STL is working"

this will work the same but give the option to scale some functionality of the Rx-core. on platform that does not support HW filter at all (virtio/vmxnet3/SR-IOV) the only option is to work in multi-core (DP path)

from trex-core.

BTW, maybe I've missed it. From your requirement respective, is it enough to filter only by ether-type value? If yes, this would be pretty easy to implement as an exception path for all drivers and only for capturing. The scope of my proposal is broader and more complicated to implement. eBPF is required for the more general solution (mainly for performance)

from trex-core.

Yes,
The user requirement was "capture custom ethernet type without performance degradation".
I think we can add it on BPF filter.

For example,
When user specify in BPF filter in TRex, "service> capture monitor ether proto 0xabcd",
Add "0xabcd" ethernet type to H/W filter(1G,10G,40G).
Then, we can capture this packet with minimum overhead and no additional API needed.

from trex-core.

Hi Hanoh,
I checked the current code, it have some issue when loading profile.
If we add filter in capturing phase, we cannot load profile.

I think, the original approach(Adding "custom_packet_types") seems better way for the current requirement scope("capture custom ethernet type without performance degradation and without restarting TRex server")

How about your opinion?

from trex-core.

from trex-core.

Hi Hanoh,
Good suggestion, but, it have problem when adding stream to custom packet.
Our ethernet packet type is non-standard 0xeb??, adding stream will fail in flow_stat_parser.

See example log here.
---Example log -------------
trex>start -f stl/myL2_1pkt.py -p 0
Attaching 1 streams to port(s) [0]: [FAILED]
Error loading profile 'stl/myL2_1pkt.py'
Port 0 : *** Failed parsing given packet for flow stat. NIC does not support given L2 header type

That's why I suggested implementation #1 to avoid loading failure. And filter should be added before users trying to add streams.
To avoid such situation, I think it's better to add filter in trex config file.

Syntax : In trex_cfg.yaml
custom_packet_types : { ethernet : "0xABCD" }
Description :
Define custom packet types to capture user defined ethernet packet.

Implementation #1. If custom ethernet types defined, check custom ehternet type when loading profile instead of returning error with FSTAT_PARSER_E_UNKNOWN_HDR
src/flow_stat_parser.cpp
Implementation #2. If custom ethernet types defined, add custom ethernet type filter to in set_rcv_all for all NIC types(1G,10G,40G)
src/main_dpdk.cpp

from trex-core.

from trex-core.

Hi,
When we add new filter, I did not think of any new limitations for users.
I thought it should work for both cases(per stream stat enabled or disabled).
That's why we tried to change flow_stat code.

Your original suggestion seems good, but, it may take some time. I need to check whether we can delay the feature.
BTW,
If we implement your original suggestion, which part should I implement? and which part will you implement?

Thanks
Gwangmoon

from trex-core.

from trex-core.

Hi Hanoh,
I discussed it with users, "per stream stat" is not strong requirement.
Let's go with the simplest solution(service-HW filter) without "per stream stat".

Thanks
Gwangmoon

from trex-core.

@egwakim Is there a plan to work on that?

from trex-core.

Hi Hanoh,
Jeongseok merged required change for it.
ffb83f1
With this change,
We can 1) Send custom ethernet packets 2) Capture custom ethernet packets 3) Get statistics per pg_id now.

I think we can close this ticket.

from trex-core.