From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 9964C5A52 for ; Mon, 28 Dec 2015 06:54:50 +0100 (CET) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga103.jf.intel.com with ESMTP; 27 Dec 2015 21:54:50 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,489,1444719600"; d="scan'208";a="20037596" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by fmsmga004.fm.intel.com with ESMTP; 27 Dec 2015 21:54:49 -0800 Received: from fmsmsx121.amr.corp.intel.com (10.18.125.36) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.248.2; Sun, 27 Dec 2015 21:54:48 -0800 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by fmsmsx121.amr.corp.intel.com (10.18.125.36) with Microsoft SMTP Server (TLS) id 14.3.248.2; Sun, 27 Dec 2015 21:54:48 -0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.111]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.220]) with mapi id 14.03.0248.002; Mon, 28 Dec 2015 13:54:46 +0800 From: "Liu, Jijiang" To: "Walukiewicz, Miroslaw" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [RFC PATCH 0/6] General tunneling APIs Thread-Index: AQHRPV74hAPWO2I4C02PeJAlz12jpp7X5i+AgAf9nEA= Date: Mon, 28 Dec 2015 05:54:46 +0000 Message-ID: <1ED644BD7E0A5F4091CF203DAFB8E4CC23F3DDDA@SHSMSX101.ccr.corp.intel.com> References: <1450860592-12673-1-git-send-email-jijiang.liu@intel.com> <7C4248CAE043B144B1CD242D2756265345564C3B@IRSMSX104.ger.corp.intel.com> In-Reply-To: <7C4248CAE043B144B1CD242D2756265345564C3B@IRSMSX104.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC PATCH 0/6] General tunneling APIs X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2015 05:54:51 -0000 Hi Miroslaw, The partial answer is below. > -----Original Message----- > From: Walukiewicz, Miroslaw > Sent: Wednesday, December 23, 2015 7:18 PM > To: Liu, Jijiang; dev@dpdk.org > Subject: RE: [dpdk-dev] [RFC PATCH 0/6] General tunneling APIs >=20 > Hi Jijang, >=20 > I like an idea of tunnel API very much. >=20 > I have a few questions. >=20 > 1. I see that you have only i40e support due to lack of HW tunneling supp= ort > 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 an= d > we can imagine about 40 or more different tunnels working with this NIC. >=20 > 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,= =20 If the framework is accepted, other tunneling protocol will be added one by= one in future.=20 > 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 queu= e > 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 >=20 > rte_eth_dev_tunnel_configure(uint8_t port_id, > + struct rte_eth_tunnel_conf *tunnel_conf) >=20 No, in terms of i40e, there will be up to 8K tunnels in one DPDK interfa= ce, 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 on= e 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 eve= n > 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, >=20 > Mirek >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jijiang Liu > > Sent: Wednesday, December 23, 2015 9:50 AM > > To: dev@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 que= ues. > > > > flow rule: src IP + dst IP + src port + dst port + tunnel ID (for > > VXLAN) > > > > For example: > > struct rte_eth_tunnel_conf{ > > .tunnel_type =3D VXLAN, > > .rx_queue =3D 1, > > .tx_queue =3D 1, > > .filter_type =3D 'src ip + dst ip + src port + dst port + tunnel id' > > .flow_tnl { > > .tunnel_type =3D VXLAN, > > .tunnel_id =3D 100, > > .remote_mac =3D 11.22.33.44.55.66, > > .ip_type =3D ipv4, > > .outer_ipv4.src_ip =3D 192.168.10.1 > > .outer_ipv4.dst_ip =3D 10.239.129.11 > > .src_port =3D 1000, > > .dst_port =3D2000 > > }; > > > > 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 packe= t. > > > > 4. Using rte_vxlan_encap_burst() to do encapsulation of tunneling packe= t. > > 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