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 C357742C57; Thu, 8 Jun 2023 04:02:55 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B2823427F5; Thu, 8 Jun 2023 04:02:55 +0200 (CEST) Received: from mail-ot1-f49.google.com (mail-ot1-f49.google.com [209.85.210.49]) by mails.dpdk.org (Postfix) with ESMTP id 593E940042 for ; Thu, 8 Jun 2023 04:02:54 +0200 (CEST) Received: by mail-ot1-f49.google.com with SMTP id 46e09a7af769-6b291d55f52so35791a34.2 for ; Wed, 07 Jun 2023 19:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20221208.gappssmtp.com; s=20221208; t=1686189773; x=1688781773; 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=HgJV5vLI4TwMibRzttIBNRjotNmkROnv47zT8uHD/N0=; b=hhC4hM+dKrPSDCSlFjsQy4YUhl73gPR2lbKbmFYXZ9QAdr8kJO60tT+J4acIKXOoBI F6h6+SE37lPvSRsz81Dzk7MSZbdrbW4pU/T7oqEBr7nP/OzLkbU+sN/oSon/QuAvsxcH rmP1oWJxQOdUBoT/xW6xvqxHU1fvYB/5m8/OFRf9dauHmpsSfJhQCw5xABp8a2xlcgFz 4UtRD98yrWgB4Zxabri+5Oj3Ojk3xZglI4TB5hRhRZs6ZVGmHPcGw44LPUuUhYW9WLAH xepk+fwRLAiHa9/raV0Kdml3IK1lpnXI036aLRDLHRmbYuZYnnOV42EqoOduDjCJClW3 RB5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686189773; x=1688781773; 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=HgJV5vLI4TwMibRzttIBNRjotNmkROnv47zT8uHD/N0=; b=D6DNKuzNlbw4/5rrcvU6VqE6av5z0oG1EXuvuBhufaH1LVH6xkbOMRcrp61KusLsfD +lAlkseJ9fIXUAlBY/h2KjDyzBlxEmBXd0dYP7QLhpj96vylqH6sVKwKuobbs1PjtOrQ hmcmVnA5P0Hqr1mjEkxgFADrwetDszm9f0C7sbd3PfSjLEe9NCIofAJzO3hHtQqr7Buf Qv6xbO9ZhZNgHf/NRn3dRs53ed15m5UxVC+2bXoIBlqdLwMOPd/+rY/MeCxO672x6hUE UuE0NjToSF9UrGoo75kt5C+VXgtqGvhFKU3sRGLpXSVmRR6r/tnk4Jcw49R/2KNQSzLm 48mg== X-Gm-Message-State: AC+VfDxAlWaLDOBNSQNH2qKN5gxcCHKWBnUFxneDRpYpdGsldBwOzCEZ AJBpD5/VV6TdlRXiLd2Nrj8BuQ== X-Google-Smtp-Source: ACHHUZ5TCooiaHqTkHiGOu9NP6rMsUBeHdW18rBX9cwd6ciyAVnRXN2LafuxyFlPP/9BrhBGbd88Sg== X-Received: by 2002:a05:6830:2083:b0:6af:8c34:a16a with SMTP id y3-20020a056830208300b006af8c34a16amr4875394otq.5.1686189773630; Wed, 07 Jun 2023 19:02:53 -0700 (PDT) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id a16-20020a62bd10000000b0065ecdefa57fsm40895pff.0.2023.06.07.19.02.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Jun 2023 19:02:52 -0700 (PDT) Date: Wed, 7 Jun 2023 19:02:50 -0700 From: Stephen Hemminger To: Ferruh Yigit Cc: David Christensen , dev@dpdk.org, stable@dpdk.org Subject: Re: [PATCH v2] net/tap: resolve stringop-overflow with gcc 12 on ppc64le Message-ID: <20230607190250.3733aab2@hermes.local> In-Reply-To: <44fb2571-8f96-570d-cb35-210fa5f52d9f@amd.com> References: <20230322212439.524725-1-drc@linux.vnet.ibm.com> <20230323170145.129901-1-drc@linux.vnet.ibm.com> <165a233b-b41b-3a65-1866-5b7c94993b40@amd.com> <20230515162032.36a4f3ec@hermes.local> <20230515182838.08e49a7c@hermes.local> <44fb2571-8f96-570d-cb35-210fa5f52d9f@amd.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, 7 Jun 2023 19:47:04 +0100 Ferruh Yigit wrote: > On 5/16/2023 10:55 AM, Ferruh Yigit wrote: > > On 5/16/2023 2:28 AM, Stephen Hemminger wrote: > >> On Tue, 16 May 2023 00:35:56 +0100 > >> Ferruh Yigit wrote: > >> > >>> Yes only some scripts and possible applications that hotplug tap > >>> interface with hardcoded parameters may impacted, don't know how big is > >>> this amount but this ends up breaking something that was working before > >>> upgrading DPDK for them. > >>> > >>> And I believe the motivation is weak to break the behavior. > >>> > >>> Won't it be better to update 'rte_ether_unformat_addr()' to accept more > >>> flexible syntax, and use it? Is there any disadvantage of this approach? > >> > >> It is already more flexible than the standard ether_aton(). > > > > I mean to accept single chars, as 'tap' currently does, like "a:a:a:a:a:a". > > > > Agree that impact of tap change is small, but if we can eliminate it > > completely without any side affect, why not? > > > > > > As accepting single char will be expanding 'rte_ether_unformat_addr()' > > capability, it will be backward compatible, am I missing anything? I did a little poking around. The single character format is actually non standard. It would be good to extend rte_unformat_ether_addr to allow a wider range of formats including all those used by Windows, IEEE, and network vendors.