netdev - Re: TSN: taprio scheduler

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ec16e0a9-19ff-cf7a-8917-a07b2de3f79c@ti.com>
Date:   Wed, 27 Mar 2019 15:29:44 -0400
From:   Murali Karicheri <m-karicheri2@...com>
To:     Vinicius Costa Gomes <vinicius.gomes@...el.com>,
        <netdev@...r.kernel.org>
Subject: Re: TSN: taprio scheduler

Hi Vinicius,

On 03/26/2019 05:02 PM, Vinicius Costa Gomes wrote:
> Hi Murali,
> 
> Murali Karicheri <m-karicheri2@...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.
> 
Glad to hear from you too! But you may not find much details in the TRM
as the TSN features are implemented in ICSSG_PRU firmware. We are in the
process of defining the interfaces to firmware to configure TAS 
initially and followed by Preemption.

You would find details of ICSSG_PRU at
http://www.ti.com/lit/ug/spruid7c/spruid7c.pdf#%5B%7B%22num%22%3A320%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C0%2C718%2C0%5D

This is a multi-core IP with 4 RISC core which runs the firmware. So
we have flexibility in modifying the firmware for any future changes.
The Ethernet driver manages ICSSG_PRU.

>> 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@...el.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.
> 
Great!

Our initial focus is to support TAS and frame preemption follows later.
Will review your proposal internally and provide feedback if any.
I may add more people from TI to the discussion as needed.
>>
>> 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.

Ok

Regards,

Murali
> 
> 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
>