DPDK patches and discussions
 help / color / mirror / Atom feed
From: Jeremy Spewock <jspewock@iol.unh.edu>
To: "Juraj Linkeš" <juraj.linkes@pantheon.tech>
Cc: paul.szczepanek@arm.com, Honnappa.Nagarahalli@arm.com,
	probb@iol.unh.edu,  alex.chapman@arm.com, thomas@monjalon.net,
	Luca.Vizzarro@arm.com,  npratte@iol.unh.edu,
	yoan.picchi@foss.arm.com, wathsala.vithanage@arm.com,
	 dev@dpdk.org
Subject: Re: [PATCH v2 1/1] dts: add send_packets to test suites and rework packet addressing
Date: Wed, 25 Sep 2024 12:09:31 -0400	[thread overview]
Message-ID: <CAAA20UShw9ESNUG6dj1bH6LuLj459dwHQLQsme-Q3ApQJb8jEw@mail.gmail.com> (raw)
In-Reply-To: <ae52d570-26d5-40fe-9a63-d5f882dc13a1@pantheon.tech>

On Tue, Sep 24, 2024 at 10:30 AM Juraj Linkeš
<juraj.linkes@pantheon.tech> wrote:
>
>
>
> On 20. 9. 2024 20:08, jspewock@iol.unh.edu wrote:
> > From: Jeremy Spewock <jspewock@iol.unh.edu>
> >
> > Currently the only method provided in the test suite class for sending
> > packets sends a single packet and then captures the results. There is,
> > in some cases, a need to send multiple packets at once while not really
> > needing to capture any traffic received back. The method to do this
> > exists in the traffic generator already, but this patch exposes the
> > method to test suites.
> >
>
> Patrick mentioned there is now a method that does it
> (send_packets_and_capture()), but that one captures the packets. I think
> we should add this method though, as it does something different, but
> maybe the most important point is that non-capturing TGs are going to
> support send_packets_and_capture(), so we need it either way.
>
> > This patch also updates the _adjust_addresses method of test suites so
> > that addresses of packets are only modified if the developer did not
> > configure them beforehand. This allows for developers to have more
> > control over the content of their packets when sending them through the
> > framework.
> >
>
> I think this could and should be split into two patches. They aren't
> really connected.

Sure, this makes sense. They were in the same one originally when this
was tied to the test suite I was writing it for because they were just
smaller framework updates that allowed the suite to function. Probably
didn't make much sense to keep them together then, but it makes even
less sense when the patch is standalone like this.

>
>
> > diff --git a/dts/framework/test_suite.py b/dts/framework/test_suite.py
>
> > @@ -243,41 +255,74 @@ def get_expected_packet(self, packet: Packet) -> Packet:
> >           Returns:
> >               `packet` with injected L2/L3 addresses.
> >           """
> > -        return self._adjust_addresses(packet, expected=True)
> > +        return self._adjust_addresses([packet], expected=True)[0]
> >
> > -    def _adjust_addresses(self, packet: Packet, expected: bool = False) -> Packet:
> > +    def _adjust_addresses(self, packets: list[Packet], expected: bool = False) -> list[Packet]:
> >           """L2 and L3 address additions in both directions.
> >
> > +        Packets in `packets` will be directly modified in this method. The returned list of packets
> > +        however will be copies of the modified packets in order to keep the two lists distinct.
> > +
>
> Do we need to do this? I guess you needed this in a test suite - what is
> the reason?

This is actually just me documenting something that was already
happening behind the scenes in this method that I thought would be
helpful for people to know. Right now this method ends in
`Ether(packet.build())` which essentially just copies the packet, but
it does so after the modifications were made. I think there is some
logical reason to do this which is this method is called internally in
the framework, so it allows the send methods where these packets are
used to essentially modify the list and do whatever they want to/need
to to get the packets sent and the only change that is reflected on
the user is the addresses are added.

>
> > +        Only missing addresses are added to packets, existing addresses will not be overridden. If
> > +        any packet in `packets` has multiple IP layers (using GRE, for example) only the inner-most
> > +        IP layer will have its addresses adjusted.
> > +
> >           Assumptions:
> >               Two links between SUT and TG, one link is TG -> SUT, the other SUT -> TG.
> >
> >           Args:
> > -            packet: The packet to modify.
> > +            packets: The packets to modify.
> >               expected: If :data:`True`, the direction is SUT -> TG,
> >                   otherwise the direction is TG -> SUT.
> > +
> > +        Returns:
> > +            A list containing copies of all packets in `packets` after modification.
> >           """
> > -        if expected:
> > -            # The packet enters the TG from SUT
> > -            # update l2 addresses
> > -            packet.src = self._sut_port_egress.mac_address
> > -            packet.dst = self._tg_port_ingress.mac_address
> > +        ret_packets = []
> > +        for packet in packets:
> > +            # The fields parameter of a packet does not include fields of the payload, so this can
> > +            # only be the Ether src/dst.
> > +            pkt_src_is_unset = "src" not in packet.fields
> > +            pkt_dst_is_unset = "dst" not in packet.fields
> > +            num_ip_layers = packet.layers().count(IP)
> > +
> > +            # Update the last IP layer if there are multiple to account for GRE addressing (the
>
> This comment should be more generic as it's going to apply to other
> things than just GRE.

Ack.

>
> > +            # framework should be modifying the packet address instead of the tunnel).
> > +            l3_to_use = packet.getlayer(IP, num_ip_layers)
>
> Would this make more sense inside the positive if branch right below?

Yeah, it could be defined in the positive branch. The main reason I
left it out was just because it was also used later in the method, but
the only way that part of the code is reached is if this positive
branch is hit anyway. I can update it.

>
> > +            if num_ip_layers > 0:
> > +                ip_src_is_unset = "src" not in l3_to_use.fields
> > +                ip_dst_is_unset = "dst" not in l3_to_use.fields
> > +            else:
> > +                ip_src_is_unset = None
> > +                ip_dst_is_unset = None
> >
> > -            # The packet is routed from TG egress to TG ingress
> > -            # update l3 addresses
> > -            packet.payload.src = self._tg_ip_address_egress.ip.exploded
> > -            packet.payload.dst = self._tg_ip_address_ingress.ip.exploded
> > -        else:
> > -            # The packet leaves TG towards SUT
> >               # update l2 addresses
> > -            packet.src = self._tg_port_egress.mac_address
> > -            packet.dst = self._sut_port_ingress.mac_address
> > +            # If `expected` is :data:`True`, the packet enters the TG from SUT, otherwise the
> > +            # packet leaves the TG towards the SUT
> > +            if pkt_src_is_unset:
> > +                packet.src = (
> > +                    self._sut_port_egress.mac_address
> > +                    if expected
> > +                    else self._tg_port_egress.mac_address
> > +                )
> > +            if pkt_dst_is_unset:
> > +                packet.dst = (
> > +                    self._tg_port_ingress.mac_address
> > +                    if expected
> > +                    else self._sut_port_ingress.mac_address
> > +                )
> >
> > -            # The packet is routed from TG egress to TG ingress
> >               # update l3 addresses
> > -            packet.payload.src = self._tg_ip_address_egress.ip.exploded
> > -            packet.payload.dst = self._tg_ip_address_ingress.ip.exploded
> > +            # The packet is routed from TG egress to TG ingress regardless of whether it is
> > +            # expected or not.
>
> Is this true? This might've been an error in the original
> implementation. If it's expected (that is, the returning packet), it
> should be routed from TG ingress to TG egress, no?

I guess I'm not completely sure. It would make sense that the L3
addresses should be switched as well based on either expected or not,
but currently it isn't modified, and os_udp still works which makes me
think the addresses aren't switched by the kernel interfaces, which I
believe is the only time these addresses are actually used (since we
use sendp in scapy).

>
> > +            if ip_src_is_unset:
> > +                l3_to_use.src = self._tg_ip_address_egress.ip.exploded
> > +
> > +            if ip_dst_is_unset:
> > +                l3_to_use.dst = self._tg_ip_address_ingress.ip.exploded
> > +            ret_packets.append(Ether(packet.build()))
> >
>
>

  reply	other threads:[~2024-09-25 16:09 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-04 15:28 [PATCH v1 0/1] dts: adjust packet addressing and sending jspewock
2024-09-04 15:28 ` [PATCH v1 1/1] dts: add send_packets to test suites and rework packet addressing jspewock
2024-09-09 19:43   ` Dean Marx
2024-09-12 12:35   ` Patrick Robb
2024-09-20 18:08 ` [PATCH v2 0/1] dts: adjust packet addressing and sending jspewock
2024-09-20 18:08   ` [PATCH v2 1/1] dts: add send_packets to test suites and rework packet addressing jspewock
2024-09-24 14:30     ` Juraj Linkeš
2024-09-25 16:09       ` Jeremy Spewock [this message]
2024-09-26  7:52         ` Juraj Linkeš
2024-09-26 10:13         ` Juraj Linkeš
2024-09-25 18:21 ` [PATCH v3 0/1] dts: adjust " jspewock
2024-09-25 18:21   ` [PATCH v3 1/1] dts: rework " jspewock
2024-09-26 12:30     ` Juraj Linkeš
2024-09-26 17:02       ` Jeremy Spewock
2024-09-26 18:06 ` [PATCH v4 0/1] dts: adjust " jspewock
2024-09-26 18:06   ` [PATCH v4 1/1] dts: rework " jspewock
2024-09-26 18:18 ` [PATCH v5 0/2] dts: adjust packet addressing and add send_packets to test_suite jspewock
2024-09-26 18:18   ` [PATCH v5 1/2] dts: rework packet addressing jspewock
2024-09-27  9:46     ` Juraj Linkeš
2024-09-27 11:46     ` Luca Vizzarro
2024-09-26 18:18   ` [PATCH v5 2/2] dts: add send_packets to test_suite jspewock
2024-09-27 11:46     ` Luca Vizzarro

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=CAAA20UShw9ESNUG6dj1bH6LuLj459dwHQLQsme-Q3ApQJb8jEw@mail.gmail.com \
    --to=jspewock@iol.unh.edu \
    --cc=Honnappa.Nagarahalli@arm.com \
    --cc=Luca.Vizzarro@arm.com \
    --cc=alex.chapman@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).