Hi Vladimir! On Fri, 2023-02-17 at 15:07 +0200, Vladimir Oltean wrote: > 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. This is exactly what I just started to write in my reply! Yes, this would be the right choice. The key here is the "exceedingly unlikely case" what you just mentioned. If you are lucky enough to have the luxury to think about cases where the IPV mapping should only affect the queueing and not the egress-qos- map, it would be nice to have options. Sadly mqprio and taprio classless, so you can't do the following as far as I understand it: 1. Configure tc act_gate with IPV-s like 0, 1, 2, etc. 2. Configure mqprio/taprio with prio to tc mapping for 0, 1, 2, etc. 3. As mqprio/taprio leaf-s you can apply tc skbedit/bpf direct actions which altering the skb->priority to values you would like to see at egress-to-qos mapping 4. The egress-to-qos mapping act on the new skb->priority However what if mqprio/taprio can read prio:tc map like: tc qdisc add dev eth0 root mqprio num_tc 4 map 1000:0 1001:1 1000:2 1003:3 queues 1@0 1@1 1@2 1@3 hw 0 I think that dont necessarily break the existing script since we can check if ":" if in the map parameters or not. That way skb->priority ---> tc would be flexible (as in egress-qos- map), the tc ---> queue mapping flexible too, and the original skb- >priority can control the egress-qos-map differently than the queueing that way. I miss something fundamental here? > > > 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? VNFs can perform PSFP as well or at least reprioritize the packets. Also it would be handy for selftests too. Other than that future driver implementers can verify their operation with the software behavior. Best, Ferenc
