From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id EA0257E23 for ; Fri, 18 Dec 2015 03:00:26 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga104.fm.intel.com with ESMTP; 17 Dec 2015 18:00:26 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,443,1444719600"; d="scan'208";a="710093855" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga003.jf.intel.com with ESMTP; 17 Dec 2015 18:00:25 -0800 Received: from fmsmsx117.amr.corp.intel.com (10.18.116.17) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 17 Dec 2015 18:00:25 -0800 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by fmsmsx117.amr.corp.intel.com (10.18.116.17) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 17 Dec 2015 18:00:24 -0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.190]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.105]) with mapi id 14.03.0248.002; Fri, 18 Dec 2015 10:00:22 +0800 From: "Liu, Jijiang" To: Ivan Boule Thread-Topic: [dpdk-dev] [PATCH v3] doc: announce ABI change for struct rte_eth_conf Thread-Index: AQHRNkPqc61+oU44h0OWcsv7s6i08Z7LOKQAgATEYkA= Date: Fri, 18 Dec 2015 02:00:22 +0000 Message-ID: <1ED644BD7E0A5F4091CF203DAFB8E4CC22BF1A60@SHSMSX101.ccr.corp.intel.com> References: <1450079331-28139-1-git-send-email-jijiang.liu@intel.com> <566FD452.6060309@6wind.com> In-Reply-To: <566FD452.6060309@6wind.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 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v3] doc: announce ABI change for struct rte_eth_conf 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: Fri, 18 Dec 2015 02:00:27 -0000 Hi Boule, > -----Original Message----- > From: Ivan Boule [mailto:ivan.boule@6wind.com] > Sent: Tuesday, December 15, 2015 4:50 PM > To: Liu, Jijiang > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v3] doc: announce ABI change for struct > rte_eth_conf >=20 > On 12/14/2015 08:48 AM, Jijiang Liu wrote: > > In current codes, tunnel configuration information is not stored in a d= evice > configuration, and it will get nothing if application want to retrieve tu= nnel > config, so I think it is necessary to add rte_eth_dev_tunnel_configure() > function is to do the configurations including flow and classification > information and store it in a device configuration. > > > > And tunneling packet encapsulation operation will benifit from the chan= ge. > > > > There are more descriptions for the ABI changes below, > > > > The struct 'rte_eth_tunnel_conf' is a new, its defination like below, > > struct rte_eth_tunnel_conf { > > uint16_t tx_queue; > > uint16_t filter_type; > > struct rte_eth_tunnel_flow flow_tnl; }; > > > > The ABI change announcement of struct 'rte_eth_tunnel_flow' have > already sent out, refer to [1]. > > > > [1]http://dpdk.org/ml/archives/dev/2015-December/029837.html. > > > > The change of struct 'rte_eth_conf' like below, but it have not finaliz= ed yet. > > struct rte_eth_conf { > > ... > > uint32_t dcb_capability_en; > > struct rte_fdir_conf fdir_conf; /**< FDIR configuration. */ > > struct rte_intr_conf intr_conf; /**< Interrupt mode configuration. */ > > struct rte_eth_tunnel_conf > *tunnel_conf[RTE_MAX_QUEUES_PER_PORT]; > > /**< Tunnel configuration. */ > > }; > > > > v2 change: > > Add more description for the change. > > > > v3 change: > > Change ABI announcement description. > > > > Signed-off-by: Jijiang Liu ---cmdline.c > > doc/guides/rel_notes/deprecation.rst | 6 ++++++ > > 1 files changed, 6 insertions(+), 0 deletions(-) > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > > b/doc/guides/rel_notes/deprecation.rst > > index 5c458f2..9dbe89e 100644 > > --- a/doc/guides/rel_notes/deprecation.rst > > +++ b/doc/guides/rel_notes/deprecation.rst > > @@ -23,3 +23,9 @@ Deprecation Notices > > * ABI changes are planned for struct rte_eth_tunnel_flow in order to > extend new fileds to support > > tunneling packet configuration in unified tunneling APIs. The relea= se 2.2 > does not contain these ABI > > changes, but release 2.3 will, and no backwards compatibility is pl= anned. > > + > > +* ABI changes are planned for the struct rte_eth_conf in order to add > > +'tunnel_conf' variable > > + in the struct to store tunnel configuration when using new API > > +rte_eth_dev_tunnel_configure > > + (uint8_t port_id, uint16_t rx_queue, struct rte_eth_tunnel_conf * > > +tunnel_conf) to configure > > + tunnel flow and classification information. The release 2.2 does > > +not contain these ABI change, > > + but release 2.3 will, and no backward compatibility is planned. > > > Hi Jijiang, >=20 > Can you provide a real use case - I mean an example of a real network > application - that really needs to save tunnel configurations in a data > structure associated with a NIC port? I'm trying to provide a tunneling packet solution in DPDK, which would acce= lerate de/encapsulation operation of tunneling packet. It was described at [1], [1] http://dpdk.org/ml/archives/dev/2015-December/030283.html Let me provide more details on this, these data structure definition have n= ot fully finalized yet, just for your reference. We are talking about why tunnel configuration need to be stored. strucrt rte_eth_tunnel_conf tc;=20 .... rte_eth_dev_configure(port, ...); for(...) {rte_eth_rx_queue_setup(port, ...);} rte_eth_tunnel_config(port, &tc); Here we need to the configuration when encapsulating tunnel packet. struct rte_eth_tunnel_conf { uint16_t rx_queue; uint16_t tx_queue; uint16_t filter_type; =20 struct rte_eth_tunnel_flow flow_tnl; }; struct rte_eth_tunnel_flow { enum rte_eth_tunnel_type tunnel_type; uint64_t tunnel_id; /**< Tunnel ID to match. TNI, VNI... */ uint16_t flags; struct ether_addr remote_mac; enum rte_tunnel_iptype ip_type; /**< IP address type. */ union { struct rte_eth_ipv4_flow outer_ipv4; struct rte_eth_ipv6_flow outer_ipv6; } ip_addr; uint16_t dst_port; uint16_t src_port; }; We will do the following configuration, 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'=20 .flow_tnl { . tunnel_type =3D VXLAN, . tunnel_id =3D 100, . ip_type =3D ipv4,=20 . 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 }; For NIC A RX process, VM 0--->VTEP A---> VXLAN network--->VTEP B---NIC A (Rx queue 1 with info [1= ] )--->SW decapsulation--->vSwitch--->VM 0 For NIC A TX process, VM 0<---VTEP A<---VXLAN network<---VTEP B<---NIC A (TX queue 1)<---SW Encap= sulation with info[2]<---vSwitch<---VM 0 The[2] information will be got by retrieving the tunnel configuration, if = the tunnel configuration is not stored in 'rt_eth_conf', and how to get it= ? =20 Of course, the tunnel configuration is also stored in Application, does it = make sense? [1] outr src ip(192.168.10.1) + outer dst ip(10.239.129.11) + outer src por= t(1000) + outer dst port(2000) + tunnel id(100) [2] outer src ip(10.239.129.11) + outer dst ip(192.168.10.1) + outer src po= rt(2000) + outr dst port(1000) + tunnel id(100) >=20 > Firstly, if the only usage is to enable applications to retrieve tunnel > configurations, then you are simply growing the size of the per-port stru= cture > with tunnel configurations, and imposing it to every DPDK application. > You impose it to those applications that don't care about tunneling, but = also > to those applications which do care, but which prefer to have their own > representation of ports where they store everything they need to. > If the tunnel configuration is also used for other purposes, then it must= be > precisely described what happens with the saved tunnel configuration when > the application changes the state of a port. > This is the case for instance when the application reconfigures the numbe= r of > RX queues of a port. > Who is responsible for checking that some tunnels won't be matched > anymore? > Who is responsible for dropping/invalidating the saved tunnel configurati= on, > if such operations must be performed? > This list is likely to be not exhaustive, of course. About above these question, it is related to design, I will send RFC patch = out for review. >=20 > More globally, all side-effects of saving the tunnel configuration must b= e > considered and addressed in a coherent way and in an easy-to-use approach= . >=20 > By the way, as far as I know, the Linux kernel does not [need to] save tu= nnel > data or ARP entries behind "netdevice" structures. It is not related ARP entries, I'm talking about tunnel flow. > PS : in the "rte_eth_tunnel_conf" data structure, I think that the first = field > should be named "rx_queue" instead of "tx_queue". No, 'rx_queue' id can be as index of tunnel_conf[RTE_MAX_QUEUES_PER_PORT]; It depends on final design. > Regards, > Ivan >=20 > -- > Ivan Boule > 6WIND Development Engineer