Hi Vinicius,

On 02/11/2020 02:22 PM, Vinicius Costa Gomes wrote:

Murali Karicheri [off-list ref] writes:

quoted

We are still working to send a patch for taprio offload on our hardware
and it may take a while to get to this. So if someone can help to add
the required kernel/driver interface for this, that will be great!

Will add this to my todo list. But if anyone else has the spare cycles
feel free to have a go at it.

Thanks! We have made some progress in sending the base driver to netdev
list now https://lkml.org/lkml/2020/2/22/157

This device is taprio offload capable. Next step is to add taprio
offload to this driver. Then other features will follow.

quoted

quoted

quoted

quoted

       - ConfigChangeError - Error in configuration (AdminBaseTime <
         CurrentTime)

This can be exported similarly.

In my view, having this as a "runtime" error is not useful, as we can
verify this at configuration time.

Looks like this is not an error per 802.1Q standard if I understood it
correctly.

This is what I see.
=======================================================================
  From 802.1Q 2018, 8.6.9.1.1 SetCycleStartTime()

If AdminBaseTime is set to the same time in the past in all bridges and
end stations, OperBaseTime is always in the past, and all cycles start
synchronized. Using AdminBaseTime in the past is appropriate when you
can start schedules prior to starting the application that uses the
schedules. Use of AdminBaseTime in the future is intended to change a
currently running schedule in all bridges and end stations to a new
schedule at a future time. Using AdminBaseTime in the future is
appropriate when schedules must be changed without stopping the
application
========================================================================

What I meant here is the case that I already have an "oper" schedule
running, so my "oper->base_time" is in the past, and I try to add an
"admin" schedule with a "base_time" also in the past. What's the
expected behavior in this case? The text about stopping/starting
applications doesn't seem to apply to the way the tc subsystem interacts
with the applications.

 > I try to add an "admin" schedule with a "base_time" also in the past.
 > What's the expected behavior in this case?

Ok got it. I don't think this behavior is explained in the spec. I would
assume a sane thing to do is to switch to admin schedule if 
admin->base_time is newer than oper->base_time and flag
the ConfigChangeError to be compliant to the spec, but frankly speaking
I don't know how application is going to use this. It is a low priority
item IMO and can be added as needed.

Regards,

Murali

quoted

quoted

quoted

quoted

       - SupportedListMax - Maximum supported Admin/Open shed list.

Is there a plan to export these from driver through tc show or such
command? The reason being, there would be applications developed to
manage configuration/schedule of TSN nodes that would requires these
information from the node. So would need a support either in tc or
some other means to retrieve them from hardware or driver. That is my
understanding...

Hm, now I understamd what you meant here...

quoted

Not sure what answer you expect to receive for "is there any plan".
You can go ahead and propose something, as long as it is reasonably
useful to have.

... if this is indeed useful, perhaps one way to do is to add a subcommand
to TC_SETUP_QDISC_TAPRIO, so we can retrieve the stats/information we want
from the driver. Similar to what cls_flower does.

What I understand is that there will be some work done to allow auto
configuration of TSN nodes from user space and that would need access to
all or some of the above parameters along with tc command to configure
the same. May be a open source project for this or some custom
application? Any such projects existing??

Yeah, this is a big missing piece for TSN. I've heard 'netopeer2' and
'sysrepo' mentioned when similar questions were asked, but I have still
to take a look at them and see what's missing. (Or if they are the right
tool for the job)

-- 
Murali Karicheri
Texas Instruments