Re: [PATCH v3 1/3] Added VLAN commands to testpmd_shell class

[Patrick Robb <probb@iol.unh.edu>]

On Fri, Jun 14, 2024 at 11:03 AM Dean Marx <dmarx@iol.unh.edu> wrote:
> +    def vlan_filter_set_on(self, port: int = 0, verify: bool = True):
> +        """Set vlan filter on.
> +
> +        Args:
> +            port: The port number to use, should be within 0-32.
> +            verify: If :data:`True`, the output of the command is scanned to verify that
> +                vlan filtering was enabled successfully. If not, it is
> +                considered an error.
> +
> +        Raises:
> +            InteractiveCommandExecutionError: If `verify` is :data:`True` and the filter
> +                fails to update.
> +        """
> +        filter_cmd_output = self.send_command(f"vlan set filter on {port}")

I wonder whether, when convenient, we want to name the methods more or
less 1:1 according to the actual testpmd text command they send? I.e.
in this case should the method be named vlan_set_filter_on instead of
vlan_filter_set_on (aligns better with "vlan set filter on {port}")?
The intellisense provided by the testpmd methods is indeed a QoL
improvement for folks writing testsuites, but at the same time people
who use testpmd will always have the real commands ingrained in their
thoughts, so if we try to stay as true to those as possible, we get
the stability and intellisense and also the method names are still
intuitive.

Maybe even think tiny things like renaming the method set_forward_mode
to set_fwd_mode to align 1:1 with testpmd is good.

That's just my perspective though - I would be interested to see
whether others feel the same or not.

> +        if verify:
> +            if "Invalid port" in filter_cmd_output:
> +                self._logger.debug(f"Failed to enable vlan filter: \n{filter_cmd_output}")
> +                raise InteractiveCommandExecutionError("Testpmd failed to enable vlan filter.")
> +
> +    def vlan_filter_set_off(self, port: int = 0, verify: bool = True):
> +        """Set vlan filter off.
> +
> +        Args:
> +            port: The port number to use, should be within 0-32.
> +            verify: If :data:`True`, the output of the command is scanned to verify that
> +                vlan filtering was disabled successfully. If not, it is
> +                considered an error.
> +
> +        Raises:
> +            InteractiveCommandExecutionError: If `verify` is :data:`True` and the filter
> +                fails to update.
> +        """
> +        filter_cmd_output = self.send_command(f"vlan set filter off {port}")
> +        if verify:
> +            if "Invalid port" in filter_cmd_output:
> +                self._logger.debug(f"Failed to disable vlan filter: \n{filter_cmd_output}")
> +                raise InteractiveCommandExecutionError("Testpmd failed to disable vlan filter.")
> +
> +    def rx_vlan_add(self, vlan: int = 0, port: int = 0, verify: bool = True):
> +        """Add specified vlan tag to the filter list on a port.
> +
> +        Args:
> +            vlan: The vlan tag to add, should be within 1-4094.

Worth clarifying that 4094 is the extended vlan range? Normal range is 1-1005?

> +
> +    def port_stop_all(self):
> +        """Stop all ports."""
> +        self.send_command("port stop all")

So the idea is to have distinct port_stop_all() and port_stop(self,
port: int) methods? I think this is reasonable.

> +
> +    def port_start_all(self):
> +        """Start all ports."""
> +        self.send_command("port start all")
> +
> +    def tx_vlan_set(self, port: int = 0, vlan: int = 0, verify: bool = True):
> +        """Set hardware insertion of vlan tags in packets sent on a port.
> +
> +        Args:
> +            port: The port number to use, should be within 0-32.
> +            vlan: The vlan tag to insert, should be within 1-4094.
> +            verify: If :data:`True`, the output of the command is scanned to verify that
> +                vlan insertion was enabled on the specified port. If not, it is
> +                considered an error.
> +
> +        Raises:
> +            InteractiveCommandExecutionError: If `verify` is :data:`True` and the filter
> +                fails to update.
> +        """
> +        vlan_insert_output = self.send_command(f"tx_vlan set {port} {vlan}")
> +        if verify:
> +            if ("Please stop port" in vlan_insert_output or "Invalid vlan_id" in vlan_insert_output
> +            or "Invalid port" in vlan_insert_output):
> +                self._logger.debug(f"Failed to set vlan insertion tag: \n{vlan_insert_output}")
> +                raise InteractiveCommandExecutionError("Testpmd failed to set vlan insertion tag.")
> +
> +    def tx_vlan_reset(self, port: int = 0, verify: bool = True):
> +        """Disable hardware insertion of vlan tags in packets sent on a port.
> +
> +        Args:
> +            port: The port number to use, should be within 0-32.
> +            verify: If :data:`True`, the output of the command is scanned to verify that
> +                vlan insertion was disabled on the specified port. If not, it is
> +                considered an error.
> +
> +        Raises:
> +            InteractiveCommandExecutionError: If `verify` is :data:`True` and the filter
> +                fails to update.
> +        """
> +        vlan_insert_output = self.send_command(f"tx_vlan set {port}")
> +        if verify:
> +            if "Please stop port" in vlan_insert_output or "Invalid port" in vlan_insert_output:
> +                self._logger.debug(f"Failed to reset vlan insertion: \n{vlan_insert_output}")
> +                raise InteractiveCommandExecutionError("Testpmd failed to reset vlan insertion.")

Could possibly be combined with tx_vlan_set() as one method which
handles both set and reset, but I think splitting them out is fine.

> +
>      def close(self) -> None:
>          """Overrides :meth:`~.interactive_shell.close`."""
>          self.send_command("quit", "")
> --
> 2.44.0
>