Re: [v1,net-next, 1/2] ethtool: add setting frame preemption of traffic classes

[Murali Karicheri <m-karicheri2@ti.com>]

Hi,


On 01/23/2020 12:50 PM, Vinicius Costa Gomes wrote:
> Hi,
> 
> Vladimir Oltean <olteanv@gmail.com> writes:
> 
>> Hi Murali,
>>
>> On Wed, 22 Jan 2020 at 20:04, Murali Karicheri <m-karicheri2@ti.com> wrote:
>>>
>>> I have question about the below parameters in The Gate Parameter Table
>>> that are not currently supported by tc command. Looks like they need to
>>> be shown to user for management.
>>>
>>>       - ConfigChange - Looks like this needs to be controlled by
>>>         user. After sending admin command, user send this trigger to start
>>>         copying admin schedule to operation schedule. Is this getting
>>>         added to tc command?
>>
>> "The ConfigChange parameter signals the start of a
>> configuration change for the gate
>> when it is set to TRUE. This should only be done
>> when the various administrative parameters
>> are all set to appropriate values."
>>
>> As far as my understanding goes, all tc-taprio commands currently
>> behave as though this boolean is implicitly set to TRUE after the
>> structures have been set up. I'm not sure there is any value in doing
>> otherwise.
>>
>>>       - ConfigChangeTime - The time at which the administrative variables
>>>         that determine the cycle are to be copied across to the
>>>         corresponding operational variables, expressed as a PTP timescale
>>
>> This is the base-time of the admin schedule, no?
>>
>> "The PTPtime at which the next config change is scheduled to occur.
>> The value is a representation of a PTPtime value,
>> consisting of a 48-bit integer
>> number of seconds and a 32-bit integer number of nanoseconds."
>>
>>>       - TickGranularity - the management parameters specified in Gate
>>>         Parameter Table allow a management station to discover the
>>>         characteristics of an implementation’s cycle timer clock
>>>         (TickGranularity) and to set the parameters for the gating cycle
>>>         accordingly.
>>
>> Not sure who is going to use this and for what purpose, but ok.
>>
>>>       - ConfigPending - A Boolean variable, set TRUE to indicate that
>>>         there is a new cycle configuration awaiting installation.
>>
>> I had tried to export something like this (driver calls back into
>> sch_taprio.c when hw has applied the config, this would result in
>> ConfigPending = FALSE), but ultimately didn't finish the idea, and it
>> caused some problems too, due to incorrect RCU usage.
>>
> 
> If this should be exported, this should be done from taprio, perhaps
> adding a new field to what is exported via the dump() callback, which
> should be quite easy.
>
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!

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

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

Regards,

Murali
>>
>>> Regards,
>>>
>>> Murali
>>>
>>> --
>>> Murali Karicheri
>>> Texas Instruments
>>
>> Thanks,
>> -Vladimir
> 
> Cheers,
> --
> Vinicius
> 

-- 
Murali Karicheri
Texas Instruments