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 EBE6258D2 for ; Tue, 28 Oct 2014 02:11:06 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga103.jf.intel.com with ESMTP; 27 Oct 2014 18:18:13 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,799,1406617200"; d="scan'208";a="626611535" Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82]) by orsmga002.jf.intel.com with ESMTP; 27 Oct 2014 18:19:49 -0700 Received: from kmsmsx153.gar.corp.intel.com (172.21.73.88) by PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 28 Oct 2014 09:18:28 +0800 Received: from shsmsx103.ccr.corp.intel.com (10.239.110.14) by KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 28 Oct 2014 09:18:28 +0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.174]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.207]) with mapi id 14.03.0195.001; Tue, 28 Oct 2014 09:18:28 +0800 From: "Wu, Jingjing" To: Thomas Monjalon Thread-Topic: [dpdk-dev] [PATCH v4 04/21] ethdev: define structures for adding/deleting flow director Thread-Index: AQHP7ZPPNc+2H8CRV0KURqsXeZUV9ZxDrQgAgAEFkqA= Date: Tue, 28 Oct 2014 01:18:27 +0000 Message-ID: <9BB6961774997848B5B42BEC655768F8B2467E@SHSMSX104.ccr.corp.intel.com> References: <1411711418-12881-1-git-send-email-jingjing.wu@intel.com> <1413939687-11177-1-git-send-email-jingjing.wu@intel.com> <1413939687-11177-5-git-send-email-jingjing.wu@intel.com> <3042428.RIRLHjG5pO@xps13> In-Reply-To: <3042428.RIRLHjG5pO@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v4 04/21] ethdev: define structures for adding/deleting flow director 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, 28 Oct 2014 01:11:07 -0000 Archived-At: List-Archive: Hi, Thomas > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Tuesday, October 28, 2014 12:58 AM > To: Wu, Jingjing > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v4 04/21] ethdev: define structures for > adding/deleting flow director >=20 > 2014-10-22 09:01, Jingjing Wu: > > +/** > > + * A structure used to define the input for IPV4 UDP flow */ struct > > +rte_eth_udpv4_flow { > > + uint32_t src_ip; /**< IPv4 source address to match. */ > > + uint32_t dst_ip; /**< IPv4 destination address to match. */ > > + uint16_t src_port; /**< UDP Source port to match. */ > > + uint16_t dst_port; /**< UDP Destination port to match. */ > > +}; > > + > > +/** > > + * A structure used to define the input for IPV4 TCP flow */ struct > > +rte_eth_tcpv4_flow { > > + uint32_t src_ip; /**< IPv4 source address to match. */ > > + uint32_t dst_ip; /**< IPv4 destination address to match. */ > > + uint16_t src_port; /**< TCP Source port to match. */ > > + uint16_t dst_port; /**< TCP Destination port to match. */ > > +}; > > + > > +/** > > + * A structure used to define the input for IPV4 SCTP flow */ struct > > +rte_eth_sctpv4_flow { > > + uint32_t src_ip; /**< IPv4 source address to match. */ > > + uint32_t dst_ip; /**< IPv4 destination address to match. */ > > + uint32_t verify_tag; /**< verify tag to match */ > > +}; > > + > > +/** > > + * A structure used to define the input for IPV4 flow */ struct > > +rte_eth_ipv4_flow { > > + uint32_t src_ip; /**< IPv4 source address to match. */ > > + uint32_t dst_ip; /**< IPv4 destination address to match. */ > > +}; >=20 > Why not defining only 1 structure? > struct rte_eth_ipv4_flow { > uint32_t src_ip; > uint32_t dst_ip; > uint16_t src_port; > uint16_t dst_port; > uint32_t sctp_tag; > }; >=20 > I think the same structure could be used for many filters (not only flow > director). >=20 Yes, one structure can contain all the elements we need, but I think it wil= l be clearer that each kind of flow type has its key words. =20 > > +#define RTE_ETH_FDIR_MAX_FLEXWORD_LEN 8 > > +/** > > + * A structure used to contain extend input of flow */ struct > > +rte_eth_fdir_flow_ext { > > + uint16_t vlan_tci; > > + uint8_t num_flexwords; /**< number of flexwords */ > > + uint16_t flexwords[RTE_ETH_FDIR_MAX_FLEXWORD_LEN]; > > + uint16_t dest_id; /**< destination vsi or pool id*/ > > +}; >=20 > Flexword should be explained. >=20 The flexword means the application can choose a part of packet's payload as= key words to compare match. It is flexible. In Ixgbe, the flexwords is 1 w= ord (2 bytes), while Fortville extend it to 8 words. > > +/** > > + * A structure used to define the input for an flow director filter > > +entry >=20 > typo: for *a* flow director Yes, will change. >=20 > > + */ > > +struct rte_eth_fdir_input { > > + enum rte_eth_flow_type flow_type; /**< type of flow */ > > + union rte_eth_fdir_flow flow; /**< specific flow structure *= / > > + struct rte_eth_fdir_flow_ext flow_ext; /**< specific flow info */ }; >=20 > I don't understand the logic behind flow/flow_ext. > Why flow_ext is not merged into flow ? >=20 The flow defines the key words for each flow_type, while the flow_ext has o= ther elements which have little to do with flow_type. For example the flexw= ord, dst_id (can used as pool id), I think it is not reasonable to make it = as an element in the flow. > > +/** > > + * Flow director report status > > + */ > > +enum rte_eth_fdir_status { > > + RTE_ETH_FDIR_NO_REPORT_STATUS =3D 0, /**< no report FDIR. */ > > + RTE_ETH_FDIR_REPORT_FD_ID, /**< only report FD ID. */ > > + RTE_ETH_FDIR_REPORT_FD_ID_FLEX_4, /**< report FD ID and 4 flex > bytes. */ > > + RTE_ETH_FDIR_REPORT_FLEX_8, /**< report 8 flex bytes. */ > > +}; >=20 > The names and explanations are cryptics. The enum defines what will be reported when FIR match. Can be FD_ID or flex= bytes > Is FD redundant with FDIR? Yes, good point. Will remove FD. >=20 > > +/** > > + * A structure used to define an action when match FDIR packet filter. > > + */ > > +struct rte_eth_fdir_action { > > + uint16_t rx_queue; /**< queue assigned to if fdir match. */ > > + uint16_t cnt_idx; /**< statistic counter index */ >=20 > what is the action of "statistic counter index"? When FD match happened, the counter will increase. Fortville can support to= configure the different counter for filter entries. The action is a part o= f a filter entry, so this element means which counter the entry will use. = =20 >=20 > > + uint8_t drop; /**< accept or reject */ > > + uint8_t flex_off; /**< offset used define words to report */ >=20 > still difficult to understand the flex logic Just as mentioned above, Fortville can support 8 flex words comparing. But = for reporting, only 4 or 8 bytes in the flex words can be reported. So need= to specify the offset to choose the 4 or 8 bytes. >=20 > > + enum rte_eth_fdir_status report_status; /**< status report option > > +*/ }; >=20 > > +/** > > + * A structure used to define the flow director filter entry by > > +filter_ctl API > > + * to support RTE_ETH_FILTER_FDIR with RTE_ETH_FILTER_ADD and > > + * RTE_ETH_FILTER_DELETE operations. > > + */ > > +struct rte_eth_fdir_filter { > > + uint32_t soft_id; /**< id */ >=20 > Should the application handle the id numbering? > Why is it soft_id instead of id? Yes, the soft_id is just id, is also reported id when entry match. The id i= s specified by user, and can be used to identify this entry, application sh= ould handle it. >=20 > > + struct rte_eth_fdir_input input; /**< input set */ > > + struct rte_eth_fdir_action action; /**< action taken when match */ > > +}; >=20 > It's really a hard job to define a clear and easy to use API. > It would be really interesting to have more people involved in this discu= ssion. Agree too. Thank you! > Thanks > -- > Thomas