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 956C445913; Mon, 9 Sep 2024 16:12:17 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 375D04028A; Mon, 9 Sep 2024 16:12:17 +0200 (CEST) Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com [209.85.208.176]) by mails.dpdk.org (Postfix) with ESMTP id B9F5140268 for ; Mon, 9 Sep 2024 16:12:15 +0200 (CEST) Received: by mail-lj1-f176.google.com with SMTP id 38308e7fff4ca-2f75aa08a96so29973011fa.1 for ; Mon, 09 Sep 2024 07:12:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1725891135; x=1726495935; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=iDT47mldzuIjvEGPuaEIfGfO2ApTcHGNegE1ZFbuMx8=; b=Qx2UZGagOOUTcwrkhpzLPjpbO+IKHESqn9X8FBHMYm/R4hDSDkYqJl0mJvy4XIt8Sh semla4qW4MsJ++4Daa7Lg095xGIY5F5PY+mrH0VKFLIrwoxOOwUUxDB3qlN4l/3rk8r+ AlHAERZ7z1OITkZ8AK782IzPlboV//Vjscc0U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725891135; x=1726495935; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=iDT47mldzuIjvEGPuaEIfGfO2ApTcHGNegE1ZFbuMx8=; b=E5pxipWiZCNLZWaOT9CxGcuczTcJtHYgXChOMOPIP4+X1xUBS3AASchVRj/IAZHpDm AHIlBJE6f2GBonDp1LSH9necwG4FlWUxZJ6p32y0z5LXUNArSYWzpghwm5itUhET4wNW +1Zr4Y8Ml04ogmgglC2cKxceIIf+848klwmGemxr36P+8RlwQFaufXIhb08lRxlPuoTW apOG2SBD4r/EJMWQhvDTu5KRm1W2GSWUbfN6cCPe6bocSkfHVe4HVvpoU3hqNAOBZp5T wgD6qccT+XDs5ribcdK+fUGW/I95GZEUXKxaUa+MP+g2hAaGyQWSkhCjXjhkwPjojN/B SGUA== X-Gm-Message-State: AOJu0YzArVZec/GpNKB1vE5a5NfbPQi9sSX1/L520J2jVRoTYNvBm+1s PPwrB1ts86OuPJmYDHiOByfpcJojVrG9iB8ZkUxR6KDGm9h5V+iCpkePDzDZfpdtjuFmqGuNiLD liIiM1RpuM0XwxGy5stGcV+8Pm3gCiFi/tLcOFA== X-Google-Smtp-Source: AGHT+IGo/BavuvVQ+FapvN0uCYyZ/fbj8QckOEJm2ZBVQ82n9vPj91E31yzpkZzbNvJVhMNToPbmC9+fNyABIxpQCwk= X-Received: by 2002:a2e:602:0:b0:2f5:1fa7:ac3a with SMTP id 38308e7fff4ca-2f751f671fcmr56209051fa.28.1725891134224; Mon, 09 Sep 2024 07:12:14 -0700 (PDT) MIME-Version: 1.0 References: <20240806121417.2567708-1-Luca.Vizzarro@arm.com> <20240806124642.2580828-1-luca.vizzarro@arm.com> <20240806124642.2580828-2-luca.vizzarro@arm.com> In-Reply-To: From: Jeremy Spewock Date: Mon, 9 Sep 2024 10:12:00 -0400 Message-ID: Subject: Re: [PATCH v2 1/5] dts: add ability to send/receive multiple packets To: Luca Vizzarro Cc: dev@dpdk.org, =?UTF-8?Q?Juraj_Linke=C5=A1?= , Honnappa Nagarahalli , Paul Szczepanek , Alex Chapman Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Fri, Sep 6, 2024 at 12:23=E2=80=AFPM Luca Vizzarro wrote: > > 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=3D1438) where there was some tal= k > > 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!