Message-ID: <VE1PR04MB6496CEA449E9B844094E580492510@VE1PR04MB6496.eurprd04.prod.outlook.com>
Date:   Mon, 16 Dec 2019 07:43:58 +0000
From:   Po Liu <po.liu@....com>
To:     Andre Guedes <andre.guedes@...ux.intel.com>,
        "alexandru.ardelean@...log.com" <alexandru.ardelean@...log.com>,
        "allison@...utok.net" <allison@...utok.net>,
        "andrew@...n.ch" <andrew@...n.ch>,
        "ayal@...lanox.com" <ayal@...lanox.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "hauke.mehrtens@...el.com" <hauke.mehrtens@...el.com>,
        "hkallweit1@...il.com" <hkallweit1@...il.com>,
        "jiri@...lanox.com" <jiri@...lanox.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "pablo@...filter.org" <pablo@...filter.org>,
        "saeedm@...lanox.com" <saeedm@...lanox.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        Vladimir Oltean <vladimir.oltean@....com>,
        Murali Karicheri <m-karicheri2@...com>,
        Ivan Khoronzhuk <ivan.khoronzhuk@...aro.org>
CC:     "vinicius.gomes@...el.com" <vinicius.gomes@...el.com>,
        "simon.horman@...ronome.com" <simon.horman@...ronome.com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Vladimir Oltean <vladimir.oltean@....com>,
        Alexandru Marginean <alexandru.marginean@....com>,
        Xiaoliang Yang <xiaoliang.yang_1@....com>,
        Roy Zang <roy.zang@....com>, Mingkai Hu <mingkai.hu@....com>,
        Jerry Huang <jerry.huang@....com>, Leo Li <leoyang.li@....com>
Subject: RE: [EXT] Re: [v1,net-next, 1/2] ethtool: add setting frame
 preemption of traffic classes

Hi Andre,


Br,
Po Liu

> -----Original Message-----
> From: Andre Guedes <andre.guedes@...ux.intel.com>
> Sent: 2019年12月11日 10:53
> To: alexandru.ardelean@...log.com; allison@...utok.net; andrew@...n.ch;
> ayal@...lanox.com; davem@...emloft.net; f.fainelli@...il.com;
> gregkh@...uxfoundation.org; hauke.mehrtens@...el.com;
> hkallweit1@...il.com; jiri@...lanox.com; linux-kernel@...r.kernel.org;
> netdev@...r.kernel.org; pablo@...filter.org; saeedm@...lanox.com;
> tglx@...utronix.de; Po Liu <po.liu@....com>
> Cc: vinicius.gomes@...el.com; simon.horman@...ronome.com; Claudiu Manoil
> <claudiu.manoil@....com>; Vladimir Oltean <vladimir.oltean@....com>;
> Alexandru Marginean <alexandru.marginean@....com>; Xiaoliang Yang
> <xiaoliang.yang_1@....com>; Roy Zang <roy.zang@....com>; Mingkai Hu
> <mingkai.hu@....com>; Jerry Huang <jerry.huang@....com>; Leo Li
> <leoyang.li@....com>; Po Liu <po.liu@....com>
> Subject: [EXT] Re: [v1,net-next, 1/2] ethtool: add setting frame preemption of
> traffic classes
> 
> Caution: EXT Email
> 
> Hi Po,
> 
> Quoting Po Liu (2019-11-27 01:59:18)
> > IEEE Std 802.1Qbu standard defined the frame preemption of port
> > traffic classes. This patch introduce a method to set traffic classes
> > preemption. Add a parameter 'preemption' in struct
> > ethtool_link_settings. The value will be translated to a binary, each
> > bit represent a traffic class. Bit "1" means preemptable traffic
> > class. Bit "0" means express traffic class.  MSB represent high number
> > traffic class.
> >
> > If hardware support the frame preemption, driver could set the
> > ethernet device with hw_features and features with NETIF_F_PREEMPTION
> > when initializing the port driver.
> >
> > User can check the feature 'tx-preemption' by command 'ethtool -k
> > devname'. If hareware set preemption feature. The property would be a
> > fixed value 'on' if hardware support the frame preemption.
> > Feature would show a fixed value 'off' if hardware don't support the
> > frame preemption.
> >
> > Command 'ethtool devname' and 'ethtool -s devname preemption N'
> > would show/set which traffic classes are frame preemptable.
> >
> > Port driver would implement the frame preemption in the function
> > get_link_ksettings() and set_link_ksettings() in the struct ethtool_ops.
> 
> In an early RFC series [1], we proposed a way to support frame preemption. I'm
> not sure if you have considered it before implementing this other proposal
> based on ethtool interface so I thought it would be a good idea to bring that up
> to your attention, just in case.
 
Sorry, I didn't notice the RFC proposal. Using ethtool set the preemption just thinking about 8021Qbu as standalone. And not limit to the taprio if user won't set 802.1Qbv.  

As some feedback  also want to set the MAC merge minimal fragment size and get some more information of 802.3br.

> 
> In that initial proposal, Frame Preemption feature is configured via taprio qdisc.
> For example:
> 
> $ tc qdisc add dev IFACE parent root handle 100 taprio \
>       num_tc 3 \
>       map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 \
>       queues 1@0 1@1 2@2 \
>       preemption 0 1 1 1 \
>       base-time 10000000 \
>       sched-entry S 01 300000 \
>       sched-entry S 02 300000 \
>       sched-entry S 04 400000 \
>       clockid CLOCK_TAI
> 
> It also aligns with the gate control operations Set-And-Hold-MAC and Set-And-
> Release-MAC that can be set via 'sched-entry' (see Table 8.7 from
> 802.1Q-2018 for further details.
 
I am curious about Set-And-Hold-Mac via 'sched-entry'. Actually, it could be understand as guardband by hardware preemption. MAC should auto calculate the nano seconds before  express entry slot start to break to two fragments. Set-And-Hold-MAC should minimal larger than the fragment-size oct times.

> 
> Please share your thoughts on this.

I am good to see there is frame preemption proposal. Each way is ok for me but ethtool is more flexible. I've seen the RFC the code. The hardware offload is in the mainline, but preemption is not yet, I don't know why. Could you post it again?

> Regards,
> 
> Andre

Powered by blists - more mailing lists