[dpdk-dev,v3,1/2] ethdev: add tunnel and port RSS offload types
Commit Message
- added VXLAN, GENEVE and NVGRE tunnel flow types
- added PORT flow type for accounting physical/virtual
port or channel number in flow creation
Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
---
app/test-pmd/cmdline.c | 18 +++++++++++++++---
app/test-pmd/config.c | 9 +++++++++
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 6 +++++-
lib/librte_ether/rte_eth_ctrl.h | 6 +++++-
lib/librte_ether/rte_ethdev.h | 16 +++++++++++++++-
5 files changed, 49 insertions(+), 6 deletions(-)
Comments
2016-03-31 02:21, Jerin Jacob:
> - added VXLAN, GENEVE and NVGRE tunnel flow types
> - added PORT flow type for accounting physical/virtual
> port or channel number in flow creation
These API change could be considered for 16.07 if they are motivated
by any use. Please bring some use cases, thanks.
On Fri, Apr 01, 2016 at 04:04:13PM +0200, Thomas Monjalon wrote:
> 2016-03-31 02:21, Jerin Jacob:
> > - added VXLAN, GENEVE and NVGRE tunnel flow types
> > - added PORT flow type for accounting physical/virtual
> > port or channel number in flow creation
>
> These API change could be considered for 16.07 if they are motivated
> by any use. Please bring some use cases, thanks.
The use case is to spray the packets to multiple queues using RSS on
Tunnel type packets.
Considering the case if RSS hash does not account inner packet in tunnel
case, the packet always to go a particular queue as mostly likely
outer header remains same in tunnel packets and RSS spread
will not be achieved in tunnel packets case.
This feature is part of the RSS capability of ThunderX
NIC HW. Which, we are planning to upstream on next release.
I thought of pushing the common code changes first.
Jerin
>
On Fri, Apr 01, 2016 at 07:59:33PM +0530, Jerin Jacob wrote:
> On Fri, Apr 01, 2016 at 04:04:13PM +0200, Thomas Monjalon wrote:
> > 2016-03-31 02:21, Jerin Jacob:
> > > - added VXLAN, GENEVE and NVGRE tunnel flow types
> > > - added PORT flow type for accounting physical/virtual
> > > port or channel number in flow creation
> >
> > These API change could be considered for 16.07 if they are motivated
> > by any use. Please bring some use cases, thanks.
>
> The use case is to spray the packets to multiple queues using RSS on
> Tunnel type packets.
>
> Considering the case if RSS hash does not account inner packet in tunnel
> case, the packet always to go a particular queue as mostly likely
> outer header remains same in tunnel packets and RSS spread
> will not be achieved in tunnel packets case.
>
> This feature is part of the RSS capability of ThunderX
> NIC HW. Which, we are planning to upstream on next release.
>
> I thought of pushing the common code changes first.
Ping
Can we merge this changeset if their are no concerns?
and their is a real consumer for this,
http://dpdk.org/ml/archives/dev/2016-June/041374.html
Jerin
Hi Jerin,
I wanted to push this patch which is now a dependency of ThunderX
but I do not fully understand it.
2016-03-31 02:21, Jerin Jacob:
> - added VXLAN, GENEVE and NVGRE tunnel flow types
> - added PORT flow type for accounting physical/virtual
> port or channel number in flow creation
[...]
> --- a/lib/librte_ether/rte_eth_ctrl.h
> +++ b/lib/librte_ether/rte_eth_ctrl.h
> @@ -74,7 +74,11 @@ extern "C" {
> #define RTE_ETH_FLOW_IPV6_EX 15
> #define RTE_ETH_FLOW_IPV6_TCP_EX 16
> #define RTE_ETH_FLOW_IPV6_UDP_EX 17
> -#define RTE_ETH_FLOW_MAX 18
> +#define RTE_ETH_FLOW_PORT 18
> +#define RTE_ETH_FLOW_VXLAN 19
> +#define RTE_ETH_FLOW_GENEVE 20
> +#define RTE_ETH_FLOW_NVGRE 21
> +#define RTE_ETH_FLOW_MAX 22
Please could you explain more what is PORT flow?
Does it need a comment in the code?
On Tue, Jun 21, 2016 at 11:02:59PM +0200, Thomas Monjalon wrote:
> Hi Jerin,
Hi Thomas,
>
> I wanted to push this patch which is now a dependency of ThunderX
> but I do not fully understand it.
>
> 2016-03-31 02:21, Jerin Jacob:
> > - added VXLAN, GENEVE and NVGRE tunnel flow types
> > - added PORT flow type for accounting physical/virtual
> > port or channel number in flow creation
> [...]
> > --- a/lib/librte_ether/rte_eth_ctrl.h
> > +++ b/lib/librte_ether/rte_eth_ctrl.h
> > @@ -74,7 +74,11 @@ extern "C" {
> > #define RTE_ETH_FLOW_IPV6_EX 15
> > #define RTE_ETH_FLOW_IPV6_TCP_EX 16
> > #define RTE_ETH_FLOW_IPV6_UDP_EX 17
> > -#define RTE_ETH_FLOW_MAX 18
> > +#define RTE_ETH_FLOW_PORT 18
> > +#define RTE_ETH_FLOW_VXLAN 19
> > +#define RTE_ETH_FLOW_GENEVE 20
> > +#define RTE_ETH_FLOW_NVGRE 21
> > +#define RTE_ETH_FLOW_MAX 22
>
> Please could you explain more what is PORT flow?
For example, a NIC card with two physical port where application
configures RTE_ETH_FLOW_IPV4 for both, In that case
HW generate same RSS value for a similar IPV4 packet, However, in-case if
application want to generate a flow that account physical port also then
it can configure with RTE_ETH_FLOW_IPV4 | RTE_ETH_FLOW_PORT.
RTE_ETH_FLOW_PORT useful for the case where one physical port assigned for
INBOUND traffic and other-one for OUTBOUND traffic etc
> Does it need a comment in the code?
Not sure, commit log has description.
Jerin
2016-06-22 09:00, Jerin Jacob:
> On Tue, Jun 21, 2016 at 11:02:59PM +0200, Thomas Monjalon wrote:
> > Hi Jerin,
>
> Hi Thomas,
>
> >
> > I wanted to push this patch which is now a dependency of ThunderX
> > but I do not fully understand it.
> >
> > 2016-03-31 02:21, Jerin Jacob:
> > > - added VXLAN, GENEVE and NVGRE tunnel flow types
> > > - added PORT flow type for accounting physical/virtual
> > > port or channel number in flow creation
> > [...]
> > > --- a/lib/librte_ether/rte_eth_ctrl.h
> > > +++ b/lib/librte_ether/rte_eth_ctrl.h
> > > @@ -74,7 +74,11 @@ extern "C" {
> > > #define RTE_ETH_FLOW_IPV6_EX 15
> > > #define RTE_ETH_FLOW_IPV6_TCP_EX 16
> > > #define RTE_ETH_FLOW_IPV6_UDP_EX 17
> > > -#define RTE_ETH_FLOW_MAX 18
> > > +#define RTE_ETH_FLOW_PORT 18
> > > +#define RTE_ETH_FLOW_VXLAN 19
> > > +#define RTE_ETH_FLOW_GENEVE 20
> > > +#define RTE_ETH_FLOW_NVGRE 21
> > > +#define RTE_ETH_FLOW_MAX 22
> >
> > Please could you explain more what is PORT flow?
>
> For example, a NIC card with two physical port where application
> configures RTE_ETH_FLOW_IPV4 for both, In that case
> HW generate same RSS value for a similar IPV4 packet, However, in-case if
> application want to generate a flow that account physical port also then
> it can configure with RTE_ETH_FLOW_IPV4 | RTE_ETH_FLOW_PORT.
>
> RTE_ETH_FLOW_PORT useful for the case where one physical port assigned for
> INBOUND traffic and other-one for OUTBOUND traffic etc
OK
> > Does it need a comment in the code?
> Not sure, commit log has description.
How do you expect the user to understand this new value in the API?
Users do not check in the git history.
They use doxygen, headers comments and/or examples.
On Wed, Jun 22, 2016 at 08:43:52AM +0200, Thomas Monjalon wrote:
> 2016-06-22 09:00, Jerin Jacob:
> > On Tue, Jun 21, 2016 at 11:02:59PM +0200, Thomas Monjalon wrote:
> > > Hi Jerin,
> >
> > Hi Thomas,
> >
> > >
> > > I wanted to push this patch which is now a dependency of ThunderX
> > > but I do not fully understand it.
> > >
> > > 2016-03-31 02:21, Jerin Jacob:
> > > > - added VXLAN, GENEVE and NVGRE tunnel flow types
> > > > - added PORT flow type for accounting physical/virtual
> > > > port or channel number in flow creation
> > > [...]
> > > > --- a/lib/librte_ether/rte_eth_ctrl.h
> > > > +++ b/lib/librte_ether/rte_eth_ctrl.h
> > > > @@ -74,7 +74,11 @@ extern "C" {
> > > > #define RTE_ETH_FLOW_IPV6_EX 15
> > > > #define RTE_ETH_FLOW_IPV6_TCP_EX 16
> > > > #define RTE_ETH_FLOW_IPV6_UDP_EX 17
> > > > -#define RTE_ETH_FLOW_MAX 18
> > > > +#define RTE_ETH_FLOW_PORT 18
> > > > +#define RTE_ETH_FLOW_VXLAN 19
> > > > +#define RTE_ETH_FLOW_GENEVE 20
> > > > +#define RTE_ETH_FLOW_NVGRE 21
> > > > +#define RTE_ETH_FLOW_MAX 22
> > >
> > > Please could you explain more what is PORT flow?
> >
> > For example, a NIC card with two physical port where application
> > configures RTE_ETH_FLOW_IPV4 for both, In that case
> > HW generate same RSS value for a similar IPV4 packet, However, in-case if
> > application want to generate a flow that account physical port also then
> > it can configure with RTE_ETH_FLOW_IPV4 | RTE_ETH_FLOW_PORT.
> >
> > RTE_ETH_FLOW_PORT useful for the case where one physical port assigned for
> > INBOUND traffic and other-one for OUTBOUND traffic etc
>
> OK
>
> > > Does it need a comment in the code?
> > Not sure, commit log has description.
>
> How do you expect the user to understand this new value in the API?
> Users do not check in the git history.
> They use doxygen, headers comments and/or examples.
The reason why I said because none of flow type has comments in the
list. If you think RTE_ETH_FLOW_PORT needs a doxygen comment then I can
add it.
It would be nice some else could add the comments for following,
RTE_ETH_FLOW_RAW,
RTE_ETH_FLOW_L2_PAYLOAD
2016-06-22 12:45, Jerin Jacob:
> On Wed, Jun 22, 2016 at 08:43:52AM +0200, Thomas Monjalon wrote:
> > 2016-06-22 09:00, Jerin Jacob:
> > > On Tue, Jun 21, 2016 at 11:02:59PM +0200, Thomas Monjalon wrote:
> > > > 2016-03-31 02:21, Jerin Jacob:
> > > > > +#define RTE_ETH_FLOW_PORT 18
> > > > > +#define RTE_ETH_FLOW_VXLAN 19
> > > > > +#define RTE_ETH_FLOW_GENEVE 20
> > > > > +#define RTE_ETH_FLOW_NVGRE 21
> > > > > +#define RTE_ETH_FLOW_MAX 22
> > > >
> > > > Please could you explain more what is PORT flow?
> > >
> > > For example, a NIC card with two physical port where application
> > > configures RTE_ETH_FLOW_IPV4 for both, In that case
> > > HW generate same RSS value for a similar IPV4 packet, However, in-case if
> > > application want to generate a flow that account physical port also then
> > > it can configure with RTE_ETH_FLOW_IPV4 | RTE_ETH_FLOW_PORT.
> > >
> > > RTE_ETH_FLOW_PORT useful for the case where one physical port assigned for
> > > INBOUND traffic and other-one for OUTBOUND traffic etc
> >
> > OK
> >
> > > > Does it need a comment in the code?
> > > Not sure, commit log has description.
> >
> > How do you expect the user to understand this new value in the API?
> > Users do not check in the git history.
> > They use doxygen, headers comments and/or examples.
>
> The reason why I said because none of flow type has comments in the
> list. If you think RTE_ETH_FLOW_PORT needs a doxygen comment then I can
> add it.
>
> It would be nice some else could add the comments for following,
> RTE_ETH_FLOW_RAW,
> RTE_ETH_FLOW_L2_PAYLOAD
These values passed without a proper check.
That's why we must not accept any line in API without good comment.
Please go ahead with what you can do and we'll fix or remove
the remaining later.
v1..v2
- Added cover letter
- Corrected typo in RET_ETH_FLOW_VXLAN name
- Updated test-pmd application to access newly defined RSS offload flags
v2..v3
-testpmd document update(Suggested by John and Pablo)
v3..v4
- Added doxgen comments for new FLOW types(Suggested by Thomas)
Jerin Jacob (2):
ethdev: add tunnel and port RSS offload types
ethdev: add ETH_RSS_RETA_SIZE_256
app/test-pmd/cmdline.c | 18 +++++++++++++++---
app/test-pmd/config.c | 9 +++++++++
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 6 +++++-
lib/librte_ether/rte_eth_ctrl.h | 7 ++++++-
lib/librte_ether/rte_ethdev.h | 17 ++++++++++++++++-
5 files changed, 51 insertions(+), 6 deletions(-)
> Jerin Jacob (2):
> ethdev: add tunnel and port RSS offload types
> ethdev: add ETH_RSS_RETA_SIZE_256
Applied with suggested rewording, thanks
@@ -565,7 +565,7 @@ static void cmd_help_long_parsed(void *parsed_result,
" Set crc-strip/rx-checksum/hardware-vlan/drop_en"
" for ports.\n\n"
- "port config all rss (all|ip|tcp|udp|sctp|ether|none)\n"
+ "port config all rss (all|ip|tcp|udp|sctp|ether|port|vxlan|geneve|nvgre|none)\n"
" Set the RSS mode.\n\n"
"port config port-id rss reta (hash,queue)[,(hash,queue)]\n"
@@ -1545,6 +1545,14 @@ cmd_config_rss_parsed(void *parsed_result,
rss_conf.rss_hf = ETH_RSS_SCTP;
else if (!strcmp(res->value, "ether"))
rss_conf.rss_hf = ETH_RSS_L2_PAYLOAD;
+ else if (!strcmp(res->value, "port"))
+ rss_conf.rss_hf = ETH_RSS_PORT;
+ else if (!strcmp(res->value, "vxlan"))
+ rss_conf.rss_hf = ETH_RSS_VXLAN;
+ else if (!strcmp(res->value, "geneve"))
+ rss_conf.rss_hf = ETH_RSS_GENEVE;
+ else if (!strcmp(res->value, "nvgre"))
+ rss_conf.rss_hf = ETH_RSS_NVGRE;
else if (!strcmp(res->value, "none"))
rss_conf.rss_hf = 0;
else {
@@ -1566,12 +1574,12 @@ cmdline_parse_token_string_t cmd_config_rss_name =
TOKEN_STRING_INITIALIZER(struct cmd_config_rss, name, "rss");
cmdline_parse_token_string_t cmd_config_rss_value =
TOKEN_STRING_INITIALIZER(struct cmd_config_rss, value,
- "all#ip#tcp#udp#sctp#ether#none");
+ "all#ip#tcp#udp#sctp#ether#port#vxlan#geneve#nvgre#none");
cmdline_parse_inst_t cmd_config_rss = {
.f = cmd_config_rss_parsed,
.data = NULL,
- .help_str = "port config all rss all|ip|tcp|udp|sctp|ether|none",
+ .help_str = "port config all rss all|ip|tcp|udp|sctp|ether|port|vxlan|geneve|nvgre|none",
.tokens = {
(void *)&cmd_config_rss_port,
(void *)&cmd_config_rss_keyword,
@@ -9304,6 +9312,10 @@ flowtype_to_str(uint16_t ftype)
{"ipv6-sctp", RTE_ETH_FLOW_NONFRAG_IPV6_SCTP},
{"ipv6-other", RTE_ETH_FLOW_NONFRAG_IPV6_OTHER},
{"l2_payload", RTE_ETH_FLOW_L2_PAYLOAD},
+ {"port", RTE_ETH_FLOW_PORT},
+ {"vxlan", RTE_ETH_FLOW_VXLAN},
+ {"geneve", RTE_ETH_FLOW_GENEVE},
+ {"nvgre", RTE_ETH_FLOW_NVGRE},
};
for (i = 0; i < RTE_DIM(ftype_table); i++) {
@@ -137,6 +137,11 @@ static const struct rss_type_info rss_type_table[] = {
{ "ipv6-ex", ETH_RSS_IPV6_EX },
{ "ipv6-tcp-ex", ETH_RSS_IPV6_TCP_EX },
{ "ipv6-udp-ex", ETH_RSS_IPV6_UDP_EX },
+ { "port", ETH_RSS_PORT },
+ { "vxlan", ETH_RSS_VXLAN },
+ { "geneve", ETH_RSS_GENEVE },
+ { "nvgre", ETH_RSS_NVGRE },
+
};
static void
@@ -2028,6 +2033,10 @@ flowtype_to_str(uint16_t flow_type)
{"ipv6-sctp", RTE_ETH_FLOW_NONFRAG_IPV6_SCTP},
{"ipv6-other", RTE_ETH_FLOW_NONFRAG_IPV6_OTHER},
{"l2_payload", RTE_ETH_FLOW_L2_PAYLOAD},
+ {"port", RTE_ETH_FLOW_PORT},
+ {"vxlan", RTE_ETH_FLOW_VXLAN},
+ {"geneve", RTE_ETH_FLOW_GENEVE},
+ {"nvgre", RTE_ETH_FLOW_NVGRE},
};
for (i = 0; i < RTE_DIM(flowtype_str_table); i++) {
@@ -177,6 +177,10 @@ For example:
ipv6-sctp
ipv6-other
l2_payload
+ port
+ vxlan
+ geneve
+ nvgre
show port rss reta
~~~~~~~~~~~~~~~~~~
@@ -1258,7 +1262,7 @@ port config - RSS
Set the RSS (Receive Side Scaling) mode on or off::
- testpmd> port config all rss (all|ip|tcp|udp|sctp|ether|none)
+ testpmd> port config all rss (all|ip|tcp|udp|sctp|ether|port|vxlan|geneve|nvgre|none)
RSS is on by default.
@@ -74,7 +74,11 @@ extern "C" {
#define RTE_ETH_FLOW_IPV6_EX 15
#define RTE_ETH_FLOW_IPV6_TCP_EX 16
#define RTE_ETH_FLOW_IPV6_UDP_EX 17
-#define RTE_ETH_FLOW_MAX 18
+#define RTE_ETH_FLOW_PORT 18
+#define RTE_ETH_FLOW_VXLAN 19
+#define RTE_ETH_FLOW_GENEVE 20
+#define RTE_ETH_FLOW_NVGRE 21
+#define RTE_ETH_FLOW_MAX 22
/**
* Feature filter types
@@ -406,6 +406,10 @@ struct rte_eth_rss_conf {
#define ETH_RSS_IPV6_EX (1ULL << RTE_ETH_FLOW_IPV6_EX)
#define ETH_RSS_IPV6_TCP_EX (1ULL << RTE_ETH_FLOW_IPV6_TCP_EX)
#define ETH_RSS_IPV6_UDP_EX (1ULL << RTE_ETH_FLOW_IPV6_UDP_EX)
+#define ETH_RSS_PORT (1ULL << RTE_ETH_FLOW_PORT)
+#define ETH_RSS_VXLAN (1ULL << RTE_ETH_FLOW_VXLAN)
+#define ETH_RSS_GENEVE (1ULL << RTE_ETH_FLOW_GENEVE)
+#define ETH_RSS_NVGRE (1ULL << RTE_ETH_FLOW_NVGRE)
#define ETH_RSS_IP ( \
ETH_RSS_IPV4 | \
@@ -430,6 +434,12 @@ struct rte_eth_rss_conf {
ETH_RSS_NONFRAG_IPV4_SCTP | \
ETH_RSS_NONFRAG_IPV6_SCTP)
+#define ETH_RSS_TUNNEL ( \
+ ETH_RSS_VXLAN | \
+ ETH_RSS_GENEVE | \
+ ETH_RSS_NVGRE)
+
+
/**< Mask of valid RSS hash protocols */
#define ETH_RSS_PROTO_MASK ( \
ETH_RSS_IPV4 | \
@@ -447,7 +457,11 @@ struct rte_eth_rss_conf {
ETH_RSS_L2_PAYLOAD | \
ETH_RSS_IPV6_EX | \
ETH_RSS_IPV6_TCP_EX | \
- ETH_RSS_IPV6_UDP_EX)
+ ETH_RSS_IPV6_UDP_EX | \
+ ETH_RSS_PORT | \
+ ETH_RSS_VXLAN | \
+ ETH_RSS_GENEVE | \
+ ETH_RSS_NVGRE)
/*
* Definitions used for redirection table entry size.