patches for DPDK stable branches
 help / color / mirror / Atom feed
From: Luca Boccassi <bluca@debian.org>
To: Christian Ehrhardt <christian.ehrhardt@canonical.com>,
	dpdk stable <stable@dpdk.org>
Cc: Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [dpdk-stable] [PATCH 0/3] kni: fix kernel 5.4 builds
Date: Mon, 21 Oct 2019 18:30:45 +0100	[thread overview]
Message-ID: <d34d1f35662f68fdd2115d34dce560e9dcf50590.camel@debian.org> (raw)
In-Reply-To: <20191021111634.15500-1-christian.ehrhardt@canonical.com>

On Mon, 2019-10-21 at 13:16 +0200, Christian Ehrhardt wrote:
> Hi,
> I've got a report [1] from our kernel Team which regularly pre-checks
> new kernels ahead of time. All of this is about kni/ethtool failing
> to
> build with 5.4.
> 
> I know that going forward there is [2] so the master branch doesn't
> care
> anymore.
> 
> To be clear, Thomas was rather straight on this topic on IRC :-)
> [11:18] <tmonjalo> cpaelzer: Drop KNI ethtool from your package!
> [11:20] <tmonjalo> That's a lot easier than maintaining this... thing
> [11:31] <cpaelzer> tmonjalo: that is true and correct for the future,
> which also reflects what happened in master branch
> [11:31] <cpaelzer> tmonjalo: but the past is the past and I guess I
> need to fix it there
> [11:34] <tmonjalo> cpaelzer: there is another way: drop it and wait
> for requests ;)
> [11:35] <cpaelzer> I'm not bold enough to do that
> [11:35] <cpaelzer> but I already have it in the not officially
> supported packages
> [11:35] <cpaelzer> so I can worst case just stop caring, but then I
> like to fix things ...
> 
> But I wondered if we should keep it a bit alive at least for a while
> for
> Distributions that carry it as package. Personally for Ubuntu that
> would be
> around the time of whatever kernel is recent April next year and
> valid
> for DPDK 17.11 and 18.11. But needs surely will differ for different
> distributions.
> 
> Here is a patch series intended for stable releases only, tested with
> kernel 5.3 (old behavior) and 5.4 (new behavior). We might want to
> have
> someone test other distros and other (older) kernels as well maybe?
> 
> I'm throwing in the patch series as suggestion for a fix, but it
> might
> as well be just the start for a discussion to document the projects
> thoughts about released e.g. 17.11.x/18.11.x versions carrying that
> package and how they are suggested to handle kni-ethtool being sort
> of
> unmaintainable.
> I'll surely start that discussion with Luca for the Debian/Ubuntu
> scope.
> 
> [1]: 
> https://bugs.launchpad.net/ubuntu/eoan/+source/dpdk/+bug/1848585
> 
> [2]: 
> https://git.dpdk.org/dpdk/commit/?id=ea6b39b5
> 
> 
> Christian Ehrhardt (3):
>   kni: fix kernel 5.4 build - merged pci_aspm.h
>   kni: fix kernel 5.4 build - num_online_cpus
>   kni: fix kernel 5.4 build - skb_frag_t to bio_vec
> 
>  kernel/linux/kni/ethtool/igb/igb_main.c  | 12 ++++++++++--
>  kernel/linux/kni/ethtool/igb/kcompat.h   | 10 ++++++++--
>  kernel/linux/kni/ethtool/ixgbe/kcompat.h | 10 ++++++++--
>  3 files changed, 26 insertions(+), 6 deletions(-)

Series-acked-by: Luca Boccassi <bluca@debian.org>

Given we are shipping with it we need to support it for the lifetime of
the branches, so thanks for the patches.

-- 
Kind regards,
Luca Boccassi

  parent reply	other threads:[~2019-10-21 17:30 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-21 11:16 Christian Ehrhardt
2019-10-21 11:16 ` [dpdk-stable] [PATCH 1/3] kni: fix kernel 5.4 build - merged pci_aspm.h Christian Ehrhardt
2019-10-21 11:16 ` [dpdk-stable] [PATCH 2/3] kni: fix kernel 5.4 build - num_online_cpus Christian Ehrhardt
2019-10-21 11:16 ` [dpdk-stable] [PATCH 3/3] kni: fix kernel 5.4 build - skb_frag_t to bio_vec Christian Ehrhardt
2019-10-21 17:30 ` Luca Boccassi [this message]
2019-10-24 15:58   ` [dpdk-stable] [PATCH 0/3] kni: fix kernel 5.4 builds Kevin Traynor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d34d1f35662f68fdd2115d34dce560e9dcf50590.camel@debian.org \
    --to=bluca@debian.org \
    --cc=christian.ehrhardt@canonical.com \
    --cc=stable@dpdk.org \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).