Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: z7PGyBtN0m1w1Trdy4Iw9ZiOw5G/9AfMrzqGDuCKyo30O3sHaFmWHt6wZihosFBZZc9ys4JzLK
 63unZUpamyXo2J2hj7xRVOhCklNspn7Pc4cJuSBBsOZ/ynrr68lvLlbg8ls9rJYKjm5Ch4mQ6q
 FW6MSKz5lMUAEly08vcC6s79eefmcUh9WN2zhCW4Di5lwdp/SLbA6DxHCWdGR6TlIPNjAaF6gK
 KGkuzkZqRHBFQpLeEQW/zuSpw8VDkWTUwhzhvUp9NmGJS/gD0mJvVKUdJXs1jISgletzUsV70A
 HHU=
Date:   Wed, 22 Apr 2020 21:19:10 +0200
From:   "Allan W. Nielsen" <allan.nielsen@microchip.com>
To:     Po Liu <Po.Liu@nxp.com>
CC:     <davem@davemloft.net>, <linux-kernel@vger.kernel.org>,
        <netdev@vger.kernel.org>, <vinicius.gomes@intel.com>,
        <claudiu.manoil@nxp.com>, <vladimir.oltean@nxp.com>,
        <alexandru.marginean@nxp.com>, <michael.chan@broadcom.com>,
        <vishal@chelsio.com>, <saeedm@mellanox.com>, <leon@kernel.org>,
        <jiri@mellanox.com>, <idosch@mellanox.com>,
        <alexandre.belloni@bootlin.com>, <UNGLinuxDriver@microchip.com>,
        <kuba@kernel.org>, <jhs@mojatatu.com>, <xiyou.wangcong@gmail.com>,
        <simon.horman@netronome.com>, <pablo@netfilter.org>,
        <moshe@mellanox.com>, <m-karicheri2@ti.com>,
        <andre.guedes@linux.intel.com>, <stephen@networkplumber.org>
Subject: Re: [v3,net-next  1/4] net: qos: introduce a gate control flow action
Message-ID: <20200422191910.gacjlviegrjriwcx@ws.localdomain>
References: <20200418011211.31725-5-Po.Liu@nxp.com>
 <20200422024852.23224-1-Po.Liu@nxp.com>
 <20200422024852.23224-2-Po.Liu@nxp.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Disposition: inline
In-Reply-To: <20200422024852.23224-2-Po.Liu@nxp.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Po,

Nice to see even more work on the TSN standards in the upstream kernel.

On 22.04.2020 10:48, Po Liu wrote:
>EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
>Introduce a ingress frame gate control flow action.
>Tc gate action does the work like this:
>Assume there is a gate allow specified ingress frames can be passed at
>specific time slot, and be dropped at specific time slot. Tc filter
>chooses the ingress frames, and tc gate action would specify what slot
>does these frames can be passed to device and what time slot would be
>dropped.
>Tc gate action would provide an entry list to tell how much time gate
>keep open and how much time gate keep state close. Gate action also
>assign a start time to tell when the entry list start. Then driver would
>repeat the gate entry list cyclically.
>For the software simulation, gate action requires the user assign a time
>clock type.
>
>Below is the setting example in user space. Tc filter a stream source ip
>address is 192.168.0.20 and gate action own two time slots. One is last
>200ms gate open let frame pass another is last 100ms gate close let
>frames dropped. When the frames have passed total frames over 8000000
>bytes, frames will be dropped in one 200000000ns time slot.
>
>> tc qdisc add dev eth0 ingress
>
>> tc filter add dev eth0 parent ffff: protocol ip \
>           flower src_ip 192.168.0.20 \
>           action gate index 2 clockid CLOCK_TAI \
>           sched-entry open 200000000 -1 8000000 \
>           sched-entry close 100000000 -1 -1

First of all, it is a long time since I read the 802.1Qci and when I did
it, it was a draft. So please let me know if I'm completly off here.

I know you are focusing on the gate control in this patch serie, but I
assume that you later will want to do the policing and flow-meter as
well. And it could make sense to consider how all of this work
toghether.

A common use-case for the policing is to have multiple rules pointing at
the same policing instance. Maybe you want the sum of the traffic on 2
ports to be limited to 100mbit. If you specify such action on the
individual rule (like done with the gate), then you can not have two
rules pointing at the same policer instance.

Long storry short, have you considered if it would be better to do
something like:

   tc filter add dev eth0 parent ffff: protocol ip \
            flower src_ip 192.168.0.20 \
            action psfp-id 42

And then have some other function to configure the properties of psfp-id
42?


/Allan