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 CA1FE4589B; Thu, 29 Aug 2024 21:42:50 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 61D6F402A5; Thu, 29 Aug 2024 21:42:50 +0200 (CEST) Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.180]) by mails.dpdk.org (Postfix) with ESMTP id 19AF3402A5 for ; Thu, 29 Aug 2024 21:42:48 +0200 (CEST) Received: by mail-lj1-f180.google.com with SMTP id 38308e7fff4ca-2f3aced81ebso665721fa.2 for ; Thu, 29 Aug 2024 12:42:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1724960567; x=1725565367; darn=dpdk.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=8gpKwtj2wkLnXuzzk8fWM9rc9y8fnyAX7vLQur1mDWE=; b=aVQaU7/716uPIng49OBN1S/OY2t0nVzTDGmPLpWXdPZIao3cPhBBYJJzTZaHG0X2V7 2KWPmZU4yyWkFUfUWasBVfDf2fm1/Eg9juuQNiGRf5IcZ/RB2Nz6w7886fv1NFJV+VHx o0iAZMT7lzGKrT7OknFBRq6nsuAyUR0Ct7rIs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724960567; x=1725565367; h=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=8gpKwtj2wkLnXuzzk8fWM9rc9y8fnyAX7vLQur1mDWE=; b=UNjzUBe2iyJKHXY5lyUUFzGG+eAUxqCZPP+2hRNyU7zw4MiIognmvMBGuGydgmyVI3 HQjJ+jsft4p9cW3fuNx7AgUOJQzV0uGzUIcP51PoREOLGUshN9Gdg0yHPPlN9h0mnTIQ PQ00/PFJrV1fljPTcJA8I2zblmOSTFuvcWKzUseV2fkhxFlirjAY86tMBzzmTGb4H1Pr 5VELTpqfvlmsJt5aj5gaqKVqCWYtHky5kHyxmhNgB4t2SrTOywjeB+0l2Eiyiktxza9D 60faAzrDsPF9nj65Ero1IYTajRwcsG0TkabtJb/DMgz66g9g+/vX0k2mkvz+puil/9Vm Tq/w== X-Forwarded-Encrypted: i=1; AJvYcCV7yT8u22i284/eylzsCtoUigU6YpLvRqfaQD2VHJwA5dJGWwGGh7n1J6WBxKm1+pAAhgk=@dpdk.org X-Gm-Message-State: AOJu0YznY/yn6vEuaDVKjVieLYd255wVru8wcF1DNmIguF9lLZeg0Llc YeJacXbpmomKw/O9sVAps+a8AKPaS1KnCuXoPCE7L1oXI4ZQ99HYeO34TWXWjIh6qUr8E8bMLLi T05FvPX9jwfMhbdkK7VxT6hTHFOUJli6vEowR/w== X-Google-Smtp-Source: AGHT+IGR9o1py/sAlaclZT+btGmZvTEh5OnIG+Bdlq5E1pA7UJYLunar1wrb7PZO9lO6bCWHE0+eCwiMSh0CodoGw68= X-Received: by 2002:a05:651c:2105:b0:2f3:d032:44a9 with SMTP id 38308e7fff4ca-2f6104086a8mr14991551fa.0.1724960567270; Thu, 29 Aug 2024 12:42:47 -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: Nicholas Pratte Date: Thu, 29 Aug 2024 15:42:36 -0400 Message-ID: Subject: Re: [PATCH v3 1/4] dts: add send_packets to test suites and rework packet addressing To: Jeremy Spewock 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" 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 Hi Jeremy, sorry for the delay! See my comments below. > > > 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. > > > """ > > > - 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: > > > + default_pkt_src = type(packet)().src > > > + default_pkt_dst = 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. Makes sense to me! It's probably best to not to make the Ether assumption regardless of whether or not it will likely always be present. > > > > > > + default_pkt_payload_src = IP().src if hasattr(packet.payload, "src") else None > > > + default_pkt_payload_dst = IP().dst if hasattr(packet.payload, "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 = self._tg_ip_address_egress.ip.exploded > > > - packet.payload.dst = self._tg_ip_address_ingress.ip.exploded > > > > 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 = 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? Basically, GRE is a header that encapsulates a traditional packet. Practically speaking, this means that a scapy packet with GRE will look something like 'Ether() / IP() / GRE() / IP() / UDP() / Raw()'. If you try to modify layer 3 addresses in the way the framework does it now (packet.payload.src), and more than one IP layer is present in a given packet, it will modify the the front-most IP layer (in this case, the IP layer before the GRE layer is the packet I listed before). If there are multiple IP layers, you can choose which layer you want to modify by doing something like 'packet[IP][1] = address' to modify the inner IP layer. It is my understanding that GRE packets need to have an inner IP layer as well as an outer IP layer. Here is a quick readup on what GRE is (scroll to the bottom of the article and look at the diagram of a regular datagram vs a GRE datagram as the rest of the article isn't super important). https://ipwithease.com/generic-routing-encapsulation-gre/ -Nicholas