Message-ID: <VE1PR04MB64968B11D1F7AAD2FE7A7BC692D30@VE1PR04MB6496.eurprd04.prod.outlook.com>
Date:   Thu, 23 Apr 2020 03:27:02 +0000
From:   Po Liu <po.liu@....com>
To:     "Allan W. Nielsen" <allan.nielsen@...rochip.com>
CC:     "davem@...emloft.net" <davem@...emloft.net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "vinicius.gomes@...el.com" <vinicius.gomes@...el.com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Vladimir Oltean <vladimir.oltean@....com>,
        Alexandru Marginean <alexandru.marginean@....com>,
        "michael.chan@...adcom.com" <michael.chan@...adcom.com>,
        "vishal@...lsio.com" <vishal@...lsio.com>,
        "saeedm@...lanox.com" <saeedm@...lanox.com>,
        "leon@...nel.org" <leon@...nel.org>,
        "jiri@...lanox.com" <jiri@...lanox.com>,
        "idosch@...lanox.com" <idosch@...lanox.com>,
        "alexandre.belloni@...tlin.com" <alexandre.belloni@...tlin.com>,
        "UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "jhs@...atatu.com" <jhs@...atatu.com>,
        "xiyou.wangcong@...il.com" <xiyou.wangcong@...il.com>,
        "simon.horman@...ronome.com" <simon.horman@...ronome.com>,
        "pablo@...filter.org" <pablo@...filter.org>,
        "moshe@...lanox.com" <moshe@...lanox.com>,
        "m-karicheri2@...com" <m-karicheri2@...com>,
        "andre.guedes@...ux.intel.com" <andre.guedes@...ux.intel.com>,
        "stephen@...workplumber.org" <stephen@...workplumber.org>
Subject: RE: [EXT] Re: [v3,net-next  1/4] net: qos: introduce a gate control
 flow action

Hi Nielsen,

> -----Original Message-----
> From: Allan W. Nielsen <allan.nielsen@...rochip.com>
> Sent: 2020年4月23日 3:19
> To: Po Liu <po.liu@....com>
> Cc: davem@...emloft.net; linux-kernel@...r.kernel.org;
> netdev@...r.kernel.org; vinicius.gomes@...el.com; Claudiu Manoil
> <claudiu.manoil@....com>; Vladimir Oltean <vladimir.oltean@....com>;
> Alexandru Marginean <alexandru.marginean@....com>;
> michael.chan@...adcom.com; vishal@...lsio.com;
> saeedm@...lanox.com; leon@...nel.org; jiri@...lanox.com;
> idosch@...lanox.com; alexandre.belloni@...tlin.com;
> UNGLinuxDriver@...rochip.com; kuba@...nel.org; jhs@...atatu.com;
> xiyou.wangcong@...il.com; simon.horman@...ronome.com;
> pablo@...filter.org; moshe@...lanox.com; m-karicheri2@...com;
> andre.guedes@...ux.intel.com; stephen@...workplumber.org
> Subject: [EXT] Re: [v3,net-next 1/4] net: qos: introduce a gate control flow
> action
> 
> Caution: EXT Email
> 
> 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.

The gate action is the must have feature, so here is the part of it. And provide the stream filter implementation part in the driver.
I provided a whole thoughts, with flow-meter apply to policing action and other throughs in the RFC version. You can look back to that version for reference.

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

I think the psfp-id you mention is for the gate and stream filter and flow meter and stream-identify. For each they should have an index.
The stream-identify index come from the chain value. Gate index comes from the index in the gate action, two ports or more can share one same index gate index. Will same for the flow-meter action.

> 
> 
> /Allan

Thanks!

Br,
Po Liu

Powered by blists - more mailing lists