[PATCH v1] cleanup: rename base classes

[Honnappa Nagarahalli]

<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
> 
I am not sure if Thomas is asking to change 'SUT' to 'tested node'.
>From my side, 'SUT' is better.

> > > > > * 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.
I would prefer to refer to individual device types rather than a single word that refers to all the device types.

Also, it is not applicable here, we should refer to devices types in a general sense. For ex: QAT is specific to Intel's crypto device, we should use 'Crypto' instead.

> 
> > >
> > > > > 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.
> 
> > >
> >
>