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 150AD4564F; Fri, 19 Jul 2024 12:05:36 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 76BE442FE5; Fri, 19 Jul 2024 12:02:52 +0200 (CEST) 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 5D30842F76 for ; Fri, 19 Jul 2024 12:02:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1721383362; 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=m/AUvcIVeSywfYbNRhqyjswUg8JbKX5loFaYeDEtW7o=; b=S7+cj0UXZhui9Z/yl7NHDJFURdEdyYtOnbgz9wkT3Gz1ZwEt7nJH4jfMev0gD7DpweW566 UmgSR+HQHhBXseIK+IQoYUDQ0BLR8NRfswpqcJ5ogA+jhSeYbQqNn8pVXjqewifpgzmn5c cOnb7wEOLmpR9Ry892sMRf4N+1VP6GU= 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-635-BvjgfN9YM26mQPSdrlDMsw-1; Fri, 19 Jul 2024 06:02:41 -0400 X-MC-Unique: BvjgfN9YM26mQPSdrlDMsw-1 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-42490ae735dso12645045e9.0 for ; Fri, 19 Jul 2024 03:02:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721383360; x=1721988160; h=in-reply-to:references:user-agent:cc:subject:to:from:message-id :date:content-transfer-encoding:mime-version:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=m/AUvcIVeSywfYbNRhqyjswUg8JbKX5loFaYeDEtW7o=; b=CeRKMDtIyUxdXD1FMdWm83IzpfYNTigkZnODNxgBzeVPhkTTE/329YxuBI/RHAYz3w xGCq6aH31Jy21PxqP7KVDzfgzvANuVMDWpxzmRdBKjIxJkKSzUjLexkHqPjMzU2BHaYo YXdGgqdqF1wpsZ0U24F66HOtuMUd59knFHdJ1BOJsGun61Wlyy+wkAw4UJhSRjsbuHla Om+rXfOy49RS8dR0BPBMuj988f+Xl3oQS+mIjgYvOESG1z/gNgnE8MQt885YSXIUCoGs QRbnNCgfd/SWXb13mxsQeitHc4WOeUzR3SLaBhQGlVKIsGVLRRMjpFdFduabjejxaK8f 9a4A== X-Gm-Message-State: AOJu0YzYwb8JbrQqklJc153NgbiP3nsoD5QEqMqZvu3wYGsf0oTdS7xh 4VZ3YGDB6ONP1PAWt6PTUnqHti4Z5YcDsHn/TPQJmB05LyspfgFkMibmWRoLMUCBYff7HDsoiYJ RIbYXJ01ETkpQPdLRUKIzUzDsQY28jGjQkWOtlpcq X-Received: by 2002:a05:600c:3d06:b0:426:58cb:8ca4 with SMTP id 5b1f17b1804b1-427c2d11297mr62866955e9.37.1721383360262; Fri, 19 Jul 2024 03:02:40 -0700 (PDT) X-Google-Smtp-Source: AGHT+IF/LO5fbQMBK8JN4wjO2p67CYrzzrJv9laqq2SsPd1DTqU7KvupFcqlKDRaxNtF8JmzUIHiaQ== X-Received: by 2002:a05:600c:3d06:b0:426:58cb:8ca4 with SMTP id 5b1f17b1804b1-427c2d11297mr62866405e9.37.1721383359812; Fri, 19 Jul 2024 03:02:39 -0700 (PDT) Received: from localhost (2a01cb0003516600b51f9b4ded302b00.ipv6.abo.wanadoo.fr. [2a01:cb00:351:6600:b51f:9b4d:ed30:2b00]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-427d8e68ba0sm7565405e9.21.2024.07.19.03.02.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 Jul 2024 03:02:39 -0700 (PDT) Mime-Version: 1.0 Date: Fri, 19 Jul 2024 12:02:38 +0200 Message-Id: From: "Robin Jarry" To: =?utf-8?q?Morten_Br=C3=B8rup?= , "Vladimir Medvedkin" , Subject: Re: IPv6 APIs rework Cc: , "Sunil Kumar Kori" , "Rakesh Kudurumalla" , "Vladimir Medvedkin" , "Wisam Jaddo" , "Cristian Dumitrescu" , "Konstantin Ananyev" , "Akhil Goyal" , "Fan Zhang" , "Bruce Richardson" , "Yipeng Wang" , "Sameh Gobriel" , "Nithin Dabilpuram" , "Kiran Kumar K" , "Satha Rao" , "Harman Kalra" , "Ankur Dwivedi" , "Anoob Joseph" , "Tejasree Kondoj" , "Gagandeep Singh" , "Hemant Agrawal" , "Ajit Khaparde" , "Somnath Kotur" , "Chas Williams" , "Min Hu (Connor)" , "Potnuri Bharat Teja" , "Sachin Saxena" , "Ziyang Xuan" , "Xiaoyun Wang" , "Jie Hai" , "Yisen Zhuang" , "Jingjing Wu" , "Dariusz Sosnowski" , "Viacheslav Ovsiienko" , "Bing Zhao" , "Ori Kam" , "Suanming Mou" , "Matan Azrad" , "Chaoyong He" , "Devendra Singh Rawat" , "Alok Prasad" , "Andrew Rybchenko" , "Jiawen Wu" , "Jian Wang" , "Thomas Monjalon" , "Ferruh Yigit" , "Jiayu Hu" , "Pavan Nikhilesh" , "Maxime Coquelin" , "Chenbo Xia" User-Agent: aerc/0.18.0-5-gd32d93015ed7 References: <98CBD80474FA8B44BF855DF32C47DC35E9F5AB@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35E9F5AC@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F5AC@smartserver.smartshare.dk> X-Mimecast-Spam-Score: 0 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, Jul 19, 2024 at 11:12: > > Vladimir Medvedkin, Jul 18, 2024 at 23:25: > > > I think alignment should be 1 since in FIB6 users usually don't=20 > > > copy IPv6 address and just provide a pointer to the memory inside=20 > > > the packet. > > How can they do that? The bulk lookup function takes an array of IPv6=20 > addresses, not an array of pointers to IPv6 addresses. > > What you are suggesting only works with single lookup, not bulk=20 > lookup. Indeed for bulk lookup, you need to copy addresses on the stack. > > Yes, my intention was exactly that, being able to map that structure=20 > > directly in packets without copying them on the stack. > > This would require changing the bulk lookup API to take an array of=20 > pointers instead of an array of IPv6 addresses. > > It would be acceptable to introduce a new single address lookup=20 > function, taking a pointer to an unaligned (or 2 byte aligned) IPv6=20 > address for the single lookup use cases mentioned above. That would require two different IPv6 structures. I would prefer it we=20 could avoid that. Or the unaligned lookup API needs to take a simple=20 `const uint8_t *` parameter. > I'm not worried about the IPv6 FIB functions. This proposal introduces=20 > a generic IPv6 address type for *all of DPDK*, so you need to consider=20 > *all* aspects, not just one library! > > There may be current or future CPUs, where alignment makes=20 > a performance difference. Do all architectures support unaligned 128=20 > bit access at 100 % similar performance to aligned 128 bit access?=20 > I think not! > E.g. on X86 architecture, load/store across a cache boundary has=20 > a performance impact. If the type is explicitly unaligned, an instance=20 > on the stack (i.e. a local variable holding an IPv6 address) might=20 > cross a cache boundary, whereas an 128 bit aligned instance on the=20 > stack is guaranteed not to cross a cache boundary. > > The generic IPv4 address type is natively aligned (i.e. 4 byte). When=20 > accessing an IPv4 address in an IPv4 header following an Ethernet=20 > header, it is not 4 byte aligned, so this is an *exception* from the=20 > general case, and must be treated as such. You don't want to make the=20 > general type unaligned (and thus inefficient) everywhere it is being=20 > used, only because a few use cases require the unaligned form. I think the main difference is that you almost never pass IPv4 addresses=20 as reference but always as values. So alignment does not matter. > The same principle must apply to the IPv6 address type. Let's make the=20 > generic type natively aligned (16 byte). And you might also offer an=20 > explicitly unaligned type for the exception use cases requiring=20 > unaligned access. The main issue with this is that you would not be able to use that type=20 in the IPv6 header structure to map it to mbuf data. That leaves us with=20 two options: 1) Keep a single unaligned IPv6 type and hope for the best with=20 performance. It will not be different from the current state of=20 things where every IPv6 is a uint8_t pointer. 2) Have two IPv6 types, one 16 bytes aligned, and another one 1 byte=20 aligned. The main issue with that second approach is that users may=20 get confused about which one to use and when. I would prefer to keep it simple at first and go with option 1). We can=20 always revisit that later and introduce an aligned IPv6 type for certain=20 use cases. What do you think?