From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9DB1645D03; Thu, 14 Nov 2024 11:18:41 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6771C42E6B; Thu, 14 Nov 2024 11:18:41 +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 D987D40E45 for <dev@dpdk.org>; Thu, 14 Nov 2024 11:18:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1731579519; 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=/jxivoikxaClhpDmJ08eENyVlbRDBfzxvUKzqIuz154=; b=M/UfkjEt1a7IQIXNYBozGBp2tvNEv5xDfdZVf+Vvu1Ssgbsbq7/Np9TruGYNZncoVg/7SS 5c7lmvJcnZhN8wNuL95qPpSkR3VJJen00u6+1YelAvRjPS6KdSNiOml+h/OFz2WjsjxFXY 0qQ0u3MQfI78JUkdUv/bvf7QkMf9J60= Received: from mail-lj1-f200.google.com (mail-lj1-f200.google.com [209.85.208.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-354-3a5ueQTuN_m2MIefHa5c3A-1; Thu, 14 Nov 2024 05:18:37 -0500 X-MC-Unique: 3a5ueQTuN_m2MIefHa5c3A-1 X-Mimecast-MFC-AGG-ID: 3a5ueQTuN_m2MIefHa5c3A Received: by mail-lj1-f200.google.com with SMTP id 38308e7fff4ca-2fb5035169dso3994821fa.3 for <dev@dpdk.org>; Thu, 14 Nov 2024 02:18:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731579516; x=1732184316; 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=/jxivoikxaClhpDmJ08eENyVlbRDBfzxvUKzqIuz154=; b=eLwQDbftw9CrX363aNB0H1T5QVXOUAy+Huqx2C77bdASelMgkS4lCoQR1owkbqSY6L KKOKlY0ZhRt4QAsEWnOJvoen2K8+u2QJxzQ541kBiLkHirEPQ6ZQyI3t7kWVTz9s7bGh vmUrlWKem3yyTgn6frVZ25LXH16iA327MRCi4jiw16k3JMRIbat1PY4el6UPEJwrqxET /FGD+IwxENtbRL3TSoH87EwOwOcPMtdI2T/GXfwpxZYHK/ZkCIUa6vxNKMglZ9dDOacn r3x6QDytpWIL8ZiAtbL1Azyeniq2/+VA3o57h9mHIHOL63w/kuzawYosjbaz9xsFNi75 Jvpw== X-Forwarded-Encrypted: i=1; AJvYcCU1TnfsM/GdtaprziBaNnjorRCh1zQDQtd7TN0gPpx9bV49UblN5xutrmJpeQH7mxxXXVk=@dpdk.org X-Gm-Message-State: AOJu0YwDycToRVAgM5v1/ovnrWN4fPNJ/q1PQX0JWUTmR9hmX/keRfe0 cs8Yy2W47altRoMHAfpnHPo4/+8vl7yfSkFB+/4gf7HNKCk5kAVyNJhqXj6kbrf1omv91LD/UPJ q6tTCC2xr8PXWz/vOKehYMgpUASQDta3CNGteMReL X-Received: by 2002:a05:651c:1593:b0:2ff:5645:121f with SMTP id 38308e7fff4ca-2ff590a1bb4mr11974941fa.40.1731579516118; Thu, 14 Nov 2024 02:18:36 -0800 (PST) X-Google-Smtp-Source: AGHT+IGHQSAV59WKYu05dmBNQnrVx9gY8+LotSbFAGcu78M/cyWb7iN6kRW4nZ0QMjdqGh+YS/v3uA== X-Received: by 2002:a05:651c:1593:b0:2ff:5645:121f with SMTP id 38308e7fff4ca-2ff590a1bb4mr11974711fa.40.1731579515627; Thu, 14 Nov 2024 02:18:35 -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-432da29978dsm18295605e9.41.2024.11.14.02.18.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 14 Nov 2024 02:18:35 -0800 (PST) Mime-Version: 1.0 Date: Thu, 14 Nov 2024 11:18:34 +0100 Message-Id: <D5LTPJ4FK5O0.1C6RBQKKUU055@redhat.com> Subject: Re: rte_fib network order bug From: "Robin Jarry" <rjarry@redhat.com> To: =?utf-8?q?Morten_Br=C3=B8rup?= <mb@smartsharesystems.com>, "Medvedkin, Vladimir" <vladimir.medvedkin@intel.com>, <dev@dpdk.org> User-Agent: aerc/0.18.2-101-g95b6f544c5c4 References: <D5K3GCR2XSBG.287JQOMCHLET6@redhat.com> <da689769-f9e3-43c1-95ce-cd8e0478c4a4@intel.com> <D5L33CJLU6T3.29EVLGR8HT22W@redhat.com> <SJ0PR11MB5772666B44B818FE71F7F147965A2@SJ0PR11MB5772.namprd11.prod.outlook.com> <98CBD80474FA8B44BF855DF32C47DC35E9F8CB@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F8CB@smartserver.smartshare.dk> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: Sd_GJBkujdT9Hu6MpAl9qe6ux6SLkxnThh5WIbOEcng_1731579516 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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Hi folks, Morten Br=C3=B8rup, Nov 14, 2024 at 08:43: > Medvedkin, Vladimir: >> I think control plane API should work with prefix addresses in CPU=20 >> byte order. At least our RTE_IPV4 macro works this way. Also, prefix=20 >> is an address + prefix length (not the mask), so it is more natural=20 >> if address is in cpu byte order. This may get into a religion debate, but in my opinion, an IPv4 address=20 is *not* an integer. It should be treated as an opaque value. RTE_IPV4=20 is only useful to define addresses in unit tests. I do not know of any IPv4 stack implementation that deals with=20 *host order* addresses. Here are a couple of examples where all=20 addresses are stored in network order in the control plane: https://elixir.bootlin.com/linux/v6.11.6/source/net/ipv4/fib_frontend.c#L10= 69 https://github.com/freebsd/freebsd-src/blob/release/14.1.0/sys/net/route/ro= ute_ctl.c#L692 https://git.fd.io/vpp/tree/src/vnet/fib/fib_table.c?h=3Dv24.10#n237 >> >> Also, I think byte swap should be done on the interface where byte=20 >> order changes, and this boundary lies outside the FIB library.=20 >> However, I've added this feature not only because it was asked, but=20 >> also trying to improve performance in some cases, such as using=20 >> AVX512 byte swap in vector path for users who don't want to bother=20 >> about manually do byteswap on the fast path. >> >> Why do you think this would discourage users? > > Joining the discussing with a couple of comments. > > 1. When I saw the byte order flag the first time, it was not clear to=20 > me either that it only affected lookups - I too thought it covered=20 > the 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 > e.g.: > > /** If set, FIB lookup is expecting IPv4 address in network byte order. N= ote: Only lookup! */ > #define RTE_FIB_F_LOOKUP_NETWORK_ORDER 1 > > 2. Control plane API should use CPU byte order. I consider inet_pton()=20 > irrelevant in this context. Adding network byte order lookup for=20 > fast path optimization makes good sense, and adding it to the RIB=20 > library would be nice too. > > If it was an address table (not longest prefix table, but a hash or=20 > similar), the learn()/update() function could be fast path, and=20 > thus support network byte order too; but it's not, so add() is=20 > control plane. Why would control plane use a different representation of addresses=20 compared to data plane? Also for consistency with IPv6, I really think=20 that *all* addresses should be dealt in their network form. Cheers.