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 BE649A00C2;
Thu, 5 May 2022 19:50:06 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id A60754014F;
Thu, 5 May 2022 19:50:06 +0200 (CEST)
Received: from mail-lf1-f45.google.com (mail-lf1-f45.google.com
[209.85.167.45]) by mails.dpdk.org (Postfix) with ESMTP id EA63B40042
for <dev@dpdk.org>; Thu, 5 May 2022 19:50:04 +0200 (CEST)
Received: by mail-lf1-f45.google.com with SMTP id bq30so8715158lfb.3
for <dev@dpdk.org>; Thu, 05 May 2022 10:50:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=semihalf-com.20210112.gappssmtp.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=ZWuJmycfkUjgIEXxFvj4W8jcROsPB+LcCXD0d8BSu/4=;
b=6cY0E7rYOeOMZ6KVGhxxVMWImLxJvZ0yUDoHkt8eq0nKqkMbN3QMiI7M+js1OzdQVT
fx7Blwk+4ONYe3rt+wdPautIVMpEg7mG4yyDrKG1pLjTkBPhCbRh/NXthg1ecFmm2ZtM
mBwHKv9YiCgER4JLAfjpE/LG+AVihrDrmpAblyuKoQpsYTyRvD4AGgUj7nfOYisQM6uz
TmE5pjXlBt0loSlOglY5EW56eJm1K8LqJW/GJnFlxybEIPXtK9JWPIMtrhBUYjX9XE76
plobCrxcuY7i20TleXjPZCx4C5Hf/nynna3qQElfDNmmWhYflc3mtlLlbGJRjvRCrIAG
Isrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=ZWuJmycfkUjgIEXxFvj4W8jcROsPB+LcCXD0d8BSu/4=;
b=YU38o3K04kwKAGR/K8F9uQDeRq8kXbzznsanGQBJhCJXbLWHuLHCrsPV3sPY72Omsx
i5QrQHQhNtkIqEV4LN/cfIzaeNDd2WsflwvJgJwxDXLq05OigLc9vJ3g9Vg2uNyes8RJ
dmRxV4weOdlB6DzH5dmLHiP/l7Lz37uPuR/644eFvkzGFQpWYLENc6n/DqUbQxZjh8xf
UcdQwPgifREP63zPCtFmnC28fN1TqYreRX/Rzrkh0YkgSTq86CxucxSsuI2TDsf1+hNZ
Xk9Y0FY/XZYPaP0wsVxQ2aURvFTyN070Pw4nCeqvheVZD/yk/ocWx3l+E7YZmHZxatB4
MokA==
X-Gm-Message-State: AOAM533ZHCLHL/81TYXaV2d7g9rQqcmoq+aJzLLvNISf/94mtoYyJu9X
ReL0RKxfy0jZpPN0a0iDubVhdq8e9QCje6HvN2iyoQ==
X-Google-Smtp-Source: ABdhPJyW1PzTee7xHgOzvnMzX58zaJPUZe8eko3gvgamPz9qZeTqU9xDpbUNV8Gt6jfMAFnUl+HuFHCwm58/0vuPMMk=
X-Received: by 2002:a05:6512:1520:b0:443:ec43:5fe8 with SMTP id
bq32-20020a056512152000b00443ec435fe8mr19307912lfb.589.1651773004520; Thu, 05
May 2022 10:50:04 -0700 (PDT)
MIME-Version: 1.0
References: <20220505173003.3242618-1-kda@semihalf.com>
<20220505173003.3242618-3-kda@semihalf.com>
<20220505103951.2c58b9d0@hermes.local>
In-Reply-To: <20220505103951.2c58b9d0@hermes.local>
From: =?UTF-8?Q?Stanis=C5=82aw_Kardach?= <kda@semihalf.com>
Date: Thu, 5 May 2022 19:49:28 +0200
Message-ID: <CALVGJWLfKFqDr_MROJ==oyvBMV-PVf8esrbZBBEaToHmcRdunQ@mail.gmail.com>
Subject: Re: [PATCH 02/11] examples/l3fwd: fix scalar LPM compilation
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: dev <dev@dpdk.org>, Frank Zhao <Frank.Zhao@starfivetech.com>,
Sam Grove <sam.grove@sifive.com>, Marcin Wojtas <mw@semihalf.com>,
upstream@semihalf.com, pbhagavatula@marvell.com
Content-Type: multipart/alternative; boundary="0000000000002f36cc05de475f85"
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
--0000000000002f36cc05de475f85
Content-Type: text/plain; charset="UTF-8"
On Thu, May 5, 2022 at 7:39 PM Stephen Hemminger <stephen@networkplumber.org>
wrote:
> On Thu, 5 May 2022 19:29:54 +0200
> Stanislaw Kardach <kda@semihalf.com> wrote:
>
> > The lpm_process_event_pkt() can either process a packet using an
> > architecture specific (defined for X86/SSE, ARM/Neon and PPC64/Altivec)
> > path or a scalar one. The choice is however done using an ifdef
> > pre-processor macro. Because of that the scalar version was apparently
> > not widely excersized/compiled.
> > Due to some copy/paste errors, the scalar logic in
> > lpm_process_event_pkt() retained a "continue" statement where a BAD_PORT
> > should be returned after refactoring of the LPM logic in the l3fwd
> > example.
> >
> > Fixes: 99fc91d18082 ("examples/l3fwd: add event lpm main loop")
> > Cc: pbhagavatula@marvell.com
> >
> > Signed-off-by: Stanislaw Kardach <kda@semihalf.com>
> > Sponsored-by: Frank Zhao <Frank.Zhao@starfivetech.com>
> > Sponsored-by: Sam Grove <sam.grove@sifive.com>
>
> Would be easier to get merged if bug fixes came as separate patch
> submission.
>
Sure, I can post this separately. The reason for posting this along with
RISC-V patches is that those depend on this one. So I could add
"depends-on" but wanted be on the safe side.
>
> Also have not seen Sponsored-by before; what do you expect it to mean?
> Never used in DPDK or kernel git tree.
>
The idea is that this work was sponsored by the companies mentioned in the
sign-off. It is used i.e. in FreeBSD though admittedly never in Linux or
DPDK.
Alternative, which makes checkpatch happy and was previously used is
"Suggested-by". However suggestion, doesn't necessary mean sponsorship.
I had a talk about this with Thomas Monjalon and he has also leaned towards
"Sponsored-by".
I'm open to suggestions as I admit, I'm not sure which route is better.
--0000000000002f36cc05de475f85
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr">On Thu, May 5, 2022 at 7:39 PM Stephen He=
mminger <<a href=3D"mailto:stephen@networkplumber.org">stephen@networkpl=
umber.org</a>> wrote:<br></div><div class=3D"gmail_quote"><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
rgb(204,204,204);padding-left:1ex">On Thu,=C2=A0 5 May 2022 19:29:54 +0200=
<br>
Stanislaw Kardach <<a href=3D"mailto:kda@semihalf.com" target=3D"_blank"=
>kda@semihalf.com</a>> wrote:<br>
<br>
> The lpm_process_event_pkt() can either process a packet using an<br>
> architecture specific (defined for X86/SSE, ARM/Neon and PPC64/Altivec=
)<br>
> path or a scalar one. The choice is however done using an ifdef<br>
> pre-processor macro. Because of that the scalar version was apparently=
<br>
> not widely excersized/compiled.<br>
> Due to some copy/paste errors, the scalar logic in<br>
> lpm_process_event_pkt() retained a "continue" statement wher=
e a BAD_PORT<br>
> should be returned after refactoring of the LPM logic in the l3fwd<br>
> example.<br>
> <br>
> Fixes: 99fc91d18082 ("examples/l3fwd: add event lpm main loop&quo=
t;)<br>
> Cc: <a href=3D"mailto:pbhagavatula@marvell.com" target=3D"_blank">pbha=
gavatula@marvell.com</a><br>
> <br>
> Signed-off-by: Stanislaw Kardach <<a href=3D"mailto:kda@semihalf.co=
m" target=3D"_blank">kda@semihalf.com</a>><br>
> Sponsored-by: Frank Zhao <<a href=3D"mailto:Frank.Zhao@starfivetech=
.com" target=3D"_blank">Frank.Zhao@starfivetech.com</a>><br>
> Sponsored-by: Sam Grove <<a href=3D"mailto:sam.grove@sifive.com" ta=
rget=3D"_blank">sam.grove@sifive.com</a>><br>
<br>
Would be easier to get merged if bug fixes came as separate patch<br>
submission.<br></blockquote><div>Sure, I can post this separately. The reas=
on for posting this along with RISC-V patches is that those depend on this =
one. So I could add "depends-on" but wanted be on the safe side.<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Also have not seen Sponsored-by before; what do you expect it to mean?<br>
Never used in DPDK or kernel git tree.<br></blockquote><div>The idea is tha=
t this work was sponsored by the companies mentioned in the sign-off. It is=
used i.e. in FreeBSD though admittedly never in Linux or DPDK.</div><div>A=
lternative, which makes checkpatch happy and was previously used is "S=
uggested-by". However suggestion, doesn't necessary mean sponsorsh=
ip.</div><div>I had a talk about this with Thomas Monjalon and he has also =
leaned towards "Sponsored-by".</div><div>I'm open to suggesti=
ons as I admit, I'm not sure which route is better.</div></div></div>
--0000000000002f36cc05de475f85--