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
