[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