[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220430131959.obb74c2z7ihap6ek@skbuf>
Date: Sat, 30 Apr 2022 13:19:59 +0000
From: Vladimir Oltean <vladimir.oltean@....com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
CC: Kurt Kanzenbach <kurt@...utronix.de>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Jakub Kicinski <kuba@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
Paolo Abeni <pabeni@...hat.com>,
Eric Dumazet <edumazet@...gle.com>,
Florian Fainelli <f.fainelli@...il.com>,
Vivien Didelot <vivien.didelot@...il.com>,
Andrew Lunn <andrew@...n.ch>,
Claudiu Manoil <claudiu.manoil@....com>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
"UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>,
Vinicius Costa Gomes <vinicius.gomes@...el.com>,
Gerhard Engleder <gerhard@...leder-embedded.com>,
"Y.B. Lu" <yangbo.lu@....com>,
Xiaoliang Yang <xiaoliang.yang_1@....com>,
Richard Cochran <richardcochran@...il.com>,
Yannick Vignon <yannick.vignon@....com>,
Rui Sousa <rui.sousa@....com>, Jiri Pirko <jiri@...dia.com>,
Ido Schimmel <idosch@...dia.com>
Subject: Re: [PATCH net-next] selftests: forwarding: add Per-Stream Filtering
and Policing test for Ocelot
Hi Sebastian,
On Fri, Apr 29, 2022 at 04:30:47PM +0200, Sebastian Andrzej Siewior wrote:
> On 2022-04-29 11:00:39 [+0000], Vladimir Oltean wrote:
> > > I agree. Nevertheless, having a standardized tool for this kind latency
> > > testing would be nice. For instance, cyclictest is also not part of the
> > > kernel, but packaged for all major Linux distributions.
> >
> > Right, the thing is that I'm giving myself the liberty to still make
> > backwards-incompatible changes to isochron until it reaches v1.0 (right
> > now it's at v0.7 + 14 patches, so v0.8 should be coming rather soon).
> > I don't really want to submit unstable software for inclusion in a
> > distro (plus I don't know what distros would be interested in TSN
> > testing, see above).
>
> Users of those distros, that need to test TSN, will be interested in
> having it packaged rather than having it to compile first. Just make it
> available, point to it in tests etc. and it should get packaged.
>
> > And isochron itself needs to become more stable by gathering more users,
> > being integrated in scripts such as selftests, catering to more varied
> > requirements.
> > So it's a bit of a chicken and egg situation.
> If it is completely experimental then it could be added to, say,
> Debian's experimental distribution so user's of unstable/sid can install
> it fairly easy but it won't become part of the upcoming stable release
> (the relevant freeze is currently set to 2023-02).
>
> Sebastian
If I get you right, you're saying it would be preferable to submit
isochron for inclusion in Debian Testing.
Ok, I've submitted an Intent To Package:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010396
but if you don't mind, I'd still like to proceed with v2 right away,
since the process of getting isochron packaged by Debian is essentially
unbounded and I wouldn't like to create a dependency between packaging
and this selftest. There is already a link to the Github repo in
tsn_lib.sh, I expect people are still going to get it from there for a
while. I will also make the dependency optional via a REQUIRE_ISOCHRON
variable, as discussed with Kurt. I hope that's ok.
Powered by blists - more mailing lists