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 B064945D03; Thu, 14 Nov 2024 23:17:21 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4882042EBB; Thu, 14 Nov 2024 23:17:21 +0100 (CET) Received: from inbox.dpdk.org (inbox.dpdk.org [95.142.172.178]) by mails.dpdk.org (Postfix) with ESMTP id 141864027E for ; Thu, 14 Nov 2024 23:17:20 +0100 (CET) Received: by inbox.dpdk.org (Postfix, from userid 33) id DAB2845D08; Thu, 14 Nov 2024 23:17:19 +0100 (CET) From: bugzilla@dpdk.org To: dev@dpdk.org Subject: [DPDK/ethdev Bug 1578] Observed Inconsistencies In Device Allow-list Pools. Date: Thu, 14 Nov 2024 22:17:19 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: DPDK X-Bugzilla-Component: ethdev X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: npratte@iol.unh.edu X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: dev@dpdk.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: multipart/alternative; boundary=17316226390.8bFB95Fc2.591628 Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://bugs.dpdk.org/ Auto-Submitted: auto-generated X-Auto-Response-Suppress: All MIME-Version: 1.0 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 --17316226390.8bFB95Fc2.591628 Date: Thu, 14 Nov 2024 23:17:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.dpdk.org/ Auto-Submitted: auto-generated X-Auto-Response-Suppress: All https://bugs.dpdk.org/show_bug.cgi?id=3D1578 Bug ID: 1578 Summary: Observed Inconsistencies In Device Allow-list Pools. Product: DPDK Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: ethdev Assignee: dev@dpdk.org Reporter: npratte@iol.unh.edu Target Milestone: --- Vendor NICs allow for a set amount of mac addresses to be stored as an allow-list for general address filtering. The exact amount of mac addresses= to be added can be discovered through the ethdev api, but when creating univer= sal, vendor-agnostic tests for this functionality, some vendors may allow for the listed amount of addresses not including the device's vendor-given mac addr= ess (so if the device claims it can support 128 addresses, it can actually supp= ort 129). Some other vendors take a different approach and allow for the list t= otal of addresses including the vendor-provided address (so a device that suppor= ts 128 addresses can only add 127 extra before throwing an error). There are ways to avoid this problem from coming up by creating an upper bo= und that no device should ever reasonably cross, but it might be best to discuss what is suitable for testing this functionality in the long-term. --=20 You are receiving this mail because: You are the assignee for the bug.= --17316226390.8bFB95Fc2.591628 Date: Thu, 14 Nov 2024 23:17:19 +0100 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.dpdk.org/ Auto-Submitted: auto-generated X-Auto-Response-Suppress: All
Bug ID 1578
Summary Observed Inconsistencies In Device Allow-list Pools.
Product DPDK
Version unspecified
Hardware All
OS All
Status UNCONFIRMED
Severity normal
Priority Normal
Component ethdev
Assignee dev@dpdk.org
Reporter npratte@iol.unh.edu
Target Milestone --- 

Vendor NICs allow for a set amount=
 of mac addresses to be stored as an
allow-list for general address filtering. The exact amount of mac addresses=
 to
be added can be discovered through the ethdev api, but when creating univer=
sal,
vendor-agnostic tests for this functionality, some vendors may allow for the
listed amount of addresses not including the device's vendor-given mac addr=
ess
(so if the device claims it can support 128 addresses, it can actually supp=
ort
129). Some other vendors take a different approach and allow for the list t=
otal
of addresses including the vendor-provided address (so a device that suppor=
ts
128 addresses can only add 127 extra before throwing an error).

There are ways to avoid this problem from coming up by creating an upper bo=
und
that no device should ever reasonably cross, but it might be best to discuss
what is suitable for testing this functionality in the long-term.

You are receiving this mail because:
  • You are the assignee for the bug.
=20=20=20=20=20=20=20=20=20=20
= --17316226390.8bFB95Fc2.591628--