Suricata

One approach involves aggregating multiple arguments of the same type into a list, while the other involves creating custom Suricata arguments tailored for DPDK. In the latter case, these custom parameters would then be "translated" into DPDK EAL arguments.

Argument aggregation¶

It would extend the way DPDK EAL arguments are used currently. The only addition would be aggregating the parameters of the same type into one list.
Example from the suricata.yaml:

dpdk:
  eal-params:
    proc-type: primary
    a: ["0000:3b:00.0", "0000:3b:00.1"]
    vdev: ["net_pcap0,rx_pcap=input.pcap,tx_pcap=output.pcap", "net_pcap1,rx_pcap=input.pcap,tx_pcap=output.pcap"]

Suricata DPDK arguments¶

This concept is not entirely new, as for instance, lcore parameters are not permitted in the EAL configuration section. These are crafted/loaded of the threading section of the suricata.yaml file. However, the remaining DPDK arguments are still inputted in their raw form. To go this way, this would mean implementation or rather translation of all/selected DPDK arguments to Suricata arguments. This might be more concise approach but would require constant evaluation of arguments support across DPDK versions.
As an example of this approach, here is extract from the DPDK Trex packet generator configuration file:

- version: 2
  interfaces: ['0b:00.0', '0b:00.1']
  prefix: TREX
  limit_memory: 4096
  port_info:
      - dest_mac: b4:96:91:9f:63:68
        src_mac:  40:a6:b7:0b:55:78
      - dest_mac: b4:96:91:9f:63:69
        src_mac:  40:a6:b7:0b:55:79

  platform:
      master_thread_id: 0
      latency_thread_id: 1
      dual_if:
        - socket: 0
          threads: [2,3,4,5,6,7]

Arguments such as interfaces, limit_memory, *thread* could be translated to DPDK EAL arguments --allow, --socket-limit, -l respectively.

My conclusion¶

While I can see potential benefits of shielding EAL arguments from the user in the Suricata DPDK arguments variant, I would vote for the Argument aggregation approach within the config to not limit the user to what DPDK EAL arguments are supported and at the same time, there is no need to track the support of individual arguments in within the EAL.

The Argument aggregation approach is under review in https://github.com/OISF/suricata/pull/8588

@Lukas Sismis I'm in favour of the more "raw" formats rather than having Suricata do too much parsing/reasoning of the values. For the given examples, could you provide the example of how it would be done on the command line? Would be good if it was easy to translate one to the other.

@Jason Ish

ok, here is the example of how running a t-rex would look like with command line parameters:

# trex --file-prefix=TREX --allow=0b:00.0 --allow=0b:00.1 --socket-limit=4096 --main-lcore=0 -l 2,3,4,5,6,7

Note that this configuration mixes some DPDK parameters with internal t-rex parameters (e.g. port_info section, version or platform are internal t-rex settings). So after loading the configuration, t-rex needs to translate and create DPDK command line parameters like the ones above. It is then fed to the rte_eal_init function (https://doc.dpdk.org/api/rte__eal_8h.html#a5c3f4dddc25e38c5a186ecd8a69260e3).

So if I understand it correctly, you and @Victor Julien would also be in favor of the "raw" format. However, the change would still require changes as mentioned in the Argument aggregation variant (to be able to have a valid YAML and enter multiple entries of the same argument. Am I correct?

Yeah, I think you understand correctly. I wouldn't be to afraid of command line arguments that look like:
--dpdk-foo="multiple words here" provided they are value passed directly to dpdk, don't want to have to implement another level of command line parsin.

PR under review (one approval received)
https://github.com/OISF/suricata/pull/8966