* Re: [dpdk-dev] [PATCH] mbuf: implement generic format for sched field
2018-11-23 16:54 [dpdk-dev] [PATCH] mbuf: implement generic format for sched field Jasvinder Singh
@ 2018-11-26 11:37 ` Dumitrescu, Cristian
2018-11-29 10:42 ` Singh, Jasvinder
2018-12-01 14:22 ` Jerin Jacob
` (3 subsequent siblings)
4 siblings, 1 reply; 74+ messages in thread
From: Dumitrescu, Cristian @ 2018-11-26 11:37 UTC (permalink / raw)
To: Singh, Jasvinder, dev; +Cc: Pattan, Reshma
Hi Jasvinder,
> -----Original Message-----
> From: Singh, Jasvinder
> Sent: Friday, November 23, 2018 4:54 PM
> To: dev@dpdk.org
> Cc: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Pattan, Reshma
> <reshma.pattan@intel.com>
> Subject: [PATCH] mbuf: implement generic format for sched field
>
> This patch implements the changes proposed in the deprecation
> notes [1][2].
>
> The opaque mbuf->hash.sched field is updated to support generic
> definition in line with the ethdev TM and MTR APIs. The new generic
> format contains: queue ID, traffic class, color.
>
> In addtion, following API functions of the sched library have
> been modified with an additional parameter of type struct
> rte_sched_port to accomodate the changes made to mbuf sched field.
> (i) rte_sched_port_pkt_write()
> (ii) rte_sched_port_pkt_read()
>
> The other libraries, sample applications and tests which use mbuf
> sched field have been updated as well.
>
> [1] http://mails.dpdk.org/archives/dev/2018-February/090651.html
> [2] https://mails.dpdk.org/archives/dev/2018-November/119051.html
>
> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
> Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> ---
> examples/qos_sched/app_thread.c | 6 +-
> examples/qos_sched/main.c | 1 +
> .../rte_event_eth_tx_adapter.h | 4 +-
> lib/librte_mbuf/Makefile | 2 +-
> lib/librte_mbuf/rte_mbuf.h | 10 +--
> lib/librte_pipeline/rte_table_action.c | 60 ++++++++-----
> lib/librte_sched/Makefile | 2 +-
> lib/librte_sched/rte_sched.c | 89 +++++++------------
> lib/librte_sched/rte_sched.h | 10 ++-
> test/test/test_sched.c | 8 +-
> 10 files changed, 92 insertions(+), 100 deletions(-)
>
<snip>
> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> index 3dbc6695e..98428bd21 100644
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -575,12 +575,10 @@ struct rte_mbuf {
> */
> } fdir; /**< Filter identifier if FDIR enabled */
> struct {
> - uint32_t lo;
> - uint32_t hi;
> - /**< The event eth Tx adapter uses this field
> - * to store Tx queue id.
> - * @see
> rte_event_eth_tx_adapter_txq_set()
> - */
> + uint32_t queue_id; /**< Queue ID. */
> + uint8_t traffic_class; /**< Traffic class ID. */
We should add comment here that traffic class 0 is the highest priority traffic class.
> + uint8_t color; /**< Color. */
We should create a new file rte_color.h in a common place (librte_eal/common/include) to consolidate the color definition, which is currently replicated in too many places, such as: rte_meter.h, rte_mtr.h, rte_tm.h.
We should include the rte_color.h file here (and in the above header files)
We should also document the link between this field and the color enum type (@see ...).
> + uint16_t reserved; /**< Reserved. */
> } sched; /**< Hierarchical scheduler */
> /**< User defined tags. See
> rte_distributor_process() */
> uint32_t usr;
We should also add trivial inline functions to read/write these mbuf fields as part of this header file. We want to discourage people from accessing these fields directly.
Besides the functions to read/write each field individually, we should also have a function to read all the sched fields in one operation, as well as another one to write all the sched fields in one operation.
> diff --git a/lib/librte_pipeline/rte_table_action.c
> b/lib/librte_pipeline/rte_table_action.c
> index 7c7c8dd82..99f2d779b 100644
> --- a/lib/librte_pipeline/rte_table_action.c
> +++ b/lib/librte_pipeline/rte_table_action.c
> @@ -108,12 +108,12 @@ mtr_cfg_check(struct rte_table_action_mtr_config
> *mtr)
> }
>
> #define MBUF_SCHED_QUEUE_TC_COLOR(queue, tc, color) \
> - ((uint16_t)((((uint64_t)(queue)) & 0x3) | \
> - ((((uint64_t)(tc)) & 0x3) << 2) | \
> - ((((uint64_t)(color)) & 0x3) << 4)))
> + ((uint64_t)((((uint64_t)(queue)) & 0xffffffff) | \
> + ((((uint64_t)(tc)) & 0xff) << 32) | \
> + ((((uint64_t)(color)) & 0xff) << 40)))
>
> #define MBUF_SCHED_COLOR(sched, color) \
> - (((sched) & (~0x30LLU)) | ((color) << 4))
> + ((uint64_t)((sched) & (~0xff000000LLU)) | (((uint64_t)(color)) << 40))
>
Given the read/write mbuf->sched field functions, the above two macros are no longer needed.
> struct mtr_trtcm_data {
> struct rte_meter_trtcm trtcm;
> @@ -176,7 +176,7 @@ mtr_data_size(struct rte_table_action_mtr_config
> *mtr)
> struct dscp_table_entry_data {
> enum rte_meter_color color;
> uint16_t tc;
> - uint16_t queue_tc_color;
> + uint32_t queue;
> };
>
> struct dscp_table_data {
> @@ -368,7 +368,6 @@ tm_cfg_check(struct rte_table_action_tm_config
> *tm)
> }
>
> struct tm_data {
> - uint16_t queue_tc_color;
> uint16_t subport;
> uint32_t pipe;
> } __attribute__((__packed__));
> @@ -397,26 +396,40 @@ tm_apply(struct tm_data *data,
> return status;
>
> /* Apply */
> - data->queue_tc_color = 0;
> data->subport = (uint16_t) p->subport_id;
> data->pipe = p->pipe_id;
>
> return 0;
> }
>
> +static uint32_t
> +tm_sched_qindex(struct tm_data *data,
> + struct dscp_table_entry_data *dscp,
> + struct rte_table_action_tm_config *cfg) {
> +
> + uint32_t result;
> +
> + result = data->subport * cfg->n_pipes_per_subport + data->pipe;
Since n_subports_per_pipe and n_pipes_per_subport are enforced to be power of 2, we should replace multiplication/division with shift left/right. We probably need to store log2 correspondents in the action context.
> + result = result * RTE_TABLE_ACTION_TC_MAX + dscp->tc;
> + result = result * RTE_TABLE_ACTION_TC_QUEUE_MAX + dscp-
> >queue;
> +
> + return result;
> +}
> +
> static __rte_always_inline void
> pkt_work_tm(struct rte_mbuf *mbuf,
> struct tm_data *data,
> struct dscp_table_data *dscp_table,
> - uint32_t dscp)
> + uint32_t dscp,
> + struct rte_table_action_tm_config *cfg)
> {
> struct dscp_table_entry_data *dscp_entry = &dscp_table-
> >entry[dscp];
> - struct tm_data *sched_ptr = (struct tm_data *) &mbuf->hash.sched;
> - struct tm_data sched;
> + uint64_t *sched_ptr = (uint64_t *) &mbuf->hash.sched;
> + uint32_t queue = tm_sched_qindex(data, dscp_entry, cfg);
>
> - sched = *data;
> - sched.queue_tc_color = dscp_entry->queue_tc_color;
> - *sched_ptr = sched;
> + *sched_ptr = MBUF_SCHED_QUEUE_TC_COLOR(queue,
> + dscp_entry->tc,
> + dscp_entry->color);
> }
>
> /**
> @@ -2580,17 +2593,13 @@ rte_table_action_dscp_table_update(struct
> rte_table_action *action,
> &action->dscp_table.entry[i];
> struct rte_table_action_dscp_table_entry *entry =
> &table->entry[i];
> - uint16_t queue_tc_color =
> - MBUF_SCHED_QUEUE_TC_COLOR(entry-
> >tc_queue_id,
> - entry->tc_id,
> - entry->color);
>
> if ((dscp_mask & (1LLU << i)) == 0)
> continue;
>
> data->color = entry->color;
> data->tc = entry->tc_id;
> - data->queue_tc_color = queue_tc_color;
> + data->queue = entry->tc_queue_id;
> }
>
> return 0;
> @@ -2882,7 +2891,8 @@ pkt_work(struct rte_mbuf *mbuf,
> pkt_work_tm(mbuf,
> data,
> &action->dscp_table,
> - dscp);
> + dscp,
> + &cfg->tm);
> }
>
> if (cfg->action_mask & (1LLU << RTE_TABLE_ACTION_DECAP)) {
> @@ -3108,22 +3118,26 @@ pkt4_work(struct rte_mbuf **mbufs,
> pkt_work_tm(mbuf0,
> data0,
> &action->dscp_table,
> - dscp0);
> + dscp0,
> + &cfg->tm);
>
> pkt_work_tm(mbuf1,
> data1,
> &action->dscp_table,
> - dscp1);
> + dscp1,
> + &cfg->tm);
>
> pkt_work_tm(mbuf2,
> data2,
> &action->dscp_table,
> - dscp2);
> + dscp2,
> + &cfg->tm);
>
> pkt_work_tm(mbuf3,
> data3,
> &action->dscp_table,
> - dscp3);
> + dscp3,
> + &cfg->tm);
> }
>
> if (cfg->action_mask & (1LLU << RTE_TABLE_ACTION_DECAP)) {
> diff --git a/lib/librte_sched/Makefile b/lib/librte_sched/Makefile
> index 46c53ed71..644fd9d15 100644
> --- a/lib/librte_sched/Makefile
> +++ b/lib/librte_sched/Makefile
> @@ -18,7 +18,7 @@ LDLIBS += -lrte_timer
>
> EXPORT_MAP := rte_sched_version.map
>
> -LIBABIVER := 1
> +LIBABIVER := 2
>
> #
> # all source are stored in SRCS-y
> diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c
> index 587d5e602..7bf4d6400 100644
> --- a/lib/librte_sched/rte_sched.c
> +++ b/lib/librte_sched/rte_sched.c
> @@ -128,22 +128,6 @@ enum grinder_state {
> e_GRINDER_READ_MBUF
> };
>
> -/*
> - * Path through the scheduler hierarchy used by the scheduler enqueue
> - * operation to identify the destination queue for the current
> - * packet. Stored in the field pkt.hash.sched of struct rte_mbuf of
> - * each packet, typically written by the classification stage and read
> - * by scheduler enqueue.
> - */
> -struct rte_sched_port_hierarchy {
> - uint16_t queue:2; /**< Queue ID (0 .. 3) */
> - uint16_t traffic_class:2; /**< Traffic class ID (0 .. 3)*/
> - uint32_t color:2; /**< Color */
> - uint16_t unused:10;
> - uint16_t subport; /**< Subport ID */
> - uint32_t pipe; /**< Pipe ID */
> -};
> -
> struct rte_sched_grinder {
> /* Pipe cache */
> uint16_t pcache_qmask[RTE_SCHED_GRINDER_PCACHE_SIZE];
> @@ -241,16 +225,12 @@ enum rte_sched_port_array {
> e_RTE_SCHED_PORT_ARRAY_TOTAL,
> };
>
> -#ifdef RTE_SCHED_COLLECT_STATS
> -
> static inline uint32_t
> rte_sched_port_queues_per_subport(struct rte_sched_port *port)
> {
> return RTE_SCHED_QUEUES_PER_PIPE * port-
> >n_pipes_per_subport;
> }
>
> -#endif
> -
> static inline uint32_t
> rte_sched_port_queues_per_port(struct rte_sched_port *port)
> {
> @@ -1006,44 +986,50 @@ rte_sched_port_pipe_profile_add(struct
> rte_sched_port *port,
> return 0;
> }
>
> +static inline uint32_t
> +rte_sched_port_qindex(struct rte_sched_port *port,
> + uint32_t subport,
> + uint32_t pipe,
> + uint32_t traffic_class,
> + uint32_t queue)
> +{
> + uint32_t result;
> +
> + result = subport * port->n_pipes_per_subport + pipe;
Since n_subports_per_pipe and n_pipes_per_subport are enforced to be power of 2, we should replace multiplication/division with shift left/right.
> + result = result * RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE +
> traffic_class;
> + result = result * RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS + queue;
> +
> + return result;
> +}
> +
> void
> -rte_sched_port_pkt_write(struct rte_mbuf *pkt,
> +rte_sched_port_pkt_write(struct rte_sched_port *port,
> + struct rte_mbuf *pkt,
> uint32_t subport, uint32_t pipe, uint32_t
> traffic_class,
> uint32_t queue, enum rte_meter_color color)
> {
> - struct rte_sched_port_hierarchy *sched
> - = (struct rte_sched_port_hierarchy *) &pkt->hash.sched;
> -
> - RTE_BUILD_BUG_ON(sizeof(*sched) > sizeof(pkt->hash.sched));
> -
> - sched->color = (uint32_t) color;
> - sched->subport = subport;
> - sched->pipe = pipe;
> - sched->traffic_class = traffic_class;
> - sched->queue = queue;
> + pkt->hash.sched.traffic_class = traffic_class;
> + pkt->hash.sched.queue_id = rte_sched_port_qindex(port, subport,
> pipe,
> + traffic_class, queue);
> + pkt->hash.sched.color = (uint8_t) color;
> }
>
> void
> -rte_sched_port_pkt_read_tree_path(const struct rte_mbuf *pkt,
> +rte_sched_port_pkt_read_tree_path(struct rte_sched_port *port,
> + const struct rte_mbuf *pkt,
> uint32_t *subport, uint32_t *pipe,
> uint32_t *traffic_class, uint32_t *queue)
> {
> - const struct rte_sched_port_hierarchy *sched
> - = (const struct rte_sched_port_hierarchy *) &pkt-
> >hash.sched;
> -
> - *subport = sched->subport;
> - *pipe = sched->pipe;
> - *traffic_class = sched->traffic_class;
> - *queue = sched->queue;
> + *subport = pkt->hash.sched.queue_id /
> rte_sched_port_queues_per_subport(port);
> + *pipe = pkt->hash.sched.queue_id /
> RTE_SCHED_QUEUES_PER_PIPE;
Since n_subports_per_pipe and n_pipes_per_subport are enforced to be power of 2, we should replace multiplication/division with shift left/right.
> + *traffic_class = pkt->hash.sched.traffic_class;
> + *queue = pkt->hash.sched.queue_id %
> RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS;
Since RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS is enforced to be a power of 2, please replace modulo with bitwise AND of (RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS - 1).
> }
>
> enum rte_meter_color
> rte_sched_port_pkt_read_color(const struct rte_mbuf *pkt)
> {
> - const struct rte_sched_port_hierarchy *sched
> - = (const struct rte_sched_port_hierarchy *) &pkt-
> >hash.sched;
> -
> - return (enum rte_meter_color) sched->color;
> + return (enum rte_meter_color) pkt->hash.sched.color;
> }
Should use the mbuf->sched.color read function to be added in rte_mbuf.h.
>
> int
> @@ -1100,18 +1086,6 @@ rte_sched_queue_read_stats(struct
> rte_sched_port *port,
> return 0;
> }
>
> -static inline uint32_t
> -rte_sched_port_qindex(struct rte_sched_port *port, uint32_t subport,
> uint32_t pipe, uint32_t traffic_class, uint32_t queue)
> -{
> - uint32_t result;
> -
> - result = subport * port->n_pipes_per_subport + pipe;
> - result = result * RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE +
> traffic_class;
> - result = result * RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS + queue;
> -
> - return result;
> -
Since n_subports_per_pipe and n_pipes_per_subport are enforced to be power of 2, we should replace multiplication/division with shift left/right.
}
> -
> #ifdef RTE_SCHED_DEBUG
>
> static inline int
> @@ -1272,11 +1246,8 @@ rte_sched_port_enqueue_qptrs_prefetch0(struct
> rte_sched_port *port,
> #ifdef RTE_SCHED_COLLECT_STATS
> struct rte_sched_queue_extra *qe;
> #endif
> - uint32_t subport, pipe, traffic_class, queue, qindex;
> -
> - rte_sched_port_pkt_read_tree_path(pkt, &subport, &pipe,
> &traffic_class, &queue);
> + uint32_t qindex = pkt->hash.sched.queue_id;
Let's use the read function for this mbuf field.
>
> - qindex = rte_sched_port_qindex(port, subport, pipe, traffic_class,
> queue);
> q = port->queue + qindex;
> rte_prefetch0(q);
> #ifdef RTE_SCHED_COLLECT_STATS
> diff --git a/lib/librte_sched/rte_sched.h b/lib/librte_sched/rte_sched.h
> index 84fa896de..4d9f869eb 100644
> --- a/lib/librte_sched/rte_sched.h
> +++ b/lib/librte_sched/rte_sched.h
> @@ -355,6 +355,8 @@ rte_sched_queue_read_stats(struct rte_sched_port
> *port,
> * Scheduler hierarchy path write to packet descriptor. Typically
> * called by the packet classification stage.
> *
> + * @param port
> + * Handle to port scheduler instance
> * @param pkt
> * Packet descriptor handle
> * @param subport
> @@ -369,7 +371,8 @@ rte_sched_queue_read_stats(struct rte_sched_port
> *port,
> * Packet color set
> */
> void
> -rte_sched_port_pkt_write(struct rte_mbuf *pkt,
> +rte_sched_port_pkt_write(struct rte_sched_port *port,
> + struct rte_mbuf *pkt,
> uint32_t subport, uint32_t pipe, uint32_t
> traffic_class,
> uint32_t queue, enum rte_meter_color color);
>
> @@ -379,6 +382,8 @@ rte_sched_port_pkt_write(struct rte_mbuf *pkt,
> * enqueue operation. The subport, pipe, traffic class and queue
> * parameters need to be pre-allocated by the caller.
> *
> + * @param port
> + * Handle to port scheduler instance
> * @param pkt
> * Packet descriptor handle
> * @param subport
> @@ -392,7 +397,8 @@ rte_sched_port_pkt_write(struct rte_mbuf *pkt,
> *
> */
> void
> -rte_sched_port_pkt_read_tree_path(const struct rte_mbuf *pkt,
> +rte_sched_port_pkt_read_tree_path(struct rte_sched_port *port,
> + const struct rte_mbuf *pkt,
> uint32_t *subport, uint32_t *pipe,
> uint32_t *traffic_class, uint32_t *queue);
>
<snip>
Regards,
Cristian
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH] mbuf: implement generic format for sched field
2018-11-26 11:37 ` Dumitrescu, Cristian
@ 2018-11-29 10:42 ` Singh, Jasvinder
2018-12-04 17:39 ` Dumitrescu, Cristian
0 siblings, 1 reply; 74+ messages in thread
From: Singh, Jasvinder @ 2018-11-29 10:42 UTC (permalink / raw)
To: Dumitrescu, Cristian, dev; +Cc: Pattan, Reshma
<snip>
>
> > diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> > index 3dbc6695e..98428bd21 100644
> > --- a/lib/librte_mbuf/rte_mbuf.h
> > +++ b/lib/librte_mbuf/rte_mbuf.h
> > @@ -575,12 +575,10 @@ struct rte_mbuf {
> > */
> > } fdir; /**< Filter identifier if FDIR enabled */
> > struct {
> > - uint32_t lo;
> > - uint32_t hi;
> > - /**< The event eth Tx adapter uses this field
> > - * to store Tx queue id.
> > - * @see
> > rte_event_eth_tx_adapter_txq_set()
> > - */
> > + uint32_t queue_id; /**< Queue ID. */
> > + uint8_t traffic_class; /**< Traffic class ID. */
>
> We should add comment here that traffic class 0 is the highest priority traffic
> class.
Will add the suggested comment.
>
> > + uint8_t color; /**< Color. */
>
> We should create a new file rte_color.h in a common place
> (librte_eal/common/include) to consolidate the color definition, which is
> currently replicated in too many places, such as: rte_meter.h, rte_mtr.h,
> rte_tm.h.
>
> We should include the rte_color.h file here (and in the above header files)
>
> We should also document the link between this field and the color enum type
> (@see ...).
Replacing the existing color definition with the above suggested one in rte_meter.h (librte_meter)
would be ABI break. We can do it separately through different patch.
>
> > + uint16_t reserved; /**< Reserved. */
> > } sched; /**< Hierarchical scheduler */
> > /**< User defined tags. See
> > rte_distributor_process() */
> > uint32_t usr;
>
> We should also add trivial inline functions to read/write these mbuf fields as
> part of this header file. We want to discourage people from accessing these
> fields directly.
>
> Besides the functions to read/write each field individually, we should also
> have a function to read all the sched fields in one operation, as well as another
> one to write all the sched fields in one operation.
Will create inline functions for reading and writing each field separately and jointly.
>
> > diff --git a/lib/librte_pipeline/rte_table_action.c
> > b/lib/librte_pipeline/rte_table_action.c
> > index 7c7c8dd82..99f2d779b 100644
> > --- a/lib/librte_pipeline/rte_table_action.c
> > +++ b/lib/librte_pipeline/rte_table_action.c
> > @@ -108,12 +108,12 @@ mtr_cfg_check(struct rte_table_action_mtr_config
> > *mtr)
> > }
> >
> > #define MBUF_SCHED_QUEUE_TC_COLOR(queue, tc, color) \
> > - ((uint16_t)((((uint64_t)(queue)) & 0x3) | \
> > - ((((uint64_t)(tc)) & 0x3) << 2) | \
> > - ((((uint64_t)(color)) & 0x3) << 4)))
> > + ((uint64_t)((((uint64_t)(queue)) & 0xffffffff) | \
> > + ((((uint64_t)(tc)) & 0xff) << 32) | \
> > + ((((uint64_t)(color)) & 0xff) << 40)))
> >
> > #define MBUF_SCHED_COLOR(sched, color) \
> > - (((sched) & (~0x30LLU)) | ((color) << 4))
> > + ((uint64_t)((sched) & (~0xff000000LLU)) | (((uint64_t)(color)) <<
> > +40))
> >
>
> Given the read/write mbuf->sched field functions, the above two macros are
> no longer needed.
Will remove this.
> > struct mtr_trtcm_data {
> > struct rte_meter_trtcm trtcm;
> > @@ -176,7 +176,7 @@ mtr_data_size(struct rte_table_action_mtr_config
> > *mtr)
> > struct dscp_table_entry_data {
> > enum rte_meter_color color;
> > uint16_t tc;
> > - uint16_t queue_tc_color;
> > + uint32_t queue;
> > };
> >
> > struct dscp_table_data {
> > @@ -368,7 +368,6 @@ tm_cfg_check(struct rte_table_action_tm_config
> > *tm)
> > }
> >
> > struct tm_data {
> > - uint16_t queue_tc_color;
> > uint16_t subport;
> > uint32_t pipe;
> > } __attribute__((__packed__));
> > @@ -397,26 +396,40 @@ tm_apply(struct tm_data *data,
> > return status;
> >
> > /* Apply */
> > - data->queue_tc_color = 0;
> > data->subport = (uint16_t) p->subport_id;
> > data->pipe = p->pipe_id;
> >
> > return 0;
> > }
> >
> > +static uint32_t
> > +tm_sched_qindex(struct tm_data *data,
> > + struct dscp_table_entry_data *dscp,
> > + struct rte_table_action_tm_config *cfg) {
> > +
> > + uint32_t result;
> > +
> > + result = data->subport * cfg->n_pipes_per_subport + data->pipe;
>
> Since n_subports_per_pipe and n_pipes_per_subport are enforced to be
> power of 2, we should replace multiplication/division with shift left/right. We
> probably need to store log2 correspondents in the action context.
Thanks. Will store log2 component in action context and use them in run time for shift operations.
> > + result = result * RTE_TABLE_ACTION_TC_MAX + dscp->tc;
> > + result = result * RTE_TABLE_ACTION_TC_QUEUE_MAX + dscp-
> > >queue;
> > +
> > + return result;
> > +}
> > +
> > static __rte_always_inline void
> > pkt_work_tm(struct rte_mbuf *mbuf,
> > struct tm_data *data,
> > struct dscp_table_data *dscp_table,
> > - uint32_t dscp)
> > + uint32_t dscp,
> > + struct rte_table_action_tm_config *cfg)
> > {
> > struct dscp_table_entry_data *dscp_entry = &dscp_table-
> > >entry[dscp];
> > - struct tm_data *sched_ptr = (struct tm_data *) &mbuf->hash.sched;
> > - struct tm_data sched;
> > + uint64_t *sched_ptr = (uint64_t *) &mbuf->hash.sched;
> > + uint32_t queue = tm_sched_qindex(data, dscp_entry, cfg);
> >
> > - sched = *data;
> > - sched.queue_tc_color = dscp_entry->queue_tc_color;
> > - *sched_ptr = sched;
> > + *sched_ptr = MBUF_SCHED_QUEUE_TC_COLOR(queue,
> > + dscp_entry->tc,
> > + dscp_entry->color);
> > }
> >
> > /**
> > @@ -2580,17 +2593,13 @@ rte_table_action_dscp_table_update(struct
> > rte_table_action *action,
> > &action->dscp_table.entry[i];
> > struct rte_table_action_dscp_table_entry *entry =
> > &table->entry[i];
> > - uint16_t queue_tc_color =
> > - MBUF_SCHED_QUEUE_TC_COLOR(entry-
> > >tc_queue_id,
> > - entry->tc_id,
> > - entry->color);
> >
> > if ((dscp_mask & (1LLU << i)) == 0)
> > continue;
> >
> > data->color = entry->color;
> > data->tc = entry->tc_id;
> > - data->queue_tc_color = queue_tc_color;
> > + data->queue = entry->tc_queue_id;
> > }
> >
> > return 0;
> > @@ -2882,7 +2891,8 @@ pkt_work(struct rte_mbuf *mbuf,
> > pkt_work_tm(mbuf,
> > data,
> > &action->dscp_table,
> > - dscp);
> > + dscp,
> > + &cfg->tm);
> > }
> >
> > if (cfg->action_mask & (1LLU << RTE_TABLE_ACTION_DECAP)) { @@
> > -3108,22 +3118,26 @@ pkt4_work(struct rte_mbuf **mbufs,
> > pkt_work_tm(mbuf0,
> > data0,
> > &action->dscp_table,
> > - dscp0);
> > + dscp0,
> > + &cfg->tm);
> >
> > pkt_work_tm(mbuf1,
> > data1,
> > &action->dscp_table,
> > - dscp1);
> > + dscp1,
> > + &cfg->tm);
> >
> > pkt_work_tm(mbuf2,
> > data2,
> > &action->dscp_table,
> > - dscp2);
> > + dscp2,
> > + &cfg->tm);
> >
> > pkt_work_tm(mbuf3,
> > data3,
> > &action->dscp_table,
> > - dscp3);
> > + dscp3,
> > + &cfg->tm);
> > }
> >
> > if (cfg->action_mask & (1LLU << RTE_TABLE_ACTION_DECAP)) { diff
> > --git a/lib/librte_sched/Makefile b/lib/librte_sched/Makefile index
> > 46c53ed71..644fd9d15 100644
> > --- a/lib/librte_sched/Makefile
> > +++ b/lib/librte_sched/Makefile
> > @@ -18,7 +18,7 @@ LDLIBS += -lrte_timer
> >
> > EXPORT_MAP := rte_sched_version.map
> >
> > -LIBABIVER := 1
> > +LIBABIVER := 2
> >
> > #
> > # all source are stored in SRCS-y
> > diff --git a/lib/librte_sched/rte_sched.c
> > b/lib/librte_sched/rte_sched.c index 587d5e602..7bf4d6400 100644
> > --- a/lib/librte_sched/rte_sched.c
> > +++ b/lib/librte_sched/rte_sched.c
> > @@ -128,22 +128,6 @@ enum grinder_state {
> > e_GRINDER_READ_MBUF
> > };
> >
> > -/*
> > - * Path through the scheduler hierarchy used by the scheduler enqueue
> > - * operation to identify the destination queue for the current
> > - * packet. Stored in the field pkt.hash.sched of struct rte_mbuf of
> > - * each packet, typically written by the classification stage and
> > read
> > - * by scheduler enqueue.
> > - */
> > -struct rte_sched_port_hierarchy {
> > - uint16_t queue:2; /**< Queue ID (0 .. 3) */
> > - uint16_t traffic_class:2; /**< Traffic class ID (0 .. 3)*/
> > - uint32_t color:2; /**< Color */
> > - uint16_t unused:10;
> > - uint16_t subport; /**< Subport ID */
> > - uint32_t pipe; /**< Pipe ID */
> > -};
> > -
> > struct rte_sched_grinder {
> > /* Pipe cache */
> > uint16_t pcache_qmask[RTE_SCHED_GRINDER_PCACHE_SIZE];
> > @@ -241,16 +225,12 @@ enum rte_sched_port_array {
> > e_RTE_SCHED_PORT_ARRAY_TOTAL,
> > };
> >
> > -#ifdef RTE_SCHED_COLLECT_STATS
> > -
> > static inline uint32_t
> > rte_sched_port_queues_per_subport(struct rte_sched_port *port) {
> > return RTE_SCHED_QUEUES_PER_PIPE * port-
> > >n_pipes_per_subport;
> > }
> >
> > -#endif
> > -
> > static inline uint32_t
> > rte_sched_port_queues_per_port(struct rte_sched_port *port) { @@
> > -1006,44 +986,50 @@ rte_sched_port_pipe_profile_add(struct
> > rte_sched_port *port,
> > return 0;
> > }
> >
> > +static inline uint32_t
> > +rte_sched_port_qindex(struct rte_sched_port *port,
> > + uint32_t subport,
> > + uint32_t pipe,
> > + uint32_t traffic_class,
> > + uint32_t queue)
> > +{
> > + uint32_t result;
> > +
> > + result = subport * port->n_pipes_per_subport + pipe;
>
> Since n_subports_per_pipe and n_pipes_per_subport are enforced to be
> power of 2, we should replace multiplication/division with shift left/right.
Will replace with shift operation using log2 of n_subports_per_pipe and n_pipes_per_subport.
> > + result = result * RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE +
> > traffic_class;
> > + result = result * RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS + queue;
> > +
> > + return result;
> > +}
> > +
> > void
> > -rte_sched_port_pkt_write(struct rte_mbuf *pkt,
> > +rte_sched_port_pkt_write(struct rte_sched_port *port,
> > + struct rte_mbuf *pkt,
> > uint32_t subport, uint32_t pipe, uint32_t traffic_class,
> > uint32_t queue, enum rte_meter_color color) {
> > - struct rte_sched_port_hierarchy *sched
> > - = (struct rte_sched_port_hierarchy *) &pkt->hash.sched;
> > -
> > - RTE_BUILD_BUG_ON(sizeof(*sched) > sizeof(pkt->hash.sched));
> > -
> > - sched->color = (uint32_t) color;
> > - sched->subport = subport;
> > - sched->pipe = pipe;
> > - sched->traffic_class = traffic_class;
> > - sched->queue = queue;
> > + pkt->hash.sched.traffic_class = traffic_class;
> > + pkt->hash.sched.queue_id = rte_sched_port_qindex(port, subport,
> > pipe,
> > + traffic_class, queue);
> > + pkt->hash.sched.color = (uint8_t) color;
> > }
> >
> > void
> > -rte_sched_port_pkt_read_tree_path(const struct rte_mbuf *pkt,
> > +rte_sched_port_pkt_read_tree_path(struct rte_sched_port *port,
> > + const struct rte_mbuf *pkt,
> > uint32_t *subport, uint32_t *pipe,
> > uint32_t *traffic_class, uint32_t *queue) {
> > - const struct rte_sched_port_hierarchy *sched
> > - = (const struct rte_sched_port_hierarchy *) &pkt-
> > >hash.sched;
> > -
> > - *subport = sched->subport;
> > - *pipe = sched->pipe;
> > - *traffic_class = sched->traffic_class;
> > - *queue = sched->queue;
> > + *subport = pkt->hash.sched.queue_id /
> > rte_sched_port_queues_per_subport(port);
> > + *pipe = pkt->hash.sched.queue_id /
> > RTE_SCHED_QUEUES_PER_PIPE;
>
> Since n_subports_per_pipe and n_pipes_per_subport are enforced to be
> power of 2, we should replace multiplication/division with shift left/right.
Will do that.
> > + *traffic_class = pkt->hash.sched.traffic_class;
> > + *queue = pkt->hash.sched.queue_id %
> > RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS;
>
> Since RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS is enforced to be a power of
> 2, please replace modulo with bitwise AND of
> (RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS - 1).
>
> > }
Will do that.
> > enum rte_meter_color
> > rte_sched_port_pkt_read_color(const struct rte_mbuf *pkt) {
> > - const struct rte_sched_port_hierarchy *sched
> > - = (const struct rte_sched_port_hierarchy *) &pkt-
> > >hash.sched;
> > -
> > - return (enum rte_meter_color) sched->color;
> > + return (enum rte_meter_color) pkt->hash.sched.color;
> > }
>
> Should use the mbuf->sched.color read function to be added in rte_mbuf.h.
Yes. Will change this.
> > int
> > @@ -1100,18 +1086,6 @@ rte_sched_queue_read_stats(struct
> > rte_sched_port *port,
> > return 0;
> > }
> >
> > -static inline uint32_t
> > -rte_sched_port_qindex(struct rte_sched_port *port, uint32_t subport,
> > uint32_t pipe, uint32_t traffic_class, uint32_t queue) -{
> > - uint32_t result;
> > -
> > - result = subport * port->n_pipes_per_subport + pipe;
> > - result = result * RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE +
> > traffic_class;
> > - result = result * RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS + queue;
> > -
> > - return result;
> > -
>
> Since n_subports_per_pipe and n_pipes_per_subport are enforced to be
> power of 2, we should replace multiplication/division with shift left/right.
Will change this as well.
> }
> > -
> > #ifdef RTE_SCHED_DEBUG
> >
> > static inline int
> > @@ -1272,11 +1246,8 @@ rte_sched_port_enqueue_qptrs_prefetch0(struct
> > rte_sched_port *port,
> > #ifdef RTE_SCHED_COLLECT_STATS
> > struct rte_sched_queue_extra *qe;
> > #endif
> > - uint32_t subport, pipe, traffic_class, queue, qindex;
> > -
> > - rte_sched_port_pkt_read_tree_path(pkt, &subport, &pipe,
> > &traffic_class, &queue);
> > + uint32_t qindex = pkt->hash.sched.queue_id;
>
> Let's use the read function for this mbuf field.
Yes.
> >
> > - qindex = rte_sched_port_qindex(port, subport, pipe, traffic_class,
> > queue);
> > q = port->queue + qindex;
> > rte_prefetch0(q);
> > #ifdef RTE_SCHED_COLLECT_STATS
> > diff --git a/lib/librte_sched/rte_sched.h
> > b/lib/librte_sched/rte_sched.h index 84fa896de..4d9f869eb 100644
> > --- a/lib/librte_sched/rte_sched.h
> > +++ b/lib/librte_sched/rte_sched.h
> > @@ -355,6 +355,8 @@ rte_sched_queue_read_stats(struct rte_sched_port
> > *port,
> > * Scheduler hierarchy path write to packet descriptor. Typically
> > * called by the packet classification stage.
> > *
> > + * @param port
> > + * Handle to port scheduler instance
> > * @param pkt
> > * Packet descriptor handle
> > * @param subport
> > @@ -369,7 +371,8 @@ rte_sched_queue_read_stats(struct rte_sched_port
> > *port,
> > * Packet color set
> > */
> > void
> > -rte_sched_port_pkt_write(struct rte_mbuf *pkt,
> > +rte_sched_port_pkt_write(struct rte_sched_port *port,
> > + struct rte_mbuf *pkt,
> > uint32_t subport, uint32_t pipe, uint32_t traffic_class,
> > uint32_t queue, enum rte_meter_color color);
> >
> > @@ -379,6 +382,8 @@ rte_sched_port_pkt_write(struct rte_mbuf *pkt,
> > * enqueue operation. The subport, pipe, traffic class and queue
> > * parameters need to be pre-allocated by the caller.
> > *
> > + * @param port
> > + * Handle to port scheduler instance
> > * @param pkt
> > * Packet descriptor handle
> > * @param subport
> > @@ -392,7 +397,8 @@ rte_sched_port_pkt_write(struct rte_mbuf *pkt,
> > *
> > */
> > void
> > -rte_sched_port_pkt_read_tree_path(const struct rte_mbuf *pkt,
> > +rte_sched_port_pkt_read_tree_path(struct rte_sched_port *port,
> > + const struct rte_mbuf *pkt,
> > uint32_t *subport, uint32_t *pipe,
> > uint32_t *traffic_class, uint32_t *queue);
> >
>
> <snip>
>
> Regards,
> Cristian
We will work on the suggested changes and send another version. Thank you, Cristian.
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH] mbuf: implement generic format for sched field
2018-11-29 10:42 ` Singh, Jasvinder
@ 2018-12-04 17:39 ` Dumitrescu, Cristian
2018-12-05 12:22 ` Singh, Jasvinder
0 siblings, 1 reply; 74+ messages in thread
From: Dumitrescu, Cristian @ 2018-12-04 17:39 UTC (permalink / raw)
To: Singh, Jasvinder, dev; +Cc: Pattan, Reshma
> >
> > > + uint8_t color; /**< Color. */
> >
> > We should create a new file rte_color.h in a common place
> > (librte_eal/common/include) to consolidate the color definition, which is
> > currently replicated in too many places, such as: rte_meter.h, rte_mtr.h,
> > rte_tm.h.
> >
> > We should include the rte_color.h file here (and in the above header files)
> >
> > We should also document the link between this field and the color enum
> type
> > (@see ...).
>
> Replacing the existing color definition with the above suggested one in
> rte_meter.h (librte_meter)
> would be ABI break. We can do it separately through different patch.
>
> >
We can avoid any such issues in a two step process:
1. Create aliases to the new color in rte_meter.h, rte_mtr.h and rte_tm.h at this point.
2. Announce deprecation of the existing color enums in favor of the new unified color enum at this point and remove during next release.
Example:
//file "rte_meter.h"
#include <rte_color.h>
#define rte_meter_color rte_color
#define RTE_METER_GREEN RTE_COLOR_GREEN
#define RTE_METER_YELLOW RTE_COLOR_YELLOW
#define RTE_METER_RED RTE_COLOR_RED
Makes sense?
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [dpdk-dev] [PATCH] mbuf: implement generic format for sched field
2018-12-04 17:39 ` Dumitrescu, Cristian
@ 2018-12-05 12:22 ` Singh, Jasvinder
0 siblings, 0 replies; 74+ messages in thread
From: Singh, Jasvinder @ 2018-12-05 12:22 UTC (permalink / raw)
To: Dumitrescu, Cristian, dev; +Cc: Pattan, Reshma
> -----Original Message-----
> From: Dumitrescu, Cristian
> Sent: Tuesday, December 4, 2018 5:39 PM
> To: Singh, Jasvinder <jasvinder.singh@intel.com>; dev@dpdk.org
> Cc: Pattan, Reshma <reshma.pattan@intel.com>
> Subject: RE: [PATCH] mbuf: implement generic format for sched field
>
> > >
> > > > + uint8_t color; /**< Color. */
> > >
> > > We should create a new file rte_color.h in a common place
> > > (librte_eal/common/include) to consolidate the color definition,
> > > which is currently replicated in too many places, such as:
> > > rte_meter.h, rte_mtr.h, rte_tm.h.
> > >
> > > We should include the rte_color.h file here (and in the above header
> > > files)
> > >
> > > We should also document the link between this field and the color
> > > enum
> > type
> > > (@see ...).
> >
> > Replacing the existing color definition with the above suggested one
> > in rte_meter.h (librte_meter) would be ABI break. We can do it
> > separately through different patch.
> >
> > >
>
> We can avoid any such issues in a two step process:
> 1. Create aliases to the new color in rte_meter.h, rte_mtr.h and rte_tm.h at
> this point.
> 2. Announce deprecation of the existing color enums in favor of the new
> unified color enum at this point and remove during next release.
>
> Example:
> //file "rte_meter.h"
> #include <rte_color.h>
>
> #define rte_meter_color rte_color
> #define RTE_METER_GREEN RTE_COLOR_GREEN
> #define RTE_METER_YELLOW RTE_COLOR_YELLOW #define RTE_METER_RED
> RTE_COLOR_RED
>
> Makes sense?
Looks ok. We will do this clean-up work in a separate patch instead of mixing with mbuf patch. Thanks.
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [dpdk-dev] [PATCH] mbuf: implement generic format for sched field
2018-11-23 16:54 [dpdk-dev] [PATCH] mbuf: implement generic format for sched field Jasvinder Singh
2018-11-26 11:37 ` Dumitrescu, Cristian
@ 2018-12-01 14:22 ` Jerin Jacob
2018-12-05 11:15 ` Singh, Jasvinder
2018-12-10 17:49 ` Dumitrescu, Cristian
2018-12-07 14:31 ` [dpdk-dev] [PATCH v2 1/3] " Reshma Pattan
` (2 subsequent siblings)
4 siblings, 2 replies; 74+ messages in thread
From: Jerin Jacob @ 2018-12-01 14:22 UTC (permalink / raw)
To: Jasvinder Singh; +Cc: dev, cristian.dumitrescu, Reshma Pattan, nikhil.rao
-----Original Message-----
> Date: Fri, 23 Nov 2018 16:54:23 +0000
> From: Jasvinder Singh <jasvinder.singh@intel.com>
> To: dev@dpdk.org
> CC: cristian.dumitrescu@intel.com, Reshma Pattan <reshma.pattan@intel.com>
> Subject: [dpdk-dev] [PATCH] mbuf: implement generic format for sched field
> X-Mailer: git-send-email 2.17.1
>
> This patch implements the changes proposed in the deprecation
> notes [1][2].
>
> The opaque mbuf->hash.sched field is updated to support generic
> definition in line with the ethdev TM and MTR APIs. The new generic
> format contains: queue ID, traffic class, color.
>
> In addtion, following API functions of the sched library have
> been modified with an additional parameter of type struct
> rte_sched_port to accomodate the changes made to mbuf sched field.
> (i) rte_sched_port_pkt_write()
> (ii) rte_sched_port_pkt_read()
>
> The other libraries, sample applications and tests which use mbuf
> sched field have been updated as well.
>
> [1] http://mails.dpdk.org/archives/dev/2018-February/090651.html
> [2] https://mails.dpdk.org/archives/dev/2018-November/119051.html
>
> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
> Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> ---
> @@ -575,12 +575,10 @@ struct rte_mbuf {
> */
> } fdir; /**< Filter identifier if FDIR enabled */
> struct {
> - uint32_t lo;
> - uint32_t hi;
> - /**< The event eth Tx adapter uses this field
> - * to store Tx queue id.
> - * @see rte_event_eth_tx_adapter_txq_set()
> - */
> + uint32_t queue_id; /**< Queue ID. */
> + uint8_t traffic_class; /**< Traffic class ID. */
> + uint8_t color; /**< Color. */
> + uint16_t reserved; /**< Reserved. */
> } sched; /**< Hierarchical scheduler */
+Nikhil.
Currently rte_event_eth_tx_adapter_txq_set() and
rte_event_eth_tx_adapter_txq_get() implemented using
hash.sched.queue_id. How about moving out from "sched" to "txadapter"?
Something like below,
$ git diff
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 3dbc6695e..b73bbef93 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -575,13 +575,20 @@ struct rte_mbuf {
*/
} fdir; /**< Filter identifier if FDIR enabled
*/
struct {
- uint32_t lo;
- uint32_t hi;
+ uint32_t queue_id; /**< Queue ID. */
+ uint8_t traffic_class; /**< Traffic class ID. */
+ uint8_t color; /**< Color. */
+ uint16_t reserved; /**< Reserved. */
+ } sched; /**< Hierarchical scheduler */
+ struct {
+ uint32_t reserved1;
+ uint16_t reserved2;
+ uint16_t txq;
/**< The event eth Tx adapter uses this field
* to store Tx queue id.
* @see rte_event_eth_tx_adapter_txq_set()
*/
- } sched; /**< Hierarchical scheduler */
+ } txadapter; /**< Eventdev ethdev Tx adapter */
/**< User defined tags. See rte_distributor_process() */
uint32_t usr;
} hash; /**< hash information */
> rte_event_eth_tx_adapter_txq_set(struct rte_mbuf *pkt, uint16_t queue)
> {
> - uint16_t *p = (uint16_t *)&pkt->hash.sched.hi;
> + uint16_t *p = (uint16_t *)&pkt->hash.sched.queue_id;
> p[1] = queue;
> }
>
> @@ -320,7 +320,7 @@ rte_event_eth_tx_adapter_txq_set(struct rte_mbuf *pkt, uint16_t queue)
> static __rte_always_inline uint16_t __rte_experimental
> rte_event_eth_tx_adapter_txq_get(struct rte_mbuf *pkt)
> {
> - uint16_t *p = (uint16_t *)&pkt->hash.sched.hi;
> + uint16_t *p = (uint16_t *)&pkt->hash.sched.queue_id;
> return p[1];
> }
>
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH] mbuf: implement generic format for sched field
2018-12-01 14:22 ` Jerin Jacob
@ 2018-12-05 11:15 ` Singh, Jasvinder
2018-12-10 17:49 ` Dumitrescu, Cristian
1 sibling, 0 replies; 74+ messages in thread
From: Singh, Jasvinder @ 2018-12-05 11:15 UTC (permalink / raw)
To: Jerin Jacob; +Cc: dev, Dumitrescu, Cristian, Pattan, Reshma, Rao, Nikhil
> -----Original Message-----
> From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> Sent: Saturday, December 1, 2018 2:23 PM
> To: Singh, Jasvinder <jasvinder.singh@intel.com>
> Cc: dev@dpdk.org; Dumitrescu, Cristian <cristian.dumitrescu@intel.com>;
> Pattan, Reshma <reshma.pattan@intel.com>; Rao, Nikhil
> <nikhil.rao@intel.com>
> Subject: Re: [dpdk-dev] [PATCH] mbuf: implement generic format for sched
> field
>
> -----Original Message-----
> > Date: Fri, 23 Nov 2018 16:54:23 +0000
> > From: Jasvinder Singh <jasvinder.singh@intel.com>
> > To: dev@dpdk.org
> > CC: cristian.dumitrescu@intel.com, Reshma Pattan
> > <reshma.pattan@intel.com>
> > Subject: [dpdk-dev] [PATCH] mbuf: implement generic format for sched
> > field
> > X-Mailer: git-send-email 2.17.1
> >
> > This patch implements the changes proposed in the deprecation notes
> > [1][2].
> >
> > The opaque mbuf->hash.sched field is updated to support generic
> > definition in line with the ethdev TM and MTR APIs. The new generic
> > format contains: queue ID, traffic class, color.
> >
> > In addtion, following API functions of the sched library have been
> > modified with an additional parameter of type struct rte_sched_port to
> > accomodate the changes made to mbuf sched field.
> > (i) rte_sched_port_pkt_write()
> > (ii) rte_sched_port_pkt_read()
> >
> > The other libraries, sample applications and tests which use mbuf
> > sched field have been updated as well.
> >
> > [1] http://mails.dpdk.org/archives/dev/2018-February/090651.html
> > [2] https://mails.dpdk.org/archives/dev/2018-November/119051.html
> >
> > Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
> > Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> > ---
> > @@ -575,12 +575,10 @@ struct rte_mbuf {
> > */
> > } fdir; /**< Filter identifier if FDIR enabled */
> > struct {
> > - uint32_t lo;
> > - uint32_t hi;
> > - /**< The event eth Tx adapter uses this field
> > - * to store Tx queue id.
> > - * @see rte_event_eth_tx_adapter_txq_set()
> > - */
> > + uint32_t queue_id; /**< Queue ID. */
> > + uint8_t traffic_class; /**< Traffic class ID. */
> > + uint8_t color; /**< Color. */
> > + uint16_t reserved; /**< Reserved. */
> > } sched; /**< Hierarchical scheduler */
>
> +Nikhil.
>
> Currently rte_event_eth_tx_adapter_txq_set() and
> rte_event_eth_tx_adapter_txq_get() implemented using
> hash.sched.queue_id. How about moving out from "sched" to "txadapter"?
> Something like below,
>
> $ git diff
> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h index
> 3dbc6695e..b73bbef93 100644
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -575,13 +575,20 @@ struct rte_mbuf {
> */
> } fdir; /**< Filter identifier if FDIR enabled */
> struct {
> - uint32_t lo;
> - uint32_t hi;
> + uint32_t queue_id; /**< Queue ID. */
> + uint8_t traffic_class; /**< Traffic class ID. */
> + uint8_t color; /**< Color. */
> + uint16_t reserved; /**< Reserved. */
> + } sched; /**< Hierarchical scheduler */
> + struct {
> + uint32_t reserved1;
> + uint16_t reserved2;
> + uint16_t txq;
> /**< The event eth Tx adapter uses this field
> * to store Tx queue id.
> * @see rte_event_eth_tx_adapter_txq_set()
> */
> - } sched; /**< Hierarchical scheduler */
> + } txadapter; /**< Eventdev ethdev Tx adapter */
> /**< User defined tags. See rte_distributor_process() */
> uint32_t usr;
> } hash; /**< hash information */
>
>
> > rte_event_eth_tx_adapter_txq_set(struct rte_mbuf *pkt, uint16_t
> > queue) {
> > - uint16_t *p = (uint16_t *)&pkt->hash.sched.hi;
> > + uint16_t *p = (uint16_t *)&pkt->hash.sched.queue_id;
> > p[1] = queue;
> > }
> >
> > @@ -320,7 +320,7 @@ rte_event_eth_tx_adapter_txq_set(struct rte_mbuf
> > *pkt, uint16_t queue) static __rte_always_inline uint16_t
> > __rte_experimental rte_event_eth_tx_adapter_txq_get(struct rte_mbuf
> > *pkt) {
> > - uint16_t *p = (uint16_t *)&pkt->hash.sched.hi;
> > + uint16_t *p = (uint16_t *)&pkt->hash.sched.queue_id;
> > return p[1];
> > }
> >
Will make this change in the next version. Thanks.
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH] mbuf: implement generic format for sched field
2018-12-01 14:22 ` Jerin Jacob
2018-12-05 11:15 ` Singh, Jasvinder
@ 2018-12-10 17:49 ` Dumitrescu, Cristian
1 sibling, 0 replies; 74+ messages in thread
From: Dumitrescu, Cristian @ 2018-12-10 17:49 UTC (permalink / raw)
To: Jerin Jacob, Singh, Jasvinder; +Cc: dev, Pattan, Reshma, Rao, Nikhil
> -----Original Message-----
> From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> Sent: Saturday, December 1, 2018 2:23 PM
> To: Singh, Jasvinder <jasvinder.singh@intel.com>
> Cc: dev@dpdk.org; Dumitrescu, Cristian <cristian.dumitrescu@intel.com>;
> Pattan, Reshma <reshma.pattan@intel.com>; Rao, Nikhil
> <nikhil.rao@intel.com>
> Subject: Re: [dpdk-dev] [PATCH] mbuf: implement generic format for sched
> field
>
> -----Original Message-----
> > Date: Fri, 23 Nov 2018 16:54:23 +0000
> > From: Jasvinder Singh <jasvinder.singh@intel.com>
> > To: dev@dpdk.org
> > CC: cristian.dumitrescu@intel.com, Reshma Pattan
> <reshma.pattan@intel.com>
> > Subject: [dpdk-dev] [PATCH] mbuf: implement generic format for sched
> field
> > X-Mailer: git-send-email 2.17.1
> >
> > This patch implements the changes proposed in the deprecation
> > notes [1][2].
> >
> > The opaque mbuf->hash.sched field is updated to support generic
> > definition in line with the ethdev TM and MTR APIs. The new generic
> > format contains: queue ID, traffic class, color.
> >
> > In addtion, following API functions of the sched library have
> > been modified with an additional parameter of type struct
> > rte_sched_port to accomodate the changes made to mbuf sched field.
> > (i) rte_sched_port_pkt_write()
> > (ii) rte_sched_port_pkt_read()
> >
> > The other libraries, sample applications and tests which use mbuf
> > sched field have been updated as well.
> >
> > [1] http://mails.dpdk.org/archives/dev/2018-February/090651.html
> > [2] https://mails.dpdk.org/archives/dev/2018-November/119051.html
> >
> > Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
> > Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> > ---
> > @@ -575,12 +575,10 @@ struct rte_mbuf {
> > */
> > } fdir; /**< Filter identifier if FDIR enabled */
> > struct {
> > - uint32_t lo;
> > - uint32_t hi;
> > - /**< The event eth Tx adapter uses this field
> > - * to store Tx queue id.
> > - * @see rte_event_eth_tx_adapter_txq_set()
> > - */
> > + uint32_t queue_id; /**< Queue ID. */
> > + uint8_t traffic_class; /**< Traffic class ID. */
> > + uint8_t color; /**< Color. */
> > + uint16_t reserved; /**< Reserved. */
> > } sched; /**< Hierarchical scheduler */
>
> +Nikhil.
>
> Currently rte_event_eth_tx_adapter_txq_set() and
> rte_event_eth_tx_adapter_txq_get() implemented using
> hash.sched.queue_id. How about moving out from "sched" to "txadapter"?
> Something like below,
>
> $ git diff
> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> index 3dbc6695e..b73bbef93 100644
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -575,13 +575,20 @@ struct rte_mbuf {
> */
> } fdir; /**< Filter identifier if FDIR enabled
> */
> struct {
> - uint32_t lo;
> - uint32_t hi;
> + uint32_t queue_id; /**< Queue ID. */
> + uint8_t traffic_class; /**< Traffic class ID. */
> + uint8_t color; /**< Color. */
> + uint16_t reserved; /**< Reserved. */
> + } sched; /**< Hierarchical scheduler */
> + struct {
> + uint32_t reserved1;
> + uint16_t reserved2;
> + uint16_t txq;
> /**< The event eth Tx adapter uses this field
> * to store Tx queue id.
> * @see rte_event_eth_tx_adapter_txq_set()
> */
> - } sched; /**< Hierarchical scheduler */
> + } txadapter; /**< Eventdev ethdev Tx adapter */
> /**< User defined tags. See rte_distributor_process() */
> uint32_t usr;
> } hash; /**< hash information */
>
>
> > rte_event_eth_tx_adapter_txq_set(struct rte_mbuf *pkt, uint16_t
> queue)
> > {
> > - uint16_t *p = (uint16_t *)&pkt->hash.sched.hi;
> > + uint16_t *p = (uint16_t *)&pkt->hash.sched.queue_id;
> > p[1] = queue;
> > }
> >
> > @@ -320,7 +320,7 @@ rte_event_eth_tx_adapter_txq_set(struct
> rte_mbuf *pkt, uint16_t queue)
> > static __rte_always_inline uint16_t __rte_experimental
> > rte_event_eth_tx_adapter_txq_get(struct rte_mbuf *pkt)
> > {
> > - uint16_t *p = (uint16_t *)&pkt->hash.sched.hi;
> > + uint16_t *p = (uint16_t *)&pkt->hash.sched.queue_id;
> > return p[1];
> > }
> >
Hi Jerin,
Is there a reason why eventdev cannot use the generic 32-bit queue_id field in mbuf->hash.sched?
We can definitely do it the way you suggest, but want to check with you first.
Regards,
Cristian
^ permalink raw reply [flat|nested] 74+ messages in thread
* [dpdk-dev] [PATCH v2 1/3] mbuf: implement generic format for sched field
2018-11-23 16:54 [dpdk-dev] [PATCH] mbuf: implement generic format for sched field Jasvinder Singh
2018-11-26 11:37 ` Dumitrescu, Cristian
2018-12-01 14:22 ` Jerin Jacob
@ 2018-12-07 14:31 ` Reshma Pattan
2018-12-11 19:02 ` Dumitrescu, Cristian
` (3 more replies)
2018-12-07 14:31 ` [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition Reshma Pattan
2018-12-07 14:31 ` [dpdk-dev] [PATCH v2 3/3] doc: add deprecation notice to remove rte meter color Reshma Pattan
4 siblings, 4 replies; 74+ messages in thread
From: Reshma Pattan @ 2018-12-07 14:31 UTC (permalink / raw)
To: dev, cristian.dumitrescu, jerin.jacob, jasvinder.singh; +Cc: Reshma Pattan
This patch implements the changes proposed in the deprecation
notes [1][2].
librte_mbuf changes:
The mbuf::hash::sched field is updated to support generic
definition in line with the ethdev TM and MTR APIs. The new generic
format contains: queue ID, traffic class, color.
Added public APIs to set and get these new fields to and from mbuf.
librte_sched changes:
In addtion, following API functions of the sched library have
been modified with an additional parameter of type struct
rte_sched_port to accommodate the changes made to mbuf sched field.
(i) rte_sched_port_pkt_write()
(ii) rte_sched_port_pkt_read_tree_path()
librte_pipeline, qos_sched UT, qos_sched app are updated
to make use of new changes.
Also mbuf::hash::txadpater have been added for eventdev txq,
rte_event_eth_tx_adapter_txq_set and rte_event_eth_tx_adapter_txq_get()
are updated to use uses mbuf::hash::txadpater.txq.
doc:
Release notes updated.
Removed deprecation notice for mbuf::hash::sched and sched API.
[1] http://mails.dpdk.org/archives/dev/2018-February/090651.html
[2] https://mails.dpdk.org/archives/dev/2018-November/119051.html
Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 10 --
doc/guides/rel_notes/release_19_02.rst | 15 ++-
examples/qos_sched/app_thread.c | 7 +-
examples/qos_sched/main.c | 1 +
.../rte_event_eth_tx_adapter.h | 14 +--
lib/librte_mbuf/Makefile | 2 +-
lib/librte_mbuf/rte_mbuf.h | 112 +++++++++++++++++-
lib/librte_pipeline/rte_table_action.c | 75 +++++++-----
lib/librte_sched/Makefile | 2 +-
lib/librte_sched/rte_sched.c | 97 +++++++--------
lib/librte_sched/rte_sched.h | 10 +-
test/test/test_sched.c | 9 +-
12 files changed, 234 insertions(+), 120 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index b48486d36..60e081a54 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -49,16 +49,6 @@ Deprecation Notices
structure would be made internal (or removed if all dependencies are cleared)
in future releases.
-* mbuf: The opaque ``mbuf->hash.sched`` field will be updated to support generic
- definition in line with the ethdev TM and MTR APIs. Currently, this field
- is defined in librte_sched in a non-generic way. The new generic format
- will contain: queue ID, traffic class, color. Field size will not change.
-
-* sched: Some API functions will change prototype due to the above
- deprecation note for mbuf->hash.sched, e.g. ``rte_sched_port_pkt_write()``
- and ``rte_sched_port_pkt_read()`` will likely have an additional parameter
- of type ``struct rte_sched_port``.
-
* mbuf: the macro ``RTE_MBUF_INDIRECT()`` will be removed in v18.08 or later and
replaced with ``RTE_MBUF_CLONED()`` which is already added in v18.05. As
``EXT_ATTACHED_MBUF`` is newly introduced in v18.05, ``RTE_MBUF_INDIRECT()``
diff --git a/doc/guides/rel_notes/release_19_02.rst b/doc/guides/rel_notes/release_19_02.rst
index a94fa86a7..24ba00d04 100644
--- a/doc/guides/rel_notes/release_19_02.rst
+++ b/doc/guides/rel_notes/release_19_02.rst
@@ -83,6 +83,11 @@ API Changes
Also, make sure to start the actual text at the margin.
=========================================================
+* The below functions of the sched library have been modified with an
+ additional parameter of type ``struct rte_sched_port`` to accommodate
+ the changes made to mbuf::hash::sched field.
+ (i) rte_sched_port_pkt_write()
+ (ii) rte_sched_port_pkt_read_tree_path()
ABI Changes
-----------
@@ -99,6 +104,12 @@ ABI Changes
Also, make sure to start the actual text at the margin.
=========================================================
+* The mbuf::hash::sched field is updated to support generic
+ definition in line with the ethdev TM and MTR APIs. The new generic
+ format contains: ``queue ID, traffic class, color``.
+
+* The mbuf:hash:txadapter is now added for eventdev txq. The txadapter
+ format now contains ``reserved1, reserved2 and txq``.
Shared Library Versions
-----------------------
@@ -146,7 +157,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_kvargs.so.1
librte_latencystats.so.1
librte_lpm.so.2
- librte_mbuf.so.4
+ + librte_mbuf.so.5
librte_member.so.1
librte_mempool.so.5
librte_meter.so.2
@@ -168,7 +179,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_rawdev.so.1
librte_reorder.so.1
librte_ring.so.2
- librte_sched.so.1
+ + librte_sched.so.2
librte_security.so.1
librte_table.so.3
librte_timer.so.1
diff --git a/examples/qos_sched/app_thread.c b/examples/qos_sched/app_thread.c
index a59274236..bec4deee3 100644
--- a/examples/qos_sched/app_thread.c
+++ b/examples/qos_sched/app_thread.c
@@ -73,8 +73,11 @@ app_rx_thread(struct thread_conf **confs)
for(i = 0; i < nb_rx; i++) {
get_pkt_sched(rx_mbufs[i],
&subport, &pipe, &traffic_class, &queue, &color);
- rte_sched_port_pkt_write(rx_mbufs[i], subport, pipe,
- traffic_class, queue, (enum rte_meter_color) color);
+ rte_sched_port_pkt_write(conf->sched_port,
+ rx_mbufs[i],
+ subport, pipe,
+ traffic_class, queue,
+ (enum rte_meter_color) color);
}
if (unlikely(rte_ring_sp_enqueue_bulk(conf->rx_ring,
diff --git a/examples/qos_sched/main.c b/examples/qos_sched/main.c
index e7c97bd64..c0ed16b68 100644
--- a/examples/qos_sched/main.c
+++ b/examples/qos_sched/main.c
@@ -55,6 +55,7 @@ app_main_loop(__attribute__((unused))void *dummy)
flow->rx_thread.rx_port = flow->rx_port;
flow->rx_thread.rx_ring = flow->rx_ring;
flow->rx_thread.rx_queue = flow->rx_queue;
+ flow->rx_thread.sched_port = flow->sched_port;
rx_confs[rx_idx++] = &flow->rx_thread;
diff --git a/lib/librte_eventdev/rte_event_eth_tx_adapter.h b/lib/librte_eventdev/rte_event_eth_tx_adapter.h
index 81456d4a9..b406660ab 100644
--- a/lib/librte_eventdev/rte_event_eth_tx_adapter.h
+++ b/lib/librte_eventdev/rte_event_eth_tx_adapter.h
@@ -63,11 +63,11 @@
* function can be used to retrieve the adapter's service function ID.
*
* The ethernet port and transmit queue index to transmit the mbuf on are
- * specified using the mbuf port and the higher 16 bits of
- * struct rte_mbuf::hash::sched:hi. The application should use the
- * rte_event_eth_tx_adapter_txq_set() and rte_event_eth_tx_adapter_txq_get()
- * functions to access the transmit queue index since it is expected that the
- * transmit queue will be eventually defined within struct rte_mbuf and using
+ * specified using the mbuf port struct rte_mbuf::hash::txadapter:txq.
+ * The application should use the rte_event_eth_tx_adapter_txq_set()
+ * and rte_event_eth_tx_adapter_txq_get() functions to access the transmit
+ * queue index since it is expected that the transmit queue will be
+ * eventually defined within struct rte_mbuf and using
* these macros will help with minimizing application impact due to
* a change in how the transmit queue index is specified.
*/
@@ -300,7 +300,7 @@ rte_event_eth_tx_adapter_queue_del(uint8_t id,
static __rte_always_inline void __rte_experimental
rte_event_eth_tx_adapter_txq_set(struct rte_mbuf *pkt, uint16_t queue)
{
- uint16_t *p = (uint16_t *)&pkt->hash.sched.hi;
+ uint16_t *p = (uint16_t *)&pkt->hash.txadapter.txq;
p[1] = queue;
}
@@ -320,7 +320,7 @@ rte_event_eth_tx_adapter_txq_set(struct rte_mbuf *pkt, uint16_t queue)
static __rte_always_inline uint16_t __rte_experimental
rte_event_eth_tx_adapter_txq_get(struct rte_mbuf *pkt)
{
- uint16_t *p = (uint16_t *)&pkt->hash.sched.hi;
+ uint16_t *p = (uint16_t *)&pkt->hash.txadapter.txq;
return p[1];
}
diff --git a/lib/librte_mbuf/Makefile b/lib/librte_mbuf/Makefile
index e2b98a254..8c4c7d790 100644
--- a/lib/librte_mbuf/Makefile
+++ b/lib/librte_mbuf/Makefile
@@ -11,7 +11,7 @@ LDLIBS += -lrte_eal -lrte_mempool
EXPORT_MAP := rte_mbuf_version.map
-LIBABIVER := 4
+LIBABIVER := 5
# all source are stored in SRCS-y
SRCS-$(CONFIG_RTE_LIBRTE_MBUF) := rte_mbuf.c rte_mbuf_ptype.c rte_mbuf_pool_ops.c
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 3dbc6695e..accd98d9b 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -575,13 +575,23 @@ struct rte_mbuf {
*/
} fdir; /**< Filter identifier if FDIR enabled */
struct {
- uint32_t lo;
- uint32_t hi;
+ uint32_t queue_id; /**< Queue ID. */
+ uint8_t traffic_class;
+ /**< Traffic class ID. Traffic class 0 is high
+ * priority traffic class.
+ */
+ uint8_t color; /**< Color. */
+ uint16_t reserved; /**< Reserved. */
+ } sched; /**< Hierarchical scheduler */
+ struct {
+ uint32_t reserved1;
+ uint16_t reserved2;
+ uint16_t txq;
/**< The event eth Tx adapter uses this field
* to store Tx queue id.
* @see rte_event_eth_tx_adapter_txq_set()
*/
- } sched; /**< Hierarchical scheduler */
+ } txadapter; /**< Eventdev ethdev Tx adapter */
/**< User defined tags. See rte_distributor_process() */
uint32_t usr;
} hash; /**< hash information */
@@ -2289,6 +2299,102 @@ rte_pktmbuf_linearize(struct rte_mbuf *mbuf)
*/
void rte_pktmbuf_dump(FILE *f, const struct rte_mbuf *m, unsigned dump_len);
+/**
+ * Reads the value of an mbuf's sched queue_id field.
+ */
+static inline uint32_t
+rte_mbuf_sched_queue_read(const struct rte_mbuf *m)
+{
+ return m->hash.sched.queue_id;
+}
+
+/**
+ * Reads the value of an mbuf's sched traffic_class field.
+ */
+static inline uint8_t
+rte_mbuf_sched_traffic_class_read(const struct rte_mbuf *m)
+{
+ return m->hash.sched.traffic_class;
+}
+
+/**
+ * Reads the value of an mbuf's sched color field.
+ */
+static inline uint8_t
+rte_mbuf_sched_color_read(const struct rte_mbuf *m)
+{
+ return m->hash.sched.color;
+}
+
+/**
+ * Sets an mbuf's sched queue_id to the defined value.
+ */
+static inline void
+rte_mbuf_sched_queue_set(struct rte_mbuf *m, uint32_t qid)
+{
+ m->hash.sched.queue_id = qid;
+}
+
+/**
+ * Sets an mbuf's sched traffic_class id to the defined value.
+ */
+static inline void
+rte_mbuf_sched_traffic_class_set(struct rte_mbuf *m, uint8_t tc)
+{
+ m->hash.sched.traffic_class = tc;
+}
+
+/**
+ * Sets an mbuf's sched color id to the defined value.
+ */
+static inline void
+rte_mbuf_sched_color_set(struct rte_mbuf *m, uint8_t color)
+{
+ m->hash.sched.color = color;
+}
+
+/**
+ * Reads the values of an mbuf's sched queue_id, traffic_class and color.
+ * @param m
+ * Mbuf to read
+ * @param qid
+ * Returns the queue id
+ * @param tc
+ * Returns the traffic class id
+ * @param color
+ * Returns the colour id
+ */
+static inline void
+rte_mbuf_sched_read(const struct rte_mbuf *m, uint32_t *qid,
+ uint8_t *tc,
+ uint8_t *color)
+{
+ *qid = m->hash.sched.queue_id;
+ *tc = m->hash.sched.traffic_class;
+ *color = m->hash.sched.color;
+}
+
+/**
+ * Sets the mbuf's sched queue_id, traffic_class and color.
+ * @param m
+ * Mbuf to set
+ * @param qid
+ * Queue id value to be set
+ * @param tc
+ * Traffic class id value to be set
+ * @param color
+ * Color id to be set
+ */
+static inline void
+rte_mbuf_sched_set(struct rte_mbuf *m, uint32_t qid,
+ uint8_t tc,
+ uint8_t color)
+{
+ m->hash.sched.queue_id = qid;
+ m->hash.sched.traffic_class = tc;
+ m->hash.sched.color = color;
+}
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_pipeline/rte_table_action.c b/lib/librte_pipeline/rte_table_action.c
index 7c7c8dd82..f9768b9cc 100644
--- a/lib/librte_pipeline/rte_table_action.c
+++ b/lib/librte_pipeline/rte_table_action.c
@@ -107,14 +107,6 @@ mtr_cfg_check(struct rte_table_action_mtr_config *mtr)
return 0;
}
-#define MBUF_SCHED_QUEUE_TC_COLOR(queue, tc, color) \
- ((uint16_t)((((uint64_t)(queue)) & 0x3) | \
- ((((uint64_t)(tc)) & 0x3) << 2) | \
- ((((uint64_t)(color)) & 0x3) << 4)))
-
-#define MBUF_SCHED_COLOR(sched, color) \
- (((sched) & (~0x30LLU)) | ((color) << 4))
-
struct mtr_trtcm_data {
struct rte_meter_trtcm trtcm;
uint64_t stats[e_RTE_METER_COLORS];
@@ -176,7 +168,7 @@ mtr_data_size(struct rte_table_action_mtr_config *mtr)
struct dscp_table_entry_data {
enum rte_meter_color color;
uint16_t tc;
- uint16_t queue_tc_color;
+ uint32_t queue;
};
struct dscp_table_data {
@@ -319,8 +311,7 @@ pkt_work_mtr(struct rte_mbuf *mbuf,
uint32_t dscp,
uint16_t total_length)
{
- uint64_t drop_mask, sched;
- uint64_t *sched_ptr = (uint64_t *) &mbuf->hash.sched;
+ uint64_t drop_mask;
struct dscp_table_entry_data *dscp_entry = &dscp_table->entry[dscp];
enum rte_meter_color color_in, color_meter, color_policer;
uint32_t tc, mp_id;
@@ -329,7 +320,6 @@ pkt_work_mtr(struct rte_mbuf *mbuf,
color_in = dscp_entry->color;
data += tc;
mp_id = MTR_TRTCM_DATA_METER_PROFILE_ID_GET(data);
- sched = *sched_ptr;
/* Meter */
color_meter = rte_meter_trtcm_color_aware_check(
@@ -346,7 +336,7 @@ pkt_work_mtr(struct rte_mbuf *mbuf,
drop_mask = MTR_TRTCM_DATA_POLICER_ACTION_DROP_GET(data, color_meter);
color_policer =
MTR_TRTCM_DATA_POLICER_ACTION_COLOR_GET(data, color_meter);
- *sched_ptr = MBUF_SCHED_COLOR(sched, color_policer);
+ rte_mbuf_sched_color_set(mbuf, color_policer);
return drop_mask;
}
@@ -368,11 +358,16 @@ tm_cfg_check(struct rte_table_action_tm_config *tm)
}
struct tm_data {
- uint16_t queue_tc_color;
uint16_t subport;
uint32_t pipe;
} __attribute__((__packed__));
+/* log2 representation of tm configuration */
+struct tm_cfg {
+ uint32_t subports_per_port_log2;
+ uint32_t pipes_per_subport_log2;
+} __attribute__((__packed__));
+
static int
tm_apply_check(struct rte_table_action_tm_params *p,
struct rte_table_action_tm_config *cfg)
@@ -397,26 +392,37 @@ tm_apply(struct tm_data *data,
return status;
/* Apply */
- data->queue_tc_color = 0;
data->subport = (uint16_t) p->subport_id;
data->pipe = p->pipe_id;
return 0;
}
+static uint32_t
+tm_sched_qindex(struct tm_data *data,
+ struct dscp_table_entry_data *dscp,
+ struct tm_cfg *tm)
+{
+ uint32_t result;
+
+ result = (data->subport << tm->pipes_per_subport_log2) + data->pipe;
+ result = result * RTE_TABLE_ACTION_TC_MAX + dscp->tc;
+ result = result * RTE_TABLE_ACTION_TC_QUEUE_MAX + dscp->queue;
+
+ return result;
+}
+
static __rte_always_inline void
pkt_work_tm(struct rte_mbuf *mbuf,
struct tm_data *data,
struct dscp_table_data *dscp_table,
- uint32_t dscp)
+ uint32_t dscp,
+ struct tm_cfg *tm)
{
struct dscp_table_entry_data *dscp_entry = &dscp_table->entry[dscp];
- struct tm_data *sched_ptr = (struct tm_data *) &mbuf->hash.sched;
- struct tm_data sched;
+ uint32_t queue = tm_sched_qindex(data, dscp_entry, tm);
- sched = *data;
- sched.queue_tc_color = dscp_entry->queue_tc_color;
- *sched_ptr = sched;
+ rte_mbuf_sched_set(mbuf, queue, dscp_entry->tc, dscp_entry->color);
}
/**
@@ -2440,6 +2446,7 @@ struct rte_table_action {
struct ap_data data;
struct dscp_table_data dscp_table;
struct meter_profile_data mp[METER_PROFILES_MAX];
+ struct tm_cfg tm;
};
struct rte_table_action *
@@ -2465,6 +2472,11 @@ rte_table_action_create(struct rte_table_action_profile *profile,
memcpy(&action->cfg, &profile->cfg, sizeof(profile->cfg));
memcpy(&action->data, &profile->data, sizeof(profile->data));
+ action->tm.subports_per_port_log2 =
+ __builtin_ctz(profile->cfg.tm.n_subports_per_port);
+ action->tm.pipes_per_subport_log2 =
+ __builtin_ctz(profile->cfg.tm.n_pipes_per_subport);
+
return action;
}
@@ -2580,17 +2592,13 @@ rte_table_action_dscp_table_update(struct rte_table_action *action,
&action->dscp_table.entry[i];
struct rte_table_action_dscp_table_entry *entry =
&table->entry[i];
- uint16_t queue_tc_color =
- MBUF_SCHED_QUEUE_TC_COLOR(entry->tc_queue_id,
- entry->tc_id,
- entry->color);
if ((dscp_mask & (1LLU << i)) == 0)
continue;
data->color = entry->color;
data->tc = entry->tc_id;
- data->queue_tc_color = queue_tc_color;
+ data->queue = entry->tc_queue_id;
}
return 0;
@@ -2882,7 +2890,8 @@ pkt_work(struct rte_mbuf *mbuf,
pkt_work_tm(mbuf,
data,
&action->dscp_table,
- dscp);
+ dscp,
+ &action->tm);
}
if (cfg->action_mask & (1LLU << RTE_TABLE_ACTION_DECAP)) {
@@ -3108,22 +3117,26 @@ pkt4_work(struct rte_mbuf **mbufs,
pkt_work_tm(mbuf0,
data0,
&action->dscp_table,
- dscp0);
+ dscp0,
+ &action->tm);
pkt_work_tm(mbuf1,
data1,
&action->dscp_table,
- dscp1);
+ dscp1,
+ &action->tm);
pkt_work_tm(mbuf2,
data2,
&action->dscp_table,
- dscp2);
+ dscp2,
+ &action->tm);
pkt_work_tm(mbuf3,
data3,
&action->dscp_table,
- dscp3);
+ dscp3,
+ &action->tm);
}
if (cfg->action_mask & (1LLU << RTE_TABLE_ACTION_DECAP)) {
diff --git a/lib/librte_sched/Makefile b/lib/librte_sched/Makefile
index 46c53ed71..644fd9d15 100644
--- a/lib/librte_sched/Makefile
+++ b/lib/librte_sched/Makefile
@@ -18,7 +18,7 @@ LDLIBS += -lrte_timer
EXPORT_MAP := rte_sched_version.map
-LIBABIVER := 1
+LIBABIVER := 2
#
# all source are stored in SRCS-y
diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c
index 587d5e602..a6d9a5886 100644
--- a/lib/librte_sched/rte_sched.c
+++ b/lib/librte_sched/rte_sched.c
@@ -41,6 +41,9 @@
#define RTE_SCHED_PIPE_INVALID UINT32_MAX
#define RTE_SCHED_BMP_POS_INVALID UINT32_MAX
+#define RTE_SCHED_QUEUES_PER_PIPE_LOG2 \
+ __builtin_ctz(RTE_SCHED_QUEUES_PER_PIPE)
+
/* Scaling for cycles_per_byte calculation
* Chosen so that minimum rate is 480 bit/sec
*/
@@ -128,22 +131,6 @@ enum grinder_state {
e_GRINDER_READ_MBUF
};
-/*
- * Path through the scheduler hierarchy used by the scheduler enqueue
- * operation to identify the destination queue for the current
- * packet. Stored in the field pkt.hash.sched of struct rte_mbuf of
- * each packet, typically written by the classification stage and read
- * by scheduler enqueue.
- */
-struct rte_sched_port_hierarchy {
- uint16_t queue:2; /**< Queue ID (0 .. 3) */
- uint16_t traffic_class:2; /**< Traffic class ID (0 .. 3)*/
- uint32_t color:2; /**< Color */
- uint16_t unused:10;
- uint16_t subport; /**< Subport ID */
- uint32_t pipe; /**< Pipe ID */
-};
-
struct rte_sched_grinder {
/* Pipe cache */
uint16_t pcache_qmask[RTE_SCHED_GRINDER_PCACHE_SIZE];
@@ -228,6 +215,7 @@ struct rte_sched_port {
uint8_t *bmp_array;
struct rte_mbuf **queue_array;
uint8_t memory[0] __rte_cache_aligned;
+
} __rte_cache_aligned;
enum rte_sched_port_array {
@@ -242,13 +230,11 @@ enum rte_sched_port_array {
};
#ifdef RTE_SCHED_COLLECT_STATS
-
static inline uint32_t
rte_sched_port_queues_per_subport(struct rte_sched_port *port)
{
return RTE_SCHED_QUEUES_PER_PIPE * port->n_pipes_per_subport;
}
-
#endif
static inline uint32_t
@@ -1006,44 +992,56 @@ rte_sched_port_pipe_profile_add(struct rte_sched_port *port,
return 0;
}
+static inline uint32_t
+rte_sched_port_qindex(struct rte_sched_port *port,
+ uint32_t subport,
+ uint32_t pipe,
+ uint32_t traffic_class,
+ uint32_t queue)
+{
+ uint32_t result;
+
+ result = (subport << __builtin_ctz(port->n_pipes_per_subport)) + pipe;
+ result = result * RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE + traffic_class;
+ result = result * RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS + queue;
+
+ return result;
+}
+
void
-rte_sched_port_pkt_write(struct rte_mbuf *pkt,
+rte_sched_port_pkt_write(struct rte_sched_port *port,
+ struct rte_mbuf *pkt,
uint32_t subport, uint32_t pipe, uint32_t traffic_class,
uint32_t queue, enum rte_meter_color color)
{
- struct rte_sched_port_hierarchy *sched
- = (struct rte_sched_port_hierarchy *) &pkt->hash.sched;
-
- RTE_BUILD_BUG_ON(sizeof(*sched) > sizeof(pkt->hash.sched));
-
- sched->color = (uint32_t) color;
- sched->subport = subport;
- sched->pipe = pipe;
- sched->traffic_class = traffic_class;
- sched->queue = queue;
+ uint32_t queue_id = rte_sched_port_qindex(port, subport, pipe,
+ traffic_class, queue);
+ rte_mbuf_sched_set(pkt, queue_id, traffic_class, (uint8_t)color);
}
void
-rte_sched_port_pkt_read_tree_path(const struct rte_mbuf *pkt,
+rte_sched_port_pkt_read_tree_path(struct rte_sched_port *port,
+ const struct rte_mbuf *pkt,
uint32_t *subport, uint32_t *pipe,
uint32_t *traffic_class, uint32_t *queue)
{
- const struct rte_sched_port_hierarchy *sched
- = (const struct rte_sched_port_hierarchy *) &pkt->hash.sched;
-
- *subport = sched->subport;
- *pipe = sched->pipe;
- *traffic_class = sched->traffic_class;
- *queue = sched->queue;
+ uint32_t qid = rte_mbuf_sched_queue_read(pkt);
+
+ *subport = qid >>
+ (__builtin_ctz
+ (RTE_SCHED_QUEUES_PER_PIPE <<
+ __builtin_ctz(port->n_pipes_per_subport)
+ )
+ );
+ *pipe = qid >> RTE_SCHED_QUEUES_PER_PIPE_LOG2;
+ *traffic_class = rte_mbuf_sched_traffic_class_read(pkt);
+ *queue = qid & (RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS - 1);
}
enum rte_meter_color
rte_sched_port_pkt_read_color(const struct rte_mbuf *pkt)
{
- const struct rte_sched_port_hierarchy *sched
- = (const struct rte_sched_port_hierarchy *) &pkt->hash.sched;
-
- return (enum rte_meter_color) sched->color;
+ return (enum rte_meter_color)rte_mbuf_sched_color_read(pkt);
}
int
@@ -1100,18 +1098,6 @@ rte_sched_queue_read_stats(struct rte_sched_port *port,
return 0;
}
-static inline uint32_t
-rte_sched_port_qindex(struct rte_sched_port *port, uint32_t subport, uint32_t pipe, uint32_t traffic_class, uint32_t queue)
-{
- uint32_t result;
-
- result = subport * port->n_pipes_per_subport + pipe;
- result = result * RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE + traffic_class;
- result = result * RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS + queue;
-
- return result;
-}
-
#ifdef RTE_SCHED_DEBUG
static inline int
@@ -1272,11 +1258,8 @@ rte_sched_port_enqueue_qptrs_prefetch0(struct rte_sched_port *port,
#ifdef RTE_SCHED_COLLECT_STATS
struct rte_sched_queue_extra *qe;
#endif
- uint32_t subport, pipe, traffic_class, queue, qindex;
-
- rte_sched_port_pkt_read_tree_path(pkt, &subport, &pipe, &traffic_class, &queue);
+ uint32_t qindex = rte_mbuf_sched_queue_read(pkt);
- qindex = rte_sched_port_qindex(port, subport, pipe, traffic_class, queue);
q = port->queue + qindex;
rte_prefetch0(q);
#ifdef RTE_SCHED_COLLECT_STATS
diff --git a/lib/librte_sched/rte_sched.h b/lib/librte_sched/rte_sched.h
index 84fa896de..243efa1d4 100644
--- a/lib/librte_sched/rte_sched.h
+++ b/lib/librte_sched/rte_sched.h
@@ -355,6 +355,8 @@ rte_sched_queue_read_stats(struct rte_sched_port *port,
* Scheduler hierarchy path write to packet descriptor. Typically
* called by the packet classification stage.
*
+ * @param port
+ * Handle to port scheduler instance
* @param pkt
* Packet descriptor handle
* @param subport
@@ -369,7 +371,8 @@ rte_sched_queue_read_stats(struct rte_sched_port *port,
* Packet color set
*/
void
-rte_sched_port_pkt_write(struct rte_mbuf *pkt,
+rte_sched_port_pkt_write(struct rte_sched_port *port,
+ struct rte_mbuf *pkt,
uint32_t subport, uint32_t pipe, uint32_t traffic_class,
uint32_t queue, enum rte_meter_color color);
@@ -379,6 +382,8 @@ rte_sched_port_pkt_write(struct rte_mbuf *pkt,
* enqueue operation. The subport, pipe, traffic class and queue
* parameters need to be pre-allocated by the caller.
*
+ * @param port
+ * Handle to port scheduler instance
* @param pkt
* Packet descriptor handle
* @param subport
@@ -392,7 +397,8 @@ rte_sched_port_pkt_write(struct rte_mbuf *pkt,
*
*/
void
-rte_sched_port_pkt_read_tree_path(const struct rte_mbuf *pkt,
+rte_sched_port_pkt_read_tree_path(struct rte_sched_port *port,
+ const struct rte_mbuf *pkt,
uint32_t *subport, uint32_t *pipe,
uint32_t *traffic_class, uint32_t *queue);
diff --git a/test/test/test_sched.c b/test/test/test_sched.c
index 32e500ba9..40e411cab 100644
--- a/test/test/test_sched.c
+++ b/test/test/test_sched.c
@@ -76,7 +76,7 @@ create_mempool(void)
}
static void
-prepare_pkt(struct rte_mbuf *mbuf)
+prepare_pkt(struct rte_sched_port *port, struct rte_mbuf *mbuf)
{
struct ether_hdr *eth_hdr;
struct vlan_hdr *vlan1, *vlan2;
@@ -95,7 +95,8 @@ prepare_pkt(struct rte_mbuf *mbuf)
ip_hdr->dst_addr = IPv4(0,0,TC,QUEUE);
- rte_sched_port_pkt_write(mbuf, SUBPORT, PIPE, TC, QUEUE, e_RTE_METER_YELLOW);
+ rte_sched_port_pkt_write(port, mbuf, SUBPORT, PIPE, TC, QUEUE,
+ e_RTE_METER_YELLOW);
/* 64 byte packet */
mbuf->pkt_len = 60;
@@ -138,7 +139,7 @@ test_sched(void)
for (i = 0; i < 10; i++) {
in_mbufs[i] = rte_pktmbuf_alloc(mp);
TEST_ASSERT_NOT_NULL(in_mbufs[i], "Packet allocation failed\n");
- prepare_pkt(in_mbufs[i]);
+ prepare_pkt(port, in_mbufs[i]);
}
@@ -155,7 +156,7 @@ test_sched(void)
color = rte_sched_port_pkt_read_color(out_mbufs[i]);
TEST_ASSERT_EQUAL(color, e_RTE_METER_YELLOW, "Wrong color\n");
- rte_sched_port_pkt_read_tree_path(out_mbufs[i],
+ rte_sched_port_pkt_read_tree_path(port, out_mbufs[i],
&subport, &pipe, &traffic_class, &queue);
TEST_ASSERT_EQUAL(subport, SUBPORT, "Wrong subport\n");
--
2.17.1
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v2 1/3] mbuf: implement generic format for sched field
2018-12-07 14:31 ` [dpdk-dev] [PATCH v2 1/3] " Reshma Pattan
@ 2018-12-11 19:02 ` Dumitrescu, Cristian
2018-12-12 18:17 ` Dumitrescu, Cristian
` (2 subsequent siblings)
3 siblings, 0 replies; 74+ messages in thread
From: Dumitrescu, Cristian @ 2018-12-11 19:02 UTC (permalink / raw)
To: Pattan, Reshma, dev, jerin.jacob, Singh, Jasvinder
> -----Original Message-----
> From: Pattan, Reshma
> Sent: Friday, December 7, 2018 2:32 PM
> To: dev@dpdk.org; Dumitrescu, Cristian <cristian.dumitrescu@intel.com>;
> jerin.jacob@caviumnetworks.com; Singh, Jasvinder
> <jasvinder.singh@intel.com>
> Cc: Pattan, Reshma <reshma.pattan@intel.com>
> Subject: [PATCH v2 1/3] mbuf: implement generic format for sched field
>
> This patch implements the changes proposed in the deprecation
> notes [1][2].
>
> librte_mbuf changes:
> The mbuf::hash::sched field is updated to support generic
> definition in line with the ethdev TM and MTR APIs. The new generic
> format contains: queue ID, traffic class, color.
>
> Added public APIs to set and get these new fields to and from mbuf.
>
> librte_sched changes:
> In addtion, following API functions of the sched library have
> been modified with an additional parameter of type struct
> rte_sched_port to accommodate the changes made to mbuf sched field.
> (i) rte_sched_port_pkt_write()
> (ii) rte_sched_port_pkt_read_tree_path()
>
> librte_pipeline, qos_sched UT, qos_sched app are updated
> to make use of new changes.
>
> Also mbuf::hash::txadpater have been added for eventdev txq,
> rte_event_eth_tx_adapter_txq_set and
> rte_event_eth_tx_adapter_txq_get()
> are updated to use uses mbuf::hash::txadpater.txq.
>
> doc:
> Release notes updated.
> Removed deprecation notice for mbuf::hash::sched and sched API.
>
> [1] http://mails.dpdk.org/archives/dev/2018-February/090651.html
> [2] https://mails.dpdk.org/archives/dev/2018-November/119051.html
>
> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
> Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> ---
> doc/guides/rel_notes/deprecation.rst | 10 --
> doc/guides/rel_notes/release_19_02.rst | 15 ++-
> examples/qos_sched/app_thread.c | 7 +-
> examples/qos_sched/main.c | 1 +
> .../rte_event_eth_tx_adapter.h | 14 +--
> lib/librte_mbuf/Makefile | 2 +-
> lib/librte_mbuf/rte_mbuf.h | 112 +++++++++++++++++-
> lib/librte_pipeline/rte_table_action.c | 75 +++++++-----
> lib/librte_sched/Makefile | 2 +-
> lib/librte_sched/rte_sched.c | 97 +++++++--------
> lib/librte_sched/rte_sched.h | 10 +-
> test/test/test_sched.c | 9 +-
> 12 files changed, 234 insertions(+), 120 deletions(-)
>
<snip>
> diff --git a/doc/guides/rel_notes/release_19_02.rst
> b/doc/guides/rel_notes/release_19_02.rst
> index a94fa86a7..24ba00d04 100644
> --- a/doc/guides/rel_notes/release_19_02.rst
> +++ b/doc/guides/rel_notes/release_19_02.rst
> @@ -83,6 +83,11 @@ API Changes
> Also, make sure to start the actual text at the margin.
> =========================================================
>
> +* The below functions of the sched library have been modified with an
> + additional parameter of type ``struct rte_sched_port`` to accommodate
> + the changes made to mbuf::hash::sched field.
> + (i) rte_sched_port_pkt_write()
> + (ii) rte_sched_port_pkt_read_tree_path()
>
> ABI Changes
> -----------
> @@ -99,6 +104,12 @@ ABI Changes
> Also, make sure to start the actual text at the margin.
> =========================================================
>
> +* The mbuf::hash::sched field is updated to support generic
> + definition in line with the ethdev TM and MTR APIs. The new generic
> + format contains: ``queue ID, traffic class, color``.
> +
> +* The mbuf:hash:txadapter is now added for eventdev txq. The txadapter
> + format now contains ``reserved1, reserved2 and txq``.
>
IMO these changes are too small to make it to the release notes, I suggest we remove them from here.
<snip>
> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> index 3dbc6695e..accd98d9b 100644
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -575,13 +575,23 @@ struct rte_mbuf {
> */
> } fdir; /**< Filter identifier if FDIR enabled */
> struct {
> - uint32_t lo;
> - uint32_t hi;
> + uint32_t queue_id; /**< Queue ID. */
> + uint8_t traffic_class;
> + /**< Traffic class ID. Traffic class 0 is high
> + * priority traffic class.
> + */
This comment is too fuzzy, my initial suggestion was: Traffic class 0 is the highest priority traffic class.
> + uint8_t color; /**< Color. */
Already suggested the following:
1. Include the new file "rte_color.h" in this file
2. Clearly connect this field to its real type, i.e. enum rte_color through the proper Doxygen syntax: /**< Color. @see enum rte_color. */
> + uint16_t reserved; /**< Reserved. */
> + } sched; /**< Hierarchical scheduler */
> + struct {
> + uint32_t reserved1;
> + uint16_t reserved2;
> + uint16_t txq;
> /**< The event eth Tx adapter uses this field
> * to store Tx queue id.
> * @see
> rte_event_eth_tx_adapter_txq_set()
> */
> - } sched; /**< Hierarchical scheduler */
> + } txadapter; /**< Eventdev ethdev Tx adapter */
> /**< User defined tags. See
> rte_distributor_process() */
> uint32_t usr;
> } hash; /**< hash information */
> @@ -2289,6 +2299,102 @@ rte_pktmbuf_linearize(struct rte_mbuf *mbuf)
> */
> void rte_pktmbuf_dump(FILE *f, const struct rte_mbuf *m, unsigned
> dump_len);
>
> +/**
> + * Reads the value of an mbuf's sched queue_id field.
> + */
> +static inline uint32_t
> +rte_mbuf_sched_queue_read(const struct rte_mbuf *m)
> +{
> + return m->hash.sched.queue_id;
> +}
Let's name these functions *_get instead of *_read, which pairs up with the *_set functions below.
Applicable to all get/set functions: The comment should contain an imperative verb, i.e. "Get the value ...." instead of "Gets the value ...".
> +
> +/**
> + * Reads the value of an mbuf's sched traffic_class field.
> + */
> +static inline uint8_t
> +rte_mbuf_sched_traffic_class_read(const struct rte_mbuf *m)
> +{
> + return m->hash.sched.traffic_class;
> +}
> +
> +/**
> + * Reads the value of an mbuf's sched color field.
> + */
> +static inline uint8_t
> +rte_mbuf_sched_color_read(const struct rte_mbuf *m)
> +{
> + return m->hash.sched.color;
> +}
The type of the return value should be enum rte_color instead of uint8_t:
static inline enum rte_color
rte_mbuf_sched_color_read(const struct rte_mbuf *m)
{
return (enum rte_color)m->hash.sched.color;
}
> +
> +/**
> + * Sets an mbuf's sched queue_id to the defined value.
> + */
> +static inline void
> +rte_mbuf_sched_queue_set(struct rte_mbuf *m, uint32_t qid)
> +{
> + m->hash.sched.queue_id = qid;
> +}
Let's use the full name queue_id instead of qid, please.
> +
> +/**
> + * Sets an mbuf's sched traffic_class id to the defined value.
> + */
> +static inline void
> +rte_mbuf_sched_traffic_class_set(struct rte_mbuf *m, uint8_t tc)
> +{
> + m->hash.sched.traffic_class = tc;
> +}
> +
Same here.
> +/**
> + * Sets an mbuf's sched color id to the defined value.
> + */
> +static inline void
> +rte_mbuf_sched_color_set(struct rte_mbuf *m, uint8_t color)
> +{
> + m->hash.sched.color = color;
> +}
The color parameter type should be enum rte_color, not uint8_t:
static inline void
rte_mbuf_sched_color_set(struct rte_mbuf *m, enum rte_color color)
{
m->hash.sched.color = (uint8_t)color;
}
> +
> +/**
> + * Reads the values of an mbuf's sched queue_id, traffic_class and color.
> + * @param m
> + * Mbuf to read
> + * @param qid
> + * Returns the queue id
> + * @param tc
> + * Returns the traffic class id
> + * @param color
> + * Returns the colour id
> + */
> +static inline void
> +rte_mbuf_sched_read(const struct rte_mbuf *m, uint32_t *qid,
> + uint8_t *tc,
> + uint8_t *color)
> +{
> + *qid = m->hash.sched.queue_id;
> + *tc = m->hash.sched.traffic_class;
> + *color = m->hash.sched.color;
> +}
Color type should be enum rte_color instead of uint8_t.
Full names, not abbreviated names, please.
Please move this function above with the other *_get functions (i.e. before any *_set function).
> +
> +/**
> + * Sets the mbuf's sched queue_id, traffic_class and color.
> + * @param m
> + * Mbuf to set
> + * @param qid
> + * Queue id value to be set
> + * @param tc
> + * Traffic class id value to be set
> + * @param color
> + * Color id to be set
> + */
> +static inline void
> +rte_mbuf_sched_set(struct rte_mbuf *m, uint32_t qid,
> + uint8_t tc,
> + uint8_t color)
> +{
> + m->hash.sched.queue_id = qid;
> + m->hash.sched.traffic_class = tc;
> + m->hash.sched.color = color;
> +}
Color type should be enum rte_color instead of uint8_t.
Full names, not abbreviated names, please.
> +
> #ifdef __cplusplus
> }
> #endif
> diff --git a/lib/librte_pipeline/rte_table_action.c
> b/lib/librte_pipeline/rte_table_action.c
> index 7c7c8dd82..f9768b9cc 100644
> --- a/lib/librte_pipeline/rte_table_action.c
> +++ b/lib/librte_pipeline/rte_table_action.c
> @@ -107,14 +107,6 @@ mtr_cfg_check(struct rte_table_action_mtr_config
> *mtr)
> return 0;
> }
>
> -#define MBUF_SCHED_QUEUE_TC_COLOR(queue, tc, color) \
> - ((uint16_t)((((uint64_t)(queue)) & 0x3) | \
> - ((((uint64_t)(tc)) & 0x3) << 2) | \
> - ((((uint64_t)(color)) & 0x3) << 4)))
> -
> -#define MBUF_SCHED_COLOR(sched, color) \
> - (((sched) & (~0x30LLU)) | ((color) << 4))
> -
> struct mtr_trtcm_data {
> struct rte_meter_trtcm trtcm;
> uint64_t stats[e_RTE_METER_COLORS];
> @@ -176,7 +168,7 @@ mtr_data_size(struct rte_table_action_mtr_config
> *mtr)
> struct dscp_table_entry_data {
> enum rte_meter_color color;
> uint16_t tc;
> - uint16_t queue_tc_color;
> + uint32_t queue;
> };
In this data structure, let's rename queue as tc_queue, as it better illustrates what it is, i.e. queue within the traffic class.
In order to preserve the size of this data structure (8 bytes), let's use uint16_t to store tc_queue field.
>
> struct dscp_table_data {
> @@ -319,8 +311,7 @@ pkt_work_mtr(struct rte_mbuf *mbuf,
> uint32_t dscp,
> uint16_t total_length)
> {
> - uint64_t drop_mask, sched;
> - uint64_t *sched_ptr = (uint64_t *) &mbuf->hash.sched;
> + uint64_t drop_mask;
> struct dscp_table_entry_data *dscp_entry = &dscp_table-
> >entry[dscp];
> enum rte_meter_color color_in, color_meter, color_policer;
> uint32_t tc, mp_id;
> @@ -329,7 +320,6 @@ pkt_work_mtr(struct rte_mbuf *mbuf,
> color_in = dscp_entry->color;
> data += tc;
> mp_id = MTR_TRTCM_DATA_METER_PROFILE_ID_GET(data);
> - sched = *sched_ptr;
>
> /* Meter */
> color_meter = rte_meter_trtcm_color_aware_check(
> @@ -346,7 +336,7 @@ pkt_work_mtr(struct rte_mbuf *mbuf,
> drop_mask =
> MTR_TRTCM_DATA_POLICER_ACTION_DROP_GET(data, color_meter);
> color_policer =
> MTR_TRTCM_DATA_POLICER_ACTION_COLOR_GET(data,
> color_meter);
> - *sched_ptr = MBUF_SCHED_COLOR(sched, color_policer);
> + rte_mbuf_sched_color_set(mbuf, color_policer);
>
> return drop_mask;
> }
> @@ -368,11 +358,16 @@ tm_cfg_check(struct rte_table_action_tm_config
> *tm)
> }
>
> struct tm_data {
> - uint16_t queue_tc_color;
> uint16_t subport;
> uint32_t pipe;
> } __attribute__((__packed__));
>
In order to preserve the current size for this data structure (8 bytes), let's have subport type as uint32_t.
> +/* log2 representation of tm configuration */
I suggest to remove this comment.
> +struct tm_cfg {
> + uint32_t subports_per_port_log2;
> + uint32_t pipes_per_subport_log2;
> +} __attribute__((__packed__));
> +
For readability purpose, it is probably better to preserve the names, so please use n_subports_per_port_log2 and n_pipes_per_subport_log2.
> static int
> tm_apply_check(struct rte_table_action_tm_params *p,
> struct rte_table_action_tm_config *cfg)
> @@ -397,26 +392,37 @@ tm_apply(struct tm_data *data,
> return status;
>
> /* Apply */
> - data->queue_tc_color = 0;
> data->subport = (uint16_t) p->subport_id;
> data->pipe = p->pipe_id;
>
> return 0;
> }
>
> +static uint32_t
> +tm_sched_qindex(struct tm_data *data,
> + struct dscp_table_entry_data *dscp,
> + struct tm_cfg *tm)
> +{
> + uint32_t result;
> +
> + result = (data->subport << tm->pipes_per_subport_log2) + data-
> >pipe;
> + result = result * RTE_TABLE_ACTION_TC_MAX + dscp->tc;
> + result = result * RTE_TABLE_ACTION_TC_QUEUE_MAX + dscp-
> >queue;
> +
> + return result;
> +}
> +
We can do this in a single assignment (replace the multiplication with 4 by shift left with 2).
> static __rte_always_inline void
> pkt_work_tm(struct rte_mbuf *mbuf,
> struct tm_data *data,
> struct dscp_table_data *dscp_table,
> - uint32_t dscp)
> + uint32_t dscp,
> + struct tm_cfg *tm)
> {
> struct dscp_table_entry_data *dscp_entry = &dscp_table-
> >entry[dscp];
> - struct tm_data *sched_ptr = (struct tm_data *) &mbuf->hash.sched;
> - struct tm_data sched;
> + uint32_t queue = tm_sched_qindex(data, dscp_entry, tm);
>
> - sched = *data;
> - sched.queue_tc_color = dscp_entry->queue_tc_color;
> - *sched_ptr = sched;
> + rte_mbuf_sched_set(mbuf, queue, dscp_entry->tc, dscp_entry-
> >color);
> }
>
> /**
> @@ -2440,6 +2446,7 @@ struct rte_table_action {
> struct ap_data data;
> struct dscp_table_data dscp_table;
> struct meter_profile_data mp[METER_PROFILES_MAX];
> + struct tm_cfg tm;
> };
>
> struct rte_table_action *
> @@ -2465,6 +2472,11 @@ rte_table_action_create(struct
> rte_table_action_profile *profile,
> memcpy(&action->cfg, &profile->cfg, sizeof(profile->cfg));
> memcpy(&action->data, &profile->data, sizeof(profile->data));
>
> + action->tm.subports_per_port_log2 =
> + __builtin_ctz(profile->cfg.tm.n_subports_per_port);
> + action->tm.pipes_per_subport_log2 =
> + __builtin_ctz(profile->cfg.tm.n_pipes_per_subport);
> +
> return action;
> }
>
> @@ -2580,17 +2592,13 @@ rte_table_action_dscp_table_update(struct
> rte_table_action *action,
> &action->dscp_table.entry[i];
> struct rte_table_action_dscp_table_entry *entry =
> &table->entry[i];
> - uint16_t queue_tc_color =
> - MBUF_SCHED_QUEUE_TC_COLOR(entry-
> >tc_queue_id,
> - entry->tc_id,
> - entry->color);
>
> if ((dscp_mask & (1LLU << i)) == 0)
> continue;
>
> data->color = entry->color;
> data->tc = entry->tc_id;
> - data->queue_tc_color = queue_tc_color;
> + data->queue = entry->tc_queue_id;
> }
>
> return 0;
> @@ -2882,7 +2890,8 @@ pkt_work(struct rte_mbuf *mbuf,
> pkt_work_tm(mbuf,
> data,
> &action->dscp_table,
> - dscp);
> + dscp,
> + &action->tm);
> }
>
> if (cfg->action_mask & (1LLU << RTE_TABLE_ACTION_DECAP)) {
> @@ -3108,22 +3117,26 @@ pkt4_work(struct rte_mbuf **mbufs,
> pkt_work_tm(mbuf0,
> data0,
> &action->dscp_table,
> - dscp0);
> + dscp0,
> + &action->tm);
>
> pkt_work_tm(mbuf1,
> data1,
> &action->dscp_table,
> - dscp1);
> + dscp1,
> + &action->tm);
>
> pkt_work_tm(mbuf2,
> data2,
> &action->dscp_table,
> - dscp2);
> + dscp2,
> + &action->tm);
>
> pkt_work_tm(mbuf3,
> data3,
> &action->dscp_table,
> - dscp3);
> + dscp3,
> + &action->tm);
> }
>
> if (cfg->action_mask & (1LLU << RTE_TABLE_ACTION_DECAP)) {
> diff --git a/lib/librte_sched/Makefile b/lib/librte_sched/Makefile
> index 46c53ed71..644fd9d15 100644
> --- a/lib/librte_sched/Makefile
> +++ b/lib/librte_sched/Makefile
> @@ -18,7 +18,7 @@ LDLIBS += -lrte_timer
>
> EXPORT_MAP := rte_sched_version.map
>
> -LIBABIVER := 1
> +LIBABIVER := 2
>
> #
> # all source are stored in SRCS-y
> diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c
> index 587d5e602..a6d9a5886 100644
> --- a/lib/librte_sched/rte_sched.c
> +++ b/lib/librte_sched/rte_sched.c
> @@ -41,6 +41,9 @@
> #define RTE_SCHED_PIPE_INVALID UINT32_MAX
> #define RTE_SCHED_BMP_POS_INVALID UINT32_MAX
>
> +#define RTE_SCHED_QUEUES_PER_PIPE_LOG2 \
> + __builtin_ctz(RTE_SCHED_QUEUES_PER_PIPE)
> +
> /* Scaling for cycles_per_byte calculation
> * Chosen so that minimum rate is 480 bit/sec
> */
> @@ -128,22 +131,6 @@ enum grinder_state {
> e_GRINDER_READ_MBUF
> };
>
> -/*
> - * Path through the scheduler hierarchy used by the scheduler enqueue
> - * operation to identify the destination queue for the current
> - * packet. Stored in the field pkt.hash.sched of struct rte_mbuf of
> - * each packet, typically written by the classification stage and read
> - * by scheduler enqueue.
> - */
> -struct rte_sched_port_hierarchy {
> - uint16_t queue:2; /**< Queue ID (0 .. 3) */
> - uint16_t traffic_class:2; /**< Traffic class ID (0 .. 3)*/
> - uint32_t color:2; /**< Color */
> - uint16_t unused:10;
> - uint16_t subport; /**< Subport ID */
> - uint32_t pipe; /**< Pipe ID */
> -};
> -
> struct rte_sched_grinder {
> /* Pipe cache */
> uint16_t pcache_qmask[RTE_SCHED_GRINDER_PCACHE_SIZE];
> @@ -228,6 +215,7 @@ struct rte_sched_port {
> uint8_t *bmp_array;
> struct rte_mbuf **queue_array;
> uint8_t memory[0] __rte_cache_aligned;
> +
> } __rte_cache_aligned;
>
> enum rte_sched_port_array {
> @@ -242,13 +230,11 @@ enum rte_sched_port_array {
> };
>
> #ifdef RTE_SCHED_COLLECT_STATS
> -
> static inline uint32_t
> rte_sched_port_queues_per_subport(struct rte_sched_port *port)
> {
> return RTE_SCHED_QUEUES_PER_PIPE * port-
> >n_pipes_per_subport;
> }
> -
> #endif
>
> static inline uint32_t
> @@ -1006,44 +992,56 @@ rte_sched_port_pipe_profile_add(struct
> rte_sched_port *port,
> return 0;
> }
>
> +static inline uint32_t
> +rte_sched_port_qindex(struct rte_sched_port *port,
> + uint32_t subport,
> + uint32_t pipe,
> + uint32_t traffic_class,
> + uint32_t queue)
> +{
> + uint32_t result;
> +
> + result = (subport << __builtin_ctz(port->n_pipes_per_subport)) +
> pipe;
> + result = result * RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE +
> traffic_class;
> + result = result * RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS + queue;
> +
> + return result;
> +}
> +
> void
> -rte_sched_port_pkt_write(struct rte_mbuf *pkt,
> +rte_sched_port_pkt_write(struct rte_sched_port *port,
> + struct rte_mbuf *pkt,
> uint32_t subport, uint32_t pipe, uint32_t
> traffic_class,
> uint32_t queue, enum rte_meter_color color)
> {
> - struct rte_sched_port_hierarchy *sched
> - = (struct rte_sched_port_hierarchy *) &pkt->hash.sched;
> -
> - RTE_BUILD_BUG_ON(sizeof(*sched) > sizeof(pkt->hash.sched));
> -
> - sched->color = (uint32_t) color;
> - sched->subport = subport;
> - sched->pipe = pipe;
> - sched->traffic_class = traffic_class;
> - sched->queue = queue;
> + uint32_t queue_id = rte_sched_port_qindex(port, subport, pipe,
> + traffic_class, queue);
> + rte_mbuf_sched_set(pkt, queue_id, traffic_class, (uint8_t)color);
> }
>
> void
> -rte_sched_port_pkt_read_tree_path(const struct rte_mbuf *pkt,
> +rte_sched_port_pkt_read_tree_path(struct rte_sched_port *port,
> + const struct rte_mbuf *pkt,
> uint32_t *subport, uint32_t *pipe,
> uint32_t *traffic_class, uint32_t *queue)
> {
> - const struct rte_sched_port_hierarchy *sched
> - = (const struct rte_sched_port_hierarchy *) &pkt-
> >hash.sched;
> -
> - *subport = sched->subport;
> - *pipe = sched->pipe;
> - *traffic_class = sched->traffic_class;
> - *queue = sched->queue;
> + uint32_t qid = rte_mbuf_sched_queue_read(pkt);
> +
> + *subport = qid >>
> + (__builtin_ctz
> + (RTE_SCHED_QUEUES_PER_PIPE <<
> + __builtin_ctz(port->n_pipes_per_subport)
> + )
> + );
> + *pipe = qid >> RTE_SCHED_QUEUES_PER_PIPE_LOG2;
> + *traffic_class = rte_mbuf_sched_traffic_class_read(pkt);
> + *queue = qid & (RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS - 1);
> }
>
> enum rte_meter_color
> rte_sched_port_pkt_read_color(const struct rte_mbuf *pkt)
> {
> - const struct rte_sched_port_hierarchy *sched
> - = (const struct rte_sched_port_hierarchy *) &pkt-
> >hash.sched;
> -
> - return (enum rte_meter_color) sched->color;
> + return (enum rte_meter_color)rte_mbuf_sched_color_read(pkt);
> }
>
> int
> @@ -1100,18 +1098,6 @@ rte_sched_queue_read_stats(struct
> rte_sched_port *port,
> return 0;
> }
>
> -static inline uint32_t
> -rte_sched_port_qindex(struct rte_sched_port *port, uint32_t subport,
> uint32_t pipe, uint32_t traffic_class, uint32_t queue)
> -{
> - uint32_t result;
> -
> - result = subport * port->n_pipes_per_subport + pipe;
> - result = result * RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE +
> traffic_class;
> - result = result * RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS + queue;
> -
> - return result;
> -}
> -
> #ifdef RTE_SCHED_DEBUG
>
> static inline int
> @@ -1272,11 +1258,8 @@ rte_sched_port_enqueue_qptrs_prefetch0(struct
> rte_sched_port *port,
> #ifdef RTE_SCHED_COLLECT_STATS
> struct rte_sched_queue_extra *qe;
> #endif
> - uint32_t subport, pipe, traffic_class, queue, qindex;
> -
> - rte_sched_port_pkt_read_tree_path(pkt, &subport, &pipe,
> &traffic_class, &queue);
> + uint32_t qindex = rte_mbuf_sched_queue_read(pkt);
>
> - qindex = rte_sched_port_qindex(port, subport, pipe, traffic_class,
> queue);
> q = port->queue + qindex;
> rte_prefetch0(q);
> #ifdef RTE_SCHED_COLLECT_STATS
> diff --git a/lib/librte_sched/rte_sched.h b/lib/librte_sched/rte_sched.h
> index 84fa896de..243efa1d4 100644
> --- a/lib/librte_sched/rte_sched.h
> +++ b/lib/librte_sched/rte_sched.h
> @@ -355,6 +355,8 @@ rte_sched_queue_read_stats(struct rte_sched_port
> *port,
> * Scheduler hierarchy path write to packet descriptor. Typically
> * called by the packet classification stage.
> *
> + * @param port
> + * Handle to port scheduler instance
> * @param pkt
> * Packet descriptor handle
> * @param subport
> @@ -369,7 +371,8 @@ rte_sched_queue_read_stats(struct rte_sched_port
> *port,
> * Packet color set
> */
> void
> -rte_sched_port_pkt_write(struct rte_mbuf *pkt,
> +rte_sched_port_pkt_write(struct rte_sched_port *port,
> + struct rte_mbuf *pkt,
> uint32_t subport, uint32_t pipe, uint32_t
> traffic_class,
> uint32_t queue, enum rte_meter_color color);
>
> @@ -379,6 +382,8 @@ rte_sched_port_pkt_write(struct rte_mbuf *pkt,
> * enqueue operation. The subport, pipe, traffic class and queue
> * parameters need to be pre-allocated by the caller.
> *
> + * @param port
> + * Handle to port scheduler instance
> * @param pkt
> * Packet descriptor handle
> * @param subport
> @@ -392,7 +397,8 @@ rte_sched_port_pkt_write(struct rte_mbuf *pkt,
> *
> */
> void
> -rte_sched_port_pkt_read_tree_path(const struct rte_mbuf *pkt,
> +rte_sched_port_pkt_read_tree_path(struct rte_sched_port *port,
> + const struct rte_mbuf *pkt,
> uint32_t *subport, uint32_t *pipe,
> uint32_t *traffic_class, uint32_t *queue);
>
> diff --git a/test/test/test_sched.c b/test/test/test_sched.c
> index 32e500ba9..40e411cab 100644
> --- a/test/test/test_sched.c
> +++ b/test/test/test_sched.c
> @@ -76,7 +76,7 @@ create_mempool(void)
> }
>
> static void
> -prepare_pkt(struct rte_mbuf *mbuf)
> +prepare_pkt(struct rte_sched_port *port, struct rte_mbuf *mbuf)
> {
> struct ether_hdr *eth_hdr;
> struct vlan_hdr *vlan1, *vlan2;
> @@ -95,7 +95,8 @@ prepare_pkt(struct rte_mbuf *mbuf)
> ip_hdr->dst_addr = IPv4(0,0,TC,QUEUE);
>
>
> - rte_sched_port_pkt_write(mbuf, SUBPORT, PIPE, TC, QUEUE,
> e_RTE_METER_YELLOW);
> + rte_sched_port_pkt_write(port, mbuf, SUBPORT, PIPE, TC, QUEUE,
> + e_RTE_METER_YELLOW);
>
> /* 64 byte packet */
> mbuf->pkt_len = 60;
> @@ -138,7 +139,7 @@ test_sched(void)
> for (i = 0; i < 10; i++) {
> in_mbufs[i] = rte_pktmbuf_alloc(mp);
> TEST_ASSERT_NOT_NULL(in_mbufs[i], "Packet allocation
> failed\n");
> - prepare_pkt(in_mbufs[i]);
> + prepare_pkt(port, in_mbufs[i]);
> }
>
>
> @@ -155,7 +156,7 @@ test_sched(void)
> color = rte_sched_port_pkt_read_color(out_mbufs[i]);
> TEST_ASSERT_EQUAL(color, e_RTE_METER_YELLOW, "Wrong
> color\n");
>
> - rte_sched_port_pkt_read_tree_path(out_mbufs[i],
> + rte_sched_port_pkt_read_tree_path(port, out_mbufs[i],
> &subport, &pipe, &traffic_class, &queue);
>
> TEST_ASSERT_EQUAL(subport, SUBPORT, "Wrong
> subport\n");
> --
> 2.17.1
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v2 1/3] mbuf: implement generic format for sched field
2018-12-07 14:31 ` [dpdk-dev] [PATCH v2 1/3] " Reshma Pattan
2018-12-11 19:02 ` Dumitrescu, Cristian
@ 2018-12-12 18:17 ` Dumitrescu, Cristian
2018-12-13 8:51 ` Rao, Nikhil
2018-12-13 18:08 ` [dpdk-dev] [PATCH v3 1/2] eal: add new rte color definition Reshma Pattan
3 siblings, 0 replies; 74+ messages in thread
From: Dumitrescu, Cristian @ 2018-12-12 18:17 UTC (permalink / raw)
To: Pattan, Reshma, dev, jerin.jacob, Singh, Jasvinder
Hi Reshma,
More comments on this patch.
<snip>
> diff --git a/lib/librte_pipeline/rte_table_action.c
> b/lib/librte_pipeline/rte_table_action.c
> index 7c7c8dd82..f9768b9cc 100644
> --- a/lib/librte_pipeline/rte_table_action.c
> +++ b/lib/librte_pipeline/rte_table_action.c
> @@ -107,14 +107,6 @@ mtr_cfg_check(struct rte_table_action_mtr_config
> *mtr)
> return 0;
> }
>
<snip>
> @@ -368,11 +358,16 @@ tm_cfg_check(struct rte_table_action_tm_config
> *tm)
> }
>
> struct tm_data {
> - uint16_t queue_tc_color;
> uint16_t subport;
> uint32_t pipe;
> } __attribute__((__packed__));
>
Currently, the tm_data has the same memory layout as mbuf->hash.sched, as defined by librte_sched.
Now, we are basically replacing sched with queue_id, whose format is defined by librte_sched. So why not keep the same approach going forward?
What does this mean in practice:
- queue_id is simply packaging (subport ID, pipe ID, tc, tc_queue) into the 32-bit queue_id.
- we can simply pre-pack subport ID and pipe ID into queue_id, and initially use tc = 0 and tc_queue = 0
-later on, as we read tc and tc_queue from DSCP table, we simply update them in the queue_id, basically we change the least significant 4 bits of queue_id
Does it make sense?
Let's also keep tm_data size of 8 bytes to preserve the current 8-byte action data alignment:
struct tm_data {
uint32_t queue_id;
uint32_t reserved;
} __attribute__((__packed__));
> +/* log2 representation of tm configuration */
> +struct tm_cfg {
> + uint32_t subports_per_port_log2;
> + uint32_t pipes_per_subport_log2;
> +} __attribute__((__packed__));
No need to worry about _log2 values if we follow this approach, as they will only be needed (and computed) by apply function, not the run-time tm_work function.
> +
> static int
> tm_apply_check(struct rte_table_action_tm_params *p,
> struct rte_table_action_tm_config *cfg)
> @@ -397,26 +392,37 @@ tm_apply(struct tm_data *data,
> return status;
>
> /* Apply */
> - data->queue_tc_color = 0;
> data->subport = (uint16_t) p->subport_id;
> data->pipe = p->pipe_id;
>
> return 0;
> }
>
> +static uint32_t
> +tm_sched_qindex(struct tm_data *data,
> + struct dscp_table_entry_data *dscp,
> + struct tm_cfg *tm)
> +{
> + uint32_t result;
> +
> + result = (data->subport << tm->pipes_per_subport_log2) + data-
> >pipe;
> + result = result * RTE_TABLE_ACTION_TC_MAX + dscp->tc;
> + result = result * RTE_TABLE_ACTION_TC_QUEUE_MAX + dscp-
> >queue;
> +
> + return result;
> +}
> +
This function is no longer needed with the above approach.
> static __rte_always_inline void
> pkt_work_tm(struct rte_mbuf *mbuf,
> struct tm_data *data,
> struct dscp_table_data *dscp_table,
> - uint32_t dscp)
> + uint32_t dscp,
> + struct tm_cfg *tm)
> {
> struct dscp_table_entry_data *dscp_entry = &dscp_table-
> >entry[dscp];
> - struct tm_data *sched_ptr = (struct tm_data *) &mbuf->hash.sched;
> - struct tm_data sched;
> + uint32_t queue = tm_sched_qindex(data, dscp_entry, tm);
>
> - sched = *data;
> - sched.queue_tc_color = dscp_entry->queue_tc_color;
> - *sched_ptr = sched;
> + rte_mbuf_sched_set(mbuf, queue, dscp_entry->tc, dscp_entry-
> >color);
> }
>
With the above approach:
uint32_t queue_id = data->queue_id | (dscp_entry-> tc << 2) | dscp_entry->tc_queue;
rte_mbuf_sched_set(mbuf, queue_id, dscp_entry->tc, dscp_entry-color);
> /**
> @@ -2440,6 +2446,7 @@ struct rte_table_action {
> struct ap_data data;
> struct dscp_table_data dscp_table;
> struct meter_profile_data mp[METER_PROFILES_MAX];
> + struct tm_cfg tm;
> };
>
Not needed with the above approach.
> struct rte_table_action *
> @@ -2465,6 +2472,11 @@ rte_table_action_create(struct
> rte_table_action_profile *profile,
> memcpy(&action->cfg, &profile->cfg, sizeof(profile->cfg));
> memcpy(&action->data, &profile->data, sizeof(profile->data));
>
> + action->tm.subports_per_port_log2 =
> + __builtin_ctz(profile->cfg.tm.n_subports_per_port);
> + action->tm.pipes_per_subport_log2 =
> + __builtin_ctz(profile->cfg.tm.n_pipes_per_subport);
> +
> return action;
> }
>
> @@ -2580,17 +2592,13 @@ rte_table_action_dscp_table_update(struct
> rte_table_action *action,
> &action->dscp_table.entry[i];
> struct rte_table_action_dscp_table_entry *entry =
> &table->entry[i];
> - uint16_t queue_tc_color =
> - MBUF_SCHED_QUEUE_TC_COLOR(entry-
> >tc_queue_id,
> - entry->tc_id,
> - entry->color);
>
> if ((dscp_mask & (1LLU << i)) == 0)
> continue;
>
> data->color = entry->color;
> data->tc = entry->tc_id;
> - data->queue_tc_color = queue_tc_color;
> + data->queue = entry->tc_queue_id;
> }
>
> return 0;
> @@ -2882,7 +2890,8 @@ pkt_work(struct rte_mbuf *mbuf,
> pkt_work_tm(mbuf,
> data,
> &action->dscp_table,
> - dscp);
> + dscp,
> + &action->tm);
> }
>
> if (cfg->action_mask & (1LLU << RTE_TABLE_ACTION_DECAP)) {
> @@ -3108,22 +3117,26 @@ pkt4_work(struct rte_mbuf **mbufs,
> pkt_work_tm(mbuf0,
> data0,
> &action->dscp_table,
> - dscp0);
> + dscp0,
> + &action->tm);
>
> pkt_work_tm(mbuf1,
> data1,
> &action->dscp_table,
> - dscp1);
> + dscp1,
> + &action->tm);
>
> pkt_work_tm(mbuf2,
> data2,
> &action->dscp_table,
> - dscp2);
> + dscp2,
> + &action->tm);
>
> pkt_work_tm(mbuf3,
> data3,
> &action->dscp_table,
> - dscp3);
> + dscp3,
> + &action->tm);
> }
>
> if (cfg->action_mask & (1LLU << RTE_TABLE_ACTION_DECAP)) {
> diff --git a/lib/librte_sched/Makefile b/lib/librte_sched/Makefile
> index 46c53ed71..644fd9d15 100644
> --- a/lib/librte_sched/Makefile
> +++ b/lib/librte_sched/Makefile
> @@ -18,7 +18,7 @@ LDLIBS += -lrte_timer
>
> EXPORT_MAP := rte_sched_version.map
>
> -LIBABIVER := 1
> +LIBABIVER := 2
>
> #
> # all source are stored in SRCS-y
> diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c
> index 587d5e602..a6d9a5886 100644
> --- a/lib/librte_sched/rte_sched.c
> +++ b/lib/librte_sched/rte_sched.c
> @@ -41,6 +41,9 @@
> #define RTE_SCHED_PIPE_INVALID UINT32_MAX
> #define RTE_SCHED_BMP_POS_INVALID UINT32_MAX
>
> +#define RTE_SCHED_QUEUES_PER_PIPE_LOG2 \
> + __builtin_ctz(RTE_SCHED_QUEUES_PER_PIPE)
> +
> /* Scaling for cycles_per_byte calculation
> * Chosen so that minimum rate is 480 bit/sec
> */
> @@ -128,22 +131,6 @@ enum grinder_state {
> e_GRINDER_READ_MBUF
> };
>
> -/*
> - * Path through the scheduler hierarchy used by the scheduler enqueue
> - * operation to identify the destination queue for the current
> - * packet. Stored in the field pkt.hash.sched of struct rte_mbuf of
> - * each packet, typically written by the classification stage and read
> - * by scheduler enqueue.
> - */
> -struct rte_sched_port_hierarchy {
> - uint16_t queue:2; /**< Queue ID (0 .. 3) */
> - uint16_t traffic_class:2; /**< Traffic class ID (0 .. 3)*/
> - uint32_t color:2; /**< Color */
> - uint16_t unused:10;
> - uint16_t subport; /**< Subport ID */
> - uint32_t pipe; /**< Pipe ID */
> -};
> -
> struct rte_sched_grinder {
> /* Pipe cache */
> uint16_t pcache_qmask[RTE_SCHED_GRINDER_PCACHE_SIZE];
> @@ -228,6 +215,7 @@ struct rte_sched_port {
> uint8_t *bmp_array;
> struct rte_mbuf **queue_array;
> uint8_t memory[0] __rte_cache_aligned;
> +
> } __rte_cache_aligned;
>
Please remove this blank line.
> enum rte_sched_port_array {
> @@ -242,13 +230,11 @@ enum rte_sched_port_array {
> };
>
> #ifdef RTE_SCHED_COLLECT_STATS
> -
> static inline uint32_t
> rte_sched_port_queues_per_subport(struct rte_sched_port *port)
> {
> return RTE_SCHED_QUEUES_PER_PIPE * port-
> >n_pipes_per_subport;
> }
> -
> #endif
>
Please put back the two blank lines that got removed.
> static inline uint32_t
> @@ -1006,44 +992,56 @@ rte_sched_port_pipe_profile_add(struct
> rte_sched_port *port,
> return 0;
> }
>
> +static inline uint32_t
> +rte_sched_port_qindex(struct rte_sched_port *port,
> + uint32_t subport,
> + uint32_t pipe,
> + uint32_t traffic_class,
> + uint32_t queue)
> +{
> + uint32_t result;
> +
> + result = (subport << __builtin_ctz(port->n_pipes_per_subport)) +
> pipe;
> + result = result * RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE +
> traffic_class;
> + result = result * RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS + queue;
> +
> + return result;
> +}
> +
This is a performance critical run-time function, so let's optimize it by pre-computing log2 value for n_pipes_per_subport and store it in the port data structure: port->n_pipes_per_subport_log2.
We should also make sure we truncate subport ID and pipe ID in case they are bigger than max, which is easily done since the max values are enforced to be power of 2.
static inline uint32_t
rte_sched_port_qindex(struct rte_sched_port *port,
uint32_t subport,
uint32_t pipe,
uint32_t traffic_class,
uint32_t queue)
{
return ((subport & (port->n_subports_per_port - 1)) << (port->n_pipes_per_subport_log2 + 4)) |
((pipe & (port->n_pipes_per_subport - 1)) << 4) |
((traffic_class & (RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE - 1)) << 2) |
(queue & (RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS - 1));
}
> void
> -rte_sched_port_pkt_write(struct rte_mbuf *pkt,
> +rte_sched_port_pkt_write(struct rte_sched_port *port,
> + struct rte_mbuf *pkt,
> uint32_t subport, uint32_t pipe, uint32_t
> traffic_class,
> uint32_t queue, enum rte_meter_color color)
> {
> - struct rte_sched_port_hierarchy *sched
> - = (struct rte_sched_port_hierarchy *) &pkt->hash.sched;
> -
> - RTE_BUILD_BUG_ON(sizeof(*sched) > sizeof(pkt->hash.sched));
> -
> - sched->color = (uint32_t) color;
> - sched->subport = subport;
> - sched->pipe = pipe;
> - sched->traffic_class = traffic_class;
> - sched->queue = queue;
> + uint32_t queue_id = rte_sched_port_qindex(port, subport, pipe,
> + traffic_class, queue);
> + rte_mbuf_sched_set(pkt, queue_id, traffic_class, (uint8_t)color);
> }
>
> void
> -rte_sched_port_pkt_read_tree_path(const struct rte_mbuf *pkt,
> +rte_sched_port_pkt_read_tree_path(struct rte_sched_port *port,
> + const struct rte_mbuf *pkt,
> uint32_t *subport, uint32_t *pipe,
> uint32_t *traffic_class, uint32_t *queue)
> {
> - const struct rte_sched_port_hierarchy *sched
> - = (const struct rte_sched_port_hierarchy *) &pkt-
> >hash.sched;
> -
> - *subport = sched->subport;
> - *pipe = sched->pipe;
> - *traffic_class = sched->traffic_class;
> - *queue = sched->queue;
> + uint32_t qid = rte_mbuf_sched_queue_read(pkt);
queue_id instead of qid, please.
> +
> + *subport = qid >>
> + (__builtin_ctz
> + (RTE_SCHED_QUEUES_PER_PIPE <<
> + __builtin_ctz(port->n_pipes_per_subport)
> + )
> + );
Not correct.
*subport = queue_id >> (port->n_pipes_per_subport_log2 + 4);
> + *pipe = qid >> RTE_SCHED_QUEUES_PER_PIPE_LOG2;
Not correct.
*pipe = (queue_id >> 4) & (port->n_queues_per_subport - 1);
> + *traffic_class = rte_mbuf_sched_traffic_class_read(pkt);
Let's read traffic class from queue_id in order to keep consistency with support ID and pipe ID, please:
*traffic_class = (queue_id >> 2) & (RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE - 1);
> + *queue = qid & (RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS - 1);
> }
>
> enum rte_meter_color
> rte_sched_port_pkt_read_color(const struct rte_mbuf *pkt)
> {
> - const struct rte_sched_port_hierarchy *sched
> - = (const struct rte_sched_port_hierarchy *) &pkt-
> >hash.sched;
> -
> - return (enum rte_meter_color) sched->color;
> + return (enum rte_meter_color)rte_mbuf_sched_color_read(pkt);
> }
>
> int
> @@ -1100,18 +1098,6 @@ rte_sched_queue_read_stats(struct
> rte_sched_port *port,
> return 0;
> }
>
> -static inline uint32_t
> -rte_sched_port_qindex(struct rte_sched_port *port, uint32_t subport,
> uint32_t pipe, uint32_t traffic_class, uint32_t queue)
> -{
> - uint32_t result;
> -
> - result = subport * port->n_pipes_per_subport + pipe;
> - result = result * RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE +
> traffic_class;
> - result = result * RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS + queue;
> -
> - return result;
> -}
> -
> #ifdef RTE_SCHED_DEBUG
>
> static inline int
> @@ -1272,11 +1258,8 @@ rte_sched_port_enqueue_qptrs_prefetch0(struct
> rte_sched_port *port,
> #ifdef RTE_SCHED_COLLECT_STATS
> struct rte_sched_queue_extra *qe;
> #endif
> - uint32_t subport, pipe, traffic_class, queue, qindex;
> -
> - rte_sched_port_pkt_read_tree_path(pkt, &subport, &pipe,
> &traffic_class, &queue);
> + uint32_t qindex = rte_mbuf_sched_queue_read(pkt);
>
> - qindex = rte_sched_port_qindex(port, subport, pipe, traffic_class,
> queue);
> q = port->queue + qindex;
> rte_prefetch0(q);
> #ifdef RTE_SCHED_COLLECT_STATS
> diff --git a/lib/librte_sched/rte_sched.h b/lib/librte_sched/rte_sched.h
> index 84fa896de..243efa1d4 100644
> --- a/lib/librte_sched/rte_sched.h
> +++ b/lib/librte_sched/rte_sched.h
> @@ -355,6 +355,8 @@ rte_sched_queue_read_stats(struct rte_sched_port
> *port,
> * Scheduler hierarchy path write to packet descriptor. Typically
> * called by the packet classification stage.
> *
> + * @param port
> + * Handle to port scheduler instance
> * @param pkt
> * Packet descriptor handle
> * @param subport
> @@ -369,7 +371,8 @@ rte_sched_queue_read_stats(struct rte_sched_port
> *port,
> * Packet color set
> */
> void
> -rte_sched_port_pkt_write(struct rte_mbuf *pkt,
> +rte_sched_port_pkt_write(struct rte_sched_port *port,
> + struct rte_mbuf *pkt,
> uint32_t subport, uint32_t pipe, uint32_t
> traffic_class,
> uint32_t queue, enum rte_meter_color color);
>
> @@ -379,6 +382,8 @@ rte_sched_port_pkt_write(struct rte_mbuf *pkt,
> * enqueue operation. The subport, pipe, traffic class and queue
> * parameters need to be pre-allocated by the caller.
> *
> + * @param port
> + * Handle to port scheduler instance
> * @param pkt
> * Packet descriptor handle
> * @param subport
> @@ -392,7 +397,8 @@ rte_sched_port_pkt_write(struct rte_mbuf *pkt,
> *
> */
> void
> -rte_sched_port_pkt_read_tree_path(const struct rte_mbuf *pkt,
> +rte_sched_port_pkt_read_tree_path(struct rte_sched_port *port,
> + const struct rte_mbuf *pkt,
> uint32_t *subport, uint32_t *pipe,
> uint32_t *traffic_class, uint32_t *queue);
>
> diff --git a/test/test/test_sched.c b/test/test/test_sched.c
> index 32e500ba9..40e411cab 100644
> --- a/test/test/test_sched.c
> +++ b/test/test/test_sched.c
> @@ -76,7 +76,7 @@ create_mempool(void)
> }
>
> static void
> -prepare_pkt(struct rte_mbuf *mbuf)
> +prepare_pkt(struct rte_sched_port *port, struct rte_mbuf *mbuf)
> {
> struct ether_hdr *eth_hdr;
> struct vlan_hdr *vlan1, *vlan2;
> @@ -95,7 +95,8 @@ prepare_pkt(struct rte_mbuf *mbuf)
> ip_hdr->dst_addr = IPv4(0,0,TC,QUEUE);
>
>
> - rte_sched_port_pkt_write(mbuf, SUBPORT, PIPE, TC, QUEUE,
> e_RTE_METER_YELLOW);
> + rte_sched_port_pkt_write(port, mbuf, SUBPORT, PIPE, TC, QUEUE,
> + e_RTE_METER_YELLOW);
>
> /* 64 byte packet */
> mbuf->pkt_len = 60;
> @@ -138,7 +139,7 @@ test_sched(void)
> for (i = 0; i < 10; i++) {
> in_mbufs[i] = rte_pktmbuf_alloc(mp);
> TEST_ASSERT_NOT_NULL(in_mbufs[i], "Packet allocation
> failed\n");
> - prepare_pkt(in_mbufs[i]);
> + prepare_pkt(port, in_mbufs[i]);
> }
>
>
> @@ -155,7 +156,7 @@ test_sched(void)
> color = rte_sched_port_pkt_read_color(out_mbufs[i]);
> TEST_ASSERT_EQUAL(color, e_RTE_METER_YELLOW, "Wrong
> color\n");
>
> - rte_sched_port_pkt_read_tree_path(out_mbufs[i],
> + rte_sched_port_pkt_read_tree_path(port, out_mbufs[i],
> &subport, &pipe, &traffic_class, &queue);
>
> TEST_ASSERT_EQUAL(subport, SUBPORT, "Wrong
> subport\n");
> --
> 2.17.1
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v2 1/3] mbuf: implement generic format for sched field
2018-12-07 14:31 ` [dpdk-dev] [PATCH v2 1/3] " Reshma Pattan
2018-12-11 19:02 ` Dumitrescu, Cristian
2018-12-12 18:17 ` Dumitrescu, Cristian
@ 2018-12-13 8:51 ` Rao, Nikhil
2018-12-13 18:08 ` [dpdk-dev] [PATCH v3 1/2] eal: add new rte color definition Reshma Pattan
3 siblings, 0 replies; 74+ messages in thread
From: Rao, Nikhil @ 2018-12-13 8:51 UTC (permalink / raw)
To: Pattan, Reshma, dev, Dumitrescu, Cristian, jerin.jacob, Singh, Jasvinder
Cc: Pattan, Reshma, Rao, Nikhil
Hi Reshma,
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Reshma Pattan
> Sent: Friday, December 7, 2018 8:02 PM
> To: dev@dpdk.org; Dumitrescu, Cristian <cristian.dumitrescu@intel.com>;
> jerin.jacob@caviumnetworks.com; Singh, Jasvinder
> <jasvinder.singh@intel.com>
> Cc: Pattan, Reshma <reshma.pattan@intel.com>
> Subject: [dpdk-dev] [PATCH v2 1/3] mbuf: implement generic format for
> sched field
>
> This patch implements the changes proposed in the deprecation notes [1][2].
>
> librte_mbuf changes:
> The mbuf::hash::sched field is updated to support generic definition in line
> with the ethdev TM and MTR APIs. The new generic format contains: queue
> ID, traffic class, color.
>
> Added public APIs to set and get these new fields to and from mbuf.
>
> librte_sched changes:
> In addtion, following API functions of the sched library have been modified
> with an additional parameter of type struct rte_sched_port to accommodate
> the changes made to mbuf sched field.
> (i) rte_sched_port_pkt_write()
> (ii) rte_sched_port_pkt_read_tree_path()
>
> librte_pipeline, qos_sched UT, qos_sched app are updated to make use of
> new changes.
>
> Also mbuf::hash::txadpater
s/txadpater/txadapter
> have been added for eventdev txq,
s/have/has
> rte_event_eth_tx_adapter_txq_set and rte_event_eth_tx_adapter_txq_get()
> are updated to use uses mbuf::hash::txadpater.txq.
s/txadpater/txadapter
>
<snip>
>
> diff --git a/lib/librte_eventdev/rte_event_eth_tx_adapter.h
> b/lib/librte_eventdev/rte_event_eth_tx_adapter.h
> index 81456d4a9..b406660ab 100644
> --- a/lib/librte_eventdev/rte_event_eth_tx_adapter.h
> +++ b/lib/librte_eventdev/rte_event_eth_tx_adapter.h
> @@ -63,11 +63,11 @@
> * function can be used to retrieve the adapter's service function ID.
> *
> * The ethernet port and transmit queue index to transmit the mbuf on are
> - * specified using the mbuf port and the higher 16 bits of
> - * struct rte_mbuf::hash::sched:hi. The application should use the
> - * rte_event_eth_tx_adapter_txq_set() and
> rte_event_eth_tx_adapter_txq_get()
> - * functions to access the transmit queue index since it is expected that the
> - * transmit queue will be eventually defined within struct rte_mbuf and using
> + * specified using the mbuf port struct rte_mbuf::hash::txadapter:txq.
> + * The application should use the rte_event_eth_tx_adapter_txq_set()
> + * and rte_event_eth_tx_adapter_txq_get() functions to access the
> + transmit
> + * queue index
>since it is expected that the transmit queue will be
> + * eventually defined within struct rte_mbuf and
Can we delete the text above ?
> using
> * these macros will help with minimizing application impact due to
> * a change in how the transmit queue index is specified.
> */
Retaining the macro looks OK to me.
> @@ -300,7 +300,7 @@ rte_event_eth_tx_adapter_queue_del(uint8_t id,
> static __rte_always_inline void __rte_experimental
> rte_event_eth_tx_adapter_txq_set(struct rte_mbuf *pkt, uint16_t queue) {
> - uint16_t *p = (uint16_t *)&pkt->hash.sched.hi;
> + uint16_t *p = (uint16_t *)&pkt->hash.txadapter.txq;
> p[1] = queue;
> }
Replace with
pkt->hash.txadapter.txq = queue;
>
> @@ -320,7 +320,7 @@ rte_event_eth_tx_adapter_txq_set(struct rte_mbuf
> *pkt, uint16_t queue) static __rte_always_inline uint16_t
> __rte_experimental rte_event_eth_tx_adapter_txq_get(struct rte_mbuf
> *pkt) {
> - uint16_t *p = (uint16_t *)&pkt->hash.sched.hi;
> + uint16_t *p = (uint16_t *)&pkt->hash.txadapter.txq;
> return p[1];
> }
Replace with
return pkt->hash.txadapter.txq;
Thanks,
Nikhil
^ permalink raw reply [flat|nested] 74+ messages in thread* [dpdk-dev] [PATCH v3 1/2] eal: add new rte color definition
2018-12-07 14:31 ` [dpdk-dev] [PATCH v2 1/3] " Reshma Pattan
` (2 preceding siblings ...)
2018-12-13 8:51 ` Rao, Nikhil
@ 2018-12-13 18:08 ` Reshma Pattan
2018-12-13 18:08 ` [dpdk-dev] [PATCH v3 2/2] mbuf: implement generic format for sched field Reshma Pattan
` (3 more replies)
3 siblings, 4 replies; 74+ messages in thread
From: Reshma Pattan @ 2018-12-13 18:08 UTC (permalink / raw)
To: dev, jerin.jacob, nikhil.rao, jasvinder.singh, cristian.dumitrescu
Cc: Reshma Pattan
Added new rte_color definition in eal to
consolidate color definition which is currently replicated
in various places such as rte_meter.h, rte_tm.h and rte_mtr.h
Created aliases for rte_tm_color, rte_mtr_color and rte_meter_color
to use new rte_color values.
The definitions of rte_tm_color, rte_mtr_color and rte_meter_color
will be deprecated in future.
Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
---
v2: Addressed review comments given in the below link
http://patches.dpdk.org/patch/48588/
Added rte_color.h to meson build.
---
---
lib/librte_eal/common/Makefile | 2 +-
lib/librte_eal/common/include/rte_color.h | 26 +++++++++++++++++++++++
lib/librte_eal/common/meson.build | 1 +
lib/librte_ethdev/rte_mtr.h | 8 +++++++
lib/librte_ethdev/rte_tm.h | 8 +++++++
lib/librte_meter/rte_meter.h | 8 +++++++
6 files changed, 52 insertions(+), 1 deletion(-)
create mode 100644 lib/librte_eal/common/include/rte_color.h
diff --git a/lib/librte_eal/common/Makefile b/lib/librte_eal/common/Makefile
index 87d8c455d..c76bb2dd7 100644
--- a/lib/librte_eal/common/Makefile
+++ b/lib/librte_eal/common/Makefile
@@ -17,7 +17,7 @@ INC += rte_pci_dev_feature_defs.h rte_pci_dev_features.h
INC += rte_malloc.h rte_keepalive.h rte_time.h
INC += rte_service.h rte_service_component.h
INC += rte_bitmap.h rte_vfio.h rte_hypervisor.h rte_test.h
-INC += rte_reciprocal.h rte_fbarray.h rte_uuid.h
+INC += rte_reciprocal.h rte_fbarray.h rte_uuid.h rte_color.h
GENERIC_INC := rte_atomic.h rte_byteorder.h rte_cycles.h rte_prefetch.h
GENERIC_INC += rte_spinlock.h rte_memcpy.h rte_cpuflags.h rte_rwlock.h
diff --git a/lib/librte_eal/common/include/rte_color.h b/lib/librte_eal/common/include/rte_color.h
new file mode 100644
index 000000000..fafe1146d
--- /dev/null
+++ b/lib/librte_eal/common/include/rte_color.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2018 Intel Corporation
+ */
+
+#ifndef __INCLUDE_RTE_COLOR_H__
+#define __INCLUDE_RTE_COLOR_H__
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/**
+ * Color
+ */
+enum rte_color {
+ RTE_COLOR_GREEN = 0, /**< Green */
+ RTE_COLOR_YELLOW, /**< Yellow */
+ RTE_COLOR_RED, /**< Red */
+ RTE_COLORS /**< Number of colors */
+};
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* __RTE_COLOR_H__ */
diff --git a/lib/librte_eal/common/meson.build b/lib/librte_eal/common/meson.build
index 2a10d57d8..f0a561f21 100644
--- a/lib/librte_eal/common/meson.build
+++ b/lib/librte_eal/common/meson.build
@@ -52,6 +52,7 @@ common_headers = files(
'include/rte_bus.h',
'include/rte_bitmap.h',
'include/rte_class.h',
+ 'include/rte_color.h',
'include/rte_common.h',
'include/rte_debug.h',
'include/rte_devargs.h',
diff --git a/lib/librte_ethdev/rte_mtr.h b/lib/librte_ethdev/rte_mtr.h
index c4819b274..1de20ef2b 100644
--- a/lib/librte_ethdev/rte_mtr.h
+++ b/lib/librte_ethdev/rte_mtr.h
@@ -76,6 +76,7 @@
#include <stdint.h>
#include <rte_compat.h>
#include <rte_common.h>
+#include <rte_color.h>
#ifdef __cplusplus
extern "C" {
@@ -91,6 +92,13 @@ enum rte_mtr_color {
RTE_MTR_COLORS /**< Number of colors. */
};
+/* New rte_color is defined and used to deprecate rte_mtr_color soon. */
+#define rte_mtr_color rte_color
+#define RTE_MTR_GREEN RTE_COLOR_GREEN
+#define RTE_MTR_YELLOW RTE_COLOR_YELLOW
+#define RTE_MTR_RED RTE_COLOR_RED
+#define RTE_MTR_COLORS RTE_COLORS
+
/**
* Statistics counter type
*/
diff --git a/lib/librte_ethdev/rte_tm.h b/lib/librte_ethdev/rte_tm.h
index 646ef3880..cce8230b6 100644
--- a/lib/librte_ethdev/rte_tm.h
+++ b/lib/librte_ethdev/rte_tm.h
@@ -51,6 +51,7 @@
#include <stdint.h>
#include <rte_common.h>
+#include <rte_color.h>
#ifdef __cplusplus
extern "C" {
@@ -125,6 +126,13 @@ enum rte_tm_color {
RTE_TM_COLORS /**< Number of colors */
};
+/* New rte_color is defined and used to deprecate rte_tm_color soon. */
+#define rte_tm_color rte_color
+#define RTE_TM_GREEN RTE_COLOR_GREEN
+#define RTE_TM_YELLOW RTE_COLOR_YELLOW
+#define RTE_TM_RED RTE_COLOR_RED
+#define RTE_TM_COLORS RTE_COLORS
+
/**
* Node statistics counter type
*/
diff --git a/lib/librte_meter/rte_meter.h b/lib/librte_meter/rte_meter.h
index 58a051583..e8d878b12 100644
--- a/lib/librte_meter/rte_meter.h
+++ b/lib/librte_meter/rte_meter.h
@@ -21,6 +21,7 @@ extern "C" {
#include <stdint.h>
+#include <rte_color.h>
/*
* Application Programmer's Interface (API)
*
@@ -34,6 +35,13 @@ enum rte_meter_color {
e_RTE_METER_COLORS /**< Number of available colors */
};
+/* New rte_color is defined and used to deprecate rte_meter_color soon. */
+#define rte_meter_color rte_color
+#define e_RTE_METER_GREEN RTE_COLOR_GREEN
+#define e_RTE_METER_YELLOW RTE_COLOR_YELLOW
+#define e_RTE_METER_RED RTE_COLOR_RED
+#define e_RTE_METER_COLORS RTE_COLORS
+
/** srTCM parameters per metered traffic flow. The CIR, CBS and EBS parameters only
count bytes of IP packets and do not include link specific headers. At least one of
the CBS or EBS parameters has to be greater than zero. */
--
2.17.1
^ permalink raw reply [flat|nested] 74+ messages in thread* [dpdk-dev] [PATCH v3 2/2] mbuf: implement generic format for sched field
2018-12-13 18:08 ` [dpdk-dev] [PATCH v3 1/2] eal: add new rte color definition Reshma Pattan
@ 2018-12-13 18:08 ` Reshma Pattan
2018-12-14 22:52 ` Dumitrescu, Cristian
2018-12-14 22:19 ` [dpdk-dev] [PATCH v3 1/2] eal: add new rte color definition Dumitrescu, Cristian
` (2 subsequent siblings)
3 siblings, 1 reply; 74+ messages in thread
From: Reshma Pattan @ 2018-12-13 18:08 UTC (permalink / raw)
To: dev, jerin.jacob, nikhil.rao, jasvinder.singh, cristian.dumitrescu
Cc: Reshma Pattan
This patch implements the changes proposed in the deprecation
notes [1][2].
librte_mbuf changes:
The mbuf::hash::sched field is updated to support generic
definition in line with the ethdev TM and MTR APIs. The new generic
format contains: queue ID, traffic class, color.
Added public APIs to set and get these new fields to and from mbuf.
librte_sched changes:
In addtion, following API functions of the sched library have
been modified with an additional parameter of type struct
rte_sched_port to accommodate the changes made to mbuf sched field.
(i) rte_sched_port_pkt_write()
(ii) rte_sched_port_pkt_read_tree_path()
librte_pipeline, qos_sched UT, qos_sched app are updated
to make use of new changes.
Also mbuf::hash::txadapter has been added for eventdev txq,
rte_event_eth_tx_adapter_txq_set and rte_event_eth_tx_adapter_txq_get()
are updated to use uses mbuf::hash::txadapter.txq.
doc:
Release notes updated.
Removed deprecation notice for mbuf::hash::sched and sched API.
[1] http://mails.dpdk.org/archives/dev/2018-February/090651.html
[2] https://mails.dpdk.org/archives/dev/2018-November/119051.html
Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
---
v3: addressed review comments given in the below link.
http://patches.dpdk.org/patch/48587/
Updated library ABI versioning in meson build.
---
---
doc/guides/rel_notes/deprecation.rst | 10 --
doc/guides/rel_notes/release_19_02.rst | 4 +-
examples/qos_sched/app_thread.c | 7 +-
examples/qos_sched/main.c | 1 +
.../rte_event_eth_tx_adapter.h | 18 ++-
lib/librte_mbuf/Makefile | 2 +-
lib/librte_mbuf/meson.build | 2 +-
lib/librte_mbuf/rte_mbuf.h | 114 +++++++++++++++++-
lib/librte_pipeline/rte_table_action.c | 43 ++-----
lib/librte_sched/Makefile | 2 +-
lib/librte_sched/meson.build | 1 +
lib/librte_sched/rte_sched.c | 90 ++++++--------
lib/librte_sched/rte_sched.h | 10 +-
test/test/test_sched.c | 9 +-
14 files changed, 191 insertions(+), 122 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index b48486d36..60e081a54 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -49,16 +49,6 @@ Deprecation Notices
structure would be made internal (or removed if all dependencies are cleared)
in future releases.
-* mbuf: The opaque ``mbuf->hash.sched`` field will be updated to support generic
- definition in line with the ethdev TM and MTR APIs. Currently, this field
- is defined in librte_sched in a non-generic way. The new generic format
- will contain: queue ID, traffic class, color. Field size will not change.
-
-* sched: Some API functions will change prototype due to the above
- deprecation note for mbuf->hash.sched, e.g. ``rte_sched_port_pkt_write()``
- and ``rte_sched_port_pkt_read()`` will likely have an additional parameter
- of type ``struct rte_sched_port``.
-
* mbuf: the macro ``RTE_MBUF_INDIRECT()`` will be removed in v18.08 or later and
replaced with ``RTE_MBUF_CLONED()`` which is already added in v18.05. As
``EXT_ATTACHED_MBUF`` is newly introduced in v18.05, ``RTE_MBUF_INDIRECT()``
diff --git a/doc/guides/rel_notes/release_19_02.rst b/doc/guides/rel_notes/release_19_02.rst
index a94fa86a7..deadaafa9 100644
--- a/doc/guides/rel_notes/release_19_02.rst
+++ b/doc/guides/rel_notes/release_19_02.rst
@@ -146,7 +146,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_kvargs.so.1
librte_latencystats.so.1
librte_lpm.so.2
- librte_mbuf.so.4
+ + librte_mbuf.so.5
librte_member.so.1
librte_mempool.so.5
librte_meter.so.2
@@ -168,7 +168,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_rawdev.so.1
librte_reorder.so.1
librte_ring.so.2
- librte_sched.so.1
+ + librte_sched.so.2
librte_security.so.1
librte_table.so.3
librte_timer.so.1
diff --git a/examples/qos_sched/app_thread.c b/examples/qos_sched/app_thread.c
index a59274236..bec4deee3 100644
--- a/examples/qos_sched/app_thread.c
+++ b/examples/qos_sched/app_thread.c
@@ -73,8 +73,11 @@ app_rx_thread(struct thread_conf **confs)
for(i = 0; i < nb_rx; i++) {
get_pkt_sched(rx_mbufs[i],
&subport, &pipe, &traffic_class, &queue, &color);
- rte_sched_port_pkt_write(rx_mbufs[i], subport, pipe,
- traffic_class, queue, (enum rte_meter_color) color);
+ rte_sched_port_pkt_write(conf->sched_port,
+ rx_mbufs[i],
+ subport, pipe,
+ traffic_class, queue,
+ (enum rte_meter_color) color);
}
if (unlikely(rte_ring_sp_enqueue_bulk(conf->rx_ring,
diff --git a/examples/qos_sched/main.c b/examples/qos_sched/main.c
index e7c97bd64..c0ed16b68 100644
--- a/examples/qos_sched/main.c
+++ b/examples/qos_sched/main.c
@@ -55,6 +55,7 @@ app_main_loop(__attribute__((unused))void *dummy)
flow->rx_thread.rx_port = flow->rx_port;
flow->rx_thread.rx_ring = flow->rx_ring;
flow->rx_thread.rx_queue = flow->rx_queue;
+ flow->rx_thread.sched_port = flow->sched_port;
rx_confs[rx_idx++] = &flow->rx_thread;
diff --git a/lib/librte_eventdev/rte_event_eth_tx_adapter.h b/lib/librte_eventdev/rte_event_eth_tx_adapter.h
index 81456d4a9..2a50656d9 100644
--- a/lib/librte_eventdev/rte_event_eth_tx_adapter.h
+++ b/lib/librte_eventdev/rte_event_eth_tx_adapter.h
@@ -63,13 +63,11 @@
* function can be used to retrieve the adapter's service function ID.
*
* The ethernet port and transmit queue index to transmit the mbuf on are
- * specified using the mbuf port and the higher 16 bits of
- * struct rte_mbuf::hash::sched:hi. The application should use the
- * rte_event_eth_tx_adapter_txq_set() and rte_event_eth_tx_adapter_txq_get()
- * functions to access the transmit queue index since it is expected that the
- * transmit queue will be eventually defined within struct rte_mbuf and using
- * these macros will help with minimizing application impact due to
- * a change in how the transmit queue index is specified.
+ * specified using the mbuf port struct rte_mbuf::hash::txadapter:txq.
+ * The application should use the rte_event_eth_tx_adapter_txq_set()
+ * and rte_event_eth_tx_adapter_txq_get() functions to access the transmit
+ * queue index, using these macros will help with minimizing application
+ * impact due to a change in how the transmit queue index is specified.
*/
#ifdef __cplusplus
@@ -300,8 +298,7 @@ rte_event_eth_tx_adapter_queue_del(uint8_t id,
static __rte_always_inline void __rte_experimental
rte_event_eth_tx_adapter_txq_set(struct rte_mbuf *pkt, uint16_t queue)
{
- uint16_t *p = (uint16_t *)&pkt->hash.sched.hi;
- p[1] = queue;
+ pkt->hash.txadapter.txq = queue;
}
/**
@@ -320,8 +317,7 @@ rte_event_eth_tx_adapter_txq_set(struct rte_mbuf *pkt, uint16_t queue)
static __rte_always_inline uint16_t __rte_experimental
rte_event_eth_tx_adapter_txq_get(struct rte_mbuf *pkt)
{
- uint16_t *p = (uint16_t *)&pkt->hash.sched.hi;
- return p[1];
+ return pkt->hash.txadapter.txq;
}
/**
diff --git a/lib/librte_mbuf/Makefile b/lib/librte_mbuf/Makefile
index e2b98a254..8c4c7d790 100644
--- a/lib/librte_mbuf/Makefile
+++ b/lib/librte_mbuf/Makefile
@@ -11,7 +11,7 @@ LDLIBS += -lrte_eal -lrte_mempool
EXPORT_MAP := rte_mbuf_version.map
-LIBABIVER := 4
+LIBABIVER := 5
# all source are stored in SRCS-y
SRCS-$(CONFIG_RTE_LIBRTE_MBUF) := rte_mbuf.c rte_mbuf_ptype.c rte_mbuf_pool_ops.c
diff --git a/lib/librte_mbuf/meson.build b/lib/librte_mbuf/meson.build
index 94d9c4c96..e37da0250 100644
--- a/lib/librte_mbuf/meson.build
+++ b/lib/librte_mbuf/meson.build
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017 Intel Corporation
-version = 4
+version = 5
sources = files('rte_mbuf.c', 'rte_mbuf_ptype.c', 'rte_mbuf_pool_ops.c')
headers = files('rte_mbuf.h', 'rte_mbuf_ptype.h', 'rte_mbuf_pool_ops.h')
deps += ['mempool']
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 3dbc6695e..032237321 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -34,6 +34,7 @@
#include <stdint.h>
#include <rte_compat.h>
#include <rte_common.h>
+#include <rte_color.h>
#include <rte_config.h>
#include <rte_mempool.h>
#include <rte_memory.h>
@@ -575,13 +576,24 @@ struct rte_mbuf {
*/
} fdir; /**< Filter identifier if FDIR enabled */
struct {
- uint32_t lo;
- uint32_t hi;
+ uint32_t queue_id; /**< Queue ID. */
+ uint8_t traffic_class;
+ /**< Traffic class ID. Traffic class 0
+ * is the highest priority traffic class.
+ */
+ uint8_t color;
+ /**< Color. @see enum rte_color.*/
+ uint16_t reserved; /**< Reserved. */
+ } sched; /**< Hierarchical scheduler */
+ struct {
+ uint32_t reserved1;
+ uint16_t reserved2;
+ uint16_t txq;
/**< The event eth Tx adapter uses this field
* to store Tx queue id.
* @see rte_event_eth_tx_adapter_txq_set()
*/
- } sched; /**< Hierarchical scheduler */
+ } txadapter; /**< Eventdev ethdev Tx adapter */
/**< User defined tags. See rte_distributor_process() */
uint32_t usr;
} hash; /**< hash information */
@@ -2289,6 +2301,102 @@ rte_pktmbuf_linearize(struct rte_mbuf *mbuf)
*/
void rte_pktmbuf_dump(FILE *f, const struct rte_mbuf *m, unsigned dump_len);
+/**
+ * Get the value of mbuf sched queue_id field.
+ */
+static inline uint32_t
+rte_mbuf_sched_queue_get(const struct rte_mbuf *m)
+{
+ return m->hash.sched.queue_id;
+}
+
+/**
+ * Get the value of mbuf sched traffic_class field.
+ */
+static inline uint8_t
+rte_mbuf_sched_traffic_class_get(const struct rte_mbuf *m)
+{
+ return m->hash.sched.traffic_class;
+}
+
+/**
+ * Get the value of mbuf sched color field.
+ */
+static inline enum rte_color
+rte_mbuf_sched_color_get(const struct rte_mbuf *m)
+{
+ return (enum rte_color)m->hash.sched.color;
+}
+
+/**
+ * Get the values of mbuf sched queue_id, traffic_class and color.
+ * @param m
+ * Mbuf to read
+ * @param queue_id
+ * Returns the queue id
+ * @param traffic_class
+ * Returns the traffic class id
+ * @param color
+ * Returns the colour id
+ */
+static inline void
+rte_mbuf_sched_get(const struct rte_mbuf *m, uint32_t *queue_id,
+ uint8_t *traffic_class,
+ enum rte_color *color)
+{
+ *queue_id = m->hash.sched.queue_id;
+ *traffic_class = m->hash.sched.traffic_class;
+ *color = (enum rte_color)m->hash.sched.color;
+}
+
+/**
+ * Set the mbuf sched queue_id to the defined value.
+ */
+static inline void
+rte_mbuf_sched_queue_set(struct rte_mbuf *m, uint32_t queue_id)
+{
+ m->hash.sched.queue_id = queue_id;
+}
+
+/**
+ * Set the mbuf sched traffic_class id to the defined value.
+ */
+static inline void
+rte_mbuf_sched_traffic_class_set(struct rte_mbuf *m, uint8_t traffic_class)
+{
+ m->hash.sched.traffic_class = traffic_class;
+}
+
+/**
+ * Set the mbuf sched color id to the defined value.
+ */
+static inline void
+rte_mbuf_sched_color_set(struct rte_mbuf *m, enum rte_color color)
+{
+ m->hash.sched.color = (uint8_t)color;
+}
+
+/**
+ * Set the mbuf sched queue_id, traffic_class and color.
+ * @param m
+ * Mbuf to set
+ * @param queue_id
+ * Queue id value to be set
+ * @param traffic_class
+ * Traffic class id value to be set
+ * @param color
+ * Color id to be set
+ */
+static inline void
+rte_mbuf_sched_set(struct rte_mbuf *m, uint32_t queue_id,
+ uint8_t traffic_class,
+ enum rte_color color)
+{
+ m->hash.sched.queue_id = queue_id;
+ m->hash.sched.traffic_class = traffic_class;
+ m->hash.sched.color = (uint8_t)color;
+}
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_pipeline/rte_table_action.c b/lib/librte_pipeline/rte_table_action.c
index 7c7c8dd82..3158301ff 100644
--- a/lib/librte_pipeline/rte_table_action.c
+++ b/lib/librte_pipeline/rte_table_action.c
@@ -107,14 +107,6 @@ mtr_cfg_check(struct rte_table_action_mtr_config *mtr)
return 0;
}
-#define MBUF_SCHED_QUEUE_TC_COLOR(queue, tc, color) \
- ((uint16_t)((((uint64_t)(queue)) & 0x3) | \
- ((((uint64_t)(tc)) & 0x3) << 2) | \
- ((((uint64_t)(color)) & 0x3) << 4)))
-
-#define MBUF_SCHED_COLOR(sched, color) \
- (((sched) & (~0x30LLU)) | ((color) << 4))
-
struct mtr_trtcm_data {
struct rte_meter_trtcm trtcm;
uint64_t stats[e_RTE_METER_COLORS];
@@ -176,7 +168,7 @@ mtr_data_size(struct rte_table_action_mtr_config *mtr)
struct dscp_table_entry_data {
enum rte_meter_color color;
uint16_t tc;
- uint16_t queue_tc_color;
+ uint16_t tc_queue;
};
struct dscp_table_data {
@@ -319,8 +311,7 @@ pkt_work_mtr(struct rte_mbuf *mbuf,
uint32_t dscp,
uint16_t total_length)
{
- uint64_t drop_mask, sched;
- uint64_t *sched_ptr = (uint64_t *) &mbuf->hash.sched;
+ uint64_t drop_mask;
struct dscp_table_entry_data *dscp_entry = &dscp_table->entry[dscp];
enum rte_meter_color color_in, color_meter, color_policer;
uint32_t tc, mp_id;
@@ -329,7 +320,6 @@ pkt_work_mtr(struct rte_mbuf *mbuf,
color_in = dscp_entry->color;
data += tc;
mp_id = MTR_TRTCM_DATA_METER_PROFILE_ID_GET(data);
- sched = *sched_ptr;
/* Meter */
color_meter = rte_meter_trtcm_color_aware_check(
@@ -346,7 +336,7 @@ pkt_work_mtr(struct rte_mbuf *mbuf,
drop_mask = MTR_TRTCM_DATA_POLICER_ACTION_DROP_GET(data, color_meter);
color_policer =
MTR_TRTCM_DATA_POLICER_ACTION_COLOR_GET(data, color_meter);
- *sched_ptr = MBUF_SCHED_COLOR(sched, color_policer);
+ rte_mbuf_sched_color_set(mbuf, color_policer);
return drop_mask;
}
@@ -368,9 +358,8 @@ tm_cfg_check(struct rte_table_action_tm_config *tm)
}
struct tm_data {
- uint16_t queue_tc_color;
- uint16_t subport;
- uint32_t pipe;
+ uint32_t queue_id;
+ uint32_t reserved;
} __attribute__((__packed__));
static int
@@ -397,9 +386,9 @@ tm_apply(struct tm_data *data,
return status;
/* Apply */
- data->queue_tc_color = 0;
- data->subport = (uint16_t) p->subport_id;
- data->pipe = p->pipe_id;
+ data->queue_id = p->subport_id <<
+ (__builtin_ctz(cfg->n_pipes_per_subport) + 4) |
+ p->pipe_id << 4;
return 0;
}
@@ -411,12 +400,10 @@ pkt_work_tm(struct rte_mbuf *mbuf,
uint32_t dscp)
{
struct dscp_table_entry_data *dscp_entry = &dscp_table->entry[dscp];
- struct tm_data *sched_ptr = (struct tm_data *) &mbuf->hash.sched;
- struct tm_data sched;
-
- sched = *data;
- sched.queue_tc_color = dscp_entry->queue_tc_color;
- *sched_ptr = sched;
+ uint32_t queue_id = data->queue_id |
+ (dscp_entry->tc << 2) |
+ dscp_entry->tc_queue;
+ rte_mbuf_sched_set(mbuf, queue_id, dscp_entry->tc, dscp_entry->color);
}
/**
@@ -2580,17 +2567,13 @@ rte_table_action_dscp_table_update(struct rte_table_action *action,
&action->dscp_table.entry[i];
struct rte_table_action_dscp_table_entry *entry =
&table->entry[i];
- uint16_t queue_tc_color =
- MBUF_SCHED_QUEUE_TC_COLOR(entry->tc_queue_id,
- entry->tc_id,
- entry->color);
if ((dscp_mask & (1LLU << i)) == 0)
continue;
data->color = entry->color;
data->tc = entry->tc_id;
- data->queue_tc_color = queue_tc_color;
+ data->tc_queue = entry->tc_queue_id;
}
return 0;
diff --git a/lib/librte_sched/Makefile b/lib/librte_sched/Makefile
index 46c53ed71..644fd9d15 100644
--- a/lib/librte_sched/Makefile
+++ b/lib/librte_sched/Makefile
@@ -18,7 +18,7 @@ LDLIBS += -lrte_timer
EXPORT_MAP := rte_sched_version.map
-LIBABIVER := 1
+LIBABIVER := 2
#
# all source are stored in SRCS-y
diff --git a/lib/librte_sched/meson.build b/lib/librte_sched/meson.build
index f85d64df8..8e989e5f6 100644
--- a/lib/librte_sched/meson.build
+++ b/lib/librte_sched/meson.build
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017 Intel Corporation
+version = 2
sources = files('rte_sched.c', 'rte_red.c', 'rte_approx.c')
headers = files('rte_sched.h', 'rte_sched_common.h',
'rte_red.h', 'rte_approx.h')
diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c
index 587d5e602..3b8b2b038 100644
--- a/lib/librte_sched/rte_sched.c
+++ b/lib/librte_sched/rte_sched.c
@@ -128,22 +128,6 @@ enum grinder_state {
e_GRINDER_READ_MBUF
};
-/*
- * Path through the scheduler hierarchy used by the scheduler enqueue
- * operation to identify the destination queue for the current
- * packet. Stored in the field pkt.hash.sched of struct rte_mbuf of
- * each packet, typically written by the classification stage and read
- * by scheduler enqueue.
- */
-struct rte_sched_port_hierarchy {
- uint16_t queue:2; /**< Queue ID (0 .. 3) */
- uint16_t traffic_class:2; /**< Traffic class ID (0 .. 3)*/
- uint32_t color:2; /**< Color */
- uint16_t unused:10;
- uint16_t subport; /**< Subport ID */
- uint32_t pipe; /**< Pipe ID */
-};
-
struct rte_sched_grinder {
/* Pipe cache */
uint16_t pcache_qmask[RTE_SCHED_GRINDER_PCACHE_SIZE];
@@ -185,6 +169,7 @@ struct rte_sched_port {
/* User parameters */
uint32_t n_subports_per_port;
uint32_t n_pipes_per_subport;
+ uint32_t n_pipes_per_subport_log2;
uint32_t rate;
uint32_t mtu;
uint32_t frame_overhead;
@@ -645,6 +630,8 @@ rte_sched_port_config(struct rte_sched_port_params *params)
/* User parameters */
port->n_subports_per_port = params->n_subports_per_port;
port->n_pipes_per_subport = params->n_pipes_per_subport;
+ port->n_pipes_per_subport_log2 =
+ __builtin_ctz(params->n_pipes_per_subport);
port->rate = params->rate;
port->mtu = params->mtu + params->frame_overhead;
port->frame_overhead = params->frame_overhead;
@@ -1006,44 +993,52 @@ rte_sched_port_pipe_profile_add(struct rte_sched_port *port,
return 0;
}
+static inline uint32_t
+rte_sched_port_qindex(struct rte_sched_port *port,
+ uint32_t subport,
+ uint32_t pipe,
+ uint32_t traffic_class,
+ uint32_t queue)
+{
+ return ((subport & (port->n_subports_per_port - 1)) <<
+ (port->n_pipes_per_subport_log2 + 4)) |
+ ((pipe & (port->n_pipes_per_subport - 1)) << 4) |
+ ((traffic_class &
+ (RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE - 1)) << 2) |
+ (queue & (RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS - 1));
+}
+
void
-rte_sched_port_pkt_write(struct rte_mbuf *pkt,
- uint32_t subport, uint32_t pipe, uint32_t traffic_class,
+rte_sched_port_pkt_write(struct rte_sched_port *port,
+ struct rte_mbuf *pkt,
+ uint32_t subport, uint32_t pipe,
+ uint32_t traffic_class,
uint32_t queue, enum rte_meter_color color)
{
- struct rte_sched_port_hierarchy *sched
- = (struct rte_sched_port_hierarchy *) &pkt->hash.sched;
-
- RTE_BUILD_BUG_ON(sizeof(*sched) > sizeof(pkt->hash.sched));
-
- sched->color = (uint32_t) color;
- sched->subport = subport;
- sched->pipe = pipe;
- sched->traffic_class = traffic_class;
- sched->queue = queue;
+ uint32_t queue_id = rte_sched_port_qindex(port, subport, pipe,
+ traffic_class, queue);
+ rte_mbuf_sched_set(pkt, queue_id, traffic_class, (enum rte_color)color);
}
void
-rte_sched_port_pkt_read_tree_path(const struct rte_mbuf *pkt,
+rte_sched_port_pkt_read_tree_path(struct rte_sched_port *port,
+ const struct rte_mbuf *pkt,
uint32_t *subport, uint32_t *pipe,
uint32_t *traffic_class, uint32_t *queue)
{
- const struct rte_sched_port_hierarchy *sched
- = (const struct rte_sched_port_hierarchy *) &pkt->hash.sched;
+ uint32_t queue_id = rte_mbuf_sched_queue_get(pkt);
- *subport = sched->subport;
- *pipe = sched->pipe;
- *traffic_class = sched->traffic_class;
- *queue = sched->queue;
+ *subport = queue_id >> (port->n_pipes_per_subport_log2 + 4);
+ *pipe = (queue_id >> 4) & (port->n_pipes_per_subport - 1);
+ *traffic_class = (queue_id >> 2) &
+ (RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE - 1);
+ *queue = queue_id & (RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS - 1);
}
enum rte_meter_color
rte_sched_port_pkt_read_color(const struct rte_mbuf *pkt)
{
- const struct rte_sched_port_hierarchy *sched
- = (const struct rte_sched_port_hierarchy *) &pkt->hash.sched;
-
- return (enum rte_meter_color) sched->color;
+ return (enum rte_meter_color)rte_mbuf_sched_color_get(pkt);
}
int
@@ -1100,18 +1095,6 @@ rte_sched_queue_read_stats(struct rte_sched_port *port,
return 0;
}
-static inline uint32_t
-rte_sched_port_qindex(struct rte_sched_port *port, uint32_t subport, uint32_t pipe, uint32_t traffic_class, uint32_t queue)
-{
- uint32_t result;
-
- result = subport * port->n_pipes_per_subport + pipe;
- result = result * RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE + traffic_class;
- result = result * RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS + queue;
-
- return result;
-}
-
#ifdef RTE_SCHED_DEBUG
static inline int
@@ -1272,11 +1255,8 @@ rte_sched_port_enqueue_qptrs_prefetch0(struct rte_sched_port *port,
#ifdef RTE_SCHED_COLLECT_STATS
struct rte_sched_queue_extra *qe;
#endif
- uint32_t subport, pipe, traffic_class, queue, qindex;
-
- rte_sched_port_pkt_read_tree_path(pkt, &subport, &pipe, &traffic_class, &queue);
+ uint32_t qindex = rte_mbuf_sched_queue_get(pkt);
- qindex = rte_sched_port_qindex(port, subport, pipe, traffic_class, queue);
q = port->queue + qindex;
rte_prefetch0(q);
#ifdef RTE_SCHED_COLLECT_STATS
diff --git a/lib/librte_sched/rte_sched.h b/lib/librte_sched/rte_sched.h
index 84fa896de..243efa1d4 100644
--- a/lib/librte_sched/rte_sched.h
+++ b/lib/librte_sched/rte_sched.h
@@ -355,6 +355,8 @@ rte_sched_queue_read_stats(struct rte_sched_port *port,
* Scheduler hierarchy path write to packet descriptor. Typically
* called by the packet classification stage.
*
+ * @param port
+ * Handle to port scheduler instance
* @param pkt
* Packet descriptor handle
* @param subport
@@ -369,7 +371,8 @@ rte_sched_queue_read_stats(struct rte_sched_port *port,
* Packet color set
*/
void
-rte_sched_port_pkt_write(struct rte_mbuf *pkt,
+rte_sched_port_pkt_write(struct rte_sched_port *port,
+ struct rte_mbuf *pkt,
uint32_t subport, uint32_t pipe, uint32_t traffic_class,
uint32_t queue, enum rte_meter_color color);
@@ -379,6 +382,8 @@ rte_sched_port_pkt_write(struct rte_mbuf *pkt,
* enqueue operation. The subport, pipe, traffic class and queue
* parameters need to be pre-allocated by the caller.
*
+ * @param port
+ * Handle to port scheduler instance
* @param pkt
* Packet descriptor handle
* @param subport
@@ -392,7 +397,8 @@ rte_sched_port_pkt_write(struct rte_mbuf *pkt,
*
*/
void
-rte_sched_port_pkt_read_tree_path(const struct rte_mbuf *pkt,
+rte_sched_port_pkt_read_tree_path(struct rte_sched_port *port,
+ const struct rte_mbuf *pkt,
uint32_t *subport, uint32_t *pipe,
uint32_t *traffic_class, uint32_t *queue);
diff --git a/test/test/test_sched.c b/test/test/test_sched.c
index 32e500ba9..40e411cab 100644
--- a/test/test/test_sched.c
+++ b/test/test/test_sched.c
@@ -76,7 +76,7 @@ create_mempool(void)
}
static void
-prepare_pkt(struct rte_mbuf *mbuf)
+prepare_pkt(struct rte_sched_port *port, struct rte_mbuf *mbuf)
{
struct ether_hdr *eth_hdr;
struct vlan_hdr *vlan1, *vlan2;
@@ -95,7 +95,8 @@ prepare_pkt(struct rte_mbuf *mbuf)
ip_hdr->dst_addr = IPv4(0,0,TC,QUEUE);
- rte_sched_port_pkt_write(mbuf, SUBPORT, PIPE, TC, QUEUE, e_RTE_METER_YELLOW);
+ rte_sched_port_pkt_write(port, mbuf, SUBPORT, PIPE, TC, QUEUE,
+ e_RTE_METER_YELLOW);
/* 64 byte packet */
mbuf->pkt_len = 60;
@@ -138,7 +139,7 @@ test_sched(void)
for (i = 0; i < 10; i++) {
in_mbufs[i] = rte_pktmbuf_alloc(mp);
TEST_ASSERT_NOT_NULL(in_mbufs[i], "Packet allocation failed\n");
- prepare_pkt(in_mbufs[i]);
+ prepare_pkt(port, in_mbufs[i]);
}
@@ -155,7 +156,7 @@ test_sched(void)
color = rte_sched_port_pkt_read_color(out_mbufs[i]);
TEST_ASSERT_EQUAL(color, e_RTE_METER_YELLOW, "Wrong color\n");
- rte_sched_port_pkt_read_tree_path(out_mbufs[i],
+ rte_sched_port_pkt_read_tree_path(port, out_mbufs[i],
&subport, &pipe, &traffic_class, &queue);
TEST_ASSERT_EQUAL(subport, SUBPORT, "Wrong subport\n");
--
2.17.1
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v3 2/2] mbuf: implement generic format for sched field
2018-12-13 18:08 ` [dpdk-dev] [PATCH v3 2/2] mbuf: implement generic format for sched field Reshma Pattan
@ 2018-12-14 22:52 ` Dumitrescu, Cristian
2018-12-20 8:32 ` Olivier Matz
0 siblings, 1 reply; 74+ messages in thread
From: Dumitrescu, Cristian @ 2018-12-14 22:52 UTC (permalink / raw)
To: Pattan, Reshma, dev, jerin.jacob, Rao, Nikhil, Singh, Jasvinder
> -----Original Message-----
> From: Pattan, Reshma
> Sent: Thursday, December 13, 2018 6:09 PM
> To: dev@dpdk.org; jerin.jacob@caviumnetworks.com; Rao, Nikhil
> <nikhil.rao@intel.com>; Singh, Jasvinder <jasvinder.singh@intel.com>;
> Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> Cc: Pattan, Reshma <reshma.pattan@intel.com>
> Subject: [PATCH v3 2/2] mbuf: implement generic format for sched field
>
> This patch implements the changes proposed in the deprecation
> notes [1][2].
>
> librte_mbuf changes:
> The mbuf::hash::sched field is updated to support generic
> definition in line with the ethdev TM and MTR APIs. The new generic
> format contains: queue ID, traffic class, color.
>
> Added public APIs to set and get these new fields to and from mbuf.
>
> librte_sched changes:
> In addtion, following API functions of the sched library have
> been modified with an additional parameter of type struct
> rte_sched_port to accommodate the changes made to mbuf sched field.
> (i) rte_sched_port_pkt_write()
> (ii) rte_sched_port_pkt_read_tree_path()
>
> librte_pipeline, qos_sched UT, qos_sched app are updated
> to make use of new changes.
>
> Also mbuf::hash::txadapter has been added for eventdev txq,
> rte_event_eth_tx_adapter_txq_set and
> rte_event_eth_tx_adapter_txq_get()
> are updated to use uses mbuf::hash::txadapter.txq.
>
> doc:
> Release notes updated.
> Removed deprecation notice for mbuf::hash::sched and sched API.
>
> [1] http://mails.dpdk.org/archives/dev/2018-February/090651.html
> [2] https://mails.dpdk.org/archives/dev/2018-November/119051.html
>
> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
> Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> ---
> v3: addressed review comments given in the below link.
> http://patches.dpdk.org/patch/48587/
> Updated library ABI versioning in meson build.
> ---
> ---
> doc/guides/rel_notes/deprecation.rst | 10 --
> doc/guides/rel_notes/release_19_02.rst | 4 +-
> examples/qos_sched/app_thread.c | 7 +-
> examples/qos_sched/main.c | 1 +
> .../rte_event_eth_tx_adapter.h | 18 ++-
> lib/librte_mbuf/Makefile | 2 +-
> lib/librte_mbuf/meson.build | 2 +-
> lib/librte_mbuf/rte_mbuf.h | 114 +++++++++++++++++-
> lib/librte_pipeline/rte_table_action.c | 43 ++-----
> lib/librte_sched/Makefile | 2 +-
> lib/librte_sched/meson.build | 1 +
> lib/librte_sched/rte_sched.c | 90 ++++++--------
> lib/librte_sched/rte_sched.h | 10 +-
> test/test/test_sched.c | 9 +-
> 14 files changed, 191 insertions(+), 122 deletions(-)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> index b48486d36..60e081a54 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -49,16 +49,6 @@ Deprecation Notices
> structure would be made internal (or removed if all dependencies are
> cleared)
> in future releases.
>
> -* mbuf: The opaque ``mbuf->hash.sched`` field will be updated to support
> generic
> - definition in line with the ethdev TM and MTR APIs. Currently, this field
> - is defined in librte_sched in a non-generic way. The new generic format
> - will contain: queue ID, traffic class, color. Field size will not change.
> -
> -* sched: Some API functions will change prototype due to the above
> - deprecation note for mbuf->hash.sched, e.g.
> ``rte_sched_port_pkt_write()``
> - and ``rte_sched_port_pkt_read()`` will likely have an additional parameter
> - of type ``struct rte_sched_port``.
> -
> * mbuf: the macro ``RTE_MBUF_INDIRECT()`` will be removed in v18.08 or
> later and
> replaced with ``RTE_MBUF_CLONED()`` which is already added in v18.05. As
> ``EXT_ATTACHED_MBUF`` is newly introduced in v18.05,
> ``RTE_MBUF_INDIRECT()``
> diff --git a/doc/guides/rel_notes/release_19_02.rst
> b/doc/guides/rel_notes/release_19_02.rst
> index a94fa86a7..deadaafa9 100644
> --- a/doc/guides/rel_notes/release_19_02.rst
> +++ b/doc/guides/rel_notes/release_19_02.rst
> @@ -146,7 +146,7 @@ The libraries prepended with a plus sign were
> incremented in this version.
> librte_kvargs.so.1
> librte_latencystats.so.1
> librte_lpm.so.2
> - librte_mbuf.so.4
> + + librte_mbuf.so.5
> librte_member.so.1
> librte_mempool.so.5
> librte_meter.so.2
> @@ -168,7 +168,7 @@ The libraries prepended with a plus sign were
> incremented in this version.
> librte_rawdev.so.1
> librte_reorder.so.1
> librte_ring.so.2
> - librte_sched.so.1
> + + librte_sched.so.2
> librte_security.so.1
> librte_table.so.3
> librte_timer.so.1
> diff --git a/examples/qos_sched/app_thread.c
> b/examples/qos_sched/app_thread.c
> index a59274236..bec4deee3 100644
> --- a/examples/qos_sched/app_thread.c
> +++ b/examples/qos_sched/app_thread.c
> @@ -73,8 +73,11 @@ app_rx_thread(struct thread_conf **confs)
> for(i = 0; i < nb_rx; i++) {
> get_pkt_sched(rx_mbufs[i],
> &subport, &pipe,
> &traffic_class, &queue, &color);
> - rte_sched_port_pkt_write(rx_mbufs[i],
> subport, pipe,
> - traffic_class, queue, (enum
> rte_meter_color) color);
> + rte_sched_port_pkt_write(conf-
> >sched_port,
> + rx_mbufs[i],
> + subport, pipe,
> + traffic_class, queue,
> + (enum rte_meter_color)
> color);
> }
>
> if (unlikely(rte_ring_sp_enqueue_bulk(conf-
> >rx_ring,
> diff --git a/examples/qos_sched/main.c b/examples/qos_sched/main.c
> index e7c97bd64..c0ed16b68 100644
> --- a/examples/qos_sched/main.c
> +++ b/examples/qos_sched/main.c
> @@ -55,6 +55,7 @@ app_main_loop(__attribute__((unused))void *dummy)
> flow->rx_thread.rx_port = flow->rx_port;
> flow->rx_thread.rx_ring = flow->rx_ring;
> flow->rx_thread.rx_queue = flow->rx_queue;
> + flow->rx_thread.sched_port = flow->sched_port;
>
> rx_confs[rx_idx++] = &flow->rx_thread;
>
> diff --git a/lib/librte_eventdev/rte_event_eth_tx_adapter.h
> b/lib/librte_eventdev/rte_event_eth_tx_adapter.h
> index 81456d4a9..2a50656d9 100644
> --- a/lib/librte_eventdev/rte_event_eth_tx_adapter.h
> +++ b/lib/librte_eventdev/rte_event_eth_tx_adapter.h
> @@ -63,13 +63,11 @@
> * function can be used to retrieve the adapter's service function ID.
> *
> * The ethernet port and transmit queue index to transmit the mbuf on are
> - * specified using the mbuf port and the higher 16 bits of
> - * struct rte_mbuf::hash::sched:hi. The application should use the
> - * rte_event_eth_tx_adapter_txq_set() and
> rte_event_eth_tx_adapter_txq_get()
> - * functions to access the transmit queue index since it is expected that the
> - * transmit queue will be eventually defined within struct rte_mbuf and
> using
> - * these macros will help with minimizing application impact due to
> - * a change in how the transmit queue index is specified.
> + * specified using the mbuf port struct rte_mbuf::hash::txadapter:txq.
> + * The application should use the rte_event_eth_tx_adapter_txq_set()
> + * and rte_event_eth_tx_adapter_txq_get() functions to access the
> transmit
> + * queue index, using these macros will help with minimizing application
> + * impact due to a change in how the transmit queue index is specified.
> */
>
> #ifdef __cplusplus
> @@ -300,8 +298,7 @@ rte_event_eth_tx_adapter_queue_del(uint8_t id,
> static __rte_always_inline void __rte_experimental
> rte_event_eth_tx_adapter_txq_set(struct rte_mbuf *pkt, uint16_t queue)
> {
> - uint16_t *p = (uint16_t *)&pkt->hash.sched.hi;
> - p[1] = queue;
> + pkt->hash.txadapter.txq = queue;
> }
>
> /**
> @@ -320,8 +317,7 @@ rte_event_eth_tx_adapter_txq_set(struct rte_mbuf
> *pkt, uint16_t queue)
> static __rte_always_inline uint16_t __rte_experimental
> rte_event_eth_tx_adapter_txq_get(struct rte_mbuf *pkt)
> {
> - uint16_t *p = (uint16_t *)&pkt->hash.sched.hi;
> - return p[1];
> + return pkt->hash.txadapter.txq;
> }
>
> /**
> diff --git a/lib/librte_mbuf/Makefile b/lib/librte_mbuf/Makefile
> index e2b98a254..8c4c7d790 100644
> --- a/lib/librte_mbuf/Makefile
> +++ b/lib/librte_mbuf/Makefile
> @@ -11,7 +11,7 @@ LDLIBS += -lrte_eal -lrte_mempool
>
> EXPORT_MAP := rte_mbuf_version.map
>
> -LIBABIVER := 4
> +LIBABIVER := 5
>
> # all source are stored in SRCS-y
> SRCS-$(CONFIG_RTE_LIBRTE_MBUF) := rte_mbuf.c rte_mbuf_ptype.c
> rte_mbuf_pool_ops.c
> diff --git a/lib/librte_mbuf/meson.build b/lib/librte_mbuf/meson.build
> index 94d9c4c96..e37da0250 100644
> --- a/lib/librte_mbuf/meson.build
> +++ b/lib/librte_mbuf/meson.build
> @@ -1,7 +1,7 @@
> # SPDX-License-Identifier: BSD-3-Clause
> # Copyright(c) 2017 Intel Corporation
>
> -version = 4
> +version = 5
> sources = files('rte_mbuf.c', 'rte_mbuf_ptype.c', 'rte_mbuf_pool_ops.c')
> headers = files('rte_mbuf.h', 'rte_mbuf_ptype.h', 'rte_mbuf_pool_ops.h')
> deps += ['mempool']
> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> index 3dbc6695e..032237321 100644
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -34,6 +34,7 @@
> #include <stdint.h>
> #include <rte_compat.h>
> #include <rte_common.h>
> +#include <rte_color.h>
> #include <rte_config.h>
> #include <rte_mempool.h>
> #include <rte_memory.h>
> @@ -575,13 +576,24 @@ struct rte_mbuf {
> */
> } fdir; /**< Filter identifier if FDIR enabled */
> struct {
> - uint32_t lo;
> - uint32_t hi;
> + uint32_t queue_id; /**< Queue ID. */
> + uint8_t traffic_class;
> + /**< Traffic class ID. Traffic class 0
> + * is the highest priority traffic class.
> + */
> + uint8_t color;
> + /**< Color. @see enum rte_color.*/
> + uint16_t reserved; /**< Reserved. */
> + } sched; /**< Hierarchical scheduler */
New idea: let's make this an explicit struct rte_mbuf_sched that we instantiate here: struct rte_mbuf_sched sched;
> + struct {
> + uint32_t reserved1;
> + uint16_t reserved2;
> + uint16_t txq;
> /**< The event eth Tx adapter uses this field
> * to store Tx queue id.
> * @see
> rte_event_eth_tx_adapter_txq_set()
> */
> - } sched; /**< Hierarchical scheduler */
> + } txadapter; /**< Eventdev ethdev Tx adapter */
> /**< User defined tags. See
> rte_distributor_process() */
> uint32_t usr;
> } hash; /**< hash information */
> @@ -2289,6 +2301,102 @@ rte_pktmbuf_linearize(struct rte_mbuf *mbuf)
> */
> void rte_pktmbuf_dump(FILE *f, const struct rte_mbuf *m, unsigned
> dump_len);
>
> +/**
> + * Get the value of mbuf sched queue_id field.
> + */
> +static inline uint32_t
> +rte_mbuf_sched_queue_get(const struct rte_mbuf *m)
> +{
> + return m->hash.sched.queue_id;
> +}
> +
> +/**
> + * Get the value of mbuf sched traffic_class field.
> + */
> +static inline uint8_t
> +rte_mbuf_sched_traffic_class_get(const struct rte_mbuf *m)
> +{
> + return m->hash.sched.traffic_class;
> +}
> +
> +/**
> + * Get the value of mbuf sched color field.
> + */
> +static inline enum rte_color
> +rte_mbuf_sched_color_get(const struct rte_mbuf *m)
> +{
> + return (enum rte_color)m->hash.sched.color;
> +}
> +
> +/**
> + * Get the values of mbuf sched queue_id, traffic_class and color.
> + * @param m
> + * Mbuf to read
> + * @param queue_id
> + * Returns the queue id
> + * @param traffic_class
> + * Returns the traffic class id
> + * @param color
> + * Returns the colour id
> + */
> +static inline void
> +rte_mbuf_sched_get(const struct rte_mbuf *m, uint32_t *queue_id,
> + uint8_t *traffic_class,
> + enum rte_color *color)
> +{
> + *queue_id = m->hash.sched.queue_id;
> + *traffic_class = m->hash.sched.traffic_class;
> + *color = (enum rte_color)m->hash.sched.color;
For performance reasons, let's ask the compiler to read all sched fields in a single operation as opposed to 3:
struct rte_mbuf_sched sched = m->hash.sched;
*queue_id = sched.queue_id;
*traffic_class = sched.traffic_class;
*color = (enum rte_colo)sched.color;
> +}
> +
> +/**
> + * Set the mbuf sched queue_id to the defined value.
> + */
> +static inline void
> +rte_mbuf_sched_queue_set(struct rte_mbuf *m, uint32_t queue_id)
> +{
> + m->hash.sched.queue_id = queue_id;
> +}
> +
> +/**
> + * Set the mbuf sched traffic_class id to the defined value.
> + */
> +static inline void
> +rte_mbuf_sched_traffic_class_set(struct rte_mbuf *m, uint8_t
> traffic_class)
> +{
> + m->hash.sched.traffic_class = traffic_class;
> +}
> +
> +/**
> + * Set the mbuf sched color id to the defined value.
> + */
> +static inline void
> +rte_mbuf_sched_color_set(struct rte_mbuf *m, enum rte_color color)
> +{
> + m->hash.sched.color = (uint8_t)color;
> +}
> +
> +/**
> + * Set the mbuf sched queue_id, traffic_class and color.
> + * @param m
> + * Mbuf to set
> + * @param queue_id
> + * Queue id value to be set
> + * @param traffic_class
> + * Traffic class id value to be set
> + * @param color
> + * Color id to be set
> + */
> +static inline void
> +rte_mbuf_sched_set(struct rte_mbuf *m, uint32_t queue_id,
> + uint8_t traffic_class,
> + enum rte_color color)
> +{
> + m->hash.sched.queue_id = queue_id;
> + m->hash.sched.traffic_class = traffic_class;
> + m->hash.sched.color = (uint8_t)color;
For performance reasons, let's combine all writes in a single access:
m->hash.sched = (struct rte_mbuf_sched){
.queue_id = queue_id,
.traffic_class = traffic_class,
.color = (uint8_t)color,
};
> +}
> +
> #ifdef __cplusplus
> }
> #endif
> diff --git a/lib/librte_pipeline/rte_table_action.c
> b/lib/librte_pipeline/rte_table_action.c
> index 7c7c8dd82..3158301ff 100644
> --- a/lib/librte_pipeline/rte_table_action.c
> +++ b/lib/librte_pipeline/rte_table_action.c
> @@ -107,14 +107,6 @@ mtr_cfg_check(struct rte_table_action_mtr_config
> *mtr)
> return 0;
> }
>
> -#define MBUF_SCHED_QUEUE_TC_COLOR(queue, tc, color) \
> - ((uint16_t)((((uint64_t)(queue)) & 0x3) | \
> - ((((uint64_t)(tc)) & 0x3) << 2) | \
> - ((((uint64_t)(color)) & 0x3) << 4)))
> -
> -#define MBUF_SCHED_COLOR(sched, color) \
> - (((sched) & (~0x30LLU)) | ((color) << 4))
> -
> struct mtr_trtcm_data {
> struct rte_meter_trtcm trtcm;
> uint64_t stats[e_RTE_METER_COLORS];
> @@ -176,7 +168,7 @@ mtr_data_size(struct rte_table_action_mtr_config
> *mtr)
> struct dscp_table_entry_data {
> enum rte_meter_color color;
> uint16_t tc;
> - uint16_t queue_tc_color;
> + uint16_t tc_queue;
> };
>
> struct dscp_table_data {
> @@ -319,8 +311,7 @@ pkt_work_mtr(struct rte_mbuf *mbuf,
> uint32_t dscp,
> uint16_t total_length)
> {
> - uint64_t drop_mask, sched;
> - uint64_t *sched_ptr = (uint64_t *) &mbuf->hash.sched;
> + uint64_t drop_mask;
> struct dscp_table_entry_data *dscp_entry = &dscp_table-
> >entry[dscp];
> enum rte_meter_color color_in, color_meter, color_policer;
> uint32_t tc, mp_id;
> @@ -329,7 +320,6 @@ pkt_work_mtr(struct rte_mbuf *mbuf,
> color_in = dscp_entry->color;
> data += tc;
> mp_id = MTR_TRTCM_DATA_METER_PROFILE_ID_GET(data);
> - sched = *sched_ptr;
>
> /* Meter */
> color_meter = rte_meter_trtcm_color_aware_check(
> @@ -346,7 +336,7 @@ pkt_work_mtr(struct rte_mbuf *mbuf,
> drop_mask =
> MTR_TRTCM_DATA_POLICER_ACTION_DROP_GET(data, color_meter);
> color_policer =
> MTR_TRTCM_DATA_POLICER_ACTION_COLOR_GET(data,
> color_meter);
> - *sched_ptr = MBUF_SCHED_COLOR(sched, color_policer);
> + rte_mbuf_sched_color_set(mbuf, color_policer);
>
> return drop_mask;
> }
> @@ -368,9 +358,8 @@ tm_cfg_check(struct rte_table_action_tm_config
> *tm)
> }
>
> struct tm_data {
> - uint16_t queue_tc_color;
> - uint16_t subport;
> - uint32_t pipe;
> + uint32_t queue_id;
> + uint32_t reserved;
> } __attribute__((__packed__));
>
> static int
> @@ -397,9 +386,9 @@ tm_apply(struct tm_data *data,
> return status;
>
> /* Apply */
> - data->queue_tc_color = 0;
> - data->subport = (uint16_t) p->subport_id;
> - data->pipe = p->pipe_id;
> + data->queue_id = p->subport_id <<
> + (__builtin_ctz(cfg->n_pipes_per_subport) +
> 4) |
> + p->pipe_id << 4;
>
> return 0;
> }
> @@ -411,12 +400,10 @@ pkt_work_tm(struct rte_mbuf *mbuf,
> uint32_t dscp)
> {
> struct dscp_table_entry_data *dscp_entry = &dscp_table-
> >entry[dscp];
> - struct tm_data *sched_ptr = (struct tm_data *) &mbuf->hash.sched;
> - struct tm_data sched;
> -
> - sched = *data;
> - sched.queue_tc_color = dscp_entry->queue_tc_color;
> - *sched_ptr = sched;
> + uint32_t queue_id = data->queue_id |
> + (dscp_entry->tc << 2) |
> + dscp_entry->tc_queue;
> + rte_mbuf_sched_set(mbuf, queue_id, dscp_entry->tc, dscp_entry-
> >color);
> }
>
> /**
> @@ -2580,17 +2567,13 @@ rte_table_action_dscp_table_update(struct
> rte_table_action *action,
> &action->dscp_table.entry[i];
> struct rte_table_action_dscp_table_entry *entry =
> &table->entry[i];
> - uint16_t queue_tc_color =
> - MBUF_SCHED_QUEUE_TC_COLOR(entry-
> >tc_queue_id,
> - entry->tc_id,
> - entry->color);
>
> if ((dscp_mask & (1LLU << i)) == 0)
> continue;
>
> data->color = entry->color;
> data->tc = entry->tc_id;
> - data->queue_tc_color = queue_tc_color;
> + data->tc_queue = entry->tc_queue_id;
> }
>
> return 0;
> diff --git a/lib/librte_sched/Makefile b/lib/librte_sched/Makefile
> index 46c53ed71..644fd9d15 100644
> --- a/lib/librte_sched/Makefile
> +++ b/lib/librte_sched/Makefile
> @@ -18,7 +18,7 @@ LDLIBS += -lrte_timer
>
> EXPORT_MAP := rte_sched_version.map
>
> -LIBABIVER := 1
> +LIBABIVER := 2
>
> #
> # all source are stored in SRCS-y
> diff --git a/lib/librte_sched/meson.build b/lib/librte_sched/meson.build
> index f85d64df8..8e989e5f6 100644
> --- a/lib/librte_sched/meson.build
> +++ b/lib/librte_sched/meson.build
> @@ -1,6 +1,7 @@
> # SPDX-License-Identifier: BSD-3-Clause
> # Copyright(c) 2017 Intel Corporation
>
> +version = 2
> sources = files('rte_sched.c', 'rte_red.c', 'rte_approx.c')
> headers = files('rte_sched.h', 'rte_sched_common.h',
> 'rte_red.h', 'rte_approx.h')
> diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c
> index 587d5e602..3b8b2b038 100644
> --- a/lib/librte_sched/rte_sched.c
> +++ b/lib/librte_sched/rte_sched.c
> @@ -128,22 +128,6 @@ enum grinder_state {
> e_GRINDER_READ_MBUF
> };
>
> -/*
> - * Path through the scheduler hierarchy used by the scheduler enqueue
> - * operation to identify the destination queue for the current
> - * packet. Stored in the field pkt.hash.sched of struct rte_mbuf of
> - * each packet, typically written by the classification stage and read
> - * by scheduler enqueue.
> - */
> -struct rte_sched_port_hierarchy {
> - uint16_t queue:2; /**< Queue ID (0 .. 3) */
> - uint16_t traffic_class:2; /**< Traffic class ID (0 .. 3)*/
> - uint32_t color:2; /**< Color */
> - uint16_t unused:10;
> - uint16_t subport; /**< Subport ID */
> - uint32_t pipe; /**< Pipe ID */
> -};
> -
> struct rte_sched_grinder {
> /* Pipe cache */
> uint16_t pcache_qmask[RTE_SCHED_GRINDER_PCACHE_SIZE];
> @@ -185,6 +169,7 @@ struct rte_sched_port {
> /* User parameters */
> uint32_t n_subports_per_port;
> uint32_t n_pipes_per_subport;
> + uint32_t n_pipes_per_subport_log2;
> uint32_t rate;
> uint32_t mtu;
> uint32_t frame_overhead;
> @@ -645,6 +630,8 @@ rte_sched_port_config(struct
> rte_sched_port_params *params)
> /* User parameters */
> port->n_subports_per_port = params->n_subports_per_port;
> port->n_pipes_per_subport = params->n_pipes_per_subport;
> + port->n_pipes_per_subport_log2 =
> + __builtin_ctz(params->n_pipes_per_subport);
> port->rate = params->rate;
> port->mtu = params->mtu + params->frame_overhead;
> port->frame_overhead = params->frame_overhead;
> @@ -1006,44 +993,52 @@ rte_sched_port_pipe_profile_add(struct
> rte_sched_port *port,
> return 0;
> }
>
> +static inline uint32_t
> +rte_sched_port_qindex(struct rte_sched_port *port,
> + uint32_t subport,
> + uint32_t pipe,
> + uint32_t traffic_class,
> + uint32_t queue)
> +{
> + return ((subport & (port->n_subports_per_port - 1)) <<
> + (port->n_pipes_per_subport_log2 + 4)) |
> + ((pipe & (port->n_pipes_per_subport - 1)) << 4) |
> + ((traffic_class &
> + (RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE - 1)) <<
> 2) |
> + (queue &
> (RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS - 1));
> +}
> +
> void
> -rte_sched_port_pkt_write(struct rte_mbuf *pkt,
> - uint32_t subport, uint32_t pipe, uint32_t
> traffic_class,
> +rte_sched_port_pkt_write(struct rte_sched_port *port,
> + struct rte_mbuf *pkt,
> + uint32_t subport, uint32_t pipe,
> + uint32_t traffic_class,
> uint32_t queue, enum rte_meter_color color)
> {
> - struct rte_sched_port_hierarchy *sched
> - = (struct rte_sched_port_hierarchy *) &pkt->hash.sched;
> -
> - RTE_BUILD_BUG_ON(sizeof(*sched) > sizeof(pkt->hash.sched));
> -
> - sched->color = (uint32_t) color;
> - sched->subport = subport;
> - sched->pipe = pipe;
> - sched->traffic_class = traffic_class;
> - sched->queue = queue;
> + uint32_t queue_id = rte_sched_port_qindex(port, subport, pipe,
> + traffic_class, queue);
> + rte_mbuf_sched_set(pkt, queue_id, traffic_class, (enum
> rte_color)color);
> }
>
> void
> -rte_sched_port_pkt_read_tree_path(const struct rte_mbuf *pkt,
> +rte_sched_port_pkt_read_tree_path(struct rte_sched_port *port,
> + const struct rte_mbuf *pkt,
> uint32_t *subport, uint32_t *pipe,
> uint32_t *traffic_class, uint32_t *queue)
> {
> - const struct rte_sched_port_hierarchy *sched
> - = (const struct rte_sched_port_hierarchy *) &pkt-
> >hash.sched;
> + uint32_t queue_id = rte_mbuf_sched_queue_get(pkt);
>
> - *subport = sched->subport;
> - *pipe = sched->pipe;
> - *traffic_class = sched->traffic_class;
> - *queue = sched->queue;
> + *subport = queue_id >> (port->n_pipes_per_subport_log2 + 4);
> + *pipe = (queue_id >> 4) & (port->n_pipes_per_subport - 1);
> + *traffic_class = (queue_id >> 2) &
> + (RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE -
> 1);
> + *queue = queue_id & (RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS -
> 1);
> }
>
> enum rte_meter_color
> rte_sched_port_pkt_read_color(const struct rte_mbuf *pkt)
> {
> - const struct rte_sched_port_hierarchy *sched
> - = (const struct rte_sched_port_hierarchy *) &pkt-
> >hash.sched;
> -
> - return (enum rte_meter_color) sched->color;
> + return (enum rte_meter_color)rte_mbuf_sched_color_get(pkt);
No need to convert to enum, as this function return value is already of enum type.
> }
>
> int
> @@ -1100,18 +1095,6 @@ rte_sched_queue_read_stats(struct
> rte_sched_port *port,
> return 0;
> }
>
> -static inline uint32_t
> -rte_sched_port_qindex(struct rte_sched_port *port, uint32_t subport,
> uint32_t pipe, uint32_t traffic_class, uint32_t queue)
> -{
> - uint32_t result;
> -
> - result = subport * port->n_pipes_per_subport + pipe;
> - result = result * RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE +
> traffic_class;
> - result = result * RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS + queue;
> -
> - return result;
> -}
> -
> #ifdef RTE_SCHED_DEBUG
>
> static inline int
> @@ -1272,11 +1255,8 @@ rte_sched_port_enqueue_qptrs_prefetch0(struct
> rte_sched_port *port,
> #ifdef RTE_SCHED_COLLECT_STATS
> struct rte_sched_queue_extra *qe;
> #endif
> - uint32_t subport, pipe, traffic_class, queue, qindex;
> -
> - rte_sched_port_pkt_read_tree_path(pkt, &subport, &pipe,
> &traffic_class, &queue);
> + uint32_t qindex = rte_mbuf_sched_queue_get(pkt);
>
> - qindex = rte_sched_port_qindex(port, subport, pipe, traffic_class,
> queue);
> q = port->queue + qindex;
> rte_prefetch0(q);
> #ifdef RTE_SCHED_COLLECT_STATS
> diff --git a/lib/librte_sched/rte_sched.h b/lib/librte_sched/rte_sched.h
> index 84fa896de..243efa1d4 100644
> --- a/lib/librte_sched/rte_sched.h
> +++ b/lib/librte_sched/rte_sched.h
> @@ -355,6 +355,8 @@ rte_sched_queue_read_stats(struct rte_sched_port
> *port,
> * Scheduler hierarchy path write to packet descriptor. Typically
> * called by the packet classification stage.
> *
> + * @param port
> + * Handle to port scheduler instance
> * @param pkt
> * Packet descriptor handle
> * @param subport
> @@ -369,7 +371,8 @@ rte_sched_queue_read_stats(struct rte_sched_port
> *port,
> * Packet color set
> */
> void
> -rte_sched_port_pkt_write(struct rte_mbuf *pkt,
> +rte_sched_port_pkt_write(struct rte_sched_port *port,
> + struct rte_mbuf *pkt,
> uint32_t subport, uint32_t pipe, uint32_t
> traffic_class,
> uint32_t queue, enum rte_meter_color color);
>
> @@ -379,6 +382,8 @@ rte_sched_port_pkt_write(struct rte_mbuf *pkt,
> * enqueue operation. The subport, pipe, traffic class and queue
> * parameters need to be pre-allocated by the caller.
> *
> + * @param port
> + * Handle to port scheduler instance
> * @param pkt
> * Packet descriptor handle
> * @param subport
> @@ -392,7 +397,8 @@ rte_sched_port_pkt_write(struct rte_mbuf *pkt,
> *
> */
> void
> -rte_sched_port_pkt_read_tree_path(const struct rte_mbuf *pkt,
> +rte_sched_port_pkt_read_tree_path(struct rte_sched_port *port,
> + const struct rte_mbuf *pkt,
> uint32_t *subport, uint32_t *pipe,
> uint32_t *traffic_class, uint32_t *queue);
>
> diff --git a/test/test/test_sched.c b/test/test/test_sched.c
> index 32e500ba9..40e411cab 100644
> --- a/test/test/test_sched.c
> +++ b/test/test/test_sched.c
> @@ -76,7 +76,7 @@ create_mempool(void)
> }
>
> static void
> -prepare_pkt(struct rte_mbuf *mbuf)
> +prepare_pkt(struct rte_sched_port *port, struct rte_mbuf *mbuf)
> {
> struct ether_hdr *eth_hdr;
> struct vlan_hdr *vlan1, *vlan2;
> @@ -95,7 +95,8 @@ prepare_pkt(struct rte_mbuf *mbuf)
> ip_hdr->dst_addr = IPv4(0,0,TC,QUEUE);
>
>
> - rte_sched_port_pkt_write(mbuf, SUBPORT, PIPE, TC, QUEUE,
> e_RTE_METER_YELLOW);
> + rte_sched_port_pkt_write(port, mbuf, SUBPORT, PIPE, TC, QUEUE,
> + e_RTE_METER_YELLOW);
>
> /* 64 byte packet */
> mbuf->pkt_len = 60;
> @@ -138,7 +139,7 @@ test_sched(void)
> for (i = 0; i < 10; i++) {
> in_mbufs[i] = rte_pktmbuf_alloc(mp);
> TEST_ASSERT_NOT_NULL(in_mbufs[i], "Packet allocation
> failed\n");
> - prepare_pkt(in_mbufs[i]);
> + prepare_pkt(port, in_mbufs[i]);
> }
>
>
> @@ -155,7 +156,7 @@ test_sched(void)
> color = rte_sched_port_pkt_read_color(out_mbufs[i]);
> TEST_ASSERT_EQUAL(color, e_RTE_METER_YELLOW, "Wrong
> color\n");
>
> - rte_sched_port_pkt_read_tree_path(out_mbufs[i],
> + rte_sched_port_pkt_read_tree_path(port, out_mbufs[i],
> &subport, &pipe, &traffic_class, &queue);
>
> TEST_ASSERT_EQUAL(subport, SUBPORT, "Wrong
> subport\n");
> --
> 2.17.1
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v3 2/2] mbuf: implement generic format for sched field
2018-12-14 22:52 ` Dumitrescu, Cristian
@ 2018-12-20 8:32 ` Olivier Matz
2018-12-20 11:19 ` Dumitrescu, Cristian
0 siblings, 1 reply; 74+ messages in thread
From: Olivier Matz @ 2018-12-20 8:32 UTC (permalink / raw)
To: Dumitrescu, Cristian
Cc: Pattan, Reshma, dev, jerin.jacob, Rao, Nikhil, Singh, Jasvinder
Hi Cristian,
On Fri, Dec 14, 2018 at 10:52:18PM +0000, Dumitrescu, Cristian wrote:
> > --- a/lib/librte_mbuf/rte_mbuf.h
> > +++ b/lib/librte_mbuf/rte_mbuf.h
> > @@ -34,6 +34,7 @@
> > #include <stdint.h>
> > #include <rte_compat.h>
> > #include <rte_common.h>
> > +#include <rte_color.h>
> > #include <rte_config.h>
> > #include <rte_mempool.h>
> > #include <rte_memory.h>
> > @@ -575,13 +576,24 @@ struct rte_mbuf {
> > */
> > } fdir; /**< Filter identifier if FDIR enabled */
> > struct {
> > - uint32_t lo;
> > - uint32_t hi;
> > + uint32_t queue_id; /**< Queue ID. */
> > + uint8_t traffic_class;
> > + /**< Traffic class ID. Traffic class 0
> > + * is the highest priority traffic class.
> > + */
> > + uint8_t color;
> > + /**< Color. @see enum rte_color.*/
> > + uint16_t reserved; /**< Reserved. */
> > + } sched; /**< Hierarchical scheduler */
>
> New idea: let's make this an explicit struct rte_mbuf_sched that we instantiate here: struct rte_mbuf_sched sched;
Sorry, I don't really agree here. I think having it inside the mbuf
struct helps to estimate the size of the union here, and it would be
less consistent with other fields.
[...]
> > +/**
> > + * Get the values of mbuf sched queue_id, traffic_class and color.
> > + * @param m
> > + * Mbuf to read
> > + * @param queue_id
> > + * Returns the queue id
> > + * @param traffic_class
> > + * Returns the traffic class id
> > + * @param color
> > + * Returns the colour id
> > + */
> > +static inline void
> > +rte_mbuf_sched_get(const struct rte_mbuf *m, uint32_t *queue_id,
> > + uint8_t *traffic_class,
> > + enum rte_color *color)
> > +{
> > + *queue_id = m->hash.sched.queue_id;
> > + *traffic_class = m->hash.sched.traffic_class;
> > + *color = (enum rte_color)m->hash.sched.color;
>
> For performance reasons, let's ask the compiler to read all sched fields in a single operation as opposed to 3:
>
> struct rte_mbuf_sched sched = m->hash.sched;
> *queue_id = sched.queue_id;
> *traffic_class = sched.traffic_class;
> *color = (enum rte_colo)sched.color;
Are you sure it would me more efficient?
Thanks,
Olivier
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v3 2/2] mbuf: implement generic format for sched field
2018-12-20 8:32 ` Olivier Matz
@ 2018-12-20 11:19 ` Dumitrescu, Cristian
0 siblings, 0 replies; 74+ messages in thread
From: Dumitrescu, Cristian @ 2018-12-20 11:19 UTC (permalink / raw)
To: Olivier Matz
Cc: Pattan, Reshma, dev, jerin.jacob, Rao, Nikhil, Singh, Jasvinder
Hi Olivier,
Thanks for your comments.
> -----Original Message-----
> From: Olivier Matz [mailto:olivier.matz@6wind.com]
> Sent: Thursday, December 20, 2018 8:33 AM
> To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> Cc: Pattan, Reshma <reshma.pattan@intel.com>; dev@dpdk.org;
> jerin.jacob@caviumnetworks.com; Rao, Nikhil <nikhil.rao@intel.com>; Singh,
> Jasvinder <jasvinder.singh@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v3 2/2] mbuf: implement generic format for
> sched field
>
> Hi Cristian,
>
> On Fri, Dec 14, 2018 at 10:52:18PM +0000, Dumitrescu, Cristian wrote:
> > > --- a/lib/librte_mbuf/rte_mbuf.h
> > > +++ b/lib/librte_mbuf/rte_mbuf.h
> > > @@ -34,6 +34,7 @@
> > > #include <stdint.h>
> > > #include <rte_compat.h>
> > > #include <rte_common.h>
> > > +#include <rte_color.h>
> > > #include <rte_config.h>
> > > #include <rte_mempool.h>
> > > #include <rte_memory.h>
> > > @@ -575,13 +576,24 @@ struct rte_mbuf {
> > > */
> > > } fdir; /**< Filter identifier if FDIR enabled */
> > > struct {
> > > - uint32_t lo;
> > > - uint32_t hi;
> > > + uint32_t queue_id; /**< Queue ID. */
> > > + uint8_t traffic_class;
> > > + /**< Traffic class ID. Traffic class 0
> > > + * is the highest priority traffic class.
> > > + */
> > > + uint8_t color;
> > > + /**< Color. @see enum rte_color.*/
> > > + uint16_t reserved; /**< Reserved. */
> > > + } sched; /**< Hierarchical scheduler */
> >
> > New idea: let's make this an explicit struct rte_mbuf_sched that we
> instantiate here: struct rte_mbuf_sched sched;
>
> Sorry, I don't really agree here. I think having it inside the mbuf
> struct helps to estimate the size of the union here, and it would be
> less consistent with other fields.
>
All I need is a name for this structure that I can use in some other parts of the code, i.e. for the set/get functions below.
I am not sure if we can declare and also instantiate this structure within the mbuf structure to fit bot my need and your preference. Basically, I am not sure if syntax like this is legal in C language; if it is, it would fit both purposes:
struct rte_mbuf {
...
struct rte_mbuf_sched {
...
} sched;
...
};
Would this syntax limit the scope of struct rte_mbuf_sched just to within the struct rte_mbuf?
>
> [...]
>
> > > +/**
> > > + * Get the values of mbuf sched queue_id, traffic_class and color.
> > > + * @param m
> > > + * Mbuf to read
> > > + * @param queue_id
> > > + * Returns the queue id
> > > + * @param traffic_class
> > > + * Returns the traffic class id
> > > + * @param color
> > > + * Returns the colour id
> > > + */
> > > +static inline void
> > > +rte_mbuf_sched_get(const struct rte_mbuf *m, uint32_t *queue_id,
> > > + uint8_t *traffic_class,
> > > + enum rte_color *color)
> > > +{
> > > + *queue_id = m->hash.sched.queue_id;
> > > + *traffic_class = m->hash.sched.traffic_class;
> > > + *color = (enum rte_color)m->hash.sched.color;
> >
> > For performance reasons, let's ask the compiler to read all sched fields in a
> single operation as opposed to 3:
> >
> > struct rte_mbuf_sched sched = m->hash.sched;
> > *queue_id = sched.queue_id;
> > *traffic_class = sched.traffic_class;
> > *color = (enum rte_colo)sched.color;
>
> Are you sure it would me more efficient?
Yes, this is one of the reasons: this structure is 8-byte in size and this function is used in performance critical actions, so we need to read this structure in a single 8-byte read operation (my proposal) as opposed to compiler generating 3 separate read operations. Makes sense?
Same for the rte_mbuf_sched_set() function.
>
>
> Thanks,
> Olivier
Regards,
Cristian
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [dpdk-dev] [PATCH v3 1/2] eal: add new rte color definition
2018-12-13 18:08 ` [dpdk-dev] [PATCH v3 1/2] eal: add new rte color definition Reshma Pattan
2018-12-13 18:08 ` [dpdk-dev] [PATCH v3 2/2] mbuf: implement generic format for sched field Reshma Pattan
@ 2018-12-14 22:19 ` Dumitrescu, Cristian
2018-12-17 20:35 ` Thomas Monjalon
2018-12-18 15:40 ` [dpdk-dev] [PATCH v4 1/2] meter: " Reshma Pattan
3 siblings, 0 replies; 74+ messages in thread
From: Dumitrescu, Cristian @ 2018-12-14 22:19 UTC (permalink / raw)
To: Pattan, Reshma, dev, jerin.jacob, Rao, Nikhil, Singh, Jasvinder
> -----Original Message-----
> From: Pattan, Reshma
> Sent: Thursday, December 13, 2018 6:09 PM
> To: dev@dpdk.org; jerin.jacob@caviumnetworks.com; Rao, Nikhil
> <nikhil.rao@intel.com>; Singh, Jasvinder <jasvinder.singh@intel.com>;
> Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> Cc: Pattan, Reshma <reshma.pattan@intel.com>
> Subject: [PATCH v3 1/2] eal: add new rte color definition
>
> Added new rte_color definition in eal to
> consolidate color definition which is currently replicated
> in various places such as rte_meter.h, rte_tm.h and rte_mtr.h
>
> Created aliases for rte_tm_color, rte_mtr_color and rte_meter_color
> to use new rte_color values.
>
> The definitions of rte_tm_color, rte_mtr_color and rte_meter_color
> will be deprecated in future.
>
> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
> Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> ---
> v2: Addressed review comments given in the below link
> http://patches.dpdk.org/patch/48588/
> Added rte_color.h to meson build.
> ---
> ---
> lib/librte_eal/common/Makefile | 2 +-
> lib/librte_eal/common/include/rte_color.h | 26
> +++++++++++++++++++++++
> lib/librte_eal/common/meson.build | 1 +
> lib/librte_ethdev/rte_mtr.h | 8 +++++++
> lib/librte_ethdev/rte_tm.h | 8 +++++++
> lib/librte_meter/rte_meter.h | 8 +++++++
> 6 files changed, 52 insertions(+), 1 deletion(-)
> create mode 100644 lib/librte_eal/common/include/rte_color.h
>
> diff --git a/lib/librte_eal/common/Makefile
> b/lib/librte_eal/common/Makefile
> index 87d8c455d..c76bb2dd7 100644
> --- a/lib/librte_eal/common/Makefile
> +++ b/lib/librte_eal/common/Makefile
> @@ -17,7 +17,7 @@ INC += rte_pci_dev_feature_defs.h
> rte_pci_dev_features.h
> INC += rte_malloc.h rte_keepalive.h rte_time.h
> INC += rte_service.h rte_service_component.h
> INC += rte_bitmap.h rte_vfio.h rte_hypervisor.h rte_test.h
> -INC += rte_reciprocal.h rte_fbarray.h rte_uuid.h
> +INC += rte_reciprocal.h rte_fbarray.h rte_uuid.h rte_color.h
>
> GENERIC_INC := rte_atomic.h rte_byteorder.h rte_cycles.h rte_prefetch.h
> GENERIC_INC += rte_spinlock.h rte_memcpy.h rte_cpuflags.h rte_rwlock.h
> diff --git a/lib/librte_eal/common/include/rte_color.h
> b/lib/librte_eal/common/include/rte_color.h
> new file mode 100644
> index 000000000..fafe1146d
> --- /dev/null
> +++ b/lib/librte_eal/common/include/rte_color.h
> @@ -0,0 +1,26 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(c) 2018 Intel Corporation
> + */
> +
> +#ifndef __INCLUDE_RTE_COLOR_H__
> +#define __INCLUDE_RTE_COLOR_H__
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +/**
> + * Color
> + */
> +enum rte_color {
> + RTE_COLOR_GREEN = 0, /**< Green */
> + RTE_COLOR_YELLOW, /**< Yellow */
> + RTE_COLOR_RED, /**< Red */
> + RTE_COLORS /**< Number of colors */
> +};
> +
> +#ifdef __cplusplus
> +}
> +#endif
> +
> +#endif /* __RTE_COLOR_H__ */
> diff --git a/lib/librte_eal/common/meson.build
> b/lib/librte_eal/common/meson.build
> index 2a10d57d8..f0a561f21 100644
> --- a/lib/librte_eal/common/meson.build
> +++ b/lib/librte_eal/common/meson.build
> @@ -52,6 +52,7 @@ common_headers = files(
> 'include/rte_bus.h',
> 'include/rte_bitmap.h',
> 'include/rte_class.h',
> + 'include/rte_color.h',
> 'include/rte_common.h',
> 'include/rte_debug.h',
> 'include/rte_devargs.h',
> diff --git a/lib/librte_ethdev/rte_mtr.h b/lib/librte_ethdev/rte_mtr.h
> index c4819b274..1de20ef2b 100644
> --- a/lib/librte_ethdev/rte_mtr.h
> +++ b/lib/librte_ethdev/rte_mtr.h
> @@ -76,6 +76,7 @@
> #include <stdint.h>
> #include <rte_compat.h>
> #include <rte_common.h>
> +#include <rte_color.h>
>
> #ifdef __cplusplus
> extern "C" {
> @@ -91,6 +92,13 @@ enum rte_mtr_color {
> RTE_MTR_COLORS /**< Number of colors. */
> };
>
> +/* New rte_color is defined and used to deprecate rte_mtr_color soon. */
> +#define rte_mtr_color rte_color
> +#define RTE_MTR_GREEN RTE_COLOR_GREEN
> +#define RTE_MTR_YELLOW RTE_COLOR_YELLOW
> +#define RTE_MTR_RED RTE_COLOR_RED
> +#define RTE_MTR_COLORS RTE_COLORS
> +
> /**
> * Statistics counter type
> */
> diff --git a/lib/librte_ethdev/rte_tm.h b/lib/librte_ethdev/rte_tm.h
> index 646ef3880..cce8230b6 100644
> --- a/lib/librte_ethdev/rte_tm.h
> +++ b/lib/librte_ethdev/rte_tm.h
> @@ -51,6 +51,7 @@
> #include <stdint.h>
>
> #include <rte_common.h>
> +#include <rte_color.h>
>
> #ifdef __cplusplus
> extern "C" {
> @@ -125,6 +126,13 @@ enum rte_tm_color {
> RTE_TM_COLORS /**< Number of colors */
> };
>
> +/* New rte_color is defined and used to deprecate rte_tm_color soon. */
> +#define rte_tm_color rte_color
> +#define RTE_TM_GREEN RTE_COLOR_GREEN
> +#define RTE_TM_YELLOW RTE_COLOR_YELLOW
> +#define RTE_TM_RED RTE_COLOR_RED
> +#define RTE_TM_COLORS RTE_COLORS
> +
> /**
> * Node statistics counter type
> */
> diff --git a/lib/librte_meter/rte_meter.h b/lib/librte_meter/rte_meter.h
> index 58a051583..e8d878b12 100644
> --- a/lib/librte_meter/rte_meter.h
> +++ b/lib/librte_meter/rte_meter.h
> @@ -21,6 +21,7 @@ extern "C" {
>
> #include <stdint.h>
>
> +#include <rte_color.h>
> /*
> * Application Programmer's Interface (API)
> *
> @@ -34,6 +35,13 @@ enum rte_meter_color {
> e_RTE_METER_COLORS /**< Number of available colors */
> };
>
> +/* New rte_color is defined and used to deprecate rte_meter_color soon.
> */
> +#define rte_meter_color rte_color
> +#define e_RTE_METER_GREEN RTE_COLOR_GREEN
> +#define e_RTE_METER_YELLOW RTE_COLOR_YELLOW
> +#define e_RTE_METER_RED RTE_COLOR_RED
> +#define e_RTE_METER_COLORS RTE_COLORS
> +
> /** srTCM parameters per metered traffic flow. The CIR, CBS and EBS
> parameters only
> count bytes of IP packets and do not include link specific headers. At least
> one of
> the CBS or EBS parameters has to be greater than zero. */
> --
> 2.17.1
This makes sense to me, but you need to remove the definitions of the existing enums (rte_mtr_color, rte_tm_color, rte_meter_color) first, otherwise what is the purpose of aliasing them to the new rte_color enum through the above macros?
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v3 1/2] eal: add new rte color definition
2018-12-13 18:08 ` [dpdk-dev] [PATCH v3 1/2] eal: add new rte color definition Reshma Pattan
2018-12-13 18:08 ` [dpdk-dev] [PATCH v3 2/2] mbuf: implement generic format for sched field Reshma Pattan
2018-12-14 22:19 ` [dpdk-dev] [PATCH v3 1/2] eal: add new rte color definition Dumitrescu, Cristian
@ 2018-12-17 20:35 ` Thomas Monjalon
2018-12-18 15:40 ` [dpdk-dev] [PATCH v4 1/2] meter: " Reshma Pattan
3 siblings, 0 replies; 74+ messages in thread
From: Thomas Monjalon @ 2018-12-17 20:35 UTC (permalink / raw)
To: Reshma Pattan
Cc: dev, jerin.jacob, nikhil.rao, jasvinder.singh,
cristian.dumitrescu, ferruh.yigit, arybchenko
13/12/2018 19:08, Reshma Pattan:
> Added new rte_color definition in eal to
> consolidate color definition which is currently replicated
> in various places such as rte_meter.h, rte_tm.h and rte_mtr.h
I don't think EAL is the right place for such definition.
Why ethdev would not rely on definitions from rte_meter.h?
^ permalink raw reply [flat|nested] 74+ messages in thread
* [dpdk-dev] [PATCH v4 1/2] meter: add new rte color definition
2018-12-13 18:08 ` [dpdk-dev] [PATCH v3 1/2] eal: add new rte color definition Reshma Pattan
` (2 preceding siblings ...)
2018-12-17 20:35 ` Thomas Monjalon
@ 2018-12-18 15:40 ` Reshma Pattan
2018-12-18 15:40 ` [dpdk-dev] [PATCH v4 2/2] mbuf: implement generic format for sched field Reshma Pattan
2018-12-19 15:34 ` [dpdk-dev] [PATCH v5 1/2] meter: add new rte color definition Reshma Pattan
3 siblings, 2 replies; 74+ messages in thread
From: Reshma Pattan @ 2018-12-18 15:40 UTC (permalink / raw)
To: dev, jerin.jacob, nikhil.rao, jasvinder.singh, cristian.dumitrescu
Cc: Reshma Pattan
Added new rte_color definition in librte_meter to
consolidate color definition which is currently replicated
in various places such as rte_meter.h, rte_tm.h and rte_mtr.h
Created aliases for rte_tm_color, rte_mtr_color and rte_meter_color
to use new rte_color values.
The definitions of rte_tm_color, rte_mtr_color and rte_meter_color
will be deprecated in future.
Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
---
v4: Removed rte_meter, rte_mtr and rte_tm color definitions.
Moved rte_color definition from eal to meter library.
v3:Addressed review comments given in the below link
http://patches.dpdk.org/patch/48588/
Added rte_color.h to meson build.
---
---
lib/Makefile | 1 +
lib/librte_ethdev/Makefile | 2 +-
lib/librte_ethdev/meson.build | 2 +-
lib/librte_ethdev/rte_mtr.h | 16 +++++++---------
lib/librte_ethdev/rte_tm.h | 16 +++++++---------
lib/librte_meter/rte_meter.h | 21 +++++++++++++++------
lib/meson.build | 4 ++--
7 files changed, 34 insertions(+), 28 deletions(-)
diff --git a/lib/Makefile b/lib/Makefile
index b7370ef97..8dbdc9bca 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -26,6 +26,7 @@ DEPDIRS-librte_ethdev := librte_net librte_eal librte_mempool librte_ring
DEPDIRS-librte_ethdev += librte_mbuf
DEPDIRS-librte_ethdev += librte_kvargs
DEPDIRS-librte_ethdev += librte_cmdline
+DEPDIRS-librte_ethdev += librte_meter
DIRS-$(CONFIG_RTE_LIBRTE_BBDEV) += librte_bbdev
DEPDIRS-librte_bbdev := librte_eal librte_mempool librte_mbuf
DIRS-$(CONFIG_RTE_LIBRTE_CRYPTODEV) += librte_cryptodev
diff --git a/lib/librte_ethdev/Makefile b/lib/librte_ethdev/Makefile
index 3e27ae466..e09c4263a 100644
--- a/lib/librte_ethdev/Makefile
+++ b/lib/librte_ethdev/Makefile
@@ -12,7 +12,7 @@ CFLAGS += -DALLOW_EXPERIMENTAL_API
CFLAGS += -O3
CFLAGS += $(WERROR_FLAGS)
LDLIBS += -lrte_net -lrte_eal -lrte_mempool -lrte_ring
-LDLIBS += -lrte_mbuf -lrte_kvargs -lrte_cmdline
+LDLIBS += -lrte_mbuf -lrte_kvargs -lrte_cmdline -lrte_meter
EXPORT_MAP := rte_ethdev_version.map
diff --git a/lib/librte_ethdev/meson.build b/lib/librte_ethdev/meson.build
index a4d850268..e98942ff8 100644
--- a/lib/librte_ethdev/meson.build
+++ b/lib/librte_ethdev/meson.build
@@ -26,4 +26,4 @@ headers = files('rte_ethdev.h',
'rte_tm.h',
'rte_tm_driver.h')
-deps += ['net', 'kvargs', 'cmdline']
+deps += ['net', 'kvargs', 'cmdline', 'meter']
diff --git a/lib/librte_ethdev/rte_mtr.h b/lib/librte_ethdev/rte_mtr.h
index c4819b274..c667f87e1 100644
--- a/lib/librte_ethdev/rte_mtr.h
+++ b/lib/librte_ethdev/rte_mtr.h
@@ -76,20 +76,18 @@
#include <stdint.h>
#include <rte_compat.h>
#include <rte_common.h>
+#include <rte_meter.h>
#ifdef __cplusplus
extern "C" {
#endif
-/**
- * Color
- */
-enum rte_mtr_color {
- RTE_MTR_GREEN = 0, /**< Green */
- RTE_MTR_YELLOW, /**< Yellow */
- RTE_MTR_RED, /**< Red */
- RTE_MTR_COLORS /**< Number of colors. */
-};
+/* New rte_color is defined and used to deprecate rte_mtr_color soon. */
+#define rte_mtr_color rte_color
+#define RTE_MTR_GREEN RTE_COLOR_GREEN
+#define RTE_MTR_YELLOW RTE_COLOR_YELLOW
+#define RTE_MTR_RED RTE_COLOR_RED
+#define RTE_MTR_COLORS RTE_COLORS
/**
* Statistics counter type
diff --git a/lib/librte_ethdev/rte_tm.h b/lib/librte_ethdev/rte_tm.h
index 646ef3880..c4a788b85 100644
--- a/lib/librte_ethdev/rte_tm.h
+++ b/lib/librte_ethdev/rte_tm.h
@@ -51,6 +51,7 @@
#include <stdint.h>
#include <rte_common.h>
+#include <rte_meter.h>
#ifdef __cplusplus
extern "C" {
@@ -115,15 +116,12 @@ extern "C" {
*/
#define RTE_TM_NODE_LEVEL_ID_ANY UINT32_MAX
-/**
- * Color
- */
-enum rte_tm_color {
- RTE_TM_GREEN = 0, /**< Green */
- RTE_TM_YELLOW, /**< Yellow */
- RTE_TM_RED, /**< Red */
- RTE_TM_COLORS /**< Number of colors */
-};
+/* New rte_color is defined and used to deprecate rte_tm_color soon. */
+#define rte_tm_color rte_color
+#define RTE_TM_GREEN RTE_COLOR_GREEN
+#define RTE_TM_YELLOW RTE_COLOR_YELLOW
+#define RTE_TM_RED RTE_COLOR_RED
+#define RTE_TM_COLORS RTE_COLORS
/**
* Node statistics counter type
diff --git a/lib/librte_meter/rte_meter.h b/lib/librte_meter/rte_meter.h
index 58a051583..c2ea47332 100644
--- a/lib/librte_meter/rte_meter.h
+++ b/lib/librte_meter/rte_meter.h
@@ -26,14 +26,23 @@ extern "C" {
*
***/
-/** Packet Color Set */
-enum rte_meter_color {
- e_RTE_METER_GREEN = 0, /**< Green */
- e_RTE_METER_YELLOW, /**< Yellow */
- e_RTE_METER_RED, /**< Red */
- e_RTE_METER_COLORS /**< Number of available colors */
+/**
+ * Color
+ */
+enum rte_color {
+ RTE_COLOR_GREEN = 0, /**< Green */
+ RTE_COLOR_YELLOW, /**< Yellow */
+ RTE_COLOR_RED, /**< Red */
+ RTE_COLORS /**< Number of colors */
};
+/* New rte_color is defined and used to deprecate rte_meter_color soon. */
+#define rte_meter_color rte_color
+#define e_RTE_METER_GREEN RTE_COLOR_GREEN
+#define e_RTE_METER_YELLOW RTE_COLOR_YELLOW
+#define e_RTE_METER_RED RTE_COLOR_RED
+#define e_RTE_METER_COLORS RTE_COLORS
+
/** srTCM parameters per metered traffic flow. The CIR, CBS and EBS parameters only
count bytes of IP packets and do not include link specific headers. At least one of
the CBS or EBS parameters has to be greater than zero. */
diff --git a/lib/meson.build b/lib/meson.build
index bb7f443f9..930ae48fd 100644
--- a/lib/meson.build
+++ b/lib/meson.build
@@ -11,7 +11,7 @@
libraries = [ 'compat', # just a header, used for versioning
'cmdline', # ethdev depends on cmdline for parsing functions
'kvargs', # eal depends on kvargs
- 'eal', 'ring', 'mempool', 'mbuf', 'net', 'ethdev', 'pci', # core
+ 'eal', 'ring', 'mempool', 'meter', 'mbuf', 'net', 'ethdev', 'pci', # core
'metrics', # bitrate/latency stats depends on this
'hash', # efd depends on this
'timer', # eventdev depends on this
@@ -20,7 +20,7 @@ libraries = [ 'compat', # just a header, used for versioning
'distributor', 'efd', 'eventdev',
'gro', 'gso', 'ip_frag', 'jobstats',
'kni', 'latencystats', 'lpm', 'member',
- 'meter', 'power', 'pdump', 'rawdev',
+ 'power', 'pdump', 'rawdev',
'reorder', 'sched', 'security', 'vhost',
# add pkt framework libs which use other libs from above
'port', 'table', 'pipeline',
--
2.17.1
^ permalink raw reply [flat|nested] 74+ messages in thread* [dpdk-dev] [PATCH v4 2/2] mbuf: implement generic format for sched field
2018-12-18 15:40 ` [dpdk-dev] [PATCH v4 1/2] meter: " Reshma Pattan
@ 2018-12-18 15:40 ` Reshma Pattan
2018-12-19 15:34 ` [dpdk-dev] [PATCH v5 1/2] meter: add new rte color definition Reshma Pattan
1 sibling, 0 replies; 74+ messages in thread
From: Reshma Pattan @ 2018-12-18 15:40 UTC (permalink / raw)
To: dev, jerin.jacob, nikhil.rao, jasvinder.singh, cristian.dumitrescu
Cc: Reshma Pattan
This patch implements the changes proposed in the deprecation
notes [1][2].
librte_mbuf changes:
The mbuf::hash::sched field is updated to support generic
definition in line with the ethdev TM and MTR APIs. The new generic
format contains: queue ID, traffic class, color.
Added public APIs to set and get these new fields to and from mbuf.
librte_sched changes:
In addtion, following API functions of the sched library have
been modified with an additional parameter of type struct
rte_sched_port to accommodate the changes made to mbuf sched field.
(i)rte_sched_port_pkt_write()
(ii) rte_sched_port_pkt_read_tree_path()
librte_pipeline, qos_sched UT, qos_sched app are updated
to make use of new changes.
Also mbuf::hash::txadapter has been added for eventdev txq,
rte_event_eth_tx_adapter_txq_set and rte_event_eth_tx_adapter_txq_get()
are updated to use uses mbuf::hash::txadapter.txq.
doc:
Release notes updated.
Removed deprecation notice for mbuf::hash::sched and sched API.
[1] http://mails.dpdk.org/archives/dev/2018-February/090651.html
[2] https://mails.dpdk.org/archives/dev/2018-November/119051.html
Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
---
v4: converted mbuf::hash::sched as instantiation of rte_mbuf_sched.
v3: addressed review comments given in the below link.
http://patches.dpdk.org/patch/48587/
Updated library ABI versioning in meson build.
---
---
doc/guides/rel_notes/deprecation.rst | 10 --
doc/guides/rel_notes/release_19_02.rst | 4 +-
examples/qos_sched/app_thread.c | 7 +-
examples/qos_sched/main.c | 1 +
lib/Makefile | 2 +-
.../rte_event_eth_tx_adapter.h | 18 ++-
lib/librte_mbuf/Makefile | 4 +-
lib/librte_mbuf/meson.build | 4 +-
lib/librte_mbuf/rte_mbuf.h | 118 +++++++++++++++++-
lib/librte_pipeline/rte_table_action.c | 43 ++-----
lib/librte_sched/Makefile | 2 +-
lib/librte_sched/meson.build | 1 +
lib/librte_sched/rte_sched.c | 90 ++++++-------
lib/librte_sched/rte_sched.h | 10 +-
test/test/test_sched.c | 9 +-
15 files changed, 198 insertions(+), 125 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index b48486d36..60e081a54 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -49,16 +49,6 @@ Deprecation Notices
structure would be made internal (or removed if all dependencies are cleared)
in future releases.
-* mbuf: The opaque ``mbuf->hash.sched`` field will be updated to support generic
- definition in line with the ethdev TM and MTR APIs. Currently, this field
- is defined in librte_sched in a non-generic way. The new generic format
- will contain: queue ID, traffic class, color. Field size will not change.
-
-* sched: Some API functions will change prototype due to the above
- deprecation note for mbuf->hash.sched, e.g. ``rte_sched_port_pkt_write()``
- and ``rte_sched_port_pkt_read()`` will likely have an additional parameter
- of type ``struct rte_sched_port``.
-
* mbuf: the macro ``RTE_MBUF_INDIRECT()`` will be removed in v18.08 or later and
replaced with ``RTE_MBUF_CLONED()`` which is already added in v18.05. As
``EXT_ATTACHED_MBUF`` is newly introduced in v18.05, ``RTE_MBUF_INDIRECT()``
diff --git a/doc/guides/rel_notes/release_19_02.rst b/doc/guides/rel_notes/release_19_02.rst
index e86ef9511..39951b398 100644
--- a/doc/guides/rel_notes/release_19_02.rst
+++ b/doc/guides/rel_notes/release_19_02.rst
@@ -152,7 +152,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_kvargs.so.1
librte_latencystats.so.1
librte_lpm.so.2
- librte_mbuf.so.4
+ + librte_mbuf.so.5
librte_member.so.1
librte_mempool.so.5
librte_meter.so.2
@@ -174,7 +174,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_rawdev.so.1
librte_reorder.so.1
librte_ring.so.2
- librte_sched.so.1
+ + librte_sched.so.2
librte_security.so.1
librte_table.so.3
librte_timer.so.1
diff --git a/examples/qos_sched/app_thread.c b/examples/qos_sched/app_thread.c
index a59274236..bec4deee3 100644
--- a/examples/qos_sched/app_thread.c
+++ b/examples/qos_sched/app_thread.c
@@ -73,8 +73,11 @@ app_rx_thread(struct thread_conf **confs)
for(i = 0; i < nb_rx; i++) {
get_pkt_sched(rx_mbufs[i],
&subport, &pipe, &traffic_class, &queue, &color);
- rte_sched_port_pkt_write(rx_mbufs[i], subport, pipe,
- traffic_class, queue, (enum rte_meter_color) color);
+ rte_sched_port_pkt_write(conf->sched_port,
+ rx_mbufs[i],
+ subport, pipe,
+ traffic_class, queue,
+ (enum rte_meter_color) color);
}
if (unlikely(rte_ring_sp_enqueue_bulk(conf->rx_ring,
diff --git a/examples/qos_sched/main.c b/examples/qos_sched/main.c
index e7c97bd64..c0ed16b68 100644
--- a/examples/qos_sched/main.c
+++ b/examples/qos_sched/main.c
@@ -55,6 +55,7 @@ app_main_loop(__attribute__((unused))void *dummy)
flow->rx_thread.rx_port = flow->rx_port;
flow->rx_thread.rx_ring = flow->rx_ring;
flow->rx_thread.rx_queue = flow->rx_queue;
+ flow->rx_thread.sched_port = flow->sched_port;
rx_confs[rx_idx++] = &flow->rx_thread;
diff --git a/lib/Makefile b/lib/Makefile
index 8dbdc9bca..d243c0b64 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -15,7 +15,7 @@ DEPDIRS-librte_ring := librte_eal
DIRS-$(CONFIG_RTE_LIBRTE_MEMPOOL) += librte_mempool
DEPDIRS-librte_mempool := librte_eal librte_ring
DIRS-$(CONFIG_RTE_LIBRTE_MBUF) += librte_mbuf
-DEPDIRS-librte_mbuf := librte_eal librte_mempool
+DEPDIRS-librte_mbuf := librte_eal librte_mempool librte_meter
DIRS-$(CONFIG_RTE_LIBRTE_TIMER) += librte_timer
DEPDIRS-librte_timer := librte_eal
DIRS-$(CONFIG_RTE_LIBRTE_CFGFILE) += librte_cfgfile
diff --git a/lib/librte_eventdev/rte_event_eth_tx_adapter.h b/lib/librte_eventdev/rte_event_eth_tx_adapter.h
index 81456d4a9..2a50656d9 100644
--- a/lib/librte_eventdev/rte_event_eth_tx_adapter.h
+++ b/lib/librte_eventdev/rte_event_eth_tx_adapter.h
@@ -63,13 +63,11 @@
* function can be used to retrieve the adapter's service function ID.
*
* The ethernet port and transmit queue index to transmit the mbuf on are
- * specified using the mbuf port and the higher 16 bits of
- * struct rte_mbuf::hash::sched:hi. The application should use the
- * rte_event_eth_tx_adapter_txq_set() and rte_event_eth_tx_adapter_txq_get()
- * functions to access the transmit queue index since it is expected that the
- * transmit queue will be eventually defined within struct rte_mbuf and using
- * these macros will help with minimizing application impact due to
- * a change in how the transmit queue index is specified.
+ * specified using the mbuf port struct rte_mbuf::hash::txadapter:txq.
+ * The application should use the rte_event_eth_tx_adapter_txq_set()
+ * and rte_event_eth_tx_adapter_txq_get() functions to access the transmit
+ * queue index, using these macros will help with minimizing application
+ * impact due to a change in how the transmit queue index is specified.
*/
#ifdef __cplusplus
@@ -300,8 +298,7 @@ rte_event_eth_tx_adapter_queue_del(uint8_t id,
static __rte_always_inline void __rte_experimental
rte_event_eth_tx_adapter_txq_set(struct rte_mbuf *pkt, uint16_t queue)
{
- uint16_t *p = (uint16_t *)&pkt->hash.sched.hi;
- p[1] = queue;
+ pkt->hash.txadapter.txq = queue;
}
/**
@@ -320,8 +317,7 @@ rte_event_eth_tx_adapter_txq_set(struct rte_mbuf *pkt, uint16_t queue)
static __rte_always_inline uint16_t __rte_experimental
rte_event_eth_tx_adapter_txq_get(struct rte_mbuf *pkt)
{
- uint16_t *p = (uint16_t *)&pkt->hash.sched.hi;
- return p[1];
+ return pkt->hash.txadapter.txq;
}
/**
diff --git a/lib/librte_mbuf/Makefile b/lib/librte_mbuf/Makefile
index e2b98a254..eb1b5e6a1 100644
--- a/lib/librte_mbuf/Makefile
+++ b/lib/librte_mbuf/Makefile
@@ -7,11 +7,11 @@ include $(RTE_SDK)/mk/rte.vars.mk
LIB = librte_mbuf.a
CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3
-LDLIBS += -lrte_eal -lrte_mempool
+LDLIBS += -lrte_eal -lrte_mempool -lrte_meter
EXPORT_MAP := rte_mbuf_version.map
-LIBABIVER := 4
+LIBABIVER := 5
# all source are stored in SRCS-y
SRCS-$(CONFIG_RTE_LIBRTE_MBUF) := rte_mbuf.c rte_mbuf_ptype.c rte_mbuf_pool_ops.c
diff --git a/lib/librte_mbuf/meson.build b/lib/librte_mbuf/meson.build
index 94d9c4c96..d87785818 100644
--- a/lib/librte_mbuf/meson.build
+++ b/lib/librte_mbuf/meson.build
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017 Intel Corporation
-version = 4
+version = 5
sources = files('rte_mbuf.c', 'rte_mbuf_ptype.c', 'rte_mbuf_pool_ops.c')
headers = files('rte_mbuf.h', 'rte_mbuf_ptype.h', 'rte_mbuf_pool_ops.h')
-deps += ['mempool']
+deps += ['mempool', 'meter']
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 3dbc6695e..7397e3cf5 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -37,6 +37,7 @@
#include <rte_config.h>
#include <rte_mempool.h>
#include <rte_memory.h>
+#include <rte_meter.h>
#include <rte_atomic.h>
#include <rte_prefetch.h>
#include <rte_branch_prediction.h>
@@ -574,14 +575,25 @@ struct rte_mbuf {
* on PKT_RX_FDIR_* flag in ol_flags.
*/
} fdir; /**< Filter identifier if FDIR enabled */
+ struct rte_mbuf_sched {
+ uint32_t queue_id; /**< Queue ID. */
+ uint8_t traffic_class;
+ /**< Traffic class ID. Traffic class 0
+ * is the highest priority traffic class.
+ */
+ uint8_t color;
+ /**< Color. @see enum rte_color.*/
+ uint16_t reserved; /**< Reserved. */
+ } sched; /**< Hierarchical scheduler */
struct {
- uint32_t lo;
- uint32_t hi;
+ uint32_t reserved1;
+ uint16_t reserved2;
+ uint16_t txq;
/**< The event eth Tx adapter uses this field
* to store Tx queue id.
* @see rte_event_eth_tx_adapter_txq_set()
*/
- } sched; /**< Hierarchical scheduler */
+ } txadapter; /**< Eventdev ethdev Tx adapter */
/**< User defined tags. See rte_distributor_process() */
uint32_t usr;
} hash; /**< hash information */
@@ -2289,6 +2301,106 @@ rte_pktmbuf_linearize(struct rte_mbuf *mbuf)
*/
void rte_pktmbuf_dump(FILE *f, const struct rte_mbuf *m, unsigned dump_len);
+/**
+ * Get the value of mbuf sched queue_id field.
+ */
+static inline uint32_t
+rte_mbuf_sched_queue_get(const struct rte_mbuf *m)
+{
+ return m->hash.sched.queue_id;
+}
+
+/**
+ * Get the value of mbuf sched traffic_class field.
+ */
+static inline uint8_t
+rte_mbuf_sched_traffic_class_get(const struct rte_mbuf *m)
+{
+ return m->hash.sched.traffic_class;
+}
+
+/**
+ * Get the value of mbuf sched color field.
+ */
+static inline enum rte_color
+rte_mbuf_sched_color_get(const struct rte_mbuf *m)
+{
+ return (enum rte_color)m->hash.sched.color;
+}
+
+/**
+ * Get the values of mbuf sched queue_id, traffic_class and color.
+ * @param m
+ * Mbuf to read
+ * @param queue_id
+ * Returns the queue id
+ * @param traffic_class
+ * Returns the traffic class id
+ * @param color
+ * Returns the colour id
+ */
+static inline void
+rte_mbuf_sched_get(const struct rte_mbuf *m, uint32_t *queue_id,
+ uint8_t *traffic_class,
+ enum rte_color *color)
+{
+ struct rte_mbuf_sched sched = m->hash.sched;
+
+ *queue_id = sched.queue_id;
+ *traffic_class = sched.traffic_class;
+ *color = (enum rte_color)sched.color;
+}
+
+/**
+ * Set the mbuf sched queue_id to the defined value.
+ */
+static inline void
+rte_mbuf_sched_queue_set(struct rte_mbuf *m, uint32_t queue_id)
+{
+ m->hash.sched.queue_id = queue_id;
+}
+
+/**
+ * Set the mbuf sched traffic_class id to the defined value.
+ */
+static inline void
+rte_mbuf_sched_traffic_class_set(struct rte_mbuf *m, uint8_t traffic_class)
+{
+ m->hash.sched.traffic_class = traffic_class;
+}
+
+/**
+ * Set the mbuf sched color id to the defined value.
+ */
+static inline void
+rte_mbuf_sched_color_set(struct rte_mbuf *m, enum rte_color color)
+{
+ m->hash.sched.color = (uint8_t)color;
+}
+
+/**
+ * Set the mbuf sched queue_id, traffic_class and color.
+ * @param m
+ * Mbuf to set
+ * @param queue_id
+ * Queue id value to be set
+ * @param traffic_class
+ * Traffic class id value to be set
+ * @param color
+ * Color id to be set
+ */
+static inline void
+rte_mbuf_sched_set(struct rte_mbuf *m, uint32_t queue_id,
+ uint8_t traffic_class,
+ enum rte_color color)
+{
+ m->hash.sched = (struct rte_mbuf_sched){
+ .queue_id = queue_id,
+ .traffic_class = traffic_class,
+ .color = (uint8_t)color,
+ };
+}
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_pipeline/rte_table_action.c b/lib/librte_pipeline/rte_table_action.c
index 7c7c8dd82..3158301ff 100644
--- a/lib/librte_pipeline/rte_table_action.c
+++ b/lib/librte_pipeline/rte_table_action.c
@@ -107,14 +107,6 @@ mtr_cfg_check(struct rte_table_action_mtr_config *mtr)
return 0;
}
-#define MBUF_SCHED_QUEUE_TC_COLOR(queue, tc, color) \
- ((uint16_t)((((uint64_t)(queue)) & 0x3) | \
- ((((uint64_t)(tc)) & 0x3) << 2) | \
- ((((uint64_t)(color)) & 0x3) << 4)))
-
-#define MBUF_SCHED_COLOR(sched, color) \
- (((sched) & (~0x30LLU)) | ((color) << 4))
-
struct mtr_trtcm_data {
struct rte_meter_trtcm trtcm;
uint64_t stats[e_RTE_METER_COLORS];
@@ -176,7 +168,7 @@ mtr_data_size(struct rte_table_action_mtr_config *mtr)
struct dscp_table_entry_data {
enum rte_meter_color color;
uint16_t tc;
- uint16_t queue_tc_color;
+ uint16_t tc_queue;
};
struct dscp_table_data {
@@ -319,8 +311,7 @@ pkt_work_mtr(struct rte_mbuf *mbuf,
uint32_t dscp,
uint16_t total_length)
{
- uint64_t drop_mask, sched;
- uint64_t *sched_ptr = (uint64_t *) &mbuf->hash.sched;
+ uint64_t drop_mask;
struct dscp_table_entry_data *dscp_entry = &dscp_table->entry[dscp];
enum rte_meter_color color_in, color_meter, color_policer;
uint32_t tc, mp_id;
@@ -329,7 +320,6 @@ pkt_work_mtr(struct rte_mbuf *mbuf,
color_in = dscp_entry->color;
data += tc;
mp_id = MTR_TRTCM_DATA_METER_PROFILE_ID_GET(data);
- sched = *sched_ptr;
/* Meter */
color_meter = rte_meter_trtcm_color_aware_check(
@@ -346,7 +336,7 @@ pkt_work_mtr(struct rte_mbuf *mbuf,
drop_mask = MTR_TRTCM_DATA_POLICER_ACTION_DROP_GET(data, color_meter);
color_policer =
MTR_TRTCM_DATA_POLICER_ACTION_COLOR_GET(data, color_meter);
- *sched_ptr = MBUF_SCHED_COLOR(sched, color_policer);
+ rte_mbuf_sched_color_set(mbuf, color_policer);
return drop_mask;
}
@@ -368,9 +358,8 @@ tm_cfg_check(struct rte_table_action_tm_config *tm)
}
struct tm_data {
- uint16_t queue_tc_color;
- uint16_t subport;
- uint32_t pipe;
+ uint32_t queue_id;
+ uint32_t reserved;
} __attribute__((__packed__));
static int
@@ -397,9 +386,9 @@ tm_apply(struct tm_data *data,
return status;
/* Apply */
- data->queue_tc_color = 0;
- data->subport = (uint16_t) p->subport_id;
- data->pipe = p->pipe_id;
+ data->queue_id = p->subport_id <<
+ (__builtin_ctz(cfg->n_pipes_per_subport) + 4) |
+ p->pipe_id << 4;
return 0;
}
@@ -411,12 +400,10 @@ pkt_work_tm(struct rte_mbuf *mbuf,
uint32_t dscp)
{
struct dscp_table_entry_data *dscp_entry = &dscp_table->entry[dscp];
- struct tm_data *sched_ptr = (struct tm_data *) &mbuf->hash.sched;
- struct tm_data sched;
-
- sched = *data;
- sched.queue_tc_color = dscp_entry->queue_tc_color;
- *sched_ptr = sched;
+ uint32_t queue_id = data->queue_id |
+ (dscp_entry->tc << 2) |
+ dscp_entry->tc_queue;
+ rte_mbuf_sched_set(mbuf, queue_id, dscp_entry->tc, dscp_entry->color);
}
/**
@@ -2580,17 +2567,13 @@ rte_table_action_dscp_table_update(struct rte_table_action *action,
&action->dscp_table.entry[i];
struct rte_table_action_dscp_table_entry *entry =
&table->entry[i];
- uint16_t queue_tc_color =
- MBUF_SCHED_QUEUE_TC_COLOR(entry->tc_queue_id,
- entry->tc_id,
- entry->color);
if ((dscp_mask & (1LLU << i)) == 0)
continue;
data->color = entry->color;
data->tc = entry->tc_id;
- data->queue_tc_color = queue_tc_color;
+ data->tc_queue = entry->tc_queue_id;
}
return 0;
diff --git a/lib/librte_sched/Makefile b/lib/librte_sched/Makefile
index 46c53ed71..644fd9d15 100644
--- a/lib/librte_sched/Makefile
+++ b/lib/librte_sched/Makefile
@@ -18,7 +18,7 @@ LDLIBS += -lrte_timer
EXPORT_MAP := rte_sched_version.map
-LIBABIVER := 1
+LIBABIVER := 2
#
# all source are stored in SRCS-y
diff --git a/lib/librte_sched/meson.build b/lib/librte_sched/meson.build
index f85d64df8..8e989e5f6 100644
--- a/lib/librte_sched/meson.build
+++ b/lib/librte_sched/meson.build
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017 Intel Corporation
+version = 2
sources = files('rte_sched.c', 'rte_red.c', 'rte_approx.c')
headers = files('rte_sched.h', 'rte_sched_common.h',
'rte_red.h', 'rte_approx.h')
diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c
index 587d5e602..14290ee44 100644
--- a/lib/librte_sched/rte_sched.c
+++ b/lib/librte_sched/rte_sched.c
@@ -128,22 +128,6 @@ enum grinder_state {
e_GRINDER_READ_MBUF
};
-/*
- * Path through the scheduler hierarchy used by the scheduler enqueue
- * operation to identify the destination queue for the current
- * packet. Stored in the field pkt.hash.sched of struct rte_mbuf of
- * each packet, typically written by the classification stage and read
- * by scheduler enqueue.
- */
-struct rte_sched_port_hierarchy {
- uint16_t queue:2; /**< Queue ID (0 .. 3) */
- uint16_t traffic_class:2; /**< Traffic class ID (0 .. 3)*/
- uint32_t color:2; /**< Color */
- uint16_t unused:10;
- uint16_t subport; /**< Subport ID */
- uint32_t pipe; /**< Pipe ID */
-};
-
struct rte_sched_grinder {
/* Pipe cache */
uint16_t pcache_qmask[RTE_SCHED_GRINDER_PCACHE_SIZE];
@@ -185,6 +169,7 @@ struct rte_sched_port {
/* User parameters */
uint32_t n_subports_per_port;
uint32_t n_pipes_per_subport;
+ uint32_t n_pipes_per_subport_log2;
uint32_t rate;
uint32_t mtu;
uint32_t frame_overhead;
@@ -645,6 +630,8 @@ rte_sched_port_config(struct rte_sched_port_params *params)
/* User parameters */
port->n_subports_per_port = params->n_subports_per_port;
port->n_pipes_per_subport = params->n_pipes_per_subport;
+ port->n_pipes_per_subport_log2 =
+ __builtin_ctz(params->n_pipes_per_subport);
port->rate = params->rate;
port->mtu = params->mtu + params->frame_overhead;
port->frame_overhead = params->frame_overhead;
@@ -1006,44 +993,52 @@ rte_sched_port_pipe_profile_add(struct rte_sched_port *port,
return 0;
}
+static inline uint32_t
+rte_sched_port_qindex(struct rte_sched_port *port,
+ uint32_t subport,
+ uint32_t pipe,
+ uint32_t traffic_class,
+ uint32_t queue)
+{
+ return ((subport & (port->n_subports_per_port - 1)) <<
+ (port->n_pipes_per_subport_log2 + 4)) |
+ ((pipe & (port->n_pipes_per_subport - 1)) << 4) |
+ ((traffic_class &
+ (RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE - 1)) << 2) |
+ (queue & (RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS - 1));
+}
+
void
-rte_sched_port_pkt_write(struct rte_mbuf *pkt,
- uint32_t subport, uint32_t pipe, uint32_t traffic_class,
+rte_sched_port_pkt_write(struct rte_sched_port *port,
+ struct rte_mbuf *pkt,
+ uint32_t subport, uint32_t pipe,
+ uint32_t traffic_class,
uint32_t queue, enum rte_meter_color color)
{
- struct rte_sched_port_hierarchy *sched
- = (struct rte_sched_port_hierarchy *) &pkt->hash.sched;
-
- RTE_BUILD_BUG_ON(sizeof(*sched) > sizeof(pkt->hash.sched));
-
- sched->color = (uint32_t) color;
- sched->subport = subport;
- sched->pipe = pipe;
- sched->traffic_class = traffic_class;
- sched->queue = queue;
+ uint32_t queue_id = rte_sched_port_qindex(port, subport, pipe,
+ traffic_class, queue);
+ rte_mbuf_sched_set(pkt, queue_id, traffic_class, (enum rte_color)color);
}
void
-rte_sched_port_pkt_read_tree_path(const struct rte_mbuf *pkt,
+rte_sched_port_pkt_read_tree_path(struct rte_sched_port *port,
+ const struct rte_mbuf *pkt,
uint32_t *subport, uint32_t *pipe,
uint32_t *traffic_class, uint32_t *queue)
{
- const struct rte_sched_port_hierarchy *sched
- = (const struct rte_sched_port_hierarchy *) &pkt->hash.sched;
+ uint32_t queue_id = rte_mbuf_sched_queue_get(pkt);
- *subport = sched->subport;
- *pipe = sched->pipe;
- *traffic_class = sched->traffic_class;
- *queue = sched->queue;
+ *subport = queue_id >> (port->n_pipes_per_subport_log2 + 4);
+ *pipe = (queue_id >> 4) & (port->n_pipes_per_subport - 1);
+ *traffic_class = (queue_id >> 2) &
+ (RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE - 1);
+ *queue = queue_id & (RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS - 1);
}
enum rte_meter_color
rte_sched_port_pkt_read_color(const struct rte_mbuf *pkt)
{
- const struct rte_sched_port_hierarchy *sched
- = (const struct rte_sched_port_hierarchy *) &pkt->hash.sched;
-
- return (enum rte_meter_color) sched->color;
+ return rte_mbuf_sched_color_get(pkt);
}
int
@@ -1100,18 +1095,6 @@ rte_sched_queue_read_stats(struct rte_sched_port *port,
return 0;
}
-static inline uint32_t
-rte_sched_port_qindex(struct rte_sched_port *port, uint32_t subport, uint32_t pipe, uint32_t traffic_class, uint32_t queue)
-{
- uint32_t result;
-
- result = subport * port->n_pipes_per_subport + pipe;
- result = result * RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE + traffic_class;
- result = result * RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS + queue;
-
- return result;
-}
-
#ifdef RTE_SCHED_DEBUG
static inline int
@@ -1272,11 +1255,8 @@ rte_sched_port_enqueue_qptrs_prefetch0(struct rte_sched_port *port,
#ifdef RTE_SCHED_COLLECT_STATS
struct rte_sched_queue_extra *qe;
#endif
- uint32_t subport, pipe, traffic_class, queue, qindex;
-
- rte_sched_port_pkt_read_tree_path(pkt, &subport, &pipe, &traffic_class, &queue);
+ uint32_t qindex = rte_mbuf_sched_queue_get(pkt);
- qindex = rte_sched_port_qindex(port, subport, pipe, traffic_class, queue);
q = port->queue + qindex;
rte_prefetch0(q);
#ifdef RTE_SCHED_COLLECT_STATS
diff --git a/lib/librte_sched/rte_sched.h b/lib/librte_sched/rte_sched.h
index 84fa896de..243efa1d4 100644
--- a/lib/librte_sched/rte_sched.h
+++ b/lib/librte_sched/rte_sched.h
@@ -355,6 +355,8 @@ rte_sched_queue_read_stats(struct rte_sched_port *port,
* Scheduler hierarchy path write to packet descriptor. Typically
* called by the packet classification stage.
*
+ * @param port
+ * Handle to port scheduler instance
* @param pkt
* Packet descriptor handle
* @param subport
@@ -369,7 +371,8 @@ rte_sched_queue_read_stats(struct rte_sched_port *port,
* Packet color set
*/
void
-rte_sched_port_pkt_write(struct rte_mbuf *pkt,
+rte_sched_port_pkt_write(struct rte_sched_port *port,
+ struct rte_mbuf *pkt,
uint32_t subport, uint32_t pipe, uint32_t traffic_class,
uint32_t queue, enum rte_meter_color color);
@@ -379,6 +382,8 @@ rte_sched_port_pkt_write(struct rte_mbuf *pkt,
* enqueue operation. The subport, pipe, traffic class and queue
* parameters need to be pre-allocated by the caller.
*
+ * @param port
+ * Handle to port scheduler instance
* @param pkt
* Packet descriptor handle
* @param subport
@@ -392,7 +397,8 @@ rte_sched_port_pkt_write(struct rte_mbuf *pkt,
*
*/
void
-rte_sched_port_pkt_read_tree_path(const struct rte_mbuf *pkt,
+rte_sched_port_pkt_read_tree_path(struct rte_sched_port *port,
+ const struct rte_mbuf *pkt,
uint32_t *subport, uint32_t *pipe,
uint32_t *traffic_class, uint32_t *queue);
diff --git a/test/test/test_sched.c b/test/test/test_sched.c
index 32e500ba9..40e411cab 100644
--- a/test/test/test_sched.c
+++ b/test/test/test_sched.c
@@ -76,7 +76,7 @@ create_mempool(void)
}
static void
-prepare_pkt(struct rte_mbuf *mbuf)
+prepare_pkt(struct rte_sched_port *port, struct rte_mbuf *mbuf)
{
struct ether_hdr *eth_hdr;
struct vlan_hdr *vlan1, *vlan2;
@@ -95,7 +95,8 @@ prepare_pkt(struct rte_mbuf *mbuf)
ip_hdr->dst_addr = IPv4(0,0,TC,QUEUE);
- rte_sched_port_pkt_write(mbuf, SUBPORT, PIPE, TC, QUEUE, e_RTE_METER_YELLOW);
+ rte_sched_port_pkt_write(port, mbuf, SUBPORT, PIPE, TC, QUEUE,
+ e_RTE_METER_YELLOW);
/* 64 byte packet */
mbuf->pkt_len = 60;
@@ -138,7 +139,7 @@ test_sched(void)
for (i = 0; i < 10; i++) {
in_mbufs[i] = rte_pktmbuf_alloc(mp);
TEST_ASSERT_NOT_NULL(in_mbufs[i], "Packet allocation failed\n");
- prepare_pkt(in_mbufs[i]);
+ prepare_pkt(port, in_mbufs[i]);
}
@@ -155,7 +156,7 @@ test_sched(void)
color = rte_sched_port_pkt_read_color(out_mbufs[i]);
TEST_ASSERT_EQUAL(color, e_RTE_METER_YELLOW, "Wrong color\n");
- rte_sched_port_pkt_read_tree_path(out_mbufs[i],
+ rte_sched_port_pkt_read_tree_path(port, out_mbufs[i],
&subport, &pipe, &traffic_class, &queue);
TEST_ASSERT_EQUAL(subport, SUBPORT, "Wrong subport\n");
--
2.17.1
^ permalink raw reply [flat|nested] 74+ messages in thread* [dpdk-dev] [PATCH v5 1/2] meter: add new rte color definition
2018-12-18 15:40 ` [dpdk-dev] [PATCH v4 1/2] meter: " Reshma Pattan
2018-12-18 15:40 ` [dpdk-dev] [PATCH v4 2/2] mbuf: implement generic format for sched field Reshma Pattan
@ 2018-12-19 15:34 ` Reshma Pattan
2018-12-19 15:34 ` [dpdk-dev] [PATCH v5 2/2] mbuf: implement generic format for sched field Reshma Pattan
2018-12-19 15:42 ` [dpdk-dev] [PATCH v6 1/2] meter: add new rte color definition Reshma Pattan
1 sibling, 2 replies; 74+ messages in thread
From: Reshma Pattan @ 2018-12-19 15:34 UTC (permalink / raw)
To: dev, jerin.jacob, nikhil.rao, olivier.matz, thomas,
jasvinder.singh, cristian.dumitrescu
Cc: Reshma Pattan
Added new rte_color definition in librte_meter to
consolidate color definition which is currently replicated
in various places such as rte_meter.h, rte_tm.h and rte_mtr.h
Created aliases for rte_tm_color, rte_mtr_color and rte_meter_color
to use new rte_color values.
The definitions of rte_tm_color, rte_mtr_color and rte_meter_color
will be deprecated in future.
Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
---
v5: Removed meter library from librte_mbuf dependency list.
v4: Removed rte_meter, rte_mtr and rte_tm color definitions.
Moved rte_color definition from eal to meter library.
v3:Addressed review comments given in the below link
http://patches.dpdk.org/patch/48588/
Added rte_color.h to meson build.
---
---
lib/Makefile | 1 +
lib/librte_ethdev/Makefile | 2 +-
lib/librte_ethdev/meson.build | 2 +-
lib/librte_ethdev/rte_mtr.h | 16 +++++++---------
lib/librte_ethdev/rte_tm.h | 16 +++++++---------
lib/librte_meter/rte_meter.h | 21 +++++++++++++++------
lib/meson.build | 4 ++--
7 files changed, 34 insertions(+), 28 deletions(-)
diff --git a/lib/Makefile b/lib/Makefile
index b7370ef97..8dbdc9bca 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -26,6 +26,7 @@ DEPDIRS-librte_ethdev := librte_net librte_eal librte_mempool librte_ring
DEPDIRS-librte_ethdev += librte_mbuf
DEPDIRS-librte_ethdev += librte_kvargs
DEPDIRS-librte_ethdev += librte_cmdline
+DEPDIRS-librte_ethdev += librte_meter
DIRS-$(CONFIG_RTE_LIBRTE_BBDEV) += librte_bbdev
DEPDIRS-librte_bbdev := librte_eal librte_mempool librte_mbuf
DIRS-$(CONFIG_RTE_LIBRTE_CRYPTODEV) += librte_cryptodev
diff --git a/lib/librte_ethdev/Makefile b/lib/librte_ethdev/Makefile
index 3e27ae466..e09c4263a 100644
--- a/lib/librte_ethdev/Makefile
+++ b/lib/librte_ethdev/Makefile
@@ -12,7 +12,7 @@ CFLAGS += -DALLOW_EXPERIMENTAL_API
CFLAGS += -O3
CFLAGS += $(WERROR_FLAGS)
LDLIBS += -lrte_net -lrte_eal -lrte_mempool -lrte_ring
-LDLIBS += -lrte_mbuf -lrte_kvargs -lrte_cmdline
+LDLIBS += -lrte_mbuf -lrte_kvargs -lrte_cmdline -lrte_meter
EXPORT_MAP := rte_ethdev_version.map
diff --git a/lib/librte_ethdev/meson.build b/lib/librte_ethdev/meson.build
index a4d850268..e98942ff8 100644
--- a/lib/librte_ethdev/meson.build
+++ b/lib/librte_ethdev/meson.build
@@ -26,4 +26,4 @@ headers = files('rte_ethdev.h',
'rte_tm.h',
'rte_tm_driver.h')
-deps += ['net', 'kvargs', 'cmdline']
+deps += ['net', 'kvargs', 'cmdline', 'meter']
diff --git a/lib/librte_ethdev/rte_mtr.h b/lib/librte_ethdev/rte_mtr.h
index c4819b274..c667f87e1 100644
--- a/lib/librte_ethdev/rte_mtr.h
+++ b/lib/librte_ethdev/rte_mtr.h
@@ -76,20 +76,18 @@
#include <stdint.h>
#include <rte_compat.h>
#include <rte_common.h>
+#include <rte_meter.h>
#ifdef __cplusplus
extern "C" {
#endif
-/**
- * Color
- */
-enum rte_mtr_color {
- RTE_MTR_GREEN = 0, /**< Green */
- RTE_MTR_YELLOW, /**< Yellow */
- RTE_MTR_RED, /**< Red */
- RTE_MTR_COLORS /**< Number of colors. */
-};
+/* New rte_color is defined and used to deprecate rte_mtr_color soon. */
+#define rte_mtr_color rte_color
+#define RTE_MTR_GREEN RTE_COLOR_GREEN
+#define RTE_MTR_YELLOW RTE_COLOR_YELLOW
+#define RTE_MTR_RED RTE_COLOR_RED
+#define RTE_MTR_COLORS RTE_COLORS
/**
* Statistics counter type
diff --git a/lib/librte_ethdev/rte_tm.h b/lib/librte_ethdev/rte_tm.h
index 646ef3880..c4a788b85 100644
--- a/lib/librte_ethdev/rte_tm.h
+++ b/lib/librte_ethdev/rte_tm.h
@@ -51,6 +51,7 @@
#include <stdint.h>
#include <rte_common.h>
+#include <rte_meter.h>
#ifdef __cplusplus
extern "C" {
@@ -115,15 +116,12 @@ extern "C" {
*/
#define RTE_TM_NODE_LEVEL_ID_ANY UINT32_MAX
-/**
- * Color
- */
-enum rte_tm_color {
- RTE_TM_GREEN = 0, /**< Green */
- RTE_TM_YELLOW, /**< Yellow */
- RTE_TM_RED, /**< Red */
- RTE_TM_COLORS /**< Number of colors */
-};
+/* New rte_color is defined and used to deprecate rte_tm_color soon. */
+#define rte_tm_color rte_color
+#define RTE_TM_GREEN RTE_COLOR_GREEN
+#define RTE_TM_YELLOW RTE_COLOR_YELLOW
+#define RTE_TM_RED RTE_COLOR_RED
+#define RTE_TM_COLORS RTE_COLORS
/**
* Node statistics counter type
diff --git a/lib/librte_meter/rte_meter.h b/lib/librte_meter/rte_meter.h
index 58a051583..c2ea47332 100644
--- a/lib/librte_meter/rte_meter.h
+++ b/lib/librte_meter/rte_meter.h
@@ -26,14 +26,23 @@ extern "C" {
*
***/
-/** Packet Color Set */
-enum rte_meter_color {
- e_RTE_METER_GREEN = 0, /**< Green */
- e_RTE_METER_YELLOW, /**< Yellow */
- e_RTE_METER_RED, /**< Red */
- e_RTE_METER_COLORS /**< Number of available colors */
+/**
+ * Color
+ */
+enum rte_color {
+ RTE_COLOR_GREEN = 0, /**< Green */
+ RTE_COLOR_YELLOW, /**< Yellow */
+ RTE_COLOR_RED, /**< Red */
+ RTE_COLORS /**< Number of colors */
};
+/* New rte_color is defined and used to deprecate rte_meter_color soon. */
+#define rte_meter_color rte_color
+#define e_RTE_METER_GREEN RTE_COLOR_GREEN
+#define e_RTE_METER_YELLOW RTE_COLOR_YELLOW
+#define e_RTE_METER_RED RTE_COLOR_RED
+#define e_RTE_METER_COLORS RTE_COLORS
+
/** srTCM parameters per metered traffic flow. The CIR, CBS and EBS parameters only
count bytes of IP packets and do not include link specific headers. At least one of
the CBS or EBS parameters has to be greater than zero. */
diff --git a/lib/meson.build b/lib/meson.build
index bb7f443f9..a2dd52e17 100644
--- a/lib/meson.build
+++ b/lib/meson.build
@@ -11,7 +11,7 @@
libraries = [ 'compat', # just a header, used for versioning
'cmdline', # ethdev depends on cmdline for parsing functions
'kvargs', # eal depends on kvargs
- 'eal', 'ring', 'mempool', 'mbuf', 'net', 'ethdev', 'pci', # core
+ 'eal', 'ring', 'mempool', 'mbuf', 'net', 'meter', 'ethdev', 'pci', # core
'metrics', # bitrate/latency stats depends on this
'hash', # efd depends on this
'timer', # eventdev depends on this
@@ -20,7 +20,7 @@ libraries = [ 'compat', # just a header, used for versioning
'distributor', 'efd', 'eventdev',
'gro', 'gso', 'ip_frag', 'jobstats',
'kni', 'latencystats', 'lpm', 'member',
- 'meter', 'power', 'pdump', 'rawdev',
+ 'power', 'pdump', 'rawdev',
'reorder', 'sched', 'security', 'vhost',
# add pkt framework libs which use other libs from above
'port', 'table', 'pipeline',
--
2.17.1
^ permalink raw reply [flat|nested] 74+ messages in thread* [dpdk-dev] [PATCH v5 2/2] mbuf: implement generic format for sched field
2018-12-19 15:34 ` [dpdk-dev] [PATCH v5 1/2] meter: add new rte color definition Reshma Pattan
@ 2018-12-19 15:34 ` Reshma Pattan
2018-12-19 15:42 ` [dpdk-dev] [PATCH v6 1/2] meter: add new rte color definition Reshma Pattan
1 sibling, 0 replies; 74+ messages in thread
From: Reshma Pattan @ 2018-12-19 15:34 UTC (permalink / raw)
To: dev, jerin.jacob, nikhil.rao, olivier.matz, thomas,
jasvinder.singh, cristian.dumitrescu
Cc: Reshma Pattan
This patch implements the changes proposed in the deprecation
notes [1][2].
librte_mbuf changes:
The mbuf::hash::sched field is updated to support generic
definition in line with the ethdev TM and MTR APIs. The new generic
format contains: queue ID, traffic class, color.
Added public APIs to set and get these new fields to and from mbuf.
librte_sched changes:
In addtion, following API functions of the sched library have
been modified with an additional parameter of type struct
rte_sched_port to accommodate the changes made to mbuf sched field.
(i)rte_sched_port_pkt_write()
(ii) rte_sched_port_pkt_read_tree_path()
librte_pipeline, qos_sched UT, qos_sched app are updated
to make use of new changes.
Also mbuf::hash::txadapter has been added for eventdev txq,
rte_event_eth_tx_adapter_txq_set and rte_event_eth_tx_adapter_txq_get()
are updated to use uses mbuf::hash::txadapter.txq.
doc:
Release notes updated.
Removed deprecation notice for mbuf::hash::sched and sched API.
[1] http://mails.dpdk.org/archives/dev/2018-February/090651.html
[2] https://mails.dpdk.org/archives/dev/2018-November/119051.html
Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
---
v5:
Removed librte_meter from librte_mbuf dependency list.
Changed the mbuf set/get functions to use uint8_t for color.
v4: converted mbuf::hash::sched as instantiation of rte_mbuf_sched.
v3: addressed review comments given in the below link.
http://patches.dpdk.org/patch/48587/
Updated library ABI versioning in meson build.
---
---
doc/guides/rel_notes/deprecation.rst | 10 --
doc/guides/rel_notes/release_19_02.rst | 4 +-
examples/qos_sched/app_thread.c | 7 +-
examples/qos_sched/main.c | 1 +
.../rte_event_eth_tx_adapter.h | 18 ++-
lib/librte_mbuf/Makefile | 2 +-
lib/librte_mbuf/meson.build | 2 +-
lib/librte_mbuf/rte_mbuf.h | 119 +++++++++++++++++-
lib/librte_pipeline/rte_table_action.c | 44 +++----
lib/librte_sched/Makefile | 2 +-
lib/librte_sched/meson.build | 1 +
lib/librte_sched/rte_sched.c | 90 ++++++-------
lib/librte_sched/rte_sched.h | 10 +-
test/test/test_sched.c | 9 +-
14 files changed, 197 insertions(+), 122 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index ac7fb29a7..ec80dcc7b 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -49,16 +49,6 @@ Deprecation Notices
structure would be made internal (or removed if all dependencies are cleared)
in future releases.
-* mbuf: The opaque ``mbuf->hash.sched`` field will be updated to support generic
- definition in line with the ethdev TM and MTR APIs. Currently, this field
- is defined in librte_sched in a non-generic way. The new generic format
- will contain: queue ID, traffic class, color. Field size will not change.
-
-* sched: Some API functions will change prototype due to the above
- deprecation note for mbuf->hash.sched, e.g. ``rte_sched_port_pkt_write()``
- and ``rte_sched_port_pkt_read()`` will likely have an additional parameter
- of type ``struct rte_sched_port``.
-
* mbuf: the macro ``RTE_MBUF_INDIRECT()`` will be removed in v18.08 or later and
replaced with ``RTE_MBUF_CLONED()`` which is already added in v18.05. As
``EXT_ATTACHED_MBUF`` is newly introduced in v18.05, ``RTE_MBUF_INDIRECT()``
diff --git a/doc/guides/rel_notes/release_19_02.rst b/doc/guides/rel_notes/release_19_02.rst
index 8deb68b9a..1f9ec9fc1 100644
--- a/doc/guides/rel_notes/release_19_02.rst
+++ b/doc/guides/rel_notes/release_19_02.rst
@@ -156,7 +156,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_kvargs.so.1
librte_latencystats.so.1
librte_lpm.so.2
- librte_mbuf.so.4
+ + librte_mbuf.so.5
librte_member.so.1
librte_mempool.so.5
librte_meter.so.2
@@ -178,7 +178,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_rawdev.so.1
librte_reorder.so.1
librte_ring.so.2
- librte_sched.so.1
+ + librte_sched.so.2
librte_security.so.1
librte_table.so.3
librte_timer.so.1
diff --git a/examples/qos_sched/app_thread.c b/examples/qos_sched/app_thread.c
index a59274236..bec4deee3 100644
--- a/examples/qos_sched/app_thread.c
+++ b/examples/qos_sched/app_thread.c
@@ -73,8 +73,11 @@ app_rx_thread(struct thread_conf **confs)
for(i = 0; i < nb_rx; i++) {
get_pkt_sched(rx_mbufs[i],
&subport, &pipe, &traffic_class, &queue, &color);
- rte_sched_port_pkt_write(rx_mbufs[i], subport, pipe,
- traffic_class, queue, (enum rte_meter_color) color);
+ rte_sched_port_pkt_write(conf->sched_port,
+ rx_mbufs[i],
+ subport, pipe,
+ traffic_class, queue,
+ (enum rte_meter_color) color);
}
if (unlikely(rte_ring_sp_enqueue_bulk(conf->rx_ring,
diff --git a/examples/qos_sched/main.c b/examples/qos_sched/main.c
index e7c97bd64..c0ed16b68 100644
--- a/examples/qos_sched/main.c
+++ b/examples/qos_sched/main.c
@@ -55,6 +55,7 @@ app_main_loop(__attribute__((unused))void *dummy)
flow->rx_thread.rx_port = flow->rx_port;
flow->rx_thread.rx_ring = flow->rx_ring;
flow->rx_thread.rx_queue = flow->rx_queue;
+ flow->rx_thread.sched_port = flow->sched_port;
rx_confs[rx_idx++] = &flow->rx_thread;
diff --git a/lib/librte_eventdev/rte_event_eth_tx_adapter.h b/lib/librte_eventdev/rte_event_eth_tx_adapter.h
index 81456d4a9..2a50656d9 100644
--- a/lib/librte_eventdev/rte_event_eth_tx_adapter.h
+++ b/lib/librte_eventdev/rte_event_eth_tx_adapter.h
@@ -63,13 +63,11 @@
* function can be used to retrieve the adapter's service function ID.
*
* The ethernet port and transmit queue index to transmit the mbuf on are
- * specified using the mbuf port and the higher 16 bits of
- * struct rte_mbuf::hash::sched:hi. The application should use the
- * rte_event_eth_tx_adapter_txq_set() and rte_event_eth_tx_adapter_txq_get()
- * functions to access the transmit queue index since it is expected that the
- * transmit queue will be eventually defined within struct rte_mbuf and using
- * these macros will help with minimizing application impact due to
- * a change in how the transmit queue index is specified.
+ * specified using the mbuf port struct rte_mbuf::hash::txadapter:txq.
+ * The application should use the rte_event_eth_tx_adapter_txq_set()
+ * and rte_event_eth_tx_adapter_txq_get() functions to access the transmit
+ * queue index, using these macros will help with minimizing application
+ * impact due to a change in how the transmit queue index is specified.
*/
#ifdef __cplusplus
@@ -300,8 +298,7 @@ rte_event_eth_tx_adapter_queue_del(uint8_t id,
static __rte_always_inline void __rte_experimental
rte_event_eth_tx_adapter_txq_set(struct rte_mbuf *pkt, uint16_t queue)
{
- uint16_t *p = (uint16_t *)&pkt->hash.sched.hi;
- p[1] = queue;
+ pkt->hash.txadapter.txq = queue;
}
/**
@@ -320,8 +317,7 @@ rte_event_eth_tx_adapter_txq_set(struct rte_mbuf *pkt, uint16_t queue)
static __rte_always_inline uint16_t __rte_experimental
rte_event_eth_tx_adapter_txq_get(struct rte_mbuf *pkt)
{
- uint16_t *p = (uint16_t *)&pkt->hash.sched.hi;
- return p[1];
+ return pkt->hash.txadapter.txq;
}
/**
diff --git a/lib/librte_mbuf/Makefile b/lib/librte_mbuf/Makefile
index e2b98a254..8c4c7d790 100644
--- a/lib/librte_mbuf/Makefile
+++ b/lib/librte_mbuf/Makefile
@@ -11,7 +11,7 @@ LDLIBS += -lrte_eal -lrte_mempool
EXPORT_MAP := rte_mbuf_version.map
-LIBABIVER := 4
+LIBABIVER := 5
# all source are stored in SRCS-y
SRCS-$(CONFIG_RTE_LIBRTE_MBUF) := rte_mbuf.c rte_mbuf_ptype.c rte_mbuf_pool_ops.c
diff --git a/lib/librte_mbuf/meson.build b/lib/librte_mbuf/meson.build
index 94d9c4c96..e37da0250 100644
--- a/lib/librte_mbuf/meson.build
+++ b/lib/librte_mbuf/meson.build
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017 Intel Corporation
-version = 4
+version = 5
sources = files('rte_mbuf.c', 'rte_mbuf_ptype.c', 'rte_mbuf_pool_ops.c')
headers = files('rte_mbuf.h', 'rte_mbuf_ptype.h', 'rte_mbuf_pool_ops.h')
deps += ['mempool']
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 3dbc6695e..8e06187ff 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -468,6 +468,17 @@ __extension__
typedef uint64_t MARKER64[0]; /**< marker that allows us to overwrite 8 bytes
* with a single assignment */
+struct rte_mbuf_sched {
+ uint32_t queue_id; /**< Queue ID. */
+ uint8_t traffic_class;
+ /**< Traffic class ID. Traffic class 0
+ * is the highest priority traffic class.
+ */
+ uint8_t color;
+ /**< Color. @see enum rte_color.*/
+ uint16_t reserved; /**< Reserved. */
+};
+
/**
* The generic rte_mbuf, containing a packet mbuf.
*/
@@ -574,14 +585,16 @@ struct rte_mbuf {
* on PKT_RX_FDIR_* flag in ol_flags.
*/
} fdir; /**< Filter identifier if FDIR enabled */
+ struct rte_mbuf_sched sched;
struct {
- uint32_t lo;
- uint32_t hi;
+ uint32_t reserved1;
+ uint16_t reserved2;
+ uint16_t txq;
/**< The event eth Tx adapter uses this field
* to store Tx queue id.
* @see rte_event_eth_tx_adapter_txq_set()
*/
- } sched; /**< Hierarchical scheduler */
+ } txadapter; /**< Eventdev ethdev Tx adapter */
/**< User defined tags. See rte_distributor_process() */
uint32_t usr;
} hash; /**< hash information */
@@ -2289,6 +2302,106 @@ rte_pktmbuf_linearize(struct rte_mbuf *mbuf)
*/
void rte_pktmbuf_dump(FILE *f, const struct rte_mbuf *m, unsigned dump_len);
+/**
+ * Get the value of mbuf sched queue_id field.
+ */
+static inline uint32_t
+rte_mbuf_sched_queue_get(const struct rte_mbuf *m)
+{
+ return m->hash.sched.queue_id;
+}
+
+/**
+ * Get the value of mbuf sched traffic_class field.
+ */
+static inline uint8_t
+rte_mbuf_sched_traffic_class_get(const struct rte_mbuf *m)
+{
+ return m->hash.sched.traffic_class;
+}
+
+/**
+ * Get the value of mbuf sched color field.
+ */
+static inline uint8_t
+rte_mbuf_sched_color_get(const struct rte_mbuf *m)
+{
+ return m->hash.sched.color;
+}
+
+/**
+ * Get the values of mbuf sched queue_id, traffic_class and color.
+ * @param m
+ * Mbuf to read
+ * @param queue_id
+ * Returns the queue id
+ * @param traffic_class
+ * Returns the traffic class id
+ * @param color
+ * Returns the colour id
+ */
+static inline void
+rte_mbuf_sched_get(const struct rte_mbuf *m, uint32_t *queue_id,
+ uint8_t *traffic_class,
+ uint8_t *color)
+{
+ struct rte_mbuf_sched sched = m->hash.sched;
+
+ *queue_id = sched.queue_id;
+ *traffic_class = sched.traffic_class;
+ *color = sched.color;
+}
+
+/**
+ * Set the mbuf sched queue_id to the defined value.
+ */
+static inline void
+rte_mbuf_sched_queue_set(struct rte_mbuf *m, uint32_t queue_id)
+{
+ m->hash.sched.queue_id = queue_id;
+}
+
+/**
+ * Set the mbuf sched traffic_class id to the defined value.
+ */
+static inline void
+rte_mbuf_sched_traffic_class_set(struct rte_mbuf *m, uint8_t traffic_class)
+{
+ m->hash.sched.traffic_class = traffic_class;
+}
+
+/**
+ * Set the mbuf sched color id to the defined value.
+ */
+static inline void
+rte_mbuf_sched_color_set(struct rte_mbuf *m, uint8_t color)
+{
+ m->hash.sched.color = color;
+}
+
+/**
+ * Set the mbuf sched queue_id, traffic_class and color.
+ * @param m
+ * Mbuf to set
+ * @param queue_id
+ * Queue id value to be set
+ * @param traffic_class
+ * Traffic class id value to be set
+ * @param color
+ * Color id to be set
+ */
+static inline void
+rte_mbuf_sched_set(struct rte_mbuf *m, uint32_t queue_id,
+ uint8_t traffic_class,
+ uint8_t color)
+{
+ m->hash.sched = (struct rte_mbuf_sched){
+ .queue_id = queue_id,
+ .traffic_class = traffic_class,
+ .color = color,
+ };
+}
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_pipeline/rte_table_action.c b/lib/librte_pipeline/rte_table_action.c
index 7c7c8dd82..8a2bb13dc 100644
--- a/lib/librte_pipeline/rte_table_action.c
+++ b/lib/librte_pipeline/rte_table_action.c
@@ -107,14 +107,6 @@ mtr_cfg_check(struct rte_table_action_mtr_config *mtr)
return 0;
}
-#define MBUF_SCHED_QUEUE_TC_COLOR(queue, tc, color) \
- ((uint16_t)((((uint64_t)(queue)) & 0x3) | \
- ((((uint64_t)(tc)) & 0x3) << 2) | \
- ((((uint64_t)(color)) & 0x3) << 4)))
-
-#define MBUF_SCHED_COLOR(sched, color) \
- (((sched) & (~0x30LLU)) | ((color) << 4))
-
struct mtr_trtcm_data {
struct rte_meter_trtcm trtcm;
uint64_t stats[e_RTE_METER_COLORS];
@@ -176,7 +168,7 @@ mtr_data_size(struct rte_table_action_mtr_config *mtr)
struct dscp_table_entry_data {
enum rte_meter_color color;
uint16_t tc;
- uint16_t queue_tc_color;
+ uint16_t tc_queue;
};
struct dscp_table_data {
@@ -319,8 +311,7 @@ pkt_work_mtr(struct rte_mbuf *mbuf,
uint32_t dscp,
uint16_t total_length)
{
- uint64_t drop_mask, sched;
- uint64_t *sched_ptr = (uint64_t *) &mbuf->hash.sched;
+ uint64_t drop_mask;
struct dscp_table_entry_data *dscp_entry = &dscp_table->entry[dscp];
enum rte_meter_color color_in, color_meter, color_policer;
uint32_t tc, mp_id;
@@ -329,7 +320,6 @@ pkt_work_mtr(struct rte_mbuf *mbuf,
color_in = dscp_entry->color;
data += tc;
mp_id = MTR_TRTCM_DATA_METER_PROFILE_ID_GET(data);
- sched = *sched_ptr;
/* Meter */
color_meter = rte_meter_trtcm_color_aware_check(
@@ -346,7 +336,7 @@ pkt_work_mtr(struct rte_mbuf *mbuf,
drop_mask = MTR_TRTCM_DATA_POLICER_ACTION_DROP_GET(data, color_meter);
color_policer =
MTR_TRTCM_DATA_POLICER_ACTION_COLOR_GET(data, color_meter);
- *sched_ptr = MBUF_SCHED_COLOR(sched, color_policer);
+ rte_mbuf_sched_color_set(mbuf, (uint8_t)color_policer);
return drop_mask;
}
@@ -368,9 +358,8 @@ tm_cfg_check(struct rte_table_action_tm_config *tm)
}
struct tm_data {
- uint16_t queue_tc_color;
- uint16_t subport;
- uint32_t pipe;
+ uint32_t queue_id;
+ uint32_t reserved;
} __attribute__((__packed__));
static int
@@ -397,9 +386,9 @@ tm_apply(struct tm_data *data,
return status;
/* Apply */
- data->queue_tc_color = 0;
- data->subport = (uint16_t) p->subport_id;
- data->pipe = p->pipe_id;
+ data->queue_id = p->subport_id <<
+ (__builtin_ctz(cfg->n_pipes_per_subport) + 4) |
+ p->pipe_id << 4;
return 0;
}
@@ -411,12 +400,11 @@ pkt_work_tm(struct rte_mbuf *mbuf,
uint32_t dscp)
{
struct dscp_table_entry_data *dscp_entry = &dscp_table->entry[dscp];
- struct tm_data *sched_ptr = (struct tm_data *) &mbuf->hash.sched;
- struct tm_data sched;
-
- sched = *data;
- sched.queue_tc_color = dscp_entry->queue_tc_color;
- *sched_ptr = sched;
+ uint32_t queue_id = data->queue_id |
+ (dscp_entry->tc << 2) |
+ dscp_entry->tc_queue;
+ rte_mbuf_sched_set(mbuf, queue_id, dscp_entry->tc,
+ (uint8_t)dscp_entry->color);
}
/**
@@ -2580,17 +2568,13 @@ rte_table_action_dscp_table_update(struct rte_table_action *action,
&action->dscp_table.entry[i];
struct rte_table_action_dscp_table_entry *entry =
&table->entry[i];
- uint16_t queue_tc_color =
- MBUF_SCHED_QUEUE_TC_COLOR(entry->tc_queue_id,
- entry->tc_id,
- entry->color);
if ((dscp_mask & (1LLU << i)) == 0)
continue;
data->color = entry->color;
data->tc = entry->tc_id;
- data->queue_tc_color = queue_tc_color;
+ data->tc_queue = entry->tc_queue_id;
}
return 0;
diff --git a/lib/librte_sched/Makefile b/lib/librte_sched/Makefile
index 46c53ed71..644fd9d15 100644
--- a/lib/librte_sched/Makefile
+++ b/lib/librte_sched/Makefile
@@ -18,7 +18,7 @@ LDLIBS += -lrte_timer
EXPORT_MAP := rte_sched_version.map
-LIBABIVER := 1
+LIBABIVER := 2
#
# all source are stored in SRCS-y
diff --git a/lib/librte_sched/meson.build b/lib/librte_sched/meson.build
index f85d64df8..8e989e5f6 100644
--- a/lib/librte_sched/meson.build
+++ b/lib/librte_sched/meson.build
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017 Intel Corporation
+version = 2
sources = files('rte_sched.c', 'rte_red.c', 'rte_approx.c')
headers = files('rte_sched.h', 'rte_sched_common.h',
'rte_red.h', 'rte_approx.h')
diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c
index 587d5e602..dd7739172 100644
--- a/lib/librte_sched/rte_sched.c
+++ b/lib/librte_sched/rte_sched.c
@@ -128,22 +128,6 @@ enum grinder_state {
e_GRINDER_READ_MBUF
};
-/*
- * Path through the scheduler hierarchy used by the scheduler enqueue
- * operation to identify the destination queue for the current
- * packet. Stored in the field pkt.hash.sched of struct rte_mbuf of
- * each packet, typically written by the classification stage and read
- * by scheduler enqueue.
- */
-struct rte_sched_port_hierarchy {
- uint16_t queue:2; /**< Queue ID (0 .. 3) */
- uint16_t traffic_class:2; /**< Traffic class ID (0 .. 3)*/
- uint32_t color:2; /**< Color */
- uint16_t unused:10;
- uint16_t subport; /**< Subport ID */
- uint32_t pipe; /**< Pipe ID */
-};
-
struct rte_sched_grinder {
/* Pipe cache */
uint16_t pcache_qmask[RTE_SCHED_GRINDER_PCACHE_SIZE];
@@ -185,6 +169,7 @@ struct rte_sched_port {
/* User parameters */
uint32_t n_subports_per_port;
uint32_t n_pipes_per_subport;
+ uint32_t n_pipes_per_subport_log2;
uint32_t rate;
uint32_t mtu;
uint32_t frame_overhead;
@@ -645,6 +630,8 @@ rte_sched_port_config(struct rte_sched_port_params *params)
/* User parameters */
port->n_subports_per_port = params->n_subports_per_port;
port->n_pipes_per_subport = params->n_pipes_per_subport;
+ port->n_pipes_per_subport_log2 =
+ __builtin_ctz(params->n_pipes_per_subport);
port->rate = params->rate;
port->mtu = params->mtu + params->frame_overhead;
port->frame_overhead = params->frame_overhead;
@@ -1006,44 +993,52 @@ rte_sched_port_pipe_profile_add(struct rte_sched_port *port,
return 0;
}
+static inline uint32_t
+rte_sched_port_qindex(struct rte_sched_port *port,
+ uint32_t subport,
+ uint32_t pipe,
+ uint32_t traffic_class,
+ uint32_t queue)
+{
+ return ((subport & (port->n_subports_per_port - 1)) <<
+ (port->n_pipes_per_subport_log2 + 4)) |
+ ((pipe & (port->n_pipes_per_subport - 1)) << 4) |
+ ((traffic_class &
+ (RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE - 1)) << 2) |
+ (queue & (RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS - 1));
+}
+
void
-rte_sched_port_pkt_write(struct rte_mbuf *pkt,
- uint32_t subport, uint32_t pipe, uint32_t traffic_class,
+rte_sched_port_pkt_write(struct rte_sched_port *port,
+ struct rte_mbuf *pkt,
+ uint32_t subport, uint32_t pipe,
+ uint32_t traffic_class,
uint32_t queue, enum rte_meter_color color)
{
- struct rte_sched_port_hierarchy *sched
- = (struct rte_sched_port_hierarchy *) &pkt->hash.sched;
-
- RTE_BUILD_BUG_ON(sizeof(*sched) > sizeof(pkt->hash.sched));
-
- sched->color = (uint32_t) color;
- sched->subport = subport;
- sched->pipe = pipe;
- sched->traffic_class = traffic_class;
- sched->queue = queue;
+ uint32_t queue_id = rte_sched_port_qindex(port, subport, pipe,
+ traffic_class, queue);
+ rte_mbuf_sched_set(pkt, queue_id, traffic_class, (uint8_t)color);
}
void
-rte_sched_port_pkt_read_tree_path(const struct rte_mbuf *pkt,
+rte_sched_port_pkt_read_tree_path(struct rte_sched_port *port,
+ const struct rte_mbuf *pkt,
uint32_t *subport, uint32_t *pipe,
uint32_t *traffic_class, uint32_t *queue)
{
- const struct rte_sched_port_hierarchy *sched
- = (const struct rte_sched_port_hierarchy *) &pkt->hash.sched;
+ uint32_t queue_id = rte_mbuf_sched_queue_get(pkt);
- *subport = sched->subport;
- *pipe = sched->pipe;
- *traffic_class = sched->traffic_class;
- *queue = sched->queue;
+ *subport = queue_id >> (port->n_pipes_per_subport_log2 + 4);
+ *pipe = (queue_id >> 4) & (port->n_pipes_per_subport - 1);
+ *traffic_class = (queue_id >> 2) &
+ (RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE - 1);
+ *queue = queue_id & (RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS - 1);
}
enum rte_meter_color
rte_sched_port_pkt_read_color(const struct rte_mbuf *pkt)
{
- const struct rte_sched_port_hierarchy *sched
- = (const struct rte_sched_port_hierarchy *) &pkt->hash.sched;
-
- return (enum rte_meter_color) sched->color;
+ return (enum rte_meter_color)rte_mbuf_sched_color_get(pkt);
}
int
@@ -1100,18 +1095,6 @@ rte_sched_queue_read_stats(struct rte_sched_port *port,
return 0;
}
-static inline uint32_t
-rte_sched_port_qindex(struct rte_sched_port *port, uint32_t subport, uint32_t pipe, uint32_t traffic_class, uint32_t queue)
-{
- uint32_t result;
-
- result = subport * port->n_pipes_per_subport + pipe;
- result = result * RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE + traffic_class;
- result = result * RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS + queue;
-
- return result;
-}
-
#ifdef RTE_SCHED_DEBUG
static inline int
@@ -1272,11 +1255,8 @@ rte_sched_port_enqueue_qptrs_prefetch0(struct rte_sched_port *port,
#ifdef RTE_SCHED_COLLECT_STATS
struct rte_sched_queue_extra *qe;
#endif
- uint32_t subport, pipe, traffic_class, queue, qindex;
-
- rte_sched_port_pkt_read_tree_path(pkt, &subport, &pipe, &traffic_class, &queue);
+ uint32_t qindex = rte_mbuf_sched_queue_get(pkt);
- qindex = rte_sched_port_qindex(port, subport, pipe, traffic_class, queue);
q = port->queue + qindex;
rte_prefetch0(q);
#ifdef RTE_SCHED_COLLECT_STATS
diff --git a/lib/librte_sched/rte_sched.h b/lib/librte_sched/rte_sched.h
index 84fa896de..243efa1d4 100644
--- a/lib/librte_sched/rte_sched.h
+++ b/lib/librte_sched/rte_sched.h
@@ -355,6 +355,8 @@ rte_sched_queue_read_stats(struct rte_sched_port *port,
* Scheduler hierarchy path write to packet descriptor. Typically
* called by the packet classification stage.
*
+ * @param port
+ * Handle to port scheduler instance
* @param pkt
* Packet descriptor handle
* @param subport
@@ -369,7 +371,8 @@ rte_sched_queue_read_stats(struct rte_sched_port *port,
* Packet color set
*/
void
-rte_sched_port_pkt_write(struct rte_mbuf *pkt,
+rte_sched_port_pkt_write(struct rte_sched_port *port,
+ struct rte_mbuf *pkt,
uint32_t subport, uint32_t pipe, uint32_t traffic_class,
uint32_t queue, enum rte_meter_color color);
@@ -379,6 +382,8 @@ rte_sched_port_pkt_write(struct rte_mbuf *pkt,
* enqueue operation. The subport, pipe, traffic class and queue
* parameters need to be pre-allocated by the caller.
*
+ * @param port
+ * Handle to port scheduler instance
* @param pkt
* Packet descriptor handle
* @param subport
@@ -392,7 +397,8 @@ rte_sched_port_pkt_write(struct rte_mbuf *pkt,
*
*/
void
-rte_sched_port_pkt_read_tree_path(const struct rte_mbuf *pkt,
+rte_sched_port_pkt_read_tree_path(struct rte_sched_port *port,
+ const struct rte_mbuf *pkt,
uint32_t *subport, uint32_t *pipe,
uint32_t *traffic_class, uint32_t *queue);
diff --git a/test/test/test_sched.c b/test/test/test_sched.c
index 32e500ba9..40e411cab 100644
--- a/test/test/test_sched.c
+++ b/test/test/test_sched.c
@@ -76,7 +76,7 @@ create_mempool(void)
}
static void
-prepare_pkt(struct rte_mbuf *mbuf)
+prepare_pkt(struct rte_sched_port *port, struct rte_mbuf *mbuf)
{
struct ether_hdr *eth_hdr;
struct vlan_hdr *vlan1, *vlan2;
@@ -95,7 +95,8 @@ prepare_pkt(struct rte_mbuf *mbuf)
ip_hdr->dst_addr = IPv4(0,0,TC,QUEUE);
- rte_sched_port_pkt_write(mbuf, SUBPORT, PIPE, TC, QUEUE, e_RTE_METER_YELLOW);
+ rte_sched_port_pkt_write(port, mbuf, SUBPORT, PIPE, TC, QUEUE,
+ e_RTE_METER_YELLOW);
/* 64 byte packet */
mbuf->pkt_len = 60;
@@ -138,7 +139,7 @@ test_sched(void)
for (i = 0; i < 10; i++) {
in_mbufs[i] = rte_pktmbuf_alloc(mp);
TEST_ASSERT_NOT_NULL(in_mbufs[i], "Packet allocation failed\n");
- prepare_pkt(in_mbufs[i]);
+ prepare_pkt(port, in_mbufs[i]);
}
@@ -155,7 +156,7 @@ test_sched(void)
color = rte_sched_port_pkt_read_color(out_mbufs[i]);
TEST_ASSERT_EQUAL(color, e_RTE_METER_YELLOW, "Wrong color\n");
- rte_sched_port_pkt_read_tree_path(out_mbufs[i],
+ rte_sched_port_pkt_read_tree_path(port, out_mbufs[i],
&subport, &pipe, &traffic_class, &queue);
TEST_ASSERT_EQUAL(subport, SUBPORT, "Wrong subport\n");
--
2.17.1
^ permalink raw reply [flat|nested] 74+ messages in thread* [dpdk-dev] [PATCH v6 1/2] meter: add new rte color definition
2018-12-19 15:34 ` [dpdk-dev] [PATCH v5 1/2] meter: add new rte color definition Reshma Pattan
2018-12-19 15:34 ` [dpdk-dev] [PATCH v5 2/2] mbuf: implement generic format for sched field Reshma Pattan
@ 2018-12-19 15:42 ` Reshma Pattan
2018-12-19 15:42 ` [dpdk-dev] [PATCH v6 2/2] mbuf: implement generic format for sched field Reshma Pattan
2018-12-20 12:16 ` [dpdk-dev] [PATCH v7 1/2] meter: add new rte color definition Reshma Pattan
1 sibling, 2 replies; 74+ messages in thread
From: Reshma Pattan @ 2018-12-19 15:42 UTC (permalink / raw)
To: dev, jerin.jacob, nikhil.rao, olivier.matz, thomas,
jasvinder.singh, cristian.dumitrescu
Cc: Reshma Pattan
Added new rte_color definition in librte_meter to
consolidate color definition which is currently replicated
in various places such as rte_meter.h, rte_tm.h and rte_mtr.h
Created aliases for rte_tm_color, rte_mtr_color and rte_meter_color
to use new rte_color values.
The definitions of rte_tm_color, rte_mtr_color and rte_meter_color
will be deprecated in future.
Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
---
v5: Removed meter library from librte_mbuf dependency list.
v4: Removed rte_meter, rte_mtr and rte_tm color definitions.
Moved rte_color definition from eal to meter library.
v3:Addressed review comments given in the below link
http://patches.dpdk.org/patch/48588/
Added rte_color.h to meson build.
---
---
lib/Makefile | 1 +
lib/librte_ethdev/Makefile | 2 +-
lib/librte_ethdev/meson.build | 2 +-
lib/librte_ethdev/rte_mtr.h | 16 +++++++---------
lib/librte_ethdev/rte_tm.h | 16 +++++++---------
lib/librte_meter/rte_meter.h | 21 +++++++++++++++------
lib/meson.build | 4 ++--
7 files changed, 34 insertions(+), 28 deletions(-)
diff --git a/lib/Makefile b/lib/Makefile
index b7370ef97..8dbdc9bca 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -26,6 +26,7 @@ DEPDIRS-librte_ethdev := librte_net librte_eal librte_mempool librte_ring
DEPDIRS-librte_ethdev += librte_mbuf
DEPDIRS-librte_ethdev += librte_kvargs
DEPDIRS-librte_ethdev += librte_cmdline
+DEPDIRS-librte_ethdev += librte_meter
DIRS-$(CONFIG_RTE_LIBRTE_BBDEV) += librte_bbdev
DEPDIRS-librte_bbdev := librte_eal librte_mempool librte_mbuf
DIRS-$(CONFIG_RTE_LIBRTE_CRYPTODEV) += librte_cryptodev
diff --git a/lib/librte_ethdev/Makefile b/lib/librte_ethdev/Makefile
index 3e27ae466..e09c4263a 100644
--- a/lib/librte_ethdev/Makefile
+++ b/lib/librte_ethdev/Makefile
@@ -12,7 +12,7 @@ CFLAGS += -DALLOW_EXPERIMENTAL_API
CFLAGS += -O3
CFLAGS += $(WERROR_FLAGS)
LDLIBS += -lrte_net -lrte_eal -lrte_mempool -lrte_ring
-LDLIBS += -lrte_mbuf -lrte_kvargs -lrte_cmdline
+LDLIBS += -lrte_mbuf -lrte_kvargs -lrte_cmdline -lrte_meter
EXPORT_MAP := rte_ethdev_version.map
diff --git a/lib/librte_ethdev/meson.build b/lib/librte_ethdev/meson.build
index a4d850268..e98942ff8 100644
--- a/lib/librte_ethdev/meson.build
+++ b/lib/librte_ethdev/meson.build
@@ -26,4 +26,4 @@ headers = files('rte_ethdev.h',
'rte_tm.h',
'rte_tm_driver.h')
-deps += ['net', 'kvargs', 'cmdline']
+deps += ['net', 'kvargs', 'cmdline', 'meter']
diff --git a/lib/librte_ethdev/rte_mtr.h b/lib/librte_ethdev/rte_mtr.h
index c4819b274..c667f87e1 100644
--- a/lib/librte_ethdev/rte_mtr.h
+++ b/lib/librte_ethdev/rte_mtr.h
@@ -76,20 +76,18 @@
#include <stdint.h>
#include <rte_compat.h>
#include <rte_common.h>
+#include <rte_meter.h>
#ifdef __cplusplus
extern "C" {
#endif
-/**
- * Color
- */
-enum rte_mtr_color {
- RTE_MTR_GREEN = 0, /**< Green */
- RTE_MTR_YELLOW, /**< Yellow */
- RTE_MTR_RED, /**< Red */
- RTE_MTR_COLORS /**< Number of colors. */
-};
+/* New rte_color is defined and used to deprecate rte_mtr_color soon. */
+#define rte_mtr_color rte_color
+#define RTE_MTR_GREEN RTE_COLOR_GREEN
+#define RTE_MTR_YELLOW RTE_COLOR_YELLOW
+#define RTE_MTR_RED RTE_COLOR_RED
+#define RTE_MTR_COLORS RTE_COLORS
/**
* Statistics counter type
diff --git a/lib/librte_ethdev/rte_tm.h b/lib/librte_ethdev/rte_tm.h
index 646ef3880..c4a788b85 100644
--- a/lib/librte_ethdev/rte_tm.h
+++ b/lib/librte_ethdev/rte_tm.h
@@ -51,6 +51,7 @@
#include <stdint.h>
#include <rte_common.h>
+#include <rte_meter.h>
#ifdef __cplusplus
extern "C" {
@@ -115,15 +116,12 @@ extern "C" {
*/
#define RTE_TM_NODE_LEVEL_ID_ANY UINT32_MAX
-/**
- * Color
- */
-enum rte_tm_color {
- RTE_TM_GREEN = 0, /**< Green */
- RTE_TM_YELLOW, /**< Yellow */
- RTE_TM_RED, /**< Red */
- RTE_TM_COLORS /**< Number of colors */
-};
+/* New rte_color is defined and used to deprecate rte_tm_color soon. */
+#define rte_tm_color rte_color
+#define RTE_TM_GREEN RTE_COLOR_GREEN
+#define RTE_TM_YELLOW RTE_COLOR_YELLOW
+#define RTE_TM_RED RTE_COLOR_RED
+#define RTE_TM_COLORS RTE_COLORS
/**
* Node statistics counter type
diff --git a/lib/librte_meter/rte_meter.h b/lib/librte_meter/rte_meter.h
index 58a051583..c2ea47332 100644
--- a/lib/librte_meter/rte_meter.h
+++ b/lib/librte_meter/rte_meter.h
@@ -26,14 +26,23 @@ extern "C" {
*
***/
-/** Packet Color Set */
-enum rte_meter_color {
- e_RTE_METER_GREEN = 0, /**< Green */
- e_RTE_METER_YELLOW, /**< Yellow */
- e_RTE_METER_RED, /**< Red */
- e_RTE_METER_COLORS /**< Number of available colors */
+/**
+ * Color
+ */
+enum rte_color {
+ RTE_COLOR_GREEN = 0, /**< Green */
+ RTE_COLOR_YELLOW, /**< Yellow */
+ RTE_COLOR_RED, /**< Red */
+ RTE_COLORS /**< Number of colors */
};
+/* New rte_color is defined and used to deprecate rte_meter_color soon. */
+#define rte_meter_color rte_color
+#define e_RTE_METER_GREEN RTE_COLOR_GREEN
+#define e_RTE_METER_YELLOW RTE_COLOR_YELLOW
+#define e_RTE_METER_RED RTE_COLOR_RED
+#define e_RTE_METER_COLORS RTE_COLORS
+
/** srTCM parameters per metered traffic flow. The CIR, CBS and EBS parameters only
count bytes of IP packets and do not include link specific headers. At least one of
the CBS or EBS parameters has to be greater than zero. */
diff --git a/lib/meson.build b/lib/meson.build
index bb7f443f9..a2dd52e17 100644
--- a/lib/meson.build
+++ b/lib/meson.build
@@ -11,7 +11,7 @@
libraries = [ 'compat', # just a header, used for versioning
'cmdline', # ethdev depends on cmdline for parsing functions
'kvargs', # eal depends on kvargs
- 'eal', 'ring', 'mempool', 'mbuf', 'net', 'ethdev', 'pci', # core
+ 'eal', 'ring', 'mempool', 'mbuf', 'net', 'meter', 'ethdev', 'pci', # core
'metrics', # bitrate/latency stats depends on this
'hash', # efd depends on this
'timer', # eventdev depends on this
@@ -20,7 +20,7 @@ libraries = [ 'compat', # just a header, used for versioning
'distributor', 'efd', 'eventdev',
'gro', 'gso', 'ip_frag', 'jobstats',
'kni', 'latencystats', 'lpm', 'member',
- 'meter', 'power', 'pdump', 'rawdev',
+ 'power', 'pdump', 'rawdev',
'reorder', 'sched', 'security', 'vhost',
# add pkt framework libs which use other libs from above
'port', 'table', 'pipeline',
--
2.17.1
^ permalink raw reply [flat|nested] 74+ messages in thread* [dpdk-dev] [PATCH v6 2/2] mbuf: implement generic format for sched field
2018-12-19 15:42 ` [dpdk-dev] [PATCH v6 1/2] meter: add new rte color definition Reshma Pattan
@ 2018-12-19 15:42 ` Reshma Pattan
2018-12-19 18:14 ` Ananyev, Konstantin
2018-12-20 8:29 ` Olivier Matz
2018-12-20 12:16 ` [dpdk-dev] [PATCH v7 1/2] meter: add new rte color definition Reshma Pattan
1 sibling, 2 replies; 74+ messages in thread
From: Reshma Pattan @ 2018-12-19 15:42 UTC (permalink / raw)
To: dev, jerin.jacob, nikhil.rao, olivier.matz, thomas,
jasvinder.singh, cristian.dumitrescu
Cc: Reshma Pattan
This patch implements the changes proposed in the deprecation
notes [1][2].
librte_mbuf changes:
The mbuf::hash::sched field is updated to support generic
definition in line with the ethdev TM and MTR APIs. The new generic
format contains: queue ID, traffic class, color.
Added public APIs to set and get these new fields to and from mbuf.
librte_sched changes:
In addtion, following API functions of the sched library have
been modified with an additional parameter of type struct
rte_sched_port to accommodate the changes made to mbuf sched field.
(i)rte_sched_port_pkt_write()
(ii) rte_sched_port_pkt_read_tree_path()
librte_pipeline, qos_sched UT, qos_sched app are updated
to make use of new changes.
Also mbuf::hash::txadapter has been added for eventdev txq,
rte_event_eth_tx_adapter_txq_set and rte_event_eth_tx_adapter_txq_get()
are updated to use uses mbuf::hash::txadapter.txq.
doc:
Release notes updated.
Removed deprecation notice for mbuf::hash::sched and sched API.
[1] http://mails.dpdk.org/archives/dev/2018-February/090651.html
[2] https://mails.dpdk.org/archives/dev/2018-November/119051.html
Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
---
v6: added scheduler comment
v5:
Removed librte_meter from librte_mbuf dependency list.
Changed the mbuf set/get functions to use uint8_t for color.
v4: converted mbuf::hash::sched as instantiation of rte_mbuf_sched.
v3: addressed review comments given in the below link.
http://patches.dpdk.org/patch/48587/
Updated library ABI versioning in meson build.
---
---
doc/guides/rel_notes/deprecation.rst | 10 --
doc/guides/rel_notes/release_19_02.rst | 4 +-
examples/qos_sched/app_thread.c | 7 +-
examples/qos_sched/main.c | 1 +
.../rte_event_eth_tx_adapter.h | 18 ++-
lib/librte_mbuf/Makefile | 2 +-
lib/librte_mbuf/meson.build | 2 +-
lib/librte_mbuf/rte_mbuf.h | 119 +++++++++++++++++-
lib/librte_pipeline/rte_table_action.c | 44 +++----
lib/librte_sched/Makefile | 2 +-
lib/librte_sched/meson.build | 1 +
lib/librte_sched/rte_sched.c | 90 ++++++-------
lib/librte_sched/rte_sched.h | 10 +-
test/test/test_sched.c | 9 +-
14 files changed, 197 insertions(+), 122 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index ac7fb29a7..ec80dcc7b 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -49,16 +49,6 @@ Deprecation Notices
structure would be made internal (or removed if all dependencies are cleared)
in future releases.
-* mbuf: The opaque ``mbuf->hash.sched`` field will be updated to support generic
- definition in line with the ethdev TM and MTR APIs. Currently, this field
- is defined in librte_sched in a non-generic way. The new generic format
- will contain: queue ID, traffic class, color. Field size will not change.
-
-* sched: Some API functions will change prototype due to the above
- deprecation note for mbuf->hash.sched, e.g. ``rte_sched_port_pkt_write()``
- and ``rte_sched_port_pkt_read()`` will likely have an additional parameter
- of type ``struct rte_sched_port``.
-
* mbuf: the macro ``RTE_MBUF_INDIRECT()`` will be removed in v18.08 or later and
replaced with ``RTE_MBUF_CLONED()`` which is already added in v18.05. As
``EXT_ATTACHED_MBUF`` is newly introduced in v18.05, ``RTE_MBUF_INDIRECT()``
diff --git a/doc/guides/rel_notes/release_19_02.rst b/doc/guides/rel_notes/release_19_02.rst
index 8deb68b9a..1f9ec9fc1 100644
--- a/doc/guides/rel_notes/release_19_02.rst
+++ b/doc/guides/rel_notes/release_19_02.rst
@@ -156,7 +156,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_kvargs.so.1
librte_latencystats.so.1
librte_lpm.so.2
- librte_mbuf.so.4
+ + librte_mbuf.so.5
librte_member.so.1
librte_mempool.so.5
librte_meter.so.2
@@ -178,7 +178,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_rawdev.so.1
librte_reorder.so.1
librte_ring.so.2
- librte_sched.so.1
+ + librte_sched.so.2
librte_security.so.1
librte_table.so.3
librte_timer.so.1
diff --git a/examples/qos_sched/app_thread.c b/examples/qos_sched/app_thread.c
index a59274236..bec4deee3 100644
--- a/examples/qos_sched/app_thread.c
+++ b/examples/qos_sched/app_thread.c
@@ -73,8 +73,11 @@ app_rx_thread(struct thread_conf **confs)
for(i = 0; i < nb_rx; i++) {
get_pkt_sched(rx_mbufs[i],
&subport, &pipe, &traffic_class, &queue, &color);
- rte_sched_port_pkt_write(rx_mbufs[i], subport, pipe,
- traffic_class, queue, (enum rte_meter_color) color);
+ rte_sched_port_pkt_write(conf->sched_port,
+ rx_mbufs[i],
+ subport, pipe,
+ traffic_class, queue,
+ (enum rte_meter_color) color);
}
if (unlikely(rte_ring_sp_enqueue_bulk(conf->rx_ring,
diff --git a/examples/qos_sched/main.c b/examples/qos_sched/main.c
index e7c97bd64..c0ed16b68 100644
--- a/examples/qos_sched/main.c
+++ b/examples/qos_sched/main.c
@@ -55,6 +55,7 @@ app_main_loop(__attribute__((unused))void *dummy)
flow->rx_thread.rx_port = flow->rx_port;
flow->rx_thread.rx_ring = flow->rx_ring;
flow->rx_thread.rx_queue = flow->rx_queue;
+ flow->rx_thread.sched_port = flow->sched_port;
rx_confs[rx_idx++] = &flow->rx_thread;
diff --git a/lib/librte_eventdev/rte_event_eth_tx_adapter.h b/lib/librte_eventdev/rte_event_eth_tx_adapter.h
index 81456d4a9..2a50656d9 100644
--- a/lib/librte_eventdev/rte_event_eth_tx_adapter.h
+++ b/lib/librte_eventdev/rte_event_eth_tx_adapter.h
@@ -63,13 +63,11 @@
* function can be used to retrieve the adapter's service function ID.
*
* The ethernet port and transmit queue index to transmit the mbuf on are
- * specified using the mbuf port and the higher 16 bits of
- * struct rte_mbuf::hash::sched:hi. The application should use the
- * rte_event_eth_tx_adapter_txq_set() and rte_event_eth_tx_adapter_txq_get()
- * functions to access the transmit queue index since it is expected that the
- * transmit queue will be eventually defined within struct rte_mbuf and using
- * these macros will help with minimizing application impact due to
- * a change in how the transmit queue index is specified.
+ * specified using the mbuf port struct rte_mbuf::hash::txadapter:txq.
+ * The application should use the rte_event_eth_tx_adapter_txq_set()
+ * and rte_event_eth_tx_adapter_txq_get() functions to access the transmit
+ * queue index, using these macros will help with minimizing application
+ * impact due to a change in how the transmit queue index is specified.
*/
#ifdef __cplusplus
@@ -300,8 +298,7 @@ rte_event_eth_tx_adapter_queue_del(uint8_t id,
static __rte_always_inline void __rte_experimental
rte_event_eth_tx_adapter_txq_set(struct rte_mbuf *pkt, uint16_t queue)
{
- uint16_t *p = (uint16_t *)&pkt->hash.sched.hi;
- p[1] = queue;
+ pkt->hash.txadapter.txq = queue;
}
/**
@@ -320,8 +317,7 @@ rte_event_eth_tx_adapter_txq_set(struct rte_mbuf *pkt, uint16_t queue)
static __rte_always_inline uint16_t __rte_experimental
rte_event_eth_tx_adapter_txq_get(struct rte_mbuf *pkt)
{
- uint16_t *p = (uint16_t *)&pkt->hash.sched.hi;
- return p[1];
+ return pkt->hash.txadapter.txq;
}
/**
diff --git a/lib/librte_mbuf/Makefile b/lib/librte_mbuf/Makefile
index e2b98a254..8c4c7d790 100644
--- a/lib/librte_mbuf/Makefile
+++ b/lib/librte_mbuf/Makefile
@@ -11,7 +11,7 @@ LDLIBS += -lrte_eal -lrte_mempool
EXPORT_MAP := rte_mbuf_version.map
-LIBABIVER := 4
+LIBABIVER := 5
# all source are stored in SRCS-y
SRCS-$(CONFIG_RTE_LIBRTE_MBUF) := rte_mbuf.c rte_mbuf_ptype.c rte_mbuf_pool_ops.c
diff --git a/lib/librte_mbuf/meson.build b/lib/librte_mbuf/meson.build
index 94d9c4c96..e37da0250 100644
--- a/lib/librte_mbuf/meson.build
+++ b/lib/librte_mbuf/meson.build
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017 Intel Corporation
-version = 4
+version = 5
sources = files('rte_mbuf.c', 'rte_mbuf_ptype.c', 'rte_mbuf_pool_ops.c')
headers = files('rte_mbuf.h', 'rte_mbuf_ptype.h', 'rte_mbuf_pool_ops.h')
deps += ['mempool']
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 3dbc6695e..dd69123a1 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -468,6 +468,17 @@ __extension__
typedef uint64_t MARKER64[0]; /**< marker that allows us to overwrite 8 bytes
* with a single assignment */
+struct rte_mbuf_sched {
+ uint32_t queue_id; /**< Queue ID. */
+ uint8_t traffic_class;
+ /**< Traffic class ID. Traffic class 0
+ * is the highest priority traffic class.
+ */
+ uint8_t color;
+ /**< Color. @see enum rte_color.*/
+ uint16_t reserved; /**< Reserved. */
+};
+
/**
* The generic rte_mbuf, containing a packet mbuf.
*/
@@ -574,14 +585,16 @@ struct rte_mbuf {
* on PKT_RX_FDIR_* flag in ol_flags.
*/
} fdir; /**< Filter identifier if FDIR enabled */
+ struct rte_mbuf_sched sched; /**< Hierarchical scheduler */
struct {
- uint32_t lo;
- uint32_t hi;
+ uint32_t reserved1;
+ uint16_t reserved2;
+ uint16_t txq;
/**< The event eth Tx adapter uses this field
* to store Tx queue id.
* @see rte_event_eth_tx_adapter_txq_set()
*/
- } sched; /**< Hierarchical scheduler */
+ } txadapter; /**< Eventdev ethdev Tx adapter */
/**< User defined tags. See rte_distributor_process() */
uint32_t usr;
} hash; /**< hash information */
@@ -2289,6 +2302,106 @@ rte_pktmbuf_linearize(struct rte_mbuf *mbuf)
*/
void rte_pktmbuf_dump(FILE *f, const struct rte_mbuf *m, unsigned dump_len);
+/**
+ * Get the value of mbuf sched queue_id field.
+ */
+static inline uint32_t
+rte_mbuf_sched_queue_get(const struct rte_mbuf *m)
+{
+ return m->hash.sched.queue_id;
+}
+
+/**
+ * Get the value of mbuf sched traffic_class field.
+ */
+static inline uint8_t
+rte_mbuf_sched_traffic_class_get(const struct rte_mbuf *m)
+{
+ return m->hash.sched.traffic_class;
+}
+
+/**
+ * Get the value of mbuf sched color field.
+ */
+static inline uint8_t
+rte_mbuf_sched_color_get(const struct rte_mbuf *m)
+{
+ return m->hash.sched.color;
+}
+
+/**
+ * Get the values of mbuf sched queue_id, traffic_class and color.
+ * @param m
+ * Mbuf to read
+ * @param queue_id
+ * Returns the queue id
+ * @param traffic_class
+ * Returns the traffic class id
+ * @param color
+ * Returns the colour id
+ */
+static inline void
+rte_mbuf_sched_get(const struct rte_mbuf *m, uint32_t *queue_id,
+ uint8_t *traffic_class,
+ uint8_t *color)
+{
+ struct rte_mbuf_sched sched = m->hash.sched;
+
+ *queue_id = sched.queue_id;
+ *traffic_class = sched.traffic_class;
+ *color = sched.color;
+}
+
+/**
+ * Set the mbuf sched queue_id to the defined value.
+ */
+static inline void
+rte_mbuf_sched_queue_set(struct rte_mbuf *m, uint32_t queue_id)
+{
+ m->hash.sched.queue_id = queue_id;
+}
+
+/**
+ * Set the mbuf sched traffic_class id to the defined value.
+ */
+static inline void
+rte_mbuf_sched_traffic_class_set(struct rte_mbuf *m, uint8_t traffic_class)
+{
+ m->hash.sched.traffic_class = traffic_class;
+}
+
+/**
+ * Set the mbuf sched color id to the defined value.
+ */
+static inline void
+rte_mbuf_sched_color_set(struct rte_mbuf *m, uint8_t color)
+{
+ m->hash.sched.color = color;
+}
+
+/**
+ * Set the mbuf sched queue_id, traffic_class and color.
+ * @param m
+ * Mbuf to set
+ * @param queue_id
+ * Queue id value to be set
+ * @param traffic_class
+ * Traffic class id value to be set
+ * @param color
+ * Color id to be set
+ */
+static inline void
+rte_mbuf_sched_set(struct rte_mbuf *m, uint32_t queue_id,
+ uint8_t traffic_class,
+ uint8_t color)
+{
+ m->hash.sched = (struct rte_mbuf_sched){
+ .queue_id = queue_id,
+ .traffic_class = traffic_class,
+ .color = color,
+ };
+}
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_pipeline/rte_table_action.c b/lib/librte_pipeline/rte_table_action.c
index 7c7c8dd82..8a2bb13dc 100644
--- a/lib/librte_pipeline/rte_table_action.c
+++ b/lib/librte_pipeline/rte_table_action.c
@@ -107,14 +107,6 @@ mtr_cfg_check(struct rte_table_action_mtr_config *mtr)
return 0;
}
-#define MBUF_SCHED_QUEUE_TC_COLOR(queue, tc, color) \
- ((uint16_t)((((uint64_t)(queue)) & 0x3) | \
- ((((uint64_t)(tc)) & 0x3) << 2) | \
- ((((uint64_t)(color)) & 0x3) << 4)))
-
-#define MBUF_SCHED_COLOR(sched, color) \
- (((sched) & (~0x30LLU)) | ((color) << 4))
-
struct mtr_trtcm_data {
struct rte_meter_trtcm trtcm;
uint64_t stats[e_RTE_METER_COLORS];
@@ -176,7 +168,7 @@ mtr_data_size(struct rte_table_action_mtr_config *mtr)
struct dscp_table_entry_data {
enum rte_meter_color color;
uint16_t tc;
- uint16_t queue_tc_color;
+ uint16_t tc_queue;
};
struct dscp_table_data {
@@ -319,8 +311,7 @@ pkt_work_mtr(struct rte_mbuf *mbuf,
uint32_t dscp,
uint16_t total_length)
{
- uint64_t drop_mask, sched;
- uint64_t *sched_ptr = (uint64_t *) &mbuf->hash.sched;
+ uint64_t drop_mask;
struct dscp_table_entry_data *dscp_entry = &dscp_table->entry[dscp];
enum rte_meter_color color_in, color_meter, color_policer;
uint32_t tc, mp_id;
@@ -329,7 +320,6 @@ pkt_work_mtr(struct rte_mbuf *mbuf,
color_in = dscp_entry->color;
data += tc;
mp_id = MTR_TRTCM_DATA_METER_PROFILE_ID_GET(data);
- sched = *sched_ptr;
/* Meter */
color_meter = rte_meter_trtcm_color_aware_check(
@@ -346,7 +336,7 @@ pkt_work_mtr(struct rte_mbuf *mbuf,
drop_mask = MTR_TRTCM_DATA_POLICER_ACTION_DROP_GET(data, color_meter);
color_policer =
MTR_TRTCM_DATA_POLICER_ACTION_COLOR_GET(data, color_meter);
- *sched_ptr = MBUF_SCHED_COLOR(sched, color_policer);
+ rte_mbuf_sched_color_set(mbuf, (uint8_t)color_policer);
return drop_mask;
}
@@ -368,9 +358,8 @@ tm_cfg_check(struct rte_table_action_tm_config *tm)
}
struct tm_data {
- uint16_t queue_tc_color;
- uint16_t subport;
- uint32_t pipe;
+ uint32_t queue_id;
+ uint32_t reserved;
} __attribute__((__packed__));
static int
@@ -397,9 +386,9 @@ tm_apply(struct tm_data *data,
return status;
/* Apply */
- data->queue_tc_color = 0;
- data->subport = (uint16_t) p->subport_id;
- data->pipe = p->pipe_id;
+ data->queue_id = p->subport_id <<
+ (__builtin_ctz(cfg->n_pipes_per_subport) + 4) |
+ p->pipe_id << 4;
return 0;
}
@@ -411,12 +400,11 @@ pkt_work_tm(struct rte_mbuf *mbuf,
uint32_t dscp)
{
struct dscp_table_entry_data *dscp_entry = &dscp_table->entry[dscp];
- struct tm_data *sched_ptr = (struct tm_data *) &mbuf->hash.sched;
- struct tm_data sched;
-
- sched = *data;
- sched.queue_tc_color = dscp_entry->queue_tc_color;
- *sched_ptr = sched;
+ uint32_t queue_id = data->queue_id |
+ (dscp_entry->tc << 2) |
+ dscp_entry->tc_queue;
+ rte_mbuf_sched_set(mbuf, queue_id, dscp_entry->tc,
+ (uint8_t)dscp_entry->color);
}
/**
@@ -2580,17 +2568,13 @@ rte_table_action_dscp_table_update(struct rte_table_action *action,
&action->dscp_table.entry[i];
struct rte_table_action_dscp_table_entry *entry =
&table->entry[i];
- uint16_t queue_tc_color =
- MBUF_SCHED_QUEUE_TC_COLOR(entry->tc_queue_id,
- entry->tc_id,
- entry->color);
if ((dscp_mask & (1LLU << i)) == 0)
continue;
data->color = entry->color;
data->tc = entry->tc_id;
- data->queue_tc_color = queue_tc_color;
+ data->tc_queue = entry->tc_queue_id;
}
return 0;
diff --git a/lib/librte_sched/Makefile b/lib/librte_sched/Makefile
index 46c53ed71..644fd9d15 100644
--- a/lib/librte_sched/Makefile
+++ b/lib/librte_sched/Makefile
@@ -18,7 +18,7 @@ LDLIBS += -lrte_timer
EXPORT_MAP := rte_sched_version.map
-LIBABIVER := 1
+LIBABIVER := 2
#
# all source are stored in SRCS-y
diff --git a/lib/librte_sched/meson.build b/lib/librte_sched/meson.build
index f85d64df8..8e989e5f6 100644
--- a/lib/librte_sched/meson.build
+++ b/lib/librte_sched/meson.build
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017 Intel Corporation
+version = 2
sources = files('rte_sched.c', 'rte_red.c', 'rte_approx.c')
headers = files('rte_sched.h', 'rte_sched_common.h',
'rte_red.h', 'rte_approx.h')
diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c
index 587d5e602..dd7739172 100644
--- a/lib/librte_sched/rte_sched.c
+++ b/lib/librte_sched/rte_sched.c
@@ -128,22 +128,6 @@ enum grinder_state {
e_GRINDER_READ_MBUF
};
-/*
- * Path through the scheduler hierarchy used by the scheduler enqueue
- * operation to identify the destination queue for the current
- * packet. Stored in the field pkt.hash.sched of struct rte_mbuf of
- * each packet, typically written by the classification stage and read
- * by scheduler enqueue.
- */
-struct rte_sched_port_hierarchy {
- uint16_t queue:2; /**< Queue ID (0 .. 3) */
- uint16_t traffic_class:2; /**< Traffic class ID (0 .. 3)*/
- uint32_t color:2; /**< Color */
- uint16_t unused:10;
- uint16_t subport; /**< Subport ID */
- uint32_t pipe; /**< Pipe ID */
-};
-
struct rte_sched_grinder {
/* Pipe cache */
uint16_t pcache_qmask[RTE_SCHED_GRINDER_PCACHE_SIZE];
@@ -185,6 +169,7 @@ struct rte_sched_port {
/* User parameters */
uint32_t n_subports_per_port;
uint32_t n_pipes_per_subport;
+ uint32_t n_pipes_per_subport_log2;
uint32_t rate;
uint32_t mtu;
uint32_t frame_overhead;
@@ -645,6 +630,8 @@ rte_sched_port_config(struct rte_sched_port_params *params)
/* User parameters */
port->n_subports_per_port = params->n_subports_per_port;
port->n_pipes_per_subport = params->n_pipes_per_subport;
+ port->n_pipes_per_subport_log2 =
+ __builtin_ctz(params->n_pipes_per_subport);
port->rate = params->rate;
port->mtu = params->mtu + params->frame_overhead;
port->frame_overhead = params->frame_overhead;
@@ -1006,44 +993,52 @@ rte_sched_port_pipe_profile_add(struct rte_sched_port *port,
return 0;
}
+static inline uint32_t
+rte_sched_port_qindex(struct rte_sched_port *port,
+ uint32_t subport,
+ uint32_t pipe,
+ uint32_t traffic_class,
+ uint32_t queue)
+{
+ return ((subport & (port->n_subports_per_port - 1)) <<
+ (port->n_pipes_per_subport_log2 + 4)) |
+ ((pipe & (port->n_pipes_per_subport - 1)) << 4) |
+ ((traffic_class &
+ (RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE - 1)) << 2) |
+ (queue & (RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS - 1));
+}
+
void
-rte_sched_port_pkt_write(struct rte_mbuf *pkt,
- uint32_t subport, uint32_t pipe, uint32_t traffic_class,
+rte_sched_port_pkt_write(struct rte_sched_port *port,
+ struct rte_mbuf *pkt,
+ uint32_t subport, uint32_t pipe,
+ uint32_t traffic_class,
uint32_t queue, enum rte_meter_color color)
{
- struct rte_sched_port_hierarchy *sched
- = (struct rte_sched_port_hierarchy *) &pkt->hash.sched;
-
- RTE_BUILD_BUG_ON(sizeof(*sched) > sizeof(pkt->hash.sched));
-
- sched->color = (uint32_t) color;
- sched->subport = subport;
- sched->pipe = pipe;
- sched->traffic_class = traffic_class;
- sched->queue = queue;
+ uint32_t queue_id = rte_sched_port_qindex(port, subport, pipe,
+ traffic_class, queue);
+ rte_mbuf_sched_set(pkt, queue_id, traffic_class, (uint8_t)color);
}
void
-rte_sched_port_pkt_read_tree_path(const struct rte_mbuf *pkt,
+rte_sched_port_pkt_read_tree_path(struct rte_sched_port *port,
+ const struct rte_mbuf *pkt,
uint32_t *subport, uint32_t *pipe,
uint32_t *traffic_class, uint32_t *queue)
{
- const struct rte_sched_port_hierarchy *sched
- = (const struct rte_sched_port_hierarchy *) &pkt->hash.sched;
+ uint32_t queue_id = rte_mbuf_sched_queue_get(pkt);
- *subport = sched->subport;
- *pipe = sched->pipe;
- *traffic_class = sched->traffic_class;
- *queue = sched->queue;
+ *subport = queue_id >> (port->n_pipes_per_subport_log2 + 4);
+ *pipe = (queue_id >> 4) & (port->n_pipes_per_subport - 1);
+ *traffic_class = (queue_id >> 2) &
+ (RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE - 1);
+ *queue = queue_id & (RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS - 1);
}
enum rte_meter_color
rte_sched_port_pkt_read_color(const struct rte_mbuf *pkt)
{
- const struct rte_sched_port_hierarchy *sched
- = (const struct rte_sched_port_hierarchy *) &pkt->hash.sched;
-
- return (enum rte_meter_color) sched->color;
+ return (enum rte_meter_color)rte_mbuf_sched_color_get(pkt);
}
int
@@ -1100,18 +1095,6 @@ rte_sched_queue_read_stats(struct rte_sched_port *port,
return 0;
}
-static inline uint32_t
-rte_sched_port_qindex(struct rte_sched_port *port, uint32_t subport, uint32_t pipe, uint32_t traffic_class, uint32_t queue)
-{
- uint32_t result;
-
- result = subport * port->n_pipes_per_subport + pipe;
- result = result * RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE + traffic_class;
- result = result * RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS + queue;
-
- return result;
-}
-
#ifdef RTE_SCHED_DEBUG
static inline int
@@ -1272,11 +1255,8 @@ rte_sched_port_enqueue_qptrs_prefetch0(struct rte_sched_port *port,
#ifdef RTE_SCHED_COLLECT_STATS
struct rte_sched_queue_extra *qe;
#endif
- uint32_t subport, pipe, traffic_class, queue, qindex;
-
- rte_sched_port_pkt_read_tree_path(pkt, &subport, &pipe, &traffic_class, &queue);
+ uint32_t qindex = rte_mbuf_sched_queue_get(pkt);
- qindex = rte_sched_port_qindex(port, subport, pipe, traffic_class, queue);
q = port->queue + qindex;
rte_prefetch0(q);
#ifdef RTE_SCHED_COLLECT_STATS
diff --git a/lib/librte_sched/rte_sched.h b/lib/librte_sched/rte_sched.h
index 84fa896de..243efa1d4 100644
--- a/lib/librte_sched/rte_sched.h
+++ b/lib/librte_sched/rte_sched.h
@@ -355,6 +355,8 @@ rte_sched_queue_read_stats(struct rte_sched_port *port,
* Scheduler hierarchy path write to packet descriptor. Typically
* called by the packet classification stage.
*
+ * @param port
+ * Handle to port scheduler instance
* @param pkt
* Packet descriptor handle
* @param subport
@@ -369,7 +371,8 @@ rte_sched_queue_read_stats(struct rte_sched_port *port,
* Packet color set
*/
void
-rte_sched_port_pkt_write(struct rte_mbuf *pkt,
+rte_sched_port_pkt_write(struct rte_sched_port *port,
+ struct rte_mbuf *pkt,
uint32_t subport, uint32_t pipe, uint32_t traffic_class,
uint32_t queue, enum rte_meter_color color);
@@ -379,6 +382,8 @@ rte_sched_port_pkt_write(struct rte_mbuf *pkt,
* enqueue operation. The subport, pipe, traffic class and queue
* parameters need to be pre-allocated by the caller.
*
+ * @param port
+ * Handle to port scheduler instance
* @param pkt
* Packet descriptor handle
* @param subport
@@ -392,7 +397,8 @@ rte_sched_port_pkt_write(struct rte_mbuf *pkt,
*
*/
void
-rte_sched_port_pkt_read_tree_path(const struct rte_mbuf *pkt,
+rte_sched_port_pkt_read_tree_path(struct rte_sched_port *port,
+ const struct rte_mbuf *pkt,
uint32_t *subport, uint32_t *pipe,
uint32_t *traffic_class, uint32_t *queue);
diff --git a/test/test/test_sched.c b/test/test/test_sched.c
index 32e500ba9..40e411cab 100644
--- a/test/test/test_sched.c
+++ b/test/test/test_sched.c
@@ -76,7 +76,7 @@ create_mempool(void)
}
static void
-prepare_pkt(struct rte_mbuf *mbuf)
+prepare_pkt(struct rte_sched_port *port, struct rte_mbuf *mbuf)
{
struct ether_hdr *eth_hdr;
struct vlan_hdr *vlan1, *vlan2;
@@ -95,7 +95,8 @@ prepare_pkt(struct rte_mbuf *mbuf)
ip_hdr->dst_addr = IPv4(0,0,TC,QUEUE);
- rte_sched_port_pkt_write(mbuf, SUBPORT, PIPE, TC, QUEUE, e_RTE_METER_YELLOW);
+ rte_sched_port_pkt_write(port, mbuf, SUBPORT, PIPE, TC, QUEUE,
+ e_RTE_METER_YELLOW);
/* 64 byte packet */
mbuf->pkt_len = 60;
@@ -138,7 +139,7 @@ test_sched(void)
for (i = 0; i < 10; i++) {
in_mbufs[i] = rte_pktmbuf_alloc(mp);
TEST_ASSERT_NOT_NULL(in_mbufs[i], "Packet allocation failed\n");
- prepare_pkt(in_mbufs[i]);
+ prepare_pkt(port, in_mbufs[i]);
}
@@ -155,7 +156,7 @@ test_sched(void)
color = rte_sched_port_pkt_read_color(out_mbufs[i]);
TEST_ASSERT_EQUAL(color, e_RTE_METER_YELLOW, "Wrong color\n");
- rte_sched_port_pkt_read_tree_path(out_mbufs[i],
+ rte_sched_port_pkt_read_tree_path(port, out_mbufs[i],
&subport, &pipe, &traffic_class, &queue);
TEST_ASSERT_EQUAL(subport, SUBPORT, "Wrong subport\n");
--
2.17.1
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v6 2/2] mbuf: implement generic format for sched field
2018-12-19 15:42 ` [dpdk-dev] [PATCH v6 2/2] mbuf: implement generic format for sched field Reshma Pattan
@ 2018-12-19 18:14 ` Ananyev, Konstantin
2018-12-20 8:29 ` Olivier Matz
1 sibling, 0 replies; 74+ messages in thread
From: Ananyev, Konstantin @ 2018-12-19 18:14 UTC (permalink / raw)
To: Pattan, Reshma, dev, jerin.jacob, Rao, Nikhil, olivier.matz,
thomas, Singh, Jasvinder, Dumitrescu, Cristian
Cc: Pattan, Reshma
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Reshma Pattan
> Sent: Wednesday, December 19, 2018 3:43 PM
> To: dev@dpdk.org; jerin.jacob@caviumnetworks.com; Rao, Nikhil <nikhil.rao@intel.com>; olivier.matz@6wind.com;
> thomas@monjalon.net; Singh, Jasvinder <jasvinder.singh@intel.com>; Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> Cc: Pattan, Reshma <reshma.pattan@intel.com>
> Subject: [dpdk-dev] [PATCH v6 2/2] mbuf: implement generic format for sched field
>
> This patch implements the changes proposed in the deprecation
> notes [1][2].
>
> librte_mbuf changes:
> The mbuf::hash::sched field is updated to support generic
> definition in line with the ethdev TM and MTR APIs. The new generic
> format contains: queue ID, traffic class, color.
>
> Added public APIs to set and get these new fields to and from mbuf.
>
> librte_sched changes:
> In addtion, following API functions of the sched library have
> been modified with an additional parameter of type struct
> rte_sched_port to accommodate the changes made to mbuf sched field.
> (i)rte_sched_port_pkt_write()
> (ii) rte_sched_port_pkt_read_tree_path()
>
> librte_pipeline, qos_sched UT, qos_sched app are updated
> to make use of new changes.
>
> Also mbuf::hash::txadapter has been added for eventdev txq,
> rte_event_eth_tx_adapter_txq_set and rte_event_eth_tx_adapter_txq_get()
> are updated to use uses mbuf::hash::txadapter.txq.
>
> doc:
> Release notes updated.
> Removed deprecation notice for mbuf::hash::sched and sched API.
>
> [1] http://mails.dpdk.org/archives/dev/2018-February/090651.html
> [2] https://mails.dpdk.org/archives/dev/2018-November/119051.html
>
> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
> Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> ---
> v6: added scheduler comment
>
> v5:
> Removed librte_meter from librte_mbuf dependency list.
> Changed the mbuf set/get functions to use uint8_t for color.
>
> v4: converted mbuf::hash::sched as instantiation of rte_mbuf_sched.
>
> v3: addressed review comments given in the below link.
> http://patches.dpdk.org/patch/48587/
> Updated library ABI versioning in meson build.
> ---
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> 2.17.1
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [dpdk-dev] [PATCH v6 2/2] mbuf: implement generic format for sched field
2018-12-19 15:42 ` [dpdk-dev] [PATCH v6 2/2] mbuf: implement generic format for sched field Reshma Pattan
2018-12-19 18:14 ` Ananyev, Konstantin
@ 2018-12-20 8:29 ` Olivier Matz
2018-12-20 11:28 ` Dumitrescu, Cristian
1 sibling, 1 reply; 74+ messages in thread
From: Olivier Matz @ 2018-12-20 8:29 UTC (permalink / raw)
To: Reshma Pattan
Cc: dev, jerin.jacob, nikhil.rao, thomas, jasvinder.singh,
cristian.dumitrescu
Hi Reshma,
Please find few minor comments below.
On Wed, Dec 19, 2018 at 03:42:37PM +0000, Reshma Pattan wrote:
> This patch implements the changes proposed in the deprecation
> notes [1][2].
>
> librte_mbuf changes:
> The mbuf::hash::sched field is updated to support generic
I think it would be clearer to use mbuf->hash.sched (instead of ::).
> definition in line with the ethdev TM and MTR APIs. The new generic
> format contains: queue ID, traffic class, color.
I wonder if it wouldn't be worth specifying "traffic manager" and
"meter" instead of or in addition to TM and MTR.
[...]
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -468,6 +468,17 @@ __extension__
> typedef uint64_t MARKER64[0]; /**< marker that allows us to overwrite 8 bytes
> * with a single assignment */
>
> +struct rte_mbuf_sched {
> + uint32_t queue_id; /**< Queue ID. */
> + uint8_t traffic_class;
> + /**< Traffic class ID. Traffic class 0
> + * is the highest priority traffic class.
> + */
> + uint8_t color;
> + /**< Color. @see enum rte_color.*/
> + uint16_t reserved; /**< Reserved. */
> +};
> +
> /**
> * The generic rte_mbuf, containing a packet mbuf.
> */
> @@ -574,14 +585,16 @@ struct rte_mbuf {
> * on PKT_RX_FDIR_* flag in ol_flags.
> */
> } fdir; /**< Filter identifier if FDIR enabled */
> + struct rte_mbuf_sched sched; /**< Hierarchical scheduler */
What about directly embedding the structure like the others? Since mbuf
is a very packed structure, I think it helps to show that rte_mbuf_sched
does not exceed the size of the union.
I mean something like this:
struct rte_mbuf_sched {
uint32_t queue_id; /**< Queue ID. */
uint8_t traffic_class;
/**< Traffic class ID (0 = highest priority). */
uint8_t color;
/**< Color. @see enum rte_color. */
uint16_t reserved; /**< Reserved. */
} sched;
I would require small changes, see below.
> struct {
> - uint32_t lo;
> - uint32_t hi;
> + uint32_t reserved1;
> + uint16_t reserved2;
> + uint16_t txq;
> /**< The event eth Tx adapter uses this field
> * to store Tx queue id.
> * @see rte_event_eth_tx_adapter_txq_set()
> */
> - } sched; /**< Hierarchical scheduler */
> + } txadapter; /**< Eventdev ethdev Tx adapter */
> /**< User defined tags. See rte_distributor_process() */
> uint32_t usr;
> } hash; /**< hash information */
> @@ -2289,6 +2302,106 @@ rte_pktmbuf_linearize(struct rte_mbuf *mbuf)
> */
> void rte_pktmbuf_dump(FILE *f, const struct rte_mbuf *m, unsigned dump_len);
>
> +/**
> + * Get the value of mbuf sched queue_id field.
> + */
> +static inline uint32_t
> +rte_mbuf_sched_queue_get(const struct rte_mbuf *m)
> +{
> + return m->hash.sched.queue_id;
> +}
> +
> +/**
> + * Get the value of mbuf sched traffic_class field.
> + */
> +static inline uint8_t
> +rte_mbuf_sched_traffic_class_get(const struct rte_mbuf *m)
> +{
> + return m->hash.sched.traffic_class;
> +}
> +
> +/**
> + * Get the value of mbuf sched color field.
> + */
> +static inline uint8_t
> +rte_mbuf_sched_color_get(const struct rte_mbuf *m)
> +{
> + return m->hash.sched.color;
> +}
> +
> +/**
> + * Get the values of mbuf sched queue_id, traffic_class and color.
missing an empty comment line here.
> + * @param m
> + * Mbuf to read
> + * @param queue_id
> + * Returns the queue id
> + * @param traffic_class
> + * Returns the traffic class id
> + * @param color
> + * Returns the colour id
> + */
> +static inline void
> +rte_mbuf_sched_get(const struct rte_mbuf *m, uint32_t *queue_id,
> + uint8_t *traffic_class,
> + uint8_t *color)
> +{
> + struct rte_mbuf_sched sched = m->hash.sched;
> +
> + *queue_id = sched.queue_id;
> + *traffic_class = sched.traffic_class;
> + *color = sched.color;
I don't think there is a need to have an additional local copy.
*queue_id = m->hash.sched.queue_id;
*traffic_class = m->hash.sched.traffic_class;
*color = m->hash.sched.color;
> +}
> +
> +/**
> + * Set the mbuf sched queue_id to the defined value.
> + */
> +static inline void
> +rte_mbuf_sched_queue_set(struct rte_mbuf *m, uint32_t queue_id)
> +{
> + m->hash.sched.queue_id = queue_id;
> +}
> +
> +/**
> + * Set the mbuf sched traffic_class id to the defined value.
> + */
> +static inline void
> +rte_mbuf_sched_traffic_class_set(struct rte_mbuf *m, uint8_t traffic_class)
> +{
> + m->hash.sched.traffic_class = traffic_class;
> +}
> +
> +/**
> + * Set the mbuf sched color id to the defined value.
> + */
> +static inline void
> +rte_mbuf_sched_color_set(struct rte_mbuf *m, uint8_t color)
> +{
> + m->hash.sched.color = color;
> +}
> +
> +/**
> + * Set the mbuf sched queue_id, traffic_class and color.
empty comment missing
> + * @param m
> + * Mbuf to set
> + * @param queue_id
> + * Queue id value to be set
> + * @param traffic_class
> + * Traffic class id value to be set
> + * @param color
> + * Color id to be set
> + */
> +static inline void
> +rte_mbuf_sched_set(struct rte_mbuf *m, uint32_t queue_id,
> + uint8_t traffic_class,
> + uint8_t color)
> +{
> + m->hash.sched = (struct rte_mbuf_sched){
> + .queue_id = queue_id,
> + .traffic_class = traffic_class,
> + .color = color,
> + };
Why not this?
m->hash.sched.queue_id = queue_id;
m->hash.sched.traffic_class = traffic_class;
m->hash.sched.color = color;
Apart from this, the mbuf part looks ok to me.
Thanks,
Olivier
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v6 2/2] mbuf: implement generic format for sched field
2018-12-20 8:29 ` Olivier Matz
@ 2018-12-20 11:28 ` Dumitrescu, Cristian
2018-12-20 12:41 ` Olivier Matz
0 siblings, 1 reply; 74+ messages in thread
From: Dumitrescu, Cristian @ 2018-12-20 11:28 UTC (permalink / raw)
To: Olivier Matz, Pattan, Reshma
Cc: dev, jerin.jacob, Rao, Nikhil, thomas, Singh, Jasvinder
Hi Olivier,
Thanks for your reply!
<snip>
> > * The generic rte_mbuf, containing a packet mbuf.
> > */
> > @@ -574,14 +585,16 @@ struct rte_mbuf {
> > * on PKT_RX_FDIR_* flag in ol_flags.
> > */
> > } fdir; /**< Filter identifier if FDIR enabled */
> > + struct rte_mbuf_sched sched; /**< Hierarchical
> scheduler */
>
>
> What about directly embedding the structure like the others? Since mbuf
> is a very packed structure, I think it helps to show that rte_mbuf_sched
> does not exceed the size of the union.
>
> I mean something like this:
>
> struct rte_mbuf_sched {
> uint32_t queue_id; /**< Queue ID. */
> uint8_t traffic_class;
> /**< Traffic class ID (0 = highest priority). */
> uint8_t color;
> /**< Color. @see enum rte_color. */
> uint16_t reserved; /**< Reserved. */
> } sched;
If this syntax does not limit the scope of struct rte_mbuf_sched to just within its parent struct rte_mbuf, then it would also fit my needs and I am more than happy to use it.
All I need is a name for this rte_mbuf_sched structure, so I can use it to get a decent implementation of set/get functions.
<snip>
> > + * @param m
> > + * Mbuf to read
> > + * @param queue_id
> > + * Returns the queue id
> > + * @param traffic_class
> > + * Returns the traffic class id
> > + * @param color
> > + * Returns the colour id
> > + */
> > +static inline void
> > +rte_mbuf_sched_get(const struct rte_mbuf *m, uint32_t *queue_id,
> > + uint8_t *traffic_class,
> > + uint8_t *color)
> > +{
> > + struct rte_mbuf_sched sched = m->hash.sched;
> > +
> > + *queue_id = sched.queue_id;
> > + *traffic_class = sched.traffic_class;
> > + *color = sched.color;
>
> I don't think there is a need to have an additional local copy.
>
> *queue_id = m->hash.sched.queue_id;
> *traffic_class = m->hash.sched.traffic_class;
> *color = m->hash.sched.color;
>
With local copy, compiler typically generates a single 8-byte read instruction. Without the local copy, compiler typically generates 3x read instructions.
The set/get functions are used in some performance critical actions, so this is the reason to make sure we get them right.
<snip>
> > + * @param m
> > + * Mbuf to set
> > + * @param queue_id
> > + * Queue id value to be set
> > + * @param traffic_class
> > + * Traffic class id value to be set
> > + * @param color
> > + * Color id to be set
> > + */
> > +static inline void
> > +rte_mbuf_sched_set(struct rte_mbuf *m, uint32_t queue_id,
> > + uint8_t traffic_class,
> > + uint8_t color)
> > +{
> > + m->hash.sched = (struct rte_mbuf_sched){
> > + .queue_id = queue_id,
> > + .traffic_class = traffic_class,
> > + .color = color,
> > + };
>
> Why not this?
>
> m->hash.sched.queue_id = queue_id;
> m->hash.sched.traffic_class = traffic_class;
> m->hash.sched.color = color;
>
Same here, we need the compiler to generate a single 8-byte write instruction rather than 3x read-modify-write operations. Makes sense?
>
> Apart from this, the mbuf part looks ok to me.
>
> Thanks,
> Olivier
Thanks,
Cristian
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v6 2/2] mbuf: implement generic format for sched field
2018-12-20 11:28 ` Dumitrescu, Cristian
@ 2018-12-20 12:41 ` Olivier Matz
0 siblings, 0 replies; 74+ messages in thread
From: Olivier Matz @ 2018-12-20 12:41 UTC (permalink / raw)
To: Dumitrescu, Cristian
Cc: Pattan, Reshma, dev, jerin.jacob, Rao, Nikhil, thomas, Singh, Jasvinder
Hi Cristian,
[...]
On Thu, Dec 20, 2018 at 11:28:01AM +0000, Dumitrescu, Cristian wrote:
> > > + * @param m
> > > + * Mbuf to read
> > > + * @param queue_id
> > > + * Returns the queue id
> > > + * @param traffic_class
> > > + * Returns the traffic class id
> > > + * @param color
> > > + * Returns the colour id
> > > + */
> > > +static inline void
> > > +rte_mbuf_sched_get(const struct rte_mbuf *m, uint32_t *queue_id,
> > > + uint8_t *traffic_class,
> > > + uint8_t *color)
> > > +{
> > > + struct rte_mbuf_sched sched = m->hash.sched;
> > > +
> > > + *queue_id = sched.queue_id;
> > > + *traffic_class = sched.traffic_class;
> > > + *color = sched.color;
> >
> > I don't think there is a need to have an additional local copy.
> >
> > *queue_id = m->hash.sched.queue_id;
> > *traffic_class = m->hash.sched.traffic_class;
> > *color = m->hash.sched.color;
> >
>
> With local copy, compiler typically generates a single 8-byte read instruction. Without the local copy, compiler typically generates 3x read instructions.
>
> The set/get functions are used in some performance critical actions, so this is the reason to make sure we get them right.
Ok, that makes sense, thanks for clarification.
Regards,
Olivier
^ permalink raw reply [flat|nested] 74+ messages in thread
* [dpdk-dev] [PATCH v7 1/2] meter: add new rte color definition
2018-12-19 15:42 ` [dpdk-dev] [PATCH v6 1/2] meter: add new rte color definition Reshma Pattan
2018-12-19 15:42 ` [dpdk-dev] [PATCH v6 2/2] mbuf: implement generic format for sched field Reshma Pattan
@ 2018-12-20 12:16 ` Reshma Pattan
2018-12-20 12:16 ` [dpdk-dev] [PATCH v7 2/2] mbuf: implement generic format for sched field Reshma Pattan
1 sibling, 1 reply; 74+ messages in thread
From: Reshma Pattan @ 2018-12-20 12:16 UTC (permalink / raw)
To: dev, jerin.jacob, nikhil.rao, olivier.matz, thomas,
jasvinder.singh, cristian.dumitrescu, konstantin.ananyev
Cc: Reshma Pattan
Added new rte_color definition in librte_meter to
consolidate color definition which is currently replicated
in various places such as rte_meter.h, rte_tm.h and rte_mtr.h
Created aliases for rte_tm_color, rte_mtr_color and rte_meter_color
to use new rte_color values.
The definitions of rte_tm_color, rte_mtr_color and rte_meter_color
will be deprecated in future.
Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
---
v5: Removed meter library from librte_mbuf dependency list.
v4: Removed rte_meter, rte_mtr and rte_tm color definitions.
Moved rte_color definition from eal to meter library.
v3:Addressed review comments given in the below link
http://patches.dpdk.org/patch/48588/
Added rte_color.h to meson build.
---
---
lib/Makefile | 1 +
lib/librte_ethdev/Makefile | 2 +-
lib/librte_ethdev/meson.build | 2 +-
lib/librte_ethdev/rte_mtr.h | 16 +++++++---------
lib/librte_ethdev/rte_tm.h | 16 +++++++---------
lib/librte_meter/rte_meter.h | 21 +++++++++++++++------
lib/meson.build | 4 ++--
7 files changed, 34 insertions(+), 28 deletions(-)
diff --git a/lib/Makefile b/lib/Makefile
index b7370ef97..8dbdc9bca 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -26,6 +26,7 @@ DEPDIRS-librte_ethdev := librte_net librte_eal librte_mempool librte_ring
DEPDIRS-librte_ethdev += librte_mbuf
DEPDIRS-librte_ethdev += librte_kvargs
DEPDIRS-librte_ethdev += librte_cmdline
+DEPDIRS-librte_ethdev += librte_meter
DIRS-$(CONFIG_RTE_LIBRTE_BBDEV) += librte_bbdev
DEPDIRS-librte_bbdev := librte_eal librte_mempool librte_mbuf
DIRS-$(CONFIG_RTE_LIBRTE_CRYPTODEV) += librte_cryptodev
diff --git a/lib/librte_ethdev/Makefile b/lib/librte_ethdev/Makefile
index 3e27ae466..e09c4263a 100644
--- a/lib/librte_ethdev/Makefile
+++ b/lib/librte_ethdev/Makefile
@@ -12,7 +12,7 @@ CFLAGS += -DALLOW_EXPERIMENTAL_API
CFLAGS += -O3
CFLAGS += $(WERROR_FLAGS)
LDLIBS += -lrte_net -lrte_eal -lrte_mempool -lrte_ring
-LDLIBS += -lrte_mbuf -lrte_kvargs -lrte_cmdline
+LDLIBS += -lrte_mbuf -lrte_kvargs -lrte_cmdline -lrte_meter
EXPORT_MAP := rte_ethdev_version.map
diff --git a/lib/librte_ethdev/meson.build b/lib/librte_ethdev/meson.build
index a4d850268..e98942ff8 100644
--- a/lib/librte_ethdev/meson.build
+++ b/lib/librte_ethdev/meson.build
@@ -26,4 +26,4 @@ headers = files('rte_ethdev.h',
'rte_tm.h',
'rte_tm_driver.h')
-deps += ['net', 'kvargs', 'cmdline']
+deps += ['net', 'kvargs', 'cmdline', 'meter']
diff --git a/lib/librte_ethdev/rte_mtr.h b/lib/librte_ethdev/rte_mtr.h
index c4819b274..c667f87e1 100644
--- a/lib/librte_ethdev/rte_mtr.h
+++ b/lib/librte_ethdev/rte_mtr.h
@@ -76,20 +76,18 @@
#include <stdint.h>
#include <rte_compat.h>
#include <rte_common.h>
+#include <rte_meter.h>
#ifdef __cplusplus
extern "C" {
#endif
-/**
- * Color
- */
-enum rte_mtr_color {
- RTE_MTR_GREEN = 0, /**< Green */
- RTE_MTR_YELLOW, /**< Yellow */
- RTE_MTR_RED, /**< Red */
- RTE_MTR_COLORS /**< Number of colors. */
-};
+/* New rte_color is defined and used to deprecate rte_mtr_color soon. */
+#define rte_mtr_color rte_color
+#define RTE_MTR_GREEN RTE_COLOR_GREEN
+#define RTE_MTR_YELLOW RTE_COLOR_YELLOW
+#define RTE_MTR_RED RTE_COLOR_RED
+#define RTE_MTR_COLORS RTE_COLORS
/**
* Statistics counter type
diff --git a/lib/librte_ethdev/rte_tm.h b/lib/librte_ethdev/rte_tm.h
index 646ef3880..c4a788b85 100644
--- a/lib/librte_ethdev/rte_tm.h
+++ b/lib/librte_ethdev/rte_tm.h
@@ -51,6 +51,7 @@
#include <stdint.h>
#include <rte_common.h>
+#include <rte_meter.h>
#ifdef __cplusplus
extern "C" {
@@ -115,15 +116,12 @@ extern "C" {
*/
#define RTE_TM_NODE_LEVEL_ID_ANY UINT32_MAX
-/**
- * Color
- */
-enum rte_tm_color {
- RTE_TM_GREEN = 0, /**< Green */
- RTE_TM_YELLOW, /**< Yellow */
- RTE_TM_RED, /**< Red */
- RTE_TM_COLORS /**< Number of colors */
-};
+/* New rte_color is defined and used to deprecate rte_tm_color soon. */
+#define rte_tm_color rte_color
+#define RTE_TM_GREEN RTE_COLOR_GREEN
+#define RTE_TM_YELLOW RTE_COLOR_YELLOW
+#define RTE_TM_RED RTE_COLOR_RED
+#define RTE_TM_COLORS RTE_COLORS
/**
* Node statistics counter type
diff --git a/lib/librte_meter/rte_meter.h b/lib/librte_meter/rte_meter.h
index 58a051583..c2ea47332 100644
--- a/lib/librte_meter/rte_meter.h
+++ b/lib/librte_meter/rte_meter.h
@@ -26,14 +26,23 @@ extern "C" {
*
***/
-/** Packet Color Set */
-enum rte_meter_color {
- e_RTE_METER_GREEN = 0, /**< Green */
- e_RTE_METER_YELLOW, /**< Yellow */
- e_RTE_METER_RED, /**< Red */
- e_RTE_METER_COLORS /**< Number of available colors */
+/**
+ * Color
+ */
+enum rte_color {
+ RTE_COLOR_GREEN = 0, /**< Green */
+ RTE_COLOR_YELLOW, /**< Yellow */
+ RTE_COLOR_RED, /**< Red */
+ RTE_COLORS /**< Number of colors */
};
+/* New rte_color is defined and used to deprecate rte_meter_color soon. */
+#define rte_meter_color rte_color
+#define e_RTE_METER_GREEN RTE_COLOR_GREEN
+#define e_RTE_METER_YELLOW RTE_COLOR_YELLOW
+#define e_RTE_METER_RED RTE_COLOR_RED
+#define e_RTE_METER_COLORS RTE_COLORS
+
/** srTCM parameters per metered traffic flow. The CIR, CBS and EBS parameters only
count bytes of IP packets and do not include link specific headers. At least one of
the CBS or EBS parameters has to be greater than zero. */
diff --git a/lib/meson.build b/lib/meson.build
index bb7f443f9..a2dd52e17 100644
--- a/lib/meson.build
+++ b/lib/meson.build
@@ -11,7 +11,7 @@
libraries = [ 'compat', # just a header, used for versioning
'cmdline', # ethdev depends on cmdline for parsing functions
'kvargs', # eal depends on kvargs
- 'eal', 'ring', 'mempool', 'mbuf', 'net', 'ethdev', 'pci', # core
+ 'eal', 'ring', 'mempool', 'mbuf', 'net', 'meter', 'ethdev', 'pci', # core
'metrics', # bitrate/latency stats depends on this
'hash', # efd depends on this
'timer', # eventdev depends on this
@@ -20,7 +20,7 @@ libraries = [ 'compat', # just a header, used for versioning
'distributor', 'efd', 'eventdev',
'gro', 'gso', 'ip_frag', 'jobstats',
'kni', 'latencystats', 'lpm', 'member',
- 'meter', 'power', 'pdump', 'rawdev',
+ 'power', 'pdump', 'rawdev',
'reorder', 'sched', 'security', 'vhost',
# add pkt framework libs which use other libs from above
'port', 'table', 'pipeline',
--
2.17.1
^ permalink raw reply [flat|nested] 74+ messages in thread* [dpdk-dev] [PATCH v7 2/2] mbuf: implement generic format for sched field
2018-12-20 12:16 ` [dpdk-dev] [PATCH v7 1/2] meter: add new rte color definition Reshma Pattan
@ 2018-12-20 12:16 ` Reshma Pattan
2018-12-20 12:43 ` Olivier Matz
` (3 more replies)
0 siblings, 4 replies; 74+ messages in thread
From: Reshma Pattan @ 2018-12-20 12:16 UTC (permalink / raw)
To: dev, jerin.jacob, nikhil.rao, olivier.matz, thomas,
jasvinder.singh, cristian.dumitrescu, konstantin.ananyev
Cc: Reshma Pattan
This patch implements the changes proposed in the deprecation
notes [1][2].
librte_mbuf changes:
The mbuf->hash.sched field is updated to support generic
definition in line with the ethdev traffic manager and meter APIs.
The new generic format contains: queue ID, traffic class, color.
Added public APIs to set and get these new fields to and from mbuf.
librte_sched changes:
In addtion, following API functions of the sched library have
been modified with an additional parameter of type struct
rte_sched_port to accommodate the changes made to mbuf sched field.
(i)rte_sched_port_pkt_write()
(ii) rte_sched_port_pkt_read_tree_path()
librte_pipeline, qos_sched UT, qos_sched app are updated
to make use of new changes.
Also mbuf->hash.txadapter has been added for eventdev txq,
rte_event_eth_tx_adapter_txq_set and rte_event_eth_tx_adapter_txq_get()
are updated to use mbuf->hash.txadapter.txq.
doc:
Release notes updated.
Removed deprecation notice for mbuf->hash.sched and sched API.
[1] http://mails.dpdk.org/archives/dev/2018-February/090651.html
[2] https://mails.dpdk.org/archives/dev/2018-November/119051.html
Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
---
v7:
Edited the commit message.
Moved rte_mbuf_sched inside the rte_mbuf struct.
Added missing empty line in doxygen comments of sched
set and get functions.
v6: added scheduler comment
v5:
Removed librte_meter from librte_mbuf dependency list.
Changed the mbuf set/get functions to use uint8_t for color.
v4: converted mbuf->hash.sched as instantiation of rte_mbuf_sched.
v3: addressed review comments given in the below link.
http://patches.dpdk.org/patch/48587/
Updated library ABI versioning in meson build.
---
---
doc/guides/rel_notes/deprecation.rst | 10 --
doc/guides/rel_notes/release_19_02.rst | 4 +-
examples/qos_sched/app_thread.c | 7 +-
examples/qos_sched/main.c | 1 +
.../rte_event_eth_tx_adapter.h | 18 ++-
lib/librte_mbuf/Makefile | 2 +-
lib/librte_mbuf/meson.build | 2 +-
lib/librte_mbuf/rte_mbuf.h | 119 +++++++++++++++++-
lib/librte_pipeline/rte_table_action.c | 44 +++----
lib/librte_sched/Makefile | 2 +-
lib/librte_sched/meson.build | 1 +
lib/librte_sched/rte_sched.c | 90 ++++++-------
lib/librte_sched/rte_sched.h | 10 +-
test/test/test_sched.c | 9 +-
14 files changed, 197 insertions(+), 122 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index ac7fb29a7..ec80dcc7b 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -49,16 +49,6 @@ Deprecation Notices
structure would be made internal (or removed if all dependencies are cleared)
in future releases.
-* mbuf: The opaque ``mbuf->hash.sched`` field will be updated to support generic
- definition in line with the ethdev TM and MTR APIs. Currently, this field
- is defined in librte_sched in a non-generic way. The new generic format
- will contain: queue ID, traffic class, color. Field size will not change.
-
-* sched: Some API functions will change prototype due to the above
- deprecation note for mbuf->hash.sched, e.g. ``rte_sched_port_pkt_write()``
- and ``rte_sched_port_pkt_read()`` will likely have an additional parameter
- of type ``struct rte_sched_port``.
-
* mbuf: the macro ``RTE_MBUF_INDIRECT()`` will be removed in v18.08 or later and
replaced with ``RTE_MBUF_CLONED()`` which is already added in v18.05. As
``EXT_ATTACHED_MBUF`` is newly introduced in v18.05, ``RTE_MBUF_INDIRECT()``
diff --git a/doc/guides/rel_notes/release_19_02.rst b/doc/guides/rel_notes/release_19_02.rst
index 8deb68b9a..1f9ec9fc1 100644
--- a/doc/guides/rel_notes/release_19_02.rst
+++ b/doc/guides/rel_notes/release_19_02.rst
@@ -156,7 +156,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_kvargs.so.1
librte_latencystats.so.1
librte_lpm.so.2
- librte_mbuf.so.4
+ + librte_mbuf.so.5
librte_member.so.1
librte_mempool.so.5
librte_meter.so.2
@@ -178,7 +178,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_rawdev.so.1
librte_reorder.so.1
librte_ring.so.2
- librte_sched.so.1
+ + librte_sched.so.2
librte_security.so.1
librte_table.so.3
librte_timer.so.1
diff --git a/examples/qos_sched/app_thread.c b/examples/qos_sched/app_thread.c
index a59274236..bec4deee3 100644
--- a/examples/qos_sched/app_thread.c
+++ b/examples/qos_sched/app_thread.c
@@ -73,8 +73,11 @@ app_rx_thread(struct thread_conf **confs)
for(i = 0; i < nb_rx; i++) {
get_pkt_sched(rx_mbufs[i],
&subport, &pipe, &traffic_class, &queue, &color);
- rte_sched_port_pkt_write(rx_mbufs[i], subport, pipe,
- traffic_class, queue, (enum rte_meter_color) color);
+ rte_sched_port_pkt_write(conf->sched_port,
+ rx_mbufs[i],
+ subport, pipe,
+ traffic_class, queue,
+ (enum rte_meter_color) color);
}
if (unlikely(rte_ring_sp_enqueue_bulk(conf->rx_ring,
diff --git a/examples/qos_sched/main.c b/examples/qos_sched/main.c
index e7c97bd64..c0ed16b68 100644
--- a/examples/qos_sched/main.c
+++ b/examples/qos_sched/main.c
@@ -55,6 +55,7 @@ app_main_loop(__attribute__((unused))void *dummy)
flow->rx_thread.rx_port = flow->rx_port;
flow->rx_thread.rx_ring = flow->rx_ring;
flow->rx_thread.rx_queue = flow->rx_queue;
+ flow->rx_thread.sched_port = flow->sched_port;
rx_confs[rx_idx++] = &flow->rx_thread;
diff --git a/lib/librte_eventdev/rte_event_eth_tx_adapter.h b/lib/librte_eventdev/rte_event_eth_tx_adapter.h
index 81456d4a9..2a50656d9 100644
--- a/lib/librte_eventdev/rte_event_eth_tx_adapter.h
+++ b/lib/librte_eventdev/rte_event_eth_tx_adapter.h
@@ -63,13 +63,11 @@
* function can be used to retrieve the adapter's service function ID.
*
* The ethernet port and transmit queue index to transmit the mbuf on are
- * specified using the mbuf port and the higher 16 bits of
- * struct rte_mbuf::hash::sched:hi. The application should use the
- * rte_event_eth_tx_adapter_txq_set() and rte_event_eth_tx_adapter_txq_get()
- * functions to access the transmit queue index since it is expected that the
- * transmit queue will be eventually defined within struct rte_mbuf and using
- * these macros will help with minimizing application impact due to
- * a change in how the transmit queue index is specified.
+ * specified using the mbuf port struct rte_mbuf::hash::txadapter:txq.
+ * The application should use the rte_event_eth_tx_adapter_txq_set()
+ * and rte_event_eth_tx_adapter_txq_get() functions to access the transmit
+ * queue index, using these macros will help with minimizing application
+ * impact due to a change in how the transmit queue index is specified.
*/
#ifdef __cplusplus
@@ -300,8 +298,7 @@ rte_event_eth_tx_adapter_queue_del(uint8_t id,
static __rte_always_inline void __rte_experimental
rte_event_eth_tx_adapter_txq_set(struct rte_mbuf *pkt, uint16_t queue)
{
- uint16_t *p = (uint16_t *)&pkt->hash.sched.hi;
- p[1] = queue;
+ pkt->hash.txadapter.txq = queue;
}
/**
@@ -320,8 +317,7 @@ rte_event_eth_tx_adapter_txq_set(struct rte_mbuf *pkt, uint16_t queue)
static __rte_always_inline uint16_t __rte_experimental
rte_event_eth_tx_adapter_txq_get(struct rte_mbuf *pkt)
{
- uint16_t *p = (uint16_t *)&pkt->hash.sched.hi;
- return p[1];
+ return pkt->hash.txadapter.txq;
}
/**
diff --git a/lib/librte_mbuf/Makefile b/lib/librte_mbuf/Makefile
index e2b98a254..8c4c7d790 100644
--- a/lib/librte_mbuf/Makefile
+++ b/lib/librte_mbuf/Makefile
@@ -11,7 +11,7 @@ LDLIBS += -lrte_eal -lrte_mempool
EXPORT_MAP := rte_mbuf_version.map
-LIBABIVER := 4
+LIBABIVER := 5
# all source are stored in SRCS-y
SRCS-$(CONFIG_RTE_LIBRTE_MBUF) := rte_mbuf.c rte_mbuf_ptype.c rte_mbuf_pool_ops.c
diff --git a/lib/librte_mbuf/meson.build b/lib/librte_mbuf/meson.build
index 94d9c4c96..e37da0250 100644
--- a/lib/librte_mbuf/meson.build
+++ b/lib/librte_mbuf/meson.build
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017 Intel Corporation
-version = 4
+version = 5
sources = files('rte_mbuf.c', 'rte_mbuf_ptype.c', 'rte_mbuf_pool_ops.c')
headers = files('rte_mbuf.h', 'rte_mbuf_ptype.h', 'rte_mbuf_pool_ops.h')
deps += ['mempool']
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 3dbc6695e..bc562dc8a 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -574,14 +574,25 @@ struct rte_mbuf {
* on PKT_RX_FDIR_* flag in ol_flags.
*/
} fdir; /**< Filter identifier if FDIR enabled */
+ struct rte_mbuf_sched {
+ uint32_t queue_id; /**< Queue ID. */
+ uint8_t traffic_class;
+ /**< Traffic class ID. Traffic class 0
+ * is the highest priority traffic class.
+ */
+ uint8_t color;
+ /**< Color. @see enum rte_color.*/
+ uint16_t reserved; /**< Reserved. */
+ } sched; /**< Hierarchical scheduler */
struct {
- uint32_t lo;
- uint32_t hi;
+ uint32_t reserved1;
+ uint16_t reserved2;
+ uint16_t txq;
/**< The event eth Tx adapter uses this field
* to store Tx queue id.
* @see rte_event_eth_tx_adapter_txq_set()
*/
- } sched; /**< Hierarchical scheduler */
+ } txadapter; /**< Eventdev ethdev Tx adapter */
/**< User defined tags. See rte_distributor_process() */
uint32_t usr;
} hash; /**< hash information */
@@ -2289,6 +2300,108 @@ rte_pktmbuf_linearize(struct rte_mbuf *mbuf)
*/
void rte_pktmbuf_dump(FILE *f, const struct rte_mbuf *m, unsigned dump_len);
+/**
+ * Get the value of mbuf sched queue_id field.
+ */
+static inline uint32_t
+rte_mbuf_sched_queue_get(const struct rte_mbuf *m)
+{
+ return m->hash.sched.queue_id;
+}
+
+/**
+ * Get the value of mbuf sched traffic_class field.
+ */
+static inline uint8_t
+rte_mbuf_sched_traffic_class_get(const struct rte_mbuf *m)
+{
+ return m->hash.sched.traffic_class;
+}
+
+/**
+ * Get the value of mbuf sched color field.
+ */
+static inline uint8_t
+rte_mbuf_sched_color_get(const struct rte_mbuf *m)
+{
+ return m->hash.sched.color;
+}
+
+/**
+ * Get the values of mbuf sched queue_id, traffic_class and color.
+ *
+ * @param m
+ * Mbuf to read
+ * @param queue_id
+ * Returns the queue id
+ * @param traffic_class
+ * Returns the traffic class id
+ * @param color
+ * Returns the colour id
+ */
+static inline void
+rte_mbuf_sched_get(const struct rte_mbuf *m, uint32_t *queue_id,
+ uint8_t *traffic_class,
+ uint8_t *color)
+{
+ struct rte_mbuf_sched sched = m->hash.sched;
+
+ *queue_id = sched.queue_id;
+ *traffic_class = sched.traffic_class;
+ *color = sched.color;
+}
+
+/**
+ * Set the mbuf sched queue_id to the defined value.
+ */
+static inline void
+rte_mbuf_sched_queue_set(struct rte_mbuf *m, uint32_t queue_id)
+{
+ m->hash.sched.queue_id = queue_id;
+}
+
+/**
+ * Set the mbuf sched traffic_class id to the defined value.
+ */
+static inline void
+rte_mbuf_sched_traffic_class_set(struct rte_mbuf *m, uint8_t traffic_class)
+{
+ m->hash.sched.traffic_class = traffic_class;
+}
+
+/**
+ * Set the mbuf sched color id to the defined value.
+ */
+static inline void
+rte_mbuf_sched_color_set(struct rte_mbuf *m, uint8_t color)
+{
+ m->hash.sched.color = color;
+}
+
+/**
+ * Set the mbuf sched queue_id, traffic_class and color.
+ *
+ * @param m
+ * Mbuf to set
+ * @param queue_id
+ * Queue id value to be set
+ * @param traffic_class
+ * Traffic class id value to be set
+ * @param color
+ * Color id to be set
+ */
+static inline void
+rte_mbuf_sched_set(struct rte_mbuf *m, uint32_t queue_id,
+ uint8_t traffic_class,
+ uint8_t color)
+{
+ m->hash.sched = (struct rte_mbuf_sched){
+ .queue_id = queue_id,
+ .traffic_class = traffic_class,
+ .color = color,
+ };
+}
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_pipeline/rte_table_action.c b/lib/librte_pipeline/rte_table_action.c
index 7c7c8dd82..8a2bb13dc 100644
--- a/lib/librte_pipeline/rte_table_action.c
+++ b/lib/librte_pipeline/rte_table_action.c
@@ -107,14 +107,6 @@ mtr_cfg_check(struct rte_table_action_mtr_config *mtr)
return 0;
}
-#define MBUF_SCHED_QUEUE_TC_COLOR(queue, tc, color) \
- ((uint16_t)((((uint64_t)(queue)) & 0x3) | \
- ((((uint64_t)(tc)) & 0x3) << 2) | \
- ((((uint64_t)(color)) & 0x3) << 4)))
-
-#define MBUF_SCHED_COLOR(sched, color) \
- (((sched) & (~0x30LLU)) | ((color) << 4))
-
struct mtr_trtcm_data {
struct rte_meter_trtcm trtcm;
uint64_t stats[e_RTE_METER_COLORS];
@@ -176,7 +168,7 @@ mtr_data_size(struct rte_table_action_mtr_config *mtr)
struct dscp_table_entry_data {
enum rte_meter_color color;
uint16_t tc;
- uint16_t queue_tc_color;
+ uint16_t tc_queue;
};
struct dscp_table_data {
@@ -319,8 +311,7 @@ pkt_work_mtr(struct rte_mbuf *mbuf,
uint32_t dscp,
uint16_t total_length)
{
- uint64_t drop_mask, sched;
- uint64_t *sched_ptr = (uint64_t *) &mbuf->hash.sched;
+ uint64_t drop_mask;
struct dscp_table_entry_data *dscp_entry = &dscp_table->entry[dscp];
enum rte_meter_color color_in, color_meter, color_policer;
uint32_t tc, mp_id;
@@ -329,7 +320,6 @@ pkt_work_mtr(struct rte_mbuf *mbuf,
color_in = dscp_entry->color;
data += tc;
mp_id = MTR_TRTCM_DATA_METER_PROFILE_ID_GET(data);
- sched = *sched_ptr;
/* Meter */
color_meter = rte_meter_trtcm_color_aware_check(
@@ -346,7 +336,7 @@ pkt_work_mtr(struct rte_mbuf *mbuf,
drop_mask = MTR_TRTCM_DATA_POLICER_ACTION_DROP_GET(data, color_meter);
color_policer =
MTR_TRTCM_DATA_POLICER_ACTION_COLOR_GET(data, color_meter);
- *sched_ptr = MBUF_SCHED_COLOR(sched, color_policer);
+ rte_mbuf_sched_color_set(mbuf, (uint8_t)color_policer);
return drop_mask;
}
@@ -368,9 +358,8 @@ tm_cfg_check(struct rte_table_action_tm_config *tm)
}
struct tm_data {
- uint16_t queue_tc_color;
- uint16_t subport;
- uint32_t pipe;
+ uint32_t queue_id;
+ uint32_t reserved;
} __attribute__((__packed__));
static int
@@ -397,9 +386,9 @@ tm_apply(struct tm_data *data,
return status;
/* Apply */
- data->queue_tc_color = 0;
- data->subport = (uint16_t) p->subport_id;
- data->pipe = p->pipe_id;
+ data->queue_id = p->subport_id <<
+ (__builtin_ctz(cfg->n_pipes_per_subport) + 4) |
+ p->pipe_id << 4;
return 0;
}
@@ -411,12 +400,11 @@ pkt_work_tm(struct rte_mbuf *mbuf,
uint32_t dscp)
{
struct dscp_table_entry_data *dscp_entry = &dscp_table->entry[dscp];
- struct tm_data *sched_ptr = (struct tm_data *) &mbuf->hash.sched;
- struct tm_data sched;
-
- sched = *data;
- sched.queue_tc_color = dscp_entry->queue_tc_color;
- *sched_ptr = sched;
+ uint32_t queue_id = data->queue_id |
+ (dscp_entry->tc << 2) |
+ dscp_entry->tc_queue;
+ rte_mbuf_sched_set(mbuf, queue_id, dscp_entry->tc,
+ (uint8_t)dscp_entry->color);
}
/**
@@ -2580,17 +2568,13 @@ rte_table_action_dscp_table_update(struct rte_table_action *action,
&action->dscp_table.entry[i];
struct rte_table_action_dscp_table_entry *entry =
&table->entry[i];
- uint16_t queue_tc_color =
- MBUF_SCHED_QUEUE_TC_COLOR(entry->tc_queue_id,
- entry->tc_id,
- entry->color);
if ((dscp_mask & (1LLU << i)) == 0)
continue;
data->color = entry->color;
data->tc = entry->tc_id;
- data->queue_tc_color = queue_tc_color;
+ data->tc_queue = entry->tc_queue_id;
}
return 0;
diff --git a/lib/librte_sched/Makefile b/lib/librte_sched/Makefile
index 46c53ed71..644fd9d15 100644
--- a/lib/librte_sched/Makefile
+++ b/lib/librte_sched/Makefile
@@ -18,7 +18,7 @@ LDLIBS += -lrte_timer
EXPORT_MAP := rte_sched_version.map
-LIBABIVER := 1
+LIBABIVER := 2
#
# all source are stored in SRCS-y
diff --git a/lib/librte_sched/meson.build b/lib/librte_sched/meson.build
index f85d64df8..8e989e5f6 100644
--- a/lib/librte_sched/meson.build
+++ b/lib/librte_sched/meson.build
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017 Intel Corporation
+version = 2
sources = files('rte_sched.c', 'rte_red.c', 'rte_approx.c')
headers = files('rte_sched.h', 'rte_sched_common.h',
'rte_red.h', 'rte_approx.h')
diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c
index 587d5e602..dd7739172 100644
--- a/lib/librte_sched/rte_sched.c
+++ b/lib/librte_sched/rte_sched.c
@@ -128,22 +128,6 @@ enum grinder_state {
e_GRINDER_READ_MBUF
};
-/*
- * Path through the scheduler hierarchy used by the scheduler enqueue
- * operation to identify the destination queue for the current
- * packet. Stored in the field pkt.hash.sched of struct rte_mbuf of
- * each packet, typically written by the classification stage and read
- * by scheduler enqueue.
- */
-struct rte_sched_port_hierarchy {
- uint16_t queue:2; /**< Queue ID (0 .. 3) */
- uint16_t traffic_class:2; /**< Traffic class ID (0 .. 3)*/
- uint32_t color:2; /**< Color */
- uint16_t unused:10;
- uint16_t subport; /**< Subport ID */
- uint32_t pipe; /**< Pipe ID */
-};
-
struct rte_sched_grinder {
/* Pipe cache */
uint16_t pcache_qmask[RTE_SCHED_GRINDER_PCACHE_SIZE];
@@ -185,6 +169,7 @@ struct rte_sched_port {
/* User parameters */
uint32_t n_subports_per_port;
uint32_t n_pipes_per_subport;
+ uint32_t n_pipes_per_subport_log2;
uint32_t rate;
uint32_t mtu;
uint32_t frame_overhead;
@@ -645,6 +630,8 @@ rte_sched_port_config(struct rte_sched_port_params *params)
/* User parameters */
port->n_subports_per_port = params->n_subports_per_port;
port->n_pipes_per_subport = params->n_pipes_per_subport;
+ port->n_pipes_per_subport_log2 =
+ __builtin_ctz(params->n_pipes_per_subport);
port->rate = params->rate;
port->mtu = params->mtu + params->frame_overhead;
port->frame_overhead = params->frame_overhead;
@@ -1006,44 +993,52 @@ rte_sched_port_pipe_profile_add(struct rte_sched_port *port,
return 0;
}
+static inline uint32_t
+rte_sched_port_qindex(struct rte_sched_port *port,
+ uint32_t subport,
+ uint32_t pipe,
+ uint32_t traffic_class,
+ uint32_t queue)
+{
+ return ((subport & (port->n_subports_per_port - 1)) <<
+ (port->n_pipes_per_subport_log2 + 4)) |
+ ((pipe & (port->n_pipes_per_subport - 1)) << 4) |
+ ((traffic_class &
+ (RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE - 1)) << 2) |
+ (queue & (RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS - 1));
+}
+
void
-rte_sched_port_pkt_write(struct rte_mbuf *pkt,
- uint32_t subport, uint32_t pipe, uint32_t traffic_class,
+rte_sched_port_pkt_write(struct rte_sched_port *port,
+ struct rte_mbuf *pkt,
+ uint32_t subport, uint32_t pipe,
+ uint32_t traffic_class,
uint32_t queue, enum rte_meter_color color)
{
- struct rte_sched_port_hierarchy *sched
- = (struct rte_sched_port_hierarchy *) &pkt->hash.sched;
-
- RTE_BUILD_BUG_ON(sizeof(*sched) > sizeof(pkt->hash.sched));
-
- sched->color = (uint32_t) color;
- sched->subport = subport;
- sched->pipe = pipe;
- sched->traffic_class = traffic_class;
- sched->queue = queue;
+ uint32_t queue_id = rte_sched_port_qindex(port, subport, pipe,
+ traffic_class, queue);
+ rte_mbuf_sched_set(pkt, queue_id, traffic_class, (uint8_t)color);
}
void
-rte_sched_port_pkt_read_tree_path(const struct rte_mbuf *pkt,
+rte_sched_port_pkt_read_tree_path(struct rte_sched_port *port,
+ const struct rte_mbuf *pkt,
uint32_t *subport, uint32_t *pipe,
uint32_t *traffic_class, uint32_t *queue)
{
- const struct rte_sched_port_hierarchy *sched
- = (const struct rte_sched_port_hierarchy *) &pkt->hash.sched;
+ uint32_t queue_id = rte_mbuf_sched_queue_get(pkt);
- *subport = sched->subport;
- *pipe = sched->pipe;
- *traffic_class = sched->traffic_class;
- *queue = sched->queue;
+ *subport = queue_id >> (port->n_pipes_per_subport_log2 + 4);
+ *pipe = (queue_id >> 4) & (port->n_pipes_per_subport - 1);
+ *traffic_class = (queue_id >> 2) &
+ (RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE - 1);
+ *queue = queue_id & (RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS - 1);
}
enum rte_meter_color
rte_sched_port_pkt_read_color(const struct rte_mbuf *pkt)
{
- const struct rte_sched_port_hierarchy *sched
- = (const struct rte_sched_port_hierarchy *) &pkt->hash.sched;
-
- return (enum rte_meter_color) sched->color;
+ return (enum rte_meter_color)rte_mbuf_sched_color_get(pkt);
}
int
@@ -1100,18 +1095,6 @@ rte_sched_queue_read_stats(struct rte_sched_port *port,
return 0;
}
-static inline uint32_t
-rte_sched_port_qindex(struct rte_sched_port *port, uint32_t subport, uint32_t pipe, uint32_t traffic_class, uint32_t queue)
-{
- uint32_t result;
-
- result = subport * port->n_pipes_per_subport + pipe;
- result = result * RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE + traffic_class;
- result = result * RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS + queue;
-
- return result;
-}
-
#ifdef RTE_SCHED_DEBUG
static inline int
@@ -1272,11 +1255,8 @@ rte_sched_port_enqueue_qptrs_prefetch0(struct rte_sched_port *port,
#ifdef RTE_SCHED_COLLECT_STATS
struct rte_sched_queue_extra *qe;
#endif
- uint32_t subport, pipe, traffic_class, queue, qindex;
-
- rte_sched_port_pkt_read_tree_path(pkt, &subport, &pipe, &traffic_class, &queue);
+ uint32_t qindex = rte_mbuf_sched_queue_get(pkt);
- qindex = rte_sched_port_qindex(port, subport, pipe, traffic_class, queue);
q = port->queue + qindex;
rte_prefetch0(q);
#ifdef RTE_SCHED_COLLECT_STATS
diff --git a/lib/librte_sched/rte_sched.h b/lib/librte_sched/rte_sched.h
index 84fa896de..243efa1d4 100644
--- a/lib/librte_sched/rte_sched.h
+++ b/lib/librte_sched/rte_sched.h
@@ -355,6 +355,8 @@ rte_sched_queue_read_stats(struct rte_sched_port *port,
* Scheduler hierarchy path write to packet descriptor. Typically
* called by the packet classification stage.
*
+ * @param port
+ * Handle to port scheduler instance
* @param pkt
* Packet descriptor handle
* @param subport
@@ -369,7 +371,8 @@ rte_sched_queue_read_stats(struct rte_sched_port *port,
* Packet color set
*/
void
-rte_sched_port_pkt_write(struct rte_mbuf *pkt,
+rte_sched_port_pkt_write(struct rte_sched_port *port,
+ struct rte_mbuf *pkt,
uint32_t subport, uint32_t pipe, uint32_t traffic_class,
uint32_t queue, enum rte_meter_color color);
@@ -379,6 +382,8 @@ rte_sched_port_pkt_write(struct rte_mbuf *pkt,
* enqueue operation. The subport, pipe, traffic class and queue
* parameters need to be pre-allocated by the caller.
*
+ * @param port
+ * Handle to port scheduler instance
* @param pkt
* Packet descriptor handle
* @param subport
@@ -392,7 +397,8 @@ rte_sched_port_pkt_write(struct rte_mbuf *pkt,
*
*/
void
-rte_sched_port_pkt_read_tree_path(const struct rte_mbuf *pkt,
+rte_sched_port_pkt_read_tree_path(struct rte_sched_port *port,
+ const struct rte_mbuf *pkt,
uint32_t *subport, uint32_t *pipe,
uint32_t *traffic_class, uint32_t *queue);
diff --git a/test/test/test_sched.c b/test/test/test_sched.c
index 32e500ba9..40e411cab 100644
--- a/test/test/test_sched.c
+++ b/test/test/test_sched.c
@@ -76,7 +76,7 @@ create_mempool(void)
}
static void
-prepare_pkt(struct rte_mbuf *mbuf)
+prepare_pkt(struct rte_sched_port *port, struct rte_mbuf *mbuf)
{
struct ether_hdr *eth_hdr;
struct vlan_hdr *vlan1, *vlan2;
@@ -95,7 +95,8 @@ prepare_pkt(struct rte_mbuf *mbuf)
ip_hdr->dst_addr = IPv4(0,0,TC,QUEUE);
- rte_sched_port_pkt_write(mbuf, SUBPORT, PIPE, TC, QUEUE, e_RTE_METER_YELLOW);
+ rte_sched_port_pkt_write(port, mbuf, SUBPORT, PIPE, TC, QUEUE,
+ e_RTE_METER_YELLOW);
/* 64 byte packet */
mbuf->pkt_len = 60;
@@ -138,7 +139,7 @@ test_sched(void)
for (i = 0; i < 10; i++) {
in_mbufs[i] = rte_pktmbuf_alloc(mp);
TEST_ASSERT_NOT_NULL(in_mbufs[i], "Packet allocation failed\n");
- prepare_pkt(in_mbufs[i]);
+ prepare_pkt(port, in_mbufs[i]);
}
@@ -155,7 +156,7 @@ test_sched(void)
color = rte_sched_port_pkt_read_color(out_mbufs[i]);
TEST_ASSERT_EQUAL(color, e_RTE_METER_YELLOW, "Wrong color\n");
- rte_sched_port_pkt_read_tree_path(out_mbufs[i],
+ rte_sched_port_pkt_read_tree_path(port, out_mbufs[i],
&subport, &pipe, &traffic_class, &queue);
TEST_ASSERT_EQUAL(subport, SUBPORT, "Wrong subport\n");
--
2.17.1
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v7 2/2] mbuf: implement generic format for sched field
2018-12-20 12:16 ` [dpdk-dev] [PATCH v7 2/2] mbuf: implement generic format for sched field Reshma Pattan
@ 2018-12-20 12:43 ` Olivier Matz
2018-12-20 19:11 ` Dumitrescu, Cristian
2018-12-20 14:55 ` Rao, Nikhil
` (2 subsequent siblings)
3 siblings, 1 reply; 74+ messages in thread
From: Olivier Matz @ 2018-12-20 12:43 UTC (permalink / raw)
To: Reshma Pattan
Cc: dev, jerin.jacob, nikhil.rao, thomas, jasvinder.singh,
cristian.dumitrescu, konstantin.ananyev
On Thu, Dec 20, 2018 at 12:16:09PM +0000, Reshma Pattan wrote:
> This patch implements the changes proposed in the deprecation
> notes [1][2].
>
> librte_mbuf changes:
> The mbuf->hash.sched field is updated to support generic
> definition in line with the ethdev traffic manager and meter APIs.
> The new generic format contains: queue ID, traffic class, color.
>
> Added public APIs to set and get these new fields to and from mbuf.
>
> librte_sched changes:
> In addtion, following API functions of the sched library have
> been modified with an additional parameter of type struct
> rte_sched_port to accommodate the changes made to mbuf sched field.
> (i)rte_sched_port_pkt_write()
> (ii) rte_sched_port_pkt_read_tree_path()
>
> librte_pipeline, qos_sched UT, qos_sched app are updated
> to make use of new changes.
>
> Also mbuf->hash.txadapter has been added for eventdev txq,
> rte_event_eth_tx_adapter_txq_set and rte_event_eth_tx_adapter_txq_get()
> are updated to use mbuf->hash.txadapter.txq.
>
> doc:
> Release notes updated.
> Removed deprecation notice for mbuf->hash.sched and sched API.
>
> [1] http://mails.dpdk.org/archives/dev/2018-February/090651.html
> [2] https://mails.dpdk.org/archives/dev/2018-November/119051.html
>
> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
> Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
Acked-by: Olivier Matz <olivier.matz@6wind.com>
Thanks
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v7 2/2] mbuf: implement generic format for sched field
2018-12-20 12:43 ` Olivier Matz
@ 2018-12-20 19:11 ` Dumitrescu, Cristian
0 siblings, 0 replies; 74+ messages in thread
From: Dumitrescu, Cristian @ 2018-12-20 19:11 UTC (permalink / raw)
To: Olivier Matz, Pattan, Reshma
Cc: dev, jerin.jacob, Rao, Nikhil, thomas, Singh, Jasvinder, Ananyev,
Konstantin
> -----Original Message-----
> From: Olivier Matz [mailto:olivier.matz@6wind.com]
> Sent: Thursday, December 20, 2018 12:43 PM
> To: Pattan, Reshma <reshma.pattan@intel.com>
> Cc: dev@dpdk.org; jerin.jacob@caviumnetworks.com; Rao, Nikhil
> <nikhil.rao@intel.com>; thomas@monjalon.net; Singh, Jasvinder
> <jasvinder.singh@intel.com>; Dumitrescu, Cristian
> <cristian.dumitrescu@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>
> Subject: Re: [PATCH v7 2/2] mbuf: implement generic format for sched field
>
> On Thu, Dec 20, 2018 at 12:16:09PM +0000, Reshma Pattan wrote:
> > This patch implements the changes proposed in the deprecation
> > notes [1][2].
> >
> > librte_mbuf changes:
> > The mbuf->hash.sched field is updated to support generic
> > definition in line with the ethdev traffic manager and meter APIs.
> > The new generic format contains: queue ID, traffic class, color.
> >
> > Added public APIs to set and get these new fields to and from mbuf.
> >
> > librte_sched changes:
> > In addtion, following API functions of the sched library have
> > been modified with an additional parameter of type struct
> > rte_sched_port to accommodate the changes made to mbuf sched field.
> > (i)rte_sched_port_pkt_write()
> > (ii) rte_sched_port_pkt_read_tree_path()
> >
> > librte_pipeline, qos_sched UT, qos_sched app are updated
> > to make use of new changes.
> >
> > Also mbuf->hash.txadapter has been added for eventdev txq,
> > rte_event_eth_tx_adapter_txq_set and
> rte_event_eth_tx_adapter_txq_get()
> > are updated to use mbuf->hash.txadapter.txq.
> >
> > doc:
> > Release notes updated.
> > Removed deprecation notice for mbuf->hash.sched and sched API.
> >
> > [1] http://mails.dpdk.org/archives/dev/2018-February/090651.html
> > [2] https://mails.dpdk.org/archives/dev/2018-November/119051.html
> >
> > Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
> > Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> > Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
>
> Acked-by: Olivier Matz <olivier.matz@6wind.com>
>
> Thanks
Patch set applied to next-qos tree, thanks!
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [dpdk-dev] [PATCH v7 2/2] mbuf: implement generic format for sched field
2018-12-20 12:16 ` [dpdk-dev] [PATCH v7 2/2] mbuf: implement generic format for sched field Reshma Pattan
2018-12-20 12:43 ` Olivier Matz
@ 2018-12-20 14:55 ` Rao, Nikhil
2019-01-15 22:37 ` Stephen Hemminger
2019-01-15 23:11 ` Stephen Hemminger
3 siblings, 0 replies; 74+ messages in thread
From: Rao, Nikhil @ 2018-12-20 14:55 UTC (permalink / raw)
To: Pattan, Reshma, dev, jerin.jacob, olivier.matz, thomas, Singh,
Jasvinder, Dumitrescu, Cristian, Ananyev, Konstantin
> -----Original Message-----
> From: Pattan, Reshma
> Sent: Thursday, December 20, 2018 5:46 PM
> To: dev@dpdk.org; jerin.jacob@caviumnetworks.com; Rao, Nikhil
> <nikhil.rao@intel.com>; olivier.matz@6wind.com; thomas@monjalon.net;
> Singh, Jasvinder <jasvinder.singh@intel.com>; Dumitrescu, Cristian
> <cristian.dumitrescu@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>
> Cc: Pattan, Reshma <reshma.pattan@intel.com>
> Subject: [PATCH v7 2/2] mbuf: implement generic format for sched field
>
> This patch implements the changes proposed in the deprecation notes [1][2].
>
> librte_mbuf changes:
> The mbuf->hash.sched field is updated to support generic definition in line
> with the ethdev traffic manager and meter APIs.
> The new generic format contains: queue ID, traffic class, color.
>
> Added public APIs to set and get these new fields to and from mbuf.
>
> librte_sched changes:
> In addtion, following API functions of the sched library have been modified
> with an additional parameter of type struct rte_sched_port to accommodate
> the changes made to mbuf sched field.
> (i)rte_sched_port_pkt_write()
> (ii) rte_sched_port_pkt_read_tree_path()
>
> librte_pipeline, qos_sched UT, qos_sched app are updated to make use of
> new changes.
>
> Also mbuf->hash.txadapter has been added for eventdev txq,
> rte_event_eth_tx_adapter_txq_set and rte_event_eth_tx_adapter_txq_get()
> are updated to use mbuf->hash.txadapter.txq.
>
> doc:
> Release notes updated.
> Removed deprecation notice for mbuf->hash.sched and sched API.
>
> [1] http://mails.dpdk.org/archives/dev/2018-February/090651.html
> [2] https://mails.dpdk.org/archives/dev/2018-November/119051.html
>
> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
> Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> ---
> v7:
>
> Edited the commit message.
> Moved rte_mbuf_sched inside the rte_mbuf struct.
> Added missing empty line in doxygen comments of sched set and get
> functions.
>
> v6: added scheduler comment
>
> v5:
> Removed librte_meter from librte_mbuf dependency list.
> Changed the mbuf set/get functions to use uint8_t for color.
>
> v4: converted mbuf->hash.sched as instantiation of rte_mbuf_sched.
>
> v3: addressed review comments given in the below link.
> http://patches.dpdk.org/patch/48587/
> Updated library ABI versioning in meson build.
> ---
> ---
> doc/guides/rel_notes/deprecation.rst | 10 --
> doc/guides/rel_notes/release_19_02.rst | 4 +-
> examples/qos_sched/app_thread.c | 7 +-
> examples/qos_sched/main.c | 1 +
> .../rte_event_eth_tx_adapter.h | 18 ++-
> lib/librte_mbuf/Makefile | 2 +-
> lib/librte_mbuf/meson.build | 2 +-
> lib/librte_mbuf/rte_mbuf.h | 119 +++++++++++++++++-
> lib/librte_pipeline/rte_table_action.c | 44 +++----
> lib/librte_sched/Makefile | 2 +-
> lib/librte_sched/meson.build | 1 +
> lib/librte_sched/rte_sched.c | 90 ++++++-------
> lib/librte_sched/rte_sched.h | 10 +-
> test/test/test_sched.c | 9 +-
> 14 files changed, 197 insertions(+), 122 deletions(-)
>
> diff --git a/lib/librte_eventdev/rte_event_eth_tx_adapter.h
> b/lib/librte_eventdev/rte_event_eth_tx_adapter.h
> index 81456d4a9..2a50656d9 100644
> --- a/lib/librte_eventdev/rte_event_eth_tx_adapter.h
> +++ b/lib/librte_eventdev/rte_event_eth_tx_adapter.h
> @@ -63,13 +63,11 @@
> * function can be used to retrieve the adapter's service function ID.
> *
> * The ethernet port and transmit queue index to transmit the mbuf on are
> - * specified using the mbuf port and the higher 16 bits of
> - * struct rte_mbuf::hash::sched:hi. The application should use the
> - * rte_event_eth_tx_adapter_txq_set() and
> rte_event_eth_tx_adapter_txq_get()
> - * functions to access the transmit queue index since it is expected that the
> - * transmit queue will be eventually defined within struct rte_mbuf and using
> - * these macros will help with minimizing application impact due to
> - * a change in how the transmit queue index is specified.
> + * specified using the mbuf port struct rte_mbuf::hash::txadapter:txq.
> + * The application should use the rte_event_eth_tx_adapter_txq_set()
> + * and rte_event_eth_tx_adapter_txq_get() functions to access the
> + transmit
> + * queue index, using these macros will help with minimizing
> + application
> + * impact due to a change in how the transmit queue index is specified.
> */
>
> #ifdef __cplusplus
> @@ -300,8 +298,7 @@ rte_event_eth_tx_adapter_queue_del(uint8_t id,
> static __rte_always_inline void __rte_experimental
> rte_event_eth_tx_adapter_txq_set(struct rte_mbuf *pkt, uint16_t queue) {
> - uint16_t *p = (uint16_t *)&pkt->hash.sched.hi;
> - p[1] = queue;
> + pkt->hash.txadapter.txq = queue;
> }
>
> /**
> @@ -320,8 +317,7 @@ rte_event_eth_tx_adapter_txq_set(struct rte_mbuf
> *pkt, uint16_t queue) static __rte_always_inline uint16_t
> __rte_experimental rte_event_eth_tx_adapter_txq_get(struct rte_mbuf
> *pkt) {
> - uint16_t *p = (uint16_t *)&pkt->hash.sched.hi;
> - return p[1];
> + return pkt->hash.txadapter.txq;
> }
>
Event Tx adapter changes
Tested-by: Nikhil Rao <nikhil.rao@intel.com>
Reviewed-by: Nikhil Rao <nikhil.rao@intel.com>
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v7 2/2] mbuf: implement generic format for sched field
2018-12-20 12:16 ` [dpdk-dev] [PATCH v7 2/2] mbuf: implement generic format for sched field Reshma Pattan
2018-12-20 12:43 ` Olivier Matz
2018-12-20 14:55 ` Rao, Nikhil
@ 2019-01-15 22:37 ` Stephen Hemminger
2019-01-16 9:19 ` Pattan, Reshma
2019-01-15 23:11 ` Stephen Hemminger
3 siblings, 1 reply; 74+ messages in thread
From: Stephen Hemminger @ 2019-01-15 22:37 UTC (permalink / raw)
To: Reshma Pattan
Cc: dev, jerin.jacob, nikhil.rao, olivier.matz, thomas,
jasvinder.singh, cristian.dumitrescu, konstantin.ananyev
On Thu, 20 Dec 2018 12:16:09 +0000
Reshma Pattan <reshma.pattan@intel.com> wrote:
> This patch implements the changes proposed in the deprecation
> notes [1][2].
>
> librte_mbuf changes:
> The mbuf->hash.sched field is updated to support generic
> definition in line with the ethdev traffic manager and meter APIs.
> The new generic format contains: queue ID, traffic class, color.
>
> Added public APIs to set and get these new fields to and from mbuf.
>
> librte_sched changes:
> In addtion, following API functions of the sched library have
> been modified with an additional parameter of type struct
> rte_sched_port to accommodate the changes made to mbuf sched field.
> (i)rte_sched_port_pkt_write()
> (ii) rte_sched_port_pkt_read_tree_path()
>
> librte_pipeline, qos_sched UT, qos_sched app are updated
> to make use of new changes.
>
> Also mbuf->hash.txadapter has been added for eventdev txq,
> rte_event_eth_tx_adapter_txq_set and rte_event_eth_tx_adapter_txq_get()
> are updated to use mbuf->hash.txadapter.txq.
>
> doc:
> Release notes updated.
> Removed deprecation notice for mbuf->hash.sched and sched API.
>
> [1] http://mails.dpdk.org/archives/dev/2018-February/090651.html
> [2] https://mails.dpdk.org/archives/dev/2018-November/119051.html
>
> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
> Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
This patch breaks build of VPP because it refers to sched.hi and sched.lo.
Breaking source compatibility is as bad (if not worse) than ABI breakage.
Maybe make the sched field a union?
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [dpdk-dev] [PATCH v7 2/2] mbuf: implement generic format for sched field
2019-01-15 22:37 ` Stephen Hemminger
@ 2019-01-16 9:19 ` Pattan, Reshma
2019-01-16 9:33 ` Dumitrescu, Cristian
0 siblings, 1 reply; 74+ messages in thread
From: Pattan, Reshma @ 2019-01-16 9:19 UTC (permalink / raw)
To: Stephen Hemminger
Cc: dev, jerin.jacob, Rao, Nikhil, olivier.matz, thomas, Singh,
Jasvinder, Dumitrescu, Cristian, Ananyev, Konstantin
Hi
> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Tuesday, January 15, 2019 10:37 PM
> To: Pattan, Reshma <reshma.pattan@intel.com>
> Cc: dev@dpdk.org; jerin.jacob@caviumnetworks.com; Rao, Nikhil
> <nikhil.rao@intel.com>; olivier.matz@6wind.com; thomas@monjalon.net;
> Singh, Jasvinder <jasvinder.singh@intel.com>; Dumitrescu, Cristian
> <cristian.dumitrescu@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v7 2/2] mbuf: implement generic format for
> sched field
>
> On Thu, 20 Dec 2018 12:16:09 +0000
> Reshma Pattan <reshma.pattan@intel.com> wrote:
>
> > This patch implements the changes proposed in the deprecation notes
> > [1][2].
> >
> > librte_mbuf changes:
> > The mbuf->hash.sched field is updated to support generic definition in
> > line with the ethdev traffic manager and meter APIs.
> > The new generic format contains: queue ID, traffic class, color.
> >
> > Added public APIs to set and get these new fields to and from mbuf.
> >
> > librte_sched changes:
> > In addtion, following API functions of the sched library have been
> > modified with an additional parameter of type struct rte_sched_port to
> > accommodate the changes made to mbuf sched field.
> > (i)rte_sched_port_pkt_write()
> > (ii) rte_sched_port_pkt_read_tree_path()
> >
> > librte_pipeline, qos_sched UT, qos_sched app are updated to make use
> > of new changes.
> >
> > Also mbuf->hash.txadapter has been added for eventdev txq,
> > rte_event_eth_tx_adapter_txq_set and
> > rte_event_eth_tx_adapter_txq_get()
> > are updated to use mbuf->hash.txadapter.txq.
> >
> > doc:
> > Release notes updated.
> > Removed deprecation notice for mbuf->hash.sched and sched API.
> >
> > [1] http://mails.dpdk.org/archives/dev/2018-February/090651.html
> > [2] https://mails.dpdk.org/archives/dev/2018-November/119051.html
> >
> > Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
> > Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> > Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
>
>
> This patch breaks build of VPP because it refers to sched.hi and sched.lo.
> Breaking source compatibility is as bad (if not worse) than ABI breakage.
>
Yes this breaks the build and we have actions to fix VPP Qos Sched when DPDK 19.02 is formally integrated to VPP.
Thanks,
Reshma
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [dpdk-dev] [PATCH v7 2/2] mbuf: implement generic format for sched field
2019-01-16 9:19 ` Pattan, Reshma
@ 2019-01-16 9:33 ` Dumitrescu, Cristian
2019-01-16 10:09 ` Singh, Jasvinder
0 siblings, 1 reply; 74+ messages in thread
From: Dumitrescu, Cristian @ 2019-01-16 9:33 UTC (permalink / raw)
To: Pattan, Reshma, Stephen Hemminger
Cc: dev, jerin.jacob, Rao, Nikhil, olivier.matz, thomas, Singh,
Jasvinder, Ananyev, Konstantin
> -----Original Message-----
> From: Pattan, Reshma
> Sent: Wednesday, January 16, 2019 9:19 AM
> To: Stephen Hemminger <stephen@networkplumber.org>
> Cc: dev@dpdk.org; jerin.jacob@caviumnetworks.com; Rao, Nikhil
> <nikhil.rao@intel.com>; olivier.matz@6wind.com; thomas@monjalon.net;
> Singh, Jasvinder <jasvinder.singh@intel.com>; Dumitrescu, Cristian
> <cristian.dumitrescu@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>
> Subject: RE: [dpdk-dev] [PATCH v7 2/2] mbuf: implement generic format for
> sched field
>
> Hi
>
> > -----Original Message-----
> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > Sent: Tuesday, January 15, 2019 10:37 PM
> > To: Pattan, Reshma <reshma.pattan@intel.com>
> > Cc: dev@dpdk.org; jerin.jacob@caviumnetworks.com; Rao, Nikhil
> > <nikhil.rao@intel.com>; olivier.matz@6wind.com; thomas@monjalon.net;
> > Singh, Jasvinder <jasvinder.singh@intel.com>; Dumitrescu, Cristian
> > <cristian.dumitrescu@intel.com>; Ananyev, Konstantin
> > <konstantin.ananyev@intel.com>
> > Subject: Re: [dpdk-dev] [PATCH v7 2/2] mbuf: implement generic format
> for
> > sched field
> >
> > On Thu, 20 Dec 2018 12:16:09 +0000
> > Reshma Pattan <reshma.pattan@intel.com> wrote:
> >
> > > This patch implements the changes proposed in the deprecation notes
> > > [1][2].
> > >
> > > librte_mbuf changes:
> > > The mbuf->hash.sched field is updated to support generic definition in
> > > line with the ethdev traffic manager and meter APIs.
> > > The new generic format contains: queue ID, traffic class, color.
> > >
> > > Added public APIs to set and get these new fields to and from mbuf.
> > >
> > > librte_sched changes:
> > > In addtion, following API functions of the sched library have been
> > > modified with an additional parameter of type struct rte_sched_port to
> > > accommodate the changes made to mbuf sched field.
> > > (i)rte_sched_port_pkt_write()
> > > (ii) rte_sched_port_pkt_read_tree_path()
> > >
> > > librte_pipeline, qos_sched UT, qos_sched app are updated to make use
> > > of new changes.
> > >
> > > Also mbuf->hash.txadapter has been added for eventdev txq,
> > > rte_event_eth_tx_adapter_txq_set and
> > > rte_event_eth_tx_adapter_txq_get()
> > > are updated to use mbuf->hash.txadapter.txq.
> > >
> > > doc:
> > > Release notes updated.
> > > Removed deprecation notice for mbuf->hash.sched and sched API.
> > >
> > > [1] http://mails.dpdk.org/archives/dev/2018-February/090651.html
> > > [2] https://mails.dpdk.org/archives/dev/2018-November/119051.html
> > >
> > > Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
> > > Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> > > Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> >
> >
> > This patch breaks build of VPP because it refers to sched.hi and sched.lo.
> > Breaking source compatibility is as bad (if not worse) than ABI breakage.
> >
>
> Yes this breaks the build and we have actions to fix VPP Qos Sched when
> DPDK 19.02 is formally integrated to VPP.
>
> Thanks,
> Reshma
Yes, Jasvinder is the maintainer of the VPP HQoS code, this is on his plate to fix in VPP for the next VPP release using DPDK release 19.02.
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [dpdk-dev] [PATCH v7 2/2] mbuf: implement generic format for sched field
2019-01-16 9:33 ` Dumitrescu, Cristian
@ 2019-01-16 10:09 ` Singh, Jasvinder
0 siblings, 0 replies; 74+ messages in thread
From: Singh, Jasvinder @ 2019-01-16 10:09 UTC (permalink / raw)
To: Dumitrescu, Cristian, Pattan, Reshma, Stephen Hemminger
Cc: dev, jerin.jacob, Rao, Nikhil, olivier.matz, thomas, Ananyev, Konstantin
<snip>
> >
> > > -----Original Message-----
> > > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > > Sent: Tuesday, January 15, 2019 10:37 PM
> > > To: Pattan, Reshma <reshma.pattan@intel.com>
> > > Cc: dev@dpdk.org; jerin.jacob@caviumnetworks.com; Rao, Nikhil
> > > <nikhil.rao@intel.com>; olivier.matz@6wind.com; thomas@monjalon.net;
> > > Singh, Jasvinder <jasvinder.singh@intel.com>; Dumitrescu, Cristian
> > > <cristian.dumitrescu@intel.com>; Ananyev, Konstantin
> > > <konstantin.ananyev@intel.com>
> > > Subject: Re: [dpdk-dev] [PATCH v7 2/2] mbuf: implement generic
> > > format
> > for
> > > sched field
> > >
> > > On Thu, 20 Dec 2018 12:16:09 +0000
> > > Reshma Pattan <reshma.pattan@intel.com> wrote:
> > >
> > > > This patch implements the changes proposed in the deprecation
> > > > notes [1][2].
> > > >
> > > > librte_mbuf changes:
> > > > The mbuf->hash.sched field is updated to support generic
> > > > definition in line with the ethdev traffic manager and meter APIs.
> > > > The new generic format contains: queue ID, traffic class, color.
> > > >
> > > > Added public APIs to set and get these new fields to and from mbuf.
> > > >
> > > > librte_sched changes:
> > > > In addtion, following API functions of the sched library have been
> > > > modified with an additional parameter of type struct
> > > > rte_sched_port to accommodate the changes made to mbuf sched field.
> > > > (i)rte_sched_port_pkt_write()
> > > > (ii) rte_sched_port_pkt_read_tree_path()
> > > >
> > > > librte_pipeline, qos_sched UT, qos_sched app are updated to make
> > > > use of new changes.
> > > >
> > > > Also mbuf->hash.txadapter has been added for eventdev txq,
> > > > rte_event_eth_tx_adapter_txq_set and
> > > > rte_event_eth_tx_adapter_txq_get()
> > > > are updated to use mbuf->hash.txadapter.txq.
> > > >
> > > > doc:
> > > > Release notes updated.
> > > > Removed deprecation notice for mbuf->hash.sched and sched API.
> > > >
> > > > [1] http://mails.dpdk.org/archives/dev/2018-February/090651.html
> > > > [2] https://mails.dpdk.org/archives/dev/2018-November/119051.html
> > > >
> > > > Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
> > > > Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> > > > Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> > > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > >
> > >
> > > This patch breaks build of VPP because it refers to sched.hi and sched.lo.
> > > Breaking source compatibility is as bad (if not worse) than ABI breakage.
> > >
> >
> > Yes this breaks the build and we have actions to fix VPP Qos Sched
> > when DPDK 19.02 is formally integrated to VPP.
> >
> > Thanks,
> > Reshma
>
> Yes, Jasvinder is the maintainer of the VPP HQoS code, this is on his plate to fix
> in VPP for the next VPP release using DPDK release 19
Yes, patch will be up streamed as soon as dpdk19.02 is out.
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [dpdk-dev] [PATCH v7 2/2] mbuf: implement generic format for sched field
2018-12-20 12:16 ` [dpdk-dev] [PATCH v7 2/2] mbuf: implement generic format for sched field Reshma Pattan
` (2 preceding siblings ...)
2019-01-15 22:37 ` Stephen Hemminger
@ 2019-01-15 23:11 ` Stephen Hemminger
2019-01-16 8:41 ` Thomas Monjalon
3 siblings, 1 reply; 74+ messages in thread
From: Stephen Hemminger @ 2019-01-15 23:11 UTC (permalink / raw)
To: Reshma Pattan
Cc: dev, jerin.jacob, nikhil.rao, olivier.matz, thomas,
jasvinder.singh, cristian.dumitrescu, konstantin.ananyev
On Thu, 20 Dec 2018 12:16:09 +0000
Reshma Pattan <reshma.pattan@intel.com> wrote:
> void
> -rte_sched_port_pkt_write(struct rte_mbuf *pkt,
> - uint32_t subport, uint32_t pipe, uint32_t traffic_class,
> +rte_sched_port_pkt_write(struct rte_sched_port *port,
> + struct rte_mbuf *pkt,
> + uint32_t subport, uint32_t pipe,
> + uint32_t traffic_class,
> uint32_t queue, enum rte_meter_color color)
Sorry I didn't notice this earlier, but changing the function signature like
this is a complete ABI breakage. Old code will be passing different arguments than
new code; therefore this change breaks both source and binary compatibility.
Is 19.02 supposed to be an ABI/API breaking release? Or only an incremental update.
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v7 2/2] mbuf: implement generic format for sched field
2019-01-15 23:11 ` Stephen Hemminger
@ 2019-01-16 8:41 ` Thomas Monjalon
0 siblings, 0 replies; 74+ messages in thread
From: Thomas Monjalon @ 2019-01-16 8:41 UTC (permalink / raw)
To: dev
Cc: Stephen Hemminger, Reshma Pattan, jerin.jacob, nikhil.rao,
olivier.matz, jasvinder.singh, cristian.dumitrescu,
konstantin.ananyev
16/01/2019 00:11, Stephen Hemminger:
> On Thu, 20 Dec 2018 12:16:09 +0000
> Reshma Pattan <reshma.pattan@intel.com> wrote:
>
> > void
> > -rte_sched_port_pkt_write(struct rte_mbuf *pkt,
> > - uint32_t subport, uint32_t pipe, uint32_t traffic_class,
> > +rte_sched_port_pkt_write(struct rte_sched_port *port,
> > + struct rte_mbuf *pkt,
> > + uint32_t subport, uint32_t pipe,
> > + uint32_t traffic_class,
> > uint32_t queue, enum rte_meter_color color)
>
> Sorry I didn't notice this earlier, but changing the function signature like
> this is a complete ABI breakage. Old code will be passing different arguments than
> new code; therefore this change breaks both source and binary compatibility.
>
> Is 19.02 supposed to be an ABI/API breaking release? Or only an incremental update.
It is an API breaking release.
^ permalink raw reply [flat|nested] 74+ messages in thread
* [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
2018-11-23 16:54 [dpdk-dev] [PATCH] mbuf: implement generic format for sched field Jasvinder Singh
` (2 preceding siblings ...)
2018-12-07 14:31 ` [dpdk-dev] [PATCH v2 1/3] " Reshma Pattan
@ 2018-12-07 14:31 ` Reshma Pattan
2018-12-10 18:24 ` Dumitrescu, Cristian
2018-12-14 23:35 ` Ananyev, Konstantin
2018-12-07 14:31 ` [dpdk-dev] [PATCH v2 3/3] doc: add deprecation notice to remove rte meter color Reshma Pattan
4 siblings, 2 replies; 74+ messages in thread
From: Reshma Pattan @ 2018-12-07 14:31 UTC (permalink / raw)
To: dev, cristian.dumitrescu, jerin.jacob, jasvinder.singh; +Cc: Reshma Pattan
Added new rte_color definition in eal to
consolidate color definition which is currently replicated
in various places such as rte_meter.h, rte_tm.h and rte_mtr.h
Removed rte_tm_color and rte_mtr_color and used the new color
definition in rte_tm* and rte_mtr* files.
Updated softnic and testpmd to use new color definition.
Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
---
app/test-pmd/cmdline_mtr.c | 47 +++++++++++----------
app/test-pmd/cmdline_tm.c | 23 +++++-----
drivers/net/softnic/rte_eth_softnic_flow.c | 10 +++--
drivers/net/softnic/rte_eth_softnic_meter.c | 28 ++++++------
drivers/net/softnic/rte_eth_softnic_tm.c | 31 ++++++++------
lib/librte_eal/common/Makefile | 2 +-
lib/librte_eal/common/include/rte_color.h | 18 ++++++++
lib/librte_ethdev/rte_mtr.c | 2 +-
lib/librte_ethdev/rte_mtr.h | 21 +++------
lib/librte_ethdev/rte_mtr_driver.h | 2 +-
lib/librte_ethdev/rte_tm.h | 25 ++++-------
lib/librte_meter/rte_meter.h | 7 +++
12 files changed, 118 insertions(+), 98 deletions(-)
create mode 100644 lib/librte_eal/common/include/rte_color.h
diff --git a/app/test-pmd/cmdline_mtr.c b/app/test-pmd/cmdline_mtr.c
index c506d87ee..3d7861d14 100644
--- a/app/test-pmd/cmdline_mtr.c
+++ b/app/test-pmd/cmdline_mtr.c
@@ -9,6 +9,7 @@
#include <rte_ethdev.h>
#include <rte_flow.h>
#include <rte_mtr.h>
+#include <rte_color.h>
#include "testpmd.h"
#include "cmdline_mtr.h"
@@ -74,7 +75,7 @@ parse_uint(uint64_t *value, const char *str)
}
static int
-parse_dscp_table_entries(char *str, enum rte_mtr_color **dscp_table)
+parse_dscp_table_entries(char *str, enum rte_color **dscp_table)
{
char *token;
int i = 0;
@@ -84,21 +85,21 @@ parse_dscp_table_entries(char *str, enum rte_mtr_color **dscp_table)
return 0;
/* Allocate memory for dscp table */
- *dscp_table = (enum rte_mtr_color *)malloc(MAX_DSCP_TABLE_ENTRIES *
- sizeof(enum rte_mtr_color));
+ *dscp_table = (enum rte_color *)malloc(MAX_DSCP_TABLE_ENTRIES *
+ sizeof(enum rte_color));
if (*dscp_table == NULL)
return -1;
while (1) {
if (strcmp(token, "G") == 0 ||
strcmp(token, "g") == 0)
- *dscp_table[i++] = RTE_MTR_GREEN;
+ *dscp_table[i++] = RTE_COLOR_GREEN;
else if (strcmp(token, "Y") == 0 ||
strcmp(token, "y") == 0)
- *dscp_table[i++] = RTE_MTR_YELLOW;
+ *dscp_table[i++] = RTE_COLOR_YELLOW;
else if (strcmp(token, "R") == 0 ||
strcmp(token, "r") == 0)
- *dscp_table[i++] = RTE_MTR_RED;
+ *dscp_table[i++] = RTE_COLOR_RED;
else {
free(*dscp_table);
return -1;
@@ -117,7 +118,7 @@ parse_dscp_table_entries(char *str, enum rte_mtr_color **dscp_table)
static int
parse_meter_color_str(char *c_str, uint32_t *use_prev_meter_color,
- enum rte_mtr_color **dscp_table)
+ enum rte_color **dscp_table)
{
char *token;
uint64_t previous_mtr_color = 0;
@@ -182,20 +183,20 @@ parse_policer_action_string(char *p_str, uint32_t action_mask,
return -1;
if (g_color == 0 && (action_mask & 0x1)) {
- actions[RTE_MTR_GREEN] = action;
+ actions[RTE_COLOR_GREEN] = action;
g_color = 1;
} else if (y_color == 0 && (action_mask & 0x2)) {
- actions[RTE_MTR_YELLOW] = action;
+ actions[RTE_COLOR_YELLOW] = action;
y_color = 1;
} else
- actions[RTE_MTR_RED] = action;
+ actions[RTE_COLOR_RED] = action;
}
return 0;
}
static int
parse_multi_token_string(char *t_str, uint16_t *port_id,
- uint32_t *mtr_id, enum rte_mtr_color **dscp_table)
+ uint32_t *mtr_id, enum rte_color **dscp_table)
{
char *token;
uint64_t val;
@@ -782,7 +783,7 @@ static void cmd_create_port_meter_parsed(void *parsed_result,
uint32_t shared = res->shared;
uint32_t use_prev_meter_color = 0;
uint16_t port_id = res->port_id;
- enum rte_mtr_color *dscp_table = NULL;
+ enum rte_color *dscp_table = NULL;
char *c_str = res->meter_input_color;
int ret;
@@ -808,11 +809,11 @@ static void cmd_create_port_meter_parsed(void *parsed_result,
else
params.meter_enable = 0;
- params.action[RTE_MTR_GREEN] =
+ params.action[RTE_COLOR_GREEN] =
string_to_policer_action(res->g_action);
- params.action[RTE_MTR_YELLOW] =
+ params.action[RTE_COLOR_YELLOW] =
string_to_policer_action(res->y_action);
- params.action[RTE_MTR_RED] =
+ params.action[RTE_COLOR_RED] =
string_to_policer_action(res->r_action);
params.stats_mask = res->statistics_mask;
@@ -1134,7 +1135,7 @@ static void cmd_set_port_meter_dscp_table_parsed(void *parsed_result,
{
struct cmd_set_port_meter_dscp_table_result *res = parsed_result;
struct rte_mtr_error error;
- enum rte_mtr_color *dscp_table = NULL;
+ enum rte_color *dscp_table = NULL;
char *t_str = res->token_string;
uint32_t mtr_id = 0;
uint16_t port_id;
@@ -1245,7 +1246,7 @@ static void cmd_set_port_meter_policer_action_parsed(void *parsed_result,
}
/* Allocate memory for policer actions */
- actions = (enum rte_mtr_policer_action *)malloc(RTE_MTR_COLORS *
+ actions = (enum rte_mtr_policer_action *)malloc(RTE_COLORS *
sizeof(enum rte_mtr_policer_action));
if (actions == NULL) {
printf("Memory for policer actions not allocated (error)\n");
@@ -1426,22 +1427,22 @@ static void cmd_show_port_meter_stats_parsed(void *parsed_result,
/* Display stats */
if (stats_mask & RTE_MTR_STATS_N_PKTS_GREEN)
printf("\tPkts G: %" PRIu64 "\n",
- stats.n_pkts[RTE_MTR_GREEN]);
+ stats.n_pkts[RTE_COLOR_GREEN]);
if (stats_mask & RTE_MTR_STATS_N_BYTES_GREEN)
printf("\tBytes G: %" PRIu64 "\n",
- stats.n_bytes[RTE_MTR_GREEN]);
+ stats.n_bytes[RTE_COLOR_GREEN]);
if (stats_mask & RTE_MTR_STATS_N_PKTS_YELLOW)
printf("\tPkts Y: %" PRIu64 "\n",
- stats.n_pkts[RTE_MTR_YELLOW]);
+ stats.n_pkts[RTE_COLOR_YELLOW]);
if (stats_mask & RTE_MTR_STATS_N_BYTES_YELLOW)
printf("\tBytes Y: %" PRIu64 "\n",
- stats.n_bytes[RTE_MTR_YELLOW]);
+ stats.n_bytes[RTE_COLOR_YELLOW]);
if (stats_mask & RTE_MTR_STATS_N_PKTS_RED)
printf("\tPkts R: %" PRIu64 "\n",
- stats.n_pkts[RTE_MTR_RED]);
+ stats.n_pkts[RTE_COLOR_RED]);
if (stats_mask & RTE_MTR_STATS_N_BYTES_RED)
printf("\tBytes R: %" PRIu64 "\n",
- stats.n_bytes[RTE_MTR_RED]);
+ stats.n_bytes[RTE_COLOR_RED]);
if (stats_mask & RTE_MTR_STATS_N_PKTS_DROPPED)
printf("\tPkts DROPPED: %" PRIu64 "\n",
stats.n_pkts_dropped);
diff --git a/app/test-pmd/cmdline_tm.c b/app/test-pmd/cmdline_tm.c
index 4c763482a..753ea2c99 100644
--- a/app/test-pmd/cmdline_tm.c
+++ b/app/test-pmd/cmdline_tm.c
@@ -9,6 +9,7 @@
#include <rte_ethdev.h>
#include <rte_flow.h>
#include <rte_tm.h>
+#include <rte_color.h>
#include "testpmd.h"
#include "cmdline_tm.h"
@@ -296,7 +297,7 @@ static void cmd_show_port_tm_cap_parsed(void *parsed_result,
printf("cap.cman_wred_context_shared_n_contexts_per_node_max %" PRIu32
"\n", cap.cman_wred_context_shared_n_contexts_per_node_max);
- for (i = 0; i < RTE_TM_COLORS; i++) {
+ for (i = 0; i < RTE_COLORS; i++) {
printf("cap.mark_vlan_dei_supported %" PRId32 "\n",
cap.mark_vlan_dei_supported[i]);
printf("cap.mark_ip_ecn_tcp_supported %" PRId32 "\n",
@@ -642,22 +643,22 @@ static void cmd_show_port_tm_node_stats_parsed(void *parsed_result,
stats.n_bytes);
if (stats_mask & RTE_TM_STATS_N_PKTS_GREEN_DROPPED)
printf("\tPkts dropped (green): %" PRIu64 "\n",
- stats.leaf.n_pkts_dropped[RTE_TM_GREEN]);
+ stats.leaf.n_pkts_dropped[RTE_COLOR_GREEN]);
if (stats_mask & RTE_TM_STATS_N_PKTS_YELLOW_DROPPED)
printf("\tPkts dropped (yellow): %" PRIu64 "\n",
- stats.leaf.n_pkts_dropped[RTE_TM_YELLOW]);
+ stats.leaf.n_pkts_dropped[RTE_COLOR_YELLOW]);
if (stats_mask & RTE_TM_STATS_N_PKTS_RED_DROPPED)
printf("\tPkts dropped (red): %" PRIu64 "\n",
- stats.leaf.n_pkts_dropped[RTE_TM_RED]);
+ stats.leaf.n_pkts_dropped[RTE_COLOR_RED]);
if (stats_mask & RTE_TM_STATS_N_BYTES_GREEN_DROPPED)
printf("\tBytes dropped (green): %" PRIu64 "\n",
- stats.leaf.n_bytes_dropped[RTE_TM_GREEN]);
+ stats.leaf.n_bytes_dropped[RTE_COLOR_GREEN]);
if (stats_mask & RTE_TM_STATS_N_BYTES_YELLOW_DROPPED)
printf("\tBytes dropped (yellow): %" PRIu64 "\n",
- stats.leaf.n_bytes_dropped[RTE_TM_YELLOW]);
+ stats.leaf.n_bytes_dropped[RTE_COLOR_YELLOW]);
if (stats_mask & RTE_TM_STATS_N_BYTES_RED_DROPPED)
printf("\tBytes dropped (red): %" PRIu64 "\n",
- stats.leaf.n_bytes_dropped[RTE_TM_RED]);
+ stats.leaf.n_bytes_dropped[RTE_COLOR_RED]);
if (stats_mask & RTE_TM_STATS_N_PKTS_QUEUED)
printf("\tPkts queued: %" PRIu64 "\n",
stats.leaf.n_pkts_queued);
@@ -1267,7 +1268,7 @@ static void cmd_add_port_tm_node_wred_profile_parsed(void *parsed_result,
{
struct cmd_add_port_tm_node_wred_profile_result *res = parsed_result;
struct rte_tm_wred_params wp;
- enum rte_tm_color color;
+ enum rte_color color;
struct rte_tm_error error;
uint32_t wred_profile_id = res->wred_profile_id;
portid_t port_id = res->port_id;
@@ -1280,7 +1281,7 @@ static void cmd_add_port_tm_node_wred_profile_parsed(void *parsed_result,
memset(&error, 0, sizeof(struct rte_tm_error));
/* WRED Params (Green Color)*/
- color = RTE_TM_GREEN;
+ color = RTE_COLOR_GREEN;
wp.red_params[color].min_th = res->min_th_g;
wp.red_params[color].max_th = res->max_th_g;
wp.red_params[color].maxp_inv = res->maxp_inv_g;
@@ -1288,14 +1289,14 @@ static void cmd_add_port_tm_node_wred_profile_parsed(void *parsed_result,
/* WRED Params (Yellow Color)*/
- color = RTE_TM_YELLOW;
+ color = RTE_COLOR_YELLOW;
wp.red_params[color].min_th = res->min_th_y;
wp.red_params[color].max_th = res->max_th_y;
wp.red_params[color].maxp_inv = res->maxp_inv_y;
wp.red_params[color].wq_log2 = res->wq_log2_y;
/* WRED Params (Red Color)*/
- color = RTE_TM_RED;
+ color = RTE_COLOR_RED;
wp.red_params[color].min_th = res->min_th_r;
wp.red_params[color].max_th = res->max_th_r;
wp.red_params[color].maxp_inv = res->maxp_inv_r;
diff --git a/drivers/net/softnic/rte_eth_softnic_flow.c b/drivers/net/softnic/rte_eth_softnic_flow.c
index 21e753001..1a4322fef 100644
--- a/drivers/net/softnic/rte_eth_softnic_flow.c
+++ b/drivers/net/softnic/rte_eth_softnic_flow.c
@@ -12,6 +12,7 @@
#include <rte_flow.h>
#include <rte_flow_driver.h>
#include <rte_tailq.h>
+#include <rte_color.h>
#include "rte_eth_softnic_internals.h"
#include "rte_eth_softnic.h"
@@ -1624,11 +1625,14 @@ flow_rule_action_get(struct pmd_internals *softnic,
/* RTE_TABLE_ACTION_METER */
rule_action->mtr.mtr[0].meter_profile_id = meter_profile_id;
rule_action->mtr.mtr[0].policer[e_RTE_METER_GREEN] =
- softnic_table_action_policer(m->params.action[RTE_MTR_GREEN]);
+ softnic_table_action_policer
+ (m->params.action[RTE_COLOR_GREEN]);
rule_action->mtr.mtr[0].policer[e_RTE_METER_YELLOW] =
- softnic_table_action_policer(m->params.action[RTE_MTR_YELLOW]);
+ softnic_table_action_policer
+ (m->params.action[RTE_COLOR_YELLOW]);
rule_action->mtr.mtr[0].policer[e_RTE_METER_RED] =
- softnic_table_action_policer(m->params.action[RTE_MTR_RED]);
+ softnic_table_action_policer
+ (m->params.action[RTE_COLOR_RED]);
rule_action->mtr.tc_mask = 1;
rule_action->action_mask |= 1 << RTE_TABLE_ACTION_MTR;
break;
diff --git a/drivers/net/softnic/rte_eth_softnic_meter.c b/drivers/net/softnic/rte_eth_softnic_meter.c
index 7b747ba5d..3a0ec84b1 100644
--- a/drivers/net/softnic/rte_eth_softnic_meter.c
+++ b/drivers/net/softnic/rte_eth_softnic_meter.c
@@ -8,6 +8,7 @@
#include <rte_mtr.h>
#include <rte_mtr_driver.h>
+#include <rte_color.h>
#include "rte_eth_softnic_internals.h"
@@ -458,7 +459,7 @@ pmd_mtr_meter_profile_update(struct rte_eth_dev *dev,
static int
pmd_mtr_meter_dscp_table_update(struct rte_eth_dev *dev,
uint32_t mtr_id,
- enum rte_mtr_color *dscp_table,
+ enum rte_color *dscp_table,
struct rte_mtr_error *error)
{
struct pmd_internals *p = dev->data->dev_private;
@@ -536,7 +537,7 @@ pmd_mtr_policer_actions_update(struct rte_eth_dev *dev,
NULL,
"Invalid actions");
- for (i = 0; i < RTE_MTR_COLORS; i++) {
+ for (i = 0; i < RTE_COLORS; i++) {
if (action_mask & (1 << i)) {
if (actions[i] != MTR_POLICER_ACTION_COLOR_GREEN &&
actions[i] != MTR_POLICER_ACTION_COLOR_YELLOW &&
@@ -560,7 +561,7 @@ pmd_mtr_policer_actions_update(struct rte_eth_dev *dev,
memcpy(&action, &m->flow->action, sizeof(action));
/* Set action */
- for (i = 0; i < RTE_MTR_COLORS; i++)
+ for (i = 0; i < RTE_COLORS; i++)
if (action_mask & (1 << i))
action.mtr.mtr[0].policer[i] =
softnic_table_action_policer(actions[i]);
@@ -588,7 +589,7 @@ pmd_mtr_policer_actions_update(struct rte_eth_dev *dev,
}
/* Meter: Update policer actions */
- for (i = 0; i < RTE_MTR_COLORS; i++)
+ for (i = 0; i < RTE_COLORS; i++)
if (action_mask & (1 << i))
m->params.action[i] = actions[i];
@@ -618,15 +619,17 @@ mtr_stats_convert(struct softnic_mtr *m,
if (in->n_packets_valid) {
uint32_t i;
- for (i = 0; i < RTE_MTR_COLORS; i++) {
+ for (i = 0; i < RTE_COLORS; i++) {
if (m->params.action[i] == MTR_POLICER_ACTION_COLOR_GREEN)
- out->n_pkts[RTE_MTR_GREEN] += in->n_packets[i];
+ out->n_pkts[RTE_COLOR_GREEN] +=
+ in->n_packets[i];
if (m->params.action[i] == MTR_POLICER_ACTION_COLOR_YELLOW)
- out->n_pkts[RTE_MTR_YELLOW] += in->n_packets[i];
+ out->n_pkts[RTE_COLOR_YELLOW] +=
+ in->n_packets[i];
if (m->params.action[i] == MTR_POLICER_ACTION_COLOR_RED)
- out->n_pkts[RTE_MTR_RED] += in->n_packets[i];
+ out->n_pkts[RTE_COLOR_RED] += in->n_packets[i];
if (m->params.action[i] == MTR_POLICER_ACTION_DROP)
out->n_pkts_dropped += in->n_packets[i];
@@ -638,15 +641,16 @@ mtr_stats_convert(struct softnic_mtr *m,
if (in->n_bytes_valid) {
uint32_t i;
- for (i = 0; i < RTE_MTR_COLORS; i++) {
+ for (i = 0; i < RTE_COLORS; i++) {
if (m->params.action[i] == MTR_POLICER_ACTION_COLOR_GREEN)
- out->n_bytes[RTE_MTR_GREEN] += in->n_bytes[i];
+ out->n_bytes[RTE_COLOR_GREEN] += in->n_bytes[i];
if (m->params.action[i] == MTR_POLICER_ACTION_COLOR_YELLOW)
- out->n_bytes[RTE_MTR_YELLOW] += in->n_bytes[i];
+ out->n_bytes[RTE_COLOR_YELLOW] +=
+ in->n_bytes[i];
if (m->params.action[i] == MTR_POLICER_ACTION_COLOR_RED)
- out->n_bytes[RTE_MTR_RED] += in->n_bytes[i];
+ out->n_bytes[RTE_COLOR_RED] += in->n_bytes[i];
if (m->params.action[i] == MTR_POLICER_ACTION_DROP)
out->n_bytes_dropped += in->n_bytes[i];
diff --git a/drivers/net/softnic/rte_eth_softnic_tm.c b/drivers/net/softnic/rte_eth_softnic_tm.c
index baaafbe29..e1012ac3d 100644
--- a/drivers/net/softnic/rte_eth_softnic_tm.c
+++ b/drivers/net/softnic/rte_eth_softnic_tm.c
@@ -8,6 +8,7 @@
#include <rte_malloc.h>
#include <rte_string_fns.h>
+#include <rte_color.h>
#include "rte_eth_softnic_internals.h"
#include "rte_eth_softnic.h"
@@ -1204,7 +1205,7 @@ wred_profile_check(struct rte_eth_dev *dev,
struct rte_tm_error *error)
{
struct tm_wred_profile *wp;
- enum rte_tm_color color;
+ enum rte_color color;
/* WRED profile ID must not be NONE. */
if (wred_profile_id == RTE_TM_WRED_PROFILE_ID_NONE)
@@ -1240,7 +1241,7 @@ wred_profile_check(struct rte_eth_dev *dev,
rte_strerror(ENOTSUP));
/* min_th <= max_th, max_th > 0 */
- for (color = RTE_TM_GREEN; color < RTE_TM_COLORS; color++) {
+ for (color = RTE_COLOR_GREEN; color < RTE_COLORS; color++) {
uint32_t min_th = profile->red_params[color].min_th;
uint32_t max_th = profile->red_params[color].max_th;
@@ -2218,10 +2219,10 @@ wred_profiles_set(struct rte_eth_dev *dev)
struct pmd_internals *p = dev->data->dev_private;
struct rte_sched_port_params *pp = &p->soft.tm.params.port_params;
uint32_t tc_id;
- enum rte_tm_color color;
+ enum rte_color color;
for (tc_id = 0; tc_id < RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE; tc_id++)
- for (color = RTE_TM_GREEN; color < RTE_TM_COLORS; color++) {
+ for (color = RTE_COLOR_GREEN; color < RTE_COLORS; color++) {
struct rte_red_params *dst =
&pp->red_params[tc_id][color];
struct tm_wred_profile *src_wp =
@@ -3058,9 +3059,9 @@ read_port_stats(struct rte_eth_dev *dev,
s.n_pkts_tc[id] - s.n_pkts_tc_dropped[id];
nr->stats.n_bytes +=
s.n_bytes_tc[id] - s.n_bytes_tc_dropped[id];
- nr->stats.leaf.n_pkts_dropped[RTE_TM_GREEN] +=
+ nr->stats.leaf.n_pkts_dropped[RTE_COLOR_GREEN] +=
s.n_pkts_tc_dropped[id];
- nr->stats.leaf.n_bytes_dropped[RTE_TM_GREEN] +=
+ nr->stats.leaf.n_bytes_dropped[RTE_COLOR_GREEN] +=
s.n_bytes_tc_dropped[id];
}
}
@@ -3105,9 +3106,9 @@ read_subport_stats(struct rte_eth_dev *dev,
s.n_pkts_tc[tc_id] - s.n_pkts_tc_dropped[tc_id];
ns->stats.n_bytes +=
s.n_bytes_tc[tc_id] - s.n_bytes_tc_dropped[tc_id];
- ns->stats.leaf.n_pkts_dropped[RTE_TM_GREEN] +=
+ ns->stats.leaf.n_pkts_dropped[RTE_COLOR_GREEN] +=
s.n_pkts_tc_dropped[tc_id];
- ns->stats.leaf.n_bytes_dropped[RTE_TM_GREEN] +=
+ ns->stats.leaf.n_bytes_dropped[RTE_COLOR_GREEN] +=
s.n_bytes_tc_dropped[tc_id];
}
@@ -3162,8 +3163,9 @@ read_pipe_stats(struct rte_eth_dev *dev,
/* Stats accumulate */
np->stats.n_pkts += s.n_pkts - s.n_pkts_dropped;
np->stats.n_bytes += s.n_bytes - s.n_bytes_dropped;
- np->stats.leaf.n_pkts_dropped[RTE_TM_GREEN] += s.n_pkts_dropped;
- np->stats.leaf.n_bytes_dropped[RTE_TM_GREEN] +=
+ np->stats.leaf.n_pkts_dropped[RTE_COLOR_GREEN] +=
+ s.n_pkts_dropped;
+ np->stats.leaf.n_bytes_dropped[RTE_COLOR_GREEN] +=
s.n_bytes_dropped;
np->stats.leaf.n_pkts_queued = qlen;
}
@@ -3222,8 +3224,9 @@ read_tc_stats(struct rte_eth_dev *dev,
/* Stats accumulate */
nt->stats.n_pkts += s.n_pkts - s.n_pkts_dropped;
nt->stats.n_bytes += s.n_bytes - s.n_bytes_dropped;
- nt->stats.leaf.n_pkts_dropped[RTE_TM_GREEN] += s.n_pkts_dropped;
- nt->stats.leaf.n_bytes_dropped[RTE_TM_GREEN] +=
+ nt->stats.leaf.n_pkts_dropped[RTE_COLOR_GREEN] +=
+ s.n_pkts_dropped;
+ nt->stats.leaf.n_bytes_dropped[RTE_COLOR_GREEN] +=
s.n_bytes_dropped;
nt->stats.leaf.n_pkts_queued = qlen;
}
@@ -3281,8 +3284,8 @@ read_queue_stats(struct rte_eth_dev *dev,
/* Stats accumulate */
nq->stats.n_pkts += s.n_pkts - s.n_pkts_dropped;
nq->stats.n_bytes += s.n_bytes - s.n_bytes_dropped;
- nq->stats.leaf.n_pkts_dropped[RTE_TM_GREEN] += s.n_pkts_dropped;
- nq->stats.leaf.n_bytes_dropped[RTE_TM_GREEN] +=
+ nq->stats.leaf.n_pkts_dropped[RTE_COLOR_GREEN] += s.n_pkts_dropped;
+ nq->stats.leaf.n_bytes_dropped[RTE_COLOR_GREEN] +=
s.n_bytes_dropped;
nq->stats.leaf.n_pkts_queued = qlen;
diff --git a/lib/librte_eal/common/Makefile b/lib/librte_eal/common/Makefile
index 87d8c455d..c76bb2dd7 100644
--- a/lib/librte_eal/common/Makefile
+++ b/lib/librte_eal/common/Makefile
@@ -17,7 +17,7 @@ INC += rte_pci_dev_feature_defs.h rte_pci_dev_features.h
INC += rte_malloc.h rte_keepalive.h rte_time.h
INC += rte_service.h rte_service_component.h
INC += rte_bitmap.h rte_vfio.h rte_hypervisor.h rte_test.h
-INC += rte_reciprocal.h rte_fbarray.h rte_uuid.h
+INC += rte_reciprocal.h rte_fbarray.h rte_uuid.h rte_color.h
GENERIC_INC := rte_atomic.h rte_byteorder.h rte_cycles.h rte_prefetch.h
GENERIC_INC += rte_spinlock.h rte_memcpy.h rte_cpuflags.h rte_rwlock.h
diff --git a/lib/librte_eal/common/include/rte_color.h b/lib/librte_eal/common/include/rte_color.h
new file mode 100644
index 000000000..f4387071b
--- /dev/null
+++ b/lib/librte_eal/common/include/rte_color.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2018 Intel Corporation
+ */
+
+#ifndef _RTE_COLOR_H_
+#define _RTE_COLOR_H_
+
+/**
+ * Color
+ */
+enum rte_color {
+ RTE_COLOR_GREEN = 0, /**< Green */
+ RTE_COLOR_YELLOW, /**< Yellow */
+ RTE_COLOR_RED, /**< Red */
+ RTE_COLORS /**< Number of colors */
+};
+
+#endif /* _RTE_COLOR_H_ */
diff --git a/lib/librte_ethdev/rte_mtr.c b/lib/librte_ethdev/rte_mtr.c
index 1046cb5fd..12b815406 100644
--- a/lib/librte_ethdev/rte_mtr.c
+++ b/lib/librte_ethdev/rte_mtr.c
@@ -153,7 +153,7 @@ rte_mtr_meter_profile_update(uint16_t port_id,
int __rte_experimental
rte_mtr_meter_dscp_table_update(uint16_t port_id,
uint32_t mtr_id,
- enum rte_mtr_color *dscp_table,
+ enum rte_color *dscp_table,
struct rte_mtr_error *error)
{
struct rte_eth_dev *dev = &rte_eth_devices[port_id];
diff --git a/lib/librte_ethdev/rte_mtr.h b/lib/librte_ethdev/rte_mtr.h
index c4819b274..113db06a9 100644
--- a/lib/librte_ethdev/rte_mtr.h
+++ b/lib/librte_ethdev/rte_mtr.h
@@ -76,21 +76,12 @@
#include <stdint.h>
#include <rte_compat.h>
#include <rte_common.h>
+#include <rte_color.h>
#ifdef __cplusplus
extern "C" {
#endif
-/**
- * Color
- */
-enum rte_mtr_color {
- RTE_MTR_GREEN = 0, /**< Green */
- RTE_MTR_YELLOW, /**< Yellow */
- RTE_MTR_RED, /**< Red */
- RTE_MTR_COLORS /**< Number of colors. */
-};
-
/**
* Statistics counter type
*/
@@ -125,10 +116,10 @@ enum rte_mtr_stats_type {
*/
struct rte_mtr_stats {
/** Number of packets passed by the policer (per color). */
- uint64_t n_pkts[RTE_MTR_COLORS];
+ uint64_t n_pkts[RTE_COLORS];
/** Number of bytes passed by the policer (per color). */
- uint64_t n_bytes[RTE_MTR_COLORS];
+ uint64_t n_bytes[RTE_COLORS];
/** Number of packets dropped by the policer. */
uint64_t n_pkts_dropped;
@@ -260,7 +251,7 @@ struct rte_mtr_params {
* at least one yellow or red color element, then the color aware mode
* is configured.
*/
- enum rte_mtr_color *dscp_table;
+ enum rte_color *dscp_table;
/** Non-zero to enable the meter, zero to disable the meter at the time
* of MTR object creation. Ignored when the meter profile indicated by
@@ -270,7 +261,7 @@ struct rte_mtr_params {
int meter_enable;
/** Policer actions (per meter output color). */
- enum rte_mtr_policer_action action[RTE_MTR_COLORS];
+ enum rte_mtr_policer_action action[RTE_COLORS];
/** Set of stats counters to be enabled.
* @see enum rte_mtr_stats_type
@@ -636,7 +627,7 @@ rte_mtr_meter_profile_update(uint16_t port_id,
int __rte_experimental
rte_mtr_meter_dscp_table_update(uint16_t port_id,
uint32_t mtr_id,
- enum rte_mtr_color *dscp_table,
+ enum rte_color *dscp_table,
struct rte_mtr_error *error);
/**
diff --git a/lib/librte_ethdev/rte_mtr_driver.h b/lib/librte_ethdev/rte_mtr_driver.h
index c9a6d7c38..3ec7ffa2a 100644
--- a/lib/librte_ethdev/rte_mtr_driver.h
+++ b/lib/librte_ethdev/rte_mtr_driver.h
@@ -70,7 +70,7 @@ typedef int (*rte_mtr_meter_profile_update_t)(struct rte_eth_dev *dev,
typedef int (*rte_mtr_meter_dscp_table_update_t)(struct rte_eth_dev *dev,
uint32_t mtr_id,
- enum rte_mtr_color *dscp_table,
+ enum rte_color *dscp_table,
struct rte_mtr_error *error);
/**< @internal MTR object meter DSCP table update */
diff --git a/lib/librte_ethdev/rte_tm.h b/lib/librte_ethdev/rte_tm.h
index 646ef3880..95f322313 100644
--- a/lib/librte_ethdev/rte_tm.h
+++ b/lib/librte_ethdev/rte_tm.h
@@ -51,6 +51,7 @@
#include <stdint.h>
#include <rte_common.h>
+#include <rte_color.h>
#ifdef __cplusplus
extern "C" {
@@ -115,16 +116,6 @@ extern "C" {
*/
#define RTE_TM_NODE_LEVEL_ID_ANY UINT32_MAX
-/**
- * Color
- */
-enum rte_tm_color {
- RTE_TM_GREEN = 0, /**< Green */
- RTE_TM_YELLOW, /**< Yellow */
- RTE_TM_RED, /**< Red */
- RTE_TM_COLORS /**< Number of colors */
-};
-
/**
* Node statistics counter type
*/
@@ -179,12 +170,12 @@ struct rte_tm_node_stats {
/** Number of packets dropped by current leaf node per each
* color.
*/
- uint64_t n_pkts_dropped[RTE_TM_COLORS];
+ uint64_t n_pkts_dropped[RTE_COLORS];
/** Number of bytes dropped by current leaf node per each
* color.
*/
- uint64_t n_bytes_dropped[RTE_TM_COLORS];
+ uint64_t n_bytes_dropped[RTE_COLORS];
/** Number of packets currently waiting in the packet queue of
* current leaf node.
@@ -435,16 +426,16 @@ struct rte_tm_capabilities {
uint32_t cman_wred_context_shared_n_contexts_per_node_max;
/** Support for VLAN DEI packet marking (per color). */
- int mark_vlan_dei_supported[RTE_TM_COLORS];
+ int mark_vlan_dei_supported[RTE_COLORS];
/** Support for IPv4/IPv6 ECN marking of TCP packets (per color). */
- int mark_ip_ecn_tcp_supported[RTE_TM_COLORS];
+ int mark_ip_ecn_tcp_supported[RTE_COLORS];
/** Support for IPv4/IPv6 ECN marking of SCTP packets (per color). */
- int mark_ip_ecn_sctp_supported[RTE_TM_COLORS];
+ int mark_ip_ecn_sctp_supported[RTE_COLORS];
/** Support for IPv4/IPv6 DSCP packet marking (per color). */
- int mark_ip_dscp_supported[RTE_TM_COLORS];
+ int mark_ip_dscp_supported[RTE_COLORS];
/** Set of supported dynamic update operations.
* @see enum rte_tm_dynamic_update_type
@@ -861,7 +852,7 @@ struct rte_tm_red_params {
*/
struct rte_tm_wred_params {
/** One set of RED parameters per packet color */
- struct rte_tm_red_params red_params[RTE_TM_COLORS];
+ struct rte_tm_red_params red_params[RTE_COLORS];
/** When non-zero, the *min_th* and *max_th* thresholds are specified
* in packets (WRED packet mode). When zero, the *min_th* and *max_th*
diff --git a/lib/librte_meter/rte_meter.h b/lib/librte_meter/rte_meter.h
index 58a051583..e6187c49d 100644
--- a/lib/librte_meter/rte_meter.h
+++ b/lib/librte_meter/rte_meter.h
@@ -21,6 +21,7 @@ extern "C" {
#include <stdint.h>
+#include <rte_color.h>
/*
* Application Programmer's Interface (API)
*
@@ -34,6 +35,12 @@ enum rte_meter_color {
e_RTE_METER_COLORS /**< Number of available colors */
};
+/* New rte_color is defined and used to deprecate rte_meter_color soon. */
+#define rte_meter_color rte_color
+#define e_RTE_METER_GREEN RTE_COLOR_GREEN
+#define e_RTE_METER_YELLOW RTE_COLOR_YELLOW
+#define e_RTE_METER_RED RTE_COLOR_RED
+
/** srTCM parameters per metered traffic flow. The CIR, CBS and EBS parameters only
count bytes of IP packets and do not include link specific headers. At least one of
the CBS or EBS parameters has to be greater than zero. */
--
2.17.1
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
2018-12-07 14:31 ` [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition Reshma Pattan
@ 2018-12-10 18:24 ` Dumitrescu, Cristian
2018-12-14 23:35 ` Ananyev, Konstantin
1 sibling, 0 replies; 74+ messages in thread
From: Dumitrescu, Cristian @ 2018-12-10 18:24 UTC (permalink / raw)
To: Pattan, Reshma, dev, jerin.jacob, Singh, Jasvinder
Hi Reshma,
> -----Original Message-----
> From: Pattan, Reshma
> Sent: Friday, December 7, 2018 2:32 PM
> To: dev@dpdk.org; Dumitrescu, Cristian <cristian.dumitrescu@intel.com>;
> jerin.jacob@caviumnetworks.com; Singh, Jasvinder
> <jasvinder.singh@intel.com>
> Cc: Pattan, Reshma <reshma.pattan@intel.com>
> Subject: [PATCH v2 2/3] eal: add new rte color definition
>
> Added new rte_color definition in eal to
> consolidate color definition which is currently replicated
> in various places such as rte_meter.h, rte_tm.h and rte_mtr.h
>
> Removed rte_tm_color and rte_mtr_color and used the new color
> definition in rte_tm* and rte_mtr* files.
>
> Updated softnic and testpmd to use new color definition.
>
> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
> Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> ---
> app/test-pmd/cmdline_mtr.c | 47 +++++++++++----------
> app/test-pmd/cmdline_tm.c | 23 +++++-----
> drivers/net/softnic/rte_eth_softnic_flow.c | 10 +++--
> drivers/net/softnic/rte_eth_softnic_meter.c | 28 ++++++------
> drivers/net/softnic/rte_eth_softnic_tm.c | 31 ++++++++------
> lib/librte_eal/common/Makefile | 2 +-
> lib/librte_eal/common/include/rte_color.h | 18 ++++++++
> lib/librte_ethdev/rte_mtr.c | 2 +-
> lib/librte_ethdev/rte_mtr.h | 21 +++------
> lib/librte_ethdev/rte_mtr_driver.h | 2 +-
> lib/librte_ethdev/rte_tm.h | 25 ++++-------
> lib/librte_meter/rte_meter.h | 7 +++
> 12 files changed, 118 insertions(+), 98 deletions(-)
> create mode 100644 lib/librte_eal/common/include/rte_color.h
>
This patch should come first in the set, i.e. before the redefinition of the sched field in struct rte_mbuf, as it defines the format for the new sched color field.
At this point, we should not remove the usage of rte_meter_color, rte_mtr_color, rte_mtr_color in any of the files using them, as this will break people's apps. We should first deprecate them by adding a deprecation note in the current release and then in one of the next releases (hopefully 19.5) remove them completely by replacing with the new rte_color, as you do in this patch. So, for now, please do not do this replacement in any of the above files. Bottom line: remove (for now) the above changes in the .c files of test-pmd, softnic, librte_ethdev; keep the above changes in the .h files such as rte_meter.h, rte_tm.h, rte_mtr.h. Makes sense? This patch should be very small :)
<snip>
> diff --git a/lib/librte_eal/common/include/rte_color.h
> b/lib/librte_eal/common/include/rte_color.h
> new file mode 100644
> index 000000000..f4387071b
> --- /dev/null
> +++ b/lib/librte_eal/common/include/rte_color.h
> @@ -0,0 +1,18 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(c) 2018 Intel Corporation
> + */
> +
> +#ifndef _RTE_COLOR_H_
> +#define _RTE_COLOR_H_
> +
> +/**
> + * Color
> + */
> +enum rte_color {
> + RTE_COLOR_GREEN = 0, /**< Green */
> + RTE_COLOR_YELLOW, /**< Yellow */
> + RTE_COLOR_RED, /**< Red */
> + RTE_COLORS /**< Number of colors */
> +};
> +
> +#endif /* _RTE_COLOR_H_ */
Please add the C++ pattern at the beginning and end of this file:
#ifndef __INCLUDE_RTE_COLOR__
#define __INCLUDE_RTE_COLOR__
#ifdef __cplusplus
extern "C" {
#endif
#ifdef __cplusplus
}
#endif
#endif
<snip>
> diff --git a/lib/librte_ethdev/rte_mtr.h b/lib/librte_ethdev/rte_mtr.h
> index c4819b274..113db06a9 100644
> --- a/lib/librte_ethdev/rte_mtr.h
> +++ b/lib/librte_ethdev/rte_mtr.h
> @@ -76,21 +76,12 @@
> #include <stdint.h>
> #include <rte_compat.h>
> #include <rte_common.h>
> +#include <rte_color.h>
>
> #ifdef __cplusplus
> extern "C" {
> #endif
>
> -/**
> - * Color
> - */
> -enum rte_mtr_color {
> - RTE_MTR_GREEN = 0, /**< Green */
> - RTE_MTR_YELLOW, /**< Yellow */
> - RTE_MTR_RED, /**< Red */
> - RTE_MTR_COLORS /**< Number of colors. */
> -};
> -
We should not use rte_color yet, we should simply create alias of current rte_mtr_color enum and values to the new rte_color enum and enum values, just like you do it below for rte_meter.h. So please remove the rest of the changes for now.
<snip>
> diff --git a/lib/librte_ethdev/rte_tm.h b/lib/librte_ethdev/rte_tm.h
> index 646ef3880..95f322313 100644
> --- a/lib/librte_ethdev/rte_tm.h
> +++ b/lib/librte_ethdev/rte_tm.h
> @@ -51,6 +51,7 @@
> #include <stdint.h>
>
> #include <rte_common.h>
> +#include <rte_color.h>
>
> #ifdef __cplusplus
> extern "C" {
> @@ -115,16 +116,6 @@ extern "C" {
> */
> #define RTE_TM_NODE_LEVEL_ID_ANY UINT32_MAX
>
> -/**
> - * Color
> - */
> -enum rte_tm_color {
> - RTE_TM_GREEN = 0, /**< Green */
> - RTE_TM_YELLOW, /**< Yellow */
> - RTE_TM_RED, /**< Red */
> - RTE_TM_COLORS /**< Number of colors */
> -};
> -
We should not use rte_color yet, we should simply create alias of current rte_tm_color enum and values to the new rte_color enum and enum values, just like you do it below for rte_meter.h. So please remove the rest of the changes for now.
<snip>
> diff --git a/lib/librte_meter/rte_meter.h b/lib/librte_meter/rte_meter.h
> index 58a051583..e6187c49d 100644
> --- a/lib/librte_meter/rte_meter.h
> +++ b/lib/librte_meter/rte_meter.h
> @@ -21,6 +21,7 @@ extern "C" {
>
> #include <stdint.h>
>
> +#include <rte_color.h>
> /*
> * Application Programmer's Interface (API)
> *
> @@ -34,6 +35,12 @@ enum rte_meter_color {
> e_RTE_METER_COLORS /**< Number of available colors */
> };
>
> +/* New rte_color is defined and used to deprecate rte_meter_color soon.
> */
> +#define rte_meter_color rte_color
> +#define e_RTE_METER_GREEN RTE_COLOR_GREEN
> +#define e_RTE_METER_YELLOW RTE_COLOR_YELLOW
> +#define e_RTE_METER_RED RTE_COLOR_RED
> +
> /** srTCM parameters per metered traffic flow. The CIR, CBS and EBS
> parameters only
> count bytes of IP packets and do not include link specific headers. At least
> one of
> the CBS or EBS parameters has to be greater than zero. */
> --
> 2.17.1
The changes for rte_meter.h are perfect, please do the same to rte_mtr.h and rte_tm.h.
Regards,
Cristian
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
2018-12-07 14:31 ` [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition Reshma Pattan
2018-12-10 18:24 ` Dumitrescu, Cristian
@ 2018-12-14 23:35 ` Ananyev, Konstantin
2018-12-15 0:16 ` Dumitrescu, Cristian
2018-12-15 14:15 ` Mattias Rönnblom
1 sibling, 2 replies; 74+ messages in thread
From: Ananyev, Konstantin @ 2018-12-14 23:35 UTC (permalink / raw)
To: Pattan, Reshma, dev, Dumitrescu, Cristian, jerin.jacob, Singh, Jasvinder
Cc: Pattan, Reshma
Hi Reshma,
> diff --git a/lib/librte_eal/common/include/rte_color.h b/lib/librte_eal/common/include/rte_color.h
> new file mode 100644
> index 000000000..f4387071b
> --- /dev/null
> +++ b/lib/librte_eal/common/include/rte_color.h
> @@ -0,0 +1,18 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(c) 2018 Intel Corporation
> + */
> +
> +#ifndef _RTE_COLOR_H_
> +#define _RTE_COLOR_H_
> +
> +/**
> + * Color
> + */
> +enum rte_color {
> + RTE_COLOR_GREEN = 0, /**< Green */
> + RTE_COLOR_YELLOW, /**< Yellow */
> + RTE_COLOR_RED, /**< Red */
> + RTE_COLORS /**< Number of colors */
> +};
Does it really belong to EAL?
Konstantin
> +
> +#endif /* _RTE_COLOR_H_ */
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
2018-12-14 23:35 ` Ananyev, Konstantin
@ 2018-12-15 0:16 ` Dumitrescu, Cristian
2018-12-17 11:21 ` Ananyev, Konstantin
2018-12-15 14:15 ` Mattias Rönnblom
1 sibling, 1 reply; 74+ messages in thread
From: Dumitrescu, Cristian @ 2018-12-15 0:16 UTC (permalink / raw)
To: Ananyev, Konstantin, Pattan, Reshma, dev, jerin.jacob, Singh, Jasvinder
Cc: Pattan, Reshma
> -----Original Message-----
> From: Ananyev, Konstantin
> Sent: Friday, December 14, 2018 11:36 PM
> To: Pattan, Reshma <reshma.pattan@intel.com>; dev@dpdk.org;
> Dumitrescu, Cristian <cristian.dumitrescu@intel.com>;
> jerin.jacob@caviumnetworks.com; Singh, Jasvinder
> <jasvinder.singh@intel.com>
> Cc: Pattan, Reshma <reshma.pattan@intel.com>
> Subject: RE: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
>
> Hi Reshma,
>
> > diff --git a/lib/librte_eal/common/include/rte_color.h
> b/lib/librte_eal/common/include/rte_color.h
> > new file mode 100644
> > index 000000000..f4387071b
> > --- /dev/null
> > +++ b/lib/librte_eal/common/include/rte_color.h
> > @@ -0,0 +1,18 @@
> > +/* SPDX-License-Identifier: BSD-3-Clause
> > + * Copyright(c) 2018 Intel Corporation
> > + */
> > +
> > +#ifndef _RTE_COLOR_H_
> > +#define _RTE_COLOR_H_
> > +
> > +/**
> > + * Color
> > + */
> > +enum rte_color {
> > + RTE_COLOR_GREEN = 0, /**< Green */
> > + RTE_COLOR_YELLOW, /**< Yellow */
> > + RTE_COLOR_RED, /**< Red */
> > + RTE_COLORS /**< Number of colors */
> > +};
>
> Does it really belong to EAL?
> Konstantin
>
Why not?
It needs to be visible to multiple libraries: ethdev, meter, sched, as well as drivers. We'd like to avoid adding more complexity to dependencies between libraries.
It is very generic. EAL common/include is currently the place to put generic data structures, functions, algs, etc that are widely used by DPDK libraries. Lots of similar examples are easy to find in this folder.
Where else would you put it?
> > +
> > +#endif /* _RTE_COLOR_H_ */
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
2018-12-15 0:16 ` Dumitrescu, Cristian
@ 2018-12-17 11:21 ` Ananyev, Konstantin
2018-12-17 17:15 ` Pattan, Reshma
0 siblings, 1 reply; 74+ messages in thread
From: Ananyev, Konstantin @ 2018-12-17 11:21 UTC (permalink / raw)
To: Dumitrescu, Cristian, Pattan, Reshma, dev, jerin.jacob, Singh, Jasvinder
Cc: Pattan, Reshma
> -----Original Message-----
> From: Dumitrescu, Cristian
> Sent: Saturday, December 15, 2018 12:16 AM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>; Pattan, Reshma <reshma.pattan@intel.com>; dev@dpdk.org;
> jerin.jacob@caviumnetworks.com; Singh, Jasvinder <jasvinder.singh@intel.com>
> Cc: Pattan, Reshma <reshma.pattan@intel.com>
> Subject: RE: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
>
>
>
> > -----Original Message-----
> > From: Ananyev, Konstantin
> > Sent: Friday, December 14, 2018 11:36 PM
> > To: Pattan, Reshma <reshma.pattan@intel.com>; dev@dpdk.org;
> > Dumitrescu, Cristian <cristian.dumitrescu@intel.com>;
> > jerin.jacob@caviumnetworks.com; Singh, Jasvinder
> > <jasvinder.singh@intel.com>
> > Cc: Pattan, Reshma <reshma.pattan@intel.com>
> > Subject: RE: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
> >
> > Hi Reshma,
> >
> > > diff --git a/lib/librte_eal/common/include/rte_color.h
> > b/lib/librte_eal/common/include/rte_color.h
> > > new file mode 100644
> > > index 000000000..f4387071b
> > > --- /dev/null
> > > +++ b/lib/librte_eal/common/include/rte_color.h
> > > @@ -0,0 +1,18 @@
> > > +/* SPDX-License-Identifier: BSD-3-Clause
> > > + * Copyright(c) 2018 Intel Corporation
> > > + */
> > > +
> > > +#ifndef _RTE_COLOR_H_
> > > +#define _RTE_COLOR_H_
> > > +
> > > +/**
> > > + * Color
> > > + */
> > > +enum rte_color {
> > > + RTE_COLOR_GREEN = 0, /**< Green */
> > > + RTE_COLOR_YELLOW, /**< Yellow */
> > > + RTE_COLOR_RED, /**< Red */
> > > + RTE_COLORS /**< Number of colors */
> > > +};
> >
> > Does it really belong to EAL?
> > Konstantin
> >
>
> Why not?
>
> It needs to be visible to multiple libraries: ethdev, meter, sched, as well as drivers. We'd like to avoid adding more complexity to
> dependencies between libraries.
>
> It is very generic. EAL common/include is currently the place to put generic data structures, functions, algs, etc that are widely used by
> DPDK libraries. Lots of similar examples are easy to find in this folder.
I don't think it is *that* generic to be in EAL.
Yes it is used by few libs, ethdev and by softnic PMD,
but it doesn't look as core dpdk thing to me.
>
> Where else would you put it?
If it defines format of rte_mbuf fileds,
then probably new .h inside librte_mbuf is a good place.
Other alternatives would be rte_ethdev or rte_net.
Konstantin
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
2018-12-17 11:21 ` Ananyev, Konstantin
@ 2018-12-17 17:15 ` Pattan, Reshma
2018-12-17 18:51 ` Dumitrescu, Cristian
0 siblings, 1 reply; 74+ messages in thread
From: Pattan, Reshma @ 2018-12-17 17:15 UTC (permalink / raw)
To: Ananyev, Konstantin, Dumitrescu, Cristian, dev, jerin.jacob,
Singh, Jasvinder
> -----Original Message-----
> From: Ananyev, Konstantin
> Sent: Monday, December 17, 2018 11:21 AM
> To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Pattan, Reshma
> <reshma.pattan@intel.com>; dev@dpdk.org;
> jerin.jacob@caviumnetworks.com; Singh, Jasvinder
> <jasvinder.singh@intel.com>
> Cc: Pattan, Reshma <reshma.pattan@intel.com>
> Subject: RE: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
>
>
>
> > -----Original Message-----
> > From: Dumitrescu, Cristian
> > Sent: Saturday, December 15, 2018 12:16 AM
> > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>; Pattan, Reshma
> > <reshma.pattan@intel.com>; dev@dpdk.org;
> > jerin.jacob@caviumnetworks.com; Singh, Jasvinder
> > <jasvinder.singh@intel.com>
> > Cc: Pattan, Reshma <reshma.pattan@intel.com>
> > Subject: RE: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color
> > definition
> >
> >
> >
> > > -----Original Message-----
> > > From: Ananyev, Konstantin
> > > Sent: Friday, December 14, 2018 11:36 PM
> > > To: Pattan, Reshma <reshma.pattan@intel.com>; dev@dpdk.org;
> > > Dumitrescu, Cristian <cristian.dumitrescu@intel.com>;
> > > jerin.jacob@caviumnetworks.com; Singh, Jasvinder
> > > <jasvinder.singh@intel.com>
> > > Cc: Pattan, Reshma <reshma.pattan@intel.com>
> > > Subject: RE: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color
> > > definition
> > >
> > > Hi Reshma,
> > >
> > > > diff --git a/lib/librte_eal/common/include/rte_color.h
> > > b/lib/librte_eal/common/include/rte_color.h
> > > > new file mode 100644
> > > > index 000000000..f4387071b
> > > > --- /dev/null
> > > > +++ b/lib/librte_eal/common/include/rte_color.h
> > > > @@ -0,0 +1,18 @@
> > > > +/* SPDX-License-Identifier: BSD-3-Clause
> > > > + * Copyright(c) 2018 Intel Corporation */
> > > > +
> > > > +#ifndef _RTE_COLOR_H_
> > > > +#define _RTE_COLOR_H_
> > > > +
> > > > +/**
> > > > + * Color
> > > > + */
> > > > +enum rte_color {
> > > > + RTE_COLOR_GREEN = 0, /**< Green */
> > > > + RTE_COLOR_YELLOW, /**< Yellow */
> > > > + RTE_COLOR_RED, /**< Red */
> > > > + RTE_COLORS /**< Number of colors */ };
> > >
> > > Does it really belong to EAL?
> > > Konstantin
> > >
> >
> > Why not?
> >
> > It needs to be visible to multiple libraries: ethdev, meter, sched, as
> > well as drivers. We'd like to avoid adding more complexity to dependencies
> between libraries.
> >
> > It is very generic. EAL common/include is currently the place to put
> > generic data structures, functions, algs, etc that are widely used by DPDK
> libraries. Lots of similar examples are easy to find in this folder.
>
> I don't think it is *that* generic to be in EAL.
> Yes it is used by few libs, ethdev and by softnic PMD,
> but it doesn't look as core dpdk thing to me.
>
> >
> > Where else would you put it?
>
> If it defines format of rte_mbuf fileds, then probably new .h inside librte_mbuf is
> a good place.
> Other alternatives would be rte_ethdev or rte_net.
After going through the lib/Makefile dependencies, I see we can have rte_color.h in eal or mbuf library only.
Cannot keep it inside ethdev or net libraries because these two libraries already have dependency on mbuf library, so cannot create loop dependency.
Snippet
1) DEPDIRS-librte_eal := librte_kvargs
2)DEPDIRS-librte_mbuf := librte_eal librte_mempool
3)DEPDIRS-librte_ethdev := librte_net librte_eal librte_mempool librte_ring
DEPDIRS-librte_ethdev += librte_mbuf
DEPDIRS-librte_ethdev += librte_kvargs
DEPDIRS-librte_ethdev += librte_cmdline
4) DEPDIRS-librte_net := librte_mbuf librte_eal
5) DEPDIRS-librte_meter := librte_eal
Thanks,
Reshma
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
2018-12-17 17:15 ` Pattan, Reshma
@ 2018-12-17 18:51 ` Dumitrescu, Cristian
2018-12-17 23:11 ` Thomas Monjalon
2018-12-18 10:15 ` Ananyev, Konstantin
0 siblings, 2 replies; 74+ messages in thread
From: Dumitrescu, Cristian @ 2018-12-17 18:51 UTC (permalink / raw)
To: Pattan, Reshma, Ananyev, Konstantin, dev, jerin.jacob, Singh, Jasvinder
> -----Original Message-----
> From: Pattan, Reshma
> Sent: Monday, December 17, 2018 5:15 PM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>; Dumitrescu,
> Cristian <cristian.dumitrescu@intel.com>; dev@dpdk.org;
> jerin.jacob@caviumnetworks.com; Singh, Jasvinder
> <jasvinder.singh@intel.com>
> Subject: RE: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
>
>
>
> > -----Original Message-----
> > From: Ananyev, Konstantin
> > Sent: Monday, December 17, 2018 11:21 AM
> > To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Pattan, Reshma
> > <reshma.pattan@intel.com>; dev@dpdk.org;
> > jerin.jacob@caviumnetworks.com; Singh, Jasvinder
> > <jasvinder.singh@intel.com>
> > Cc: Pattan, Reshma <reshma.pattan@intel.com>
> > Subject: RE: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
> >
> >
> >
> > > -----Original Message-----
> > > From: Dumitrescu, Cristian
> > > Sent: Saturday, December 15, 2018 12:16 AM
> > > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>; Pattan,
> Reshma
> > > <reshma.pattan@intel.com>; dev@dpdk.org;
> > > jerin.jacob@caviumnetworks.com; Singh, Jasvinder
> > > <jasvinder.singh@intel.com>
> > > Cc: Pattan, Reshma <reshma.pattan@intel.com>
> > > Subject: RE: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color
> > > definition
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Ananyev, Konstantin
> > > > Sent: Friday, December 14, 2018 11:36 PM
> > > > To: Pattan, Reshma <reshma.pattan@intel.com>; dev@dpdk.org;
> > > > Dumitrescu, Cristian <cristian.dumitrescu@intel.com>;
> > > > jerin.jacob@caviumnetworks.com; Singh, Jasvinder
> > > > <jasvinder.singh@intel.com>
> > > > Cc: Pattan, Reshma <reshma.pattan@intel.com>
> > > > Subject: RE: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color
> > > > definition
> > > >
> > > > Hi Reshma,
> > > >
> > > > > diff --git a/lib/librte_eal/common/include/rte_color.h
> > > > b/lib/librte_eal/common/include/rte_color.h
> > > > > new file mode 100644
> > > > > index 000000000..f4387071b
> > > > > --- /dev/null
> > > > > +++ b/lib/librte_eal/common/include/rte_color.h
> > > > > @@ -0,0 +1,18 @@
> > > > > +/* SPDX-License-Identifier: BSD-3-Clause
> > > > > + * Copyright(c) 2018 Intel Corporation */
> > > > > +
> > > > > +#ifndef _RTE_COLOR_H_
> > > > > +#define _RTE_COLOR_H_
> > > > > +
> > > > > +/**
> > > > > + * Color
> > > > > + */
> > > > > +enum rte_color {
> > > > > + RTE_COLOR_GREEN = 0, /**< Green */
> > > > > + RTE_COLOR_YELLOW, /**< Yellow */
> > > > > + RTE_COLOR_RED, /**< Red */
> > > > > + RTE_COLORS /**< Number of colors */ };
> > > >
> > > > Does it really belong to EAL?
> > > > Konstantin
> > > >
> > >
> > > Why not?
> > >
> > > It needs to be visible to multiple libraries: ethdev, meter, sched, as
> > > well as drivers. We'd like to avoid adding more complexity to
> dependencies
> > between libraries.
> > >
> > > It is very generic. EAL common/include is currently the place to put
> > > generic data structures, functions, algs, etc that are widely used by DPDK
> > libraries. Lots of similar examples are easy to find in this folder.
> >
> > I don't think it is *that* generic to be in EAL.
> > Yes it is used by few libs, ethdev and by softnic PMD,
> > but it doesn't look as core dpdk thing to me.
> >
> > >
> > > Where else would you put it?
> >
> > If it defines format of rte_mbuf fileds, then probably new .h inside
> librte_mbuf is
> > a good place.
> > Other alternatives would be rte_ethdev or rte_net.
>
> After going through the lib/Makefile dependencies, I see we can have
> rte_color.h in eal or mbuf library only.
> Cannot keep it inside ethdev or net libraries because these two libraries
> already have dependency on mbuf library, so cannot create loop
> dependency.
>
> Snippet
>
> 1) DEPDIRS-librte_eal := librte_kvargs
>
> 2)DEPDIRS-librte_mbuf := librte_eal librte_mempool
>
> 3)DEPDIRS-librte_ethdev := librte_net librte_eal librte_mempool librte_ring
> DEPDIRS-librte_ethdev += librte_mbuf
> DEPDIRS-librte_ethdev += librte_kvargs
> DEPDIRS-librte_ethdev += librte_cmdline
>
> 4) DEPDIRS-librte_net := librte_mbuf librte_eal
>
> 5) DEPDIRS-librte_meter := librte_eal
>
> Thanks,
> Reshma
Yes, I wound not mind to put this header file in librte_net, it makes sense to me. But librte_net depends on librte_mbuf, so then librte_net is not an option.
The only two options are librte_eal and librte_mbuf. Between these two, my vote was librte_eal (as we already have plenty of similar items in librte_eal/common/include) instead of librte_mbuf, as to me the packet color is not related to how DPDK decides to pick its packet meta-data.
To me, librte_eal/common/include is still the best option, but I guess I can live with librte_mbuf in case Konstantin has a hard opinion on it.
What is your choice, Konstantin?
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
2018-12-17 18:51 ` Dumitrescu, Cristian
@ 2018-12-17 23:11 ` Thomas Monjalon
2018-12-18 10:30 ` Dumitrescu, Cristian
2018-12-18 11:18 ` Dumitrescu, Cristian
2018-12-18 10:15 ` Ananyev, Konstantin
1 sibling, 2 replies; 74+ messages in thread
From: Thomas Monjalon @ 2018-12-17 23:11 UTC (permalink / raw)
To: Dumitrescu, Cristian, Pattan, Reshma
Cc: dev, Ananyev, Konstantin, jerin.jacob, Singh, Jasvinder, david.marchand
17/12/2018 19:51, Dumitrescu, Cristian:
> From: Pattan, Reshma
> > From: Ananyev, Konstantin
> > > From: Dumitrescu, Cristian
> > > > From: Ananyev, Konstantin
> > > > > > --- /dev/null
> > > > > > +++ b/lib/librte_eal/common/include/rte_color.h
> > > > > > +enum rte_color {
> > > > > > + RTE_COLOR_GREEN = 0, /**< Green */
> > > > > > + RTE_COLOR_YELLOW, /**< Yellow */
> > > > > > + RTE_COLOR_RED, /**< Red */
> > > > > > + RTE_COLORS /**< Number of colors */ };
> > > > >
> > > > > Does it really belong to EAL?
> > > > > Konstantin
> > > >
> > > > Why not?
> > > >
> > > > It needs to be visible to multiple libraries: ethdev, meter, sched, as
> > > > well as drivers. We'd like to avoid adding more complexity to
> > dependencies
> > > between libraries.
> > > >
> > > > It is very generic. EAL common/include is currently the place to put
> > > > generic data structures, functions, algs, etc that are widely used by DPDK
> > > libraries. Lots of similar examples are easy to find in this folder.
> > >
> > > I don't think it is *that* generic to be in EAL.
> > > Yes it is used by few libs, ethdev and by softnic PMD,
> > > but it doesn't look as core dpdk thing to me.
> > >
> > > >
> > > > Where else would you put it?
> > >
> > > If it defines format of rte_mbuf fileds, then probably new .h inside
> > librte_mbuf is
> > > a good place.
> > > Other alternatives would be rte_ethdev or rte_net.
> >
> > After going through the lib/Makefile dependencies, I see we can have
> > rte_color.h in eal or mbuf library only.
> > Cannot keep it inside ethdev or net libraries because these two libraries
> > already have dependency on mbuf library, so cannot create loop
> > dependency.
> >
> > Snippet
> >
> > 1) DEPDIRS-librte_eal := librte_kvargs
> >
> > 2)DEPDIRS-librte_mbuf := librte_eal librte_mempool
> >
> > 3)DEPDIRS-librte_ethdev := librte_net librte_eal librte_mempool librte_ring
> > DEPDIRS-librte_ethdev += librte_mbuf
> > DEPDIRS-librte_ethdev += librte_kvargs
> > DEPDIRS-librte_ethdev += librte_cmdline
> >
> > 4) DEPDIRS-librte_net := librte_mbuf librte_eal
> >
> > 5) DEPDIRS-librte_meter := librte_eal
> >
> > Thanks,
> > Reshma
>
> Yes, I wound not mind to put this header file in librte_net, it makes sense to me. But librte_net depends on librte_mbuf, so then librte_net is not an option.
>
> The only two options are librte_eal and librte_mbuf. Between these two, my vote was librte_eal (as we already have plenty of similar items in librte_eal/common/include) instead of librte_mbuf, as to me the packet color is not related to how DPDK decides to pick its packet meta-data.
>
> To me, librte_eal/common/include is still the best option, but I guess I can live with librte_mbuf in case Konstantin has a hard opinion on it.
>
> What is your choice, Konstantin?
I replied in v3 that it should stay in rte_meter.h.
You can include rte_meter.h in ethdev.
The other option, agreed by Reshma, is to add black color ;)
Note: I did not see this discussion on v2 because the versions are
not in the same thread. Have I already asked to use --in-reply-to please?
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
2018-12-17 23:11 ` Thomas Monjalon
@ 2018-12-18 10:30 ` Dumitrescu, Cristian
2018-12-18 11:18 ` Dumitrescu, Cristian
1 sibling, 0 replies; 74+ messages in thread
From: Dumitrescu, Cristian @ 2018-12-18 10:30 UTC (permalink / raw)
To: Thomas Monjalon, Pattan, Reshma
Cc: dev, Ananyev, Konstantin, jerin.jacob, Singh, Jasvinder, david.marchand
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Monday, December 17, 2018 11:11 PM
> To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Pattan, Reshma
> <reshma.pattan@intel.com>
> Cc: dev@dpdk.org; Ananyev, Konstantin <konstantin.ananyev@intel.com>;
> jerin.jacob@caviumnetworks.com; Singh, Jasvinder
> <jasvinder.singh@intel.com>; david.marchand@redhat.com
> Subject: Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
>
> 17/12/2018 19:51, Dumitrescu, Cristian:
> > From: Pattan, Reshma
> > > From: Ananyev, Konstantin
> > > > From: Dumitrescu, Cristian
> > > > > From: Ananyev, Konstantin
> > > > > > > --- /dev/null
> > > > > > > +++ b/lib/librte_eal/common/include/rte_color.h
> > > > > > > +enum rte_color {
> > > > > > > + RTE_COLOR_GREEN = 0, /**< Green */
> > > > > > > + RTE_COLOR_YELLOW, /**< Yellow */
> > > > > > > + RTE_COLOR_RED, /**< Red */
> > > > > > > + RTE_COLORS /**< Number of colors */ };
> > > > > >
> > > > > > Does it really belong to EAL?
> > > > > > Konstantin
> > > > >
> > > > > Why not?
> > > > >
> > > > > It needs to be visible to multiple libraries: ethdev, meter, sched, as
> > > > > well as drivers. We'd like to avoid adding more complexity to
> > > dependencies
> > > > between libraries.
> > > > >
> > > > > It is very generic. EAL common/include is currently the place to put
> > > > > generic data structures, functions, algs, etc that are widely used by
> DPDK
> > > > libraries. Lots of similar examples are easy to find in this folder.
> > > >
> > > > I don't think it is *that* generic to be in EAL.
> > > > Yes it is used by few libs, ethdev and by softnic PMD,
> > > > but it doesn't look as core dpdk thing to me.
> > > >
> > > > >
> > > > > Where else would you put it?
> > > >
> > > > If it defines format of rte_mbuf fileds, then probably new .h inside
> > > librte_mbuf is
> > > > a good place.
> > > > Other alternatives would be rte_ethdev or rte_net.
> > >
> > > After going through the lib/Makefile dependencies, I see we can have
> > > rte_color.h in eal or mbuf library only.
> > > Cannot keep it inside ethdev or net libraries because these two libraries
> > > already have dependency on mbuf library, so cannot create loop
> > > dependency.
> > >
> > > Snippet
> > >
> > > 1) DEPDIRS-librte_eal := librte_kvargs
> > >
> > > 2)DEPDIRS-librte_mbuf := librte_eal librte_mempool
> > >
> > > 3)DEPDIRS-librte_ethdev := librte_net librte_eal librte_mempool
> librte_ring
> > > DEPDIRS-librte_ethdev += librte_mbuf
> > > DEPDIRS-librte_ethdev += librte_kvargs
> > > DEPDIRS-librte_ethdev += librte_cmdline
> > >
> > > 4) DEPDIRS-librte_net := librte_mbuf librte_eal
> > >
> > > 5) DEPDIRS-librte_meter := librte_eal
> > >
> > > Thanks,
> > > Reshma
> >
> > Yes, I wound not mind to put this header file in librte_net, it makes sense
> to me. But librte_net depends on librte_mbuf, so then librte_net is not an
> option.
> >
> > The only two options are librte_eal and librte_mbuf. Between these two,
> my vote was librte_eal (as we already have plenty of similar items in
> librte_eal/common/include) instead of librte_mbuf, as to me the packet
> color is not related to how DPDK decides to pick its packet meta-data.
> >
> > To me, librte_eal/common/include is still the best option, but I guess I can
> live with librte_mbuf in case Konstantin has a hard opinion on it.
> >
> > What is your choice, Konstantin?
>
> I replied in v3 that it should stay in rte_meter.h.
Strange, I did not see this reply from you ...
> You can include rte_meter.h in ethdev.
OK, thanks Thomas, makes sense to me as well.
>
> The other option, agreed by Reshma, is to add black color ;)
>
> Note: I did not see this discussion on v2 because the versions are
> not in the same thread. Have I already asked to use --in-reply-to please?
>
>
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
2018-12-17 23:11 ` Thomas Monjalon
2018-12-18 10:30 ` Dumitrescu, Cristian
@ 2018-12-18 11:18 ` Dumitrescu, Cristian
2018-12-18 12:38 ` Thomas Monjalon
1 sibling, 1 reply; 74+ messages in thread
From: Dumitrescu, Cristian @ 2018-12-18 11:18 UTC (permalink / raw)
To: Thomas Monjalon, Pattan, Reshma
Cc: dev, Ananyev, Konstantin, jerin.jacob, Singh, Jasvinder, david.marchand
> > I replied in v3 that it should stay in rte_meter.h.
> > You can include rte_meter.h in ethdev.
>
> OK, thanks Thomas, makes sense to me as well.
>
Thomas,
I agree with your input, but just want to make sure we are on the same page:
Besides including rte_meter.h in ethdev (which you are fine with), we would also need to include rte_meter.h in mbuf.
Are you OK with this as well?
Regards,
Cristian
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
2018-12-18 11:18 ` Dumitrescu, Cristian
@ 2018-12-18 12:38 ` Thomas Monjalon
2018-12-18 13:19 ` Dumitrescu, Cristian
0 siblings, 1 reply; 74+ messages in thread
From: Thomas Monjalon @ 2018-12-18 12:38 UTC (permalink / raw)
To: Dumitrescu, Cristian
Cc: Pattan, Reshma, dev, Ananyev, Konstantin, jerin.jacob, Singh,
Jasvinder, david.marchand, olivier.matz
18/12/2018 12:18, Dumitrescu, Cristian:
> > > I replied in v3 that it should stay in rte_meter.h.
> > > You can include rte_meter.h in ethdev.
> >
> > OK, thanks Thomas, makes sense to me as well.
> >
>
> Thomas,
>
> I agree with your input, but just want to make sure we are on the same page:
>
> Besides including rte_meter.h in ethdev (which you are fine with), we would also need to include rte_meter.h in mbuf.
>
> Are you OK with this as well?
Why do we need rte_meter.h in mbuf?
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
2018-12-18 12:38 ` Thomas Monjalon
@ 2018-12-18 13:19 ` Dumitrescu, Cristian
2018-12-18 13:39 ` Thomas Monjalon
0 siblings, 1 reply; 74+ messages in thread
From: Dumitrescu, Cristian @ 2018-12-18 13:19 UTC (permalink / raw)
To: Thomas Monjalon
Cc: Pattan, Reshma, dev, Ananyev, Konstantin, jerin.jacob, Singh,
Jasvinder, david.marchand, olivier.matz
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Tuesday, December 18, 2018 12:38 PM
> To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> Cc: Pattan, Reshma <reshma.pattan@intel.com>; dev@dpdk.org; Ananyev,
> Konstantin <konstantin.ananyev@intel.com>;
> jerin.jacob@caviumnetworks.com; Singh, Jasvinder
> <jasvinder.singh@intel.com>; david.marchand@redhat.com;
> olivier.matz@6wind.com
> Subject: Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
>
> 18/12/2018 12:18, Dumitrescu, Cristian:
> > > > I replied in v3 that it should stay in rte_meter.h.
> > > > You can include rte_meter.h in ethdev.
> > >
> > > OK, thanks Thomas, makes sense to me as well.
> > >
> >
> > Thomas,
> >
> > I agree with your input, but just want to make sure we are on the same
> page:
> >
> > Besides including rte_meter.h in ethdev (which you are fine with), we
> would also need to include rte_meter.h in mbuf.
> >
> > Are you OK with this as well?
>
> Why do we need rte_meter.h in mbuf?
>
You probably looked at V2 only, but in V3 we have functions to set/get the color within the mbuf->hash.sched field.
For space compression reasons, the mbuf->hash.sched stores the color on 8-bit variable, while for the outside world the set/get functions work with the 32-bit enum type. We do same thing in other places in DPDK, such as rte_crypto_op, etc.
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
2018-12-18 13:19 ` Dumitrescu, Cristian
@ 2018-12-18 13:39 ` Thomas Monjalon
2018-12-18 17:07 ` Ananyev, Konstantin
0 siblings, 1 reply; 74+ messages in thread
From: Thomas Monjalon @ 2018-12-18 13:39 UTC (permalink / raw)
To: Dumitrescu, Cristian
Cc: Pattan, Reshma, dev, Ananyev, Konstantin, jerin.jacob, Singh,
Jasvinder, david.marchand, olivier.matz
18/12/2018 14:19, Dumitrescu, Cristian:
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > 18/12/2018 12:18, Dumitrescu, Cristian:
> > > > > I replied in v3 that it should stay in rte_meter.h.
> > > > > You can include rte_meter.h in ethdev.
> > > >
> > > > OK, thanks Thomas, makes sense to me as well.
> > > >
> > >
> > > Thomas,
> > >
> > > I agree with your input, but just want to make sure we are on the same
> > page:
> > >
> > > Besides including rte_meter.h in ethdev (which you are fine with), we
> > would also need to include rte_meter.h in mbuf.
> > >
> > > Are you OK with this as well?
> >
> > Why do we need rte_meter.h in mbuf?
> >
>
> You probably looked at V2 only, but in V3 we have functions to set/get the color within the mbuf->hash.sched field.
>
> For space compression reasons, the mbuf->hash.sched stores the color on 8-bit variable, while for the outside world the set/get functions work with the 32-bit enum type. We do same thing in other places in DPDK, such as rte_crypto_op, etc.
So it's a different discussion.
We need to review this v3 and check how relevant this mbuf API is.
If the API is accepted, yes the include should not be an issue.
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
2018-12-18 13:39 ` Thomas Monjalon
@ 2018-12-18 17:07 ` Ananyev, Konstantin
2018-12-18 19:34 ` Dumitrescu, Cristian
0 siblings, 1 reply; 74+ messages in thread
From: Ananyev, Konstantin @ 2018-12-18 17:07 UTC (permalink / raw)
To: Thomas Monjalon, Dumitrescu, Cristian
Cc: Pattan, Reshma, dev, jerin.jacob, Singh, Jasvinder,
david.marchand, olivier.matz
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Tuesday, December 18, 2018 1:39 PM
> To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> Cc: Pattan, Reshma <reshma.pattan@intel.com>; dev@dpdk.org; Ananyev, Konstantin <konstantin.ananyev@intel.com>;
> jerin.jacob@caviumnetworks.com; Singh, Jasvinder <jasvinder.singh@intel.com>; david.marchand@redhat.com; olivier.matz@6wind.com
> Subject: Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
>
> 18/12/2018 14:19, Dumitrescu, Cristian:
> > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > 18/12/2018 12:18, Dumitrescu, Cristian:
> > > > > > I replied in v3 that it should stay in rte_meter.h.
> > > > > > You can include rte_meter.h in ethdev.
> > > > >
> > > > > OK, thanks Thomas, makes sense to me as well.
> > > > >
> > > >
> > > > Thomas,
> > > >
> > > > I agree with your input, but just want to make sure we are on the same
> > > page:
> > > >
> > > > Besides including rte_meter.h in ethdev (which you are fine with), we
> > > would also need to include rte_meter.h in mbuf.
> > > >
> > > > Are you OK with this as well?
> > >
> > > Why do we need rte_meter.h in mbuf?
> > >
> >
> > You probably looked at V2 only, but in V3 we have functions to set/get the color within the mbuf->hash.sched field.
> >
> > For space compression reasons, the mbuf->hash.sched stores the color on 8-bit variable, while for the outside world the set/get functions
> work with the 32-bit enum type. We do same thing in other places in DPDK, such as rte_crypto_op, etc.
>
> So it's a different discussion.
> We need to review this v3 and check how relevant this mbuf API is.
>
> If the API is accepted, yes the include should not be an issue.
Personally, I don't think it is a good idea to add extra dependency for librte_mbuf.
I'd prefer either to keep rte_color definition inside librte_mbuf,
or move corresponding function definitions out of it.
Konstantin
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
2018-12-18 17:07 ` Ananyev, Konstantin
@ 2018-12-18 19:34 ` Dumitrescu, Cristian
2018-12-18 20:19 ` Thomas Monjalon
2018-12-19 10:49 ` Ananyev, Konstantin
0 siblings, 2 replies; 74+ messages in thread
From: Dumitrescu, Cristian @ 2018-12-18 19:34 UTC (permalink / raw)
To: Ananyev, Konstantin, Thomas Monjalon
Cc: Pattan, Reshma, dev, jerin.jacob, Singh, Jasvinder,
david.marchand, olivier.matz
> -----Original Message-----
> From: Ananyev, Konstantin
> Sent: Tuesday, December 18, 2018 5:07 PM
> To: Thomas Monjalon <thomas@monjalon.net>; Dumitrescu, Cristian
> <cristian.dumitrescu@intel.com>
> Cc: Pattan, Reshma <reshma.pattan@intel.com>; dev@dpdk.org;
> jerin.jacob@caviumnetworks.com; Singh, Jasvinder
> <jasvinder.singh@intel.com>; david.marchand@redhat.com;
> olivier.matz@6wind.com
> Subject: RE: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
>
>
>
> > -----Original Message-----
> > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > Sent: Tuesday, December 18, 2018 1:39 PM
> > To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> > Cc: Pattan, Reshma <reshma.pattan@intel.com>; dev@dpdk.org; Ananyev,
> Konstantin <konstantin.ananyev@intel.com>;
> > jerin.jacob@caviumnetworks.com; Singh, Jasvinder
> <jasvinder.singh@intel.com>; david.marchand@redhat.com;
> olivier.matz@6wind.com
> > Subject: Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
> >
> > 18/12/2018 14:19, Dumitrescu, Cristian:
> > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > 18/12/2018 12:18, Dumitrescu, Cristian:
> > > > > > > I replied in v3 that it should stay in rte_meter.h.
> > > > > > > You can include rte_meter.h in ethdev.
> > > > > >
> > > > > > OK, thanks Thomas, makes sense to me as well.
> > > > > >
> > > > >
> > > > > Thomas,
> > > > >
> > > > > I agree with your input, but just want to make sure we are on the
> same
> > > > page:
> > > > >
> > > > > Besides including rte_meter.h in ethdev (which you are fine with), we
> > > > would also need to include rte_meter.h in mbuf.
> > > > >
> > > > > Are you OK with this as well?
> > > >
> > > > Why do we need rte_meter.h in mbuf?
> > > >
> > >
> > > You probably looked at V2 only, but in V3 we have functions to set/get
> the color within the mbuf->hash.sched field.
> > >
> > > For space compression reasons, the mbuf->hash.sched stores the color
> on 8-bit variable, while for the outside world the set/get functions
> > work with the 32-bit enum type. We do same thing in other places in DPDK,
> such as rte_crypto_op, etc.
> >
> > So it's a different discussion.
> > We need to review this v3 and check how relevant this mbuf API is.
> >
> > If the API is accepted, yes the include should not be an issue.
>
> Personally, I don't think it is a good idea to add extra dependency for
> librte_mbuf.
> I'd prefer either to keep rte_color definition inside librte_mbuf,
> or move corresponding function definitions out of it.
> Konstantin
Konstantin,
As you see, the number of options is limited, and none of them is perfect:
1/ color enum in EAL/common/include: still my favorite, as it does not create any new library dependencies, and it is already used to store lots of similar generic items
2/ color enum in rte_meter.h: results in creating new librte_mbuf dependency to librte_meter
3/ color enum in rte_mbuf.h: results in creating new librte_meter dependency to librte_mbuf (yes, currently librte_meter does not depend on librte_mbuf)
Personally, I can live with any of these options.
Thomas,
It would be good to have your input as well, Reshma just sent V4 implementing your proposal based on having the color enum defined in rte_meter.h, which gets included into rte_mbuf.h.
We need to make progress for RC1 deadline.
Thanks,
Cristian
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
2018-12-18 19:34 ` Dumitrescu, Cristian
@ 2018-12-18 20:19 ` Thomas Monjalon
2018-12-19 10:47 ` Dumitrescu, Cristian
2018-12-19 10:52 ` Ananyev, Konstantin
2018-12-19 10:49 ` Ananyev, Konstantin
1 sibling, 2 replies; 74+ messages in thread
From: Thomas Monjalon @ 2018-12-18 20:19 UTC (permalink / raw)
To: Dumitrescu, Cristian
Cc: Ananyev, Konstantin, Pattan, Reshma, dev, jerin.jacob, Singh,
Jasvinder, david.marchand, olivier.matz, techboard
18/12/2018 20:34, Dumitrescu, Cristian:
> From: Ananyev, Konstantin
> > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > 18/12/2018 14:19, Dumitrescu, Cristian:
> > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > > 18/12/2018 12:18, Dumitrescu, Cristian:
> > > > > > > > I replied in v3 that it should stay in rte_meter.h.
> > > > > > > > You can include rte_meter.h in ethdev.
> > > > > > >
> > > > > > > OK, thanks Thomas, makes sense to me as well.
> > > > > > >
> > > > > >
> > > > > > Thomas,
> > > > > >
> > > > > > I agree with your input, but just want to make sure we are on the
> > same
> > > > > page:
> > > > > >
> > > > > > Besides including rte_meter.h in ethdev (which you are fine with), we
> > > > > would also need to include rte_meter.h in mbuf.
> > > > > >
> > > > > > Are you OK with this as well?
> > > > >
> > > > > Why do we need rte_meter.h in mbuf?
> > > > >
> > > >
> > > > You probably looked at V2 only, but in V3 we have functions to set/get
> > the color within the mbuf->hash.sched field.
> > > >
> > > > For space compression reasons, the mbuf->hash.sched stores the color
> > on 8-bit variable, while for the outside world the set/get functions
> > > work with the 32-bit enum type. We do same thing in other places in DPDK,
> > such as rte_crypto_op, etc.
> > >
> > > So it's a different discussion.
> > > We need to review this v3 and check how relevant this mbuf API is.
> > >
> > > If the API is accepted, yes the include should not be an issue.
> >
> > Personally, I don't think it is a good idea to add extra dependency for
> > librte_mbuf.
> > I'd prefer either to keep rte_color definition inside librte_mbuf,
> > or move corresponding function definitions out of it.
> > Konstantin
>
> Konstantin,
>
> As you see, the number of options is limited, and none of them is perfect:
>
> 1/ color enum in EAL/common/include: still my favorite, as it does not create any new library dependencies, and it is already used to store lots of similar generic items
> 2/ color enum in rte_meter.h: results in creating new librte_mbuf dependency to librte_meter
> 3/ color enum in rte_mbuf.h: results in creating new librte_meter dependency to librte_mbuf (yes, currently librte_meter does not depend on librte_mbuf)
>
> Personally, I can live with any of these options.
>
> Thomas,
>
> It would be good to have your input as well, Reshma just sent V4 implementing your proposal based on having the color enum defined in rte_meter.h, which gets included into rte_mbuf.h.
We need a decision from Olivier, mbuf maintainer.
> We need to make progress for RC1 deadline.
I'm afraid 19.02 is not the right release to change the mbuf.
This kind of decision usually takes several weeks.
Cc the technical board to get more opinions.
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
2018-12-18 20:19 ` Thomas Monjalon
@ 2018-12-19 10:47 ` Dumitrescu, Cristian
2018-12-19 10:50 ` Thomas Monjalon
2018-12-19 10:52 ` Ananyev, Konstantin
1 sibling, 1 reply; 74+ messages in thread
From: Dumitrescu, Cristian @ 2018-12-19 10:47 UTC (permalink / raw)
To: Thomas Monjalon
Cc: Ananyev, Konstantin, Pattan, Reshma, dev, jerin.jacob, Singh,
Jasvinder, david.marchand, olivier.matz, techboard
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Tuesday, December 18, 2018 8:20 PM
> To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> Cc: Ananyev, Konstantin <konstantin.ananyev@intel.com>; Pattan, Reshma
> <reshma.pattan@intel.com>; dev@dpdk.org;
> jerin.jacob@caviumnetworks.com; Singh, Jasvinder
> <jasvinder.singh@intel.com>; david.marchand@redhat.com;
> olivier.matz@6wind.com; techboard@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
>
> 18/12/2018 20:34, Dumitrescu, Cristian:
> > From: Ananyev, Konstantin
> > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > 18/12/2018 14:19, Dumitrescu, Cristian:
> > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > > > 18/12/2018 12:18, Dumitrescu, Cristian:
> > > > > > > > > I replied in v3 that it should stay in rte_meter.h.
> > > > > > > > > You can include rte_meter.h in ethdev.
> > > > > > > >
> > > > > > > > OK, thanks Thomas, makes sense to me as well.
> > > > > > > >
> > > > > > >
> > > > > > > Thomas,
> > > > > > >
> > > > > > > I agree with your input, but just want to make sure we are on the
> > > same
> > > > > > page:
> > > > > > >
> > > > > > > Besides including rte_meter.h in ethdev (which you are fine with),
> we
> > > > > > would also need to include rte_meter.h in mbuf.
> > > > > > >
> > > > > > > Are you OK with this as well?
> > > > > >
> > > > > > Why do we need rte_meter.h in mbuf?
> > > > > >
> > > > >
> > > > > You probably looked at V2 only, but in V3 we have functions to
> set/get
> > > the color within the mbuf->hash.sched field.
> > > > >
> > > > > For space compression reasons, the mbuf->hash.sched stores the
> color
> > > on 8-bit variable, while for the outside world the set/get functions
> > > > work with the 32-bit enum type. We do same thing in other places in
> DPDK,
> > > such as rte_crypto_op, etc.
> > > >
> > > > So it's a different discussion.
> > > > We need to review this v3 and check how relevant this mbuf API is.
> > > >
> > > > If the API is accepted, yes the include should not be an issue.
> > >
> > > Personally, I don't think it is a good idea to add extra dependency for
> > > librte_mbuf.
> > > I'd prefer either to keep rte_color definition inside librte_mbuf,
> > > or move corresponding function definitions out of it.
> > > Konstantin
> >
> > Konstantin,
> >
> > As you see, the number of options is limited, and none of them is
> perfect:
> >
> > 1/ color enum in EAL/common/include: still my favorite, as it does not
> create any new library dependencies, and it is already used to store lots of
> similar generic items
> > 2/ color enum in rte_meter.h: results in creating new librte_mbuf
> dependency to librte_meter
> > 3/ color enum in rte_mbuf.h: results in creating new librte_meter
> dependency to librte_mbuf (yes, currently librte_meter does not depend on
> librte_mbuf)
> >
> > Personally, I can live with any of these options.
> >
> > Thomas,
> >
> > It would be good to have your input as well, Reshma just sent V4
> implementing your proposal based on having the color enum defined in
> rte_meter.h, which gets included into rte_mbuf.h.
>
> We need a decision from Olivier, mbuf maintainer.
>
> > We need to make progress for RC1 deadline.
>
> I'm afraid 19.02 is not the right release to change the mbuf.
> This kind of decision usually takes several weeks.
> Cc the technical board to get more opinions.
>
Hi Thomas,
The only change we are planning to do on the mbuf is reformatting of the sched field, according to the deprecation note that was already acked by Olivier and many others:
http://git.dpdk.org/dpdk/tree/doc/guides/rel_notes/deprecation.rst#n52
We are planning to send V5 that should simplify the solution and avoid any such issues. Specifically, what we are going to do in V5 is:
1/ Make sure the only mbuf changes are related to the reformatting of the sched field, precisely implementing the above deprecation note;
2/ Include rte_meter.h into some ethdev headers, which you already agreed with
3/ Avoid adding any header to librte_eal/common/include
Are you OK with this?
Hopefully this should remove any roadblocks and any further delays for this patch set.
Regards,
Cristian
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
2018-12-19 10:47 ` Dumitrescu, Cristian
@ 2018-12-19 10:50 ` Thomas Monjalon
0 siblings, 0 replies; 74+ messages in thread
From: Thomas Monjalon @ 2018-12-19 10:50 UTC (permalink / raw)
To: Dumitrescu, Cristian
Cc: Ananyev, Konstantin, Pattan, Reshma, dev, jerin.jacob, Singh,
Jasvinder, david.marchand, olivier.matz, techboard
19/12/2018 11:47, Dumitrescu, Cristian:
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > 18/12/2018 20:34, Dumitrescu, Cristian:
> > > From: Ananyev, Konstantin
> > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > > 18/12/2018 14:19, Dumitrescu, Cristian:
> > > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > > > > 18/12/2018 12:18, Dumitrescu, Cristian:
> > > > > > > > > > I replied in v3 that it should stay in rte_meter.h.
> > > > > > > > > > You can include rte_meter.h in ethdev.
> > > > > > > > >
> > > > > > > > > OK, thanks Thomas, makes sense to me as well.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Thomas,
> > > > > > > >
> > > > > > > > I agree with your input, but just want to make sure we are on the
> > > > same
> > > > > > > page:
> > > > > > > >
> > > > > > > > Besides including rte_meter.h in ethdev (which you are fine with),
> > we
> > > > > > > would also need to include rte_meter.h in mbuf.
> > > > > > > >
> > > > > > > > Are you OK with this as well?
> > > > > > >
> > > > > > > Why do we need rte_meter.h in mbuf?
> > > > > > >
> > > > > >
> > > > > > You probably looked at V2 only, but in V3 we have functions to
> > set/get
> > > > the color within the mbuf->hash.sched field.
> > > > > >
> > > > > > For space compression reasons, the mbuf->hash.sched stores the
> > color
> > > > on 8-bit variable, while for the outside world the set/get functions
> > > > > work with the 32-bit enum type. We do same thing in other places in
> > DPDK,
> > > > such as rte_crypto_op, etc.
> > > > >
> > > > > So it's a different discussion.
> > > > > We need to review this v3 and check how relevant this mbuf API is.
> > > > >
> > > > > If the API is accepted, yes the include should not be an issue.
> > > >
> > > > Personally, I don't think it is a good idea to add extra dependency for
> > > > librte_mbuf.
> > > > I'd prefer either to keep rte_color definition inside librte_mbuf,
> > > > or move corresponding function definitions out of it.
> > > > Konstantin
> > >
> > > Konstantin,
> > >
> > > As you see, the number of options is limited, and none of them is
> > perfect:
> > >
> > > 1/ color enum in EAL/common/include: still my favorite, as it does not
> > create any new library dependencies, and it is already used to store lots of
> > similar generic items
> > > 2/ color enum in rte_meter.h: results in creating new librte_mbuf
> > dependency to librte_meter
> > > 3/ color enum in rte_mbuf.h: results in creating new librte_meter
> > dependency to librte_mbuf (yes, currently librte_meter does not depend on
> > librte_mbuf)
> > >
> > > Personally, I can live with any of these options.
> > >
> > > Thomas,
> > >
> > > It would be good to have your input as well, Reshma just sent V4
> > implementing your proposal based on having the color enum defined in
> > rte_meter.h, which gets included into rte_mbuf.h.
> >
> > We need a decision from Olivier, mbuf maintainer.
> >
> > > We need to make progress for RC1 deadline.
> >
> > I'm afraid 19.02 is not the right release to change the mbuf.
> > This kind of decision usually takes several weeks.
> > Cc the technical board to get more opinions.
> >
>
> Hi Thomas,
>
> The only change we are planning to do on the mbuf is reformatting of the sched field, according to the deprecation note that was already acked by Olivier and many others:
> http://git.dpdk.org/dpdk/tree/doc/guides/rel_notes/deprecation.rst#n52
>
> We are planning to send V5 that should simplify the solution and avoid any such issues. Specifically, what we are going to do in V5 is:
> 1/ Make sure the only mbuf changes are related to the reformatting of the sched field, precisely implementing the above deprecation note;
> 2/ Include rte_meter.h into some ethdev headers, which you already agreed with
> 3/ Avoid adding any header to librte_eal/common/include
>
> Are you OK with this?
>
> Hopefully this should remove any roadblocks and any further delays for this patch set.
Yes I am OK.
Obvioulsy, I would be more confortable if having an ack from Olivier.
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
2018-12-18 20:19 ` Thomas Monjalon
2018-12-19 10:47 ` Dumitrescu, Cristian
@ 2018-12-19 10:52 ` Ananyev, Konstantin
1 sibling, 0 replies; 74+ messages in thread
From: Ananyev, Konstantin @ 2018-12-19 10:52 UTC (permalink / raw)
To: Thomas Monjalon, Dumitrescu, Cristian
Cc: Pattan, Reshma, dev, jerin.jacob, Singh, Jasvinder,
david.marchand, olivier.matz, techboard
> 18/12/2018 20:34, Dumitrescu, Cristian:
> > From: Ananyev, Konstantin
> > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > 18/12/2018 14:19, Dumitrescu, Cristian:
> > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > > > 18/12/2018 12:18, Dumitrescu, Cristian:
> > > > > > > > > I replied in v3 that it should stay in rte_meter.h.
> > > > > > > > > You can include rte_meter.h in ethdev.
> > > > > > > >
> > > > > > > > OK, thanks Thomas, makes sense to me as well.
> > > > > > > >
> > > > > > >
> > > > > > > Thomas,
> > > > > > >
> > > > > > > I agree with your input, but just want to make sure we are on the
> > > same
> > > > > > page:
> > > > > > >
> > > > > > > Besides including rte_meter.h in ethdev (which you are fine with), we
> > > > > > would also need to include rte_meter.h in mbuf.
> > > > > > >
> > > > > > > Are you OK with this as well?
> > > > > >
> > > > > > Why do we need rte_meter.h in mbuf?
> > > > > >
> > > > >
> > > > > You probably looked at V2 only, but in V3 we have functions to set/get
> > > the color within the mbuf->hash.sched field.
> > > > >
> > > > > For space compression reasons, the mbuf->hash.sched stores the color
> > > on 8-bit variable, while for the outside world the set/get functions
> > > > work with the 32-bit enum type. We do same thing in other places in DPDK,
> > > such as rte_crypto_op, etc.
> > > >
> > > > So it's a different discussion.
> > > > We need to review this v3 and check how relevant this mbuf API is.
> > > >
> > > > If the API is accepted, yes the include should not be an issue.
> > >
> > > Personally, I don't think it is a good idea to add extra dependency for
> > > librte_mbuf.
> > > I'd prefer either to keep rte_color definition inside librte_mbuf,
> > > or move corresponding function definitions out of it.
> > > Konstantin
> >
> > Konstantin,
> >
> > As you see, the number of options is limited, and none of them is perfect:
> >
> > 1/ color enum in EAL/common/include: still my favorite, as it does not create any new library dependencies, and it is already used
> to store lots of similar generic items
> > 2/ color enum in rte_meter.h: results in creating new librte_mbuf dependency to librte_meter
> > 3/ color enum in rte_mbuf.h: results in creating new librte_meter dependency to librte_mbuf (yes, currently librte_meter does not
> depend on librte_mbuf)
> >
> > Personally, I can live with any of these options.
> >
> > Thomas,
> >
> > It would be good to have your input as well, Reshma just sent V4 implementing your proposal based on having the color enum
> defined in rte_meter.h, which gets included into rte_mbuf.h.
>
> We need a decision from Olivier, mbuf maintainer.
>
> > We need to make progress for RC1 deadline.
>
> I'm afraid 19.02 is not the right release to change the mbuf.
> This kind of decision usually takes several weeks.
> Cc the technical board to get more opinions.
I general, I don't see any problem with these changes for 19.02.
As I can see,, they only affect rte_mbuf sched filed format/interpretation.
All other fields meaning/layout remain the same.
Konstantin
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
2018-12-18 19:34 ` Dumitrescu, Cristian
2018-12-18 20:19 ` Thomas Monjalon
@ 2018-12-19 10:49 ` Ananyev, Konstantin
2018-12-19 11:04 ` Dumitrescu, Cristian
1 sibling, 1 reply; 74+ messages in thread
From: Ananyev, Konstantin @ 2018-12-19 10:49 UTC (permalink / raw)
To: Dumitrescu, Cristian, Thomas Monjalon
Cc: Pattan, Reshma, dev, jerin.jacob, Singh, Jasvinder,
david.marchand, olivier.matz
Hi Cristian,
> > > 18/12/2018 14:19, Dumitrescu, Cristian:
> > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > > 18/12/2018 12:18, Dumitrescu, Cristian:
> > > > > > > > I replied in v3 that it should stay in rte_meter.h.
> > > > > > > > You can include rte_meter.h in ethdev.
> > > > > > >
> > > > > > > OK, thanks Thomas, makes sense to me as well.
> > > > > > >
> > > > > >
> > > > > > Thomas,
> > > > > >
> > > > > > I agree with your input, but just want to make sure we are on the
> > same
> > > > > page:
> > > > > >
> > > > > > Besides including rte_meter.h in ethdev (which you are fine with), we
> > > > > would also need to include rte_meter.h in mbuf.
> > > > > >
> > > > > > Are you OK with this as well?
> > > > >
> > > > > Why do we need rte_meter.h in mbuf?
> > > > >
> > > >
> > > > You probably looked at V2 only, but in V3 we have functions to set/get
> > the color within the mbuf->hash.sched field.
> > > >
> > > > For space compression reasons, the mbuf->hash.sched stores the color
> > on 8-bit variable, while for the outside world the set/get functions
> > > work with the 32-bit enum type. We do same thing in other places in DPDK,
> > such as rte_crypto_op, etc.
> > >
> > > So it's a different discussion.
> > > We need to review this v3 and check how relevant this mbuf API is.
> > >
> > > If the API is accepted, yes the include should not be an issue.
> >
> > Personally, I don't think it is a good idea to add extra dependency for
> > librte_mbuf.
> > I'd prefer either to keep rte_color definition inside librte_mbuf,
> > or move corresponding function definitions out of it.
> > Konstantin
>
> Konstantin,
>
> As you see, the number of options is limited, and none of them is perfect:
>
> 1/ color enum in EAL/common/include: still my favorite, as it does not create any new library dependencies, and it is already used
> to store lots of similar generic items
As I remember, we don't put network specific things into EAL, but probably you have different examples?
> 2/ color enum in rte_meter.h: results in creating new librte_mbuf dependency to librte_meter
> 3/ color enum in rte_mbuf.h: results in creating new librte_meter dependency to librte_mbuf (yes, currently librte_meter does not
> depend on librte_mbuf)
4/ Keep color as uint8_t in rte_mbuf and 'move enum rte_color' definition and related functions in rte_meter.
My preference is either 3) or 4).
Konstantin
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
2018-12-19 10:49 ` Ananyev, Konstantin
@ 2018-12-19 11:04 ` Dumitrescu, Cristian
0 siblings, 0 replies; 74+ messages in thread
From: Dumitrescu, Cristian @ 2018-12-19 11:04 UTC (permalink / raw)
To: Ananyev, Konstantin, Thomas Monjalon
Cc: Pattan, Reshma, dev, jerin.jacob, Singh, Jasvinder,
david.marchand, olivier.matz
> -----Original Message-----
> From: Ananyev, Konstantin
> Sent: Wednesday, December 19, 2018 10:49 AM
> To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Thomas Monjalon
> <thomas@monjalon.net>
> Cc: Pattan, Reshma <reshma.pattan@intel.com>; dev@dpdk.org;
> jerin.jacob@caviumnetworks.com; Singh, Jasvinder
> <jasvinder.singh@intel.com>; david.marchand@redhat.com;
> olivier.matz@6wind.com
> Subject: RE: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
>
>
> Hi Cristian,
>
> > > > 18/12/2018 14:19, Dumitrescu, Cristian:
> > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > > > 18/12/2018 12:18, Dumitrescu, Cristian:
> > > > > > > > > I replied in v3 that it should stay in rte_meter.h.
> > > > > > > > > You can include rte_meter.h in ethdev.
> > > > > > > >
> > > > > > > > OK, thanks Thomas, makes sense to me as well.
> > > > > > > >
> > > > > > >
> > > > > > > Thomas,
> > > > > > >
> > > > > > > I agree with your input, but just want to make sure we are on the
> > > same
> > > > > > page:
> > > > > > >
> > > > > > > Besides including rte_meter.h in ethdev (which you are fine with),
> we
> > > > > > would also need to include rte_meter.h in mbuf.
> > > > > > >
> > > > > > > Are you OK with this as well?
> > > > > >
> > > > > > Why do we need rte_meter.h in mbuf?
> > > > > >
> > > > >
> > > > > You probably looked at V2 only, but in V3 we have functions to
> set/get
> > > the color within the mbuf->hash.sched field.
> > > > >
> > > > > For space compression reasons, the mbuf->hash.sched stores the
> color
> > > on 8-bit variable, while for the outside world the set/get functions
> > > > work with the 32-bit enum type. We do same thing in other places in
> DPDK,
> > > such as rte_crypto_op, etc.
> > > >
> > > > So it's a different discussion.
> > > > We need to review this v3 and check how relevant this mbuf API is.
> > > >
> > > > If the API is accepted, yes the include should not be an issue.
> > >
> > > Personally, I don't think it is a good idea to add extra dependency for
> > > librte_mbuf.
> > > I'd prefer either to keep rte_color definition inside librte_mbuf,
> > > or move corresponding function definitions out of it.
> > > Konstantin
> >
> > Konstantin,
> >
> > As you see, the number of options is limited, and none of them is
> perfect:
> >
> > 1/ color enum in EAL/common/include: still my favorite, as it does not
> create any new library dependencies, and it is already used
> > to store lots of similar generic items
>
> As I remember, we don't put network specific things into EAL, but probably
> you have different examples?
Examples in librte_eal/common/include: random, reciprocal, bitmap, alarm, branch prediction, debug, log, fbarray, hexdump, keep alive, string functions, tailq, etc.
You might agree with me these are utilities that are not even used by EAL, therefor not really part of EAL.
Color would logically belong to librte_net, but librte_net currently depends on mbuf, which IMO is totally incorrect, as network protocols existed before DPD mbuf came into existence.
>
> > 2/ color enum in rte_meter.h: results in creating new librte_mbuf
> dependency to librte_meter
> > 3/ color enum in rte_mbuf.h: results in creating new librte_meter
> dependency to librte_mbuf (yes, currently librte_meter does not
> > depend on librte_mbuf)
>
> 4/ Keep color as uint8_t in rte_mbuf and 'move enum rte_color' definition
> and related functions in rte_meter.
Yes, 4/ is what we are implementing in V5.
>
> My preference is either 3) or 4).
> Konstantin
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
2018-12-17 18:51 ` Dumitrescu, Cristian
2018-12-17 23:11 ` Thomas Monjalon
@ 2018-12-18 10:15 ` Ananyev, Konstantin
2018-12-18 10:25 ` Pattan, Reshma
1 sibling, 1 reply; 74+ messages in thread
From: Ananyev, Konstantin @ 2018-12-18 10:15 UTC (permalink / raw)
To: Dumitrescu, Cristian, Pattan, Reshma, dev, jerin.jacob, Singh, Jasvinder
> -----Original Message-----
> From: Dumitrescu, Cristian
> Sent: Monday, December 17, 2018 6:51 PM
> To: Pattan, Reshma <reshma.pattan@intel.com>; Ananyev, Konstantin <konstantin.ananyev@intel.com>; dev@dpdk.org;
> jerin.jacob@caviumnetworks.com; Singh, Jasvinder <jasvinder.singh@intel.com>
> Subject: RE: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
>
>
>
> > -----Original Message-----
> > From: Pattan, Reshma
> > Sent: Monday, December 17, 2018 5:15 PM
> > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>; Dumitrescu,
> > Cristian <cristian.dumitrescu@intel.com>; dev@dpdk.org;
> > jerin.jacob@caviumnetworks.com; Singh, Jasvinder
> > <jasvinder.singh@intel.com>
> > Subject: RE: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
> >
> >
> >
> > > -----Original Message-----
> > > From: Ananyev, Konstantin
> > > Sent: Monday, December 17, 2018 11:21 AM
> > > To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Pattan, Reshma
> > > <reshma.pattan@intel.com>; dev@dpdk.org;
> > > jerin.jacob@caviumnetworks.com; Singh, Jasvinder
> > > <jasvinder.singh@intel.com>
> > > Cc: Pattan, Reshma <reshma.pattan@intel.com>
> > > Subject: RE: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Dumitrescu, Cristian
> > > > Sent: Saturday, December 15, 2018 12:16 AM
> > > > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>; Pattan,
> > Reshma
> > > > <reshma.pattan@intel.com>; dev@dpdk.org;
> > > > jerin.jacob@caviumnetworks.com; Singh, Jasvinder
> > > > <jasvinder.singh@intel.com>
> > > > Cc: Pattan, Reshma <reshma.pattan@intel.com>
> > > > Subject: RE: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color
> > > > definition
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Ananyev, Konstantin
> > > > > Sent: Friday, December 14, 2018 11:36 PM
> > > > > To: Pattan, Reshma <reshma.pattan@intel.com>; dev@dpdk.org;
> > > > > Dumitrescu, Cristian <cristian.dumitrescu@intel.com>;
> > > > > jerin.jacob@caviumnetworks.com; Singh, Jasvinder
> > > > > <jasvinder.singh@intel.com>
> > > > > Cc: Pattan, Reshma <reshma.pattan@intel.com>
> > > > > Subject: RE: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color
> > > > > definition
> > > > >
> > > > > Hi Reshma,
> > > > >
> > > > > > diff --git a/lib/librte_eal/common/include/rte_color.h
> > > > > b/lib/librte_eal/common/include/rte_color.h
> > > > > > new file mode 100644
> > > > > > index 000000000..f4387071b
> > > > > > --- /dev/null
> > > > > > +++ b/lib/librte_eal/common/include/rte_color.h
> > > > > > @@ -0,0 +1,18 @@
> > > > > > +/* SPDX-License-Identifier: BSD-3-Clause
> > > > > > + * Copyright(c) 2018 Intel Corporation */
> > > > > > +
> > > > > > +#ifndef _RTE_COLOR_H_
> > > > > > +#define _RTE_COLOR_H_
> > > > > > +
> > > > > > +/**
> > > > > > + * Color
> > > > > > + */
> > > > > > +enum rte_color {
> > > > > > + RTE_COLOR_GREEN = 0, /**< Green */
> > > > > > + RTE_COLOR_YELLOW, /**< Yellow */
> > > > > > + RTE_COLOR_RED, /**< Red */
> > > > > > + RTE_COLORS /**< Number of colors */ };
> > > > >
> > > > > Does it really belong to EAL?
> > > > > Konstantin
> > > > >
> > > >
> > > > Why not?
> > > >
> > > > It needs to be visible to multiple libraries: ethdev, meter, sched, as
> > > > well as drivers. We'd like to avoid adding more complexity to
> > dependencies
> > > between libraries.
> > > >
> > > > It is very generic. EAL common/include is currently the place to put
> > > > generic data structures, functions, algs, etc that are widely used by DPDK
> > > libraries. Lots of similar examples are easy to find in this folder.
> > >
> > > I don't think it is *that* generic to be in EAL.
> > > Yes it is used by few libs, ethdev and by softnic PMD,
> > > but it doesn't look as core dpdk thing to me.
> > >
> > > >
> > > > Where else would you put it?
> > >
> > > If it defines format of rte_mbuf fileds, then probably new .h inside
> > librte_mbuf is
> > > a good place.
> > > Other alternatives would be rte_ethdev or rte_net.
> >
> > After going through the lib/Makefile dependencies, I see we can have
> > rte_color.h in eal or mbuf library only.
> > Cannot keep it inside ethdev or net libraries because these two libraries
> > already have dependency on mbuf library, so cannot create loop
> > dependency.
> >
> > Snippet
> >
> > 1) DEPDIRS-librte_eal := librte_kvargs
> >
> > 2)DEPDIRS-librte_mbuf := librte_eal librte_mempool
> >
> > 3)DEPDIRS-librte_ethdev := librte_net librte_eal librte_mempool librte_ring
> > DEPDIRS-librte_ethdev += librte_mbuf
> > DEPDIRS-librte_ethdev += librte_kvargs
> > DEPDIRS-librte_ethdev += librte_cmdline
> >
> > 4) DEPDIRS-librte_net := librte_mbuf librte_eal
> >
> > 5) DEPDIRS-librte_meter := librte_eal
> >
> > Thanks,
> > Reshma
>
> Yes, I wound not mind to put this header file in librte_net, it makes sense to me. But librte_net depends on librte_mbuf, so then librte_net is
> not an option.
>
> The only two options are librte_eal and librte_mbuf. Between these two, my vote was librte_eal (as we already have plenty of similar items
> in librte_eal/common/include) instead of librte_mbuf, as to me the packet color is not related to how DPDK decides to pick its packet meta-
> data.
>
> To me, librte_eal/common/include is still the best option, but I guess I can live with librte_mbuf in case Konstantin has a hard opinion on it.
>
> What is your choice, Konstantin?
If to choose between EAL and mbuf - I would choose mbuf,
that what I stated in my previous mail, see above.
BTW, I probably missing something, but why rte_net is not an option?
What circular dependency you are talking about?
Konstantin
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
2018-12-18 10:15 ` Ananyev, Konstantin
@ 2018-12-18 10:25 ` Pattan, Reshma
2018-12-18 10:38 ` Ananyev, Konstantin
0 siblings, 1 reply; 74+ messages in thread
From: Pattan, Reshma @ 2018-12-18 10:25 UTC (permalink / raw)
To: Ananyev, Konstantin, Dumitrescu, Cristian, dev, jerin.jacob,
Singh, Jasvinder
> -----Original Message-----
> From: Ananyev, Konstantin
> Sent: Tuesday, December 18, 2018 10:15 AM
> To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Pattan, Reshma
> <reshma.pattan@intel.com>; dev@dpdk.org;
> jerin.jacob@caviumnetworks.com; Singh, Jasvinder
> <jasvinder.singh@intel.com>
> Subject: RE: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
>
>
>
> > -----Original Message-----
> > From: Dumitrescu, Cristian
> > Sent: Monday, December 17, 2018 6:51 PM
> > To: Pattan, Reshma <reshma.pattan@intel.com>; Ananyev, Konstantin
> > <konstantin.ananyev@intel.com>; dev@dpdk.org;
> > jerin.jacob@caviumnetworks.com; Singh, Jasvinder
> > <jasvinder.singh@intel.com>
> > Subject: RE: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color
> > definition
> >
> >
> >
> > > -----Original Message-----
> > > From: Pattan, Reshma
> > > Sent: Monday, December 17, 2018 5:15 PM
> > > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>; Dumitrescu,
> > > Cristian <cristian.dumitrescu@intel.com>; dev@dpdk.org;
> > > jerin.jacob@caviumnetworks.com; Singh, Jasvinder
> > > <jasvinder.singh@intel.com>
> > > Subject: RE: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color
> > > definition
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Ananyev, Konstantin
> > > > Sent: Monday, December 17, 2018 11:21 AM
> > > > To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Pattan,
> > > > Reshma <reshma.pattan@intel.com>; dev@dpdk.org;
> > > > jerin.jacob@caviumnetworks.com; Singh, Jasvinder
> > > > <jasvinder.singh@intel.com>
> > > > Cc: Pattan, Reshma <reshma.pattan@intel.com>
> > > > Subject: RE: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color
> > > > definition
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Dumitrescu, Cristian
> > > > > Sent: Saturday, December 15, 2018 12:16 AM
> > > > > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>; Pattan,
> > > Reshma
> > > > > <reshma.pattan@intel.com>; dev@dpdk.org;
> > > > > jerin.jacob@caviumnetworks.com; Singh, Jasvinder
> > > > > <jasvinder.singh@intel.com>
> > > > > Cc: Pattan, Reshma <reshma.pattan@intel.com>
> > > > > Subject: RE: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color
> > > > > definition
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Ananyev, Konstantin
> > > > > > Sent: Friday, December 14, 2018 11:36 PM
> > > > > > To: Pattan, Reshma <reshma.pattan@intel.com>; dev@dpdk.org;
> > > > > > Dumitrescu, Cristian <cristian.dumitrescu@intel.com>;
> > > > > > jerin.jacob@caviumnetworks.com; Singh, Jasvinder
> > > > > > <jasvinder.singh@intel.com>
> > > > > > Cc: Pattan, Reshma <reshma.pattan@intel.com>
> > > > > > Subject: RE: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color
> > > > > > definition
> > > > > >
> > > > > > Hi Reshma,
> > > > > >
> > > > > > > diff --git a/lib/librte_eal/common/include/rte_color.h
> > > > > > b/lib/librte_eal/common/include/rte_color.h
> > > > > > > new file mode 100644
> > > > > > > index 000000000..f4387071b
> > > > > > > --- /dev/null
> > > > > > > +++ b/lib/librte_eal/common/include/rte_color.h
> > > > > > > @@ -0,0 +1,18 @@
> > > > > > > +/* SPDX-License-Identifier: BSD-3-Clause
> > > > > > > + * Copyright(c) 2018 Intel Corporation */
> > > > > > > +
> > > > > > > +#ifndef _RTE_COLOR_H_
> > > > > > > +#define _RTE_COLOR_H_
> > > > > > > +
> > > > > > > +/**
> > > > > > > + * Color
> > > > > > > + */
> > > > > > > +enum rte_color {
> > > > > > > + RTE_COLOR_GREEN = 0, /**< Green */
> > > > > > > + RTE_COLOR_YELLOW, /**< Yellow */
> > > > > > > + RTE_COLOR_RED, /**< Red */
> > > > > > > + RTE_COLORS /**< Number of colors */ };
> > > > > >
> > > > > > Does it really belong to EAL?
> > > > > > Konstantin
> > > > > >
> > > > >
> > > > > Why not?
> > > > >
> > > > > It needs to be visible to multiple libraries: ethdev, meter,
> > > > > sched, as well as drivers. We'd like to avoid adding more
> > > > > complexity to
> > > dependencies
> > > > between libraries.
> > > > >
> > > > > It is very generic. EAL common/include is currently the place to
> > > > > put generic data structures, functions, algs, etc that are
> > > > > widely used by DPDK
> > > > libraries. Lots of similar examples are easy to find in this folder.
> > > >
> > > > I don't think it is *that* generic to be in EAL.
> > > > Yes it is used by few libs, ethdev and by softnic PMD, but it
> > > > doesn't look as core dpdk thing to me.
> > > >
> > > > >
> > > > > Where else would you put it?
> > > >
> > > > If it defines format of rte_mbuf fileds, then probably new .h
> > > > inside
> > > librte_mbuf is
> > > > a good place.
> > > > Other alternatives would be rte_ethdev or rte_net.
> > >
> > > After going through the lib/Makefile dependencies, I see we can have
> > > rte_color.h in eal or mbuf library only.
> > > Cannot keep it inside ethdev or net libraries because these two
> > > libraries already have dependency on mbuf library, so cannot create
> > > loop dependency.
> > >
> > > Snippet
> > >
> > > 1) DEPDIRS-librte_eal := librte_kvargs
> > >
> > > 2)DEPDIRS-librte_mbuf := librte_eal librte_mempool
> > >
> > > 3)DEPDIRS-librte_ethdev := librte_net librte_eal librte_mempool
> > > librte_ring DEPDIRS-librte_ethdev += librte_mbuf
> > > DEPDIRS-librte_ethdev += librte_kvargs DEPDIRS-librte_ethdev +=
> > > librte_cmdline
> > >
> > > 4) DEPDIRS-librte_net := librte_mbuf librte_eal
> > >
> > > 5) DEPDIRS-librte_meter := librte_eal
> > >
> > > Thanks,
> > > Reshma
> >
> > Yes, I wound not mind to put this header file in librte_net, it makes
> > sense to me. But librte_net depends on librte_mbuf, so then librte_net is not
> an option.
> >
> > The only two options are librte_eal and librte_mbuf. Between these
> > two, my vote was librte_eal (as we already have plenty of similar
> > items in librte_eal/common/include) instead of librte_mbuf, as to me the
> packet color is not related to how DPDK decides to pick its packet meta- data.
> >
> > To me, librte_eal/common/include is still the best option, but I guess I can live
> with librte_mbuf in case Konstantin has a hard opinion on it.
> >
> > What is your choice, Konstantin?
>
> If to choose between EAL and mbuf - I would choose mbuf, that what I stated in
> my previous mail, see above.
> BTW, I probably missing something, but why rte_net is not an option?
> What circular dependency you are talking about?
> Konstantin
>
Since librte_net has mbuf in its dependent list as below from lib/Makefile.
i.e. DEPDIRS-librte_net := librte_mbuf librte_eal
So now, If we move rte_color.h to librte_net, then need to add librte_net to mbuf dependency list(as we are using rte_color.h in rte_mbuf.h)
Current mbuf dependency list is
DEPDIRS-librte_mbuf := librte_eal librte_mempool
The new will be
DEPDIRS-librte_mbuf := librte_eal librte_mempool librte_net
So this will create circular dependency, I think this is not allowed in DPDK right?
If my understanding is correct, librte_net is not the correct place. Please clarify.
Thanks,
Reshma
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
2018-12-18 10:25 ` Pattan, Reshma
@ 2018-12-18 10:38 ` Ananyev, Konstantin
2018-12-18 10:41 ` Pattan, Reshma
0 siblings, 1 reply; 74+ messages in thread
From: Ananyev, Konstantin @ 2018-12-18 10:38 UTC (permalink / raw)
To: Pattan, Reshma, Dumitrescu, Cristian, dev, jerin.jacob, Singh, Jasvinder
Hi Reshma,
> > > > > > > > diff --git a/lib/librte_eal/common/include/rte_color.h
> > > > > > > b/lib/librte_eal/common/include/rte_color.h
> > > > > > > > new file mode 100644
> > > > > > > > index 000000000..f4387071b
> > > > > > > > --- /dev/null
> > > > > > > > +++ b/lib/librte_eal/common/include/rte_color.h
> > > > > > > > @@ -0,0 +1,18 @@
> > > > > > > > +/* SPDX-License-Identifier: BSD-3-Clause
> > > > > > > > + * Copyright(c) 2018 Intel Corporation */
> > > > > > > > +
> > > > > > > > +#ifndef _RTE_COLOR_H_
> > > > > > > > +#define _RTE_COLOR_H_
> > > > > > > > +
> > > > > > > > +/**
> > > > > > > > + * Color
> > > > > > > > + */
> > > > > > > > +enum rte_color {
> > > > > > > > + RTE_COLOR_GREEN = 0, /**< Green */
> > > > > > > > + RTE_COLOR_YELLOW, /**< Yellow */
> > > > > > > > + RTE_COLOR_RED, /**< Red */
> > > > > > > > + RTE_COLORS /**< Number of colors */ };
> > > > > > >
> > > > > > > Does it really belong to EAL?
> > > > > > > Konstantin
> > > > > > >
> > > > > >
> > > > > > Why not?
> > > > > >
> > > > > > It needs to be visible to multiple libraries: ethdev, meter,
> > > > > > sched, as well as drivers. We'd like to avoid adding more
> > > > > > complexity to
> > > > dependencies
> > > > > between libraries.
> > > > > >
> > > > > > It is very generic. EAL common/include is currently the place to
> > > > > > put generic data structures, functions, algs, etc that are
> > > > > > widely used by DPDK
> > > > > libraries. Lots of similar examples are easy to find in this folder.
> > > > >
> > > > > I don't think it is *that* generic to be in EAL.
> > > > > Yes it is used by few libs, ethdev and by softnic PMD, but it
> > > > > doesn't look as core dpdk thing to me.
> > > > >
> > > > > >
> > > > > > Where else would you put it?
> > > > >
> > > > > If it defines format of rte_mbuf fileds, then probably new .h
> > > > > inside
> > > > librte_mbuf is
> > > > > a good place.
> > > > > Other alternatives would be rte_ethdev or rte_net.
> > > >
> > > > After going through the lib/Makefile dependencies, I see we can have
> > > > rte_color.h in eal or mbuf library only.
> > > > Cannot keep it inside ethdev or net libraries because these two
> > > > libraries already have dependency on mbuf library, so cannot create
> > > > loop dependency.
> > > >
> > > > Snippet
> > > >
> > > > 1) DEPDIRS-librte_eal := librte_kvargs
> > > >
> > > > 2)DEPDIRS-librte_mbuf := librte_eal librte_mempool
> > > >
> > > > 3)DEPDIRS-librte_ethdev := librte_net librte_eal librte_mempool
> > > > librte_ring DEPDIRS-librte_ethdev += librte_mbuf
> > > > DEPDIRS-librte_ethdev += librte_kvargs DEPDIRS-librte_ethdev +=
> > > > librte_cmdline
> > > >
> > > > 4) DEPDIRS-librte_net := librte_mbuf librte_eal
> > > >
> > > > 5) DEPDIRS-librte_meter := librte_eal
> > > >
> > > > Thanks,
> > > > Reshma
> > >
> > > Yes, I wound not mind to put this header file in librte_net, it makes
> > > sense to me. But librte_net depends on librte_mbuf, so then librte_net is not
> > an option.
> > >
> > > The only two options are librte_eal and librte_mbuf. Between these
> > > two, my vote was librte_eal (as we already have plenty of similar
> > > items in librte_eal/common/include) instead of librte_mbuf, as to me the
> > packet color is not related to how DPDK decides to pick its packet meta- data.
> > >
> > > To me, librte_eal/common/include is still the best option, but I guess I can live
> > with librte_mbuf in case Konstantin has a hard opinion on it.
> > >
> > > What is your choice, Konstantin?
> >
> > If to choose between EAL and mbuf - I would choose mbuf, that what I stated in
> > my previous mail, see above.
> > BTW, I probably missing something, but why rte_net is not an option?
> > What circular dependency you are talking about?
> > Konstantin
> >
>
> Since librte_net has mbuf in its dependent list as below from lib/Makefile.
> i.e. DEPDIRS-librte_net := librte_mbuf librte_eal
>
> So now, If we move rte_color.h to librte_net, then need to add librte_net to mbuf dependency list(as we are using rte_color.h in
> rte_mbuf.h)
>
> Current mbuf dependency list is
> DEPDIRS-librte_mbuf := librte_eal librte_mempool
>
> The new will be
> DEPDIRS-librte_mbuf := librte_eal librte_mempool librte_net
>
> So this will create circular dependency, I think this is not allowed in DPDK right?
I understand that part, but why rte_color definitions have to be visible by rte_mbuf?
Do you refer it in rte_mbuf functions?
Konstantin
>
> If my understanding is correct, librte_net is not the correct place. Please clarify.
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
2018-12-18 10:38 ` Ananyev, Konstantin
@ 2018-12-18 10:41 ` Pattan, Reshma
2018-12-18 10:52 ` Singh, Jasvinder
0 siblings, 1 reply; 74+ messages in thread
From: Pattan, Reshma @ 2018-12-18 10:41 UTC (permalink / raw)
To: Ananyev, Konstantin, Dumitrescu, Cristian, dev, jerin.jacob,
Singh, Jasvinder
Hi,
> -----Original Message-----
> From: Ananyev, Konstantin
> Sent: Tuesday, December 18, 2018 10:38 AM
> To: Pattan, Reshma <reshma.pattan@intel.com>; Dumitrescu, Cristian
> <cristian.dumitrescu@intel.com>; dev@dpdk.org;
> jerin.jacob@caviumnetworks.com; Singh, Jasvinder
> <jasvinder.singh@intel.com>
> Subject: RE: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
>
> Hi Reshma,
>
> > > > > > > > > diff --git a/lib/librte_eal/common/include/rte_color.h
> > > > > > > > b/lib/librte_eal/common/include/rte_color.h
> > > > > > > > > new file mode 100644
> > > > > > > > > index 000000000..f4387071b
> > > > > > > > > --- /dev/null
> > > > > > > > > +++ b/lib/librte_eal/common/include/rte_color.h
> > > > > > > > > @@ -0,0 +1,18 @@
> > > > > > > > > +/* SPDX-License-Identifier: BSD-3-Clause
> > > > > > > > > + * Copyright(c) 2018 Intel Corporation */
> > > > > > > > > +
> > > > > > > > > +#ifndef _RTE_COLOR_H_
> > > > > > > > > +#define _RTE_COLOR_H_
> > > > > > > > > +
> > > > > > > > > +/**
> > > > > > > > > + * Color
> > > > > > > > > + */
> > > > > > > > > +enum rte_color {
> > > > > > > > > + RTE_COLOR_GREEN = 0, /**< Green */
> > > > > > > > > + RTE_COLOR_YELLOW, /**< Yellow */
> > > > > > > > > + RTE_COLOR_RED, /**< Red */
> > > > > > > > > + RTE_COLORS /**< Number of colors */ };
> > > > > > > >
> > > > > > > > Does it really belong to EAL?
> > > > > > > > Konstantin
> > > > > > > >
> > > > > > >
> > > > > > > Why not?
> > > > > > >
> > > > > > > It needs to be visible to multiple libraries: ethdev, meter,
> > > > > > > sched, as well as drivers. We'd like to avoid adding more
> > > > > > > complexity to
> > > > > dependencies
> > > > > > between libraries.
> > > > > > >
> > > > > > > It is very generic. EAL common/include is currently the
> > > > > > > place to put generic data structures, functions, algs, etc
> > > > > > > that are widely used by DPDK
> > > > > > libraries. Lots of similar examples are easy to find in this folder.
> > > > > >
> > > > > > I don't think it is *that* generic to be in EAL.
> > > > > > Yes it is used by few libs, ethdev and by softnic PMD, but it
> > > > > > doesn't look as core dpdk thing to me.
> > > > > >
> > > > > > >
> > > > > > > Where else would you put it?
> > > > > >
> > > > > > If it defines format of rte_mbuf fileds, then probably new .h
> > > > > > inside
> > > > > librte_mbuf is
> > > > > > a good place.
> > > > > > Other alternatives would be rte_ethdev or rte_net.
> > > > >
> > > > > After going through the lib/Makefile dependencies, I see we can
> > > > > have rte_color.h in eal or mbuf library only.
> > > > > Cannot keep it inside ethdev or net libraries because these two
> > > > > libraries already have dependency on mbuf library, so cannot
> > > > > create loop dependency.
> > > > >
> > > > > Snippet
> > > > >
> > > > > 1) DEPDIRS-librte_eal := librte_kvargs
> > > > >
> > > > > 2)DEPDIRS-librte_mbuf := librte_eal librte_mempool
> > > > >
> > > > > 3)DEPDIRS-librte_ethdev := librte_net librte_eal librte_mempool
> > > > > librte_ring DEPDIRS-librte_ethdev += librte_mbuf
> > > > > DEPDIRS-librte_ethdev += librte_kvargs DEPDIRS-librte_ethdev +=
> > > > > librte_cmdline
> > > > >
> > > > > 4) DEPDIRS-librte_net := librte_mbuf librte_eal
> > > > >
> > > > > 5) DEPDIRS-librte_meter := librte_eal
> > > > >
> > > > > Thanks,
> > > > > Reshma
> > > >
> > > > Yes, I wound not mind to put this header file in librte_net, it
> > > > makes sense to me. But librte_net depends on librte_mbuf, so then
> > > > librte_net is not
> > > an option.
> > > >
> > > > The only two options are librte_eal and librte_mbuf. Between these
> > > > two, my vote was librte_eal (as we already have plenty of similar
> > > > items in librte_eal/common/include) instead of librte_mbuf, as to
> > > > me the
> > > packet color is not related to how DPDK decides to pick its packet meta-
> data.
> > > >
> > > > To me, librte_eal/common/include is still the best option, but I
> > > > guess I can live
> > > with librte_mbuf in case Konstantin has a hard opinion on it.
> > > >
> > > > What is your choice, Konstantin?
> > >
> > > If to choose between EAL and mbuf - I would choose mbuf, that what I
> > > stated in my previous mail, see above.
> > > BTW, I probably missing something, but why rte_net is not an option?
> > > What circular dependency you are talking about?
> > > Konstantin
> > >
> >
> > Since librte_net has mbuf in its dependent list as below from lib/Makefile.
> > i.e. DEPDIRS-librte_net := librte_mbuf librte_eal
> >
> > So now, If we move rte_color.h to librte_net, then need to add
> > librte_net to mbuf dependency list(as we are using rte_color.h in
> > rte_mbuf.h)
> >
> > Current mbuf dependency list is
> > DEPDIRS-librte_mbuf := librte_eal librte_mempool
> >
> > The new will be
> > DEPDIRS-librte_mbuf := librte_eal librte_mempool librte_net
> >
> > So this will create circular dependency, I think this is not allowed in DPDK right?
>
> I understand that part, but why rte_color definitions have to be visible by
> rte_mbuf?
> Do you refer it in rte_mbuf functions?
Oh yes, in 2nd patch of this patchset we have added new set/get functions in librte_mbuf, there ,we are referring the rte_color.
I am sorry I would have been more explicit in my earlier mail.
Thanks,
Reshma
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
2018-12-18 10:41 ` Pattan, Reshma
@ 2018-12-18 10:52 ` Singh, Jasvinder
2018-12-18 12:10 ` Ananyev, Konstantin
0 siblings, 1 reply; 74+ messages in thread
From: Singh, Jasvinder @ 2018-12-18 10:52 UTC (permalink / raw)
To: Pattan, Reshma, Ananyev, Konstantin, Dumitrescu, Cristian, dev,
jerin.jacob
> -----Original Message-----
> From: Pattan, Reshma
> Sent: Tuesday, December 18, 2018 10:41 AM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>; Dumitrescu, Cristian
> <cristian.dumitrescu@intel.com>; dev@dpdk.org;
> jerin.jacob@caviumnetworks.com; Singh, Jasvinder
> <jasvinder.singh@intel.com>
> Subject: RE: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
>
> Hi,
>
> > -----Original Message-----
> > From: Ananyev, Konstantin
> > Sent: Tuesday, December 18, 2018 10:38 AM
> > To: Pattan, Reshma <reshma.pattan@intel.com>; Dumitrescu, Cristian
> > <cristian.dumitrescu@intel.com>; dev@dpdk.org;
> > jerin.jacob@caviumnetworks.com; Singh, Jasvinder
> > <jasvinder.singh@intel.com>
> > Subject: RE: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color
> > definition
> >
> > Hi Reshma,
> >
> > > > > > > > > > diff --git a/lib/librte_eal/common/include/rte_color.h
> > > > > > > > > b/lib/librte_eal/common/include/rte_color.h
> > > > > > > > > > new file mode 100644
> > > > > > > > > > index 000000000..f4387071b
> > > > > > > > > > --- /dev/null
> > > > > > > > > > +++ b/lib/librte_eal/common/include/rte_color.h
> > > > > > > > > > @@ -0,0 +1,18 @@
> > > > > > > > > > +/* SPDX-License-Identifier: BSD-3-Clause
> > > > > > > > > > + * Copyright(c) 2018 Intel Corporation */
> > > > > > > > > > +
> > > > > > > > > > +#ifndef _RTE_COLOR_H_ #define _RTE_COLOR_H_
> > > > > > > > > > +
> > > > > > > > > > +/**
> > > > > > > > > > + * Color
> > > > > > > > > > + */
> > > > > > > > > > +enum rte_color {
> > > > > > > > > > + RTE_COLOR_GREEN = 0, /**< Green */
> > > > > > > > > > + RTE_COLOR_YELLOW, /**< Yellow */
> > > > > > > > > > + RTE_COLOR_RED, /**< Red */
> > > > > > > > > > + RTE_COLORS /**< Number of colors */ };
> > > > > > > > >
> > > > > > > > > Does it really belong to EAL?
> > > > > > > > > Konstantin
> > > > > > > > >
> > > > > > > >
> > > > > > > > Why not?
> > > > > > > >
> > > > > > > > It needs to be visible to multiple libraries: ethdev,
> > > > > > > > meter, sched, as well as drivers. We'd like to avoid
> > > > > > > > adding more complexity to
> > > > > > dependencies
> > > > > > > between libraries.
> > > > > > > >
> > > > > > > > It is very generic. EAL common/include is currently the
> > > > > > > > place to put generic data structures, functions, algs, etc
> > > > > > > > that are widely used by DPDK
> > > > > > > libraries. Lots of similar examples are easy to find in this folder.
> > > > > > >
> > > > > > > I don't think it is *that* generic to be in EAL.
> > > > > > > Yes it is used by few libs, ethdev and by softnic PMD, but
> > > > > > > it doesn't look as core dpdk thing to me.
> > > > > > >
> > > > > > > >
> > > > > > > > Where else would you put it?
> > > > > > >
> > > > > > > If it defines format of rte_mbuf fileds, then probably new
> > > > > > > .h inside
> > > > > > librte_mbuf is
> > > > > > > a good place.
> > > > > > > Other alternatives would be rte_ethdev or rte_net.
> > > > > >
> > > > > > After going through the lib/Makefile dependencies, I see we
> > > > > > can have rte_color.h in eal or mbuf library only.
> > > > > > Cannot keep it inside ethdev or net libraries because these
> > > > > > two libraries already have dependency on mbuf library, so
> > > > > > cannot create loop dependency.
> > > > > >
> > > > > > Snippet
> > > > > >
> > > > > > 1) DEPDIRS-librte_eal := librte_kvargs
> > > > > >
> > > > > > 2)DEPDIRS-librte_mbuf := librte_eal librte_mempool
> > > > > >
> > > > > > 3)DEPDIRS-librte_ethdev := librte_net librte_eal
> > > > > > librte_mempool librte_ring DEPDIRS-librte_ethdev +=
> > > > > > librte_mbuf DEPDIRS-librte_ethdev += librte_kvargs
> > > > > > DEPDIRS-librte_ethdev += librte_cmdline
> > > > > >
> > > > > > 4) DEPDIRS-librte_net := librte_mbuf librte_eal
> > > > > >
> > > > > > 5) DEPDIRS-librte_meter := librte_eal
> > > > > >
> > > > > > Thanks,
> > > > > > Reshma
> > > > >
> > > > > Yes, I wound not mind to put this header file in librte_net, it
> > > > > makes sense to me. But librte_net depends on librte_mbuf, so
> > > > > then librte_net is not
> > > > an option.
> > > > >
> > > > > The only two options are librte_eal and librte_mbuf. Between
> > > > > these two, my vote was librte_eal (as we already have plenty of
> > > > > similar items in librte_eal/common/include) instead of
> > > > > librte_mbuf, as to me the
> > > > packet color is not related to how DPDK decides to pick its packet
> > > > meta-
> > data.
> > > > >
> > > > > To me, librte_eal/common/include is still the best option, but I
> > > > > guess I can live
> > > > with librte_mbuf in case Konstantin has a hard opinion on it.
> > > > >
> > > > > What is your choice, Konstantin?
> > > >
> > > > If to choose between EAL and mbuf - I would choose mbuf, that what
> > > > I stated in my previous mail, see above.
> > > > BTW, I probably missing something, but why rte_net is not an option?
> > > > What circular dependency you are talking about?
> > > > Konstantin
> > > >
> > >
> > > Since librte_net has mbuf in its dependent list as below from lib/Makefile.
> > > i.e. DEPDIRS-librte_net := librte_mbuf librte_eal
> > >
> > > So now, If we move rte_color.h to librte_net, then need to add
> > > librte_net to mbuf dependency list(as we are using rte_color.h in
> > > rte_mbuf.h)
> > >
> > > Current mbuf dependency list is
> > > DEPDIRS-librte_mbuf := librte_eal librte_mempool
> > >
> > > The new will be
> > > DEPDIRS-librte_mbuf := librte_eal librte_mempool librte_net
> > >
> > > So this will create circular dependency, I think this is not allowed in DPDK
> right?
> >
> > I understand that part, but why rte_color definitions have to be
> > visible by rte_mbuf?
> > Do you refer it in rte_mbuf functions?
>
>
> Oh yes, in 2nd patch of this patchset we have added new set/get functions in
> librte_mbuf, there ,we are referring the rte_color.
> I am sorry I would have been more explicit in my earlier mail.
>
I guess Reshma is referring to 2nd patch of the v3 version which is the latest version of this series.
Patchwork: https://patches.dpdk.org/patch/48788/
Mail list: https://mails.dpdk.org/archives/dev/2018-December/120848.html
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
2018-12-18 10:52 ` Singh, Jasvinder
@ 2018-12-18 12:10 ` Ananyev, Konstantin
0 siblings, 0 replies; 74+ messages in thread
From: Ananyev, Konstantin @ 2018-12-18 12:10 UTC (permalink / raw)
To: Singh, Jasvinder, Pattan, Reshma, Dumitrescu, Cristian, dev, jerin.jacob
> > > > > > > > > > > diff --git a/lib/librte_eal/common/include/rte_color.h
> > > > > > > > > > b/lib/librte_eal/common/include/rte_color.h
> > > > > > > > > > > new file mode 100644
> > > > > > > > > > > index 000000000..f4387071b
> > > > > > > > > > > --- /dev/null
> > > > > > > > > > > +++ b/lib/librte_eal/common/include/rte_color.h
> > > > > > > > > > > @@ -0,0 +1,18 @@
> > > > > > > > > > > +/* SPDX-License-Identifier: BSD-3-Clause
> > > > > > > > > > > + * Copyright(c) 2018 Intel Corporation */
> > > > > > > > > > > +
> > > > > > > > > > > +#ifndef _RTE_COLOR_H_ #define _RTE_COLOR_H_
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * Color
> > > > > > > > > > > + */
> > > > > > > > > > > +enum rte_color {
> > > > > > > > > > > + RTE_COLOR_GREEN = 0, /**< Green */
> > > > > > > > > > > + RTE_COLOR_YELLOW, /**< Yellow */
> > > > > > > > > > > + RTE_COLOR_RED, /**< Red */
> > > > > > > > > > > + RTE_COLORS /**< Number of colors */ };
> > > > > > > > > >
> > > > > > > > > > Does it really belong to EAL?
> > > > > > > > > > Konstantin
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Why not?
> > > > > > > > >
> > > > > > > > > It needs to be visible to multiple libraries: ethdev,
> > > > > > > > > meter, sched, as well as drivers. We'd like to avoid
> > > > > > > > > adding more complexity to
> > > > > > > dependencies
> > > > > > > > between libraries.
> > > > > > > > >
> > > > > > > > > It is very generic. EAL common/include is currently the
> > > > > > > > > place to put generic data structures, functions, algs, etc
> > > > > > > > > that are widely used by DPDK
> > > > > > > > libraries. Lots of similar examples are easy to find in this folder.
> > > > > > > >
> > > > > > > > I don't think it is *that* generic to be in EAL.
> > > > > > > > Yes it is used by few libs, ethdev and by softnic PMD, but
> > > > > > > > it doesn't look as core dpdk thing to me.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Where else would you put it?
> > > > > > > >
> > > > > > > > If it defines format of rte_mbuf fileds, then probably new
> > > > > > > > .h inside
> > > > > > > librte_mbuf is
> > > > > > > > a good place.
> > > > > > > > Other alternatives would be rte_ethdev or rte_net.
> > > > > > >
> > > > > > > After going through the lib/Makefile dependencies, I see we
> > > > > > > can have rte_color.h in eal or mbuf library only.
> > > > > > > Cannot keep it inside ethdev or net libraries because these
> > > > > > > two libraries already have dependency on mbuf library, so
> > > > > > > cannot create loop dependency.
> > > > > > >
> > > > > > > Snippet
> > > > > > >
> > > > > > > 1) DEPDIRS-librte_eal := librte_kvargs
> > > > > > >
> > > > > > > 2)DEPDIRS-librte_mbuf := librte_eal librte_mempool
> > > > > > >
> > > > > > > 3)DEPDIRS-librte_ethdev := librte_net librte_eal
> > > > > > > librte_mempool librte_ring DEPDIRS-librte_ethdev +=
> > > > > > > librte_mbuf DEPDIRS-librte_ethdev += librte_kvargs
> > > > > > > DEPDIRS-librte_ethdev += librte_cmdline
> > > > > > >
> > > > > > > 4) DEPDIRS-librte_net := librte_mbuf librte_eal
> > > > > > >
> > > > > > > 5) DEPDIRS-librte_meter := librte_eal
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Reshma
> > > > > >
> > > > > > Yes, I wound not mind to put this header file in librte_net, it
> > > > > > makes sense to me. But librte_net depends on librte_mbuf, so
> > > > > > then librte_net is not
> > > > > an option.
> > > > > >
> > > > > > The only two options are librte_eal and librte_mbuf. Between
> > > > > > these two, my vote was librte_eal (as we already have plenty of
> > > > > > similar items in librte_eal/common/include) instead of
> > > > > > librte_mbuf, as to me the
> > > > > packet color is not related to how DPDK decides to pick its packet
> > > > > meta-
> > > data.
> > > > > >
> > > > > > To me, librte_eal/common/include is still the best option, but I
> > > > > > guess I can live
> > > > > with librte_mbuf in case Konstantin has a hard opinion on it.
> > > > > >
> > > > > > What is your choice, Konstantin?
> > > > >
> > > > > If to choose between EAL and mbuf - I would choose mbuf, that what
> > > > > I stated in my previous mail, see above.
> > > > > BTW, I probably missing something, but why rte_net is not an option?
> > > > > What circular dependency you are talking about?
> > > > > Konstantin
> > > > >
> > > >
> > > > Since librte_net has mbuf in its dependent list as below from lib/Makefile.
> > > > i.e. DEPDIRS-librte_net := librte_mbuf librte_eal
> > > >
> > > > So now, If we move rte_color.h to librte_net, then need to add
> > > > librte_net to mbuf dependency list(as we are using rte_color.h in
> > > > rte_mbuf.h)
> > > >
> > > > Current mbuf dependency list is
> > > > DEPDIRS-librte_mbuf := librte_eal librte_mempool
> > > >
> > > > The new will be
> > > > DEPDIRS-librte_mbuf := librte_eal librte_mempool librte_net
> > > >
> > > > So this will create circular dependency, I think this is not allowed in DPDK
> > right?
> > >
> > > I understand that part, but why rte_color definitions have to be
> > > visible by rte_mbuf?
> > > Do you refer it in rte_mbuf functions?
> >
> >
> > Oh yes, in 2nd patch of this patchset we have added new set/get functions in
> > librte_mbuf, there ,we are referring the rte_color.
> > I am sorry I would have been more explicit in my earlier mail.
> >
>
> I guess Reshma is referring to 2nd patch of the v3 version which is the latest version of this series.
> Patchwork: https://patches.dpdk.org/patch/48788/
> Mail list: https://mails.dpdk.org/archives/dev/2018-December/120848.html
>
Thanks for clarification.
In theory inside mbuf color is just uint8_t, so I think you can keep mrte_mbuf.h as it is,
and have rte_color and realted function definitions in different place (rte_net/rte_meter).
Another possible option is to create a new .h file inside librte_mbuf (rte_mbuf_meter.h or so),
put related struct/enum/function definitions into it and include it from rte_mbuf.h
Konstantin
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
2018-12-14 23:35 ` Ananyev, Konstantin
2018-12-15 0:16 ` Dumitrescu, Cristian
@ 2018-12-15 14:15 ` Mattias Rönnblom
2018-12-17 7:27 ` Pattan, Reshma
2018-12-17 9:41 ` Dumitrescu, Cristian
1 sibling, 2 replies; 74+ messages in thread
From: Mattias Rönnblom @ 2018-12-15 14:15 UTC (permalink / raw)
To: Ananyev, Konstantin, Pattan, Reshma, dev, Dumitrescu, Cristian,
jerin.jacob, Singh, Jasvinder
On 2018-12-15 00:35, Ananyev, Konstantin wrote:
> Hi Reshma,
>
>> diff --git a/lib/librte_eal/common/include/rte_color.h b/lib/librte_eal/common/include/rte_color.h
>> new file mode 100644
>> index 000000000..f4387071b
>> --- /dev/null
>> +++ b/lib/librte_eal/common/include/rte_color.h
>> @@ -0,0 +1,18 @@
>> +/* SPDX-License-Identifier: BSD-3-Clause
>> + * Copyright(c) 2018 Intel Corporation
>> + */
>> +
>> +#ifndef _RTE_COLOR_H_
>> +#define _RTE_COLOR_H_
>> +
>> +/**
>> + * Color
>> + */
>> +enum rte_color {
>> + RTE_COLOR_GREEN = 0, /**< Green */
>> + RTE_COLOR_YELLOW, /**< Yellow */
>> + RTE_COLOR_RED, /**< Red */
>> + RTE_COLORS /**< Number of colors */
>> +};
>
> Does it really belong to EAL?
> Konstantin
>
If this is supposed to be a generic type, we definitely need
RTE_COLOR_BLACK as well, or RTE_COLOR_VERY_VERY_DARK_GREY.
/Batman
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
2018-12-15 14:15 ` Mattias Rönnblom
@ 2018-12-17 7:27 ` Pattan, Reshma
2018-12-17 9:41 ` Dumitrescu, Cristian
1 sibling, 0 replies; 74+ messages in thread
From: Pattan, Reshma @ 2018-12-17 7:27 UTC (permalink / raw)
To: Mattias Rönnblom, Ananyev, Konstantin, dev, Dumitrescu,
Cristian, jerin.jacob, Singh, Jasvinder
> -----Original Message-----
> From: Mattias Rönnblom [mailto:mattias.ronnblom@ericsson.com]
> Sent: Saturday, December 15, 2018 2:16 PM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>; Pattan, Reshma
> <reshma.pattan@intel.com>; dev@dpdk.org; Dumitrescu, Cristian
> <cristian.dumitrescu@intel.com>; jerin.jacob@caviumnetworks.com; Singh,
> Jasvinder <jasvinder.singh@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
>
> On 2018-12-15 00:35, Ananyev, Konstantin wrote:
> > Hi Reshma,
> >
> >> diff --git a/lib/librte_eal/common/include/rte_color.h
> >> b/lib/librte_eal/common/include/rte_color.h
> >> new file mode 100644
> >> index 000000000..f4387071b
> >> --- /dev/null
> >> +++ b/lib/librte_eal/common/include/rte_color.h
> >> @@ -0,0 +1,18 @@
> >> +/* SPDX-License-Identifier: BSD-3-Clause
> >> + * Copyright(c) 2018 Intel Corporation */
> >> +
> >> +#ifndef _RTE_COLOR_H_
> >> +#define _RTE_COLOR_H_
> >> +
> >> +/**
> >> + * Color
> >> + */
> >> +enum rte_color {
> >> + RTE_COLOR_GREEN = 0, /**< Green */
> >> + RTE_COLOR_YELLOW, /**< Yellow */
> >> + RTE_COLOR_RED, /**< Red */
> >> + RTE_COLORS /**< Number of colors */ };
> >
> > Does it really belong to EAL?
> > Konstantin
> >
>
> If this is supposed to be a generic type, we definitely need RTE_COLOR_BLACK
> as well, or RTE_COLOR_VERY_VERY_DARK_GREY.
>
Ok, I can add RTE_COLOR_BLACK after RTE_COLOR_RED now.
Thanks,
Reshma
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
2018-12-15 14:15 ` Mattias Rönnblom
2018-12-17 7:27 ` Pattan, Reshma
@ 2018-12-17 9:41 ` Dumitrescu, Cristian
2018-12-17 19:36 ` Mattias Rönnblom
1 sibling, 1 reply; 74+ messages in thread
From: Dumitrescu, Cristian @ 2018-12-17 9:41 UTC (permalink / raw)
To: Mattias Rönnblom, Ananyev, Konstantin, Pattan, Reshma, dev,
jerin.jacob, Singh, Jasvinder
> -----Original Message-----
> From: Mattias Rönnblom [mailto:mattias.ronnblom@ericsson.com]
> Sent: Saturday, December 15, 2018 2:16 PM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>; Pattan, Reshma
> <reshma.pattan@intel.com>; dev@dpdk.org; Dumitrescu, Cristian
> <cristian.dumitrescu@intel.com>; jerin.jacob@caviumnetworks.com; Singh,
> Jasvinder <jasvinder.singh@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
>
> On 2018-12-15 00:35, Ananyev, Konstantin wrote:
> > Hi Reshma,
> >
> >> diff --git a/lib/librte_eal/common/include/rte_color.h
> b/lib/librte_eal/common/include/rte_color.h
> >> new file mode 100644
> >> index 000000000..f4387071b
> >> --- /dev/null
> >> +++ b/lib/librte_eal/common/include/rte_color.h
> >> @@ -0,0 +1,18 @@
> >> +/* SPDX-License-Identifier: BSD-3-Clause
> >> + * Copyright(c) 2018 Intel Corporation
> >> + */
> >> +
> >> +#ifndef _RTE_COLOR_H_
> >> +#define _RTE_COLOR_H_
> >> +
> >> +/**
> >> + * Color
> >> + */
> >> +enum rte_color {
> >> + RTE_COLOR_GREEN = 0, /**< Green */
> >> + RTE_COLOR_YELLOW, /**< Yellow */
> >> + RTE_COLOR_RED, /**< Red */
> >> + RTE_COLORS /**< Number of colors */
> >> +};
> >
> > Does it really belong to EAL?
> > Konstantin
> >
>
> If this is supposed to be a generic type, we definitely need
> RTE_COLOR_BLACK as well, or RTE_COLOR_VERY_VERY_DARK_GREY.
>
> /Batman
Hi Mattias,
The packet color values of (green, yellow, red) are not my invention, they are part of the IETF DiffServ foundation and standardized by a long list of RFCs, with just a few of them listed below:
RFC 2697 - srTCM
RFC 2698 - trTCM
RFC 4115 - trTCM
RFC 2597 - Assured Forwarding
It is also easy to check in the documentation from Cisco, Juniper and other router vendors that the packet color values used for traffic metering and policing are always (green, yellow, red).
So, bottom line:
1. This is a formal as well as a de facto standard, to me it makes no sense for DPDK to do it differently. Why not align to the formal and de facto industry standards?
2. DPDK already recognized this in a number of its APIs, such as: rte_meter, ethdev rte_mtr, ethdev rte_tm, rte_sched. This patch is simply a cosmetic consolidation of the packet color definition for easier integration of all these API, it does not propose any API change. If you want to change any of these APIs, please describe the motivation and send a separate patch for review.
Regards,
Cristian
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
2018-12-17 9:41 ` Dumitrescu, Cristian
@ 2018-12-17 19:36 ` Mattias Rönnblom
2018-12-17 23:24 ` Ferruh Yigit
0 siblings, 1 reply; 74+ messages in thread
From: Mattias Rönnblom @ 2018-12-17 19:36 UTC (permalink / raw)
To: Dumitrescu, Cristian, Ananyev, Konstantin, Pattan, Reshma, dev,
jerin.jacob, Singh, Jasvinder
On 2018-12-17 10:41, Dumitrescu, Cristian wrote:
>
>
>> -----Original Message-----
>> From: Mattias Rönnblom [mailto:mattias.ronnblom@ericsson.com]
>> Sent: Saturday, December 15, 2018 2:16 PM
>> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>; Pattan, Reshma
>> <reshma.pattan@intel.com>; dev@dpdk.org; Dumitrescu, Cristian
>> <cristian.dumitrescu@intel.com>; jerin.jacob@caviumnetworks.com; Singh,
>> Jasvinder <jasvinder.singh@intel.com>
>> Subject: Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
>>
>> On 2018-12-15 00:35, Ananyev, Konstantin wrote:
>>> Hi Reshma,
>>>
>>>> diff --git a/lib/librte_eal/common/include/rte_color.h
>> b/lib/librte_eal/common/include/rte_color.h
>>>> new file mode 100644
>>>> index 000000000..f4387071b
>>>> --- /dev/null
>>>> +++ b/lib/librte_eal/common/include/rte_color.h
>>>> @@ -0,0 +1,18 @@
>>>> +/* SPDX-License-Identifier: BSD-3-Clause
>>>> + * Copyright(c) 2018 Intel Corporation
>>>> + */
>>>> +
>>>> +#ifndef _RTE_COLOR_H_
>>>> +#define _RTE_COLOR_H_
>>>> +
>>>> +/**
>>>> + * Color
>>>> + */
>>>> +enum rte_color {
>>>> + RTE_COLOR_GREEN = 0, /**< Green */
>>>> + RTE_COLOR_YELLOW, /**< Yellow */
>>>> + RTE_COLOR_RED, /**< Red */
>>>> + RTE_COLORS /**< Number of colors */
>>>> +};
>>>
>>> Does it really belong to EAL?
>>> Konstantin
>>>
>>
>> If this is supposed to be a generic type, we definitely need
>> RTE_COLOR_BLACK as well, or RTE_COLOR_VERY_VERY_DARK_GREY.
>>
>> /Batman
>
> Hi Mattias,
>
> The packet color values of (green, yellow, red) are not my invention, they are part of the IETF DiffServ foundation and standardized by a long list of RFCs, with just a few of them listed below:
>
> RFC 2697 - srTCM
> RFC 2698 - trTCM
> RFC 4115 - trTCM
> RFC 2597 - Assured Forwarding
>
> It is also easy to check in the documentation from Cisco, Juniper and other router vendors that the packet color values used for traffic metering and policing are always (green, yellow, red).
>
> So, bottom line:
> 1. This is a formal as well as a de facto standard, to me it makes no sense for DPDK to do it differently. Why not align to the formal and de facto industry standards?
> 2. DPDK already recognized this in a number of its APIs, such as: rte_meter, ethdev rte_mtr, ethdev rte_tm, rte_sched. This patch is simply a cosmetic consolidation of the packet color definition for easier integration of all these API, it does not propose any API change. If you want to change any of these APIs, please describe the motivation and send a separate patch for review.
>
It was a joke. Also, I'm not actually Batman. Sorry for the confusion.
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
2018-12-17 19:36 ` Mattias Rönnblom
@ 2018-12-17 23:24 ` Ferruh Yigit
0 siblings, 0 replies; 74+ messages in thread
From: Ferruh Yigit @ 2018-12-17 23:24 UTC (permalink / raw)
To: Mattias Rönnblom, Dumitrescu, Cristian, Ananyev, Konstantin,
Pattan, Reshma, dev, jerin.jacob, Singh, Jasvinder
On 12/17/2018 7:36 PM, Mattias Rönnblom wrote:
> On 2018-12-17 10:41, Dumitrescu, Cristian wrote:
>>
>>
>>> -----Original Message-----
>>> From: Mattias Rönnblom [mailto:mattias.ronnblom@ericsson.com]
>>> Sent: Saturday, December 15, 2018 2:16 PM
>>> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>; Pattan, Reshma
>>> <reshma.pattan@intel.com>; dev@dpdk.org; Dumitrescu, Cristian
>>> <cristian.dumitrescu@intel.com>; jerin.jacob@caviumnetworks.com; Singh,
>>> Jasvinder <jasvinder.singh@intel.com>
>>> Subject: Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
>>>
>>> On 2018-12-15 00:35, Ananyev, Konstantin wrote:
>>>> Hi Reshma,
>>>>
>>>>> diff --git a/lib/librte_eal/common/include/rte_color.h
>>> b/lib/librte_eal/common/include/rte_color.h
>>>>> new file mode 100644
>>>>> index 000000000..f4387071b
>>>>> --- /dev/null
>>>>> +++ b/lib/librte_eal/common/include/rte_color.h
>>>>> @@ -0,0 +1,18 @@
>>>>> +/* SPDX-License-Identifier: BSD-3-Clause
>>>>> + * Copyright(c) 2018 Intel Corporation
>>>>> + */
>>>>> +
>>>>> +#ifndef _RTE_COLOR_H_
>>>>> +#define _RTE_COLOR_H_
>>>>> +
>>>>> +/**
>>>>> + * Color
>>>>> + */
>>>>> +enum rte_color {
>>>>> + RTE_COLOR_GREEN = 0, /**< Green */
>>>>> + RTE_COLOR_YELLOW, /**< Yellow */
>>>>> + RTE_COLOR_RED, /**< Red */
>>>>> + RTE_COLORS /**< Number of colors */
>>>>> +};
>>>>
>>>> Does it really belong to EAL?
>>>> Konstantin
>>>>
>>>
>>> If this is supposed to be a generic type, we definitely need
>>> RTE_COLOR_BLACK as well, or RTE_COLOR_VERY_VERY_DARK_GREY.
>>>
>>> /Batman
>>
>> Hi Mattias,
>>
>> The packet color values of (green, yellow, red) are not my invention, they are part of the IETF DiffServ foundation and standardized by a long list of RFCs, with just a few of them listed below:
>>
>> RFC 2697 - srTCM
>> RFC 2698 - trTCM
>> RFC 4115 - trTCM
>> RFC 2597 - Assured Forwarding
>>
>> It is also easy to check in the documentation from Cisco, Juniper and other router vendors that the packet color values used for traffic metering and policing are always (green, yellow, red).
>>
>> So, bottom line:
>> 1. This is a formal as well as a de facto standard, to me it makes no sense for DPDK to do it differently. Why not align to the formal and de facto industry standards?
>> 2. DPDK already recognized this in a number of its APIs, such as: rte_meter, ethdev rte_mtr, ethdev rte_tm, rte_sched. This patch is simply a cosmetic consolidation of the packet color definition for easier integration of all these API, it does not propose any API change. If you want to change any of these APIs, please describe the motivation and send a separate patch for review.
>>
>
> It was a joke. Also, I'm not actually Batman. Sorry for the confusion.
This is hilarious :), although I am a bit disappointed to not have
RTE_COLOR_VERY_VERY_DARK_GREY
^ permalink raw reply [flat|nested] 74+ messages in thread
* [dpdk-dev] [PATCH v2 3/3] doc: add deprecation notice to remove rte meter color
2018-11-23 16:54 [dpdk-dev] [PATCH] mbuf: implement generic format for sched field Jasvinder Singh
` (3 preceding siblings ...)
2018-12-07 14:31 ` [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition Reshma Pattan
@ 2018-12-07 14:31 ` Reshma Pattan
2018-12-11 14:58 ` Dumitrescu, Cristian
4 siblings, 1 reply; 74+ messages in thread
From: Reshma Pattan @ 2018-12-07 14:31 UTC (permalink / raw)
To: dev, cristian.dumitrescu, jerin.jacob, jasvinder.singh; +Cc: Reshma Pattan
Added deprecation notice to replace rte_meter_color
with rte_color.
Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 60e081a54..1c771d865 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -95,3 +95,8 @@ Deprecation Notices
- ``rte_pdump_set_socket_dir`` will be removed;
- The parameter, ``path``, of ``rte_pdump_init`` will be removed;
- The enum ``rte_pdump_socktype`` will be removed.
+
+* meter: New ``rte_color`` definition will be added in 19.02 and that will
+ replace ``enum rte_meter_color`` in meter library in 19.05. This will help
+ to consolidate color definition, which is currently replicated in many places,
+ such as: rte_meter.h, rte_mtr.h, rte_tm.h.
--
2.17.1
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v2 3/3] doc: add deprecation notice to remove rte meter color
2018-12-07 14:31 ` [dpdk-dev] [PATCH v2 3/3] doc: add deprecation notice to remove rte meter color Reshma Pattan
@ 2018-12-11 14:58 ` Dumitrescu, Cristian
0 siblings, 0 replies; 74+ messages in thread
From: Dumitrescu, Cristian @ 2018-12-11 14:58 UTC (permalink / raw)
To: Pattan, Reshma, dev, jerin.jacob, Singh, Jasvinder
> -----Original Message-----
> From: Pattan, Reshma
> Sent: Friday, December 7, 2018 2:32 PM
> To: dev@dpdk.org; Dumitrescu, Cristian <cristian.dumitrescu@intel.com>;
> jerin.jacob@caviumnetworks.com; Singh, Jasvinder
> <jasvinder.singh@intel.com>
> Cc: Pattan, Reshma <reshma.pattan@intel.com>
> Subject: [PATCH v2 3/3] doc: add deprecation notice to remove rte meter
> color
>
> Added deprecation notice to replace rte_meter_color
> with rte_color.
>
> Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> ---
> doc/guides/rel_notes/deprecation.rst | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> index 60e081a54..1c771d865 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -95,3 +95,8 @@ Deprecation Notices
> - ``rte_pdump_set_socket_dir`` will be removed;
> - The parameter, ``path``, of ``rte_pdump_init`` will be removed;
> - The enum ``rte_pdump_socktype`` will be removed.
> +
> +* meter: New ``rte_color`` definition will be added in 19.02 and that will
> + replace ``enum rte_meter_color`` in meter library in 19.05. This will help
> + to consolidate color definition, which is currently replicated in many places,
> + such as: rte_meter.h, rte_mtr.h, rte_tm.h.
> --
> 2.17.1
Hi Reshma,
Let's send this deprecation note as an independent patch, i.e. outside of this patch set. The deprecation notes are discussed and merged separately, so let's not create a potential barrier for this patchset because of this deprecation note.
Of course, the deprecation note needs at least 3 acks, so please put my ack.
Regards,
Cristian
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
^ permalink raw reply [flat|nested] 74+ messages in thread