RE: [PATCH v1] cleanup: rename base classes

[Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>]

+ Thomas, David, Bruce

<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.
> * The control node: the host where DTS runs
> * An SUT (system under test) node: This is where DPDK along with the
> tested hardware resides. The system comprises DPDK and the hardware.
> * A traffic generator node: The node where the traffic generator is
> present, such as Trex, Scapy or a hardware traffic generator (e.g. IXIA)
> 
> 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.
> 
> Rename the following classes:
> Crb -> Node
> Dut -> SutNode
> Tester -> TrafficGeneratorNode
> DPDKdut -> DpdkSut
> DPDKtester -> DpdkTrafficGenerator
> VirtDut -> VirtSut
> CrbsConf -> TopologyConf
> PktgenConf -> PacketGeneratorConf
> 
Hi Thomas/David/Bruce,
	This is one of the cleanup patches going into DTS. The classes are being renamed to make them more easy to understand. We have chosen the above names. If you have other thoughts, let us know.

Thanks,
Honnappa

> Along with the classes, also rename variables and doc/comment
> references.
> 
> Rename the files where these classes are defined as well:
> crb.py -> node.py
> dut.py -> sut_node.py
> tester.py -> tg_node.py
> virt_dut.py -> virt_sut.py
> 
> And also rename the top config file:
> crbs.cfg -> topology.cfg
> 
> And one of the doc files:
> setup_dut.rst -> setup_sut.rst
> 
> Also add .gitignore with some basic rules.
> 
> Also removed the output directory, as it doesn't really serve a purpose.
> 
> branch: future-dts
> 
> Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
> ---
> I didn't split the patch, as it is nontrivial and would only help with
> code review. However, if we want to do a thorough review, I can split it.
> In my view, we need to just scan review the patch, as it's really large.
> We'll do more thourough testing when submitting to DPDK anyway.
> 
> What may be more important is testing. I tested just the HelloWorld
> testcase, so basics work and it's ready for more testing, but that would
> require CI resources.
> 
> I used the CamelCase convention for the Dpdk* classes, but maybe we want
> to name them DPDKSut and DPDKTrafficGenerator.
> 
> It's possible that renaming tester to traffic generator is not the way
> to go. It seems to me that, in DTS, tester means both the traffic
> generator node and the control node, depending on context. These of
> course can be the same, but we should have a different class for these
> in DTS, if needed. I went with tester -> traffic generator since we
> don't (or shouldn't) really need a class for the control node (as we
> don't need to connect to it and the host should be setup beforehand to
> run DTS). We do need a class to handle traffic generator connections and
> management though.
> There are also complementary PacketGenerator classes which seem to
> handle some of traffic generator management. My thinking was that the
> PacketGenerator classes handle just packet (and flow) generation but it
> looks like there isn't such a clean split. We may need to think about
> this design before submitting traffic related testcases to DPDK (we
> could do some refactoring on the fly, maybe just move methods between
> classes (and maybe some renaming) to achieve a clean split we'll agree
> on later).
> 
> And the .gitignore file is a nice to have and it was particularly useful
> for me with this patch, so I just snuck it in. I could remove it and
> submit a separate patch along with the removal of the output dir.
> ---
<snip>