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 3BA0945CF7; Wed, 13 Nov 2024 14:27:13 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0B13F4025E; Wed, 13 Nov 2024 14:27:13 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id E10574021E for ; Wed, 13 Nov 2024 14:27:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1731504431; 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=K/3Yeco+Ptz9QPZd6Qyqbckuiep/Yyiaj1ZmKRl6kdk=; b=HwwC9iXpKslF6UWsMyQCHl5ngY8LKBMGyy1LoMDcN+m2+Z8Ah1coh0fwjvsAX4UqfU+RFZ JI+9wSxj29Eflgbc1C0CmKf4h/UxwpxtNZsCW4dNTu9+kW+223y1ntgQ6eyg2+A6zyn0E1 bSlnEFFH9lljjamkf5yJlIvcJ1Q/zsY= Received: from mail-lf1-f72.google.com (mail-lf1-f72.google.com [209.85.167.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-385-GYsHzp92NqCmurBjVel1mA-1; Wed, 13 Nov 2024 08:27:10 -0500 X-MC-Unique: GYsHzp92NqCmurBjVel1mA-1 X-Mimecast-MFC-AGG-ID: GYsHzp92NqCmurBjVel1mA Received: by mail-lf1-f72.google.com with SMTP id 2adb3069b0e04-539e294566dso5052517e87.3 for ; Wed, 13 Nov 2024 05:27:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731504428; x=1732109228; 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=K/3Yeco+Ptz9QPZd6Qyqbckuiep/Yyiaj1ZmKRl6kdk=; b=GO9w+W32N1KlY4OWI9laqSlcE6zAX5p4wuS/34ZbiW4IZioItkGVcK1panbxaNj5q1 BongjDo9sqsBl10zOraPwJM9TkKAzTRnZt5qOpK0FSxX18NHajF4yPB6jRqmdGwj4I/f EfMVu6DqNzoXPaHO+FWRDirFmiAR0HzS7rIdBr6077ye/sAOub0xjKRUryZNFZ++W8x5 o6Rxn7gmG50l0KAucLClgNkd9qUcBDGo8kixJAyb40EqaJPcN+xTT/ABW7ECZBXF68RS uEigH8zezBpEOi7fqIYXlucq/QmctloJ+KnmOdptIGmc3J61Bxd5kIcXHL8kfpsohOyH kLHw== X-Forwarded-Encrypted: i=1; AJvYcCVBkwPOa68t/MCoyr1iPhdNb7zHeTHMTTvnLDmOsZdPnYwX2/BFt4OH48/2Mu5lvW6+HVY=@dpdk.org X-Gm-Message-State: AOJu0YyaJjmIDJWOHJqUqh/UIC14w/esA4+LX47UtIzb/1V4wJTjifVM jH9WvivFa95dqOtjRfOQ3Yz0A3kZJE30EIJ5P2xB5eawPzTYUNOM+tHYAkY9cETx1/SmNv4Cw7O tmJPFid9Lr8cnO8/YNYIvd9C2mlU9cMGRDk8CYn+1 X-Received: by 2002:a05:6512:4017:b0:53d:a405:f14e with SMTP id 2adb3069b0e04-53da405f252mr141048e87.43.1731504428414; Wed, 13 Nov 2024 05:27:08 -0800 (PST) X-Google-Smtp-Source: AGHT+IE8Jxw/2L11DKUL9uzyEB4vmCEnCP/ay1gV6jbg2K7bZN3jpoTydULaT9jP+Ti1vf5hK+wjYA== X-Received: by 2002:a05:6512:4017:b0:53d:a405:f14e with SMTP id 2adb3069b0e04-53da405f252mr141025e87.43.1731504427958; Wed, 13 Nov 2024 05:27:07 -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-432d54f70d8sm25653495e9.16.2024.11.13.05.27.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Nov 2024 05:27:07 -0800 (PST) Mime-Version: 1.0 Date: Wed, 13 Nov 2024 14:27:06 +0100 Message-Id: Subject: Re: rte_fib network order bug From: "Robin Jarry" To: "Medvedkin, Vladimir" , User-Agent: aerc/0.18.2-101-g95b6f544c5c4 References: In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: azUZl8K3T6UKF1nrfyDcZEhSG2z_bE2JyTsgA4RCI4c_1731504429 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 Medvedkin, Vladimir, Nov 13, 2024 at 11:42: > Hi Robin, > > It should not. Here is documentation says regarding this flag: > > /** If set, fib lookup is expecting IPv4 address in network byte order */ > #define RTE_FIB_F_NETWORK_ORDER=C2=A0=C2=A0=C2=A0 1 > > As stated above lookups will be performed while expecting addresses to=20 > be in BE byte order. Control plane API expects IPv4 prefix address to be= =20 > in CPU byte order. I had not understood that it was *only* the lookups that were network=20 order. The original reason why a RTE_FIB_F_NETWORK_ORDER flag was suggested=20 some time ago is that inet_pton() always returns network order=20 addresses. It makes it much more natural to keep everything in network=20 order instead of having to swap things around. Now, only having the lookup functions requiring network order addresses=20 but all the other functions in the API requiring host order addresses is=20 even more confusing. In my opinion, when RTE_FIB_F_NETWORK_ORDER is set, *all* functions of=20 the fib API should take network order addresses. That obviously mean=20 that rib should also have a similar flag. Is that possible without a massive rework? If not, then I think we=20 should revert the patch that adds it or at least discourage its use in=20 its current state. What do you think?