[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180116144158.5e2935b8@cakuba.netronome.com>
Date: Tue, 16 Jan 2018 14:41:58 -0800
From: Jakub Kicinski <kubakici@...pl>
To: Jamal Hadi Salim <jhs@...atatu.com>
Cc: Alexander Aring <aring@...atatu.com>, xiyou.wangcong@...il.com,
jiri@...nulli.us, davem@...emloft.net, netdev@...r.kernel.org,
kernel@...atatu.com, David Ahern <dsahern@...il.com>
Subject: Re: [PATCH net-next 0/8] net: sched: cls: add extack support
On Tue, 16 Jan 2018 17:12:57 -0500, Jamal Hadi Salim wrote:
> On 18-01-16 04:46 PM, Jakub Kicinski wrote:
> > On Tue, 16 Jan 2018 12:20:19 -0500, Alexander Aring wrote:
>
> [..]
>
> > Ugh, this is going to conflict with our series too :( (and I CCed you
> > on ours)
> >
> > Would it be OK for you to hold off until Jiri's code gets merged and
> > ours comes down via bpf-next? That shouldn't take long at all. The
> > conflicts between bpf/bpf-next/net-next are really taking their toll
> > on us this release cycles, I would really appreciate if we could make
> > some progress on this relatively simple series at least...
> >
>
> I would say precedence should be Jiri's patches, Alex's patches
> and then yours:
> Alex's patches fix the core (cls_api.c) area with proper extack
> for the core and then he has one patch to cover a specific
> use case of the u32 classifier extack. Yours is only concerned
> with one use case - bpf which depend on the core (that is in Alex's
> patches)
Our patches are concerned with propagating the extack to drivers,
and nfp (and netdevsim) make use of it.
I'm miffed by the fact that you jumped out with this conflicting series
*after* we posted ours, and we got shot down on white space.
Powered by blists - more mailing lists