From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 88C6A7E75 for ; Wed, 29 Oct 2014 02:22:04 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 28 Oct 2014 18:30:52 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,807,1406617200"; d="scan'208";a="627308695" Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82]) by orsmga002.jf.intel.com with ESMTP; 28 Oct 2014 18:30:51 -0700 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 29 Oct 2014 09:29:38 +0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.174]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.13]) with mapi id 14.03.0195.001; Wed, 29 Oct 2014 09:29:36 +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+2H8CRV0KURqsXeZUV9ZxDrQgAgAEFkqCAAE8wgIABTSag Date: Wed, 29 Oct 2014 01:29:36 +0000 Message-ID: <9BB6961774997848B5B42BEC655768F8B24EE7@SHSMSX104.ccr.corp.intel.com> References: <1411711418-12881-1-git-send-email-jingjing.wu@intel.com> <3042428.RIRLHjG5pO@xps13> <9BB6961774997848B5B42BEC655768F8B2467E@SHSMSX104.ccr.corp.intel.com> <1719360.TZiYukypUI@xps13> In-Reply-To: <1719360.TZiYukypUI@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: Wed, 29 Oct 2014 01:22:05 -0000 Hi, Thomas Thanks for your comments. Jingjing > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Tuesday, October 28, 2014 9:18 PM > 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-28 01:18, Wu, Jingjing: > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > > 2014-10-22 09:01, Jingjing Wu: > > > > +#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*/ > > > > +}; > > > > > > Flexword should be explained. > > > > > 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 word (2 bytes), while Fortville extend it = to 8 > words. >=20 > OK. The problem is that I don't know how to fill the flexwords bytes. > You should explain it in the doxygen comment. > You say it's flexible. Is it usable with a non-IP packet? > Please explain constraints and syntax. >=20 OK. Will add more explanations in comments. > > > > +struct rte_eth_fdir_input { > > > > + enum rte_eth_flow_type flow_type; /**< type of flow */ > > > > + union rte_eth_fdir_flow flow; /**< specific flow structu= re */ > > > > + struct rte_eth_fdir_flow_ext flow_ext; /**< specific flow info > > > > +*/ }; > > > > > > I don't understand the logic behind flow/flow_ext. > > > Why flow_ext is not merged into flow ? > > > > > The flow defines the key words for each flow_type, while the flow_ext > > has other elements which have little to do with flow_type. > > For example the flexword, dst_id (can used as pool id), I think it is > > not reasonable to make it as an element in the flow. >=20 > Sorry, I don't understand. > flow and flow_ext are associated with a flow type. Take an example like: flow_type is IPV4, and the key words in IP is suppose= d to be dst_ip and src_ip. Other fields like dst_id has little to do with IPV= 4. > The comments are "specific flow structure" and "specific flow info" which > doesn't bring any useful information. >=20 OK, I think I need to change the comments. > > > > +/** > > > > + * 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. */ > > > > +}; > > > > > > The names and explanations are cryptics. > > > > The enum defines what will be reported when FIR match. > > Can be FD_ID or flex bytes >=20 > Just to be sure, have you understood that I'm requesting more explanation= s > in the comments to allow users of your API to understand it? > OK, get it. =20 > > > > +/** > > > > + * A structure used to define an action when match FDIR packet fil= ter. > > > > + */ > > > > +struct rte_eth_fdir_action { > > > > + uint16_t rx_queue; /**< queue assigned to if fdir match. *= / > > > > + uint16_t cnt_idx; /**< statistic counter index */ > > > > > > what is the action of "statistic counter index"? > > > > When FD match happened, the counter will increase. >=20 > Which counter? > Which value should be set in cnt_idx? >=20 A hardware counter provided in Fortville. It supposed that the user know ab= out the hardware, or just set to 0 if don't specify a counter, a default counte= r will be used for all entries. I will add more comments.=20 > > Fortville can support to configure the different counter for filter ent= ries. > > The action is a part of a filter entry, so this element means which cou= nter > the entry will use. >=20 > I perfectly understand that you are writing some code to allow usage of > Fortville features through DPDK. Thank you for bringing new features. > But I want to know if I'm allowed to use it without reading the Fortville > datasheet? Yes, you can. But for same extended functions, need more explanation. You are correct, I need to add more explanation. > And could this API be shared by other hardwares (e.g. ixgbe)? Yes, I also considered about it during design. And the integrating ixgbe's = flow=20 director to the API is ready. I plan to send another patch for it when=20 this patch set is applied. >=20 > > > > + uint8_t drop; /**< accept or reject */ > > > > + uint8_t flex_off; /**< offset used define words to report= */ > > > > > > 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 > I don't even know what are the meaning of these 4 or 8 bytes. Additional, these 4 or 8 bytes are a part of the 8 flex words. > Please don't consider that every DPDK user know the Fortville datasheet. OK. More comments. >=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 */ > > > > > > 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 is specified by user, and can be used to identify this entry, > > application should handle it. >=20 > OK, so explain it in comments. OK. > Or better, generate and return the id when creating a filter. >=20 > Thanks > -- > Thomas