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 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 ; Thu, 5 May 2022 19:50:04 +0200 (CEST) Received: by mail-lf1-f45.google.com with SMTP id bq30so8715158lfb.3 for ; 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?= Date: Thu, 5 May 2022 19:49:28 +0200 Message-ID: Subject: Re: [PATCH 02/11] examples/l3fwd: fix scalar LPM compilation To: Stephen Hemminger Cc: dev , Frank Zhao , Sam Grove , Marcin Wojtas , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 wrote: > On Thu, 5 May 2022 19:29:54 +0200 > Stanislaw Kardach 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 > > Sponsored-by: Frank Zhao > > Sponsored-by: Sam Grove > > 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
On Thu, May 5, 2022 at 7:39 PM Stephen He= mminger <stephen@networkpl= umber.org> wrote:
On Thu,=C2=A0 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 wher= e 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&quo= t;)
> Cc: pbha= gavatula@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 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>

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 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.
A= lternative, which makes checkpatch happy and was previously used is "S= uggested-by". However suggestion, doesn't necessary mean sponsorsh= ip.
I had a talk about this with Thomas Monjalon and he has also = leaned towards "Sponsored-by".
I'm open to suggesti= ons as I admit, I'm not sure which route is better.
--0000000000002f36cc05de475f85--