[RFC] ethdev: add a new flow action of queue range
Checks
Commit Message
From: Chengwen Feng <fengchengwen@huawei.com>
This patch adds a new flow action of queue range, which was used to assign
packets to a continuous queue range.
Current FD (flow director) provide a useful means to assign packets to
a target queue. But it has the following shortage: it can only route
to one queue, and there is an upper limit on one queue rxtx capacity,
which means the FD rule need more accurate else it may exceed the
queue capacity.
With the support of queue range action, user can create FD rule with
action routed to a continuous queues, like:
FD rule 0 ------|-----> queue 0
|-----> queue 1
FD rule 1 ------|-----> queue 8
|-----> queue 9
|-----> queue 10
|-----> queue 11
Note: hardware can use RSS to distribute traffic to the continuous queues
when packets match the above FD rule.
With the support of queue range action, we can further provide QoS
service when DCB disabled.
eg: one NE (network element) is configured with two ip addresses, one for
control plane and the other for data plane, user can create two FD rules,
the first for directing control plane packets to queue 0, the second for
directing data plane packets to queue 1~15.
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
---
lib/librte_ethdev/rte_flow.c | 1 +
lib/librte_ethdev/rte_flow.h | 17 +++++++++++++++++
2 files changed, 18 insertions(+)
Comments
On 7/17/20 12:32 PM, Wei Hu (Xavier) wrote:
> From: Chengwen Feng <fengchengwen@huawei.com>
>
> This patch adds a new flow action of queue range, which was used to assign
> packets to a continuous queue range.
>
> Current FD (flow director) provide a useful means to assign packets to
> a target queue. But it has the following shortage: it can only route
> to one queue, and there is an upper limit on one queue rxtx capacity,
> which means the FD rule need more accurate else it may exceed the
> queue capacity.
>
> With the support of queue range action, user can create FD rule with
> action routed to a continuous queues, like:
> FD rule 0 ------|-----> queue 0
> |-----> queue 1
>
> FD rule 1 ------|-----> queue 8
> |-----> queue 9
> |-----> queue 10
> |-----> queue 11
> Note: hardware can use RSS to distribute traffic to the continuous queues
> when packets match the above FD rule.
>
> With the support of queue range action, we can further provide QoS
> service when DCB disabled.
> eg: one NE (network element) is configured with two ip addresses, one for
> control plane and the other for data plane, user can create two FD rules,
> the first for directing control plane packets to queue 0, the second for
> directing data plane packets to queue 1~15.
I don't understand why it is not covered by RSS action.
>
> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
[snip]
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Andrew Rybchenko
>
> On 7/17/20 12:32 PM, Wei Hu (Xavier) wrote:
> > From: Chengwen Feng <fengchengwen@huawei.com>
> >
> > This patch adds a new flow action of queue range, which was used to assign
> > packets to a continuous queue range.
> >
> > Current FD (flow director) provide a useful means to assign packets to
> > a target queue. But it has the following shortage: it can only route
> > to one queue, and there is an upper limit on one queue rxtx capacity,
> > which means the FD rule need more accurate else it may exceed the
> > queue capacity.
> >
> > With the support of queue range action, user can create FD rule with
> > action routed to a continuous queues, like:
> > FD rule 0 ------|-----> queue 0
> > |-----> queue 1
> >
> > FD rule 1 ------|-----> queue 8
> > |-----> queue 9
> > |-----> queue 10
> > |-----> queue 11
> > Note: hardware can use RSS to distribute traffic to the continuous queues
> > when packets match the above FD rule.
> >
> > With the support of queue range action, we can further provide QoS
> > service when DCB disabled.
> > eg: one NE (network element) is configured with two ip addresses, one for
> > control plane and the other for data plane, user can create two FD rules,
> > the first for directing control plane packets to queue 0, the second for
> > directing data plane packets to queue 1~15.
>
> I don't understand why it is not covered by RSS action.
>
+1
This should be covered in RSS action.
> >
> > Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> > Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
>
> [snip]
Best,
Ori
Hi Fengchen,
Please make sure to include maintainers next time.
Thanks,
Ori
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Ori Kam
>
>
>
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Andrew Rybchenko
> >
> > On 7/17/20 12:32 PM, Wei Hu (Xavier) wrote:
> > > From: Chengwen Feng <fengchengwen@huawei.com>
> > >
> > > This patch adds a new flow action of queue range, which was used to assign
> > > packets to a continuous queue range.
> > >
> > > Current FD (flow director) provide a useful means to assign packets to
> > > a target queue. But it has the following shortage: it can only route
> > > to one queue, and there is an upper limit on one queue rxtx capacity,
> > > which means the FD rule need more accurate else it may exceed the
> > > queue capacity.
> > >
> > > With the support of queue range action, user can create FD rule with
> > > action routed to a continuous queues, like:
> > > FD rule 0 ------|-----> queue 0
> > > |-----> queue 1
> > >
> > > FD rule 1 ------|-----> queue 8
> > > |-----> queue 9
> > > |-----> queue 10
> > > |-----> queue 11
> > > Note: hardware can use RSS to distribute traffic to the continuous queues
> > > when packets match the above FD rule.
> > >
> > > With the support of queue range action, we can further provide QoS
> > > service when DCB disabled.
> > > eg: one NE (network element) is configured with two ip addresses, one for
> > > control plane and the other for data plane, user can create two FD rules,
> > > the first for directing control plane packets to queue 0, the second for
> > > directing data plane packets to queue 1~15.
> >
> > I don't understand why it is not covered by RSS action.
> >
> +1
> This should be covered in RSS action.
>
> > >
> > > Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> > > Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
> >
> > [snip]
>
> Best,
> Ori
@@ -114,6 +114,7 @@ static const struct rte_flow_desc_data rte_flow_desc_action[] = {
MK_FLOW_ACTION(MARK, sizeof(struct rte_flow_action_mark)),
MK_FLOW_ACTION(FLAG, 0),
MK_FLOW_ACTION(QUEUE, sizeof(struct rte_flow_action_queue)),
+ MK_FLOW_ACTION(QUEUE_RANGE, sizeof(struct rte_flow_action_queue_range)),
MK_FLOW_ACTION(DROP, 0),
MK_FLOW_ACTION(COUNT, sizeof(struct rte_flow_action_count)),
MK_FLOW_ACTION(RSS, sizeof(struct rte_flow_action_rss)),
@@ -1703,6 +1703,13 @@ enum rte_flow_action_type {
RTE_FLOW_ACTION_TYPE_QUEUE,
/**
+ * Assigns packets to a given queue range.
+ *
+ * See struct rte_flow_action_queue_range.
+ */
+ RTE_FLOW_ACTION_TYPE_QUEUE_RANGE,
+
+ /**
* Drops packets.
*
* PASSTHRU overrides this action if both are specified.
@@ -2149,6 +2156,16 @@ struct rte_flow_action_mark {
};
/**
+ * RTE_FLOW_ACTION_TYPE_QUEUE_RANGE
+ *
+ * Assign packets to a given queue range.
+ */
+struct rte_flow_action_queue_range {
+ uint16_t start_index; /**< Index of start queue start to use. */
+ uint16_t queue_num; /**< Num of continuous queues from start_index. */
+};
+
+/**
* @warning
* @b EXPERIMENTAL: this structure may change without prior notice
*