Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support of Intel i225 TAPRIO Offload Feature #21

Open
rezabfil-sec opened this issue Feb 13, 2024 · 2 comments
Open

Support of Intel i225 TAPRIO Offload Feature #21

rezabfil-sec opened this issue Feb 13, 2024 · 2 comments

Comments

@rezabfil-sec
Copy link

Hello,

We are considering using isochron for our evaluations and I am wondering if it also supports the TAPRIO in HW offload (flags 0x2 https://man7.org/linux/man-pages/man8/tc-taprio.8.html) for these scenarios:

  1. running isochron in simple Point-to-Point topology
  2. Running isochron for more than P2P where the next hop is also a Linux machine equipped with Intel i225.

Option 1. should be pretty straightforward based on the docs, but I am unsure about the second option. If I understand the flags 0x2, the application has to specify txtime itself and then pass it to the NIC. That would mean that isochron would need to receive the packet and also handle its forwarding on each additional hop. Am I correct?

Thanks for your time and clarifications!

@vladimiroltean
Copy link
Contributor

If I understand the flags 0x2, the application has to specify txtime itself and then pass it to the NIC

Not exactly so. The application just passes the buffer to the kernel using the sendto() syscall, and the kernel/NIC decides its transmission time based on the current time, the installed schedule and the traffic class that the packet gets classified to (via SO_PRIORITY or other mechanisms to influence skb->priority, like tc-skbedit).

That would mean that isochron would need to receive the packet and also handle its forwarding on each additional hop.

This program does not do forwarding. However, this is not to say that it is only for simple point-to-point topologies. It just is intended to be run on endpoints. In the situations I have needed isochron over multiple hops, the forwarding was handled by the Linux bridge, either in the kernel software path or directly offloaded to hardware (through switchdev and such). So there was no need for the packet to be passed to user space (isochron) and user space to decide where and when to forward it. If you could explain your use case in more detail, maybe I could reconsider this.

@rezabfil-sec
Copy link
Author

Thank you for getting back to me so quickly.

Sure, our use-case is that we have multiple hops with OvS on each hop and would like to run isochron on the source and sink, while shaping the traffic on each hop using I225 with TAPRIO in offload mode - we already have a working setup with 0x1 flags using the iperf3, but would like to test with TAPRIO with flags 0x2. The packets have VLAN headers and the traffic priority is in the PCP field of the VLAN header to achieve proper prioritization on the hops. Each hop has configured qdisc with tc. The setup is used to evaluate various TSN applications using COTS HW.

Thank you for looking into it and if you think the isochron can be actually used for such evalatuations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants