From: Jeremy Spewock <jspewock@iol.unh.edu>
To: Dean Marx <dmarx@iol.unh.edu>
Cc: Honnappa.Nagarahalli@arm.com, juraj.linkes@pantheon.tech,
probb@iol.unh.edu, paul.szczepanek@arm.com,
yoan.picchi@foss.arm.com, bruce.richardson@intel.com,
luca.vizzarro@arm.com, dev@dpdk.org
Subject: Re: [PATCH v3 2/3] Initial implementation for VLAN test suite
Date: Mon, 17 Jun 2024 10:56:36 -0400 [thread overview]
Message-ID: <CAAA20UTSSNB-t-ty+qpWJaz_hRJ1JX9HtM_kP_utnbynpPB0zw@mail.gmail.com> (raw)
In-Reply-To: <20240614150238.26374-3-dmarx@iol.unh.edu>
On Fri, Jun 14, 2024 at 11:03 AM Dean Marx <dmarx@iol.unh.edu> wrote:
>
> Test suite for ensuring Poll Mode Driver can enable or disable
> vlan filtering, stripping, and header insertion of packets sent on
> a port.
>
> Signed-off-by: Dean Marx <dmarx@iol.unh.edu>
> ---
<snip>
> +
> +class TestVlan(TestSuite):
> + """DPDK VLAN test suite.
> +
> + Ensures VLAN packet reception on the Poll Mode Driver when certain conditions are met.
> + If one or more of these conditions are not met, the packet reception should be unsuccessful.
> + """
> +
> + def set_up_suite(self) -> None:
> + """Set up the test suite.
> +
> + Setup:
> + Create a testpmd session and set up tg nodes
This isn't part of the setup of this suite, so you can probably leave
this sentence out.
> + verify that at least two ports are open for session
> + """
> + self.verify(len(self._port_links) > 1, "Not enough ports")
> +
> + def send_vlan_packet_and_verify(
> + self, should_receive: bool = True, strip: bool = False, vlan_id: int = -1
> + ) -> None:
I'm not sure it makes sense to default these parameters either. If we
never use the default value of -1 for vlan_id, then we might as well
make the argument positional instead of a keyword argument.
> + """Generate a vlan packet, send and verify on the dut.
> +
Maybe you could add some more description about what is being verified
in this method to the body of doc-string just to make things more
clear.
> + Args:
> + should_receive: indicate whether the packet should be successfully received
> + vlan_id: expected vlan ID
> + strip: indicates whether stripping is on or off,
> + and when the vlan tag is checked for a match
All of the individual arg definitions should end with periods and
start with capitalized words (the descriptions should be capitalized,
not the variable names). Additionally, the second line of the `strip`
description should be indented just to show it's a continuation line.
You can probably fit some more of this continuation on the line on the
one above as well if that's easier.
> + """
> + data = "P" * 10
> + packet = Ether() / Dot1Q(vlan=vlan_id) / Raw(load=data)
> + received_packets = self.send_packet_and_capture(packet)
> + received_packets = [
> + packets
> + for packets in received_packets
> + if hasattr(packets, "load") and data in str((packets.load))
> + ]
This might be easier to do with the built-in `filter` function in python:
list(filter(lambda p: hasattr(p, "load") and data in str(p.load),
received_packets))
Although what you have now is also intuitive and does the same thing
so it doesn't really matter either way.
> + if should_receive:
> + self.verify(
> + len(received_packets) == 1, "Packet was dropped when it should have been received"
> + )
<snip>
+
> + def send_packet_and_verify_insertion(self, expected_id: int = -1) -> None:
This also uses an invalid ID but I think you could just make this
positional/required instead.
> + """Generate a packet with no vlan tag, send and verify on the dut.
> +
> + Args:
> + expected_id: the vlan id that is being inserted through tx_offload configuration
> + should_receive: indicate whether the packet should be successfully received
Same comment here about the args.
> + """
> + data = "P" * 10
> + packet = Ether() / Raw(load=data)
> + received_packets = self.send_packet_and_capture(packet)
> + received_packets = [
> + packets
> + for packets in received_packets
> + if hasattr(packets, "load") and data in str((packets.load))
> + ]
The start of this method is almost exactly the same as the start of
the one for sending a VLAN packet. Maybe a different approach could be
sending the packets in the test method, and then making this method
instead just take in a list of packets and verifying them. Or, maybe
you could instead make a different method for sending packets, and
pass what that method returns into this one. Just to make sure there
is as little duplicated code as possible.
> + self.verify(
> + len(received_packets) == 1, "Packet was dropped when it should have been received"
> + )
> + received = received_packets[0]
> + self.verify(Dot1Q in received, "The received packet did not have a vlan tag")
> + self.verify(received.vlan == expected_id, "The received tag did not match the expected tag")
> +
> + def test_vlan_receipt_no_stripping(self) -> None:
> + """Ensure vlan packet is dropped when receipts are enabled and header stripping is disabled.
> +
> + Test:
> + Create an interactive testpmd shell and verify a vlan packet.
> + """
> + testpmd = self.sut_node.create_interactive_shell(TestPmdShell, privileged=True)
> + testpmd.set_forward_mode(TestPmdForwardingModes.mac)
> + testpmd.send_command("set verbose 1", "testpmd>")
> + testpmd.send_command("set promisc 0 off", "testpmd>")
I saw Patrick also mentioned this, but I agree, we shouldn't need to
be calling the send_command method anywhere. Maybe what we should do
just to make sure people don't use it is override the method in
TestpmdShell so that it throws an exception. That way we would enforce
the rule a little more and it'd be less confusing.
> + testpmd.vlan_filter_set_on(0)
This is also the default value for this method, so if we were going to
keep the defaults, this parameter would not be needed. However, we
still should probably make those arguments positional and leave this
as is.
> + testpmd.rx_vlan_add(1, 0)
This could also be testpmd.rx_vlan_add(1) with the defaults I believe,
but that would be more ambiguous.
> + testpmd.start()
> +
> + filtered_vlan = 1
It might make more sense to define this variable above the call to
testpmd.rx_vlan_add and pass it into that function call as well. That
way it isn't hard-coded in some places and used as this variable in
others.
> + self.send_vlan_packet_and_verify(True, vlan_id=filtered_vlan)
> + testpmd.close()
> +
> + def test_vlan_receipt_stripping(self) -> None:
> + """Ensure vlan packet received with no tag when receipts and header stripping are enabled.
> +
> + Test:
> + Create an interactive testpmd shell and verify a vlan packet.
> + """
> + testpmd = self.sut_node.create_interactive_shell(TestPmdShell, privileged=True)
> + testpmd.set_forward_mode(TestPmdForwardingModes.mac)
> + testpmd.send_command("set verbose 1", "testpmd>")
> + testpmd.send_command("set promisc 0 off", "testpmd>")
> + testpmd.vlan_filter_set_on(0)
> + testpmd.rx_vlan_add(1, 0)
This part of the test method is identical to
test_vlan_receipt_no_stripping, we could instead make one method for
testing called vlan_receipt_testing(self, stripping: bool) and then
set the vlan stripping to on if the boolean is true.
> + testpmd.vlan_strip_set_on(0)
> + testpmd.start()
> +
> + self.send_vlan_packet_and_verify(should_receive=True, strip=True, vlan_id=1)
> + testpmd.close()
> +
> + def test_vlan_no_receipt(self) -> None:
> + """Ensure vlan packet dropped when filter is on and sent tag not in the filter list.
> +
> + Test:
> + Create an interactive testpmd shell and verify a vlan packet.
> + """
> + testpmd = self.sut_node.create_interactive_shell(TestPmdShell, privileged=True)
> + testpmd.set_forward_mode(TestPmdForwardingModes.mac)
> + testpmd.send_command("set verbose 1", "testpmd>")
> + testpmd.send_command("set promisc 0 off", "testpmd>")
> + testpmd.vlan_filter_set_on(0)
> + testpmd.rx_vlan_add(1, 0)
> + testpmd.start()
> +
> + filtered_vlan = 1
This code is also identical to what is in
test_vlan_receipt_no_stripping. Maybe in that additional test method
you could also add a parameter for should_receive: bool and use that
to decide what to pass into the send_vlan_pacet_and_verify function:
def vlan_receipt_testig(self, stripping: bool, should_receive: bool)
^ As opposed to what I mentioned above with the vlan_receipt_testing function.
> + self.send_vlan_packet_and_verify(should_receive=False, vlan_id=filtered_vlan + 1)
> + testpmd.close()
<snip>
> + def tear_down_suite(self) -> None:
> + """Tear down the suite."""
This method declaration isn't needed since we don't require any tear
down steps to actually clean up after the test suite.
> --
> 2.44.0
>
next prev parent reply other threads:[~2024-06-17 14:57 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-11 16:15 [PATCH v2 0/2] " Dean Marx
2024-06-11 16:15 ` [PATCH v2 1/2] Initial implementation for " Dean Marx
2024-06-11 16:15 ` [PATCH v2 2/2] conf schema Dean Marx
2024-06-14 15:02 ` [PATCH v3 0/3] VLAN Test Suite Dean Marx
2024-06-14 15:02 ` [PATCH v3 1/3] Added VLAN commands to testpmd_shell class Dean Marx
2024-06-14 15:59 ` Patrick Robb
2024-06-14 20:29 ` Jeremy Spewock
2024-06-14 21:24 ` Patrick Robb
2024-06-17 14:37 ` Jeremy Spewock
2024-06-14 15:02 ` [PATCH v3 2/3] Initial implementation for VLAN test suite Dean Marx
2024-06-14 16:19 ` Patrick Robb
2024-06-17 14:56 ` Jeremy Spewock [this message]
2024-06-14 15:02 ` [PATCH v3 3/3] Config schema Dean Marx
2024-06-17 14:59 ` Jeremy Spewock
2024-06-17 14:35 ` [PATCH v3 0/3] VLAN Test Suite Jeremy Spewock
2024-06-17 17:50 ` Patrick Robb
2024-06-18 15:20 ` [PATCH v4 1/3] dts: refactored VLAN test suite Dean Marx
2024-06-18 15:20 ` [PATCH v4 2/3] dts: updated testpmd shell class Dean Marx
2024-06-18 15:20 ` [PATCH v4 3/3] dts: config schema Dean Marx
2024-06-18 16:29 ` [PATCH v5 1/3] dts: updated testpmd shell class Dean Marx
2024-06-18 16:29 ` [PATCH v5 2/3] dts: refactored VLAN test suite Dean Marx
2024-06-21 20:53 ` Jeremy Spewock
2024-06-18 16:29 ` [PATCH v5 3/3] dts: config schema Dean Marx
2024-06-21 20:53 ` Jeremy Spewock
2024-06-21 20:50 ` [PATCH v5 1/3] dts: updated testpmd shell class Jeremy Spewock
2024-06-24 18:17 ` [PATCH v6 " Dean Marx
2024-06-24 18:17 ` [PATCH v6 2/3] dts: refactored VLAN test suite Dean Marx
2024-06-24 18:17 ` [PATCH v6 3/3] dts: config schema Dean Marx
2024-06-25 15:33 ` [PATCH v7 1/3] dts: VLAN test suite implementation Dean Marx
2024-06-25 15:33 ` [PATCH v7 2/3] dts: add VLAN methods to testpmd shell Dean Marx
2024-06-26 18:22 ` Jeremy Spewock
2024-06-25 15:33 ` [PATCH v7 3/3] dts: config schema Dean Marx
2024-06-26 18:23 ` Jeremy Spewock
2024-06-26 18:21 ` [PATCH v7 1/3] dts: VLAN test suite implementation Jeremy Spewock
2024-06-28 14:00 ` [PATCH v8 1/3] dts: add VLAN methods to testpmd shell Dean Marx
2024-06-28 14:00 ` [PATCH v8 2/3] dts: VLAN test suite implementation Dean Marx
2024-07-01 19:52 ` Jeremy Spewock
2024-06-28 14:00 ` [PATCH v8 3/3] dts: config schema Dean Marx
2024-07-01 19:48 ` [PATCH v8 1/3] dts: add VLAN methods to testpmd shell Jeremy Spewock
2024-07-03 16:47 ` [PATCH v9 1/3] dts: config schema Dean Marx
2024-07-03 16:47 ` [PATCH v9 2/3] dts: VLAN test suite implementation Dean Marx
2024-07-03 16:47 ` [PATCH v9 3/3] dts: add VLAN methods to testpmd shell Dean Marx
2024-07-09 21:22 ` Jeremy Spewock
2024-07-03 16:50 ` [PATCH v10 1/3] " Dean Marx
2024-07-03 16:50 ` [PATCH v10 2/3] dts: VLAN test suite implementation Dean Marx
2024-07-09 21:22 ` Jeremy Spewock
2024-07-03 16:50 ` [PATCH v10 3/3] dts: config schema Dean Marx
2024-07-05 15:55 ` Patrick Robb
2024-07-10 15:38 ` Jeremy Spewock
2024-07-17 20:31 ` [PATCH v11 1/3] dts: add VLAN methods to testpmd shell Dean Marx
2024-07-17 20:31 ` [PATCH v11 2/3] dts: VLAN test suite implementation Dean Marx
2024-07-19 15:35 ` Jeremy Spewock
2024-07-17 20:31 ` [PATCH v11 3/3] dts: config schema Dean Marx
2024-07-19 15:35 ` Jeremy Spewock
2024-07-19 15:35 ` [PATCH v11 1/3] dts: add VLAN methods to testpmd shell Jeremy Spewock
2024-07-24 16:30 ` [PATCH v12 0/3] dts: refactored VLAN test suite Dean Marx
2024-07-24 16:30 ` [PATCH v12 1/3] dts: add VLAN methods to testpmd shell Dean Marx
2024-07-24 16:30 ` [PATCH v12 2/3] dts: VLAN test suite implementation Dean Marx
2024-07-24 16:30 ` [PATCH v12 3/3] dts: config schema Dean Marx
2024-08-07 19:43 ` [PATCH v13 0/2] dts: refactored VLAN test suite Dean Marx
2024-08-07 19:43 ` [PATCH v13 1/2] dts: add VLAN methods to testpmd shell Dean Marx
2024-08-09 17:23 ` Jeremy Spewock
2024-08-07 19:43 ` [PATCH v13 2/2] dts: VLAN test suite implementation Dean Marx
2024-08-09 17:23 ` Jeremy Spewock
2024-08-23 21:16 ` [PATCH v14 0/2] dts: port over VLAN test suite Dean Marx
2024-08-23 21:16 ` [PATCH v14 1/2] dts: add VLAN methods to testpmd shell Dean Marx
2024-09-04 19:49 ` Jeremy Spewock
2024-08-23 21:16 ` [PATCH v14 2/2] dts: VLAN test suite implementation Dean Marx
2024-09-04 19:49 ` Jeremy Spewock
2024-09-11 17:43 ` [PATCH v14 0/1] dts: port over VLAN test suite Dean Marx
2024-09-11 17:43 ` [PATCH v14 1/1] dts: VLAN test suite implementation Dean Marx
2024-09-18 20:38 ` [PATCH v15 0/1] dts: port over VLAN test suite Dean Marx
2024-09-18 20:38 ` [PATCH v15 1/1] dts: VLAN test suite implementation Dean Marx
2024-09-18 20:49 ` [PATCH v15 0/1] dts: port over VLAN test suite Dean Marx
2024-09-18 20:49 ` [PATCH v15] dts: VLAN test suite implementation Dean Marx
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=CAAA20UTSSNB-t-ty+qpWJaz_hRJ1JX9HtM_kP_utnbynpPB0zw@mail.gmail.com \
--to=jspewock@iol.unh.edu \
--cc=Honnappa.Nagarahalli@arm.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=dmarx@iol.unh.edu \
--cc=juraj.linkes@pantheon.tech \
--cc=luca.vizzarro@arm.com \
--cc=paul.szczepanek@arm.com \
--cc=probb@iol.unh.edu \
--cc=yoan.picchi@foss.arm.com \
/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).