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 A531745847; Thu, 22 Aug 2024 16:13:56 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 66C8F42E52; Thu, 22 Aug 2024 16:13:56 +0200 (CEST) Received: from mail-pj1-f44.google.com (mail-pj1-f44.google.com [209.85.216.44]) by mails.dpdk.org (Postfix) with ESMTP id 5D5EB4027A for ; Thu, 22 Aug 2024 16:13:55 +0200 (CEST) Received: by mail-pj1-f44.google.com with SMTP id 98e67ed59e1d1-2cd5d6b2581so632361a91.2 for ; Thu, 22 Aug 2024 07:13:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1724336034; x=1724940834; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=ROHgmmMQ0K6ZPxqngHfYvadBaIbafIH7n9M16vpIR4c=; b=t9Ib79LV3pbL2aKk067qkjk9+NebWMcZPaorpymDQFygz8Tm/yYnCdEP/j2iiZi724 IOJDQkjBa3b9e2Zu3BW1bXKVJDmMiJ46Lae61qYvvZzqhdzqd8PWbXzH4AknMztm7sdk tN0HUnckQcrTqoZmN/+3eA27pXc9xsfQ8D93iKl1pj4FgRYrorolJjy5tYS4GkB7t29y ZqfLNSFGx178+PEXkb/RNbzPfbPwiMwadlC2Q4OsUD69Fic/xB6d0dKnmhC++ocPCMBb 6l/SfRj+e89qngejOciRTuiQ3OUYKrL7z9CVxD4QHc639YKGZVJs6gGir9HuvOvxplRG w5AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724336034; x=1724940834; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ROHgmmMQ0K6ZPxqngHfYvadBaIbafIH7n9M16vpIR4c=; b=tu8abq2RJAj1Nu7KDNByeTYUkm87BP/BEENDWQYovO4UOiAXq5DOknkgf26oCXwQdQ jNL924kABbgWjaw9Av7bLTHuAxcF+jhpxVF/TJ0cRrLcrv0RwCOxLL0Xmyqb+K1qnejk KxbED5gVM9DuoAQi8NCtsUO+g8gE38k3jMPPxv0kJhUjZPXTHeT2CUbbEIOds7cWM5tE a3168KPUYeXdy7mgXDbHVCvvLnuFnbyJCSUmBnXUnYWOr29E7JP9C8vv4knCRW8372D9 0XGvdttSSIzyKvLF635bFfhFXBwW8mP+SjfX+x2pIv0uE9qIFsQb1sTwNLmtlFiCwoKT nOPg== X-Gm-Message-State: AOJu0YwOhZ51oGo9TumFk5KcgQ2BPkESfmFsN7DmbquBVY5QOmFSH4lW AWWCGTsE3w47yjULWwdSbKYIzvYz11l5EUWvyryLsS7eeiSuSANzDhtBMlS2enM= X-Google-Smtp-Source: AGHT+IGEq/3WJEO4NXaMbBaW4KND42cIw5X0Ph38pDz6KQwg7cgy1kIHL6Mclbeshq1vroz8GT4aaQ== X-Received: by 2002:a17:90b:164c:b0:2c9:63ef:95b9 with SMTP id 98e67ed59e1d1-2d5e99e752fmr6315103a91.14.1724336034208; Thu, 22 Aug 2024 07:13:54 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2d5ebbb17cesm4164530a91.40.2024.08.22.07.13.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Aug 2024 07:13:53 -0700 (PDT) Date: Thu, 22 Aug 2024 07:13:52 -0700 From: Stephen Hemminger To: Robin Jarry Cc: dev@dpdk.org, Morten =?UTF-8?B?QnLDuHJ1cA==?= , Vladimir Medvedkin , Konstantin Ananyev , Bruce Richardson Subject: Re: [PATCH dpdk v1 00/15] IPv6 APIs overhaul Message-ID: <20240822071352.5e4766ba@hermes.local> In-Reply-To: <20240821162516.610624-17-rjarry@redhat.com> References: <20240821162516.610624-17-rjarry@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 On Wed, 21 Aug 2024 18:25:17 +0200 Robin Jarry wrote: > Hi everyone, > > As discussed recently [1], here is a first draft of the IPv6 APIs rework. The > API change was announced before the 24.07 release [2]. This series is intended > for 24.11. > > [1] http://inbox.dpdk.org/dev/D2SR8T1H39CJ.JRQFI6JEH0OX@redhat.com/ > [2] https://git.dpdk.org/dpdk/commit/?id=835d4c41e0ab58a115c2170c886ba6d3cc1b5764 > > I tried to keep the patches as small as possible; unfortunately some of them > are quite big and cannot be broken down if we want to preserve a bisectable > tree. > > Let me know what you think. Let me ask a couple of questions about this. Why does DPDK need to have its own definitions of IPv4 and IPv6 addresses? The structures in_addr and in6_addr exist on Linux, BSD, and Windows. It creates lots of code reimplementation (see inet_ntop etc). What advantage is there to having our own definitions?