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 BFE25456BE; Fri, 26 Jul 2024 21:13:35 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 405CB427C7; Fri, 26 Jul 2024 21:13:35 +0200 (CEST) Received: from mail-pj1-f50.google.com (mail-pj1-f50.google.com [209.85.216.50]) by mails.dpdk.org (Postfix) with ESMTP id 280E341133 for ; Fri, 26 Jul 2024 21:13:33 +0200 (CEST) Received: by mail-pj1-f50.google.com with SMTP id 98e67ed59e1d1-2cf11b91813so939696a91.1 for ; Fri, 26 Jul 2024 12:13:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1722021212; x=1722626012; 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=316e9tMiZfTfcEHxl8cQufGrzlBdUycFqHDV+e7ZsGs=; b=Pe3Sm6iOUWK2sVVm8VEd88TaoIF4VGAHpcVJricy4wsqy1h1l8uyhuBPtnzlf6P3HJ 0lipWqbWi45yYaum+7JMa/DUnAxmir6YOImRu7Bom3cnHk7us5zWE4iw+Q0UQSZtFWhD sAQAO6cPGt6Pz4ajlyqeG1bWLr9WoudSND1v4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722021212; x=1722626012; 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=316e9tMiZfTfcEHxl8cQufGrzlBdUycFqHDV+e7ZsGs=; b=iAm0eHq97mWxgSngYiQkoqSEB1re9obS+aK4gOoHs4sBQMZ+PgYMO1lMrR442vfOGz 4Dv9yc9OJnQ08KRkUpiYnXfXa8oau/zIaXCxEOGOBZ0aZYyrX3riywYtsA6SWSWmL2Za H1NIEhiUaXgscYjlpXztZShcSxYjdYyBCT6K9hm4KnZfwHXQx2439/UEc90+GR59FFHB es/Vjvg5cCkA9Hnxt5324rGXaT+0ByM9ZW1duP9We/zhfSb2tBlXJBMGJX5QJOw96ctp zh0RmWSVm+b85GzfFuTuwQlNn2AVSb0zmOG2lYqW9o1s/nCoo6MTZXprGMdl/muls/r7 H1EQ== X-Forwarded-Encrypted: i=1; AJvYcCU5x3CnScGrPjw6NV3E+Fg6y+7gv0yHpLmJ+iLfF70NJe1DRfSKao4GtOcoMGsUeOI5zTYftb061Mdn2wE= X-Gm-Message-State: AOJu0YyaHJDw2i6wKlkmWpBXRbI6XfZsEjex89Fz3e7igG0evZ878j75 XYgO3IQ6HsihKilq/smVRUYnZmfxwBsNss5FmgcSE7utFFdIi3UVw4va7Qurph5zEGu44rgFqb4 n7fF+oMUvYpOGoZN0VX3d2k/qNgeGMMBcqrrRiQ== X-Google-Smtp-Source: AGHT+IGKSNmHd/DZ+MLzazV2iQTaobJh/5p6pClBB1ssmwnGzmWtWE6FJvepb3JP+GbMJ8nybeHF7z98yZrIbdF9jxs= X-Received: by 2002:a17:90b:3788:b0:2cb:4b88:2aaf with SMTP id 98e67ed59e1d1-2cf7e1c6776mr522287a91.12.1722021211965; Fri, 26 Jul 2024 12:13:31 -0700 (PDT) MIME-Version: 1.0 References: <20240625155332.2400-1-jspewock@iol.unh.edu> <20240724150714.226970-1-jspewock@iol.unh.edu> <20240724150714.226970-2-jspewock@iol.unh.edu> In-Reply-To: From: Jeremy Spewock Date: Fri, 26 Jul 2024 15:13:20 -0400 Message-ID: Subject: Re: [PATCH v3 1/4] dts: add send_packets to test suites and rework packet addressing To: Nicholas Pratte Cc: thomas@monjalon.net, Luca.Vizzarro@arm.com, Honnappa.Nagarahalli@arm.com, probb@iol.unh.edu, yoan.picchi@foss.arm.com, wathsala.vithanage@arm.com, juraj.linkes@pantheon.tech, paul.szczepanek@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 Thanks for the comments, I just had one clarifying question about them, but otherwise I will address them in the next version. On Fri, Jul 26, 2024 at 3:00=E2=80=AFPM Nicholas Pratte wrote: > > I'll make sure to look over the other parts of this series and leave > reviews at some point next week, but I prioritized this since I will > be using this patch at some point in my GRE suites. > > > > diff --git a/dts/framework/test_suite.py b/dts/framework/test_suite.py > > index 694b2eba65..0b678ed62d 100644 > > --- a/dts/framework/test_suite.py > > +++ b/dts/framework/test_suite.py > > @@ -199,7 +199,7 @@ def send_packet_and_capture( > > Returns: > > A list of received packets. > > """ > > - packet =3D self._adjust_addresses(packet) > > + packet =3D self._adjust_addresses([packet])[0] > > return self.tg_node.send_packet_and_capture( > > packet, > > self._tg_port_egress, > > @@ -208,6 +208,18 @@ def send_packet_and_capture( > > duration, > > ) > > > > + def send_packets( > > + self, > > + packets: list[Packet], > > + ) -> None: > > + """Send packets using the traffic generator and do not capture= received traffic. > > + > > + Args: > > + packets: Packets to send. > > + """ > > + packets =3D self._adjust_addresses(packets) > > + self.tg_node.send_packets(packets, self._tg_port_egress) > > + > > def get_expected_packet(self, packet: Packet) -> Packet: > > """Inject the proper L2/L3 addresses into `packet`. > > > > @@ -219,39 +231,59 @@ def get_expected_packet(self, packet: Packet) -> = Packet: > > """ > > return self._adjust_addresses(packet, expected=3DTrue) > > > > - def _adjust_addresses(self, packet: Packet, expected: bool =3D Fal= se) -> Packet: > > + def _adjust_addresses(self, packets: list[Packet], expected: bool = =3D False) -> list[Packet]: > > """L2 and L3 address additions in both directions. > > > > + Only missing addresses are added to packets, existing addresse= d will not be overridden. > > addressed should be addresses. Only saw this because of Chrome's > built-in grammar correction. Good catch. > > > + > > Assumptions: > > Two links between SUT and TG, one link is TG -> SUT, the o= ther 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. > > """ > > - if expected: > > - # The packet enters the TG from SUT > > - # update l2 addresses > > - packet.src =3D self._sut_port_egress.mac_address > > - packet.dst =3D self._tg_port_ingress.mac_address > > + ret_packets =3D [] > > + for packet in packets: > > + default_pkt_src =3D type(packet)().src > > + default_pkt_dst =3D type(packet)().dst > > This is really just a probing question for my sake, but what is the > difference between the solution you have above type(packet)().src and > Ether().src? Is there a preferred means of doing this? There isn't really a functional difference at all under the assumption that every packet we send will start with an Ethernet header. This obviously isn't an unreasonable assumption to make, so maybe I was reaching for flexibility that isn't really needed here by making it work with any theoretical first layer that has a source address. I wanted to do the same thing for the payload, but that causes issues when the following layer with an address isn't the very next layer after Ether. > > > + default_pkt_payload_src =3D IP().src if hasattr(packet.pay= load, "src") else None > > + default_pkt_payload_dst =3D IP().dst if hasattr(packet.pay= load, "dst") else None > > + # If `expected` is :data:`True`, the packet enters the TG = from SUT, otherwise the > > + # packet leaves the TG towards the SUT > > > > - # The packet is routed from TG egress to TG ingress > > - # update l3 addresses > > - packet.payload.src =3D self._tg_ip_address_egress.ip.explo= ded > > - packet.payload.dst =3D self._tg_ip_address_ingress.ip.expl= oded > > This is where it gets a little tricky. There will be circumstances, > albeit probably infrequently, where a user-created packet has more > than one IP layer, such as the ones I am using in the ipgre and nvgre > test suites that I am writing. In these cases, you need to specify an > index of the IP layer you want to modify, otherwise it will modify the > outermost IP layer in the packet (the IP layer outside the GRE layer. > See my previous comment for an example packet). Should be pretty easy > to fix, you just need to check if a packet contains an GRE layer, and > if it does, modify the packet by doing something like > packet[IP][1].src =3D self._tg_ip_address_egress.ip.exploded. I'm not as familiar with how GRE affects the packets, do you need to have the address on the inner IP layer at all times, or are you saying you need it on both IP layers? > > > - else: > > - # The packet leaves TG towards SUT > > # update l2 addresses > > - packet.src =3D self._tg_port_egress.mac_address > > - packet.dst =3D self._sut_port_ingress.mac_address > > You wouldn't need to make changes to how Ether addresses get allocated > if accounting for GRE as described above, since I'm pretty sure there > aren't really circumstances where packets would have more than one > Ethernet header, at least not that I've seen (GRE packets only have > one). > > > + if packet.src =3D=3D default_pkt_src: > > + packet.src =3D ( > > + self._sut_port_egress.mac_address > > + if expected > > + else self._tg_port_egress.mac_address > > + ) > > + if packet.dst =3D=3D default_pkt_dst: > > + packet.dst =3D ( > > + 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 regard= less of if it is expected or > > Maybe change 'regardless of if it is expected' to 'regardless of > whether it is expected.' It's admittedly picky of me, but I think it > reads a little bit better. Ack. > > > + # not. > > > > - # The packet is routed from TG egress to TG ingress > > # update l3 addresses > > - packet.payload.src =3D self._tg_ip_address_egress.ip.explo= ded > > - packet.payload.dst =3D self._tg_ip_address_ingress.ip.expl= oded > >