DPDK patches and discussions
 help / color / mirror / Atom feed
From: Jeremy Spewock <jspewock@iol.unh.edu>
To: Nicholas Pratte <npratte@iol.unh.edu>
Cc: Honnappa.Nagarahalli@arm.com, yoan.picchi@foss.arm.com,
	 paul.szczepanek@arm.com, juraj.linkes@pantheon.tech,
	luca.vizzarro@arm.com,  probb@iol.unh.edu, dmarx@iol.unh.edu,
	dev@dpdk.org
Subject: Re: [RFC v1 1/2] dts: add additional vlan configuration to testpmd shell class
Date: Thu, 8 Aug 2024 17:40:12 -0400	[thread overview]
Message-ID: <CAAA20UTo+Oqv4hWtZYoSokEfMazSm9xGfc2uBJtsBr-wsSrgLw@mail.gmail.com> (raw)
In-Reply-To: <20240805171246.18580-2-npratte@iol.unh.edu>

Hey Nick,

Patch looks pretty good to me, just a few minor comments below.

On Mon, Aug 5, 2024 at 1:13 PM Nicholas Pratte <npratte@iol.unh.edu> wrote:
>
> The ethertype test suite requires many different internal runtime
> vlan offload options to test ethertype configuration. The following patch
>  adds a new RxVlanOffloadOptions class that contains all the different
> vlan configuration options available within testpmd. Additionally, an
> extra method has beena added to adjust both the inner and outer tpids of

Extra "a" here at the end of "been."

> ingressing and egressing packets.
>
> Bugzilla ID: 1505
>
> Signed-off-by: Nicholas Pratte <npratte@iol.unh.edu>
> ---
<snip>
> +    def set_vlan_tpid(self, port_id: int, tpid: int, inner_id: bool) -> None:

Is this one of those things that you can't really verify from testpmd
output? That makes sense if it is, but we should probably note why
this method is different in the doc-string.

> +        """Set ethertype tpid values using the ethdev api.
> +
> +        Args:
> +            port_id: the ID of the port the tpid is being changed on.

"the" should be capitalized here.

> +            tpid: The tpid value being changed on the port.
> +            inner_id: If :data:`True`, set the inner tpid to the specified value. If
> +                :data:`False`, change the outer tpid to the specified value.
> +
> +        Raises:
> +            InteractiveCommandExecutionError: If either `port_id` or `tpid` value is invalid.
> +        """
> +        if tpid < 0 or tpid > 65535:
> +            raise InteractiveCommandExecutionError("Invalid TPID value given.")
> +        output = self.send_command(
> +            f'vlan set {"inner" if inner_id else "outer"} tpid {tpid} {port_id}'
> +        )
> +        if output.startswith("Invalid port"):
> +            raise InteractiveCommandExecutionError(f"Invalid port ID {port_id} given.")
> +
<snip>
>
> +    def set_vlan_offload_option(
> +        self, port: int, offload_option: VLANOffloadFlag, on: bool, verify: bool = True
> +    ) -> None:
> +        """Enable extended vlans on the specified port.
> +
> +        Args:
> +            port: The port number to use, should be within 0-32.
> +            on: If :data:`True`, extended vlan turn on, otherwise it turns off.
> +            offload_options: The rx vlan offload option to be set.
> +            verify: If :data:`True`, the output of the command and show port info
> +                is scanned to verify that vlan stripping was enabled on the specified port.
> +                If not, it is considered an error.
> +
> +        Raises:
> +            InteractiveCommandExecutionError: If `verify` is :data:`True` and stripping
> +                fails to update.
> +        """
> +        offload_output = self.send_command(
> +            f"vlan set {str(offload_option).lower()} {'on' if on else 'off'} {port}"

Because flags can be combinations of multiple values, this might not
work if you passed in a flag that had STRIP and FILTER turned on at
the same time, for example. I think the string version would come out
to be something like STRIP|FILTER which definitely wouldn't be what
you want. Unfortunately, I think the only way around that though is to
have conditional values for each option and then checking to see if
the flag contains that option. Something like

if VLANOffloadFlag.STRIP in options:
    self.send_command(vlan set strip on 0)

Obviously with proper string formatting. Although, another thing you
might be able to do is if you can iterate through the members of the
VLANOffloadFlag class, you could do something more like:

for offload in VLANOffloadFlag.__members__:
    if offload in options:
        self.send_command(f"vlan set {offload.name.lower()} on 0")

And that would be a shorter way that covers you for any combination of
offloads. Could be fancy and make it a one-liner too if you wanted to,
but that's up to you.

> +        )
> +        if verify:
> +            if on ^ (str(offload_option) in str(self.show_port_info(port_id=port).vlan_offload)):

Is there a reason you can't directly compare the flags? The different
possible combinations of options will all have unique values, so I
think you should just be able to do `offload_option ==
self.show_port_info(port_id=port).vlan_offload)`



> +                self._logger.debug(
> +                    f"""Failed to set {offload_option} {'on' if on else 'off'} port {port}:
> +                        \n{offload_output}
> +                    """
> +                )
> +                raise InteractiveCommandExecutionError(
> +                    f"Testpmd failed to set {offload_option} {'on' if on else 'off'} port {port}."
> +                )
> +
>      def port_stop_all(self, verify: bool = True) -> None:
>          """Stop all ports.
>
> --
> 2.44.0
>

  reply	other threads:[~2024-08-08 21:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-05 17:12 [RFC v1 0/2] dts: Ethertype ethdev api test suite Nicholas Pratte
2024-08-05 17:12 ` [RFC v1 1/2] dts: add additional vlan configuration to testpmd shell class Nicholas Pratte
2024-08-08 21:40   ` Jeremy Spewock [this message]
2024-08-05 17:12 ` [RFC v1 2/2] dts: port ethertype ethdev api test suite to new dts framework Nicholas Pratte
2024-08-08 21:40   ` Jeremy Spewock

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=CAAA20UTo+Oqv4hWtZYoSokEfMazSm9xGfc2uBJtsBr-wsSrgLw@mail.gmail.com \
    --to=jspewock@iol.unh.edu \
    --cc=Honnappa.Nagarahalli@arm.com \
    --cc=dev@dpdk.org \
    --cc=dmarx@iol.unh.edu \
    --cc=juraj.linkes@pantheon.tech \
    --cc=luca.vizzarro@arm.com \
    --cc=npratte@iol.unh.edu \
    --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).