[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200506082139.58dff261@hermes.lan>
Date: Wed, 6 May 2020 08:21:39 -0700
From: Stephen Hemminger <stephen@...workplumber.org>
To: Po Liu <Po.Liu@....com>
Cc: dsahern@...il.com, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, vinicius.gomes@...el.com,
davem@...emloft.net, vlad@...lov.dev, claudiu.manoil@....com,
vladimir.oltean@....com, alexandru.marginean@....com
Subject: Re: [v4,iproute2-next 1/2] iproute2-next:tc:action: add a gate
control action
On Wed, 6 May 2020 16:40:19 +0800
Po Liu <Po.Liu@....com> wrote:
> } else if (matches(*argv, "base-time") == 0) {
> + NEXT_ARG();
> + if (get_u64(&base_time, *argv, 10)) {
> + invalidarg = "base-time";
> + goto err_arg;
> + }
> + } else if (matches(*argv, "cycle-time") == 0) {
> + NEXT_ARG();
> + if (get_u64(&cycle_time, *argv, 10)) {
> + invalidarg = "cycle-time";
> + goto err_arg;
> + }
> + } else if (matches(*argv, "cycle-time-ext") == 0) {
> + NEXT_ARG();
> + if (get_u64(&cycle_time_ext, *argv, 10)) {
> + invalidarg = "cycle-time-ext";
> + goto err_arg;
> + }
Could all these time values use existing TC helper routines?
See get_time(). The way you have it makes sense for hardware
but stands out versus the rest of tc.
It maybe that the kernel UAPI is wrong, and should be using same
time units as rest of tc. Forgot to review that part of the patch.
Powered by blists - more mailing lists