[dpdk-dev] [RFC 0/3] ethdev: add IP address and TCP/UDP port rewrite actions to flow API

Jack Min jackmin at mellanox.com
Thu Aug 2 01:35:34 CEST 2018


> -----Original Message-----
> From: Rahul Lakkireddy <rahul.lakkireddy at chelsio.com>
> Sent: July 10, 2018 21:14
> To: Adrien Mazarguil <adrien.mazarguil at 6wind.com>
> Cc: Jack Min <jackmin at mellanox.com>; dev at dpdk.org; Shagun Agarwal
> <shaguna at chelsio.com>; Indranil Choudhury <indranil at chelsio.com>; Nirranjan
> Kirubaharan <nirranjan at chelsio.com>; Shahaf Shuler <shahafs at mellanox.com>;
> Xueming(Steven) Li <xuemingl at mellanox.com>
> Subject: Re: [dpdk-dev] [RFC 0/3] ethdev: add IP address and TCP/UDP port
> rewrite actions to flow API
> 
> On Friday, July 07/06/18, 2018 at 01:46:40 +0530, Adrien Mazarguil wrote:
> > On Tue, Jul 03, 2018 at 07:09:22PM +0530, Rahul Lakkireddy wrote:
> > > On Tuesday, July 07/03/18, 2018 at 07:57:55 +0530, Jack Min wrote:
> > > > Hey Rahul,
> > > >
> > > > Thank you, those two are the ways to achieve that.
> > > >
> > > > Personally I prefer the option 1 but with a little bit difference, something like:
> > > >
> > > >     struct rte_flow_action_of_set_nw_ipv4 {
> > > >  	   uint32_t ipv4_addr;
> > > >                 uint8_t   level;  /* 0 - outer (default), 1 - inner, 2 -255 deeper if
> available */
> > > >     };
> > > >
> > > > What do you think ?
> > > >
> > >
> > > Looks good. I'll update the API and use the above approach in v2.
> >
Rahul, we have second thought about **level** parameter. We found there are
no any *real* user case which really need to modify the inner layer. Do you have any?
If no, **level** could be removed in order to keep API clean and simple.

> > I still haven't looked at the original proposal (will get there
> > eventually), however keep in mind the presence of "OF" in action names
> > stands for "OpenFlow".
> >
> > Since you chose this route, these actions must be implemented exactly
> > as defined by the OpenFlow specification, which comprises their name,
> > input parameters and behavior.
> >
> > For instance there is no support/distinction for IPv6. NW actions must
> > be named OF_SET_NW_SRC and OF_SET_NW_DST, only support IPv4 (a
> single
> > be32) and not have the ability to tell inner from outer as it's
> > unspecified (note a safe approach would be to interpret this as
> > "outermost" given the tendency of OpenFlow actions to prepend empty headers
> and modify them afterward).
> >
> > In short you can't be creative if you want to keep the OF prefix.
> >
> 
> Ok, will drop OF prefix for these actions in v2.
How about drop the NW prefix as well?  Since we don't want to stick on openflow,
NW prefix seems redundant. Names like RTE_FLOW_ACTION_SET_IPV4_SRC
is clear enough, isn't it? What do you think?

> > My suggestion would be to stick with OF if your target use case is OVS
> > and implement these actions exactly as defined by OpenFlow, even if it
> > means limitations due to API (not HW) constraints. Not having to spend
> > time to figure how to map OF actions to rte_flow and handle quirks on
> > both sides should be much more convenient to users, particularly so if
> > these actions bear the same name.
> >
> 
> We can translate OF_SET_NW_* actions to RTE_FLOW_ACTION_SET_NW_IPV4_*
> actions in OVS stack itself before sending them via DPDK stack for offload.
> 
> Thanks,
> Rahul
> 
> > > > > -----Original Message-----
> > > > > From: Rahul Lakkireddy <rahul.lakkireddy at chelsio.com>
> > > > > Sent: July 2, 2018 20:04
> > > > > To: Jack Min <jackmin at mellanox.com>
> > > > > Cc: dev at dpdk.org; Shagun Agarwal <shaguna at chelsio.com>; Indranil
> > > > > Choudhury <indranil at chelsio.com>; Nirranjan Kirubaharan
> > > > > <nirranjan at chelsio.com>; Shahaf Shuler <shahafs at mellanox.com>;
> > > > > Xueming(Steven) Li <xuemingl at mellanox.com>
> > > > > Subject: Re: [dpdk-dev] [RFC 0/3] ethdev: add IP address and
> > > > > TCP/UDP port rewrite actions to flow API
> > > > >
> > > > > Hi Jack,
> > > > >
> > > > > On Monday, July 07/02/18, 2018 at 14:39:06 +0530, Jack Min wrote:
> > > > > > Hey,
> > > > > >
> > > > > > I've one question:
> > > > > >
> > > > > > Do those APIs support modify inner IP headers?
> > > > > >
> > > > >
> > > > > I'm afraid not. These API only modify outer IP addresses.
> > > > >
> > > > > I can think of two ways to achieve this:
> > > > >
> > > > > 1. Enhance these API to accept an additional flag to indicate
> > > > >    inner or outer. For example, to set inner IPv4 address, we can
> > > > >    set inner to 1 in following structure.
> > > > >
> > > > >    struct rte_flow_action_of_set_nw_ipv4 {
> > > > > 	   uint32_t inner:1; /* 1 - Inner, 0 - Outer */
> > > > > 	   uint32_t reserved:31;
> > > > > 	   uint32_t ipv4_addr;
> > > > >    };
> > > > >
> > > > > 2. Add new actions to indicate inner IP addresses; i.e.
> > > > >
> > > > >    RTE_FLOW_ACTION_TYPE_OF_SET_INNER_NW_IPV4_SRC
> > > > >    RTE_FLOW_ACTION_TYPE_OF_SET_INNER_NW_IPV4_DST
> > > > >    RTE_FLOW_ACTION_TYPE_OF_SET_INNER_NW_IPV6_SRC
> > > > >    RTE_FLOW_ACTION_TYPE_OF_SET_INNER_NW_IPV6_DST
> > > > >
> > > > > Thanks,
> > > > > Rahul
> > > > >
> > > > > > In our scenarios, we need to specific that  NAT action is on
> > > > > > inner or outer IP
> > > > > header.
> > > > > >
> > > > > > Thanks,
> > > > > > -Jack
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: dev <dev-bounces at dpdk.org> On Behalf Of Rahul
> > > > > > > Lakkireddy
> > > > > > > Sent: June 22, 2018 17:56
> > > > > > > To: dev at dpdk.org
> > > > > > > Cc: shaguna at chelsio.com; indranil at chelsio.com;
> > > > > > > nirranjan at chelsio.com
> > > > > > > Subject: [dpdk-dev] [RFC 0/3] ethdev: add IP address and
> > > > > > > TCP/UDP port rewrite actions to flow API
> > > > > > >
> > > > > > > This series of patches add support for actions:
> > > > > > > - OF_SET_NW_IPV4_SRC - set a new IPv4 source address.
> > > > > > > - OF_SET_NW_IPV4_DST - set a new IPv4 destination address.
> > > > > > > - OF_SET_NW_IPV6_SRC - set a new IPv6 source address.
> > > > > > > - OF_SET_NW_IPV6_DST - set a new IPv6 destination address.
> > > > > > > - OF_SET_TP_SRC - set a new TCP/UDP source port number.
> > > > > > > - OF_SET_TP_DST - set a new TCP/UDP destination port number.
> > > > > > >
> > > > > > > These actions are useful in Network Address Translation use
> > > > > > > case to edit IP address and TCP/UDP port numbers before
> > > > > > > switching the packets out to the destination device port.
> > > > > > >
> > > > > > > The IP address and TCP/UDP port rewrite actions are based on
> > > > > > > OFPAT_SET_NW_SRC, OFPAT_SET_NW_DST, OFPAT_SET_TP_SRC,
> and
> > > > > > > OFPAT_SET_TP_DST actions from OpenFlow Specification [1].
> > > > > > >
> > > > > > > Patch 1 adds support for IP address rewrite to rte_flow and testpmd.
> > > > > > >
> > > > > > > Patch 2 adds support for TCP/UDP port rewrite to rte_flow and
> testpmd.
> > > > > > >
> > > > > > > Patch 3 shows CXGBE PMD example to offload these actions to
> hardware.
> > > > > > >
> > > > > > > Feedback and suggestions will be much appreciated.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Rahul
> > > > > > >
> > > > > > > [1]
> > > > > > > https://emea01.safelinks.protection.outlook.com/?url=http%3A
> > > > > > > %2F%2Fww
> > > > > > > w.open
> > > > > > > networking.org%2Fimages%2Fopenflow-switch-
> > > > > > >
> > > > >
> v1.5.1.pdf&data=02%7C01%7Cxuemingl%40mellanox.com%7C74c8ce3b7995
> > > > > 4b2f
> > > > > > >
> > > > >
> 123208d5d8268617%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C1%7C63
> > > > > 6
> > > > > > >
> > > > >
> 652582334142929&sdata=uoFc1KjVTkGI9fdaPNXvXYRmh%2F6HLMKT79IwgvDS
> > > > > H
> > > > > > > 0k%3D&reserved=0
> > > > > > >
> > > > > > > Shagun Agrawal (3):
> > > > > > >   ethdev: add flow api actions to modify IP addresses
> > > > > > >   ethdev: add flow api actions to modify TCP/UDP port numbers
> > > > > > >   net/cxgbe: add flow actions to modify IP and TCP/UDP port
> > > > > > > address
> > > > > > >
> > > > > > >  app/test-pmd/cmdline_flow.c                 | 150
> > > > > > > ++++++++++++++++++++++++++++
> > > > > > >  app/test-pmd/config.c                       |  12 +++
> > > > > > >  doc/guides/prog_guide/rte_flow.rst          | 102
> +++++++++++++++++++
> > > > > > >  doc/guides/testpmd_app_ug/testpmd_funcs.rst |  24 +++++
> > > > > > >  drivers/net/cxgbe/base/common.h             |   1 +
> > > > > > >  drivers/net/cxgbe/base/t4fw_interface.h     |  50 ++++++++++
> > > > > > >  drivers/net/cxgbe/cxgbe_filter.c            |  23 ++++-
> > > > > > >  drivers/net/cxgbe/cxgbe_filter.h            |  26 ++++-
> > > > > > >  drivers/net/cxgbe/cxgbe_flow.c              | 127
> +++++++++++++++++++++++
> > > > > > >  drivers/net/cxgbe/cxgbe_main.c              |  10 ++
> > > > > > >  lib/librte_ethdev/rte_flow.c                |  12 +++
> > > > > > >  lib/librte_ethdev/rte_flow.h                |  92 +++++++++++++++++
> > > > > > >  12 files changed, 625 insertions(+), 4 deletions(-)
> > > > > > >
> > > > > > > --
> > > > > > > 2.14.1
> > > > > >
> >
> > --
> > Adrien Mazarguil
> > 6WIND


More information about the dev mailing list