netdev - Re: [PATCH v2 net-next] selftests: forwarding: add Per-Stream Filtering and Policing test for Ocelot

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 26 May 2022 06:40:22 +0000
From:   Ferenc Fejes <ferenc.fejes@...csson.com>
To:     "vladimir.oltean@....com" <vladimir.oltean@....com>
CC:     "andrew@...n.ch" <andrew@...n.ch>,
        "claudiu.manoil@....com" <claudiu.manoil@....com>,
        "vivien.didelot@...il.com" <vivien.didelot@...il.com>,
        "vinicius.gomes@...el.com" <vinicius.gomes@...el.com>,
        "shuah@...nel.org" <shuah@...nel.org>,
        "bigeasy@...utronix.de" <bigeasy@...utronix.de>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "yannick.vignon@....com" <yannick.vignon@....com>,
        "xiaoliang.yang_1@....com" <xiaoliang.yang_1@....com>,
        "UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "richardcochran@...il.com" <richardcochran@...il.com>,
        "idosch@...dia.com" <idosch@...dia.com>,
        "gerhard@...leder-embedded.com" <gerhard@...leder-embedded.com>,
        "yangbo.lu@....com" <yangbo.lu@....com>,
        "jiri@...dia.com" <jiri@...dia.com>,
        "alexandre.belloni@...tlin.com" <alexandre.belloni@...tlin.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "kurt@...utronix.de" <kurt@...utronix.de>,
        "rui.sousa@....com" <rui.sousa@....com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>
Subject: Re: [PATCH v2 net-next] selftests: forwarding: add Per-Stream
 Filtering and Policing test for Ocelot

Hi Vladimir!

On Thu, 2022-05-26 at 00:50 +0000, Vladimir Oltean wrote:
> On Fri, May 06, 2022 at 12:24:37PM +0000, Ferenc Fejes wrote:
> > Hi Vladimir!
> > 
> > On 2022. 05. 06. 14:01, Vladimir Oltean wrote:
> > > Hi Ferenc,
> > > 
> > > On Fri, May 06, 2022 at 07:49:40AM +0000, Ferenc Fejes wrote:
> > > This is correct. I have been testing only with the offloaded tc-
> > > gate
> > > action so I did not notice that the software does not act upon
> > > the ipv.
> > > Your proposal sounds straightforward enough. Care to send a bug
> > > fix patch?
> > 
> > Unfortunately I cant, our company policy does not allow direct 
> > open-source contributions :-(
> > 
> > However I would be more than happy if you can fix it.
> 
> That's too bad.
> 
> I have a patch which I am still testing, but you've managed to
> captivate
> my attention for saying that you are testing 802.1Qch with a software
> implementation of tc-gate.
> 
> Do you have a use case for this? What cycle times are you targeting?
> How are you ensuring that you are deterministically meeting the
> deadlines?

The cycle times I targeted were nowhere near to a realistic TSN
scenario:
I "generated" ping packets in every 100 msecs and on the ingress port
and I marked them with prio 1 for 500ms (gate 1) and prio 2 for another
500ms (gate 2). On the egress port I applied taprio with the same base-
time and same 500-500ms cycles but reverse ordered gates (that's the
"definition" of the Qch), so while act_gate on the ingress is in gate 1
cycle, the taprio kept open gate 2 and gate 1 closed, etc.
For "verification" I simply run a tcpdump on the listener machine what
I pinged from the talker and eyeballed wether the 5-5 packets bursts
shows up arrival timestamps.

> Do you also have a software tc-taprio on the egress device or is that
> at least offloaded?

No, I experimented with the software version, but that worked with my
netns tests and on physical machines too (after the IPV patch).

> 
> I'm asking these questions because the peristaltic shaper is
> primarily
> intended to be used on hardware switches. The patch I'm preparing
> includes changes to struct sk_buff. I just want to know how well I'll
> be
> able to sell these changes to maintainers strongly opposing the
> growth
> of this structure for an exceedingly small niche :)

Can you tell me about the intention behind the sk_buff changes? Does
that required because of some offloading scenario? In my case putting
the IPV into the skb->priority was good enough because the taprio using
that field by default to select the traffic class for the packet.

Thanks,
Ferenc