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

From: Vinicius Costa Gomes <[email-masked]>
Date: Thu, 23 Jan 2020 09:50:54 -0800

Hi,

Vladimir Oltean <[email-masked]> writes:

> Hi Murali,
>
> On Wed, 22 Jan 2020 at 20:04, Murali Karicheri <[email-masked]> 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.

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

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

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

Cheers,
--
Vinicius