DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Juraj Linkeš" <juraj.linkes@pantheon.tech>
To: jspewock@iol.unh.edu, Honnappa.Nagarahalli@arm.com,
	paul.szczepanek@arm.com, yoan.picchi@foss.arm.com,
	npratte@iol.unh.edu, probb@iol.unh.edu, thomas@monjalon.net,
	wathsala.vithanage@arm.com, Luca.Vizzarro@arm.com
Cc: dev@dpdk.org
Subject: Re: [PATCH v1 1/1] dts: Remove XML-RPC server for Scapy TG and instead use PythonShell
Date: Fri, 21 Jun 2024 16:14:25 +0200	[thread overview]
Message-ID: <c7667134-c4cd-4942-a2ce-5a02bde74514@pantheon.tech> (raw)
In-Reply-To: <20240620231158.12008-3-jspewock@iol.unh.edu>


> +    #: Padding to add to the start of a line for python syntax compliance.
> +    _padding: ClassVar[str] = " " * 4

We use padding in the context of packets so let's use something else 
here, such as _python_indentation.

> +
>       def __init__(self, tg_node: Node, config: ScapyTrafficGeneratorConfig):
>           """Extend the constructor with Scapy TG specifics.
>   
> -        The traffic generator first starts an XML-RPC on the remote `tg_node`.
> -        Then it populates the server with functions which use the Scapy library
> -        to send/receive traffic:
> -
> -            * :func:`scapy_send_packets_and_capture`
> -            * :func:`scapy_send_packets`
> -
> -        To enable verbose logging from the xmlrpc client, use the :option:`--verbose`
> -        command line argument or the :envvar:`DTS_VERBOSE` environment variable.
> +        Initializes both a traffic generator and an interactive shell to handle Scapy functions.

Should these be with the definite article (instead of a and an)?

> +        The interactive shell will be started on `tg_node`.
>   
>           Args:
>               tg_node: The node where the traffic generator resides.
>               config: The traffic generator's test run configuration.
>           """
> -        super().__init__(tg_node, config)
> +        CapturingTrafficGenerator.__init__(self, tg_node, config)
> +        PythonShell.__init__(self, tg_node, privileged=True)
>   

This should probably mirror the superclass order from which the class is 
subclassed - PythonShell first, then CapturingTrafficGenerator.	

I'm also thinking of using super() here, but it's a bit convoluted. We'd 
need to do something like this:

class Common:
     def __init__(self, *args, **kwargs):
         super().__init__()

class TrafficGenerator(Common):
     def __init__(self, tg_node, config, **kwargs):
         super().__init__(tg_node, **kwargs)

class InteractiveShell(Common):
     def __init__(self, node, privileged = False, timeout = 15, 
start_on_init = True, params = "", **kwargs):
         super().__init__(node, **kwargs)

This works for both mro's. The common class basically makes the two 
subclasses eligible for multiple interitance while still working with 
normal inheritance (e.g. when making an instance of regular PythonShell) 
and the super() calls in the subclasses define what they have in common.

Since we only have this one use case, it may be overkill to use super() 
instead of calling both __init__()s directly. But with super(), we 
should be able to use any traffic generator with any interactive shell. 
I don't know whether we'll need that (we can use T-Rex without an 
interactive shell, but maybe using one is superior), but it could be useful.

>           assert (
>               self._tg_node.config.os == OS.linux
>           ), "Linux is the only supported OS for scapy traffic generation"
>   
> -        self.session = PythonShell(
> -            self._tg_node, timeout=5, privileged=True, name="ScapyXMLRPCServer"
> -        )
> +    def start_application(self) -> None:
> +        """Extends :meth:`framework.remote_session.interactive_shell.start_application`.
>   
> -        # import libs in remote python console
> -        for import_statement in SCAPY_RPC_SERVER_IMPORTS:
> -            self.session.send_command(import_statement)
> +        Adds a command that imports everything from the scapy library immediately after starting

This sound as if we were adding the command to some sort of internal 
list for processing later. We can probably just say "Import everything 
... in the remote shell.". I think it would be valuable to explicitly 
say where the import happens.

> +        the shell for usage in later calls to the methods of this class.
> +        """
> +        super().start_application()
> +        self.send_command("from scapy.all import *")
>   

It's possible we should check that the import was successful or do some 
other check that Scapy is indeed present and throw an exception if it isn't.

Actually, we probably should add a smoke test that would do that - some 
basic verification of traffic generators.


  reply	other threads:[~2024-06-21 14:14 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-05 17:52 [RFC PATCH v1 0/2] dts: replace XML-RPC server jspewock
2024-06-05 17:52 ` [RFC PATCH v1 1/2] dts: Add interactive shell for managing Scapy jspewock
2024-06-11 11:12   ` Juraj Linkeš
2024-06-17 19:45     ` Jeremy Spewock
2024-06-05 17:52 ` [RFC PATCH v1 2/2] dts: Remove XML-RPC server for Scapy TG and instead us ScapyShell jspewock
2024-06-11 10:46   ` Juraj Linkeš
2024-06-17 19:57     ` Jeremy Spewock
2024-06-20 23:11 ` [PATCH v1 0/1] dts: replace XML-RPC server jspewock
2024-06-20 23:11   ` [PATCH v1 1/1] dts: Remove XML-RPC server for Scapy TG and instead use PythonShell jspewock
2024-06-21 14:14     ` Juraj Linkeš [this message]
2024-06-24 20:54       ` Jeremy Spewock
2024-06-25 21:11 ` [PATCH v2 0/1] dts: replace XML-RPC server jspewock
2024-06-25 21:11   ` [PATCH v2 1/1] dts: Remove XML-RPC server for Scapy TG and instead use PythonShell jspewock

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=c7667134-c4cd-4942-a2ce-5a02bde74514@pantheon.tech \
    --to=juraj.linkes@pantheon.tech \
    --cc=Honnappa.Nagarahalli@arm.com \
    --cc=Luca.Vizzarro@arm.com \
    --cc=dev@dpdk.org \
    --cc=jspewock@iol.unh.edu \
    --cc=npratte@iol.unh.edu \
    --cc=paul.szczepanek@arm.com \
    --cc=probb@iol.unh.edu \
    --cc=thomas@monjalon.net \
    --cc=wathsala.vithanage@arm.com \
    --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).