From: Jeremy Spewock <jspewock@iol.unh.edu>
To: "Juraj Linkeš" <juraj.linkes@pantheon.tech>
Cc: Luca.Vizzarro@arm.com, probb@iol.unh.edu, npratte@iol.unh.edu,
paul.szczepanek@arm.com, yoan.picchi@foss.arm.com,
thomas@monjalon.net, wathsala.vithanage@arm.com,
Honnappa.Nagarahalli@arm.com, dev@dpdk.org
Subject: Re: [RFC PATCH v1 2/2] dts: Remove XML-RPC server for Scapy TG and instead us ScapyShell
Date: Mon, 17 Jun 2024 15:57:56 -0400 [thread overview]
Message-ID: <CAAA20USv=NPLtus9Mj6omhe17gR6NpWGmOz1k10Yy92SBq6vqA@mail.gmail.com> (raw)
In-Reply-To: <206dba88-bb36-4bcd-9a21-2558ee35b426@pantheon.tech>
On Tue, Jun 11, 2024 at 6:46 AM Juraj Linkeš <juraj.linkes@pantheon.tech> wrote:
>
> > diff --git a/dts/framework/testbed_model/traffic_generator/scapy.py b/dts/framework/testbed_model/traffic_generator/scapy.py
> > index 5676235119..2b299ad02f 100644
> > --- a/dts/framework/testbed_model/traffic_generator/scapy.py
> > +++ b/dts/framework/testbed_model/traffic_generator/scapy.py
>
> >
> > class ScapyTrafficGenerator(CapturingTrafficGenerator):
> > - """Provides access to scapy functions via an RPC interface.
> > + """Provides access to scapy functions on a traffic generator.
> >
>
> traffic generator node
Ack.
>
> > This class extends the base with remote execution of scapy functions.
> >
> > - Any packets sent to the remote server are first converted to bytes. They are received as
> > - :class:`~xmlrpc.client.Binary` objects on the server side. When the server sends the packets
> > - back, they are also received as :class:`~xmlrpc.client.Binary` objects on the client side, are
> > - converted back to :class:`~scapy.packet.Packet` objects and only then returned from the methods.
> > + All processing of packets is handled via an instance of a
> > + :class:`framework.remote_session.scapy_shell.ScapyShell` that runs on the underlying
> > + :class:`framework.testbed_model.tg_node.TGNode`.
> >
>
> The module docstring should also be updated.
Oops, good catch.
>
> > Attributes:
> > session: The exclusive interactive remote session created by the Scapy
> > - traffic generator where the XML-RPC server runs.
> > - rpc_server_proxy: The object used by clients to execute functions
> > - on the XML-RPC server.
> > + traffic generator.
> > """
> >
> > - session: PythonShell
> > - rpc_server_proxy: xmlrpc.client.ServerProxy
> > + session: ScapyShell
> > _config: ScapyTrafficGeneratorConfig
> >
> > 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.
> > + The traffic generator starts an underlying session that handles scapy interactions
> > + that it will use in its provided methods.
> >
>
> I'm not sure what you're trying to say here - that the methods the tg
> exposes are using the scapy session?
Yeah, that is exactly what I was trying to say, just that the TG
creates a PythonShell and that's what it uses to interact with scapy
when you call it basically.
>
> > Args:
> > tg_node: The node where the traffic generator resides.
> > @@ -262,50 +62,11 @@ def __init__(self, tg_node: Node, config: ScapyTrafficGeneratorConfig):
> > ), "Linux is the only supported OS for scapy traffic generation"
> >
> > self.session = self._tg_node.create_interactive_shell(
>
> Looks like in this specific case, we could do this with multiple
> inheritance instead of composition.
>
> Composition is needed in the other use cases, since we use different
> objects based on the config (e.g. Linux or Windows session). Here, we're
> always going to use the same object (ScapyShell).
>
> The code would need to be refactored to achieve multiple inheritance
> (the __init__ methods would probably have to accept extra kwargs) and
> Luca's testpmd params patch would help a lot, as that looks at least
> somewhat suitable.
>
> I don't know how well would multiple inheritance work, if at all, but
> it's worth trying so that we don't have to basically copy-paste the same
> method signature over and over (e.g. _send_packets and send_packets in
> ScapyTrafficGenerator and ScapyShell).
I like this idea. Multiple inheritance is something that I haven't
used much myself but I agree that creating wrapper methods over and
over for the methods that I want to use is very unintuitive. I'll try
it and see how far I can get with it.
>
next prev parent reply other threads:[~2024-06-17 19:58 UTC|newest]
Thread overview: 30+ 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 [this message]
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š
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
2024-09-12 4:00 ` Patrick Robb
2024-09-19 19:02 ` [PATCH v3 0/1] dts: replace XML-RPC server jspewock
2024-09-19 19:02 ` [PATCH v3 1/1] dts: Remove XML-RPC server for Scapy TG and instead use PythonShell jspewock
2024-09-24 10:55 ` Juraj Linkeš
2024-09-24 16:34 ` Jeremy Spewock
2024-09-25 7:49 ` Juraj Linkeš
2024-09-25 17:37 ` [PATCH v4 0/1] dts: replace XML-RPC server jspewock
2024-09-25 17:37 ` [PATCH v4 1/1] dts: Remove XML-RPC server for Scapy TG and instead use PythonShell jspewock
2024-09-26 9:12 ` Juraj Linkeš
2024-09-26 14:54 ` Jeremy Spewock
2024-09-27 9:35 ` Juraj Linkeš
2024-09-26 14:55 ` Jeremy Spewock
2024-09-26 16:50 ` [PATCH v5 0/1] dts: replace XML-RPC server jspewock
2024-09-26 16:50 ` [PATCH v5 1/1] dts: use PythonShell for Scapy instead of XML-RPC jspewock
2024-09-27 9:42 ` Juraj Linkeš
2024-09-27 11:47 ` Luca Vizzarro
2024-09-30 13:41 ` Juraj Linkeš
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='CAAA20USv=NPLtus9Mj6omhe17gR6NpWGmOz1k10Yy92SBq6vqA@mail.gmail.com' \
--to=jspewock@iol.unh.edu \
--cc=Honnappa.Nagarahalli@arm.com \
--cc=Luca.Vizzarro@arm.com \
--cc=dev@dpdk.org \
--cc=juraj.linkes@pantheon.tech \
--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).