From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by dpdk.org (Postfix) with ESMTP id 1AB885946 for ; Thu, 28 Aug 2014 12:52:44 +0200 (CEST) Received: by mail-wi0-f173.google.com with SMTP id cc10so358038wib.0 for ; Thu, 28 Aug 2014 03:56:52 -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=Y0bbjqkTDMvVGC40ozzv9rZ0JndPQAA9A239zLqCfgw=; b=k3d2n5wOp1WGJ5t2CppWvGT7AjKCUpddA+mrm5SKbg8/7v89m/hoSnpZnpsEoCPanU jhAaWYoBAVQVAKodDXudD4p031/+a6oN4TLIfSnY0+ZkAWJ0LYx/pRN3MNKJmjffiLCI lRXItCYNmh4UY4PkU3DInUP4MUiv7VwUirVVTQ1dpJlGCrGZWWU3H0D7LxkzmqqGpjrd amEJ882e/9vfCseR4zF1wGcGujyYt5phk8DteybF1dykrPJnmhNAuDjUHeMrSbCEXJVq K2ng46akg1mIWERLq7IFknNBAPRpwSxnNajemMmHZJcCfpdy9T94aM/avh3ejBtt5G7Q 8P0w== X-Gm-Message-State: ALoCoQncLWZ0oATx41fSUWpV/cFf0xrpE/vHj7UMTI2KLiZLkqQKWHO39jdBmoqHaKVqiRjxJe8P X-Received: by 10.194.87.102 with SMTP id w6mr4199383wjz.24.1409223412529; Thu, 28 Aug 2014 03:56:52 -0700 (PDT) Received: from xps13.localnet (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by mx.google.com with ESMTPSA id hi4sm8906288wjb.46.2014.08.28.03.56.11 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Aug 2014 03:56:51 -0700 (PDT) From: Thomas Monjalon To: "Wu, Jingjing" Date: Thu, 28 Aug 2014 12:55:50 +0200 Message-ID: <1793573.SnjKVZ6loZ@xps13> Organization: 6WIND User-Agent: KMail/4.13.3 (Linux/3.15.8-1-ARCH; KDE/4.13.3; x86_64; ; ) In-Reply-To: <9BB6961774997848B5B42BEC655768F8ADBEF0@SHSMSX104.ccr.corp.intel.com> References: <1409105634-29980-1-git-send-email-jingjing.wu@intel.com> <3024593.z48vgEy6Ts@xps13> <9BB6961774997848B5B42BEC655768F8ADBEF0@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 v2 2/7] ethdev: define new ethdev API rx_classification_filter_ctl 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: Thu, 28 Aug 2014 10:52:44 -0000 2014-08-28 03:30, Wu, Jingjing: > We want to implement several common API for NIC specific features, > to avoid creating quite a lot of ops in 'struct eth_dev_ops'. > The idea came from ioctl. The approach can be interesting. > Because about flow director feature, there is large gap between i40e > and ixgbe. The existed flow director APIs looks specific to IXGBE, > so I choose this new API to implement i40e's flow director feature. The API is not OK for you so you create another one. I'm OK to change APIs but you should remove the old one, or at least, implement your new API in existing drivers to allow deprecation of the old API. I think it would help if you start by doing ixgbe work and then apply it to i40e. > The API is like below: > typedef int (*eth_rx_classification_filter_ctl_t)(struct rte_eth_dev *dev, > enum rte_eth_command cmd, > void *arg); > Define a head file called rte_i40e.h in lib/librte_pmd_i40e, which contains > the definition about structures specific to i40e, linked to the arg > parameters above. > Define a head file called rte_eth_features.h in lib/librte_ether, which > contains the commands' definition linked to cmd parameters above. Why creating a rte_eth_features.h? Don't you think rte_ethdev.h is a good place? > And if user want to use i40e specific features, then the head file > rte_i40e.h need to be included user's application, for example, test-pmd. > And user can encode these structures and call XXX_ctl API to configure > their features. OK, but the question is to know what is a specific feature? I don't think flow director is a specific feature. We shouldn't have to care if port is i40e or ixgbe to setup flow director. Is it possible to have a common API and maybe an inheritance of the common structure with PMD specific fields? Example: struct fdir_entry { fdir_input input; fdir_action action; enum rte_driver driver; }; fdir_entry_generic fdir_entry = {.driver = RTE_DRIVER_GENERIC}; filter_ctl(port, FDIR_RULE_ADD, fdir_entry); struct i40e_fdir_entry { struct fdir_entry generic; i40e_fdir_input i40e_input; }; So i40e_input will be handled by the PMD if driver == RTE_DRIVER_I40E. It's just an idea, comments are welcome. -- Thomas