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?
