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 BC4AB44120; Fri, 31 May 2024 23:08:54 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id ABDBA42DDF; Fri, 31 May 2024 23:08:54 +0200 (CEST) Received: from mail-pj1-f43.google.com (mail-pj1-f43.google.com [209.85.216.43]) by mails.dpdk.org (Postfix) with ESMTP id 9C3D142D8C for ; Fri, 31 May 2024 23:08:48 +0200 (CEST) Received: by mail-pj1-f43.google.com with SMTP id 98e67ed59e1d1-2c1b542ae9eso1110864a91.1 for ; Fri, 31 May 2024 14:08:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1717189728; x=1717794528; 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=7NJTUi7cMfH2JAR+13KZrgyBrbEw0Wl0KdJfi0QirmA=; b=ZtkfLjyqPdl7HdhtB8lwK/k0Gdp6lvYtHrTgwrZnU5tMRK5D0Spen3roUtxU+DEB7L iyjHBTYyJxXpOYLDtdh0ZokIwoiV8Av6QQPt9QvM19rTY7OdfyqanIZhDS/P0pn8LjCS KMgYcS6+M6h9cnhKNg46uVoXmQvt9dKG3AhN8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717189728; x=1717794528; 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=7NJTUi7cMfH2JAR+13KZrgyBrbEw0Wl0KdJfi0QirmA=; b=wWAowWUtTZdboXuDdhZqIxXUgGrVH+jOjIDE+7SJozTJW0rc7mOAndnJeAZSNjOA+n ap/oVYuPqrfHj73zcnlCJo1C/HyNeeF9Kskb7roEID58xUhC+uP8r9jG5l4+hwO9jG2x 3iLdmfLgvyAxPiD8TloREvQnlokzV694/FLBR9b3YSnvfq4xddokaXYnFpCY42JQeXkx QCBfRjHB6Reh/q3mrbzlwCev/dkGt8t2XpOVdrQLVprIvodl/VDr3f3NB6xu2+I77CkS Fa94lRDPZ0NSGRp6I5v2O8HwPw/KwoPgni5+DCg+WzR/KHu0R/zqtMCaxh8ZCaLkSqta j+5Q== X-Forwarded-Encrypted: i=1; AJvYcCVmXpuYfVEYWbYlzPXuTIcBpZmtZ0DMh+OhvWHdx1rkIU+KV5hSL9eryQxj7wyLgm4ks6x4hPle183Rz78= X-Gm-Message-State: AOJu0YyyZNRNYi27afE9OB20d6XlIyNCYhCEhd5h+HEiLxwP3cedLadZ ro/RGzrOM7cVfc2jkuECO+6mFVkxglfOUbIUPf1XL+sASp8vpXQ2Dmx0Mzfj0tJzEUIVLA7+hk4 LhxOLCP/XA6aAxldKPGNGTbxtjeeIXHkQPSLxtQ== X-Google-Smtp-Source: AGHT+IGDcOwV43HWZ6hanjPsvjUYIcU34JyPjXkbANO1oyoVBg1i2TgJfYL8T+Ha9UgPPSBGfBMBH9MyV9fYgE+mHuc= X-Received: by 2002:a17:90a:7f8c:b0:2c1:a526:820b with SMTP id 98e67ed59e1d1-2c1dc58c8c8mr3257126a91.23.1717189727878; Fri, 31 May 2024 14:08:47 -0700 (PDT) MIME-Version: 1.0 References: <20240514201436.2496-1-jspewock@iol.unh.edu> <20240530163339.14566-1-jspewock@iol.unh.edu> <20240530163339.14566-5-jspewock@iol.unh.edu> <0b2d6cab-048e-411a-81d6-d6b1b129a6a1@arm.com> In-Reply-To: <0b2d6cab-048e-411a-81d6-d6b1b129a6a1@arm.com> From: Jeremy Spewock Date: Fri, 31 May 2024 17:08:36 -0400 Message-ID: Subject: Re: [PATCH v2 4/4] dts: add test case that utilizes offload to pmd_buffer_scatter To: Luca Vizzarro Cc: juraj.linkes@pantheon.tech, paul.szczepanek@arm.com, wathsala.vithanage@arm.com, Honnappa.Nagarahalli@arm.com, probb@iol.unh.edu, yoan.picchi@foss.arm.com, npratte@iol.unh.edu, thomas@monjalon.net, dev@dpdk.org 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, May 31, 2024 at 12:33=E2=80=AFPM Luca Vizzarro wrote: > > While testing this patch against the Intel NICs we have, I've detected > that upon port start and stopping two ICMPv6 packets are sent out. This > has caused these packets to appear in the first capture, causing it to > intermittently fail if they were the first packets to arrive or not. > Sometimes the ICMPv6 packets would be the only ones to show in the > captured packets. This problem is not strictly related to this patch but > could be fixed if not too annoying. > > So far what appears to have fixed the issue on my side, was just add > some wait between port setup and the sending of the packets. > time.sleep(2) seems to have done the job. But it may not be an ideal > solution. Ack. Maybe something I could do here is update the verification step to instead find any packet in the list that passed the test rather than assuming there won't be interference.