RE: [PATCH v1] cleanup: rename base classes

["Juraj Linkeš" <juraj.linkes@pantheon.tech>]

> -----Original Message-----
> From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> Sent: Wednesday, May 18, 2022 1:02 AM
> To: thomas@monjalon.net; Juraj Linkeš <juraj.linkes@pantheon.tech>;
> lijuan.tu@intel.com; ohilyard@iol.unh.edu
> Cc: dts@dpdk.org; David Marchand <david.marchand@redhat.com>; nd
> <nd@arm.com>; bruce.richardson@intel.com
> Subject: RE: [PATCH v1] cleanup: rename base classes
> 
> <snip>
> >
> > > > The current naming of the base elements DTS works with is a bit
> > > > confusing, which this patch attemps to ameliorate. The basic
> > > > elements could be divided into and described in short as follows:
> > > > * A node: a broad term encompassing a host where any of the DTS
> > > > elements are present. This could be a physical or virtualized
> > > > server or a container.
> >
> > OK
> >
> > > > * The control node: the host where DTS runs
> >
> > OK
> >
> > > > * An SUT (system under test) node: This is where DPDK along with
> > > > the tested hardware resides. The system comprises DPDK and the
> hardware.
> >
> > Is there any difference between a SUT and a "tested node"?
> >
As defined above, the system under test is DPDK with the hardware we're interested in testing (usually the devices DPDK works with). I'm not sure what the definition of a "tested node" is, but what would make senes to me is that the tested node would be the node where the SUT is located (the same as an SUT node).
This definition rests on what a system is and do we apply that to our context, for example:
a regularly interacting or interdependent group of items forming a unified whole [0]

I went with DPDK + the hardware it's using as the unified whole as those are the parts we're interested in, but the unified whole could reasonably mean more than just DPDK + it's hardware (or, from another point of view, the hardware we're testing utilizing DPDK).

[0] https://www.merriam-webster.com/dictionary/system

> > > > * A traffic generator node: The node where the traffic generator
> > > > is present, such as Trex, Scapy or a hardware traffic generator (e.g.
> > > > IXIA)
> >
> > OK
> >
> > > > All references to DUT were removed. This is because it was used to
> > > > mean both the server where DPDK/NIC are present and the DUT
> > > > (device under test, i.e. the NIC) in different contexts. Where
> > > > applicable, DUT was replaced with NIC and the rest were replaced
> > > > with SUT. With this change, it's clear what's meant and the
> > > > abbreviations are very different, which removes that layer of confusion.
> >
> > "NIC" does not mean it is a device under test.
> > Also we could have other kind of devices under test, like crypto cards.
> May be for other cards, we could use "XxxAccelerator"? We could leave "NIC" as
> is.
> 
NIC is not necessarily a device under test, but a device under test could be a NIC in the proper context (such as when the tested device is a NIC, which is where the references to NICs).
Currently, when DTS docs or code mentions a NIC, it's always a NIC that's being tested (and no other device type). In DTS, when DUT refers to a device, it's always a NIC (meaning that when DTS refers to a NIC, it uses either NIC or DUT which this change unifies to just NIC). There are references to other devices, such as QAT, but DUT is never used to refer to non-NIC devices.

We could use DUT to mean any type of device (NIC, QAT, other accelerators) being tested, it's just that's not how it's used anywhere in DTS.

So the policy that this change brings is basically to refer to device types (NIC, QAT, etc.) instead of a broad category (DUT). Let us know whether this makes sense.

> >
> > > > Rename the following classes:
> > > > Crb -> Node
> > > > Dut -> SutNode
> > > > Tester -> TrafficGeneratorNode
> > > > DPDKdut -> DpdkSut
> > > > DPDKtester -> DpdkTrafficGenerator VirtDut -> VirtSut CrbsConf ->
> > > > TopologyConf PktgenConf -> PacketGeneratorConf
> >
> > I think you need to choose between "TrafficGenerator" and
> > "PacketGenerator".
> +1 for a single term
> 
Agreed. We talked this over and we're going with TrafficGenerator.

> >
>