From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 3652845920; Fri, 6 Sep 2024 18:23:39 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DEBF642F95; Fri, 6 Sep 2024 18:23:38 +0200 (CEST) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mails.dpdk.org (Postfix) with ESMTP id 15A5442E82 for ; Fri, 6 Sep 2024 18:23:37 +0200 (CEST) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A1A03FEC; Fri, 6 Sep 2024 09:24:03 -0700 (PDT) Received: from [10.57.17.223] (unknown [10.57.17.223]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 603D93F73B; Fri, 6 Sep 2024 09:23:35 -0700 (PDT) Message-ID: Date: Fri, 6 Sep 2024 17:23:33 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/5] dts: add ability to send/receive multiple packets Content-Language: en-GB To: Jeremy Spewock Cc: dev@dpdk.org, =?UTF-8?Q?Juraj_Linke=C5=A1?= , Honnappa Nagarahalli , Paul Szczepanek , Alex Chapman References: <20240806121417.2567708-1-Luca.Vizzarro@arm.com> <20240806124642.2580828-1-luca.vizzarro@arm.com> <20240806124642.2580828-2-luca.vizzarro@arm.com> From: Luca Vizzarro In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On 09/08/2024 16:10, Jeremy Spewock wrote: > >> + 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.