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