[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM0EoMmA3_9XmTFk5H-0oR5qfEYtxq_1Vc2zRVKfA_vtVTmafg@mail.gmail.com>
Date: Mon, 16 Oct 2023 17:44:20 -0400
From: Jamal Hadi Salim <jhs@...atatu.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, anjali.singhai@...el.com, namrata.limaye@...el.com,
deb.chatterjee@...el.com, john.andy.fingerhut@...el.com, dan.daly@...el.com,
Vipin.Jain@....com, tom@...anda.io, mleitner@...hat.com,
Mahesh.Shirshyad@....com, tomasz.osinski@...el.com, jiri@...nulli.us,
xiyou.wangcong@...il.com, davem@...emloft.net, edumazet@...gle.com,
pabeni@...hat.com, vladbu@...dia.com, horms@...nel.org, khalidm@...dia.com,
toke@...hat.com, mattyk@...dia.com
Subject: Re: [PATCH v7 net-next 00/18] Introducing P4TC
On Mon, Oct 16, 2023 at 4:59 PM Jamal Hadi Salim <jhs@...atatu.com> wrote:
>
> On Mon, Oct 16, 2023 at 4:38 PM Jamal Hadi Salim <jhs@...atatu.com> wrote:
> >
> > On Mon, Oct 16, 2023 at 4:15 PM Jakub Kicinski <kuba@...nel.org> wrote:
> > >
> > > On Mon, 16 Oct 2023 05:35:31 -0400 Jamal Hadi Salim wrote:
> > > > Changes In RFC Version 7
> > > > -------------------------
> > > >
> > > > 0) First time removing the RFC tag!
> > > >
> > > > 1) Removed XDP cookie. It turns out as was pointed out by Toke(Thanks!) - that
> > > > using bpf links was sufficient to protect us from someone replacing or deleting
> > > > a eBPF program after it has been bound to a netdev.
> > > >
> > > > 2) Add some reviewed-bys from Vlad.
> > > >
> > > > 3) Small bug fixes from v6 based on testing for ebpf.
> > > >
> > > > 4) Added the counter extern as a sample extern. Illustrating this example because
> > > > it is slightly complex since it is possible to invoke it directly from
> > > > the P4TC domain (in case of direct counters) or from eBPF (indirect counters).
> > > > It is not exactly the most efficient implementation (a reasonable counter impl
> > > > should be per-cpu).
> > >
> > > I think that I already shared my reservations about this series.
> >
> > And please please let's have a _technical_ discussion on reservations
> > not hyperboles.
> >
> > > On top of that, please, please, please make sure that it builds cleanly
> > > before posting.
> > >
> > > I took the shared infra 8 hours to munch thru this series, and it threw
> > > out all sorts of warnings. 8 hours during which I could not handle any
> > > PR or high-prio patch :( Not your fault that builds are slow, I guess,
> > > but if you are throwing a huge series at the list for the what-ever'th
> > > time, it'd be great if it at least built cleanly :(
> >
> > We absolutely dont want to add unnecessary work.
> > Probably we may have missed the net-next tip? We'll pull the latest
> > and retest with tip.
> > Is there a link that we can look at on what the infra does so we can
> > make sure it works per expectation next time?
> > If you know what kind of warnings/issues so we can avoid it going forward?
> > Note: We didnt see any and we built each patch separately on gcc 11,
> > 12, 13 and clang 16.
> > BTW: Lore does reorder the patches, but i am assuming cicd is smart
> > enough to understand this?
>
> Verified from downloading mbox.gz from lore that the tarball was
> reordered. Dont know if it contributed - but now compiling patch by
> patch on the latest net-next tip.
Never mind - someone pointed me to patch work and i can see some
warnings there. Looks like we need more build types and compiler
options to catch some of these issues.
We'll look into it and we will replicate in our cicd.
cheers,
jamal
> cheers,
> jamal
>
> > > --
> > > pw-bot: cr
Powered by blists - more mailing lists