Re: TSN: taprio scheduler

[Vinicius Costa Gomes <vinicius.gomes@intel.com>]

Hi Murali,

Murali Karicheri <m-karicheri2@ti.com> writes:

> Hi Vinicius,
>
> My name is Murali Karicheri from Texas Instruments Ltd. We have 
> AM65x/DRA80xMProcessor, that is capable of supporting TSN. Our solution 
> would use the ICSSG_PRU which is a fully programmable industrial 
> communication subsystems to enable future-proof designs for customers 
> that need to adopt the new Gigabit Time-sensitive 
> Networks(TSN)standards. More details can be seen in the TRM at 
> http://www.ti.com/lit/ug/spruid7c/spruid7c.pdf
>

Really glad to see more people interested in TSN. Will take a look at
that datasheet to see if the interface I will propose will turn to be
too awkward for those devices.

> I am part of the team that is working to implement IEEE Std 802.1Qbv 
> scheduler (Time aware Shaper) with Frame pre-emption capabilities in a 
> RT Linux based solution. I saw your commit for taprio which adds basic 
> support in Linux and is a good starting point for me.
>
> commit 5a781ccbd19e4664babcbe4b4ead7aa2b9283d22
> Author: Vinicius Costa Gomes <vinicius.gomes@intel.com>
> Date:   Fri Sep 28 17:59:43 2018 -0700
>
>      tc: Add support for configuring the taprio scheduler
>
> Also went through https://lwn.net/Articles/767383/
>
> Basically wondering what is the current status of the following under 
> "Future work" in the above link and also to explore if we could 
> collaborate on developing missing pieces.
>
> ===== from  https://lwn.net/Articles/767383/ =======================
>    - Add support for multiple schedules, so something like the Admin
>      and Oper schedules from IEEE 802.1Q-2018 can be implemented,
>      probably "cycle-time" will be re-implemented at this time;
>
>    - Add support for HW offloading;
>
>    - Add support for Frame Preemption related commands (formerly
>      802.1Qbu, now part of 802.1Q);
> ======================================================================

The series that I planning to send this week has some ideas about how to
solve all these three points. But for hardware offloading and frame
preemption, all I will propose is the interface for talking to the
driver.

>
> To begin with I am currently exploring how to test this software 
> implementation of taprio and what are all the dependencies.
>
> Do I need multi-q support in the Ethernet driver to test taprio? Looks 
> like it is needed. What else is needed to test this feature? If you have 
> any additional patches that you have tested, that would help for my 
> initial ramp.

Yes, for now, the only requirement is a multiqueue device. And thinking
a little more, even that may be lifted for the software only mode, with
some work.

About testing, to make things easier to test we grouped some READMEs and
scripts in this gist, perhaps it can help you on your experiments:

https://gist.github.com/jeez/bd3afeff081ba64a695008dd8215866f

See if helps.


Cheers,
--
Vinicius