Patch Comment List
List patch comments
GET /api/patches/245/comments/?format=api
[ { "id": 508, "web_url": "https://patches.dpdk.org/comment/508/", "msgid": "<3024593.z48vgEy6Ts@xps13>", "list_archive_url": "https://inbox.dpdk.org/dev/3024593.z48vgEy6Ts@xps13", "date": "2014-08-27T14:22:55", "subject": "Re: [dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev API\n\trx_classification_filter_ctl", "submitter": { "id": 1, "url": "https://patches.dpdk.org/api/people/1/?format=api", "name": "Thomas Monjalon", "email": "thomas.monjalon@6wind.com" }, "content": "Hi Jingjing,\n\n2014-08-27 10:13, Jingjing Wu:\n> support a new ethdev API rx_classification_filter_ctl for all\n> the configuration or queries for receive classification filters.\n> this patch supports commands the API used below:\n> RTE_CMD_FDIR_RULE_ADD\n> RTE_CMD_FDIR_RULE_DEL\n> RTE_CMD_FDIR_FLUSH\n> RTE_CMD_FDIR_INFO_GET\n\nCould you explain why existing API (flow director + filters) is not enough?\nI'd really like to see a common API for all filtering stuff.\n\n> -/* for 40G only */\n> -#define ETH_RSS_NONF_IPV4_UDP_SHIFT 31\n> -#define ETH_RSS_NONF_IPV4_TCP_SHIFT 33\n> -#define ETH_RSS_NONF_IPV4_SCTP_SHIFT 34\n> -#define ETH_RSS_NONF_IPV4_OTHER_SHIFT 35\n> -#define ETH_RSS_FRAG_IPV4_SHIFT 36\n> -#define ETH_RSS_NONF_IPV6_UDP_SHIFT 41\n> -#define ETH_RSS_NONF_IPV6_TCP_SHIFT 43\n> -#define ETH_RSS_NONF_IPV6_SCTP_SHIFT 44\n> -#define ETH_RSS_NONF_IPV6_OTHER_SHIFT 45\n> -#define ETH_RSS_FRAG_IPV6_SHIFT 46\n> -#define ETH_RSS_FCOE_OX_SHIFT 48\n> -#define ETH_RSS_FCOE_RX_SHIFT 49\n> -#define ETH_RSS_FCOE_OTHER_SHIFT 50\n> -#define ETH_RSS_L2_PAYLOAD_SHIFT 63\n> +/* Packet Classification Type for 40G only */\n> +#define ETH_PCTYPE_NONF_IPV4_UDP 31\n> +#define ETH_PCTYPE_NONF_IPV4_TCP 33\n> +#define ETH_PCTYPE_NONF_IPV4_SCTP 34\n> +#define ETH_PCTYPE_NONF_IPV4_OTHER 35\n> +#define ETH_PCTYPE_FRAG_IPV4 36\n> +#define ETH_PCTYPE_NONF_IPV6_UDP 41\n> +#define ETH_PCTYPE_NONF_IPV6_TCP 43\n> +#define ETH_PCTYPE_NONF_IPV6_SCTP 44\n> +#define ETH_PCTYPE_NONF_IPV6_OTHER 45\n> +#define ETH_PCTYPE_FRAG_IPV6 46\n> +#define ETH_PCTYPE_FCOE_OX 48 /* not used */\n> +#define ETH_PCTYPE_FCOE_RX 49 /* not used */\n> +#define ETH_PCTYPE_FCOE_OTHER 50 /* not used */\n> +#define ETH_PCTYPE_L2_PAYLOAD 63\n\nWhy is it specific to i40e? Could we have something generic?\nPlease take care at having only generic things in librte_ether.\n\nBy the way, these renamings should be in a separated patch.", "headers": { "Return-Path": "<thomas.monjalon@6wind.com>", "Received": [ "from mail-wg0-f42.google.com (mail-wg0-f42.google.com\n\t[74.125.82.42]) by dpdk.org (Postfix) with ESMTP id F160AB361\n\tfor <dev@dpdk.org>; Wed, 27 Aug 2014 16:18:57 +0200 (CEST)", "by mail-wg0-f42.google.com with SMTP id l18so290128wgh.1\n\tfor <dev@dpdk.org>; Wed, 27 Aug 2014 07:23:00 -0700 (PDT)", "from xps13.localnet (guy78-3-82-239-227-177.fbx.proxad.net.\n\t[82.239.227.177]) by mx.google.com with ESMTPSA id\n\ta13sm13594570wib.10.2014.08.27.07.22.59 for <multiple recipients>\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tWed, 27 Aug 2014 07:22:59 -0700 (PDT)" ], "X-Google-DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20130820;\n\th=x-gm-message-state:from:to:cc:subject:date:message-id:organization\n\t:user-agent:in-reply-to:references:mime-version\n\t:content-transfer-encoding:content-type;\n\tbh=5x17jJ6DvZHxp5IzfRICb5QhZ1bRiTKnBHGf7QzIGIw=;\n\tb=dcRDhEhqf+41rQi87W8WjBnLAedOk9M1XM+WHdqNfQ9vEfWLwhQVAKKNRjzAgCbAYA\n\txjpjZqwBBfjOriAvUAvnYGOzhs6YufMMrUasgEFAtKxkJv8Ew/HqB4i+1OnwQMO6FW4J\n\trtNyF5THuNHoCYfb5IhjmOk/herkVevY7641aElPeg3uTKE3BMbI5Pr9KQIml8IT4MfM\n\ttS35CZJHsJ2altjebeElt176fGATqBF5fW5m/ricojy9q6+tYH8FFAVT2z7SKV6rQ3th\n\tJdAdu9vYiYnvaVPJcQq+XMwcnzmcGl5mIK/KOVLAIXtcTu+xzfEIxzXN7Co0PaXtANe0\n\tcpiA==", "X-Gm-Message-State": "ALoCoQmTHYTCa0oeHjWi0he0l47sk1PweJEhVylVwW7290MAo6wf1W+jipLlPKOXt350mZxSm2Re", "X-Received": "by 10.194.76.133 with SMTP id k5mr37819568wjw.28.1409149380686; \n\tWed, 27 Aug 2014 07:23:00 -0700 (PDT)", "From": "Thomas Monjalon <thomas.monjalon@6wind.com>", "To": "Jingjing Wu <jingjing.wu@intel.com>", "Date": "Wed, 27 Aug 2014 16:22:55 +0200", "Message-ID": "<3024593.z48vgEy6Ts@xps13>", "Organization": "6WIND", "User-Agent": "KMail/4.13.3 (Linux/3.15.8-1-ARCH; KDE/4.13.3; x86_64; ; )", "In-Reply-To": "<1409105634-29980-3-git-send-email-jingjing.wu@intel.com>", "References": "<1409105634-29980-1-git-send-email-jingjing.wu@intel.com>\n\t<1409105634-29980-3-git-send-email-jingjing.wu@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\n\trx_classification_filter_ctl", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.15", "Precedence": "list", "List-Id": "patches and discussions about DPDK <dev.dpdk.org>", "List-Unsubscribe": "<http://dpdk.org/ml/options/dev>,\n\t<mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://dpdk.org/ml/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<http://dpdk.org/ml/listinfo/dev>,\n\t<mailto:dev-request@dpdk.org?subject=subscribe>", "X-List-Received-Date": "Wed, 27 Aug 2014 14:18:58 -0000" }, "addressed": null }, { "id": 534, "web_url": "https://patches.dpdk.org/comment/534/", "msgid": "<9BB6961774997848B5B42BEC655768F8ADBEF0@SHSMSX104.ccr.corp.intel.com>", "list_archive_url": "https://inbox.dpdk.org/dev/9BB6961774997848B5B42BEC655768F8ADBEF0@SHSMSX104.ccr.corp.intel.com", "date": "2014-08-28T03:30:13", "subject": "Re: [dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev API\n\trx_classification_filter_ctl", "submitter": { "id": 47, "url": "https://patches.dpdk.org/api/people/47/?format=api", "name": "Jingjing Wu", "email": "jingjing.wu@intel.com" }, "content": "HI, Thomas\n\nJust as zhang, helin's said in his pacth \"[dpdk-dev] [PATCH 2/5] ethdev: add new ops of 'check_command_supported' and 'rx_classification_filter_ctl'\":\n\n'rx_classification_filter_ctl' is for receive classification filter configuring. e.g. hash function configuration, flow director configuration. It is a common API where a lot of commands can be implemented for different sub features.\nWe 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.\n\nBecause 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.\n\nHere, I briefly describe how the new 'rx_classification_filter_ctl' works:\n\nThe API is like below:\ntypedef int (*eth_rx_classification_filter_ctl_t)(struct rte_eth_dev *dev,\n\t\t\t\t\t\t enum rte_eth_command cmd,\n\t\t\t\t\t\t void *arg);\nDefine 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.\nDefine a head file called rte_eth_features.h in lib/librte_ether, which contains the commands' definition linked to cmd parameters above.\nAnd 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.\n\nDo you think it make sense?\n\nAnd about the rename things, I will move it to a separate patch.\n\n\n> -----Original Message-----\n> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]\n> Sent: Wednesday, August 27, 2014 10:23 PM\n> To: Wu, Jingjing\n> Cc: dev@dpdk.org\n> Subject: Re: [dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev API\n> rx_classification_filter_ctl\n> \n> Hi Jingjing,\n> \n> 2014-08-27 10:13, Jingjing Wu:\n> > support a new ethdev API rx_classification_filter_ctl for all\n> > the configuration or queries for receive classification filters.\n> > this patch supports commands the API used below:\n> > RTE_CMD_FDIR_RULE_ADD\n> > RTE_CMD_FDIR_RULE_DEL\n> > RTE_CMD_FDIR_FLUSH\n> > RTE_CMD_FDIR_INFO_GET\n> \n> Could you explain why existing API (flow director + filters) is not enough?\n> I'd really like to see a common API for all filtering stuff.\n> \n> > -/* for 40G only */\n> > -#define ETH_RSS_NONF_IPV4_UDP_SHIFT 31\n> > -#define ETH_RSS_NONF_IPV4_TCP_SHIFT 33\n> > -#define ETH_RSS_NONF_IPV4_SCTP_SHIFT 34\n> > -#define ETH_RSS_NONF_IPV4_OTHER_SHIFT 35\n> > -#define ETH_RSS_FRAG_IPV4_SHIFT 36\n> > -#define ETH_RSS_NONF_IPV6_UDP_SHIFT 41\n> > -#define ETH_RSS_NONF_IPV6_TCP_SHIFT 43\n> > -#define ETH_RSS_NONF_IPV6_SCTP_SHIFT 44\n> > -#define ETH_RSS_NONF_IPV6_OTHER_SHIFT 45\n> > -#define ETH_RSS_FRAG_IPV6_SHIFT 46\n> > -#define ETH_RSS_FCOE_OX_SHIFT 48\n> > -#define ETH_RSS_FCOE_RX_SHIFT 49\n> > -#define ETH_RSS_FCOE_OTHER_SHIFT 50\n> > -#define ETH_RSS_L2_PAYLOAD_SHIFT 63\n> > +/* Packet Classification Type for 40G only */\n> > +#define ETH_PCTYPE_NONF_IPV4_UDP 31\n> > +#define ETH_PCTYPE_NONF_IPV4_TCP 33\n> > +#define ETH_PCTYPE_NONF_IPV4_SCTP 34\n> > +#define ETH_PCTYPE_NONF_IPV4_OTHER 35\n> > +#define ETH_PCTYPE_FRAG_IPV4 36\n> > +#define ETH_PCTYPE_NONF_IPV6_UDP 41\n> > +#define ETH_PCTYPE_NONF_IPV6_TCP 43\n> > +#define ETH_PCTYPE_NONF_IPV6_SCTP 44\n> > +#define ETH_PCTYPE_NONF_IPV6_OTHER 45\n> > +#define ETH_PCTYPE_FRAG_IPV6 46\n> > +#define ETH_PCTYPE_FCOE_OX 48 /* not used */\n> > +#define ETH_PCTYPE_FCOE_RX 49 /* not used */\n> > +#define ETH_PCTYPE_FCOE_OTHER 50 /* not used */\n> > +#define ETH_PCTYPE_L2_PAYLOAD 63\n> \n> Why is it specific to i40e? Could we have something generic?\n> Please take care at having only generic things in librte_ether.\n> \n> By the way, these renamings should be in a separated patch.\n> \n> --\n> Thomas", "headers": { "Return-Path": "<jingjing.wu@intel.com>", "Received": [ "from mga01.intel.com (mga01.intel.com [192.55.52.88])\n\tby dpdk.org (Postfix) with ESMTP id A76323975\n\tfor <dev@dpdk.org>; Thu, 28 Aug 2014 05:26:16 +0200 (CEST)", "from fmsmga002.fm.intel.com ([10.253.24.26])\n\tby fmsmga101.fm.intel.com with ESMTP; 27 Aug 2014 20:30:16 -0700", "from fmsmsx107.amr.corp.intel.com ([10.18.124.205])\n\tby fmsmga002.fm.intel.com with ESMTP; 27 Aug 2014 20:30:15 -0700", "from fmsmsx155.amr.corp.intel.com (10.18.116.71) by\n\tfmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP\n\tServer (TLS) id 14.3.195.1; Wed, 27 Aug 2014 20:30:15 -0700", "from shsmsx102.ccr.corp.intel.com (10.239.4.154) by\n\tFMSMSX155.amr.corp.intel.com (10.18.116.71) with Microsoft SMTP\n\tServer (TLS) id 14.3.195.1; Wed, 27 Aug 2014 20:30:14 -0700", "from shsmsx104.ccr.corp.intel.com ([169.254.5.17]) by\n\tshsmsx102.ccr.corp.intel.com ([169.254.2.246]) with mapi id\n\t14.03.0195.001; Thu, 28 Aug 2014 11:30:13 +0800" ], "X-ExtLoop1": "1", "X-IronPort-AV": "E=Sophos;i=\"5.04,415,1406617200\"; d=\"scan'208\";a=\"590932732\"", "From": "\"Wu, Jingjing\" <jingjing.wu@intel.com>", "To": "Thomas Monjalon <thomas.monjalon@6wind.com>", "Thread-Topic": "[dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev API\n\trx_classification_filter_ctl", "Thread-Index": "AQHPwZyfQaobU/kb/0yOC0EzU412AZvj+3OAgAFZloA=", "Date": "Thu, 28 Aug 2014 03:30:13 +0000", "Message-ID": "<9BB6961774997848B5B42BEC655768F8ADBEF0@SHSMSX104.ccr.corp.intel.com>", "References": "<1409105634-29980-1-git-send-email-jingjing.wu@intel.com>\n\t<1409105634-29980-3-git-send-email-jingjing.wu@intel.com>\n\t<3024593.z48vgEy6Ts@xps13>", "In-Reply-To": "<3024593.z48vgEy6Ts@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\" <dev@dpdk.org>", "Subject": "Re: [dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev API\n\trx_classification_filter_ctl", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.15", "Precedence": "list", "List-Id": "patches and discussions about DPDK <dev.dpdk.org>", "List-Unsubscribe": "<http://dpdk.org/ml/options/dev>,\n\t<mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://dpdk.org/ml/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<http://dpdk.org/ml/listinfo/dev>,\n\t<mailto:dev-request@dpdk.org?subject=subscribe>", "X-List-Received-Date": "Thu, 28 Aug 2014 03:26:17 -0000" }, "addressed": null }, { "id": 544, "web_url": "https://patches.dpdk.org/comment/544/", "msgid": "<1793573.SnjKVZ6loZ@xps13>", "list_archive_url": "https://inbox.dpdk.org/dev/1793573.SnjKVZ6loZ@xps13", "date": "2014-08-28T10:55:50", "subject": "Re: [dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev API\n\trx_classification_filter_ctl", "submitter": { "id": 1, "url": "https://patches.dpdk.org/api/people/1/?format=api", "name": "Thomas Monjalon", "email": "thomas.monjalon@6wind.com" }, "content": "2014-08-28 03:30, Wu, Jingjing:\n> We want to implement several common API for NIC specific features,\n> to avoid creating quite a lot of ops in 'struct eth_dev_ops'.\n> The idea came from ioctl.\n\nThe approach can be interesting.\n\n> Because about flow director feature, there is large gap between i40e\n> and ixgbe. The existed flow director APIs looks specific to IXGBE,\n> so I choose this new API to implement i40e's flow director feature.\n\nThe API is not OK for you so you create another one.\nI'm OK to change APIs but you should remove the old one, or at least,\nimplement your new API in existing drivers to allow deprecation of the\nold API.\nI think it would help if you start by doing ixgbe work and then apply it\nto i40e.\n\n> The API is like below:\n> typedef int (*eth_rx_classification_filter_ctl_t)(struct rte_eth_dev *dev,\n> \t\t\t\t\t\t enum rte_eth_command cmd,\n> \t\t\t\t\t\t void *arg);\n> Define a head file called rte_i40e.h in lib/librte_pmd_i40e, which contains\n> the definition about structures specific to i40e, linked to the arg\n> parameters above.\n> Define a head file called rte_eth_features.h in lib/librte_ether, which\n> contains the commands' definition linked to cmd parameters above.\n\nWhy creating a rte_eth_features.h? Don't you think rte_ethdev.h is a good place?\n\n> And if user want to use i40e specific features, then the head file\n> rte_i40e.h need to be included user's application, for example, test-pmd.\n> And user can encode these structures and call XXX_ctl API to configure\n> their features.\n\nOK, but the question is to know what is a specific feature?\nI don't think flow director is a specific feature. We shouldn't have\nto care if port is i40e or ixgbe to setup flow director.\nIs it possible to have a common API and maybe an inheritance of the\ncommon structure with PMD specific fields?\n\nExample:\n\nstruct fdir_entry {\n\tfdir_input input;\n\tfdir_action action;\n\tenum rte_driver driver;\n};\nfdir_entry_generic fdir_entry = {.driver = RTE_DRIVER_GENERIC};\nfilter_ctl(port, FDIR_RULE_ADD, fdir_entry);\n\nstruct i40e_fdir_entry {\n\tstruct fdir_entry generic;\n\ti40e_fdir_input i40e_input;\n};\n\nSo i40e_input will be handled by the PMD if driver == RTE_DRIVER_I40E.\n\nIt's just an idea, comments are welcome.", "headers": { "Return-Path": "<thomas.monjalon@6wind.com>", "Received": [ "from mail-wi0-f173.google.com (mail-wi0-f173.google.com\n\t[209.85.212.173]) by dpdk.org (Postfix) with ESMTP id 1AB885946\n\tfor <dev@dpdk.org>; Thu, 28 Aug 2014 12:52:44 +0200 (CEST)", "by mail-wi0-f173.google.com with SMTP id cc10so358038wib.0\n\tfor <dev@dpdk.org>; Thu, 28 Aug 2014 03:56:52 -0700 (PDT)", "from xps13.localnet (guy78-3-82-239-227-177.fbx.proxad.net.\n\t[82.239.227.177]) by mx.google.com with ESMTPSA id\n\thi4sm8906288wjb.46.2014.08.28.03.56.11 for <multiple recipients>\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tThu, 28 Aug 2014 03:56:51 -0700 (PDT)" ], "X-Google-DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20130820;\n\th=x-gm-message-state:from:to:cc:subject:date:message-id:organization\n\t:user-agent:in-reply-to:references:mime-version\n\t:content-transfer-encoding:content-type;\n\tbh=Y0bbjqkTDMvVGC40ozzv9rZ0JndPQAA9A239zLqCfgw=;\n\tb=k3d2n5wOp1WGJ5t2CppWvGT7AjKCUpddA+mrm5SKbg8/7v89m/hoSnpZnpsEoCPanU\n\tjhAaWYoBAVQVAKodDXudD4p031/+a6oN4TLIfSnY0+ZkAWJ0LYx/pRN3MNKJmjffiLCI\n\tlRXItCYNmh4UY4PkU3DInUP4MUiv7VwUirVVTQ1dpJlGCrGZWWU3H0D7LxkzmqqGpjrd\n\tamEJ882e/9vfCseR4zF1wGcGujyYt5phk8DteybF1dykrPJnmhNAuDjUHeMrSbCEXJVq\n\tK2ng46akg1mIWERLq7IFknNBAPRpwSxnNajemMmHZJcCfpdy9T94aM/avh3ejBtt5G7Q\n\t8P0w==", "X-Gm-Message-State": "ALoCoQncLWZ0oATx41fSUWpV/cFf0xrpE/vHj7UMTI2KLiZLkqQKWHO39jdBmoqHaKVqiRjxJe8P", "X-Received": "by 10.194.87.102 with SMTP id w6mr4199383wjz.24.1409223412529;\n\tThu, 28 Aug 2014 03:56:52 -0700 (PDT)", "From": "Thomas Monjalon <thomas.monjalon@6wind.com>", "To": "\"Wu, Jingjing\" <jingjing.wu@intel.com>", "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>\n\t<3024593.z48vgEy6Ts@xps13>\n\t<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\n\trx_classification_filter_ctl", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.15", "Precedence": "list", "List-Id": "patches and discussions about DPDK <dev.dpdk.org>", "List-Unsubscribe": "<http://dpdk.org/ml/options/dev>,\n\t<mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://dpdk.org/ml/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<http://dpdk.org/ml/listinfo/dev>,\n\t<mailto:dev-request@dpdk.org?subject=subscribe>", "X-List-Received-Date": "Thu, 28 Aug 2014 10:52:44 -0000" }, "addressed": null }, { "id": 548, "web_url": "https://patches.dpdk.org/comment/548/", "msgid": "<2601191342CEEE43887BDE71AB9772582135F39F@IRSMSX105.ger.corp.intel.com>", "list_archive_url": "https://inbox.dpdk.org/dev/2601191342CEEE43887BDE71AB9772582135F39F@IRSMSX105.ger.corp.intel.com", "date": "2014-08-28T11:48:53", "subject": "Re: [dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev\n\tAPI\trx_classification_filter_ctl", "submitter": { "id": 33, "url": "https://patches.dpdk.org/api/people/33/?format=api", "name": "Ananyev, Konstantin", "email": "konstantin.ananyev@intel.com" }, "content": "> -----Original Message-----\n> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon\n> Sent: Thursday, August 28, 2014 11:56 AM\n> To: Wu, Jingjing\n> Cc: dev@dpdk.org\n> Subject: Re: [dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev API rx_classification_filter_ctl\n> \n> 2014-08-28 03:30, Wu, Jingjing:\n> > We want to implement several common API for NIC specific features,\n> > to avoid creating quite a lot of ops in 'struct eth_dev_ops'.\n> > The idea came from ioctl.\n> \n> The approach can be interesting.\n> \n> > Because about flow director feature, there is large gap between i40e\n> > and ixgbe. The existed flow director APIs looks specific to IXGBE,\n> > so I choose this new API to implement i40e's flow director feature.\n> \n> The API is not OK for you so you create another one.\n> I'm OK to change APIs but you should remove the old one, or at least,\n> implement your new API in existing drivers to allow deprecation of the\n> old API.\n> I think it would help if you start by doing ixgbe work and then apply it\n> to i40e.\n> \n> > The API is like below:\n> > typedef int (*eth_rx_classification_filter_ctl_t)(struct rte_eth_dev *dev,\n> > \t\t\t\t\t\t enum rte_eth_command cmd,\n> > \t\t\t\t\t\t void *arg);\n> > Define a head file called rte_i40e.h in lib/librte_pmd_i40e, which contains\n> > the definition about structures specific to i40e, linked to the arg\n> > parameters above.\n> > Define a head file called rte_eth_features.h in lib/librte_ether, which\n> > contains the commands' definition linked to cmd parameters above.\n> \n> Why creating a rte_eth_features.h? Don't you think rte_ethdev.h is a good place?\n\nAs I remember the long term idea was\n(Jingjing please correct me, if I am wrong here):\n\nKeep rte_ethdev.h for generic API.\nPut features specific for different NICs into rte_eth_features.h \nTo make things clearer and avoid polluting of rte_ethdev.h.\n\nProvide API for the upper layer to query list of specific features(commands) supported by the underlying device.\nSomething like: \nrte_eth_dev_get_rx_filter_supported(port, ...);\n\nAnd ioctl-type API to configure HW specific features: \nrte_eth_dev_rx_classification_filter_ctl(port, cmd, cmd_spedific_arg);\n\nSo, instead of application knows in advance \"which specific NIC it is using\",\napplication would query which features/commannds the NIC provides and then configure them appropriately.\n\n> \n> > And if user want to use i40e specific features, then the head file\n> > rte_i40e.h need to be included user's application, for example, test-pmd.\n> > And user can encode these structures and call XXX_ctl API to configure\n> > their features.\n> \n> OK, but the question is to know what is a specific feature?\n> I don't think flow director is a specific feature. We shouldn't have\n> to care if port is i40e or ixgbe to setup flow director.\n> Is it possible to have a common API and maybe an inheritance of the\n> common structure with PMD specific fields?\n> \n> Example:\n> \n> struct fdir_entry {\n> \tfdir_input input;\n> \tfdir_action action;\n> \tenum rte_driver driver;\n> };\n> fdir_entry_generic fdir_entry = {.driver = RTE_DRIVER_GENERIC};\n> filter_ctl(port, FDIR_RULE_ADD, fdir_entry);\n> \n> struct i40e_fdir_entry {\n> \tstruct fdir_entry generic;\n> \ti40e_fdir_input i40e_input;\n> };\n> \n> So i40e_input will be handled by the PMD if driver == RTE_DRIVER_I40E.\n> \n> It's just an idea, comments are welcome.\n> \n> --\n> Thomas", "headers": { "Return-Path": "<konstantin.ananyev@intel.com>", "Received": [ "from mga02.intel.com (mga02.intel.com [134.134.136.20])\n\tby dpdk.org (Postfix) with ESMTP id 54382B37B\n\tfor <dev@dpdk.org>; Thu, 28 Aug 2014 13:45:12 +0200 (CEST)", "from orsmga001.jf.intel.com ([10.7.209.18])\n\tby orsmga101.jf.intel.com with ESMTP; 28 Aug 2014 04:48:56 -0700", "from irsmsx102.ger.corp.intel.com ([163.33.3.155])\n\tby orsmga001.jf.intel.com with ESMTP; 28 Aug 2014 04:48:55 -0700", "from irsmsx105.ger.corp.intel.com ([169.254.7.158]) by\n\tIRSMSX102.ger.corp.intel.com ([169.254.2.24]) with mapi id\n\t14.03.0195.001; Thu, 28 Aug 2014 12:48:54 +0100" ], "X-ExtLoop1": "1", "X-IronPort-AV": "E=Sophos;i=\"5.04,417,1406617200\"; d=\"scan'208\";a=\"564710453\"", "From": "\"Ananyev, Konstantin\" <konstantin.ananyev@intel.com>", "To": "Thomas Monjalon <thomas.monjalon@6wind.com>, \"Wu, Jingjing\"\n\t<jingjing.wu@intel.com>", "Thread-Topic": "[dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev API\n\trx_classification_filter_ctl", "Thread-Index": "AQHPwq7XQPBC9CDfQk+5QEFc6cZ+yZvl4rzA", "Date": "Thu, 28 Aug 2014 11:48:53 +0000", "Message-ID": "<2601191342CEEE43887BDE71AB9772582135F39F@IRSMSX105.ger.corp.intel.com>", "References": "<1409105634-29980-1-git-send-email-jingjing.wu@intel.com>\n\t<3024593.z48vgEy6Ts@xps13>\n\t<9BB6961774997848B5B42BEC655768F8ADBEF0@SHSMSX104.ccr.corp.intel.com>\n\t<1793573.SnjKVZ6loZ@xps13>", "In-Reply-To": "<1793573.SnjKVZ6loZ@xps13>", "Accept-Language": "en-IE, en-US", "Content-Language": "en-US", "X-MS-Has-Attach": "", "X-MS-TNEF-Correlator": "", "x-originating-ip": "[163.33.239.180]", "Content-Type": "text/plain; charset=\"us-ascii\"", "Content-Transfer-Encoding": "quoted-printable", "MIME-Version": "1.0", "Cc": "\"dev@dpdk.org\" <dev@dpdk.org>", "Subject": "Re: [dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev\n\tAPI\trx_classification_filter_ctl", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.15", "Precedence": "list", "List-Id": "patches and discussions about DPDK <dev.dpdk.org>", "List-Unsubscribe": "<http://dpdk.org/ml/options/dev>,\n\t<mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://dpdk.org/ml/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<http://dpdk.org/ml/listinfo/dev>,\n\t<mailto:dev-request@dpdk.org?subject=subscribe>", "X-List-Received-Date": "Thu, 28 Aug 2014 11:45:12 -0000" }, "addressed": null }, { "id": 553, "web_url": "https://patches.dpdk.org/comment/553/", "msgid": "<9BB6961774997848B5B42BEC655768F8ADC20D@SHSMSX104.ccr.corp.intel.com>", "list_archive_url": "https://inbox.dpdk.org/dev/9BB6961774997848B5B42BEC655768F8ADC20D@SHSMSX104.ccr.corp.intel.com", "date": "2014-08-28T13:39:54", "subject": "Re: [dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev API\n\trx_classification_filter_ctl", "submitter": { "id": 47, "url": "https://patches.dpdk.org/api/people/47/?format=api", "name": "Jingjing Wu", "email": "jingjing.wu@intel.com" }, "content": "Hi, Thomas\n\nPlease see my comments below. \n\nThanks a lot.\n\n> -----Original Message-----\n> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]\n> Sent: Thursday, August 28, 2014 6:56 PM\n> To: Wu, Jingjing\n> Cc: dev@dpdk.org\n> Subject: Re: [dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev API\n> rx_classification_filter_ctl\n> \n> 2014-08-28 03:30, Wu, Jingjing:\n> > We want to implement several common API for NIC specific features,\n> > to avoid creating quite a lot of ops in 'struct eth_dev_ops'.\n> > The idea came from ioctl.\n> \n> The approach can be interesting.\n\nYes, we have discussed this approach inside. And some other Fortville\nFeatures are also based on it, such as RSS hash function support,\nmac vlan filters.\nMaybe it a good chance to discuss in open forum now.\n\n> \n> > Because about flow director feature, there is large gap between i40e\n> > and ixgbe. The existed flow director APIs looks specific to IXGBE,\n> > so I choose this new API to implement i40e's flow director feature.\n> \n> The API is not OK for you so you create another one.\n> I'm OK to change APIs but you should remove the old one, or at least,\n> implement your new API in existing drivers to allow deprecation of the\n> old API.\n> I think it would help if you start by doing ixgbe work and then apply it\n> to i40e.\n> \n\nYes, it will be perfect if we can use this new API to achieve flow director \nsetting all types of NICs. But the concern is downward compatibility. \nUsers who is planning update DPDK version need to change their code\nto adapt such changes.\nThat's why we choose a new API instead of modifying current APIs. And \nOf course, the ideal plan is adding such XXX_ctl function in Ixgbe and\nIgb to moving smoothly without removing current APIs.\nI'm not sure whether I understanding correctly about the importance of\ncompatibility. \n\n> > The API is like below:\n> > typedef int (*eth_rx_classification_filter_ctl_t)(struct rte_eth_dev *dev,\n> > \t\t\t\t\t\t enum rte_eth_command cmd,\n> > \t\t\t\t\t\t void *arg);\n> > Define a head file called rte_i40e.h in lib/librte_pmd_i40e, which contains\n> > the definition about structures specific to i40e, linked to the arg\n> > parameters above.\n> > Define a head file called rte_eth_features.h in lib/librte_ether, which\n> > contains the commands' definition linked to cmd parameters above.\n> \n> Why creating a rte_eth_features.h? Don't you think rte_ethdev.h is a good place?\n> \n> > And if user want to use i40e specific features, then the head file\n> > rte_i40e.h need to be included user's application, for example, test-pmd.\n> > And user can encode these structures and call XXX_ctl API to configure\n> > their features.\n> \n> OK, but the question is to know what is a specific feature?\n> I don't think flow director is a specific feature. We shouldn't have\n> to care if port is i40e or ixgbe to setup flow director.\n> Is it possible to have a common API and maybe an inheritance of the\n> common structure with PMD specific fields?\n> \n\nYes, flow director is not a specific feature. Even ixgbe and i40 use the same \nname. But the context and key have much difference. That's why I called it\nspecific.\n\n> Example:\n> \n> struct fdir_entry {\n> \tfdir_input input;\n> \tfdir_action action;\n> \tenum rte_driver driver;\n> };\n> fdir_entry_generic fdir_entry = {.driver = RTE_DRIVER_GENERIC};\n> filter_ctl(port, FDIR_RULE_ADD, fdir_entry);\n> \n> struct i40e_fdir_entry {\n> \tstruct fdir_entry generic;\n> \ti40e_fdir_input i40e_input;\n> };\n> \n> So i40e_input will be handled by the PMD if driver == RTE_DRIVER_I40E.\n> \n> It's just an idea, comments are welcome.\n\nYes, it's a good idea about an inheritance of the common structure. I think it\nmay support new NIC integration in future. We can do it with the new API \narchitecture. But the concern is still how to be compatible with old version.\n\n> --\n> Thomas", "headers": { "Return-Path": "<jingjing.wu@intel.com>", "Received": [ "from mga09.intel.com (mga09.intel.com [134.134.136.24])\n\tby dpdk.org (Postfix) with ESMTP id 77B505905\n\tfor <dev@dpdk.org>; Thu, 28 Aug 2014 15:42:44 +0200 (CEST)", "from orsmga002.jf.intel.com ([10.7.209.21])\n\tby orsmga102.jf.intel.com with ESMTP; 28 Aug 2014 06:33:59 -0700", "from fmsmsx105.amr.corp.intel.com ([10.18.124.203])\n\tby orsmga002.jf.intel.com with ESMTP; 28 Aug 2014 06:39:58 -0700", "from fmsmsx158.amr.corp.intel.com (10.18.116.75) by\n\tFMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP\n\tServer (TLS) id 14.3.195.1; Thu, 28 Aug 2014 06:39:57 -0700", "from shsmsx102.ccr.corp.intel.com (10.239.4.154) by\n\tfmsmsx158.amr.corp.intel.com (10.18.116.75) with Microsoft SMTP\n\tServer (TLS) id 14.3.195.1; Thu, 28 Aug 2014 06:39:57 -0700", "from shsmsx104.ccr.corp.intel.com ([169.254.5.17]) by\n\tshsmsx102.ccr.corp.intel.com ([169.254.2.246]) with mapi id\n\t14.03.0195.001; Thu, 28 Aug 2014 21:39:55 +0800" ], "X-ExtLoop1": "1", "X-IronPort-AV": "E=Sophos;i=\"5.04,418,1406617200\"; d=\"scan'208\";a=\"594555871\"", "From": "\"Wu, Jingjing\" <jingjing.wu@intel.com>", "To": "Thomas Monjalon <thomas.monjalon@6wind.com>", "Thread-Topic": "[dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev API\n\trx_classification_filter_ctl", "Thread-Index": "AQHPwZyfQaobU/kb/0yOC0EzU412AZvj+3OAgAFZloD///7jAIAAq21Q", "Date": "Thu, 28 Aug 2014 13:39:54 +0000", "Message-ID": "<9BB6961774997848B5B42BEC655768F8ADC20D@SHSMSX104.ccr.corp.intel.com>", "References": "<1409105634-29980-1-git-send-email-jingjing.wu@intel.com>\n\t<3024593.z48vgEy6Ts@xps13>\n\t<9BB6961774997848B5B42BEC655768F8ADBEF0@SHSMSX104.ccr.corp.intel.com>\n\t<1793573.SnjKVZ6loZ@xps13>", "In-Reply-To": "<1793573.SnjKVZ6loZ@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\" <dev@dpdk.org>", "Subject": "Re: [dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev API\n\trx_classification_filter_ctl", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.15", "Precedence": "list", "List-Id": "patches and discussions about DPDK <dev.dpdk.org>", "List-Unsubscribe": "<http://dpdk.org/ml/options/dev>,\n\t<mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://dpdk.org/ml/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<http://dpdk.org/ml/listinfo/dev>,\n\t<mailto:dev-request@dpdk.org?subject=subscribe>", "X-List-Received-Date": "Thu, 28 Aug 2014 13:42:45 -0000" }, "addressed": null }, { "id": 554, "web_url": "https://patches.dpdk.org/comment/554/", "msgid": "<9BB6961774997848B5B42BEC655768F8ADC238@SHSMSX104.ccr.corp.intel.com>", "list_archive_url": "https://inbox.dpdk.org/dev/9BB6961774997848B5B42BEC655768F8ADC238@SHSMSX104.ccr.corp.intel.com", "date": "2014-08-28T14:07:17", "subject": "Re: [dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev\n\tAPI\trx_classification_filter_ctl", "submitter": { "id": 47, "url": "https://patches.dpdk.org/api/people/47/?format=api", "name": "Jingjing Wu", "email": "jingjing.wu@intel.com" }, "content": "Hi, Konstantin\n\nThanks a lot.\n\n> -----Original Message-----\n> From: Ananyev, Konstantin\n> Sent: Thursday, August 28, 2014 7:49 PM\n> To: Thomas Monjalon; Wu, Jingjing\n> Cc: dev@dpdk.org\n> Subject: RE: [dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev API\n> rx_classification_filter_ctl\n> \n> \n> \n> > -----Original Message-----\n> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon\n> > Sent: Thursday, August 28, 2014 11:56 AM\n> > To: Wu, Jingjing\n> > Cc: dev@dpdk.org\n> > Subject: Re: [dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev API\n> rx_classification_filter_ctl\n> >\n> > 2014-08-28 03:30, Wu, Jingjing:\n> > > We want to implement several common API for NIC specific features,\n> > > to avoid creating quite a lot of ops in 'struct eth_dev_ops'.\n> > > The idea came from ioctl.\n> >\n> > The approach can be interesting.\n> >\n> > > Because about flow director feature, there is large gap between i40e\n> > > and ixgbe. The existed flow director APIs looks specific to IXGBE,\n> > > so I choose this new API to implement i40e's flow director feature.\n> >\n> > The API is not OK for you so you create another one.\n> > I'm OK to change APIs but you should remove the old one, or at least,\n> > implement your new API in existing drivers to allow deprecation of the\n> > old API.\n> > I think it would help if you start by doing ixgbe work and then apply it\n> > to i40e.\n> >\n> > > The API is like below:\n> > > typedef int (*eth_rx_classification_filter_ctl_t)(struct rte_eth_dev *dev,\n> > > \t\t\t\t\t\t enum rte_eth_command cmd,\n> > > \t\t\t\t\t\t void *arg);\n> > > Define a head file called rte_i40e.h in lib/librte_pmd_i40e, which contains\n> > > the definition about structures specific to i40e, linked to the arg\n> > > parameters above.\n> > > Define a head file called rte_eth_features.h in lib/librte_ether, which\n> > > contains the commands' definition linked to cmd parameters above.\n> >\n> > Why creating a rte_eth_features.h? Don't you think rte_ethdev.h is a good place?\n> \n> As I remember the long term idea was\n> (Jingjing please correct me, if I am wrong here):\n> \n> Keep rte_ethdev.h for generic API.\n> Put features specific for different NICs into rte_eth_features.h\n> To make things clearer and avoid polluting of rte_ethdev.h.\n> \n> Provide API for the upper layer to query list of specific features(commands) supported by the\n> underlying device.\n> Something like:\n> rte_eth_dev_get_rx_filter_supported(port, ...);\n\nYes, in helin's patch \"[dpdk-dev] [PATCH v2 2/6] ethdev: add new ops of\n'is_command_supported' and 'rx_classification_filter_ctl'\", he already\ndefined rte_eth_dev_is_command_supported. It can be used to check\nwhether such command can be supported by the queried port.\n\nActually, some features are based on this architecture, including helin's\n\"Support configuring hash functions\" and other non-ready patch.\nWe supposed after any patch of ours is applied, others need to rework\nthen. We are using the same approach.\n\n> And ioctl-type API to configure HW specific features:\n> rte_eth_dev_rx_classification_filter_ctl(port, cmd, cmd_spedific_arg);\n> \n> So, instead of application knows in advance \"which specific NIC it is using\",\n> application would query which features/commannds the NIC provides and then configure\n> them appropriately.\n> \n> >\n> > > And if user want to use i40e specific features, then the head file\n> > > rte_i40e.h need to be included user's application, for example, test-pmd.\n> > > And user can encode these structures and call XXX_ctl API to configure\n> > > their features.\n> >\n> > OK, but the question is to know what is a specific feature?\n> > I don't think flow director is a specific feature. We shouldn't have\n> > to care if port is i40e or ixgbe to setup flow director.\n> > Is it possible to have a common API and maybe an inheritance of the\n> > common structure with PMD specific fields?\n> >\n> > Example:\n> >\n> > struct fdir_entry {\n> > \tfdir_input input;\n> > \tfdir_action action;\n> > \tenum rte_driver driver;\n> > };\n> > fdir_entry_generic fdir_entry = {.driver = RTE_DRIVER_GENERIC};\n> > filter_ctl(port, FDIR_RULE_ADD, fdir_entry);\n> >\n> > struct i40e_fdir_entry {\n> > \tstruct fdir_entry generic;\n> > \ti40e_fdir_input i40e_input;\n> > };\n> >\n> > So i40e_input will be handled by the PMD if driver == RTE_DRIVER_I40E.\n> >\n> > It's just an idea, comments are welcome.\n> >\n> > --\n> > Thomas", "headers": { "Return-Path": "<jingjing.wu@intel.com>", "Received": [ "from mga11.intel.com (mga11.intel.com [192.55.52.93])\n\tby dpdk.org (Postfix) with ESMTP id BE4325942\n\tfor <dev@dpdk.org>; Thu, 28 Aug 2014 16:06:37 +0200 (CEST)", "from fmsmga001.fm.intel.com ([10.253.24.23])\n\tby fmsmga102.fm.intel.com with ESMTP; 28 Aug 2014 07:10:28 -0700", "from fmsmsx103.amr.corp.intel.com ([10.19.9.34])\n\tby fmsmga001.fm.intel.com with ESMTP; 28 Aug 2014 07:08:10 -0700", "from fmsmsx157.amr.corp.intel.com (10.18.116.73) by\n\tFMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server\n\t(TLS) id 14.3.195.1; Thu, 28 Aug 2014 07:07:21 -0700", "from shsmsx102.ccr.corp.intel.com (10.239.4.154) by\n\tFMSMSX157.amr.corp.intel.com (10.18.116.73) with Microsoft SMTP\n\tServer (TLS) id 14.3.195.1; Thu, 28 Aug 2014 07:07:19 -0700", "from shsmsx104.ccr.corp.intel.com ([169.254.5.17]) by\n\tshsmsx102.ccr.corp.intel.com ([169.254.2.246]) with mapi id\n\t14.03.0195.001; Thu, 28 Aug 2014 22:07:18 +0800" ], "X-ExtLoop1": "1", "X-IronPort-AV": "E=Sophos;i=\"5.04,418,1406617200\"; d=\"scan'208\";a=\"582902777\"", "From": "\"Wu, Jingjing\" <jingjing.wu@intel.com>", "To": "\"Ananyev, Konstantin\" <konstantin.ananyev@intel.com>, Thomas Monjalon\n\t<thomas.monjalon@6wind.com>", "Thread-Topic": "[dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev API\n\trx_classification_filter_ctl", "Thread-Index": "AQHPwrYNUFtTGjRpdkeLRyRFF83fA5vmBwxA", "Date": "Thu, 28 Aug 2014 14:07:17 +0000", "Message-ID": "<9BB6961774997848B5B42BEC655768F8ADC238@SHSMSX104.ccr.corp.intel.com>", "References": "<1409105634-29980-1-git-send-email-jingjing.wu@intel.com>\n\t<3024593.z48vgEy6Ts@xps13>\n\t<9BB6961774997848B5B42BEC655768F8ADBEF0@SHSMSX104.ccr.corp.intel.com>\n\t<1793573.SnjKVZ6loZ@xps13>\n\t<2601191342CEEE43887BDE71AB9772582135F39F@IRSMSX105.ger.corp.intel.com>", "In-Reply-To": "<2601191342CEEE43887BDE71AB9772582135F39F@IRSMSX105.ger.corp.intel.com>", "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\" <dev@dpdk.org>", "Subject": "Re: [dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev\n\tAPI\trx_classification_filter_ctl", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.15", "Precedence": "list", "List-Id": "patches and discussions about DPDK <dev.dpdk.org>", "List-Unsubscribe": "<http://dpdk.org/ml/options/dev>,\n\t<mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://dpdk.org/ml/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<http://dpdk.org/ml/listinfo/dev>,\n\t<mailto:dev-request@dpdk.org?subject=subscribe>", "X-List-Received-Date": "Thu, 28 Aug 2014 14:06:38 -0000" }, "addressed": null }, { "id": 555, "web_url": "https://patches.dpdk.org/comment/555/", "msgid": "<33553897.HNdRDVj5YS@xps13>", "list_archive_url": "https://inbox.dpdk.org/dev/33553897.HNdRDVj5YS@xps13", "date": "2014-08-28T14:20:54", "subject": "Re: [dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev API\n\trx_classification_filter_ctl", "submitter": { "id": 1, "url": "https://patches.dpdk.org/api/people/1/?format=api", "name": "Thomas Monjalon", "email": "thomas.monjalon@6wind.com" }, "content": "2014-08-28 13:39, Wu, Jingjing:\n> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]\n> > I'm OK to change APIs but you should remove the old one, or at least,\n> > implement your new API in existing drivers to allow deprecation of the\n> > old API.\n> > I think it would help if you start by doing ixgbe work and then apply it\n> > to i40e.\n> > \n> \n> Yes, it will be perfect if we can use this new API to achieve flow director \n> setting all types of NICs. But the concern is downward compatibility.\n\nIn this case, cleanup is more important than compatibility.\n\n> Users who is planning update DPDK version need to change their code\n> to adapt such changes.\n\nYes, but we can keep deprecated function during 1 release.\n\n> That's why we choose a new API instead of modifying current APIs. And \n> Of course, the ideal plan is adding such XXX_ctl function in Ixgbe and\n> Igb to moving smoothly without removing current APIs.\n\nYes\n\n> > I don't think flow director is a specific feature. We shouldn't have\n> > to care if port is i40e or ixgbe to setup flow director.\n> > Is it possible to have a common API and maybe an inheritance of the\n> > common structure with PMD specific fields?\n> \n> Yes, flow director is not a specific feature. Even ixgbe and i40 use the same \n> name. But the context and key have much difference. That's why I called it\n> specific.\n> \n> Yes, it's a good idea about an inheritance of the common structure. I think it\n> may support new NIC integration in future. We can do it with the new API \n> architecture. But the concern is still how to be compatible with old version.\n\nThere is no compatibility blocker here.\nIf we can keep deprecated functions a while, we'll do. Otherwise, just go with\nthe new API.\nI prefer we concentrate on good design rather than on compatibility.\n\nThanks", "headers": { "Return-Path": "<thomas.monjalon@6wind.com>", "Received": [ "from mail-wg0-f52.google.com (mail-wg0-f52.google.com\n\t[74.125.82.52]) by dpdk.org (Postfix) with ESMTP id ED5BD5942\n\tfor <dev@dpdk.org>; Thu, 28 Aug 2014 16:16:50 +0200 (CEST)", "by mail-wg0-f52.google.com with SMTP id m15so818569wgh.11\n\tfor <dev@dpdk.org>; Thu, 28 Aug 2014 07:21:00 -0700 (PDT)", "from xps13.localnet (guy78-3-82-239-227-177.fbx.proxad.net.\n\t[82.239.227.177]) by mx.google.com with ESMTPSA id\n\tla2sm10394442wjb.5.2014.08.28.07.20.58 for <multiple recipients>\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tThu, 28 Aug 2014 07:20:59 -0700 (PDT)" ], "X-Google-DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20130820;\n\th=x-gm-message-state:from:to:cc:subject:date:message-id:organization\n\t:user-agent:in-reply-to:references:mime-version\n\t:content-transfer-encoding:content-type;\n\tbh=STS2YKAEJioHF/t1FJcbSMYeIBytIo7pWCkVAJbFOJM=;\n\tb=hM5ZD5sMv92BmGiVy4ewdBDAfvD85Q3PqfrNq99LZRKQNT5abbM5OuJ3Oz/cbkvNxl\n\to5Rci84eVmMfxhO8XMS85fTxyjc+Hzp9t79xUcI/aFIsNP+uvBLRprtnW/M9aBWbE4nH\n\twHHrBgJ+hky9TJcD/hvCiliMpq+5ml/3tNCyRahnm2KNmE1/U2GWMp/san+olVNend2o\n\t6TmIBu2TvO+kHHlF29VC9CIAotmzliQt876lNUSROVIgSOXPiO/qMklRCGOx+58w3bZZ\n\t9ci292HRnJWMtXGso+f5wbVWLCW4mR3a7MypRdY43CYCKd7Ii5Izj5O4lbd2xtGa44Dp\n\tS8UQ==", "X-Gm-Message-State": "ALoCoQlU1ANI6Xr6RL7oinOxzRf/SnORlLEvwShdnrxCT62sTBflLU+ZNgWasr76v4z17lQQ6u0M", "X-Received": "by 10.180.104.163 with SMTP id gf3mr37398074wib.24.1409235660131;\n\tThu, 28 Aug 2014 07:21:00 -0700 (PDT)", "From": "Thomas Monjalon <thomas.monjalon@6wind.com>", "To": "\"Wu, Jingjing\" <jingjing.wu@intel.com>", "Date": "Thu, 28 Aug 2014 16:20:54 +0200", "Message-ID": "<33553897.HNdRDVj5YS@xps13>", "Organization": "6WIND", "User-Agent": "KMail/4.13.3 (Linux/3.15.8-1-ARCH; KDE/4.13.3; x86_64; ; )", "In-Reply-To": "<9BB6961774997848B5B42BEC655768F8ADC20D@SHSMSX104.ccr.corp.intel.com>", "References": "<1409105634-29980-1-git-send-email-jingjing.wu@intel.com>\n\t<1793573.SnjKVZ6loZ@xps13>\n\t<9BB6961774997848B5B42BEC655768F8ADC20D@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\n\trx_classification_filter_ctl", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.15", "Precedence": "list", "List-Id": "patches and discussions about DPDK <dev.dpdk.org>", "List-Unsubscribe": "<http://dpdk.org/ml/options/dev>,\n\t<mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://dpdk.org/ml/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<http://dpdk.org/ml/listinfo/dev>,\n\t<mailto:dev-request@dpdk.org?subject=subscribe>", "X-List-Received-Date": "Thu, 28 Aug 2014 14:16:51 -0000" }, "addressed": null }, { "id": 556, "web_url": "https://patches.dpdk.org/comment/556/", "msgid": "<9BB6961774997848B5B42BEC655768F8ADC26A@SHSMSX104.ccr.corp.intel.com>", "list_archive_url": "https://inbox.dpdk.org/dev/9BB6961774997848B5B42BEC655768F8ADC26A@SHSMSX104.ccr.corp.intel.com", "date": "2014-08-28T14:31:34", "subject": "Re: [dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev API\n\trx_classification_filter_ctl", "submitter": { "id": 47, "url": "https://patches.dpdk.org/api/people/47/?format=api", "name": "Jingjing Wu", "email": "jingjing.wu@intel.com" }, "content": "> -----Original Message-----\n> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]\n> Sent: Thursday, August 28, 2014 10:21 PM\n> To: Wu, Jingjing\n> Cc: dev@dpdk.org\n> Subject: Re: [dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev API\n> rx_classification_filter_ctl\n> \n> 2014-08-28 13:39, Wu, Jingjing:\n> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]\n> > > I'm OK to change APIs but you should remove the old one, or at least,\n> > > implement your new API in existing drivers to allow deprecation of the\n> > > old API.\n> > > I think it would help if you start by doing ixgbe work and then apply it\n> > > to i40e.\n> > >\n> >\n> > Yes, it will be perfect if we can use this new API to achieve flow director\n> > setting all types of NICs. But the concern is downward compatibility.\n> \n> In this case, cleanup is more important than compatibility.\n> \n> > Users who is planning update DPDK version need to change their code\n> > to adapt such changes.\n> \n> Yes, but we can keep deprecated function during 1 release.\n> \n> > That's why we choose a new API instead of modifying current APIs. And\n> > Of course, the ideal plan is adding such XXX_ctl function in Ixgbe and\n> > Igb to moving smoothly without removing current APIs.\n> \n> Yes\n> \n> > > I don't think flow director is a specific feature. We shouldn't have\n> > > to care if port is i40e or ixgbe to setup flow director.\n> > > Is it possible to have a common API and maybe an inheritance of the\n> > > common structure with PMD specific fields?\n> >\n> > Yes, flow director is not a specific feature. Even ixgbe and i40 use the same\n> > name. But the context and key have much difference. That's why I called it\n> > specific.\n> >\n> > Yes, it's a good idea about an inheritance of the common structure. I think it\n> > may support new NIC integration in future. We can do it with the new API\n> > architecture. But the concern is still how to be compatible with old version.\n> \n> There is no compatibility blocker here.\n> If we can keep deprecated functions a while, we'll do. Otherwise, just go with\n> the new API.\n> I prefer we concentrate on good design rather than on compatibility.\n> \n\nOK, now I have a rough understanding about your opinion, I guess there will be lots of rework need to be done. I will try. Thanks for your explanation.\n\n> Thanks\n> --\n> Thomas\n\nThanks\nJingjing", "headers": { "Return-Path": "<jingjing.wu@intel.com>", "Received": [ "from mga02.intel.com (mga02.intel.com [134.134.136.20])\n\tby dpdk.org (Postfix) with ESMTP id EFE42682E\n\tfor <dev@dpdk.org>; Thu, 28 Aug 2014 16:27:32 +0200 (CEST)", "from orsmga002.jf.intel.com ([10.7.209.21])\n\tby orsmga101.jf.intel.com with ESMTP; 28 Aug 2014 07:31:39 -0700", "from fmsmsx106.amr.corp.intel.com ([10.18.124.204])\n\tby orsmga002.jf.intel.com with ESMTP; 28 Aug 2014 07:31:38 -0700", "from fmsmsx158.amr.corp.intel.com (10.18.116.75) by\n\tFMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP\n\tServer (TLS) id 14.3.195.1; Thu, 28 Aug 2014 07:31:38 -0700", "from shsmsx151.ccr.corp.intel.com (10.239.6.50) by\n\tfmsmsx158.amr.corp.intel.com (10.18.116.75) with Microsoft SMTP\n\tServer (TLS) id 14.3.195.1; Thu, 28 Aug 2014 07:31:38 -0700", "from shsmsx104.ccr.corp.intel.com ([169.254.5.17]) by\n\tSHSMSX151.ccr.corp.intel.com ([169.254.3.174]) with mapi id\n\t14.03.0195.001; Thu, 28 Aug 2014 22:31:35 +0800" ], "X-ExtLoop1": "1", "X-IronPort-AV": "E=Sophos;i=\"5.04,418,1406617200\"; d=\"scan'208\";a=\"594581965\"", "From": "\"Wu, Jingjing\" <jingjing.wu@intel.com>", "To": "Thomas Monjalon <thomas.monjalon@6wind.com>", "Thread-Topic": "[dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev API\n\trx_classification_filter_ctl", "Thread-Index": "AQHPwZyfQaobU/kb/0yOC0EzU412AZvj+3OAgAFZloD///7jAIAAq21Q//+N3wCAAIdxQA==", "Date": "Thu, 28 Aug 2014 14:31:34 +0000", "Message-ID": "<9BB6961774997848B5B42BEC655768F8ADC26A@SHSMSX104.ccr.corp.intel.com>", "References": "<1409105634-29980-1-git-send-email-jingjing.wu@intel.com>\n\t<1793573.SnjKVZ6loZ@xps13>\n\t<9BB6961774997848B5B42BEC655768F8ADC20D@SHSMSX104.ccr.corp.intel.com>\n\t<33553897.HNdRDVj5YS@xps13>", "In-Reply-To": "<33553897.HNdRDVj5YS@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\" <dev@dpdk.org>", "Subject": "Re: [dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev API\n\trx_classification_filter_ctl", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.15", "Precedence": "list", "List-Id": "patches and discussions about DPDK <dev.dpdk.org>", "List-Unsubscribe": "<http://dpdk.org/ml/options/dev>,\n\t<mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://dpdk.org/ml/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<http://dpdk.org/ml/listinfo/dev>,\n\t<mailto:dev-request@dpdk.org?subject=subscribe>", "X-List-Received-Date": "Thu, 28 Aug 2014 14:27:33 -0000" }, "addressed": null } ]