Re: [bmwg] Agenda for BMWG session at IETF-109

[Vladimir Vassilev <[e-mail]>]

Hi Gábor,

On 08/11/2020 19.21, Lencse Gábor wrote:
> However, I have results regarding siitperf, my RFC 8219 compliant SIIT 
> tester. (The usage of random port numbers is working well. I'm 
> currently working on calibrating it with a legacy RFC 2544 tester by 
> benhmarking the same DUT with the two devices and comparing their 
> results.) If there is interest in the WG for it, I would be happy to 
> present. But I do not want to push it.
>
> So, what do you think?


I looked into the implementation of siitperf. It is a well designed 
reference implementation for RFC 8219 and a useful DPDK API usecase and 
example in general.

Maybe it is a long shot but I was wondering if you are participating in 
the ongoing Hackathon? We are working on a relevant project that 
implements a general network interconnect tester based on a YANG model 
[1]. Instead of a single executable implementing a benchmark test (e.g. 
RFC2544, RFC8219 etc.) one can split the design into control plane 
(search logic, reconfiguration of the generator for different trials, 
reading status) and data plane (the timing critical frame input/output 
operations and timestamping). The control plane is managed with a python 
script over NETCONF [2] and the data plane workload is processed by 
software (native code in C) [3] or hardware logic (Verilog) [4] that is 
started/enabled by the NETCONF server for each interface when traffic 
generator configuration is committed.  The command line looks like this 
(based on the YANG model for a generator with single stream):

$ ./traffic-generator --interface=eth0 --frame-size=64 
--interframe-gap=20 --interburst-gap=124999852 \
    --frames-per-burst=2 --total-frames=4 
--realtime-epoch="2020-11-10T13:00:00.000000000Z" 
--interface-speed=1000000000
--frame-data="123456789ABCDEF01234567808004500002E000000000A112CBCC0000201C0000202C0200007001A0000000102030405060708090A0B0C0D0E0F10119CD50E0F"

We have an alternative traffic-generator-gmii tool [4] that instead of 
using software to generate the packets writes to the registers of a 
hardware core we have designed in Verilog. So replacing the command name 
results in deterministic generation for the systems that have the core 
available.

We were thinking of a third option based on DPDK 
(traffic-generator-dpdk) could be a compromise that is more 
deterministic then the default (Unix userspace) option and would not 
require programmable logic like the hardware dependent one.

We could augment the YANG model adding choice and an alternative to the 
static frame-data specifying the range and algorithm for generation of a 
pseudorandom port numbers in the specified range as a second reference 
implementation and do some testing of common DUTs and compare the 
results produced by the different implementations.

References:

[1] 
https://datatracker.ietf.org/doc/draft-vassilev-bmwg-network-interconnect-tester/

[2] 
https://github.com/vlvassilev/litenc/blob/master/tntapi/example/ietf-network-interconnect-tester/test-rfc2544-throughput.py 
(seems the script diverged from the initial  throughput sec. 26.1 target)

[3] 
https://github.com/vlvassilev/yuma123/blob/master/example-modules/ietf-traffic-generator/traffic-generator.c

[4] 
https://github.com/vlvassilev/network-interconnect-tester-cores/blob/master/lib/hw/lsi/cores/traffic_generator_gmii/hdl/traffic_generator_gmii.v


/Vladimir


>
> Best regards,
>
> Gábor