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 C884643A22; Wed, 31 Jan 2024 18:11:21 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9D0FF42D95; Wed, 31 Jan 2024 18:11:20 +0100 (CET) Received: from mail-oo1-f47.google.com (mail-oo1-f47.google.com [209.85.161.47]) by mails.dpdk.org (Postfix) with ESMTP id 8CB2A402A7 for ; Wed, 31 Jan 2024 18:11:18 +0100 (CET) Received: by mail-oo1-f47.google.com with SMTP id 006d021491bc7-59a99ef8c7fso11798eaf.0 for ; Wed, 31 Jan 2024 09:11:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1706721077; x=1707325877; darn=dpdk.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=LEaVWwgyd0O91Q83F8a1EnWrhvdhBOJXJ6USSq83PE4=; b=VFQLtI7wEkBOWBViKU0zJVmZrp8M+CC+XF7VhCx5JB3UTNaueM6Zs7AsN4CldkhO4E MM1HjW6H4dvGmFE3wivtPzNqCuMq/vXiM8rLYKC/wMwYmknCR33O1CU+mhiCQSQDBch8 /U+Vg/zr9Rpcj0WLUu+D5Az4/vUk4qeI5xjQM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706721077; x=1707325877; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=LEaVWwgyd0O91Q83F8a1EnWrhvdhBOJXJ6USSq83PE4=; b=uqKuxPTMDdB26kC8XW4LhTtwDaUrecuTqWHKmiABDR550kYhwhEqmHNDMbOzc4e/0H +emuD7p9OghjJRpkHDIoUUCzsdk4/QzrqymhNjRoAWaP3jyO9zW44EnqVIbG3CmTxgxw 0SJo81xdutf7UaT4MzS/We7+2VM5C7ZTr3KOo6kPvAmQTGZZSzuQ31CJur0U88D16STS cgav6umFiEKdrHchnzTDsbbUoG1uxXWGVWa1rFRqp/PTTK1R1QQPVX6HgO0s7EXzfbP9 QuIMcKWCv/bOFMqPGi4IzwVz4pswKIoLC/RT/YZ6O77Kwc2EYNk7/TLz6i0R/TiClXs+ zr3Q== X-Gm-Message-State: AOJu0Yw66pVDMgsbL4X6CqVYCa481wpygXx0P3AXfbei0QMVGZ6iE4Qv 6N5ZBPZn+Sk+6kURq1LxX4/qoOKLyRNiI+ZQ1/C3ZDtiOMw4xrypHzuObpa+bFGbbbp/d3hCLOW BTx56iCTPge4o640bCm7hIK+VnXT2AvyCFYb52V0FBV+D8R95Nes= X-Google-Smtp-Source: AGHT+IEa0cGbt229P7qB3oa3NqSkb/B9BQ/rr+Xl732IjPmxFQ3CSIOwwST49dPnO77gss92vVHU/adesHL/yA/w0wk= X-Received: by 2002:a4a:e1cd:0:b0:59a:8c51:56 with SMTP id n13-20020a4ae1cd000000b0059a8c510056mr2097979oot.9.1706721077408; Wed, 31 Jan 2024 09:11:17 -0800 (PST) MIME-Version: 1.0 From: Patrick Robb Date: Wed, 31 Jan 2024 12:10:58 -0500 Message-ID: Subject: DTS WG Meeting Minutes - January 31, 2024 To: dev@dpdk.org Cc: dts@dpdk.org, ci@dpdk.org Content-Type: multipart/alternative; boundary="0000000000008ccc5b061040f703" 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 --0000000000008ccc5b061040f703 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable January 31, 2024 ##################################################################### Attendees * Patrick Robb * Juraj Linke=C5=A1 * Paul Szczepanek * Jeremy Spewock * Luca Vizzarro * Thomas Monjalon ##################################################################### Agenda * Additions to the agenda * Patch discussions * DTS Developer documentation * 24.03 roadmap ##################################################################### Minutes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D General Announcements * Added developers for DTS: Nick from UNH is starting on DTS now, and 1-2 more people from UNH will be starting on this project in the near future. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Patch discussions * Dockerfile patch is updated to fix poetry installation and add documentation for using SSH keys. * We are not going to COPY in the keys to the image from the Dockerfile. New approach is volume mounting ~/.ssh to the container at Docker run, and readme is provided explaining this process * Patrick Robb will run this, add a tag on the patch, and request a merge from Thomas * Scatter is submitted and has been reviewed by Juraj, looking for more reviews from community members to get that patch moving. * Can have 1 test for no offload, and 1 test for including offload 1. If scatter is not available, we should expect a failure in the second case. 2. Feature is underdocumented currently 3. We can add a patch adding comments documenting the feature. All lines in ethdev.h should be commented, so it is a =E2=80=9Cbug=E2=80=9D tha= t additions from early dpdk days are not well documented. (RTE_ETH_RX_OFFLOAD_SCATTER) 4. doc/guides/nics/features.rst - this file documents the feature matrix, what the feature does and how we determine if the feature is available. * Docstring patch: What is the latest status of the needed meson changes? Has Bruce provided any feedback? * Bruce said he was OK with the patch, but Juraj is not * The docs don't look as good as they probably could. * The current process generates the docs in two steps: one generates the .rst inputs for Sphinx (using the sphinx-apidoc tool), the second step then generates the actual html docs from the .rst file. * Juraj is looking into removing the sphinx-apidoc step from meson and having a semi-manual way to produce the .rst files: running the sphinx-apidoc locally the first time (or when there's a big change to file structure) and adding new files manually (which is very easy copy-paste with just a few changes). * The second approach gives us much better control over how the docs look and how we structure the pages. * Do we want to generate docs from test suites? This is likely an item for the future. * Action item: Try to generate the docs, give feedback on how it looks, give feedback on maintenance. * Blocked test case results recording: In progress, needs rebase on top of docstrings and finishing touches. * DTS Documentation from Luca. * Has been merged by Thomas now. * We might want to move around some documentation so it is more logically partitioned for readers. * Juraj is ok with the patch, but Thomas wants bigger changes. We need to agree on what we do in this patch and what in other patches. * Possibly related are these bugzilla items: 1. DTS: Split testbed and test configuration 2. DTS: Rename the execution section/stage 3. DTS Config improvements * On one more item that came up during the review: 1. DTS: add support for externally compiled DPDK =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The original DTS patches * Thomas pinged Intel people to check whether there can be a final round of DTS patches merged, or some minimal support for that repo going forward. There are some tens or hundreds of patches which were submitted after Lijuan Tu (old maintainer) left Intel, which are just languishing in the dts mailing list. * Jeremy has a patch extending timeout for DTS which he can submit, but only if there will be more merging coming up * Patrick has some patch(es) adding cx6 and cx7 NICs to old DTS. Technically our testbeds running now are forked. When setup is 100% done for both NICs, intending to circle back and add these NICs to upstream DTS if merging is a possibility. New/Open feature requests * How do we want to handle feature requests for the framework going forward? We have a lot of needed features dumped into bugzilla now (thank you Juraj), but how do we prioritize, filter through what is most important for each release? * Patrick suggests: incorporate bugzilla tickets into release roadmaps, assign them to individuals, and set action items at each DTS meeting for bugzilla tickets. https://bugs.dpdk.org/buglist.cgi?bug_status=3D__open__&component=3Ddts&pro= duct=3DDPDK * We can also run through all the tickets during meetings, and set the =E2=80=9Cimportance=E2=80=9D value for any new tickets =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 24.03 Roadmap * Can we extend this? * Should we add another ethdev suite to work on? 1. Mtu update is running in the lab currently and seems like it would be a good candidate. Only thing to consider with this suite is that the old DTS version is broken on all non-intel NICs due to a mismatched assumption about VLAN headers, so that could lead to some getting stuck in the weeds. This suite could also be done in two main ways that I can think of, either we verify that the packet was forwarded or not by checking the number of packets sent and received on the port, or we could instead just see if we get anything back on the tg side. Checking if we received a packet on the tg side would be more seamless with what we have but either way could lead to false positives. 2. Jumboframes would also be a reasonable option, the only thing to consider with this suite is one of the cases is a =E2=80=9Cdidn=E2=80=99t r= eceive anything=E2=80=9D case currently which could easily lead to both false positives if something went wrong, or false negatives with the lack of bullet-proof packet filtering. 3. Mac-filter would force us to introduce something new to the framework which is verification using the number of packets received. Could be difficult if there is any other noise on the interface. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Action Items * Jeremy Spewock will be working on https://bugs.dpdk.org/show_bug.cgi?id=3D1359 bugzilla ticket * Juraj Linke=C5=A1 will be taking this ticket: https://bugs.dpdk.org/show_bug.cgi?id=3D1365 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Any other business * What should be the deadline for DTS changes in the release cycle? DTS changes will never break DPDK functionality, but we want some reasonable buffer between changing a test and a release. * Proposal: RC2 deadline for modifying an existing test or modifying the DTS framework, RC3 for adding a new test * Please read Gregory=E2=80=99s email about writing testsuites in his =E2= =80=9Cunit test=E2=80=9D app, for the flow API, creating flow rules and how he validates for sending packets with a certain VLAN id, etc. * Packet filtering is something that has been tossed around and discussed here and there but one idea that was mentioned was just adding a few bytes to the end of every packet as a sort of =E2=80=9CDTS header=E2=80=9D that w= e could check for the presence of to ensure that the packets are relevant. * Could this cause issues with suites that require certain MTU sizes? If so it doesn=E2=80=99t seem difficult to account for when setting packet len= gths. * Are there any test suites where a packet would get sent to the SUT and in getting forwarded back these extra bytes get stripped? Is there a test case where you send one packet to the SUT and the SUT forwards multiple packets back? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Notes on gathering device capabilities: * In the short term we should move to gathering device and queue capabilities as a preliminary step for a testsuite, and execution the testsuite (or specific testcases) based on information gathered. Then we also use testpmd for configuring. --0000000000008ccc5b061040f703 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
January 31, 2024

##################################= ###################################
Attendees
* Patrick Robb
* Jur= aj Linke=C5=A1
* Paul Szczepanek
* Jeremy Spewock
* Luca Vizzarro<= br>* Thomas Monjalon

###############################################= ######################
Agenda
* Additions to the agenda
* Patch di= scussions
* DTS Developer documentation
* 24.03 roadmap

######= ###############################################################
Minutes<= br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Gener= al Announcements
* Added developers for DTS: Nick from UNH is starting o= n DTS now, and 1-2 more people from UNH will be starting on this project in= the near future.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
Patch discussions
* Dockerfile patch is updated to fix poet= ry installation and add documentation for using SSH keys.
=C2=A0 =C2=A0*= We are not going to COPY in the keys to the image from the Dockerfile. New= approach is volume mounting ~/.ssh to the container at Docker run, and rea= dme is provided explaining this process
=C2=A0 =C2=A0* Patrick Robb will= run this, add a tag on the patch, and request a merge from Thomas
* Sca= tter is submitted and has been reviewed by Juraj, looking for more reviews = from community members to get that patch moving.
=C2=A0 =C2=A0* Can have= 1 test for no offload, and 1 test for including offload
=C2=A0 =C2=A0 = =C2=A0 1. If scatter is not available, we should expect a failure in the se= cond case.
=C2=A0 =C2=A0 =C2=A0 2. Feature is underdocumented currently<= br>=C2=A0 =C2=A0 =C2=A0 3. We can add a patch adding comments documenting t= he feature. All lines in ethdev.h should be commented, so it is a =E2=80=9C= bug=E2=80=9D that additions from early dpdk days are not well documented. (= RTE_ETH_RX_OFFLOAD_SCATTER)
=C2=A0 =C2=A0 =C2=A0 4. doc/guides/nics/feat= ures.rst - this file documents the feature matrix, what the feature does an= d how we determine if the feature is available.
* Docstring patch: What = is the latest status of the needed meson changes? Has Bruce provided any fe= edback?
=C2=A0 =C2=A0* Bruce said he was OK with the patch, but Juraj is= not
=C2=A0 =C2=A0* The docs don't look as good as they probably cou= ld.
=C2=A0 =C2=A0* The current process generates the docs in two steps: = one generates the .rst inputs for Sphinx (using the sphinx-apidoc tool), th= e second step then generates the actual html docs from the .rst file.
= =C2=A0 =C2=A0* Juraj is looking into removing the sphinx-apidoc step from m= eson and having a semi-manual way to produce the .rst files: running the sp= hinx-apidoc locally the first time (or when there's a big change to fil= e structure) and adding new files manually (which is very easy copy-paste w= ith just a few changes).
=C2=A0 =C2=A0* The second approach gives us muc= h better control over how the docs look and how we structure the pages.
= =C2=A0 =C2=A0* Do we want to generate docs from test suites? This is likely= an item for the future.
=C2=A0 =C2=A0* Action item: Try to generate the= docs, give feedback on how it looks, give feedback on maintenance.
* B= locked test case results recording: In progress, needs rebase on top of doc= strings and finishing touches.
* DTS Documentation from Luca.
=C2=A0 = =C2=A0* Has been merged by Thomas now.
=C2=A0 =C2=A0* We might want to = move around some documentation so it is more logically partitioned for read= ers.
=C2=A0 =C2=A0* Juraj is ok with the patch, but Thomas wants bigger = changes. We need to agree on what we do in this patch and what in other pat= ches.
=C2=A0 =C2=A0* Possibly related are these bugzilla items:
=C2= =A0 =C2=A0 =C2=A0 1. DTS: Split testbed and test configuration
=C2=A0 = =C2=A0 =C2=A0 2. DTS: Rename the execution section/stage
=C2=A0 =C2=A0 = =C2=A0 3. DTS Config improvements
=C2=A0 =C2=A0* On one more item that c= ame up during the review:
=C2=A0 =C2=A0 =C2=A0 1. DTS: add support for e= xternally compiled DPDK

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
The original DTS patches
* Thomas pinged Intel people= to check whether there can be a final round of DTS patches merged, or some= minimal support for that repo going forward. There are some tens or hundre= ds of patches which were submitted after Lijuan Tu (old maintainer) left In= tel, which are just languishing in the dts mailing list.
=C2=A0 =C2=A0* = Jeremy has a patch extending timeout for DTS which he can submit, but only = if there will be more merging coming up
=C2=A0 =C2=A0* Patrick has some = patch(es) adding cx6 and cx7 NICs to old DTS. Technically our testbeds runn= ing now are forked. When setup is 100% done for both NICs, intending to cir= cle back and add these NICs to upstream DTS if merging is a possibility. New/Open feature requests
* How do we want to handle feature requests = for the framework going forward? We have a lot of needed features dumped in= to bugzilla now (thank you Juraj), but how do we prioritize, filter through= what is most important for each release?
=C2=A0 =C2=A0* Patrick suggest= s: incorporate bugzilla tickets into release roadmaps, assign them to indiv= iduals, and set action items at each DTS meeting for bugzilla tickets. https://bugs.dpdk.org/buglist.cgi?bug_status=3D= __open__&component=3Ddts&product=3DDPDK
=C2=A0 =C2=A0* We ca= n also run through all the tickets during meetings, and set the =E2=80=9Cim= portance=E2=80=9D value for any new tickets

=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
24.03 Roadmap
* Can we extend this?=
=C2=A0 =C2=A0* Should we add another ethdev suite to work on?
=C2= =A0 =C2=A0 =C2=A0 1. Mtu update is running in the lab currently and seems l= ike it would be a good candidate. Only thing to consider with this suite is= that the old DTS version is broken on all non-intel NICs due to a mismatch= ed assumption about VLAN headers, so that could lead to some getting stuck = in the weeds. This suite could also be done in two main ways that I can thi= nk of, either we verify that the packet was forwarded or not by checking th= e number of packets sent and received on the port, or we could instead just= see if we get anything back on the tg side. Checking if we received a pack= et on the tg side would be more seamless with what we have but either way c= ould lead to false positives.
=C2=A0 =C2=A0 =C2=A0 2. Jumboframes would = also be a reasonable option, the only thing to consider with this suite is = one of the cases is a =E2=80=9Cdidn=E2=80=99t receive anything=E2=80=9D cas= e currently which could easily lead to both false positives if something we= nt wrong, or false negatives with the lack of bullet-proof packet filtering= .
=C2=A0 =C2=A0 =C2=A0 3. Mac-filter would force us to introduce somethi= ng new to the framework which is verification using the number of packets r= eceived. Could be difficult if there is any other noise on the interface.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Action I= tems
* Jeremy Spewock will be working on https://bugs.dpdk.org/show_bug.cgi?id=3D1359 = bugzilla ticket
* Juraj Linke=C5=A1 will be taking this ticket: https://bugs.dpdk.org/sho= w_bug.cgi?id=3D1365

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
Any other business
* What should be the deadline for = DTS changes in the release cycle? DTS changes will never break DPDK functio= nality, but we want some reasonable buffer between changing a test and a re= lease.
=C2=A0 =C2=A0* Proposal: RC2 deadline for modifying an existing t= est or modifying the DTS framework, RC3 for adding a new test
* Please r= ead Gregory=E2=80=99s email about writing testsuites in his =E2=80=9Cunit t= est=E2=80=9D app, for the flow API, creating flow rules and how he validate= s for sending packets with a certain VLAN id, etc.
* Packet filtering is= something that has been tossed around and discussed here and there but one= idea that was mentioned was just adding a few bytes to the end of every pa= cket as a sort of =E2=80=9CDTS header=E2=80=9D that we could check for the = presence of to ensure that the packets are relevant.
=C2=A0 =C2=A0* Coul= d this cause issues with suites that require certain MTU sizes? If so it do= esn=E2=80=99t seem difficult to account for when setting packet lengths.=C2=A0 =C2=A0* Are there any test suites where a packet would get sent to = the SUT and in getting forwarded back these extra bytes get stripped? Is th= ere a test case where you send one packet to the SUT and the SUT forwards m= ultiple packets back?

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
Notes on gathering device capabilities:

* In the sh= ort term we should move to gathering device and queue capabilities as a pre= liminary step for a testsuite, and execution the testsuite (or specific tes= tcases) based on information gathered. Then we also use testpmd for configu= ring.
--0000000000008ccc5b061040f703--