test suite reviews and discussions
 help / color / mirror / Atom feed
From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
To: "Juraj Linkeš" <juraj.linkes@pantheon.tech>,
	"thomas@monjalon.net" <thomas@monjalon.net>,
	"lijuan.tu@intel.com" <lijuan.tu@intel.com>,
	"ohilyard@iol.unh.edu" <ohilyard@iol.unh.edu>
Cc: "dts@dpdk.org" <dts@dpdk.org>,
	David Marchand <david.marchand@redhat.com>,  nd <nd@arm.com>,
	"bruce.richardson@intel.com" <bruce.richardson@intel.com>
Subject: RE: [PATCH v1] cleanup: rename base classes
Date: Wed, 18 May 2022 15:38:00 +0000	[thread overview]
Message-ID: <AM8PR08MB5810C2C1FA7C237F436D779198D19@AM8PR08MB5810.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <e6f6f03857e64fdbb089c1fc2e5d7aee@pantheon.tech>

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


      reply	other threads:[~2022-05-18 15:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-16 13:33 Juraj Linkeš
2022-05-17  4:53 ` Honnappa Nagarahalli
2022-05-17  6:48   ` Thomas Monjalon
2022-05-17 23:01     ` Honnappa Nagarahalli
2022-05-18 14:35       ` Juraj Linkeš
2022-05-18 15:38         ` Honnappa Nagarahalli [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AM8PR08MB5810C2C1FA7C237F436D779198D19@AM8PR08MB5810.eurprd08.prod.outlook.com \
    --to=honnappa.nagarahalli@arm.com \
    --cc=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dts@dpdk.org \
    --cc=juraj.linkes@pantheon.tech \
    --cc=lijuan.tu@intel.com \
    --cc=nd@arm.com \
    --cc=ohilyard@iol.unh.edu \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).