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 7AE9B2986 for ; Wed, 17 May 2017 16:54:32 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 May 2017 07:54:31 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.38,354,1491289200"; d="scan'208";a="87957758" Received: from irsmsx152.ger.corp.intel.com ([163.33.192.66]) by orsmga002.jf.intel.com with ESMTP; 17 May 2017 07:54:30 -0700 Received: from irsmsx112.ger.corp.intel.com (10.108.20.5) by IRSMSX152.ger.corp.intel.com (163.33.192.66) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 17 May 2017 15:54:29 +0100 Received: from irsmsx109.ger.corp.intel.com ([169.254.13.12]) by irsmsx112.ger.corp.intel.com ([169.254.1.61]) with mapi id 14.03.0319.002; Wed, 17 May 2017 15:54:29 +0100 From: "Ananyev, Konstantin" To: "Yigit, Ferruh" , "dev@dpdk.org" CC: "Yigit, Ferruh" , "Mcnamara, John" , "Tahhan, Maryam" Thread-Topic: [dpdk-dev] [RFC 17.08] flow_classify: add librte_flow_classify library Thread-Index: AQHSugeyObvZmE+/7ESUsHajNBGNXKH4vKJQ Date: Wed, 17 May 2017 14:54:28 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772583FAF774A@IRSMSX109.ger.corp.intel.com> References: <20170420185448.19162-1-ferruh.yigit@intel.com> <20170420185448.19162-2-ferruh.yigit@intel.com> In-Reply-To: <20170420185448.19162-2-ferruh.yigit@intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC 17.08] flow_classify: add librte_flow_classify library X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 14:54:33 -0000 Hi Ferruh, Please see my comments/questions below. Thanks Konstantin > + > +/** > + * @file > + * > + * RTE Flow Classify Library > + * > + * This library provides flow record information with some measured prop= erties. > + * > + * Application can select variety of flow types based on various flow ke= ys. > + * > + * Library only maintains flow records between rte_flow_classify_stats_g= et() > + * calls and with a maximum limit. > + * > + * Provided flow record will be linked list rte_flow_classify_stat_xxx > + * structure. > + * > + * Library is responsible from allocating and freeing memory for flow re= cord > + * table. Previous table freed with next rte_flow_classify_stats_get() c= all and > + * all tables are freed with rte_flow_classify_type_reset() or > + * rte_flow_classify_type_set(x, 0). Memory for table allocated on the f= ly while > + * creating records. > + * > + * A rte_flow_classify_type_set() with a valid type will register Rx/Tx > + * callbacks and start filling flow record table. > + * With rte_flow_classify_stats_get(), pointer sent to caller and meanwh= ile > + * library continues collecting records. > + * > + * Usage: > + * - application calls rte_flow_classify_type_set() for a device > + * - library creates Rx/Tx callbacks for packets and start filling flow= table Does it necessary to use an RX callback here? Can library provide an API like collect(port_id, input_mbuf[], pkt_num) ins= tead? So the user would have a choice either setup a callback or call collect() d= irectly.=20 > + * for that type of flow (currently only one flow type supported) > + * - application calls rte_flow_classify_stats_get() to get pointer to = linked > + * listed flow table. Library assigns this pointer to another value a= nd keeps > + * collecting flow data. In next rte_flow_classify_stats_get(), libra= ry first > + * free the previous table, and pass current table to the application= , keep > + * collecting data. Ok, but that means that you can't use stats_get() for the same type from 2 different threads without explicit synchronization? > + * - application calls rte_flow_classify_type_reset(), library unregist= ers the > + * callbacks and free all flow table data. > + * > + */ > + > +enum rte_flow_classify_type { > + RTE_FLOW_CLASSIFY_TYPE_GENERIC =3D (1 << 0), > + RTE_FLOW_CLASSIFY_TYPE_MAX, > +}; > + > +#define RTE_FLOW_CLASSIFY_TYPE_MASK =3D (((RTE_FLOW_CLASSIFY_TYPE_MAX - = 1) << 1) - 1) > + > +/** > + * Global configuration struct > + */ > +struct rte_flow_classify_config { > + uint32_t type; /* bitwise enum rte_flow_classify_type values */ > + void *flow_table_prev; > + uint32_t flow_table_prev_item_count; > + void *flow_table_current; > + uint32_t flow_table_current_item_count; > +} rte_flow_classify_config[RTE_MAX_ETHPORTS]; > + > +#define RTE_FLOW_CLASSIFY_STAT_MAX UINT16_MAX > + > +/** > + * Classification stats data struct > + */ > +struct rte_flow_classify_stat_generic { > + struct rte_flow_classify_stat_generic *next; > + uint32_t id; > + uint64_t timestamp; > + > + struct ether_addr src_mac; > + struct ether_addr dst_mac; > + uint32_t src_ipv4; > + uint32_t dst_ipv4; > + uint8_t l3_protocol_id; > + uint16_t src_port; > + uint16_t dst_port; > + > + uint64_t packet_count; > + uint64_t packet_size; /* bytes */ > +}; Ok, so if I understood things right, for generic type it will always classi= fy all incoming packets by: = =20 all by absolute values, and represent results as a linked list. Is that correct, or I misunderstood your intentions here? If so, then I see several disadvantages here: 1) It is really hard to predict what kind of stats is required for that par= ticular cases. Let say some people would like to collect stat by , another by , third ones by and so on. Having just one hardcoded filter doesn't seem very felxable/usable. I think you need to find a way to allow user to define what type of filter = they want to apply. I think it was discussed already, but I still wonder why rte_flow_item can'= t be used for that approach? 2) Even one 10G port can produce you ~14M rte_flow_classify_stat_generic e= ntries in one second (all packets have different ipv4/ports or so). Accessing/retrieving items over linked list with 14M entries - doesn't soun= d like a good idea. I'd say we need some better way to retrieve/present collected data.