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 4620645D7C; Fri, 22 Nov 2024 17:14:42 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 12D07402CE; Fri, 22 Nov 2024 17:14:42 +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 E6F30402C3 for ; Fri, 22 Nov 2024 17:14:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1732292080; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4SQB7f+zcgqk+mhd4xUK6Wr5i39If8qcPeLf6oD3HIc=; b=evLh6PdBqwHTFL6ca8vnG6hm6D6S0O3W76Zugkq+zIqfq79ZHpV3gR1keVLNKqtFnmSmJc 8rPQ3F/yJ7p/xtdeMGDnjUcAEeTrrCjDWVZynVLuq/ptq26QtLlgw/+5mZPI+VxzK7wXeU OoDz3PnxHgQP04lUCuzgnJTzL9y8kL0= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-140-EXn2iLxDORObya_37AJBlA-1; Fri, 22 Nov 2024 11:14:39 -0500 X-MC-Unique: EXn2iLxDORObya_37AJBlA-1 X-Mimecast-MFC-AGG-ID: EXn2iLxDORObya_37AJBlA Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-4315ad4938fso15601305e9.0 for ; Fri, 22 Nov 2024 08:14:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732292078; x=1732896878; h=in-reply-to:references:user-agent:subject:to:from:cc:message-id :date:content-transfer-encoding:mime-version:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=4SQB7f+zcgqk+mhd4xUK6Wr5i39If8qcPeLf6oD3HIc=; b=bGON4Pk7hsWudc7EmFYJgVKmhxC2FhK3cyQQRxtZtVEHdMrH9bxRqm9vtiG1fGBpAz rIfwrEGhWy9ZDFZosBwhOeu3GpO5atAm3K2+M6brTqRUkNHaKC92/B1P0tYnoxiaZTb6 xnrNMZ0/DvbCWVSF+IqulAcOLxMRAeyIh2dMn7bvDw5wlbRvcZthaICx+k584Si0BECP mKAKMAZZkQg3KDhFh9rkf7vUd09XTeFNrDJpG41C3mJ7aXi9FBU06/b/Op3GGKiwVfaH ehkq3W8PodGIeoFPMmviZVYR+ZfA3NUMog416gFHs3fe1fp8Z+21EMTC4MqyiKybYVMP bEJQ== X-Forwarded-Encrypted: i=1; AJvYcCUgkIZyMg7CjOfbMzVDtPNonSxCVgvzdTvgmaKkta5Ynmg1nv+HlFPv672JCC8uzLBaiAs=@dpdk.org X-Gm-Message-State: AOJu0Yzv1ycHgZVrwIg985Wf7OHiMNiqG4m/63oY9e/4wrHGztClNWKr +uaeImjpkLZjWhN/AE8VUAmmbd0/x37OZq1aMuIhbNlsMVDloXMQYkLajjmBLSARCqV54/mISv3 Pp380Ytbb3g66Gv9So8caldfWYMonAeb/7WFlvzRo X-Gm-Gg: ASbGncu0qcX10APe8nqEGFf+F1fP7f0jb+LeVpQ91i1ZERLqcU8MaQ253+eBR8IFRe7 txixi13nA09Ufc5PxmbzBcGOpWZbmlQX5Pwpsd/E0p8MOaa+gLiP7Jqvy48pw26PNtUozOKRVMp eys3MVmvRlymaUJcPT4tGyHx41Ymie+JbXRHqlSs8lMjwRqCIfV8pQ/8FYxzgp5sCFlYtQ2DsjK 4ADAPIqeyeDtzEn8aFe6aNJPsHY+jZ2LjI2LBcF+gOAVf1Iq4h/eed3g4YlUjXixH9uAR6myFEZ fuuPzcy1bVNp1TDyIUZAS4cJW+Pa1/3G X-Received: by 2002:a05:600c:154f:b0:42f:80f4:ab31 with SMTP id 5b1f17b1804b1-433ce43561dmr31289285e9.18.1732292078005; Fri, 22 Nov 2024 08:14:38 -0800 (PST) X-Google-Smtp-Source: AGHT+IGoZBEwfMLnLygfoouXI5//Z4uL8QLHZSdluI9SJWwGWD7yflH5CjiJpSIhfo3zW2oWacqtgQ== X-Received: by 2002:a05:600c:154f:b0:42f:80f4:ab31 with SMTP id 5b1f17b1804b1-433ce43561dmr31288975e9.18.1732292077601; Fri, 22 Nov 2024 08:14:37 -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-3825fbc3a76sm2831450f8f.83.2024.11.22.08.14.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 22 Nov 2024 08:14:37 -0800 (PST) Mime-Version: 1.0 Date: Fri, 22 Nov 2024 17:14:36 +0100 Message-Id: Cc: =?utf-8?q?Morten_Br=C3=B8rup?= , "Medvedkin, Vladimir" , , "Bruce Richardson" , "David Marchand" , "Thomas Monjalon" , "Konstantin Ananyev" From: "Robin Jarry" To: "Vladimir Medvedkin" , "Stephen Hemminger" Subject: Re: rte_fib network order bug User-Agent: aerc/0.18.2-104-gae6ebb03d2df References: <98CBD80474FA8B44BF855DF32C47DC35E9F8CB@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35E9F8CC@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35E9F8CD@smartserver.smartshare.dk> <20241115082046.46af52d5@hermes.local> In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 3PHQ013bCXXKPKOME4VcdXfPopdYNYJ_If1Kqxd3gUk_1732292078 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 Vladimir Medvedkin, Nov 17, 2024 at 16:04: > [Robin] >> I had not understood that it was *only* the lookups that were network=20 >> order > > [Morten] >> When I saw the byte order flag the first time, it was not clear to me=20 >> either that it only affected lookups - I too thought it covered the=20 >> entire API of the library. This needs to be emphasized in the=20 >> description of the flag. And the flag's name should contain LOOKUP=20 >> [Morten] > And/or rename RTE_FIB_F_NETWORK_ORDER to=20 >> RTE_FIB_F_NETWORK_ORDER_LOOKUP or similar. > > There is a clear comment for this flag that it has effects on lookup.=20 > Repeating the statement with an exclamation mark seems too much.=20 > Moreover, at first this flag was named "RTE_FIB_FLAG_LOOKUP_BE" and it=20 > was suggested for renaming here:=20 > https://inbox.dpdk.org/dev/D4SWPKOPRD5Z.87YIET3Y4AW@redhat.com/ This is my bad then. I had misunderstood what this flag was for.=20 I should have been more careful. You had clearly stated that it was only=20 affecting the lookup. > So, feel free to submit patches adding this feature to the control=20 > plane API, but let's consider: I can commit to working on that topic if we can get a consensus. In my=20 opinion there are two different approaches: 1) Change all IPv4 routing *APIs* to only use network order addresses =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This would make them consistent with all networking stacks (linux, vpp,=20 bsd, etc.) and would avoid confusion from users (like me) who naively=20 used these libraries with addresses generated with inet_pton() or=20 addresses taken verbatim from IPv4 packet headers. More importantly, it would make them consistent on big-endian and=20 little-endian architectures. Currently, the same code could work=20 (without any byte swap) on aarch4, but would not work on x86_64. It would also make them consistent with their IPv6 counterparts which do=20 not require any byteswap. This would be a drastic and breaking change but I think this would be=20 the better solution in the long run. To ensure that potential users of these libraries will not miss this=20 change, the uint32_t parameters should be changed to a rte_ipv4_addr structure that follows the same idea than rte_ipv6_addr. We could also simply use rte_be32_t types everywhere but it would expose=20 potential users of these APIs with bugs that could not be found at=20 compilation. Internally, all these routing libraries would continue using host order=20 integers, the changes I am suggesting only affect the public API. 2) Implement network order via opt-in flags =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This would allow the same thing as solution 1) but would keep the=20 default behaviour which I find confusing and inconsistent with IPv6 and=20 with all IPv4 networking stacks that I know. The other concern I have with that second solution is that the public=20 APIs would continue using uint32_t parameters which would be only=20 correct when the network-order mode is not enabled. On the other hand, it does not break any API for users that do not use=20 the flags. There would need to be an additional RTE_IPV4_BE() macro to declare IPv4=20 addresses in network order. Any thoughts?