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 9672245D13; Fri, 15 Nov 2024 15:28:40 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3077D42FF3; Fri, 15 Nov 2024 15:28:40 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 46D5642FE5 for ; Fri, 15 Nov 2024 15:28:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1731680917; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=YU/2BSIm6i2eq52uYPcu3+r8TW66gaaki5lkzp+WkhY=; b=fIoRkBSWxKqpaOtmFDKXymz7MVG9/Npwb+taAROe7YU2q3Yiov/Yu3rQxyPKJUp/zU9whZ s3TjnDz+Mwc+iRJhU9oC79C2Ps92Y7A+MxNvti3ZmJLotbJcvCpf5Wi+S5fdQmYXujHe/D M8KuYQigiDTzXr4exM/Ior3Ez5x+v5w= Received: from mail-lf1-f69.google.com (mail-lf1-f69.google.com [209.85.167.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-594-wv8ccpsNOuSCgNGMfSCrbw-1; Fri, 15 Nov 2024 09:28:36 -0500 X-MC-Unique: wv8ccpsNOuSCgNGMfSCrbw-1 X-Mimecast-MFC-AGG-ID: wv8ccpsNOuSCgNGMfSCrbw Received: by mail-lf1-f69.google.com with SMTP id 2adb3069b0e04-539ec1a590fso1574971e87.0 for ; Fri, 15 Nov 2024 06:28:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731680915; x=1732285715; h=in-reply-to:references:user-agent:to:from:subject:message-id:date :content-transfer-encoding:mime-version:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=YU/2BSIm6i2eq52uYPcu3+r8TW66gaaki5lkzp+WkhY=; b=CRn4ijM4bUjZ+XB/bVG7zGyxJnINnBt14v7R6gXrlzZjHroJvApk/jyaSJ6rHeCHCD HPK212gAXu9cjVf436VOo9aMJDFu/CYnZL71Vxbhw0QmOMvkDXqsNYk0KJqQI07+IBVH FXLqyhZ/4QvtG+ZxvNUkUJOF+mtwE3hKZYsydVE6ffTHjHTPiEiaRl+7+X4xX3563XDS op6yBkqlREHDOe+pjWf6g2GeVsOWp+X999t0SCuLj1i+XVSKVgPVt08G1Y1ANfYiRs/T ZHu8aCu1D/RpUGuDkRsDxNLPrAgK2Gl7FDb2zMtVMLAADrX52oKIVdNGzBACopT1vSRh LbMA== X-Forwarded-Encrypted: i=1; AJvYcCVfBoAhoohaAG2hchSym1C3zlBzEiSsE1bQ7Xt1Wbg1yF18CSf6wXIHpBMvxTeI/w/wzpo=@dpdk.org X-Gm-Message-State: AOJu0YwWjoLUsZkuHqoWJvy3YlcJciPU3qVDLIY1hPwyOyap9ApWLq2O +19WpXHemzCHzzysOkOSq/qZu1bIRpQS3YZu2JCQDxbH3cftXTmlZz03mojrE0Yl69MB8cXu6aY a6DbWgkTkkEcMN5MgYFpH6lFIItSzVe7eJxkljCLG X-Received: by 2002:a05:6512:130b:b0:53d:a34d:9faa with SMTP id 2adb3069b0e04-53dab3b0808mr1625978e87.45.1731680914853; Fri, 15 Nov 2024 06:28:34 -0800 (PST) X-Google-Smtp-Source: AGHT+IF+95wwDe/jh2d5TZLscRscGkAvdU3YCkheIhRrKea8vR2uby/B67EbFOH33IhMbjpYMgMXNA== X-Received: by 2002:a05:6512:130b:b0:53d:a34d:9faa with SMTP id 2adb3069b0e04-53dab3b0808mr1625961e87.45.1731680914333; Fri, 15 Nov 2024 06:28:34 -0800 (PST) Received: from localhost (2a01cb00025433006239e1f47a0b2371.ipv6.abo.wanadoo.fr. [2a01:cb00:254:3300:6239:e1f4:7a0b:2371]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-432da28cb89sm58534245e9.34.2024.11.15.06.28.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 15 Nov 2024 06:28:33 -0800 (PST) Mime-Version: 1.0 Date: Fri, 15 Nov 2024 15:28:33 +0100 Message-Id: Subject: Re: rte_fib network order bug From: "Robin Jarry" To: =?utf-8?q?Morten_Br=C3=B8rup?= , "Medvedkin, Vladimir" , User-Agent: aerc/0.18.2-101-g95b6f544c5c4 References: <98CBD80474FA8B44BF855DF32C47DC35E9F8CB@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35E9F8CC@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35E9F8CD@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F8CD@smartserver.smartshare.dk> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: -b5yaliqZwbADQe7dDnT4Sewy6dqiIkMMDaBRN8ffNs_1731680915 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8; format=Flowed 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 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). At least for 24.11 it is too late. But maybe we could make it right for=20 the next LTS? >> 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? > > 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)! 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. Thinking about it some more. Having a flag for such a drastic change in=20 behaviour does not seem right. >> On that same topic, I wonder if it would make sense to change the API=20 >> parameters to use an opaque rte_ipv4_addr_t type instead of a native=20 >> uint32_t to avoid any confusion. > > It could be considered an IPv4 address type (like the IPv6 address=20 > type) (which should be in network endian), which it is not, so I don't=20 > like this idea. > > What the API really should offer is a choice (or a union) of uint32_t=20 > and rte_be32_t, but that's not possible, so also using uint32_t for=20 > big endian values seems like a viable compromise. > > Another alternative, using void* for the IPv4 address array, seems=20 > overkill to me, since compilers don't warn about mixing uint32_t with=20 > rte_be32_t values (like mixing signed and unsigned emits warnings). If what I proposed above is possible, then all these APIs could be using=20 rte_be32_t values (or even better, an rte_ipv4_addr_t alias for=20 consistency with IPv6). That would make everything much simpler. Thoughts?