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 AD2DCA034C for ; Tue, 14 Dec 2021 14:57:54 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9AAAA4113D; Tue, 14 Dec 2021 14:57:54 +0100 (CET) Received: from smtp-relay-internal-0.canonical.com (smtp-relay-internal-0.canonical.com [185.125.188.122]) by mails.dpdk.org (Postfix) with ESMTP id DD70340041 for ; Tue, 14 Dec 2021 14:57:52 +0100 (CET) Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-0.canonical.com (Postfix) with ESMTPS id 8948440192 for ; Tue, 14 Dec 2021 13:57:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1639490272; bh=91WXfbElHhcN1xqjx75kvgn9L1eup3riwpkUezWiX98=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=tFRdNC7TvxidnpyEKLgtG5grIZtTR/d7qASGLjICqBXNJcCsLGasXF291UnTnELO1 pdTomDDk5+BRylaVaL1bykFMINJPxhPuDir4roHgyPO8agSSrM5Tn1RuY11QB/xMwM FmcgoavSDF6CG9MNaRh8pNjqCgSv3GSTjCFfC5SDmG8lVUFbS5FZTFZUjNs+KebUm3 FdgqoC0Bv0bTsEyYj6oRTCcp/HmfjJ5OHWf42Ju73xCFCASCs5yACpOCOpKH8vkn61 keiVwq0XgfT/pGV7yPzfeuutmcM7qIrZ2OBbEUeoZqQVDy0uSU6AvHhTZIDy28zX47 UBkELyiEN091Q== Received: by mail-qt1-f198.google.com with SMTP id v19-20020ac85793000000b002b19184b2bfso26775610qta.14 for ; Tue, 14 Dec 2021 05:57:52 -0800 (PST) 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=91WXfbElHhcN1xqjx75kvgn9L1eup3riwpkUezWiX98=; b=gmX0BoyCIqErKX9XsKqxnXQCC932zOvHJ/TkFzOUBju2B+3shETmJG7d38Ias7PMso 40MJLLtzpwE1JcfcvVhoKcYmS66txaYxj2MyyYWFfnl3d2KWycM/XiaYXkeAMhyGCsnF 0vMiBLKn4FIfuSvX3BNiVtMOHnJ79iNvrCUGiyYkuYsEPXfjw2uo9w33ampOEfI7wfuA TiQVzDczvgELQJGLuhL/E8km/YGGBBmFOQWBTYiSzkVKl9Co8yXdLV9NcKLrx2Nud3q9 98AtsQk7PmBnAOCJacL4cvBCh3E9+u9QNaNpSt8NQ/osBwJizMwCSTVoItY9Z1KIJnwV b1IA== X-Gm-Message-State: AOAM533+Hh2uh7LlH46XFr4YRJctrpZdLhHvQPsY4rVqPQwDHHTR44ui rR+q9oM39GQA+Y32i49q6UBZdGFf8snLKD2IWEaQM5uCmFfjUSSRaxrXS4jO6St36mpZlVqQRPv 1nVbwmP3k/Tz3KjbzBP4kJaXcfFrG/ql9+lLK4roP X-Received: by 2002:ac8:5703:: with SMTP id 3mr5959319qtw.113.1639490271441; Tue, 14 Dec 2021 05:57:51 -0800 (PST) X-Google-Smtp-Source: ABdhPJyYdPnaPLGUTTs8pborINXpkwC5qoqsvFbsrQBElPOh5DlNSgYypfVQzbM3W8h72w24f/RHRDRE0+MqE9ZGKCc= X-Received: by 2002:ac8:5703:: with SMTP id 3mr5959291qtw.113.1639490271182; Tue, 14 Dec 2021 05:57:51 -0800 (PST) MIME-Version: 1.0 References: <20211209144315.3424225-1-christian.ehrhardt@canonical.com> <7bf4583f-c2de-0aa7-fb00-bf3e9ff8d99b@intel.com> <34e0a9a8-327e-0150-b18a-dc3bfdca7d11@intel.com> <43d82514-b3e0-1bbd-1351-f1221bfc53db@intel.com> <5ac74587-4a18-3e0b-f674-73f927a11f95@intel.com> <6d30c1d3-6bb6-980f-10c9-8e17d07e2c5b@intel.com> In-Reply-To: <6d30c1d3-6bb6-980f-10c9-8e17d07e2c5b@intel.com> From: Christian Ehrhardt Date: Tue, 14 Dec 2021 14:57:22 +0100 Message-ID: Subject: Re: 19.11.11 patches review and test To: Ferruh Yigit Cc: Luca Boccassi , Kevin Traynor , "Xueming(Steven) Li" , Kalesh Anakkur Purayil , Abhishek Marathe , Akhil Goyal , Ali Alnubani , David Christensen , Hariprasad Govindharajan , Hemant Agrawal , Ian Stokes , Jerin Jacob , John McNamara , Ju-Hyoung Lee , Pei Zhang , Raslan Darawsheh , Thomas Monjalon , benjamin.walker@intel.com, dpdk stable , dpdk-dev , pingx.yu@intel.com, qian.q.xu@intel.com, yuan.peng@intel.com, zhaoyan.chen@intel.com Content-Type: text/plain; charset="UTF-8" X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org On Tue, Dec 14, 2021 at 1:08 PM Ferruh Yigit wrote: > > On 12/14/2021 11:39 AM, Christian Ehrhardt wrote: > > On Tue, Dec 14, 2021 at 11:13 AM Ferruh Yigit wrote: > >> > >> On 12/14/2021 7:44 AM, Christian Ehrhardt wrote: > >>> On Tue, Dec 14, 2021 at 6:49 AM Kalesh Anakkur Purayil > >>> wrote: > >>> > >>> [snip] > >>> > >>>>>> [Kalesh] Yes, i am seeing the same error. I used make command to build dpdk, not meson. > >>>>>> The back ported commit you mentioned takes care of meson build only I think. > >>>>>> > >>>>> > >>>>> I see, make build is failing, and yes the fix is only for the meson. > >>>>> I will check the make build and will send a fix for it. > >>>> > >>>> [Kalesh]: looks like the below changes fixes the issue. I tried only on SLES15 SP3 and not on other SLES flavors. > >>>> > >>>> diff --git a/kernel/linux/kni/Makefile b/kernel/linux/kni/Makefile > >>>> index 595bac2..bf0efab 100644 > >>>> --- a/kernel/linux/kni/Makefile > >>>> +++ b/kernel/linux/kni/Makefile > >>>> @@ -16,6 +16,16 @@ MODULE_CFLAGS += -I$(RTE_OUTPUT)/include > >>>> MODULE_CFLAGS += -include $(RTE_OUTPUT)/include/rte_config.h > >>>> MODULE_CFLAGS += -Wall -Werror > >>>> > >>>> +# > >>>> +# Use explicit 'source' folder for header path. In SUSE 'source' is not linked to 'build' folder. > >>>> +# > >>>> +ifdef CONFIG_SUSE_KERNEL > >>>> + KSRC = /lib/modules/$(shell uname -r)/source > >>>> + ifneq ($(shell grep -A 1 "ndo_tx_timeout" $(KSRC)/include/linux/netdevice.h | grep -o txqueue),) > >>>> + MODULE_CFLAGS += -DHAVE_TX_TIMEOUT_TXQUEUE > >>>> + endif > >>>> +endif > >>> > >>> Back in the day we tried various "is Suse and kernel version x.y" > >>> approaches, but they failed as there was no clear version throughout > >>> all of the Suse streams (leap, tumbleweed, sles) that worked well for > >>> all. > >>> This change here follows the upstream approach of "just check if it is there". > >>> > >>> I've applied this to 19.11 and did test builds across various distributions: > >>> 1. no non-suse build changed > >>> 2. suse builds stayed as-is or improved > >>> Formerly failing: > >>> openSUSE_Factory_ARM aarch64 > >>> SLE_15 x86_64 -> now working > >>> openSUSE_Leap_15.3 x86_64 -> now working > >>> openSUSE_Tumbleweed x86_64 -> still failing > >>> Formerly working: > >>> SLE_12_SP4 x86_64 ppc64le -> still fine > >>> openSUSE_Factory_ARM armv7l -> still fine > >>> openSUSE_Leap_15.2 x86_64 -> still fine > >>> > >> > >> Thanks Kalesh for the fix, and thanks Christian for testing. > >> > >> I was expecting this approach will fix all builds, after patch only > >> 'openSUSE_Tumbleweed' is failing, right? I will check it. > > > > As just discussed on IRC, yes and the log for that is at > > https://build.opensuse.org/package/live_build_log/home:cpaelzer:branches:home:bluca:dpdk/dpdk-19.11/openSUSE_Tumbleweed/x86_64 > > > > It also is affected by an issue around -Werror=implicit-fallthrough, > > so even with KNI fixed it likely is going to fail. > > > >> And I think you need the fix as a patch anyway, @Kalesh are you > >> planning to send the patch? > > > > I don't need it, as I have already grabbed and preliminary added it: > > https://github.com/cpaelzer/dpdk-stable-queue/commit/d43fa3e198c08a3a76d70f4565b31ad3ab5f29c4 > > > > I was thinking any commit in the LTS *must* come from either upstream > commit or a backport patch in the stable mail list. To be clear, yes we want transparency where things come from, but in this case we had all of that. It is an extension (by Kalesh) of a backport (by me) of c28e2165e that was correctly sent to stable@dpdk.org > Isn't it very hard to back trace merging diffs from emails, > are you OK with that? Only for the very special case it is here, not for random diff snippets thrown in any thread. The rule of thumb should still be "submit with prefix [Patch 19.11] to stable@dpdk.org" > > But surely, once/If you come up with a full patch that also includes > > tumbleweed I can replace it with yours. > > > >>> Past fixes always "inverted" the result, by fixing some but breaking others. > >>> This new patch works in "not breaking any formerly working build" but > >>> at the same time fixing a few builds. > >>> Therefore -> applied & thanks! > >>> > >>> I'll likely tag -rc2 before the end of the week. > >>> The good thing is that (so far) we have: > >>> 1. a non functional change > >>> 2. a change fixing clang-13 builds (TBH only one of many needed clang13 issues) > >>> 3. a change fixing sles15SP3 builds > >>> > >>> Due to those, no current ongoing tests will have to be restarted. > >>> Whoever was able to build, can continue the current tests. > >>> Whoever was blocked by SLES15SP3 or clang-13 had no tests other than a > >>> failing build and can work with -rc2 then. > >>> I'll explain the same in the mail about -rc2. > >>> > >>>> -include /etc/lsb-release > >>>> > >>>> ifeq ($(DISTRIB_ID),Ubuntu) > >>>> > >>>> Regards, > >>>> Kalesh > >>> > >>> [snip] > >>> > >> > > > > > -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd