Here is a short description on what should be done in this task in
my opinion:

The task could be finished in 2 steps (2 patches):

1. Stop providing default socket-mem if not configured, because it's
   not required by DPDK.  Rationale for this is the fact that OVS does
   that historically, because it was not possible to use DPDK without
   configuring socket-mem and OVS wanted to provide some sensible
   default value, so users will not be obligated to specify anything
   for a simple setup.
   Current DPDK uses dynamic memory allocation by default and doesn't
   require socket-mem option, which also changed its meaning from the
   "total amount of allocated memory" to "amount of pre-allocated memory".

2. Stop matching socket-mem with socket-limit if socket-limit is not set.
   If user configures socket-mem and doesn't configure socket-limit, this
   should mean that user doesn't want the memory to be limited.  If user
   wants memory to be limited, they should configure socket-limit.

In general EAL arguments should look like this:

- dpdk-socket-mem=<not set>, dpdk-socket-limit=<not set>
  current: "--scket-mem=1024,1024 --socket-limit=1024,1024"
  step 1 : ""
  step 2 : ""

- dpdk-socket-mem=<MEM>, dpdk-socket-limit=<not set>
  current: "--scket-mem=MEM --socket-limit=MEM"
  step 1 : "--scket-mem=MEM --socket-limit=MEM"
  step 2 : "--scket-mem=MEM"

- dpdk-socket-mem=<not set>, dpdk-socket-limit=<LIMIT>
  current: "--scket-mem=1024,1024 --socket-limit=LIMIT"
  step 1 : "--socket-limit=LIMIT"
  step 2 : "--socket-limit=LIMIT"

- dpdk-socket-mem=<MEM>, dpdk-socket-limit=<LIMIT>
  current: "--scket-mem=MEM --socket-limit=LIMIT"
  step 1 : "--scket-mem=MEM --socket-limit=LIMIT"
  step 2 : "--scket-mem=MEM --socket-limit=LIMIT"

Above cases could be extrapolated to cases where values passed
via dpdk-extra.  Also we should assume that if someone uses
'--legacy-mem'. they should have socket-mem configured one way or
another and OVS should not care about this scenario or try to add
some default values.

*** Bug 1949849 has been marked as a duplicate of this bug. ***

*** Bug 1944568 has been marked as a duplicate of this bug. ***

Hi Eeclo,

Can you provide steps to verify this RFE feature ? Or, can you share your test script ?

For regression, I can run two testpmd tests --- one with socket-mem=4096,4096 statement, the other without. How about that ?

Thanks!
Jean

 Rosemarie, can you help Jean on #13?

I have run two P2P/OVS-dpdk test --- one with dpdk-socket-mem="4096,4096", the other without. Both delivered 12.1 Mpps throughput.

Observation on /proc/meminfo: Only two 1GB hugepages allocated when starting openvswitch. It stayed that way during the P2P test run for either case.
Also, there were no rte_map hugepage entries in /dev/hugepages.

*** Test Info ***

[root@wsfd-advnetlab151 dev]# rpm -q openvswitch2.17
openvswitch2.17-2.17.0-15.el9fdp.x86_64
[root@wsfd-advnetlab151 dev]# uname -r
5.14.0-70.13.1.el9_0.x86_64
[root@wsfd-advnetlab151 dev]# 

[root@wsfd-advnetlab151 jhsiao]# !cat
cat ovs_dpdk_p2p.sh
ovs-vsctl set Open_vSwitch . other_config={}
ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-lcore-mask=0x0200000000000002000000000000
ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-socket-mem="4096,4096"
ovs-vsctl --no-wait set Open_vSwitch . other_config:pmd-cpu-mask=0xa0000000000000a0000000000000
ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-init=true

ovs-vsctl --if-exists del-br ovsbr0
ovs-vsctl add-br ovsbr0 -- set bridge ovsbr0 datapath_type=netdev
ovs-vsctl add-port ovsbr0 dpdk-10 \
    -- set interface dpdk-10 type=dpdk ofport_request=10 options:dpdk-devargs=0000:b1:00.0 \
    options:n_rxq=1
ovs-vsctl add-port ovsbr0 dpdk-11 \
    -- set interface dpdk-11 type=dpdk ofport_request=11 options:dpdk-devargs=0000:b1:00.1 \
    options:n_rxq=1

ovs-ofctl del-flows ovsbr0
ovs-ofctl add-flow ovsbr0 in_port=10,actions=output:11
ovs-ofctl add-flow ovsbr0 in_port=11,actions=output:10
ovs-ofctl dump-flows ovsbr0
[root@wsfd-advnetlab151 jhsiao]#

Hi Eelco,
I would like to set the bug status to VERIFIED by EOB today.
Is that OK?
Thanks!
Jean

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (openvswitch2.17), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2022:4792