On 09/08/2024 16:10, Jeremy Spewock wrote:
<snip>
+ def match_all_packets(
+ self, expected_packets: list[Packet], received_packets: list[Packet]
+ ) -> None:
This is a very interesting approach to comparing what you expect to
what you received. I hadn't seen counters used before but they seem
useful for this purpose. This method reminds me a lot of the filtering
process that was discussed in bugzilla ticket 1438
(https://bugs.dpdk.org/show_bug.cgi?id=1438) where there was some talk
about how to handle the noise vs what you received. This is different
in a few ways though of course in that it allows you to specify
multiple different criteria that are acceptable rather than just
getting the payload and really only concerns itself with matching
lists instead of doing any filtering.
The main reason I mention this is it brought up a question for me: Do
you think, in the future when the payload filtering method is
implemented, these two methods will co-exist or it would make more
sense to just let test suites get their noise-free list of packets and
then check that what they care about is present? I think a method like
this might be useful in some more niche cases where you have multiple
packet structures to look for, so I don't doubt there are some reasons
to have both, I was just wondering if you had thought about it or had
an opinion.
I am not actually entirely sure, it sounds as if everything has space
for their own case. This method is useful to just plainly check that all
the packets we sent came back, simple and straightforward. Payload
filtering can be more niche and complex. I think if it can provide the
same level of functionality as this function, it can be replaced for
sure. But in that case it sounds like the test developer would be tied
to a specific payload. In the case of random packet generation I don't
think it would work, in which case they could both coexist.
