d/numam-dpdk
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
33c9e904fb
numam-dpdk/app/test/test_meter.c

717 lines
20 KiB
C
Raw Normal View History

test: use SPDX tag for Intel copyright files Replace the BSD license header with the SPDX tag for files with only an Intel copyright on them. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
2017-12-19 15:49:05 +00:00
/* SPDX-License-Identifier: BSD-3-Clause
* Copyright(c) 2010-2014 Intel Corporation
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
*/
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <stdint.h>
#include <unistd.h>
#include "test.h"
#include <rte_cycles.h>
#include <rte_meter.h>
#define mlog(format, ...) do{\
printf("Line %d:",__LINE__);\
printf(format, ##__VA_ARGS__);\
printf("\n");\
}while(0);
#define melog(format, ...) do{\
printf("Line %d:",__LINE__);\
printf(format, ##__VA_ARGS__);\
printf(" failed!\n");\
return -1;\
}while(0);
#define TM_TEST_SRTCM_CIR_DF 46000000
#define TM_TEST_SRTCM_CBS_DF 2048
#define TM_TEST_SRTCM_EBS_DF 4096
#define TM_TEST_TRTCM_CIR_DF 46000000
#define TM_TEST_TRTCM_PIR_DF 69000000
meter: support RFC4115 trTCM This patch adds support for RFC4115 trTCM meters. Signed-off-by: Eelco Chaudron <echaudro@redhat.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-01-04 13:59:42 +00:00
#define TM_TEST_TRTCM_EIR_DF 69000000
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
#define TM_TEST_TRTCM_CBS_DF 2048
#define TM_TEST_TRTCM_PBS_DF 4096
meter: support RFC4115 trTCM This patch adds support for RFC4115 trTCM meters. Signed-off-by: Eelco Chaudron <echaudro@redhat.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-01-04 13:59:42 +00:00
#define TM_TEST_TRTCM_EBS_DF 4096
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
static struct rte_meter_srtcm_params sparams =
{.cir = TM_TEST_SRTCM_CIR_DF,
.cbs = TM_TEST_SRTCM_CBS_DF,
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
.ebs = TM_TEST_SRTCM_EBS_DF,};
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
static struct rte_meter_trtcm_params tparams=
{.cir = TM_TEST_TRTCM_CIR_DF,
.pir = TM_TEST_TRTCM_PIR_DF,
.cbs = TM_TEST_TRTCM_CBS_DF,
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
.pbs = TM_TEST_TRTCM_PBS_DF,};
meter: support RFC4115 trTCM This patch adds support for RFC4115 trTCM meters. Signed-off-by: Eelco Chaudron <echaudro@redhat.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-01-04 13:59:42 +00:00
static struct rte_meter_trtcm_rfc4115_params rfc4115params =
{.cir = TM_TEST_TRTCM_CIR_DF,
.eir = TM_TEST_TRTCM_EIR_DF,
.cbs = TM_TEST_TRTCM_CBS_DF,
.ebs = TM_TEST_TRTCM_EBS_DF,};
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
/**
* functional test for rte_meter_srtcm_config
*/
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
static inline int
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
tm_test_srtcm_config(void)
{
#define SRTCM_CFG_MSG "srtcm_config"
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
struct rte_meter_srtcm_profile sp;
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
struct rte_meter_srtcm_params sparams1;
/* invalid parameter test */
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_srtcm_profile_config(NULL, NULL) == 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(SRTCM_CFG_MSG);
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_srtcm_profile_config(&sp, NULL) == 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(SRTCM_CFG_MSG);
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_srtcm_profile_config(NULL, &sparams) == 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(SRTCM_CFG_MSG);
/* cbs and ebs can't both be zero */
sparams1 = sparams;
sparams1.cbs = 0;
sparams1.ebs = 0;
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_srtcm_profile_config(&sp, &sparams1) == 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(SRTCM_CFG_MSG);
/* cir should never be 0 */
sparams1 = sparams;
sparams1.cir = 0;
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_srtcm_profile_config(&sp, &sparams1) == 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(SRTCM_CFG_MSG);
/* one of ebs and cbs can be zero, should be successful */
sparams1 = sparams;
sparams1.ebs = 0;
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_srtcm_profile_config(&sp, &sparams1) != 0)
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
melog(SRTCM_CFG_MSG);
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
sparams1 = sparams;
sparams1.cbs = 0;
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_srtcm_profile_config(&sp, &sparams1) != 0)
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
melog(SRTCM_CFG_MSG);
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
/* usual parameter, should be successful */
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_srtcm_profile_config(&sp, &sparams) != 0)
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
melog(SRTCM_CFG_MSG);
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
return 0;
}
/**
* functional test for rte_meter_trtcm_config
*/
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
static inline int
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
tm_test_trtcm_config(void)
{
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
struct rte_meter_trtcm_profile tp;
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
struct rte_meter_trtcm_params tparams1;
#define TRTCM_CFG_MSG "trtcm_config"
/* invalid parameter test */
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_trtcm_profile_config(NULL, NULL) == 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(TRTCM_CFG_MSG);
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_trtcm_profile_config(&tp, NULL) == 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(TRTCM_CFG_MSG);
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_trtcm_profile_config(NULL, &tparams) == 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(TRTCM_CFG_MSG);
/* cir, cbs, pir and pbs never be zero */
tparams1 = tparams;
tparams1.cir = 0;
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_trtcm_profile_config(&tp, &tparams1) == 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(TRTCM_CFG_MSG);
tparams1 = tparams;
tparams1.cbs = 0;
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_trtcm_profile_config(&tp, &tparams1) == 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(TRTCM_CFG_MSG);
tparams1 = tparams;
tparams1.pbs = 0;
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_trtcm_profile_config(&tp, &tparams1) == 0)
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
melog(TRTCM_CFG_MSG);
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
tparams1 = tparams;
tparams1.pir = 0;
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_trtcm_profile_config(&tp, &tparams1) == 0)
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
melog(TRTCM_CFG_MSG);
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
/* pir should be greater or equal to cir */
tparams1 = tparams;
tparams1.pir = tparams1.cir - 1;
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_trtcm_profile_config(&tp, &tparams1) == 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(TRTCM_CFG_MSG" pir < cir test");
/* usual parameter, should be successful */
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_trtcm_profile_config(&tp, &tparams) != 0)
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
melog(TRTCM_CFG_MSG);
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
return 0;
}
meter: support RFC4115 trTCM This patch adds support for RFC4115 trTCM meters. Signed-off-by: Eelco Chaudron <echaudro@redhat.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-01-04 13:59:42 +00:00
/**
* functional test for rte_meter_trtcm_rfc4115_config
*/
static inline int
tm_test_trtcm_rfc4115_config(void)
{
struct rte_meter_trtcm_rfc4115_profile tp;
struct rte_meter_trtcm_rfc4115_params rfc4115params1;
#define TRTCM_RFC4115_CFG_MSG "trtcm_rfc4115_config"
/* invalid parameter test */
if (rte_meter_trtcm_rfc4115_profile_config(NULL, NULL) == 0)
melog(TRTCM_RFC4115_CFG_MSG);
if (rte_meter_trtcm_rfc4115_profile_config(&tp, NULL) == 0)
melog(TRTCM_RFC4115_CFG_MSG);
if (rte_meter_trtcm_rfc4115_profile_config(NULL, &rfc4115params) == 0)
melog(TRTCM_RFC4115_CFG_MSG);
/*
* cbs and pbs should be none-zero if cir and eir are none-zero
* respectively
*/
rfc4115params1 = rfc4115params;
rfc4115params1.cbs = 0;
if (rte_meter_trtcm_rfc4115_profile_config(&tp, &rfc4115params1) == 0)
melog(TRTCM_RFC4115_CFG_MSG);
rfc4115params1 = rfc4115params;
rfc4115params1.ebs = 0;
if (rte_meter_trtcm_rfc4115_profile_config(&tp, &rfc4115params1) == 0)
melog(TRTCM_RFC4115_CFG_MSG);
/* usual parameter, should be successful */
if (rte_meter_trtcm_rfc4115_profile_config(&tp, &rfc4115params) != 0)
melog(TRTCM_RFC4115_CFG_MSG);
return 0;
}
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
/**
* functional test for rte_meter_srtcm_color_blind_check
*/
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
static inline int
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
tm_test_srtcm_color_blind_check(void)
{
#define SRTCM_BLIND_CHECK_MSG "srtcm_blind_check"
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
struct rte_meter_srtcm_profile sp;
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
struct rte_meter_srtcm sm;
uint64_t time;
uint64_t hz = rte_get_tsc_hz();
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
/* Test green */
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_srtcm_profile_config(&sp, &sparams) != 0)
melog(SRTCM_BLIND_CHECK_MSG);
if (rte_meter_srtcm_config(&sm, &sp) != 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(SRTCM_BLIND_CHECK_MSG);
time = rte_get_tsc_cycles() + hz;
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_srtcm_color_blind_check(
&sm, &sp, time, TM_TEST_SRTCM_CBS_DF - 1)
meter: replace color definitions This patch implements the changes proposed in the deprecation note[1]. Replace multiple color definitions in various places such as rte_meter.h, rte_tm.h and rte_mtr.h with single rte_color defined in rte_meter.h. This is simple search and replace exercise without any implementation change. [1] https://mails.dpdk.org/archives/dev/2019-January/123861.html Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-04-11 09:15:14 +00:00
!= RTE_COLOR_GREEN)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(SRTCM_BLIND_CHECK_MSG" GREEN");
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
/* Test yellow */
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_srtcm_profile_config(&sp, &sparams) != 0)
melog(SRTCM_BLIND_CHECK_MSG);
if (rte_meter_srtcm_config(&sm, &sp) != 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(SRTCM_BLIND_CHECK_MSG);
time = rte_get_tsc_cycles() + hz;
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_srtcm_color_blind_check(
&sm, &sp, time, TM_TEST_SRTCM_CBS_DF + 1)
meter: replace color definitions This patch implements the changes proposed in the deprecation note[1]. Replace multiple color definitions in various places such as rte_meter.h, rte_tm.h and rte_mtr.h with single rte_color defined in rte_meter.h. This is simple search and replace exercise without any implementation change. [1] https://mails.dpdk.org/archives/dev/2019-January/123861.html Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-04-11 09:15:14 +00:00
!= RTE_COLOR_YELLOW)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(SRTCM_BLIND_CHECK_MSG" YELLOW");
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_srtcm_profile_config(&sp, &sparams) != 0)
melog(SRTCM_BLIND_CHECK_MSG);
if (rte_meter_srtcm_config(&sm, &sp) != 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(SRTCM_BLIND_CHECK_MSG);
time = rte_get_tsc_cycles() + hz;
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_srtcm_color_blind_check(
meter: replace color definitions This patch implements the changes proposed in the deprecation note[1]. Replace multiple color definitions in various places such as rte_meter.h, rte_tm.h and rte_mtr.h with single rte_color defined in rte_meter.h. This is simple search and replace exercise without any implementation change. [1] https://mails.dpdk.org/archives/dev/2019-January/123861.html Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-04-11 09:15:14 +00:00
&sm, &sp, time, (uint32_t)sp.ebs - 1) != RTE_COLOR_YELLOW)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(SRTCM_BLIND_CHECK_MSG" YELLOW");
/* Test red */
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_srtcm_profile_config(&sp, &sparams) != 0)
melog(SRTCM_BLIND_CHECK_MSG);
if (rte_meter_srtcm_config(&sm, &sp) != 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(SRTCM_BLIND_CHECK_MSG);
time = rte_get_tsc_cycles() + hz;
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_srtcm_color_blind_check(
&sm, &sp, time, TM_TEST_SRTCM_EBS_DF + 1)
meter: replace color definitions This patch implements the changes proposed in the deprecation note[1]. Replace multiple color definitions in various places such as rte_meter.h, rte_tm.h and rte_mtr.h with single rte_color defined in rte_meter.h. This is simple search and replace exercise without any implementation change. [1] https://mails.dpdk.org/archives/dev/2019-January/123861.html Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-04-11 09:15:14 +00:00
!= RTE_COLOR_RED)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(SRTCM_BLIND_CHECK_MSG" RED");
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
return 0;
}
/**
* functional test for rte_meter_trtcm_color_blind_check
*/
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
static inline int
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
tm_test_trtcm_color_blind_check(void)
{
#define TRTCM_BLIND_CHECK_MSG "trtcm_blind_check"
uint64_t time;
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
struct rte_meter_trtcm_profile tp;
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
struct rte_meter_trtcm tm;
uint64_t hz = rte_get_tsc_hz();
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
/* Test green */
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_trtcm_profile_config(&tp, &tparams) != 0)
melog(TRTCM_BLIND_CHECK_MSG);
if (rte_meter_trtcm_config(&tm, &tp) != 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(TRTCM_BLIND_CHECK_MSG);
time = rte_get_tsc_cycles() + hz;
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_trtcm_color_blind_check(
&tm, &tp, time, TM_TEST_TRTCM_CBS_DF - 1)
meter: replace color definitions This patch implements the changes proposed in the deprecation note[1]. Replace multiple color definitions in various places such as rte_meter.h, rte_tm.h and rte_mtr.h with single rte_color defined in rte_meter.h. This is simple search and replace exercise without any implementation change. [1] https://mails.dpdk.org/archives/dev/2019-January/123861.html Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-04-11 09:15:14 +00:00
!= RTE_COLOR_GREEN)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(TRTCM_BLIND_CHECK_MSG" GREEN");
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
/* Test yellow */
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_trtcm_profile_config(&tp, &tparams) != 0)
melog(TRTCM_BLIND_CHECK_MSG);
if (rte_meter_trtcm_config(&tm, &tp) != 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(TRTCM_BLIND_CHECK_MSG);
time = rte_get_tsc_cycles() + hz;
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_trtcm_color_blind_check(
&tm, &tp, time, TM_TEST_TRTCM_CBS_DF + 1)
meter: replace color definitions This patch implements the changes proposed in the deprecation note[1]. Replace multiple color definitions in various places such as rte_meter.h, rte_tm.h and rte_mtr.h with single rte_color defined in rte_meter.h. This is simple search and replace exercise without any implementation change. [1] https://mails.dpdk.org/archives/dev/2019-January/123861.html Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-04-11 09:15:14 +00:00
!= RTE_COLOR_YELLOW)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(TRTCM_BLIND_CHECK_MSG" YELLOW");
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_trtcm_profile_config(&tp, &tparams) != 0)
melog(TRTCM_BLIND_CHECK_MSG);
if (rte_meter_trtcm_config(&tm, &tp) != 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(TRTCM_BLIND_CHECK_MSG);
time = rte_get_tsc_cycles() + hz;
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_trtcm_color_blind_check(
&tm, &tp, time, TM_TEST_TRTCM_PBS_DF - 1)
meter: replace color definitions This patch implements the changes proposed in the deprecation note[1]. Replace multiple color definitions in various places such as rte_meter.h, rte_tm.h and rte_mtr.h with single rte_color defined in rte_meter.h. This is simple search and replace exercise without any implementation change. [1] https://mails.dpdk.org/archives/dev/2019-January/123861.html Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-04-11 09:15:14 +00:00
!= RTE_COLOR_YELLOW)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(TRTCM_BLIND_CHECK_MSG" YELLOW");
/* Test red */
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_trtcm_profile_config(&tp, &tparams) != 0)
melog(TRTCM_BLIND_CHECK_MSG);
if (rte_meter_trtcm_config(&tm, &tp) != 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(TRTCM_BLIND_CHECK_MSG);
time = rte_get_tsc_cycles() + hz;
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_trtcm_color_blind_check(
&tm, &tp, time, TM_TEST_TRTCM_PBS_DF + 1)
meter: replace color definitions This patch implements the changes proposed in the deprecation note[1]. Replace multiple color definitions in various places such as rte_meter.h, rte_tm.h and rte_mtr.h with single rte_color defined in rte_meter.h. This is simple search and replace exercise without any implementation change. [1] https://mails.dpdk.org/archives/dev/2019-January/123861.html Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-04-11 09:15:14 +00:00
!= RTE_COLOR_RED)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(TRTCM_BLIND_CHECK_MSG" RED");
return 0;
}
meter: support RFC4115 trTCM This patch adds support for RFC4115 trTCM meters. Signed-off-by: Eelco Chaudron <echaudro@redhat.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-01-04 13:59:42 +00:00
/**
* functional test for rte_meter_trtcm_rfc4115_color_blind_check
*/
static inline int
tm_test_trtcm_rfc4115_color_blind_check(void)
{
#define TRTCM_RFC4115_BLIND_CHECK_MSG "trtcm_rfc4115_blind_check"
uint64_t time;
struct rte_meter_trtcm_rfc4115_profile tp;
struct rte_meter_trtcm_rfc4115 tm;
uint64_t hz = rte_get_tsc_hz();
/* Test green */
if (rte_meter_trtcm_rfc4115_profile_config(&tp, &rfc4115params) != 0)
melog(TRTCM_RFC4115_BLIND_CHECK_MSG);
if (rte_meter_trtcm_rfc4115_config(&tm, &tp) != 0)
melog(TRTCM_RFC4115_BLIND_CHECK_MSG);
time = rte_get_tsc_cycles() + hz;
if (rte_meter_trtcm_rfc4115_color_blind_check(
&tm, &tp, time, TM_TEST_TRTCM_CBS_DF - 1)
meter: replace color definitions This patch implements the changes proposed in the deprecation note[1]. Replace multiple color definitions in various places such as rte_meter.h, rte_tm.h and rte_mtr.h with single rte_color defined in rte_meter.h. This is simple search and replace exercise without any implementation change. [1] https://mails.dpdk.org/archives/dev/2019-January/123861.html Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-04-11 09:15:14 +00:00
!= RTE_COLOR_GREEN)
meter: support RFC4115 trTCM This patch adds support for RFC4115 trTCM meters. Signed-off-by: Eelco Chaudron <echaudro@redhat.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-01-04 13:59:42 +00:00
melog(TRTCM_RFC4115_BLIND_CHECK_MSG" GREEN");
/* Test yellow */
if (rte_meter_trtcm_rfc4115_profile_config(&tp, &rfc4115params) != 0)
melog(TRTCM_RFC4115_BLIND_CHECK_MSG);
if (rte_meter_trtcm_rfc4115_config(&tm, &tp) != 0)
melog(TRTCM_RFC4115_BLIND_CHECK_MSG);
time = rte_get_tsc_cycles() + hz;
if (rte_meter_trtcm_rfc4115_color_blind_check(
&tm, &tp, time, TM_TEST_TRTCM_CBS_DF + 1)
meter: replace color definitions This patch implements the changes proposed in the deprecation note[1]. Replace multiple color definitions in various places such as rte_meter.h, rte_tm.h and rte_mtr.h with single rte_color defined in rte_meter.h. This is simple search and replace exercise without any implementation change. [1] https://mails.dpdk.org/archives/dev/2019-January/123861.html Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-04-11 09:15:14 +00:00
!= RTE_COLOR_YELLOW)
meter: support RFC4115 trTCM This patch adds support for RFC4115 trTCM meters. Signed-off-by: Eelco Chaudron <echaudro@redhat.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-01-04 13:59:42 +00:00
melog(TRTCM_RFC4115_BLIND_CHECK_MSG" YELLOW");
if (rte_meter_trtcm_rfc4115_profile_config(&tp, &rfc4115params) != 0)
melog(TRTCM_RFC4115_BLIND_CHECK_MSG);
if (rte_meter_trtcm_rfc4115_config(&tm, &tp) != 0)
melog(TRTCM_RFC4115_BLIND_CHECK_MSG);
time = rte_get_tsc_cycles() + hz;
if (rte_meter_trtcm_rfc4115_color_blind_check(
&tm, &tp, time, TM_TEST_TRTCM_EBS_DF - 1)
meter: replace color definitions This patch implements the changes proposed in the deprecation note[1]. Replace multiple color definitions in various places such as rte_meter.h, rte_tm.h and rte_mtr.h with single rte_color defined in rte_meter.h. This is simple search and replace exercise without any implementation change. [1] https://mails.dpdk.org/archives/dev/2019-January/123861.html Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-04-11 09:15:14 +00:00
!= RTE_COLOR_YELLOW)
meter: support RFC4115 trTCM This patch adds support for RFC4115 trTCM meters. Signed-off-by: Eelco Chaudron <echaudro@redhat.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-01-04 13:59:42 +00:00
melog(TRTCM_RFC4115_BLIND_CHECK_MSG" YELLOW");
/* Test red */
if (rte_meter_trtcm_rfc4115_profile_config(&tp, &rfc4115params) != 0)
melog(TRTCM_RFC4115_BLIND_CHECK_MSG);
if (rte_meter_trtcm_rfc4115_config(&tm, &tp) != 0)
melog(TRTCM_RFC4115_BLIND_CHECK_MSG);
time = rte_get_tsc_cycles() + hz;
if (rte_meter_trtcm_rfc4115_color_blind_check(
&tm, &tp, time, TM_TEST_TRTCM_EBS_DF + 1)
meter: replace color definitions This patch implements the changes proposed in the deprecation note[1]. Replace multiple color definitions in various places such as rte_meter.h, rte_tm.h and rte_mtr.h with single rte_color defined in rte_meter.h. This is simple search and replace exercise without any implementation change. [1] https://mails.dpdk.org/archives/dev/2019-January/123861.html Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-04-11 09:15:14 +00:00
!= RTE_COLOR_RED)
meter: support RFC4115 trTCM This patch adds support for RFC4115 trTCM meters. Signed-off-by: Eelco Chaudron <echaudro@redhat.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-01-04 13:59:42 +00:00
melog(TRTCM_RFC4115_BLIND_CHECK_MSG" RED");
return 0;
}
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
/**
* @in[4] : the flags packets carries.
* @in[4] : the flags function expect to return.
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
* It will do blind check at the time of 1 second from beginning.
* At the time, it will use packets length of cbs -1, cbs + 1,
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
* ebs -1 and ebs +1 with flag in[0], in[1], in[2] and in[3] to do
* aware check, expect flag out[0], out[1], out[2] and out[3]
*/
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
static inline int
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
tm_test_srtcm_aware_check
meter: replace color definitions This patch implements the changes proposed in the deprecation note[1]. Replace multiple color definitions in various places such as rte_meter.h, rte_tm.h and rte_mtr.h with single rte_color defined in rte_meter.h. This is simple search and replace exercise without any implementation change. [1] https://mails.dpdk.org/archives/dev/2019-January/123861.html Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-04-11 09:15:14 +00:00
(enum rte_color in[4], enum rte_color out[4])
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
{
#define SRTCM_AWARE_CHECK_MSG "srtcm_aware_check"
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
struct rte_meter_srtcm_profile sp;
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
struct rte_meter_srtcm sm;
uint64_t time;
uint64_t hz = rte_get_tsc_hz();
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_srtcm_profile_config(&sp, &sparams) != 0)
melog(SRTCM_AWARE_CHECK_MSG);
if (rte_meter_srtcm_config(&sm, &sp) != 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(SRTCM_AWARE_CHECK_MSG);
time = rte_get_tsc_cycles() + hz;
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_srtcm_color_aware_check(
&sm, &sp, time, TM_TEST_SRTCM_CBS_DF - 1, in[0]) != out[0])
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(SRTCM_AWARE_CHECK_MSG" %u:%u", in[0], out[0]);
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_srtcm_profile_config(&sp, &sparams) != 0)
melog(SRTCM_AWARE_CHECK_MSG);
if (rte_meter_srtcm_config(&sm, &sp) != 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(SRTCM_AWARE_CHECK_MSG);
time = rte_get_tsc_cycles() + hz;
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_srtcm_color_aware_check(
&sm, &sp, time, TM_TEST_SRTCM_CBS_DF + 1, in[1]) != out[1])
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(SRTCM_AWARE_CHECK_MSG" %u:%u", in[1], out[1]);
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_srtcm_profile_config(&sp, &sparams) != 0)
melog(SRTCM_AWARE_CHECK_MSG);
if (rte_meter_srtcm_config(&sm, &sp) != 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(SRTCM_AWARE_CHECK_MSG);
time = rte_get_tsc_cycles() + hz;
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_srtcm_color_aware_check(
&sm, &sp, time, TM_TEST_SRTCM_EBS_DF - 1, in[2]) != out[2])
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(SRTCM_AWARE_CHECK_MSG" %u:%u", in[2], out[2]);
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_srtcm_profile_config(&sp, &sparams) != 0)
melog(SRTCM_AWARE_CHECK_MSG);
if (rte_meter_srtcm_config(&sm, &sp) != 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(SRTCM_AWARE_CHECK_MSG);
time = rte_get_tsc_cycles() + hz;
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_srtcm_color_aware_check(
&sm, &sp, time, TM_TEST_SRTCM_EBS_DF + 1, in[3]) != out[3])
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(SRTCM_AWARE_CHECK_MSG" %u:%u", in[3], out[3]);
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
return 0;
}
/**
* functional test for rte_meter_srtcm_color_aware_check
*/
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
static inline int
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
tm_test_srtcm_color_aware_check(void)
{
meter: replace color definitions This patch implements the changes proposed in the deprecation note[1]. Replace multiple color definitions in various places such as rte_meter.h, rte_tm.h and rte_mtr.h with single rte_color defined in rte_meter.h. This is simple search and replace exercise without any implementation change. [1] https://mails.dpdk.org/archives/dev/2019-January/123861.html Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-04-11 09:15:14 +00:00
enum rte_color in[4], out[4];
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
/**
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
* test 4 points that will produce green, yellow, yellow, red flag
* if using blind check
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
*/
/* previouly have a green, test points should keep unchanged */
meter: replace color definitions This patch implements the changes proposed in the deprecation note[1]. Replace multiple color definitions in various places such as rte_meter.h, rte_tm.h and rte_mtr.h with single rte_color defined in rte_meter.h. This is simple search and replace exercise without any implementation change. [1] https://mails.dpdk.org/archives/dev/2019-January/123861.html Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-04-11 09:15:14 +00:00
in[0] = in[1] = in[2] = in[3] = RTE_COLOR_GREEN;
out[0] = RTE_COLOR_GREEN;
out[1] = RTE_COLOR_YELLOW;
out[2] = RTE_COLOR_YELLOW;
out[3] = RTE_COLOR_RED;
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (tm_test_srtcm_aware_check(in, out) != 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
return -1;
/**
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
* previously have a yellow, green & yellow = yellow
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
* yellow & red = red
*/
meter: replace color definitions This patch implements the changes proposed in the deprecation note[1]. Replace multiple color definitions in various places such as rte_meter.h, rte_tm.h and rte_mtr.h with single rte_color defined in rte_meter.h. This is simple search and replace exercise without any implementation change. [1] https://mails.dpdk.org/archives/dev/2019-January/123861.html Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-04-11 09:15:14 +00:00
in[0] = in[1] = in[2] = in[3] = RTE_COLOR_YELLOW;
out[0] = RTE_COLOR_YELLOW;
out[1] = RTE_COLOR_YELLOW;
out[2] = RTE_COLOR_YELLOW;
out[3] = RTE_COLOR_RED;
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (tm_test_srtcm_aware_check(in, out) != 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
return -1;
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
/**
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
* previously have a red, red & green = red
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
* red & yellow = red
*/
meter: replace color definitions This patch implements the changes proposed in the deprecation note[1]. Replace multiple color definitions in various places such as rte_meter.h, rte_tm.h and rte_mtr.h with single rte_color defined in rte_meter.h. This is simple search and replace exercise without any implementation change. [1] https://mails.dpdk.org/archives/dev/2019-January/123861.html Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-04-11 09:15:14 +00:00
in[0] = in[1] = in[2] = in[3] = RTE_COLOR_RED;
out[0] = RTE_COLOR_RED;
out[1] = RTE_COLOR_RED;
out[2] = RTE_COLOR_RED;
out[3] = RTE_COLOR_RED;
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (tm_test_srtcm_aware_check(in, out) != 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
return -1;
return 0;
}
/**
* @in[4] : the flags packets carries.
* @in[4] : the flags function expect to return.
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
* It will do blind check at the time of 1 second from beginning.
* At the time, it will use packets length of cbs -1, cbs + 1,
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
* ebs -1 and ebs +1 with flag in[0], in[1], in[2] and in[3] to do
* aware check, expect flag out[0], out[1], out[2] and out[3]
*/
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
static inline int
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
tm_test_trtcm_aware_check
meter: replace color definitions This patch implements the changes proposed in the deprecation note[1]. Replace multiple color definitions in various places such as rte_meter.h, rte_tm.h and rte_mtr.h with single rte_color defined in rte_meter.h. This is simple search and replace exercise without any implementation change. [1] https://mails.dpdk.org/archives/dev/2019-January/123861.html Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-04-11 09:15:14 +00:00
(enum rte_color in[4], enum rte_color out[4])
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
{
#define TRTCM_AWARE_CHECK_MSG "trtcm_aware_check"
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
struct rte_meter_trtcm_profile tp;
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
struct rte_meter_trtcm tm;
uint64_t time;
uint64_t hz = rte_get_tsc_hz();
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_trtcm_profile_config(&tp, &tparams) != 0)
melog(TRTCM_AWARE_CHECK_MSG);
if (rte_meter_trtcm_config(&tm, &tp) != 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(TRTCM_AWARE_CHECK_MSG);
time = rte_get_tsc_cycles() + hz;
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_trtcm_color_aware_check(
&tm, &tp, time, TM_TEST_TRTCM_CBS_DF - 1, in[0]) != out[0])
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(TRTCM_AWARE_CHECK_MSG" %u:%u", in[0], out[0]);
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_trtcm_profile_config(&tp, &tparams) != 0)
melog(TRTCM_AWARE_CHECK_MSG);
if (rte_meter_trtcm_config(&tm, &tp) != 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(TRTCM_AWARE_CHECK_MSG);
time = rte_get_tsc_cycles() + hz;
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_trtcm_color_aware_check(
&tm, &tp, time, TM_TEST_TRTCM_CBS_DF + 1, in[1]) != out[1])
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(TRTCM_AWARE_CHECK_MSG" %u:%u", in[1], out[1]);
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_trtcm_profile_config(&tp, &tparams) != 0)
melog(TRTCM_AWARE_CHECK_MSG);
if (rte_meter_trtcm_config(&tm, &tp) != 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(TRTCM_AWARE_CHECK_MSG);
time = rte_get_tsc_cycles() + hz;
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_trtcm_color_aware_check(
&tm, &tp, time, TM_TEST_TRTCM_PBS_DF - 1, in[2]) != out[2])
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(TRTCM_AWARE_CHECK_MSG" %u:%u", in[2], out[2]);
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_trtcm_profile_config(&tp, &tparams) != 0)
melog(TRTCM_AWARE_CHECK_MSG);
if (rte_meter_trtcm_config(&tm, &tp) != 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(TRTCM_AWARE_CHECK_MSG);
time = rte_get_tsc_cycles() + hz;
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (rte_meter_trtcm_color_aware_check(
&tm, &tp, time, TM_TEST_TRTCM_PBS_DF + 1, in[3]) != out[3])
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
melog(TRTCM_AWARE_CHECK_MSG" %u:%u", in[3], out[3]);
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
return 0;
}
/**
* functional test for rte_meter_trtcm_color_aware_check
*/
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
static inline int
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
tm_test_trtcm_color_aware_check(void)
{
meter: replace color definitions This patch implements the changes proposed in the deprecation note[1]. Replace multiple color definitions in various places such as rte_meter.h, rte_tm.h and rte_mtr.h with single rte_color defined in rte_meter.h. This is simple search and replace exercise without any implementation change. [1] https://mails.dpdk.org/archives/dev/2019-January/123861.html Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-04-11 09:15:14 +00:00
enum rte_color in[4], out[4];
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
/**
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
* test 4 points that will produce green, yellow, yellow, red flag
* if using blind check
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
*/
/* previouly have a green, test points should keep unchanged */
meter: replace color definitions This patch implements the changes proposed in the deprecation note[1]. Replace multiple color definitions in various places such as rte_meter.h, rte_tm.h and rte_mtr.h with single rte_color defined in rte_meter.h. This is simple search and replace exercise without any implementation change. [1] https://mails.dpdk.org/archives/dev/2019-January/123861.html Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-04-11 09:15:14 +00:00
in[0] = in[1] = in[2] = in[3] = RTE_COLOR_GREEN;
out[0] = RTE_COLOR_GREEN;
out[1] = RTE_COLOR_YELLOW;
out[2] = RTE_COLOR_YELLOW;
out[3] = RTE_COLOR_RED;
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (tm_test_trtcm_aware_check(in, out) != 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
return -1;
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
meter: replace color definitions This patch implements the changes proposed in the deprecation note[1]. Replace multiple color definitions in various places such as rte_meter.h, rte_tm.h and rte_mtr.h with single rte_color defined in rte_meter.h. This is simple search and replace exercise without any implementation change. [1] https://mails.dpdk.org/archives/dev/2019-January/123861.html Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-04-11 09:15:14 +00:00
in[0] = in[1] = in[2] = in[3] = RTE_COLOR_YELLOW;
out[0] = RTE_COLOR_YELLOW;
out[1] = RTE_COLOR_YELLOW;
out[2] = RTE_COLOR_YELLOW;
out[3] = RTE_COLOR_RED;
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (tm_test_trtcm_aware_check(in, out) != 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
return -1;
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
meter: replace color definitions This patch implements the changes proposed in the deprecation note[1]. Replace multiple color definitions in various places such as rte_meter.h, rte_tm.h and rte_mtr.h with single rte_color defined in rte_meter.h. This is simple search and replace exercise without any implementation change. [1] https://mails.dpdk.org/archives/dev/2019-January/123861.html Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-04-11 09:15:14 +00:00
in[0] = in[1] = in[2] = in[3] = RTE_COLOR_RED;
out[0] = RTE_COLOR_RED;
out[1] = RTE_COLOR_RED;
out[2] = RTE_COLOR_RED;
out[3] = RTE_COLOR_RED;
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (tm_test_trtcm_aware_check(in, out) != 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
return -1;
return 0;
}
meter: support RFC4115 trTCM This patch adds support for RFC4115 trTCM meters. Signed-off-by: Eelco Chaudron <echaudro@redhat.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-01-04 13:59:42 +00:00
/**
* @in[4] : the flags packets carries.
* @in[4] : the flags function expect to return.
* It will do blind check at the time of 1 second from beginning.
* At the time, it will use packets length of cbs -1, cbs + 1,
* ebs -1 and ebs +1 with flag in[0], in[1], in[2] and in[3] to do
* aware check, expect flag out[0], out[1], out[2] and out[3]
*/
static inline int
tm_test_trtcm_rfc4115_aware_check
meter: replace color definitions This patch implements the changes proposed in the deprecation note[1]. Replace multiple color definitions in various places such as rte_meter.h, rte_tm.h and rte_mtr.h with single rte_color defined in rte_meter.h. This is simple search and replace exercise without any implementation change. [1] https://mails.dpdk.org/archives/dev/2019-January/123861.html Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-04-11 09:15:14 +00:00
(enum rte_color in[4], enum rte_color out[4])
meter: support RFC4115 trTCM This patch adds support for RFC4115 trTCM meters. Signed-off-by: Eelco Chaudron <echaudro@redhat.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-01-04 13:59:42 +00:00
{
#define TRTCM_RFC4115_AWARE_CHECK_MSG "trtcm_rfc4115_aware_check"
struct rte_meter_trtcm_rfc4115_profile tp;
struct rte_meter_trtcm_rfc4115 tm;
uint64_t time;
uint64_t hz = rte_get_tsc_hz();
if (rte_meter_trtcm_rfc4115_profile_config(&tp, &rfc4115params) != 0)
melog(TRTCM_AWARE_CHECK_MSG);
if (rte_meter_trtcm_rfc4115_config(&tm, &tp) != 0)
melog(TRTCM_RFC4115_AWARE_CHECK_MSG);
time = rte_get_tsc_cycles() + hz;
if (rte_meter_trtcm_rfc4115_color_aware_check(
&tm, &tp, time, TM_TEST_TRTCM_CBS_DF - 1, in[0]) != out[0])
melog(TRTCM_RFC4115_AWARE_CHECK_MSG" %u:%u", in[0], out[0]);
if (rte_meter_trtcm_rfc4115_profile_config(&tp, &rfc4115params) != 0)
melog(TRTCM_RFC4115_AWARE_CHECK_MSG);
if (rte_meter_trtcm_rfc4115_config(&tm, &tp) != 0)
melog(TRTCM_RFC4115_AWARE_CHECK_MSG);
time = rte_get_tsc_cycles() + hz;
if (rte_meter_trtcm_rfc4115_color_aware_check(
&tm, &tp, time, TM_TEST_TRTCM_CBS_DF + 1, in[1]) != out[1])
melog(TRTCM_RFC4115_AWARE_CHECK_MSG" %u:%u", in[1], out[1]);
if (rte_meter_trtcm_rfc4115_profile_config(&tp, &rfc4115params) != 0)
melog(TRTCM_RFC4115_AWARE_CHECK_MSG);
if (rte_meter_trtcm_rfc4115_config(&tm, &tp) != 0)
melog(TRTCM_RFC4115_AWARE_CHECK_MSG);
time = rte_get_tsc_cycles() + hz;
if (rte_meter_trtcm_rfc4115_color_aware_check(
&tm, &tp, time, TM_TEST_TRTCM_EBS_DF - 1, in[2]) != out[2])
melog(TRTCM_RFC4115_AWARE_CHECK_MSG" %u:%u", in[2], out[2]);
if (rte_meter_trtcm_rfc4115_profile_config(&tp, &rfc4115params) != 0)
melog(TRTCM_RFC4115_AWARE_CHECK_MSG);
if (rte_meter_trtcm_rfc4115_config(&tm, &tp) != 0)
melog(TRTCM_RFC4115_AWARE_CHECK_MSG);
time = rte_get_tsc_cycles() + hz;
if (rte_meter_trtcm_rfc4115_color_aware_check(
&tm, &tp, time, TM_TEST_TRTCM_EBS_DF + 1, in[3]) != out[3])
melog(TRTCM_RFC4115_AWARE_CHECK_MSG" %u:%u", in[3], out[3]);
return 0;
}
/**
* functional test for rte_meter_trtcm_rfc4115_color_aware_check
*/
static inline int
tm_test_trtcm_rfc4115_color_aware_check(void)
{
meter: replace color definitions This patch implements the changes proposed in the deprecation note[1]. Replace multiple color definitions in various places such as rte_meter.h, rte_tm.h and rte_mtr.h with single rte_color defined in rte_meter.h. This is simple search and replace exercise without any implementation change. [1] https://mails.dpdk.org/archives/dev/2019-January/123861.html Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-04-11 09:15:14 +00:00
enum rte_color in[4], out[4];
meter: support RFC4115 trTCM This patch adds support for RFC4115 trTCM meters. Signed-off-by: Eelco Chaudron <echaudro@redhat.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-01-04 13:59:42 +00:00
/**
* test 4 points that will produce green, yellow, yellow, red flag
* if using blind check
*/
/* previouly have a green, test points should keep unchanged */
meter: replace color definitions This patch implements the changes proposed in the deprecation note[1]. Replace multiple color definitions in various places such as rte_meter.h, rte_tm.h and rte_mtr.h with single rte_color defined in rte_meter.h. This is simple search and replace exercise without any implementation change. [1] https://mails.dpdk.org/archives/dev/2019-January/123861.html Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-04-11 09:15:14 +00:00
in[0] = in[1] = in[2] = in[3] = RTE_COLOR_GREEN;
out[0] = RTE_COLOR_GREEN;
out[1] = RTE_COLOR_YELLOW;
out[2] = RTE_COLOR_YELLOW;
out[3] = RTE_COLOR_RED;
meter: support RFC4115 trTCM This patch adds support for RFC4115 trTCM meters. Signed-off-by: Eelco Chaudron <echaudro@redhat.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-01-04 13:59:42 +00:00
if (tm_test_trtcm_rfc4115_aware_check(in, out) != 0)
return -1;
meter: replace color definitions This patch implements the changes proposed in the deprecation note[1]. Replace multiple color definitions in various places such as rte_meter.h, rte_tm.h and rte_mtr.h with single rte_color defined in rte_meter.h. This is simple search and replace exercise without any implementation change. [1] https://mails.dpdk.org/archives/dev/2019-January/123861.html Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-04-11 09:15:14 +00:00
in[0] = in[1] = in[2] = in[3] = RTE_COLOR_YELLOW;
out[0] = RTE_COLOR_YELLOW;
out[1] = RTE_COLOR_YELLOW;
out[2] = RTE_COLOR_YELLOW;
out[3] = RTE_COLOR_RED;
meter: support RFC4115 trTCM This patch adds support for RFC4115 trTCM meters. Signed-off-by: Eelco Chaudron <echaudro@redhat.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-01-04 13:59:42 +00:00
if (tm_test_trtcm_rfc4115_aware_check(in, out) != 0)
return -1;
meter: replace color definitions This patch implements the changes proposed in the deprecation note[1]. Replace multiple color definitions in various places such as rte_meter.h, rte_tm.h and rte_mtr.h with single rte_color defined in rte_meter.h. This is simple search and replace exercise without any implementation change. [1] https://mails.dpdk.org/archives/dev/2019-January/123861.html Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-04-11 09:15:14 +00:00
in[0] = in[1] = in[2] = in[3] = RTE_COLOR_RED;
out[0] = RTE_COLOR_RED;
out[1] = RTE_COLOR_RED;
out[2] = RTE_COLOR_RED;
out[3] = RTE_COLOR_RED;
meter: support RFC4115 trTCM This patch adds support for RFC4115 trTCM meters. Signed-off-by: Eelco Chaudron <echaudro@redhat.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-01-04 13:59:42 +00:00
if (tm_test_trtcm_rfc4115_aware_check(in, out) != 0)
return -1;
return 0;
}
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
/**
* test main entrance for library meter
*/
app/test: convert all tests to register system Remove all tests from the builtin commands list and use the dynamic commands list register macro. Signed-off-by: David Marchand <david.marchand@6wind.com> Acked-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com>
2014-08-18 11:29:23 +00:00
static int
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
test_meter(void)
{
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (tm_test_srtcm_config() != 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
return -1;
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (tm_test_trtcm_config() != 0)
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
return -1;
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
meter: support RFC4115 trTCM This patch adds support for RFC4115 trTCM meters. Signed-off-by: Eelco Chaudron <echaudro@redhat.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-01-04 13:59:42 +00:00
if (tm_test_trtcm_rfc4115_config() != 0)
return -1;
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (tm_test_srtcm_color_blind_check() != 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
return -1;
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (tm_test_trtcm_color_blind_check() != 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
return -1;
meter: support RFC4115 trTCM This patch adds support for RFC4115 trTCM meters. Signed-off-by: Eelco Chaudron <echaudro@redhat.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-01-04 13:59:42 +00:00
if (tm_test_trtcm_rfc4115_color_blind_check() != 0)
return -1;
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (tm_test_srtcm_color_aware_check() != 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
return -1;
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
if (tm_test_trtcm_color_aware_check() != 0)
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
return -1;
remove trailing whitespaces This commit removes trailing whitespace from lines in files. Almost all files are affected, as the BSD license copyright header had trailing whitespace on 4 lines in it [hence the number of files reporting 8 lines changed in the diffstat]. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> [Thomas: remove spaces before tabs in libs] [Thomas: remove more trailing spaces in non-C files] Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-06-03 23:42:50 +00:00
meter: support RFC4115 trTCM This patch adds support for RFC4115 trTCM meters. Signed-off-by: Eelco Chaudron <echaudro@redhat.com> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
2019-01-04 13:59:42 +00:00
if (tm_test_trtcm_rfc4115_color_aware_check() != 0)
return -1;
meter: initial import Signed-off-by: Intel
2013-06-03 00:00:00 +00:00
return 0;
}
app/test: rework command registration The tests are registered with their command name by adding a structure to a list. The structure of each test was declared in each test file and passed to the register macro. This rework generate the structure inside the register macro. Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com> Reviewed-by: Jan Viktorin <viktorin@rehivetech.com>
2016-07-13 12:38:13 +00:00
REGISTER_TEST_COMMAND(meter_autotest, test_meter);
Reference in New Issue Copy Permalink