[dpdk-dev] [RFC PATCH 0/6] General tunneling APIs

Liu, Jijiang jijiang.liu at intel.com
Mon Dec 28 06:54:46 CET 2015


Hi Miroslaw,

The partial answer is below.

> -----Original Message-----
> From: Walukiewicz, Miroslaw
> Sent: Wednesday, December 23, 2015 7:18 PM
> To: Liu, Jijiang; dev at dpdk.org
> Subject: RE: [dpdk-dev] [RFC PATCH 0/6] General tunneling APIs
> 
> Hi Jijang,
> 
> I like an idea of tunnel API very much.
> 
> I have a few questions.
> 
> 1. I see that you have only i40e support due to lack of HW tunneling support
> in other NICs.
> I don't see a way how do you want to handle tunneling requests for NICs
> without HW offload.

The flow director offload mechanism is used here, flow director is a common feature in current NICs.
Here I don't use special related tunneling HW offload features, the goal is that we want to support  all of NICs.

> I think that we should have one common function for sending tunneled
> packets but the initialization should check the NIC capabilities and call some
> registered function making tunneling in SW in case of lack of HW support.
Yes, we should check NIC capabilities.

> I know that making tunnel is very time consuming process, but it makes an
> API more generic. Similar only 3 protocols are supported by i40e by HW and
> we can imagine about 40 or more different tunnels working with this NIC.
> 
> Making the SW implementation we could support missing tunnels even for
> i40e.

In this patch set, I just use VXLAN protocol to demonstrate the framework, 
If the framework is accepted, other tunneling protocol will be added one by one in future. 

> 2. I understand that we need RX HW queue defined in struct
> rte_eth_tunnel_conf but why tx_queue is necessary?.
>   As I know i40e HW we can set tunneled packet descriptors in any HW queue
> and receive only on one specific queue.

As for adding tx_queue here, I have already explained here at [1]

[1] http://dpdk.org/ml/archives/dev/2015-December/030509.html

Do you think it makes sense?

> 4. In your implementation you are assuming the there is one tunnel
> configured per DPDK interface
> 
> rte_eth_dev_tunnel_configure(uint8_t port_id,
> +			     struct rte_eth_tunnel_conf *tunnel_conf)
> 
No, in terms of i40e,  there will  be up to 8K tunnels  in one DPDK interface,
It depends on number of flow rules on a pair of queues.

struct rte_eth_tunnel_conf {
	uint16_t rx_queue;
	uint16_t tx_queue;
	uint16_t udp_tunnel_port;
	uint16_t nb_flow;
	uint16_t filter_type;
	struct rte_eth_tunnel_flow *tunnel_flow;
};

If the ' nb_flow ' is set 2000, and you can configure 2000 flow rules on one queues on a port.

> The sense of tunnel is lack of interfaces in the system because number of
> possible VLANs is too small (4095).
> In the DPDK we have only one tunnel per physical port what is useless even
> with such big acceleration provided with i40e.

> In normal use cases there is a need for 10,000s of tunnels per interface. Even
> for Vxlan we have 24 bits for tunnel definition


We use flow director HW offload here, in terms of i40e, it support up to 8K flow rules of exact match.
This is HW limitation, 10,000s of tunnels per interface is not supported by HW.


> 5. I see that you have implementations for VXLAN,TEREDO, and GENEVE
> tunnels in i40e drivers. I could  find the implementation for VXLAN
> encap/decap. Are all files in the patch present?
No, I have not finished all of codes, just VXLAN here.
Other tunneling protocol will be added one by one in future.

> Regards,
> 
> Mirek
> 
> 
> 
> 
> > -----Original Message-----
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jijiang Liu
> > Sent: Wednesday, December 23, 2015 9:50 AM
> > To: dev at dpdk.org
> > Subject: [dpdk-dev] [RFC PATCH 0/6] General tunneling APIs
> >
> > I want to define a set of General tunneling APIs, which are used to
> > accelarate tunneling packet processing in DPDK, In this RFC patch set,
> > I wll explain my idea using some codes.
> >
> > 1. Using flow director offload to define a tunnel flow in a pair of queues.
> >
> > flow rule: src IP + dst IP + src port + dst port + tunnel ID (for
> > VXLAN)
> >
> > For example:
> > 	struct rte_eth_tunnel_conf{
> > 	.tunnel_type = VXLAN,
> > 	.rx_queue = 1,
> > 	.tx_queue = 1,
> > 	.filter_type = 'src ip + dst ip + src port + dst port + tunnel id'
> > 	.flow_tnl {
> >          	.tunnel_type = VXLAN,
> >          	.tunnel_id = 100,
> >          	.remote_mac = 11.22.33.44.55.66,
> >          .ip_type = ipv4,
> >          .outer_ipv4.src_ip = 192.168.10.1
> >          .outer_ipv4.dst_ip = 10.239.129.11
> >          .src_port = 1000,
> >          .dst_port =2000
> > };
> >
> > 2. Configure tunnel flow for a device and for a pair of queues.
> >
> > rte_eth_dev_tunnel_configure(0, &rte_eth_tunnel_conf);
> >
> > In this API, it will call RX decapsulation and TX encapsulation
> > callback function if HW doesn't support encap/decap, and a space will
> > be allocated for tunnel configuration and store a pointer to this new
> > allocated space as dev->post_rx/tx_burst_cbs[].param.
> >
> > rte_eth_add_rx_callback(port_id, tunnel_conf.rx_queue,
> >                         rte_eth_tunnel_decap, (void *)tunnel_conf);
> > rte_eth_add_tx_callback(port_id, tunnel_conf.tx_queue,
> >                         rte_eth_tunnel_encap, (void *)tunnel_conf)
> >
> > 3. Using rte_vxlan_decap_burst() to do decapsulation of tunneling packet.
> >
> > 4. Using rte_vxlan_encap_burst() to do encapsulation of tunneling packet.
> >    The 'src ip, dst ip, src port, dst port and  tunnel ID" can be got
> > from tunnel configuration.
> >    And SIMD is used to accelarate the operation.
> >
> > How to use these APIs, there is a example below:
> >
> > 1)at config phase
> >
> > dev_config(port, ...);
> > tunnel_config(port,...);
> > ...
> > dev_start(port);
> > ...
> > rx_burst(port, rxq,... );
> > tx_burst(port, txq,...);
> >
> >
> > 2)at transmitting packet phase
> > The only outer src/dst MAC address need to be set for TX tunnel
> > configuration in dev->post_tx_burst_cbs[].param.
> >
> > In this patch set, I have not finished all of codes, the purpose of
> > sending patch set is that I would like to collect more comments and
> > sugestions on this idea.
> >
> >
> > Jijiang Liu (6):
> >   extend rte_eth_tunnel_flow
> >   define tunnel flow structure and APIs
> >   implement tunnel flow APIs
> >   define rte_vxlan_decap/encap
> >   implement rte_vxlan_decap/encap
> >   i40e tunnel configure
> >
> >  drivers/net/i40e/i40e_ethdev.c             |   41 +++++
> >  lib/librte_ether/libtunnel/rte_vxlan_opt.c |  251
> > ++++++++++++++++++++++++++++
> >  lib/librte_ether/libtunnel/rte_vxlan_opt.h |   49 ++++++
> >  lib/librte_ether/rte_eth_ctrl.h            |   14 ++-
> >  lib/librte_ether/rte_ethdev.h              |   28 +++
> >  lib/librte_ether/rte_ethdev.c              |   60 ++
> >  5 files changed, 440 insertions(+), 3 deletions(-)  create mode
> > 100644 lib/librte_ether/libtunnel/rte_vxlan_opt.c
> >  create mode 100644 lib/librte_ether/libtunnel/rte_vxlan_opt.h
> >
> > --
> > 1.7.7.6



More information about the dev mailing list