On Fri, Sep 6, 2024 at 12:23 PM Luca Vizzarro <luca.vizza...@arm.com> wrote: > > 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.
Good points, this makes sense to me!
