From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by dpdk.org (Postfix) with ESMTP id 5996D7E9A for ; Tue, 28 Oct 2014 14:09:02 +0100 (CET) Received: by mail-wg0-f43.google.com with SMTP id n12so825443wgh.2 for ; Tue, 28 Oct 2014 06:17:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=KfXfqLswI31nJijpWvCd6cNNeZ/lBZSoAJYZXbflV3U=; b=UPvK89AWjRiim8ha3nP2WA3bKtE14Z6aK+SZ1Y//3d46BG9Jlcaea440GAlnd7ywkg iTT4makA7WVVLvXmyJTgOl2ZXiZ3zqxdqhfWIbtKmrWJbEySB/8BQj6UfdVnjjmDZO3h TNQO01i2fN5cj9v2sAfWmq3l2EttBcp2/0MzYpoFy9FSkGPyBusA/oBq2/JYHmJ/VI6T Omap7OR8fB8nKFM6USP2xlRsyT3W3EUMRIls+MnWq/eUC5w+axQdR0ywn52qt6G+Nos0 4U2G7GPkD+79bSVVpRW7ECyEQEDAZh2xYGT6XPyhlmIYoOIssHALVqmyuBGjWqN0O3Oc 9SYw== X-Gm-Message-State: ALoCoQljHt/6GVlZRepyUeuauvavGc0GGdSNbVvek8RJQ6iGbo2K1aUQrItaCCTa9RdZ7MZ4DsWy X-Received: by 10.194.63.229 with SMTP id j5mr4219689wjs.23.1414502269365; Tue, 28 Oct 2014 06:17:49 -0700 (PDT) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id m6sm2188489wiy.16.2014.10.28.06.17.48 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Oct 2014 06:17:48 -0700 (PDT) From: Thomas Monjalon To: "Wu, Jingjing" Date: Tue, 28 Oct 2014 14:17:31 +0100 Message-ID: <1719360.TZiYukypUI@xps13> Organization: 6WIND User-Agent: KMail/4.14.2 (Linux/3.17.1-1-ARCH; KDE/4.14.2; x86_64; ; ) In-Reply-To: <9BB6961774997848B5B42BEC655768F8B2467E@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> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 13:09:02 -0000 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. 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. > > > +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 */ }; > > > > 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. Sorry, I don't understand. flow and flow_ext are associated with a flow type. The comments are "specific flow structure" and "specific flow info" which doesn't bring any useful information. > > > +/** > > > + * Flow director report status > > > + */ > > > +enum rte_eth_fdir_status { > > > + RTE_ETH_FDIR_NO_REPORT_STATUS = 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 Just to be sure, have you understood that I'm requesting more explanations in the comments to allow users of your API to understand it? > > > +/** > > > + * 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 */ > > > > what is the action of "statistic counter index"? > > When FD match happened, the counter will increase. Which counter? Which value should be set in cnt_idx? > Fortville can support to configure the different counter for filter entries. > The action is a part of a filter entry, so this element means which counter the entry will use. 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? And could this API be shared by other hardwares (e.g. ixgbe)? > > > + 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. I don't even know what are the meaning of these 4 or 8 bytes. Please don't consider that every DPDK user know the Fortville datasheet. > > > +/** > > > + * 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. OK, so explain it in comments. Or better, generate and return the id when creating a filter. Thanks -- Thomas