Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20191127094517.6255-1-Po.Liu@nxp.com> <87v9p93a2s.fsf@linux.intel.com>
 <9b13a47e-8ca3-66b0-063c-798a5fa71149@ti.com>
In-Reply-To: <9b13a47e-8ca3-66b0-063c-798a5fa71149@ti.com>
From:   Vladimir Oltean <olteanv@gmail.com>
Date:   Thu, 23 Jan 2020 15:30:16 +0200
Message-ID: <CA+h21hqk2pCfrQg5kC6HzmL=eEqJXjuRsu+cVkGsEi8OXGpKJA@mail.gmail.com>
Subject: Re: [v1,net-next, 1/2] ethtool: add setting frame preemption of
 traffic classes
To:     Murali Karicheri <m-karicheri2@ti.com>
Cc:     Vinicius Costa Gomes <vinicius.gomes@intel.com>,
        Po Liu <po.liu@nxp.com>,
        "davem@davemloft.net" <davem@davemloft.net>,
        "hauke.mehrtens@intel.com" <hauke.mehrtens@intel.com>,
        "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
        "allison@lohutok.net" <allison@lohutok.net>,
        "tglx@linutronix.de" <tglx@linutronix.de>,
        "hkallweit1@gmail.com" <hkallweit1@gmail.com>,
        "saeedm@mellanox.com" <saeedm@mellanox.com>,
        "andrew@lunn.ch" <andrew@lunn.ch>,
        "f.fainelli@gmail.com" <f.fainelli@gmail.com>,
        "alexandru.ardelean@analog.com" <alexandru.ardelean@analog.com>,
        "jiri@mellanox.com" <jiri@mellanox.com>,
        "ayal@mellanox.com" <ayal@mellanox.com>,
        "pablo@netfilter.org" <pablo@netfilter.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "simon.horman@netronome.com" <simon.horman@netronome.com>,
        Claudiu Manoil <claudiu.manoil@nxp.com>,
        Vladimir Oltean <vladimir.oltean@nxp.com>,
        Alexandru Marginean <alexandru.marginean@nxp.com>,
        Xiaoliang Yang <xiaoliang.yang_1@nxp.com>,
        Roy Zang <roy.zang@nxp.com>, Mingkai Hu <mingkai.hu@nxp.com>,
        Jerry Huang <jerry.huang@nxp.com>, Leo Li <leoyang.li@nxp.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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=E2=80=99s 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 =3D FALSE), but ultimately didn't finish the idea, and it
caused some problems too, due to incorrect RCU usage.

>      - ConfigChangeError - Error in configuration (AdminBaseTime <
>        CurrentTime)

This can be exported similarly.

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

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.

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

Thanks,
-Vladimir