netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* TSN: taprio scheduler
@ 2019-03-26 20:30 Murali Karicheri
  2019-03-26 21:02 ` Vinicius Costa Gomes
  0 siblings, 1 reply; 5+ messages in thread
From: Murali Karicheri @ 2019-03-26 20:30 UTC (permalink / raw)
  To: vinicius.gomes, netdev

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

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);
======================================================================

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.

Thanks and regards,

Murali


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: TSN: taprio scheduler
  2019-03-26 20:30 TSN: taprio scheduler Murali Karicheri
@ 2019-03-26 21:02 ` Vinicius Costa Gomes
  2019-03-27 19:29   ` Murali Karicheri
  2019-04-17  7:55   ` Jose Abreu
  0 siblings, 2 replies; 5+ messages in thread
From: Vinicius Costa Gomes @ 2019-03-26 21:02 UTC (permalink / raw)
  To: Murali Karicheri, netdev

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: TSN: taprio scheduler
  2019-03-26 21:02 ` Vinicius Costa Gomes
@ 2019-03-27 19:29   ` Murali Karicheri
  2019-04-17  7:55   ` Jose Abreu
  1 sibling, 0 replies; 5+ messages in thread
From: Murali Karicheri @ 2019-03-27 19:29 UTC (permalink / raw)
  To: Vinicius Costa Gomes, netdev

Hi Vinicius,

On 03/26/2019 05:02 PM, Vinicius Costa Gomes wrote:
> 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.
> 
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@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.
> 
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
> 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: TSN: taprio scheduler
  2019-03-26 21:02 ` Vinicius Costa Gomes
  2019-03-27 19:29   ` Murali Karicheri
@ 2019-04-17  7:55   ` Jose Abreu
  2019-04-17 15:57     ` Vinicius Costa Gomes
  1 sibling, 1 reply; 5+ messages in thread
From: Jose Abreu @ 2019-04-17  7:55 UTC (permalink / raw)
  To: Vinicius Costa Gomes, Murali Karicheri, netdev

From: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Date: Tue, Mar 26, 2019 at 21:02:43

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

Was this sent ?

I have some setups that support Frame Preemption, EST and Time-Based 
Scheduling.

Thanks,
Jose Miguel Abreu

^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: TSN: taprio scheduler
  2019-04-17  7:55   ` Jose Abreu
@ 2019-04-17 15:57     ` Vinicius Costa Gomes
  0 siblings, 0 replies; 5+ messages in thread
From: Vinicius Costa Gomes @ 2019-04-17 15:57 UTC (permalink / raw)
  To: Jose Abreu, Murali Karicheri, netdev

Hi,

Jose Abreu <Jose.Abreu@synopsys.com> writes:

> From: Vinicius Costa Gomes <vinicius.gomes@intel.com>
> Date: Tue, Mar 26, 2019 at 21:02:43
>
>> 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.
>
> Was this sent ?

Yes, here's the link to the cover letter of the RFC:

http://patchwork.ozlabs.org/cover/1082982/

>
> I have some setups that support Frame Preemption, EST and Time-Based 
> Scheduling.
>
> Thanks,
> Jose Miguel Abreu


Cheers,
--
Vinicius

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2019-04-17 15:57 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-26 20:30 TSN: taprio scheduler Murali Karicheri
2019-03-26 21:02 ` Vinicius Costa Gomes
2019-03-27 19:29   ` Murali Karicheri
2019-04-17  7:55   ` Jose Abreu
2019-04-17 15:57     ` Vinicius Costa Gomes

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).