lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9b13a47e-8ca3-66b0-063c-798a5fa71149@ti.com>
Date:   Wed, 22 Jan 2020 13:10:36 -0500
From:   Murali Karicheri <m-karicheri2@...com>
To:     Vinicius Costa Gomes <vinicius.gomes@...el.com>,
        Po Liu <po.liu@....com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "hauke.mehrtens@...el.com" <hauke.mehrtens@...el.com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "allison@...utok.net" <allison@...utok.net>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "hkallweit1@...il.com" <hkallweit1@...il.com>,
        "saeedm@...lanox.com" <saeedm@...lanox.com>,
        "andrew@...n.ch" <andrew@...n.ch>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        "alexandru.ardelean@...log.com" <alexandru.ardelean@...log.com>,
        "jiri@...lanox.com" <jiri@...lanox.com>,
        "ayal@...lanox.com" <ayal@...lanox.com>,
        "pablo@...filter.org" <pablo@...filter.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:     "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: [v1,net-next, 1/2] ethtool: add setting frame preemption of
 traffic classes

Hi, Vinicius,

On 01/17/2020 07:03 PM, Vinicius Costa Gomes wrote:
> Hi,
> 
> Po Liu <po.liu@....com> writes:
> 
>> 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.
> 
> I think that we should keep the concept of 'traffic classes' outside of
> ethtool. Ethtool should only care about queues (or similar concepts).
> And unless I am missing something here, what you mean by 'traffic class'
> here is really a hardware queue.
> 
Agree.

So this is my understanding..

Once driver support FPE, then drive accepts tc gate operation,
Set-And-Hold MAC & Set-And-Release-MAC. Otherwise it can only offload
SetGateStates.

So candidates for ethtool command.

Set

- FPE enable/disable
- framePreemptionStatusTable of Table 12-30—Frame Preemption Parameter
table of 802.1Q 2018 which are defined as Read/Write. This is an array 
of Hw queues and if they are preemptible or express.
- Additionally 802.3br defines Min fragment size that is a candidate
   for ethtool command.

Show the following:-

  -  holdAdvance
  -  releaseAdvance
  -  preemptionActive
  -  holdRequest

There is also Table 12-29—The Gate Parameter Table for taprio. These
related to taprio schedule is already part of tc command. However there
are below parameters that requires configuration by user as well.
Can we use ethtool for the same as this
  - queueMaxSDUTable

Below is what I read about this which is also for hw queues AFAIK.

==== from 802.1Q====================================================
A per-traffic class queue queueMaxSDU parameter defines the maximum
service data unit size for each queue; frames that exceed queueMaxSDU 
are discarded. The value of queueMaxSDU for each queue is configurable
by management its default value is the maximum SDU size supported by the
MAC procedures employed on the LAN to which the frame is to be relayed
=======================================================================

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?
     - 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
     - TickGranularity - the management parameters specified in Gate
       Parameter Table allow a management station to discover the
       characteristics of an implementation’s cycle timer clock
       (TickGranularity) and to set the parameters for the gating cycle
       accordingly.
     - ConfigPending - A Boolean variable, set TRUE to indicate that
       there is a new cycle configuration awaiting installation.
     - ConfigChangeError - Error in configuration (AdminBaseTime <
       CurrentTime)
     - 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...

Regards,

Murali
>>
>> 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.
>>
>> Signed-off-by: Po Liu <Po.Liu@....com>
>> ---
>>   include/linux/netdev_features.h | 5 ++++-
>>   include/uapi/linux/ethtool.h    | 5 ++++-
>>   net/core/ethtool.c              | 1 +
>>   3 files changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
>> index 4b19c544c59a..299750a8b414 100644
>> --- a/include/linux/netdev_features.h
>> +++ b/include/linux/netdev_features.h
>> @@ -80,6 +80,7 @@ enum {
>>   
>>   	NETIF_F_GRO_HW_BIT,		/* Hardware Generic receive offload */
>>   	NETIF_F_HW_TLS_RECORD_BIT,	/* Offload TLS record */
>> +	NETIF_F_HW_PREEMPTION_BIT,	/* Hardware TC frame preemption */
>>   
>>   	/*
>>   	 * Add your fresh new feature above and remember to update
>> @@ -150,6 +151,7 @@ enum {
>>   #define NETIF_F_GSO_UDP_L4	__NETIF_F(GSO_UDP_L4)
>>   #define NETIF_F_HW_TLS_TX	__NETIF_F(HW_TLS_TX)
>>   #define NETIF_F_HW_TLS_RX	__NETIF_F(HW_TLS_RX)
>> +#define NETIF_F_PREEMPTION	__NETIF_F(HW_PREEMPTION)
>>   
>>   /* Finds the next feature with the highest number of the range of start till 0.
>>    */
>> @@ -175,7 +177,8 @@ static inline int find_next_netdev_feature(u64 feature, unsigned long start)
>>   /* Features valid for ethtool to change */
>>   /* = all defined minus driver/device-class-related */
>>   #define NETIF_F_NEVER_CHANGE	(NETIF_F_VLAN_CHALLENGED | \
>> -				 NETIF_F_LLTX | NETIF_F_NETNS_LOCAL)
>> +				 NETIF_F_LLTX | NETIF_F_NETNS_LOCAL | \
>> +				 NETIF_F_PREEMPTION)
>>   
>>   /* remember that ((t)1 << t_BITS) is undefined in C99 */
>>   #define NETIF_F_ETHTOOL_BITS	((__NETIF_F_BIT(NETDEV_FEATURE_COUNT - 1) | \
>> diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
>> index d4591792f0b4..12ffb34afbfa 100644
>> --- a/include/uapi/linux/ethtool.h
>> +++ b/include/uapi/linux/ethtool.h
>> @@ -1776,6 +1776,8 @@ enum ethtool_reset_flags {
>>   };
>>   #define ETH_RESET_SHARED_SHIFT	16
>>   
>> +/* Disable preemtion. */
>> +#define PREEMPTION_DISABLE     0x0
>>   
>>   /**
>>    * struct ethtool_link_settings - link control and status
>> @@ -1886,7 +1888,8 @@ struct ethtool_link_settings {
>>   	__s8	link_mode_masks_nwords;
>>   	__u8	transceiver;
>>   	__u8	reserved1[3];
>> -	__u32	reserved[7];
>> +	__u32	preemption;
>> +	__u32	reserved[6];
>>   	__u32	link_mode_masks[0];
>>   	/* layout of link_mode_masks fields:
>>   	 * __u32 map_supported[link_mode_masks_nwords];
>> diff --git a/net/core/ethtool.c b/net/core/ethtool.c
>> index cd9bc67381b2..6ffcd8a602b8 100644
>> --- a/net/core/ethtool.c
>> +++ b/net/core/ethtool.c
>> @@ -111,6 +111,7 @@ static const char netdev_features_strings[NETDEV_FEATURE_COUNT][ETH_GSTRING_LEN]
>>   	[NETIF_F_HW_TLS_RECORD_BIT] =	"tls-hw-record",
>>   	[NETIF_F_HW_TLS_TX_BIT] =	 "tls-hw-tx-offload",
>>   	[NETIF_F_HW_TLS_RX_BIT] =	 "tls-hw-rx-offload",
>> +	[NETIF_F_HW_PREEMPTION_BIT] =	 "tx-preemption",
>>   };
>>   
>>   static const char
>> -- 
>> 2.17.1
> 

-- 
Murali Karicheri
Texas Instruments

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ