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 16A6645D13; Fri, 15 Nov 2024 14:02:04 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DC46E402A9; Fri, 15 Nov 2024 14:02:03 +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 258F540285 for ; Fri, 15 Nov 2024 14:02:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1731675721; 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=WSJyRPmvM2tcLvkziA90r5eokyY3UnT2DB0IbQ4g0DU=; b=LDnC8uI2w1ruY+hfGURsK1pcEqA9MBDNoYWderCkK5TNrV0dk/8pZRZfCiuul+fWNo7jLF Ij3U11F9V9cb//ATPyAuo6BHg0BKEbN8vFkfdGgyG6MS181tMF5opMfVwTQsE/w8DUFaeh gH0RNQblEIDjoQvDAYMOYCKfrpCaT4I= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-650-dYnismrGMhSOnayeBfe6gQ-1; Fri, 15 Nov 2024 08:01:59 -0500 X-MC-Unique: dYnismrGMhSOnayeBfe6gQ-1 X-Mimecast-MFC-AGG-ID: dYnismrGMhSOnayeBfe6gQ Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-432d9bb0f19so10822005e9.1 for ; Fri, 15 Nov 2024 05:01:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731675718; x=1732280518; 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=WSJyRPmvM2tcLvkziA90r5eokyY3UnT2DB0IbQ4g0DU=; b=QUoYn8jRJJzjGmfn+Vzr2EhwqFOHlGCkH5plZOyUtw/laBgXZIC++Lyc5PucCKAvTh LoMHK31iQeGRNC2veEoZOwoFZ3ZFpX9GoPdanE8MKac00RyylKpf6uDSPdHJYcK+FDbi kjA6RzRPcVRWsLgQtwM8LmACzFg5QvpJMRpUyNnsX1hxtzvd7pabv7Slx6z//5pFZiCk bHTDmOG6A5Xn2CPSjDAs0FmMRiPxpG15zpUBNlsUPwIF3BMTEPrER3MR/CkC2VaEvw94 cB9FN0pYUubFN9jFozw0tY1MhWPKyX5aOqdBdCJ5aR7DVf6VpxnuwrPGlQIwakK3kRQJ jUvQ== X-Forwarded-Encrypted: i=1; AJvYcCXNUpFVDZOgS8/aPOepAheGr/M9ScyWK6790ViiUl6aHEZHWkhyJr6KWDFxxGLREWQ+byQ=@dpdk.org X-Gm-Message-State: AOJu0YwcQHe6XIRwVbtPKOGwm+cljQPboDwRxlinVaL2ksV767Dhu64c UIprMm8hjO74kfMaHtu9Fyb7FDoD4m/aO7ypBZ6DMklPbWyJraoQT0/0brjqgCrS4v8/FANJeks 9j2vhGu5/Zzh9ZKoEJeISPm7cP119b8NB1XFIira5R1fNowjb X-Received: by 2002:a5d:64ae:0:b0:376:dbb5:10c2 with SMTP id ffacd0b85a97d-38224fd1243mr2399526f8f.29.1731675717669; Fri, 15 Nov 2024 05:01:57 -0800 (PST) X-Google-Smtp-Source: AGHT+IEqQp3GwvkxeS0rlr3wZzKf6tDsx4GiFfFSruBeN4X+lGGEut/AKo9Rogw7nTb4zWtZKCpJiA== X-Received: by 2002:a5d:64ae:0:b0:376:dbb5:10c2 with SMTP id ffacd0b85a97d-38224fd1243mr2399467f8f.29.1731675717122; Fri, 15 Nov 2024 05:01:57 -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 ffacd0b85a97d-3821adad3dcsm4263156f8f.31.2024.11.15.05.01.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 15 Nov 2024 05:01:56 -0800 (PST) Mime-Version: 1.0 Date: Fri, 15 Nov 2024 14:01:56 +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> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F8CC@smartserver.smartshare.dk> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: Twee7Oc_7m5iSXyqB_qYlatjp3kUY68Pgb3GFRQuRKI_1731675718 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 14, 2024 at 15:35: >> RTE_IPV4 is only useful to define addresses in unit tests. > > There are plenty of special IP addresses and subnets, where a shortcut=20 > macro makes the address easier readable in the code. OK, let me reformulate. I didn't mean to say that RTE_IPV4 is useless.=20 But it will always generate addresses in *host order*. Which means they=20 cannot be used in IPv4 headers without passing them through htonl(). This is weird in my opinion. >> Why would control plane use a different representation of addresses >> compared to data plane? > > Excellent question. > Old habit? Growing up using big endian CPUs, we have come to think of=20 > IPv4 addresses as 32 bit numbers, so we keep treating them as such.=20 > With this old way of thinking, the only reason to use network endian=20 > in the fast path with little endian CPUs is for performance reasons=20 > (to save the byte swap) - if not, we would still prefer using host=20 > endian in the fast path too. I understand the implementation reasons why you would prefer working=20 with host order integers. But the APIs that deal with IPv4 addresses=20 should not reflect implementation details. >> Also for consistency with IPv6, I really think >> that *all* addresses should be dealt in their network form. > > Food for thought! 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? 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. Thanks!