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 940C445AEB; Fri, 11 Oct 2024 19:02:21 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2093F402A3; Fri, 11 Oct 2024 19:02:21 +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 E74DC4028B for ; Fri, 11 Oct 2024 19:02:18 +0200 (CEST) Received: by mail-pj1-f50.google.com with SMTP id 98e67ed59e1d1-2e18293a5efso1614602a91.3 for ; Fri, 11 Oct 2024 10:02:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1728666138; x=1729270938; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=wfMN3Q0Vs7RV3bhFdOqYm1wyWfEQBEU/AWut8sC9LSA=; b=QA3efA1vPKHCWjIFQntlR56QIacEhFXzYdho6xKa7w/obDH0G4tdgb3se04FoQhkSf WSGJeUMJ80dMgNVps+aiUDpg3pAXKjsjnK9DgHoBk2lctNty8yN8H4wV6skXoPKRMfIY AS6XAFzRu6INCZKl8EWxk42H21Amn4jJVkxJU11C2K6It8D9Vv31kS2Lc591OfjK5Isl nilSQn6k0nN5iikHT9P34Udxwqvn9MB3utKFgS4OnmOmd6w7ZM1LpSk2OzUe/S02jX4k WQK+5DcQjctApC2W+reAJ9k5RKMMPlZUF3PMnzKOzJI+ZQyzxsNXGnolEQsLKoAjfBJE 39FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728666138; x=1729270938; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=wfMN3Q0Vs7RV3bhFdOqYm1wyWfEQBEU/AWut8sC9LSA=; b=RBu6RezB6XMuFzaLQcbsFEUTHrxGeOjuxfdMujUcWqxpJ4R/i75lqkSCSniXobGnWG tlvcIer3ngX4oT6IP6NgoAcrPwe4tCj1qc83T9zj6oUjIlea0QlSPt1iNX64BKBLVbZ4 gH9GtUN0kH+Q1UIDCKPTgEZ4xU4iPzKLFSBy3wukXeyIYQO3nxvQnQHN5KBf/QFk00an BiMVUyPh2TROnb94dfcO5BbmXo3PV22KfDJZZ+RzJR8e/CBJJvTkhCksflMbVMK56L6o GlIzhUXiUyL4DoMJVMXkYXrXXOETTIaGB6fmAizfGfKWm7eOB+LmUxbQ4R7ogZ7cNKBP YHmQ== X-Forwarded-Encrypted: i=1; AJvYcCWJhE56gXnCglGl2iNPG1cC9S61R+NA8y3gF1TwiW5fA/196YNu/J9Fmk8zpY9H3rtDD8U=@dpdk.org X-Gm-Message-State: AOJu0YwU87JhdYplqBJxJuJqu+JW+3fXSphy4C6xjqbfftO5Z59A6kO8 aA6bvqgWN3x0+K71N+sC3WRjly/v3XtLThOVlKNFDk2W4waw8UdKb0PaU5OW1ZY= X-Google-Smtp-Source: AGHT+IESPTTCbJ8gA+CrXC1gs9XD6ETTwvL1QrNGWZdF7Fv9Pvz/sHcV2IIkXJ9EaVWboGHgHg6SMg== X-Received: by 2002:a17:90a:db8a:b0:2e2:d61d:60e6 with SMTP id 98e67ed59e1d1-2e2f0aa3dccmr4359139a91.17.1728666137801; Fri, 11 Oct 2024 10:02:17 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2e2ac10385dsm5541322a91.24.2024.10.11.10.02.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Oct 2024 10:02:17 -0700 (PDT) Date: Fri, 11 Oct 2024 10:02:15 -0700 From: Stephen Hemminger To: Morten =?UTF-8?B?QnLDuHJ1cA==?= Cc: "Robin Jarry" , "Wathsala Vithanage" , "Min Zhou" , "David Christensen" , "Stanislaw Kardach" , , , , "Vipin Varghese" Subject: Re: [PATCH dpdk v2 03/16] net: add structure for ipv6 addresses Message-ID: <20241011100215.4c4b4833@hermes.local> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F7C0@smartserver.smartshare.dk> References: <20240821162516.610624-17-rjarry@redhat.com> <20241001081728.301272-1-rjarry@redhat.com> <20241001081728.301272-4-rjarry@redhat.com> <98CBD80474FA8B44BF855DF32C47DC35E9F77B@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35E9F7C0@smartserver.smartshare.dk> MIME-Version: 1.0 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 Fri, 11 Oct 2024 14:37:35 +0200 Morten Br=C3=B8rup wrote: > > From: Robin Jarry [mailto:rjarry@redhat.com] > > Sent: Thursday, 10 October 2024 22.08 > >=20 > > Morten Br=C3=B8rup, Oct 06, 2024 at 10:18: =20 > > > This has been discussed before, but I want to double check... > > > > > > If - sometime in the future - we want to add a union to offer a 2- =20 > > byte =20 > > > access variant and make the structure to 2-byte aligned (which is the > > > common case in Ethernet packets), it will break both API and ABI. =20 > > This =20 > > > seems unlikely to get accepted at a later time, so I think we are > > > - right now - in a situation where it's now or never: > > > > > > struct rte_ipv6_addr { > > > __extension__ > > > union { > > > unsigned char a[RTE_IPV6_ADDR_SIZE]; > > > uint16_t w[RTE_IPV6_ADDR_SIZE / 2]; > > > }; > > > }; > > > > > > Unless some of the CPU folks want the 2-byte aligned variant, stick > > > with what you offered. =20 > >=20 > > I was also thinking the same. I could have added an unnamed union which > > only contains one field. > >=20 > > However, it does not make much sense if we never want to change the > > default alignment. > >=20 > > Important note: DPDK is compiled with the following C flags: > >=20 > > -Wno-address-of-packed-member > >=20 > > Added in 2017 https://git.dpdk.org/dpdk/commit/?id=3D95cd37070af44 > >=20 > > If we had struct rte_ipv6_addr aligned on 2 bytes (or more), > > applications that do not silence that warning would have a hard time. > > Example in grout: > >=20 > > ../modules/ip6/datapath/ip6_input.c:99:54: error: taking address of > > packed member of =E2=80=98struct rte_ipv6_hdr=E2=80=99 may result in an= unaligned > > pointer value [-Werror=3Daddress-of-packed-member] > > 99 | nh =3D ip6_route_lookup(iface->vrf_id, &ip- =20 > > >dst_addr); =20 > > | > > ^~~~~~~~~~~~~ =20 >=20 > I don't understand the choice of packing for these types... >=20 > Why are the IPv4 [ipv4h] and IPv6 header [ipv6h] types packed? Is it so t= hey can be stored on unaligned addresses? >=20 > E.g. the IPv4 header's natural alignment is 4 byte (due to the rte_be32_t= src_addr, dst_addr fields). The IPv4 header is most often 2 byte aligned, = being located after an Ethernet header. >=20 > Maybe they should be 2-byte aligned, like the Ethernet address type [etha= ] and the Ethernet header type [ethh]. >=20 > The VLAN tag type [vlanh] is packed. Why? >=20 > I wonder if the compiler would spit out the same warnings if the above ty= pes were __rte_aligned(2) instead of __rte_packed. I am in the never use packed camp for network headers. The Linux, BSD and g= libc headers avoid use of packed. Windows seems to love using it.