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
