From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 7C5D845484; Mon, 17 Jun 2024 21:58:20 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 584FA4064E; Mon, 17 Jun 2024 21:58:20 +0200 (CEST) Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) by mails.dpdk.org (Postfix) with ESMTP id EE868402DA for ; Mon, 17 Jun 2024 21:58:18 +0200 (CEST) Received: by mail-pj1-f51.google.com with SMTP id 98e67ed59e1d1-2c2f6b47621so3309007a91.1 for ; Mon, 17 Jun 2024 12:58:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1718654298; x=1719259098; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=80GVlAnaEtBP6aPJMYMxETDOmNhYQTdqTm28/Lj2Z90=; b=ebdxKTc7vzrhS45NrEhwcNPhBt7ZSJ5lXe+2cUkp77i3FtYlIupLVthEswfCfLI86U FPS+Kv1YUULcoXaoFb6FPqzJA9lpcdxlxSeHyrv38ilEDskUO2N/RCV2h7TttAIYnQAa LZOuPUnptHV/VXPHnqnFpzNOZYXJk4gU1q170= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718654298; x=1719259098; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=80GVlAnaEtBP6aPJMYMxETDOmNhYQTdqTm28/Lj2Z90=; b=MHP433nIsyJQP8TArjzV4RN9CCland7Fx6/jgGC+s6s9f/25O4dJXto7xkzofpsZbx 4JQSt9Tx4FGLfxTVpa/bLjLEtgrShXQdluUkLkcoPKgxVsEri8OArcU+F1oOZUManFBY rgwr2fiBxeznw6O0hTHgjTTCcKTkcJlgRtCvhQRYWNdDQgZ1k/ld/ojWpjcWVvUhRRGs EmS3FmvqnNAKRFrn8jfmxuZu55okFsZ05+erCzscL1/sdZpiqZ5YoZ6XiLLPxNP5lF7l o1vH8obqgj3V3LD5kKRvewS3rNaePLxCPCqetyZfMI3Z3yqrFLfuoLEjIJxS8keMyGrf jvPg== X-Forwarded-Encrypted: i=1; AJvYcCV56/eNI5VMb8Mh+FMFJ9PuEqVbVjfoRou6ZOXC1WxZgyMbJe5q3cMRkjncJUJvHfXJW1LVLi63H/iYwqI= X-Gm-Message-State: AOJu0Yx9z2GaJaqpQmWBUV7dhSj4c73ituMNToBFnG0Z2cuZzSD7itab ehdXqhBi/b4OD9/lPIT4kXKWP2b/Jq+DaE+/AeFVv4qHiPddaXsy+NDxnCL3kYg9aSEIrpuOmsY 4t5oYg0IETRk4dKusU3iVul/hFx70VelE5BIAeA== X-Google-Smtp-Source: AGHT+IE6JutK7zkt5dWItl1y+Iqt6LyZWg1eYuse8TBiD0AyLFRptp0xtHYU+LQTdRXHNEaTq4z1gMCCJhfySxOVZo4= X-Received: by 2002:a17:90a:ea09:b0:2c2:c79f:931 with SMTP id 98e67ed59e1d1-2c6c920f204mr840531a91.8.1718654297961; Mon, 17 Jun 2024 12:58:17 -0700 (PDT) MIME-Version: 1.0 References: <20240605175227.7003-1-jspewock@iol.unh.edu> <20240605175227.7003-3-jspewock@iol.unh.edu> <206dba88-bb36-4bcd-9a21-2558ee35b426@pantheon.tech> In-Reply-To: <206dba88-bb36-4bcd-9a21-2558ee35b426@pantheon.tech> From: Jeremy Spewock Date: Mon, 17 Jun 2024 15:57:56 -0400 Message-ID: Subject: Re: [RFC PATCH v1 2/2] dts: Remove XML-RPC server for Scapy TG and instead us ScapyShell To: =?UTF-8?Q?Juraj_Linke=C5=A1?= 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Tue, Jun 11, 2024 at 6:46=E2=80=AFAM Juraj Linke=C5=A1 wrote: > > > diff --git a/dts/framework/testbed_model/traffic_generator/scapy.py b/d= ts/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 functi= ons. > > > > - 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 th= e server sends the packets > > - back, they are also received as :class:`~xmlrpc.client.Binary` obj= ects on the client side, are > > - converted back to :class:`~scapy.packet.Packet` objects and only t= hen 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 functi= ons > > - 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: ScapyTrafficGeneratorCo= nfig): > > """Extend the constructor with Scapy TG specifics. > > > > - The traffic generator first starts an XML-RPC on the remote `t= g_node`. > > - Then it populates the server with functions which use the Scap= y 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 :opt= ion:`--verbose` > > - command line argument or the :envvar:`DTS_VERBOSE` environment= variable. > > + The traffic generator starts an underlying session that handle= s 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: ScapyTra= fficGeneratorConfig): > > ), "Linux is the only supported OS for scapy traffic generati= on" > > > > self.session =3D 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. >