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 3A52845D13; Fri, 15 Nov 2024 17:52:13 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1C29C402BB; Fri, 15 Nov 2024 17:52:13 +0100 (CET) Received: from mail-pg1-f173.google.com (mail-pg1-f173.google.com [209.85.215.173]) by mails.dpdk.org (Postfix) with ESMTP id 0B52C402A7 for ; Fri, 15 Nov 2024 17:52:12 +0100 (CET) Received: by mail-pg1-f173.google.com with SMTP id 41be03b00d2f7-7ea8c4ce232so1897331a12.0 for ; Fri, 15 Nov 2024 08:52:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1731689531; x=1732294331; 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=PUpMpz07wXRgChHVvC8VPX2FEd/KFHHKBVFhJxjIHW4=; b=zpOD/DOCY+DCQM8FwbnmLS2zvFs7nP0sSWKUHkQ33StEMMWf+tUhUprRC6ndXJApTI cvIs8MkpexjiSlwCbZVPKmawpx9QsTxhO8DWxCICvBye8zP7N1Iu19tSUKaS0E+ZaXil 9Y1GDtC4L2WEqyj0UUbWmdyzxMMXe18RjaXCSF7hqjryLQP/Xxxso4DXcbPObad71mi4 ZNaYRWQbi6C1ow8/gBaL7hdSuIKA6ThCRpYAtFkGDZR4qMskLk+FbuuWAz+aUu2GY1LY UHH9WZD2vxZdmQjRNE/Cihyl5vVqL5jy5RlMIFx9V6x5/gOGncUwEJUuVU72WDK4UCrk CuDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731689531; x=1732294331; 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=PUpMpz07wXRgChHVvC8VPX2FEd/KFHHKBVFhJxjIHW4=; b=hnZHsQOsnjlUKqQHyFYalsgOm3qsMWbUNQF28UCd3gX4TBJdP0GwWuLr3xzUBV+CE5 zAt4xOxnIOgo7hT2UuU5+EuN9C/oUr9loilQl0arSb/vXTnThcyAoKVmt8E77Cm1F0zo UI3kYgAxbcKjBkSWKL+EJICUn4Ia93l+zDhPCEBRFZvVPWWVzxEHuna3UFy9R7C+Wb05 19AEYFOZ0bR7khPZ1eWZVeb6FPS8T9apXlURatVP1zNkUxHnTdRT8quyBvjG+eaahwu3 SadJnRwxW5ZPspBuREZ6vUGOJaf7gmyu3cH23lm1RvtoM3pb0WqnqQWaeR9D2soIRlF8 ya8A== X-Forwarded-Encrypted: i=1; AJvYcCVIdsu0G8L0XqH4p5jYkjc7j0Nq6N4Udk3Q3Rl0r8NBe19CPxGleDMxMOMHGVIO3LHmfOE=@dpdk.org X-Gm-Message-State: AOJu0Yw19MMJtXLOx561ESshkZaVM6Thy3cwIpiQBmVtca1r2SLzjLWu S52oxXnRkMv/KE+/G8ph2ZQZAhV1wPrhFm+K7xY79IftVBTgCpbNRi7S11Zy9U4= X-Google-Smtp-Source: AGHT+IHKCTbFuc+rz5w4Q1slAMNTJc9Fzk8/KGqoQcXmMjzWHKcnySmEgFfsZ5K0tVsNHV8ITWdfuQ== X-Received: by 2002:a05:6a20:3946:b0:1db:ed17:dd7e with SMTP id adf61e73a8af0-1dc90b24435mr4010791637.16.1731689530941; Fri, 15 Nov 2024 08:52:10 -0800 (PST) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-724771c0ac2sm1604293b3a.100.2024.11.15.08.52.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Nov 2024 08:52:10 -0800 (PST) Date: Fri, 15 Nov 2024 08:20:51 -0800 From: Stephen Hemminger To: "Robin Jarry" Cc: Morten =?UTF-8?B?QnLDuHJ1cA==?= , "Medvedkin, Vladimir" , Subject: Re: rte_fib network order bug Message-ID: <20241115082046.46af52d5@hermes.local> In-Reply-To: References: <98CBD80474FA8B44BF855DF32C47DC35E9F8CB@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35E9F8CC@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35E9F8CD@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, 15 Nov 2024 15:28:33 +0100 "Robin Jarry" wrote: > Morten Br=C3=B8rup, Nov 15, 2024 at 14:52: > > Robin, you've totally won me over on this endian discussion. :-) > > Especially the IPv6 comparison make it clear why IPv4 should also be=20 > > network byte order. > > > > API/ABI stability is a pain... we're stuck with host endian IPv4=20 > > addresses; e.g. for the RTE_IPV4() macro, which I now agree produces=20 > > the wrong endian value (on little endian CPUs). =20 >=20 > At least for 24.11 it is too late. But maybe we could make it right for=20 > the next LTS? >=20 > >> Vladimir, could we at least consider adding a real network order mode= =20 > >> for the rib and fib libraries? So that we can have consistent APIs=20 > >> between IPv4 and IPv6? =20 > > > > And/or rename RTE_FIB_F_NETWORK_ORDER to=20 > > RTE_FIB_F_NETWORK_ORDER_LOOKUP or similar. This is important if real=20 > > network order mode is added (now or later)! =20 >=20 > Maybe we could revert that patch and defer a complete change of the=20 > rib/fib APIs to only expose network order addresses? It would be an ABI=20 > breakage but if properly announced in advance, it should be possible. >=20 > Thinking about it some more. Having a flag for such a drastic change in=20 > behaviour does not seem right. It was a mistake for DPDK to define its own data structures for IP addresse= s. Would have been much better to stick with the legacy what BSD, Linux (and W= indows) uses in API. 'struct in_addr' and 'struct in6_addr' Reinvention did not help users.