From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 3AB387E9A for ; Tue, 21 Oct 2014 22:41:04 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP; 21 Oct 2014 10:56:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="403520424" Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82]) by FMSMGA003.fm.intel.com with ESMTP; 21 Oct 2014 06:41:00 -0700 Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 21 Oct 2014 21:48:35 +0800 Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 21 Oct 2014 21:48:34 +0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.202]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.207]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 21:48:28 +0800 From: "Liu, Jijiang" To: Thomas Monjalon Thread-Topic: [dpdk-dev] [PATCH v6 2/9] librte_ether:add VxLAN packet identification API in librte_ether Thread-Index: AQHP7Rz/36CcrBji70yGvoQoDSEZtJw6h8/A Date: Tue, 21 Oct 2014 13:48:27 +0000 Message-ID: <1ED644BD7E0A5F4091CF203DAFB8E4CC01D82530@SHSMSX101.ccr.corp.intel.com> References: <1413881168-20239-1-git-send-email-jijiang.liu@intel.com> <1413881168-20239-3-git-send-email-jijiang.liu@intel.com> <3607443.z2coKxdkI7@xps13> In-Reply-To: <3607443.z2coKxdkI7@xps13> 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="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v6 2/9] librte_ether:add VxLAN packet identification API in librte_ether 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: Tue, 21 Oct 2014 20:41:05 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Tuesday, October 21, 2014 6:51 PM > To: Liu, Jijiang > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v6 2/9] librte_ether:add VxLAN packet > identification API in librte_ether >=20 > 2014-10-21 16:46, Jijiang Liu: > > There are "some" destination UDP port numbers that have unque meaning. > > In terms of VxLAN, "IANA has assigned the value 4789 for the VXLAN UDP > > port, and this value SHOULD be used by default as the destination UDP > > port. Some early implementations of VXLAN have used other values for > > the destination port. To enable interoperability with these > implementations, the destination port SHOULD be configurable." > > > > Add two APIs in librte_ether for supporting UDP tunneling port > configuration on i40e. > > Currently, only VxLAN is implemented in this patch set. >=20 > Actually, there are 2 different things in this patch > - new tunnelling API > - VXLAN macros > Please split in 2 patches. Ok > > int > > +rte_eth_dev_udp_tunnel_add(uint8_t port_id, > > + struct rte_eth_udp_tunnel *udp_tunnel, > > + uint8_t count) > > +{ > > + uint8_t i; > > + struct rte_eth_dev *dev; > > + struct rte_eth_udp_tunnel *tunnel; > > + > > + if (port_id >=3D nb_ports) { > > + PMD_DEBUG_TRACE("Invalid port_id=3D%d\n", port_id); > > + return -ENODEV; > > + } > > + > > + if (udp_tunnel =3D=3D NULL) { > > + PMD_DEBUG_TRACE("Invalid udp_tunnel parameter\n"); > > + return -EINVAL; > > + } > > + tunnel =3D udp_tunnel; > > + > > + for (i =3D 0; i < count; i++, tunnel++) { > > + if (tunnel->prot_type >=3D RTE_TUNNEL_TYPE_MAX) { > > + PMD_DEBUG_TRACE("Invalid tunnel type\n"); > > + return -EINVAL; > > + } > > + } >=20 > I'm not sure it's a good idea to provide a count parameter to iterate in = a > loop. > It's probably something that the application should do by itself. It is necessary to check if this prot_type(tunnel type) is valid here in ca= se applications don't do that.=20 > > + > > + dev =3D &rte_eth_devices[port_id]; > > + FUNC_PTR_OR_ERR_RET(*dev->dev_ops->udp_tunnel_add, - > ENOTSUP); > > + return (*dev->dev_ops->udp_tunnel_add)(dev, udp_tunnel, count); } >=20 > [...] >=20 > > +/** > > + * Tunneled type. > > + */ > > +enum rte_eth_tunnel_type { > > + RTE_TUNNEL_TYPE_NONE =3D 0, > > + RTE_TUNNEL_TYPE_VXLAN, > > + RTE_TUNNEL_TYPE_GENEVE, > > + RTE_TUNNEL_TYPE_TEREDO, > > + RTE_TUNNEL_TYPE_NVGRE, > > + RTE_TUNNEL_TYPE_MAX, > > +}; >=20 > This is moved later from rte_ethdev.h to rte_eth_ctrl.h. > Please choose where is the right location in this patch. > By the way, I think ethdev is the right location because it's not directl= y > related to ctrl API, right? It is used in both rte_ethdev.h file and rte_eth_ctrl.h file. =1B$B!!=1B(B In rte_eth_ctrl.h file, it is used in rte_eth_tunnel_filter_conf structure. +struct rte_eth_tunnel_filter_conf { + ... + enum rte_eth_tunnel_type tunnel_type; /**< Tunnel Type. */ + ... +}; I will put the rte_eth_tunnel_type definition in the rte_eth_ctrl.h file at= the beginning of definition. > > struct rte_eth_conf { > > + enum rte_eth_tunnel_type tunnel_type; > > uint16_t link_speed; > > /**< ETH_LINK_SPEED_10[0|00|000], or 0 for autonegotation */ > > uint16_t link_duplex; >=20 > Please don't add this field as the first. It's more logical to start port > configuration with link speed, duplex, etc. ok > Then please add a comment to explain how it should be used. I will add more comment for it. > But I doubt we should configure a tunnel type for a whole port. Yes, your understanding is correct. It is for a whole port/PF, that's why w= e should add=20 tunnel_type in rte_eth_conf structure. > There's something weird here. > > +/* VXLAN protocol header */ >=20 > This comment should be doxygen'ed. >=20 > > +struct vxlan_hdr { > > + uint32_t vx_flags; /**< VxLAN flag. */ > > + uint32_t vx_vni; /**< VxLAN ID. */ > > +} __attribute__((__packed__)); > > + > [...] > > #define ETHER_TYPE_VLAN 0x8100 /**< IEEE 802.1Q VLAN tagging. */ > > #define ETHER_TYPE_1588 0x88F7 /**< IEEE 802.1AS 1588 Precise Time > > Protocol. */ > > > > +#define ETHER_VXLAN_HLEN (sizeof(struct udp_hdr) + sizeof(struct > > +vxlan_hdr)) >=20 > Please add a doxygen comment. ok > -- > Thomas