test suite reviews and discussions
 help / color / mirror / Atom feed
From: bugzilla@dpdk.org
To: dts@dpdk.org
Subject: [DTS/framework Bug 1438] Add additional packet checking functionality into DTS TestSuite
Date: Tue, 07 May 2024 14:43:11 +0000	[thread overview]
Message-ID: <bug-1438-433@http.bugs.dpdk.org/> (raw)

[-- Attachment #1: Type: text/plain, Size: 1976 bytes --]

https://bugs.dpdk.org/show_bug.cgi?id=1438

            Bug ID: 1438
           Summary: Add additional packet checking functionality into DTS
                    TestSuite
           Product: DTS
           Version: unspecified
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: minor
          Priority: Normal
         Component: framework
          Assignee: dts@dpdk.org
          Reporter: npratte@iol.unh.edu
  Target Milestone: ---

I think a discussion should be made around introducing extra functionality into
the TestSuite object within DTS. Old DTS, in numerous test suites, will
explicitly insert a payload into a frame; some test suites may even analyse the
contents within the frame to ensure that the specified payload was received
properly. A good example of this being the case in new DTS is the jumboframes
suite I am working on. Implementation of packet verification can be done in two
way: Assessing both layers two and three in all received packets to verify the
expected packet was received, or alternatively, dissecting and inspecting the
payload of each received packet and validating the user's previously defined
payload in within one of these received packets. For those that prefer the
latter, it might make sense to introduce a method that automatically does this
and introduce some kind of "default" payload in each packet if the user leaves
it unspecified. A potential benefit of this might be that we could create some
sort of "filter" method that, when called by the user, will return a list of
packets that contain a defined payload as a parameter, effectively getting rid
of all the the junk packets the test suite doesn't care about. In any case, I
think a good concern could be raised about why this sort of filtering is not
currently implemented in the framework currently.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #2: Type: text/html, Size: 3866 bytes --]

             reply	other threads:[~2024-05-07 14:43 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-07 14:43 bugzilla [this message]
2024-05-07 14:43 ` bugzilla

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-1438-433@http.bugs.dpdk.org/ \
    --to=bugzilla@dpdk.org \
    --cc=dts@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).