[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230217130739.flqby6ok3wh5mklw@skbuf>
Date: Fri, 17 Feb 2023 15:07:39 +0200
From: Vladimir Oltean <vladimir.oltean@....com>
To: Ferenc Fejes <fejes@....elte.hu>
Cc: peti.antal99@...il.com, "andrew@...n.ch" <andrew@...n.ch>,
Claudiu Manoil <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 <yannick.vignon@....com>,
Xiaoliang Yang <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>,
"Y.B. Lu" <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 <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 Ferenc,
On Fri, Feb 17, 2023 at 09:03:30AM +0100, Ferenc Fejes wrote:
> I agree, it takes time to guess what the intention behind the wording
> of the standard in some cases. I have the standard in front of me right
> now and its 2163 pages... Even if I grep to IPV, the context is
> overwhelmingly dense.
>
(...)
> I'll try to ask around too, thanks for pointing this out. My best
> understanding from the IPV that the standard treat it as skb->priority.
> It defines IPV as a 32bit signed value, which clearly imply similar
> semantics as skb->priority, which can be much larger than the number of
> the queues or traffic classes.
What would you say if we made the software act_gate implementation
simply alter skb->priority, which would potentially affect more stuff
including the egress-qos-map of a VLAN device in the output path of the
skb? It would definitely put less pressure on the networking data
structures, at the price of leaving an exceedingly unlikely case
uncovered.
> Oh, alright. I continue to think about alternatives over introducing
> new members into sk_buff. It would be very nice to have proper act_gate
> IPV handling without hardware offload. Its great to see the support of
> frame preemption and PSFP support in more and more hardware but on the
> other hand it makes the lack of the proper software mode operation more
> and more awkward.
I'm not sure that cyclic queuing and forwarding done with software
forwarding is going to be that practical anyway?
Powered by blists - more mailing lists