I want to know where is the TSN implementation code for LS1021ATSN and LS1028ABSP? about openil_linux

[vladimiroltean]

In order to be effective, TSN features are implemented in the hardware data path. The software just configures and enables them, but the software is not otherwise involved in the packet processing path by default.

If your questions was "where is the TSN configuration code" instead, the answer is:

• For LS1021A-TSN: sja1105-tool (user space only)
• For LS1028A-RDB: tsntool in the user space side, drivers/net/ethernet/freescale/enetc/enetc_tsn.c (for ENETC) and drivers/net/ethernet/mscc/tsn_switch.c (for Felix) in the kernel side.

[niceniu]

Thank you for your answer. I still have a question. I saw you mention taprio in other comments. As far as I know, taprio is one of the modules of the Intel team to implement TSN in software. The Intel team claims that taprio does not require hardware support. Yes, so I think Intel's solution is to implement TSN in the kernel. I also found the corresponding taprio.c code in the net-next kernel. I think these codes are the code to implement TSN. Is my guess wrong? ? Now that you have implemented TSN on a special chip, why did you transplant these modules from Intel?

[vladimiroltean]

One of the things we realized after the first wave of drivers for our TSN hardware is the importance of user space API compatibility (at the moment not even sja1105 is compatible with enetc or felix). It is useful to have generic user space programs that use generic concepts (e.g. open a socket on a net device and start streaming data, or configure certain egress shaping parameters for real-time scheduling, etc), that were not originally written for particular hardware but nonetheless work. The role of the kernel is to offer a universal abstraction over hardware, which is what user space should work with.
In the particular case of 802.1Qbv which you are mentioning, since it is an egress scheduling mechanism, it falls under the class of queuing disciplines (qdisc) for which the Linux kernel already has a rich configuration structure, with the tc program from iproute2. With this model, qdiscs can even be stacked if they are classful (e.g. you can have a qdisc class for each traffic class of the root qdisc, onto which you can attach another qdisc etc). So there was value in modeling 802.1Qbv as a tc qdisc, if you want for example to also configure CBS on traffic classes 7 and 6.
Intel has never claimed that tc-taprio is only for TSN implemented in software. To keep the tc abstraction in place, any qdisc should have at least a software implementation (and up until rather recently, the software implementation was the only one to exist). If the hardware is able of doing this task more efficiently, then the qdisc can be offloaded to hardware, and the abstraction is kept. The new wave of TSN drivers for the NXP hardware is trying to use this qdisc offloading ability. So it behaves just as it would on non-TSN hardware with software implementation, just that the gates are more precise etc.
In the case of a network switch, you can argue that 802.1Qbv features cannot be emulated in software, because on an egress port it sends not just traffic coming from the CPU, but also from other switch ports over which the CPU has no control. But this is actually consistent with the abstraction for L2 forwarding itself (switchdev net devices enslaved to a bridge will do forwarding offloaded in hardware). When L2 forwarding offload is not enabled, a switch should send all frames to the CPU, where software bridging will happen and they will get re-injected on the correct switch port. In this case, the bridge offload and the taprio offload are consistent with one another, and the bridge software implementation is also consistent with the taprio software implementation.
There are also TSN features which are not useful to be described as qdiscs, since they cannot have a software implementation. Frame preemption comes to mind here. For these, we are thinking of ethtool as the correct abstraction to enable hardware-only features.
Hope this clarifies.