I think a discussion should be made around introducing extra functionality into the TestSuite object within DTS. Old DTS, in numerous test suites, will explicitly insert a payload into a frame; some test suites may even analyse the contents within the frame to ensure that the specified payload was received properly. A good example of this being the case in new DTS is the jumboframes suite I am working on. Implementation of packet verification can be done in two way: Assessing both layers two and three in all received packets to verify the expected packet was received, or alternatively, dissecting and inspecting the payload of each received packet and validating the user's previously defined payload in within one of these received packets. For those that prefer the latter, it might make sense to introduce a method that automatically does this and introduce some kind of "default" payload in each packet if the user leaves it unspecified. A potential benefit of this might be that we could create some sort of "filter" method that, when called by the user, will return a list of packets that contain a defined payload as a parameter, effectively getting rid of all the the junk packets the test suite doesn't care about. In any case, I think a good concern could be raised about why this sort of filtering is not currently implemented in the framework currently.
We definitely want this. I think all test cases should be using default packets and only change fields when there's a reason for it. We talked about filtering extensively and we've settled on assuming that there's no extra traffic on the link (a quite wire). I'm not sure this has been properly documented though - the OS stack should be configured to not produce any packets (which is definitely true for Scapy, which uses the OS driver; may not be needed for testpmd when it uses vfio-pci).
> We talked about filtering extensively and we've settled on assuming that > there's no extra traffic on the link (a quite wire). I'm not sure this has > been properly documented though - the OS stack should be configured to not > produce any packets (which is definitely true for Scapy, which uses the OS > driver; may not be needed for testpmd when it uses vfio-pci). Interesting. In that case, I'm curious if there in any sensibility, from your perspective, as to whether or not we could modify the 'send_packet_and_capture' method to include some kind of boolean, which defaults to false, and inserts some kind of default payload into the packets beings sent. The user could go one step further and explicitly define a payload as a method parameter, or leave it blank to stick to a default payload. The problem with this is that I'm not so sure whether or not it's a good idea to begin with. My main concern with it is that it might affect how packets are built, messing with packet lengths and disrupting the logic of already existing test cases. Truth be told, I don't have much of an intuition as to the implications of an implementation like this, so I'm curious what your thoughts are. In any case, I'm pretty sure there is a way to assert a certain packet length when defining them in scapy. Much of the motivation for suggesting this in the first place is because the internal topology I used was sending LLDP packets, and I needed to filter them out to discern if payloads were received.