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

Walukiewicz, Miroslaw Miroslaw.Walukiewicz at intel.com
Mon Jan 4 11:48:32 CET 2016


Hi Jijang, 

My comments below MW>

> -----Original Message-----
> From: Liu, Jijiang
> Sent: Monday, December 28, 2015 6:55 AM
> To: Walukiewicz, Miroslaw; dev at dpdk.org
> Subject: RE: [dpdk-dev] [RFC PATCH 0/6] General tunneling APIs
> 
> 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?

MW> Unfortunately I do not see any explanation for using tx_queue parameter in this thread. 
For me this parameter is not necessary. The tunnels will work without it anyway as they are set in the packet descriptor.

> 
> > 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.

MW> so in your design the tunnel_flow is table of rte_eth_tunnel_flow structures. 
I did not catch it.

I hope that you will add a possibility to dynamically adding/removing tunnels from interface.

 What is a sense of the udp_tunnel_port parameter as the tunnel_flow structure also provides the same parameter.

Similar the tunnel_type should be a part of the tunnel_flow also as we assume to support different tunnels on single interface (not just VXLAN only)

> 
> > 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