I was thinking about more flexible design of TRAFFIC handling in VSPERF for some time.
As of now we have two configuration parameters in TRAFFIC dictionary, which controls multi stream feature:

‘multistream’ – which defines number of streams to be simulated (e.g. 5000, 300000, 1000000, etc.), where 0 (default) disables this feature, so all frames should have the same headers defined by TRAFFIC dictionary, i.e. no IP/MAC, etc should be iterated by default

‘stream_type’ – which defines what should be iterated, currently only L2, L3 and L4 values are supported and their meaning is not consistent among traffic generators. In case of IXIA (my original implementation) destination MAC (L2), destination IP (L3) or destination UDP port (L4 is iterated). Other generators (Spirent, ..?) iterate source IP/MAC/port, which makes more sense for the first sight. On the other hand iteration of DST mac/IP is crucial for some vsperf features, e.g. routing traffic to VMs connected in parallel. I was thinking for some time about enhancing “multi stream” feature to support “iteration” of different frame/packet items (and their combinations), to be more flexible.

I can see following issues with current implementation:

• it is not consistent among traffic generators (i.e. iteration of source vs. destination MAC/IP/port)
• it is possible to iterate only 3 defined ‘items’ => it should be more flexible and iteration of multiple items should be possible
• it is not possible to detect features supported by chosen traffic generator => vsperf should be able to verify TGEN capabilities required by given TC and fail if TGEN is not able to run such TC.

As usual, there are several options. I think that we should introduce something like TRAFFIC_CAPABILITIES dictionary, where every supported TGEN will have its section, with list of supported features. I can imagine that it will have identical structure as TRAFFIC dict, but instead of “scalar” leafs it will have lists with supported options. Such capabilities can be used:

1) by developers to identify, what is missing in particular TGEN implementation
2) by users to detect what traffic generator will suit their needs (required by selected/wished test setups)
3) by vsperf (e.g. in testcase.py during TC initialization) to automatically perform a simple check if all “features” requested by given testcase (i.e. its TRAFFIC customized dict) are supported (e.g. given RFCxxxx traffic pattern or multistream feature).

In case of multi stream feature, it might be useful to “integrate” its configuration into TRAFFIC dict itself. It will be more user friendly than introduction of another complex structure with multiple protocols and their headers. I can imagine something like (in TC definition, where only changes to TRAFFIC array can be defined):

TRAFFIC = {
               ‘multistream’ : 30000
               ‘l2’: {
                              ‘srcmac’ : ’#01:00:00:00:00:00:00’
                              ‘dstmac’ : ’AA:00:00:00:00:00:00’
                      }
               }

where ‘#’ sign marks, what should be iterated. Of course we should figure out more generic notation, which allows to iterate also through values from given list, etc.

I would also like to introduce some standardized naming convention of protocols, headers, etc., i.e. to get rid of current ISO OSI TRAFFIC dict keys (L2, L3...), etc. At the same time I would like to avoid a TGEN or vSwitch specific names.

=>> Al, do you have any RFC/IETF, etc. glossary in mind, which we can use as a master template for protocol names (ethernet, vlan, ip, upd…) and their headers (srcmac, dstip, etc.) in vsperf? Another option is to use some neutral tool as a reference (e.g. wireshark). In general I would like to see consistent “naming” of both existing and newly introduced TRAFFIC and trafficgen capabilities items.