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?