Patch Comment List
List patch comments
GET /api/patches/304/comments/?format=api
[ { "id": 680, "web_url": "http://patches.dpdk.org/comment/680/", "msgid": "<540D8228.809@6wind.com>", "list_archive_url": "https://inbox.dpdk.org/dev/540D8228.809@6wind.com", "date": "2014-09-08T10:17:12", "subject": "Re: [dpdk-dev] [PATCH 03/13] mbuf: add packet_type field", "submitter": { "id": 8, "url": "http://patches.dpdk.org/api/people/8/?format=api", "name": "Olivier Matz", "email": "olivier.matz@6wind.com" }, "content": "Hi Bruce,\n\nOn 09/03/2014 05:49 PM, Bruce Richardson wrote:\n> Replace a reserved slot with the new packet type field used to identify\n> the type of the packet, i.e. what protocols are used.\n> \n> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>\n> ---\n> lib/librte_mbuf/rte_mbuf.h | 2 +-\n> 1 file changed, 1 insertion(+), 1 deletion(-)\n> \n> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h\n> index f136d37..8d0c6fb 100644\n> --- a/lib/librte_mbuf/rte_mbuf.h\n> +++ b/lib/librte_mbuf/rte_mbuf.h\n> @@ -146,7 +146,7 @@ struct rte_mbuf {\n> \tuint32_t reserved1; /**< Unused field. Required for padding */\n> \n> \t/* remaining bytes are set on RX when pulling packet from descriptor */\n> -\tuint16_t reserved2; /**< Unused field. Required for padding */\n> +\tuint16_t packet_type; /**< Type of packet, e.g. protocols used */\n> \tuint16_t data_len; /**< Amount of data in segment buffer. */\n> \tuint32_t pkt_len; /**< Total pkt len: sum of all segments. */\n> \tuint16_t l3_len:9; /**< L3 (IP) Header Length. */\n> \n\nThis patch adds a new fields that nobody uses. So why should we add it ?", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@dpdk.org", "Delivered-To": "patchwork@dpdk.org", "Received": [ "from [92.243.14.124] (localhost [IPv6:::1])\n\tby dpdk.org (Postfix) with ESMTP id B1C11B3A2;\n\tMon, 8 Sep 2014 12:12:24 +0200 (CEST)", "from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67])\n\tby dpdk.org (Postfix) with ESMTP id 105AE6886\n\tfor <dev@dpdk.org>; Mon, 8 Sep 2014 12:12:23 +0200 (CEST)", "from was59-1-82-226-113-214.fbx.proxad.net ([82.226.113.214]\n\thelo=[192.168.0.10]) by mail.droids-corp.org with esmtpsa\n\t(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128)\n\t(Exim 4.80) (envelope-from <olivier.matz@6wind.com>)\n\tid 1XQw38-0007gy-Rx; Mon, 08 Sep 2014 12:19:58 +0200" ], "Message-ID": "<540D8228.809@6wind.com>", "Date": "Mon, 08 Sep 2014 12:17:12 +0200", "From": "Olivier MATZ <olivier.matz@6wind.com>", "User-Agent": "Mozilla/5.0 (X11; Linux x86_64;\n\trv:24.0) Gecko/20100101 Icedove/24.5.0", "MIME-Version": "1.0", "To": "Bruce Richardson <bruce.richardson@intel.com>, dev@dpdk.org", "References": "<1409759378-10113-1-git-send-email-bruce.richardson@intel.com>\n\t<1409759378-10113-4-git-send-email-bruce.richardson@intel.com>", "In-Reply-To": "<1409759378-10113-4-git-send-email-bruce.richardson@intel.com>", "Content-Type": "text/plain; charset=ISO-8859-1", "Content-Transfer-Encoding": "7bit", "Subject": "Re: [dpdk-dev] [PATCH 03/13] mbuf: add packet_type field", "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>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 682, "web_url": "http://patches.dpdk.org/comment/682/", "msgid": "<540D85E0.4030203@sts.kz>", "list_archive_url": "https://inbox.dpdk.org/dev/540D85E0.4030203@sts.kz", "date": "2014-09-08T10:33:04", "subject": "Re: [dpdk-dev] [PATCH 03/13] mbuf: add packet_type field", "submitter": { "id": 36, "url": "http://patches.dpdk.org/api/people/36/?format=api", "name": "Yerden Zhumabekov", "email": "e_zhumabekov@sts.kz" }, "content": "I would use it :)\nIt's useful to store the IP protocol number (UDP, TCP etc) and version\nof IP (4, 6) and then relay packet to specific handler.\n\n08.09.2014 16:17, Olivier MATZ пишет:\n> Hi Bruce,\n>\n> On 09/03/2014 05:49 PM, Bruce Richardson wrote:\n>> Replace a reserved slot with the new packet type field used to identify\n>> the type of the packet, i.e. what protocols are used.\n>>\n>> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>\n>> ---\n>> lib/librte_mbuf/rte_mbuf.h | 2 +-\n>> 1 file changed, 1 insertion(+), 1 deletion(-)\n>>\n>> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h\n>> index f136d37..8d0c6fb 100644\n>> --- a/lib/librte_mbuf/rte_mbuf.h\n>> +++ b/lib/librte_mbuf/rte_mbuf.h\n>> @@ -146,7 +146,7 @@ struct rte_mbuf {\n>> \tuint32_t reserved1; /**< Unused field. Required for padding */\n>> \n>> \t/* remaining bytes are set on RX when pulling packet from descriptor */\n>> -\tuint16_t reserved2; /**< Unused field. Required for padding */\n>> +\tuint16_t packet_type; /**< Type of packet, e.g. protocols used */\n>> \tuint16_t data_len; /**< Amount of data in segment buffer. */\n>> \tuint32_t pkt_len; /**< Total pkt len: sum of all segments. */\n>> \tuint16_t l3_len:9; /**< L3 (IP) Header Length. */\n>>\n> This patch adds a new fields that nobody uses. So why should we add it ?", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@dpdk.org", "Delivered-To": "patchwork@dpdk.org", "Received": [ "from [92.243.14.124] (localhost [IPv6:::1])\n\tby dpdk.org (Postfix) with ESMTP id 6E0C0B3A1;\n\tMon, 8 Sep 2014 12:29:46 +0200 (CEST)", "from mgw.gov.kz (mgw.gov.kz [89.218.88.242])\n\tby dpdk.org (Postfix) with ESMTP id A13CAB3A0\n\tfor <dev@dpdk.org>; Mon, 8 Sep 2014 12:29:44 +0200 (CEST)", "from mgw.gov.kz (mx.ctsat.kz [178.89.4.95])\n\tby mgw.gov.kz with ESMTP id s88AYdxs007001-s88AYdxt007001;\n\tMon, 8 Sep 2014 16:34:39 +0600", "from EXCASHUB2.rgp.local (192.168.40.53) by EdgeForefront.rgp.local\n\t(192.168.40.59) with Microsoft SMTP Server (TLS) id 14.2.247.3;\n\tMon, 8 Sep 2014 16:34:29 +0600", "from [192.168.35.15] (192.168.35.15) by excashub2.rgp.local\n\t(192.168.40.48) with Microsoft SMTP Server (TLS) id 14.2.247.3;\n\tMon, 8 Sep 2014 16:34:49 +0600" ], "Message-ID": "<540D85E0.4030203@sts.kz>", "Date": "Mon, 8 Sep 2014 16:33:04 +0600", "From": "Yerden Zhumabekov <e_zhumabekov@sts.kz>", "User-Agent": "Mozilla/5.0 (Windows NT 6.3; WOW64;\n\trv:24.0) Gecko/20100101 Thunderbird/24.6.0", "MIME-Version": "1.0", "To": "Olivier MATZ <olivier.matz@6wind.com>, Bruce Richardson\n\t<bruce.richardson@intel.com>, <dev@dpdk.org>", "References": "<1409759378-10113-1-git-send-email-bruce.richardson@intel.com>\n\t<1409759378-10113-4-git-send-email-bruce.richardson@intel.com>\n\t<540D8228.809@6wind.com>", "In-Reply-To": "<540D8228.809@6wind.com>", "X-Enigmail-Version": "1.6", "Content-Type": "text/plain; charset=\"UTF-8\"", "Content-Transfer-Encoding": "8bit", "X-Originating-IP": "[192.168.35.15]", "X-FEAS-SYSTEM-WL": "e_zhumabekov@sts.kz", "Subject": "Re: [dpdk-dev] [PATCH 03/13] mbuf: add packet_type field", "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>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 683, "web_url": "http://patches.dpdk.org/comment/683/", "msgid": "<540D903E.1060206@6wind.com>", "list_archive_url": "https://inbox.dpdk.org/dev/540D903E.1060206@6wind.com", "date": "2014-09-08T11:17:18", "subject": "Re: [dpdk-dev] [PATCH 03/13] mbuf: add packet_type field", "submitter": { "id": 8, "url": "http://patches.dpdk.org/api/people/8/?format=api", "name": "Olivier Matz", "email": "olivier.matz@6wind.com" }, "content": "Hi Yerden,\n\nOn 09/08/2014 12:33 PM, Yerden Zhumabekov wrote:\n> 08.09.2014 16:17, Olivier MATZ пишет:\n>>> --- a/lib/librte_mbuf/rte_mbuf.h\n>>> +++ b/lib/librte_mbuf/rte_mbuf.h\n>>> @@ -146,7 +146,7 @@ struct rte_mbuf {\n>>> \tuint32_t reserved1; /**< Unused field. Required for padding */\n>>> \n>>> \t/* remaining bytes are set on RX when pulling packet from descriptor */\n>>> -\tuint16_t reserved2; /**< Unused field. Required for padding */\n>>> +\tuint16_t packet_type; /**< Type of packet, e.g. protocols used */\n>>> \tuint16_t data_len; /**< Amount of data in segment buffer. */\n>>> \tuint32_t pkt_len; /**< Total pkt len: sum of all segments. */\n>>> \tuint16_t l3_len:9; /**< L3 (IP) Header Length. */\n>>>\n>> This patch adds a new fields that nobody uses. So why should we add it ?\n> \n> I would use it :)\n> It's useful to store the IP protocol number (UDP, TCP etc) and version\n> of IP (4, 6) and then relay packet to specific handler.\n\nI'm not saying this field is useless. But even if it's useful\nfor some applications like yours, it does not mean that it should go in\nthe generic mbuf structure.\n\nAlso, for a new field, we should define who is in charge of filling it.\nIs is the driver? Does it mean that all drivers have to be modified to\nfill it? Or is it just a placeholder for applications? In this case,\nshouldn't we use application-specific metadata? In the other direction\n(TX), we would also need to define if this field must be filled by the\napplication before transmitting a mbuf to a driver.\n\nRegards,\nOlivier", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@dpdk.org", "Delivered-To": "patchwork@dpdk.org", "Received": [ "from [92.243.14.124] (localhost [IPv6:::1])\n\tby dpdk.org (Postfix) with ESMTP id 2F796B38C;\n\tMon, 8 Sep 2014 13:12:33 +0200 (CEST)", "from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67])\n\tby dpdk.org (Postfix) with ESMTP id 36D9E68A8\n\tfor <dev@dpdk.org>; Mon, 8 Sep 2014 13:12:32 +0200 (CEST)", "from was59-1-82-226-113-214.fbx.proxad.net ([82.226.113.214]\n\thelo=[192.168.0.10]) by mail.droids-corp.org with esmtpsa\n\t(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128)\n\t(Exim 4.80) (envelope-from <olivier.matz@6wind.com>)\n\tid 1XQwzI-0007iF-T0; Mon, 08 Sep 2014 13:20:04 +0200" ], "Message-ID": "<540D903E.1060206@6wind.com>", "Date": "Mon, 08 Sep 2014 13:17:18 +0200", "From": "Olivier MATZ <olivier.matz@6wind.com>", "User-Agent": "Mozilla/5.0 (X11; Linux x86_64;\n\trv:24.0) Gecko/20100101 Icedove/24.5.0", "MIME-Version": "1.0", "To": "Yerden Zhumabekov <e_zhumabekov@sts.kz>, \n\tBruce Richardson <bruce.richardson@intel.com>, dev@dpdk.org", "References": "<1409759378-10113-1-git-send-email-bruce.richardson@intel.com>\n\t<1409759378-10113-4-git-send-email-bruce.richardson@intel.com>\n\t<540D8228.809@6wind.com> <540D85E0.4030203@sts.kz>", "In-Reply-To": "<540D85E0.4030203@sts.kz>", "Content-Type": "text/plain; charset=UTF-8", "Content-Transfer-Encoding": "8bit", "Subject": "Re: [dpdk-dev] [PATCH 03/13] mbuf: add packet_type field", "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>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 689, "web_url": "http://patches.dpdk.org/comment/689/", "msgid": "<1ED644BD7E0A5F4091CF203DAFB8E4CC01D64E58@SHSMSX101.ccr.corp.intel.com>", "list_archive_url": "https://inbox.dpdk.org/dev/1ED644BD7E0A5F4091CF203DAFB8E4CC01D64E58@SHSMSX101.ccr.corp.intel.com", "date": "2014-09-09T03:57:33", "subject": "Re: [dpdk-dev] [PATCH 03/13] mbuf: add packet_type field", "submitter": { "id": 52, "url": "http://patches.dpdk.org/api/people/52/?format=api", "name": "Jijiang Liu", "email": "jijiang.liu@intel.com" }, "content": "Hi Olivier,\r\n\r\n> -----Original Message-----\r\n> From: Zhu, Heqing\r\n> Sent: Tuesday, September 09, 2014 9:48 AM\r\n> To: Wu, Jingjing; Liu, Jijiang; Zhang, Helin\r\n> Cc: Zhu, Heqing\r\n> Subject: FW: [dpdk-dev] [PATCH 03/13] mbuf: add packet_type field\r\n> \r\n> One of you need respond to this thread? Please make the answer generic and\r\n> easy to understand/accept if possible.\r\n> \r\n> -----Original Message-----\r\n> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier MATZ\r\n> Sent: Monday, September 08, 2014 7:17 PM\r\n> To: Yerden Zhumabekov; Richardson, Bruce; dev@dpdk.org\r\n> Subject: Re: [dpdk-dev] [PATCH 03/13] mbuf: add packet_type field\r\n> \r\n> Hi Yerden,\r\n> \r\n> On 09/08/2014 12:33 PM, Yerden Zhumabekov wrote:\r\n> > 08.09.2014 16:17, Olivier MATZ пишет:\r\n> >>> --- a/lib/librte_mbuf/rte_mbuf.h\r\n> >>> +++ b/lib/librte_mbuf/rte_mbuf.h\r\n> >>> @@ -146,7 +146,7 @@ struct rte_mbuf {\r\n> >>> \tuint32_t reserved1; /**< Unused field. Required for padding */\r\n> >>>\r\n> >>> \t/* remaining bytes are set on RX when pulling packet from descriptor\r\n> */\r\n> >>> -\tuint16_t reserved2; /**< Unused field. Required for padding */\r\n> >>> +\tuint16_t packet_type; /**< Type of packet, e.g. protocols used */\r\n> >>> \tuint16_t data_len; /**< Amount of data in segment buffer. */\r\n> >>> \tuint32_t pkt_len; /**< Total pkt len: sum of all segments. */\r\n> >>> \tuint16_t l3_len:9; /**< L3 (IP) Header Length. */\r\n> >>>\r\n> >> This patch adds a new fields that nobody uses. So why should we add it ?\r\n> >\r\n> > I would use it :)\r\n> > It's useful to store the IP protocol number (UDP, TCP etc) and version\r\n> > of IP (4, 6) and then relay packet to specific handler.\r\n> \r\n> I'm not saying this field is useless. But even if it's useful for some applications\r\n> like yours, it does not mean that it should go in the generic mbuf structure.\r\n\r\nIn some types of NIC, for an example, Intel Fortville, which supports various packet types, and packet type value is filled in a field of receive Descriptor by HW,\r\nNormally, application analyses easily what incoming packet format is if it know what packet type is. It is a common approach for analyzing packet format.\r\n\r\n> Also, for a new field, we should define who is in charge of filling it.\r\n> Is is the driver? Does it mean that all drivers have to be modified to fill it? Or is\r\n> it just a placeholder for applications? In this case, shouldn't we use\r\n> application-specific metadata?\r\n\r\nYes, driver is in charge of filling it if this type of NIC has a packet type filed in receive Descriptor.\r\n\r\n> In the other direction (TX), we would also need\r\n> to define if this field must be filled by the application before transmitting a\r\n> mbuf to a driver.\r\n\r\nNormally, TX side don't care the packet type, instead, feature offload flag will be used in TX side.\r\n In RX side, NIC HW analyses incoming packet and know what packet type is, and fill packet type value in Receive Descriptor.\r\nOf course, I also don't object to add a packet type in TX side if mbuf TX space is enough, but from the present point of view, it is not necessary. \r\n\r\n> Regards,\r\n> Olivier\r\n\r\nRegards,\r\nJijiang Liu", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@dpdk.org", "Delivered-To": "patchwork@dpdk.org", "Received": [ "from [92.243.14.124] (localhost [IPv6:::1])\n\tby dpdk.org (Postfix) with ESMTP id 448256AB7;\n\tTue, 9 Sep 2014 05:52:38 +0200 (CEST)", "from mga02.intel.com (mga02.intel.com [134.134.136.20])\n\tby dpdk.org (Postfix) with ESMTP id 7EBB338EB\n\tfor <dev@dpdk.org>; Tue, 9 Sep 2014 05:52:35 +0200 (CEST)", "from orsmga002.jf.intel.com ([10.7.209.21])\n\tby orsmga101.jf.intel.com with ESMTP; 08 Sep 2014 20:57:36 -0700", "from fmsmsx104.amr.corp.intel.com ([10.18.124.202])\n\tby orsmga002.jf.intel.com with ESMTP; 08 Sep 2014 20:57:35 -0700", "from fmsmsx117.amr.corp.intel.com (10.18.116.17) by\n\tfmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP\n\tServer (TLS) id 14.3.195.1; Mon, 8 Sep 2014 20:57:35 -0700", "from shsmsx102.ccr.corp.intel.com (10.239.4.154) by\n\tfmsmsx117.amr.corp.intel.com (10.18.116.17) with Microsoft SMTP\n\tServer (TLS) id 14.3.195.1; Mon, 8 Sep 2014 20:57:35 -0700", "from shsmsx101.ccr.corp.intel.com ([169.254.1.198]) by\n\tshsmsx102.ccr.corp.intel.com ([169.254.2.246]) with mapi id\n\t14.03.0195.001; Tue, 9 Sep 2014 11:57:33 +0800" ], "X-ExtLoop1": "1", "X-IronPort-AV": "E=Sophos;i=\"5.04,490,1406617200\"; d=\"scan'208\";a=\"600021950\"", "From": "\"Liu, Jijiang\" <jijiang.liu@intel.com>", "To": "\"olivier.matz@6wind.com\" <olivier.matz@6wind.com>", "Thread-Topic": "[dpdk-dev] [PATCH 03/13] mbuf: add packet_type field", "Thread-Index": "AQHPx47fcPCojczbpkeAjNkF8h7F9pv2huIAgAAEbgCAAAxcAIABePZQgAAXAzA=", "Date": "Tue, 9 Sep 2014 03:57:33 +0000", "Message-ID": "<1ED644BD7E0A5F4091CF203DAFB8E4CC01D64E58@SHSMSX101.ccr.corp.intel.com>", "References": "<1409759378-10113-1-git-send-email-bruce.richardson@intel.com>\n\t<1409759378-10113-4-git-send-email-bruce.richardson@intel.com>\n\t<540D8228.809@6wind.com> <540D85E0.4030203@sts.kz>\n\t<540D903E.1060206@6wind.com>\n\t<CAD16F236028A64DBBC0158B1636EA4510F3E4F8@SHSMSX104.ccr.corp.intel.com>", "In-Reply-To": "<CAD16F236028A64DBBC0158B1636EA4510F3E4F8@SHSMSX104.ccr.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=\"utf-8\"", "Content-Transfer-Encoding": "base64", "MIME-Version": "1.0", "Cc": "\"dev@dpdk.org\" <dev@dpdk.org>", "Subject": "Re: [dpdk-dev] [PATCH 03/13] mbuf: add packet_type field", "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>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 690, "web_url": "http://patches.dpdk.org/comment/690/", "msgid": "<F35DEAC7BCE34641BA9FAC6BCA4A12E70A784E49@SHSMSX104.ccr.corp.intel.com>", "list_archive_url": "https://inbox.dpdk.org/dev/F35DEAC7BCE34641BA9FAC6BCA4A12E70A784E49@SHSMSX104.ccr.corp.intel.com", "date": "2014-09-09T03:59:48", "subject": "Re: [dpdk-dev] [PATCH 03/13] mbuf: add packet_type field", "submitter": { "id": 14, "url": "http://patches.dpdk.org/api/people/14/?format=api", "name": "Zhang, Helin", "email": "helin.zhang@intel.com" }, "content": "> -----Original Message-----\r\n> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier MATZ\r\n> Sent: Monday, September 8, 2014 7:17 PM\r\n> To: Yerden Zhumabekov; Richardson, Bruce; dev@dpdk.org\r\n> Subject: Re: [dpdk-dev] [PATCH 03/13] mbuf: add packet_type field\r\n> \r\n> Hi Yerden,\r\n> \r\n> On 09/08/2014 12:33 PM, Yerden Zhumabekov wrote:\r\n> > 08.09.2014 16:17, Olivier MATZ пишет:\r\n> >>> --- a/lib/librte_mbuf/rte_mbuf.h\r\n> >>> +++ b/lib/librte_mbuf/rte_mbuf.h\r\n> >>> @@ -146,7 +146,7 @@ struct rte_mbuf {\r\n> >>> \tuint32_t reserved1; /**< Unused field. Required for padding */\r\n> >>>\r\n> >>> \t/* remaining bytes are set on RX when pulling packet from descriptor\r\n> */\r\n> >>> -\tuint16_t reserved2; /**< Unused field. Required for padding */\r\n> >>> +\tuint16_t packet_type; /**< Type of packet, e.g. protocols used */\r\n> >>> \tuint16_t data_len; /**< Amount of data in segment buffer. */\r\n> >>> \tuint32_t pkt_len; /**< Total pkt len: sum of all segments. */\r\n> >>> \tuint16_t l3_len:9; /**< L3 (IP) Header Length. */\r\n> >>>\r\n> >> This patch adds a new fields that nobody uses. So why should we add it ?\r\n> >\r\n> > I would use it :)\r\n> > It's useful to store the IP protocol number (UDP, TCP etc) and version\r\n> > of IP (4, 6) and then relay packet to specific handler.\r\n\r\nIt is a common field which i40e PMD will use it to store the 'packet type ID'. i40e\r\nhardware can recognize more than a hundred of packet types of received packets,\r\nthis is quite useful for upper layer stack or application. So this field is quite useful\r\nand will be filled by PMD.\r\nIn ixgbe/igb, it has less than 10 packet types which are marked in offload flags. From\r\nnow on, it would be better to have new field here to put the hardware offloaded\r\npacket type in and it could be used for future NICs.\r\n\r\n> \r\n> I'm not saying this field is useless. But even if it's useful for some applications\r\n> like yours, it does not mean that it should go in the generic mbuf structure.\r\n> \r\n> Also, for a new field, we should define who is in charge of filling it.\r\n> Is is the driver? Does it mean that all drivers have to be modified to fill it? Or is\r\n> it just a placeholder for applications? In this case, shouldn't we use\r\n> application-specific metadata? In the other direction (TX), we would also need\r\n> to define if this field must be filled by the application before transmitting a mbuf\r\n> to a driver.\r\nYes, PMD will fill it. I40e PMD will be the first one, ixgbe/igb can be kept as it is, or\r\nmodified to be consistent. It is used for RX side only, and for TX side, it can be\r\ninvestigated to see if it can be used also. I think some new features in development\r\ncan think of that.\r\nAnyway, it is a quite useful field for i40e and future generation of NICs.\r\n> \r\n> Regards,\r\n> Olivier", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@dpdk.org", "Delivered-To": "patchwork@dpdk.org", "Received": [ "from [92.243.14.124] (localhost [IPv6:::1])\n\tby dpdk.org (Postfix) with ESMTP id 3BBC36AB7;\n\tTue, 9 Sep 2014 05:54:53 +0200 (CEST)", "from mga02.intel.com (mga02.intel.com [134.134.136.20])\n\tby dpdk.org (Postfix) with ESMTP id C12A038EB\n\tfor <dev@dpdk.org>; Tue, 9 Sep 2014 05:54:50 +0200 (CEST)", "from orsmga002.jf.intel.com ([10.7.209.21])\n\tby orsmga101.jf.intel.com with ESMTP; 08 Sep 2014 20:59:52 -0700", "from fmsmsx104.amr.corp.intel.com ([10.18.124.202])\n\tby orsmga002.jf.intel.com with ESMTP; 08 Sep 2014 20:59:51 -0700", "from shsmsx102.ccr.corp.intel.com (10.239.4.154) by\n\tfmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP\n\tServer (TLS) id 14.3.195.1; Mon, 8 Sep 2014 20:59:51 -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; Tue, 9 Sep 2014 11:59:49 +0800" ], "X-ExtLoop1": "1", "X-IronPort-AV": "E=Sophos;i=\"5.04,490,1406617200\"; d=\"scan'208\";a=\"600022931\"", "From": "\"Zhang, Helin\" <helin.zhang@intel.com>", "To": "Olivier MATZ <olivier.matz@6wind.com>, Yerden Zhumabekov\n\t<e_zhumabekov@sts.kz>, \"Richardson, Bruce\" <bruce.richardson@intel.com>, \n\t\"dev@dpdk.org\" <dev@dpdk.org>", "Thread-Topic": "[dpdk-dev] [PATCH 03/13] mbuf: add packet_type field", "Thread-Index": "AQHPx47fYiE42MbwtEillcPBudwivJv2huIAgAAEbgCAAAxcAIABmb7Q", "Date": "Tue, 9 Sep 2014 03:59:48 +0000", "Message-ID": "<F35DEAC7BCE34641BA9FAC6BCA4A12E70A784E49@SHSMSX104.ccr.corp.intel.com>", "References": "<1409759378-10113-1-git-send-email-bruce.richardson@intel.com>\n\t<1409759378-10113-4-git-send-email-bruce.richardson@intel.com>\n\t<540D8228.809@6wind.com> <540D85E0.4030203@sts.kz>\n\t<540D903E.1060206@6wind.com>", "In-Reply-To": "<540D903E.1060206@6wind.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=\"utf-8\"", "Content-Transfer-Encoding": "base64", "MIME-Version": "1.0", "Subject": "Re: [dpdk-dev] [PATCH 03/13] mbuf: add packet_type field", "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>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 706, "web_url": "http://patches.dpdk.org/comment/706/", "msgid": "<540EB428.9060706@6wind.com>", "list_archive_url": "https://inbox.dpdk.org/dev/540EB428.9060706@6wind.com", "date": "2014-09-09T08:02:48", "subject": "Re: [dpdk-dev] [PATCH 03/13] mbuf: add packet_type field", "submitter": { "id": 8, "url": "http://patches.dpdk.org/api/people/8/?format=api", "name": "Olivier Matz", "email": "olivier.matz@6wind.com" }, "content": "Hello,\n\nOn 09/09/2014 05:59 AM, Zhang, Helin wrote:\n> It is a common field which i40e PMD will use it to store the 'packet type ID'. i40e\n> hardware can recognize more than a hundred of packet types of received packets,\n> this is quite useful for upper layer stack or application. So this field is quite useful\n> and will be filled by PMD.\n> In ixgbe/igb, it has less than 10 packet types which are marked in offload flags. From\n> now on, it would be better to have new field here to put the hardware offloaded\n> packet type in and it could be used for future NICs.\n>\n>>\n>> I'm not saying this field is useless. But even if it's useful for some applications\n>> like yours, it does not mean that it should go in the generic mbuf structure.\n>>\n>> Also, for a new field, we should define who is in charge of filling it.\n>> Is is the driver? Does it mean that all drivers have to be modified to fill it? Or is\n>> it just a placeholder for applications? In this case, shouldn't we use\n>> application-specific metadata? In the other direction (TX), we would also need\n>> to define if this field must be filled by the application before transmitting a mbuf\n>> to a driver.\n> Yes, PMD will fill it. I40e PMD will be the first one, ixgbe/igb can be kept as it is, or\n> modified to be consistent. It is used for RX side only, and for TX side, it can be\n> investigated to see if it can be used also. I think some new features in development\n> can think of that.\n> Anyway, it is a quite useful field for i40e and future generation of NICs.\n\nTo me, having the support in a hardware for that feature is not a\nsufficient reason for adding this field. There are many hardware\nfeatures that will never be integrated in dpdk.\n\nThis first version of the patch:\n\n- just adds a field that is not used by any code, so it is useless.\n At least testpmd or an application example should show how to\n use it.\n\n- does not describe what enhancement is provided by adding the\n field (performance? in this case, numbers + use case would help\n to convince people).\n\n- does not describe what can be the content of the field. Is it\n a protocol number?\n\n- does not explain if all drivers must fill this field. If yes,\n the patch has to update all drivers. If not, something must be\n done to mark the packet field as unknown by default.\n\nRegards,\nOlivier", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@dpdk.org", "Delivered-To": "patchwork@dpdk.org", "Received": [ "from [92.243.14.124] (localhost [IPv6:::1])\n\tby dpdk.org (Postfix) with ESMTP id F41ABB3A5;\n\tTue, 9 Sep 2014 09:57:48 +0200 (CEST)", "from mail-we0-f178.google.com (mail-we0-f178.google.com\n\t[74.125.82.178]) by dpdk.org (Postfix) with ESMTP id 07557B3A1\n\tfor <dev@dpdk.org>; Tue, 9 Sep 2014 09:57:48 +0200 (CEST)", "by mail-we0-f178.google.com with SMTP id q58so4255935wes.9\n\tfor <dev@dpdk.org>; Tue, 09 Sep 2014 01:02:51 -0700 (PDT)", "from [10.16.0.195] (guy78-3-82-239-227-177.fbx.proxad.net.\n\t[82.239.227.177]) by mx.google.com with ESMTPSA id\n\tn5sm13879149wja.38.2014.09.09.01.02.49 for <multiple recipients>\n\t(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);\n\tTue, 09 Sep 2014 01:02:50 -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:message-id:date:from:user-agent:mime-version:to\n\t:subject:references:in-reply-to:content-type\n\t:content-transfer-encoding;\n\tbh=kZquozVu75mM9RRsxAgvGH0aWW14DJM8uzQRbEqGA3g=;\n\tb=FWk267u1J7Q1x6FEqxsKzlI1KMKp7fSkavIVhKoL6kFCSHTBcPvXGfu8jHH+0j2BX0\n\t4DA+AiXnt1uri3Z3ehd/WcoXA9sxMdZsRmqgemXGzZypFZ/WF51u0CMxm3GUQ+e0fX7u\n\tKwGad9degH8PAUDBf2IOvskVwvDmlz2hC7pj1QE81TepizqC4ALNpLNFu6f7i2UMs9QM\n\tsCI2TyTU1VI1BbwvJBn8s0D/JCKPIsh6SvR5yqpj0ax+50cWc+txIfslI8f2FZQc5H6Q\n\tP2QgQ03osZefqFjM3f0vScQ+u1Tq2H10G53fo7kuHEqSsZ7fFHRutWGRgECVjcnZ5R8k\n\t1VJw==", "X-Gm-Message-State": "ALoCoQmG0+LOU8ESmss3oaSHTI2UK0etGn5TUTrRAP2d7XJX65lN84v75ntkWDiTrCoI8uyxeTwM", "X-Received": "by 10.180.75.17 with SMTP id y17mr27888236wiv.3.1410249771188;\n\tTue, 09 Sep 2014 01:02:51 -0700 (PDT)", "Message-ID": "<540EB428.9060706@6wind.com>", "Date": "Tue, 09 Sep 2014 10:02:48 +0200", "From": "Olivier MATZ <olivier.matz@6wind.com>", "User-Agent": "Mozilla/5.0 (X11; Linux x86_64;\n\trv:24.0) Gecko/20100101 Icedove/24.5.0", "MIME-Version": "1.0", "To": "\"Zhang, Helin\" <helin.zhang@intel.com>, \n\tYerden Zhumabekov <e_zhumabekov@sts.kz>,\n\t\"Richardson, Bruce\" <bruce.richardson@intel.com>, \n\t\"dev@dpdk.org\" <dev@dpdk.org>", "References": "<1409759378-10113-1-git-send-email-bruce.richardson@intel.com>\n\t<1409759378-10113-4-git-send-email-bruce.richardson@intel.com>\n\t<540D8228.809@6wind.com> <540D85E0.4030203@sts.kz>\n\t<540D903E.1060206@6wind.com>\n\t<F35DEAC7BCE34641BA9FAC6BCA4A12E70A784E49@SHSMSX104.ccr.corp.intel.com>", "In-Reply-To": "<F35DEAC7BCE34641BA9FAC6BCA4A12E70A784E49@SHSMSX104.ccr.corp.intel.com>", "Content-Type": "text/plain; charset=UTF-8; format=flowed", "Content-Transfer-Encoding": "7bit", "Subject": "Re: [dpdk-dev] [PATCH 03/13] mbuf: add packet_type field", "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>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 707, "web_url": "http://patches.dpdk.org/comment/707/", "msgid": "<F35DEAC7BCE34641BA9FAC6BCA4A12E70A78512E@SHSMSX104.ccr.corp.intel.com>", "list_archive_url": "https://inbox.dpdk.org/dev/F35DEAC7BCE34641BA9FAC6BCA4A12E70A78512E@SHSMSX104.ccr.corp.intel.com", "date": "2014-09-09T08:45:27", "subject": "Re: [dpdk-dev] [PATCH 03/13] mbuf: add packet_type field", "submitter": { "id": 14, "url": "http://patches.dpdk.org/api/people/14/?format=api", "name": "Zhang, Helin", "email": "helin.zhang@intel.com" }, "content": "> -----Original Message-----\r\n> From: Olivier MATZ [mailto:olivier.matz@6wind.com]\r\n> Sent: Tuesday, September 9, 2014 4:03 PM\r\n> To: Zhang, Helin; Yerden Zhumabekov; Richardson, Bruce; dev@dpdk.org\r\n> Subject: Re: [dpdk-dev] [PATCH 03/13] mbuf: add packet_type field\r\n> \r\n> Hello,\r\n> \r\n> On 09/09/2014 05:59 AM, Zhang, Helin wrote:\r\n> > It is a common field which i40e PMD will use it to store the 'packet\r\n> > type ID'. i40e hardware can recognize more than a hundred of packet\r\n> > types of received packets, this is quite useful for upper layer stack\r\n> > or application. So this field is quite useful and will be filled by PMD.\r\n> > In ixgbe/igb, it has less than 10 packet types which are marked in\r\n> > offload flags. From now on, it would be better to have new field here\r\n> > to put the hardware offloaded packet type in and it could be used for future\r\n> NICs.\r\n> >\r\n> >>\r\n> >> I'm not saying this field is useless. But even if it's useful for\r\n> >> some applications like yours, it does not mean that it should go in the\r\n> generic mbuf structure.\r\n> >>\r\n> >> Also, for a new field, we should define who is in charge of filling it.\r\n> >> Is is the driver? Does it mean that all drivers have to be modified\r\n> >> to fill it? Or is it just a placeholder for applications? In this\r\n> >> case, shouldn't we use application-specific metadata? In the other\r\n> >> direction (TX), we would also need to define if this field must be\r\n> >> filled by the application before transmitting a mbuf to a driver.\r\n> > Yes, PMD will fill it. I40e PMD will be the first one, ixgbe/igb can\r\n> > be kept as it is, or modified to be consistent. It is used for RX side\r\n> > only, and for TX side, it can be investigated to see if it can be used\r\n> > also. I think some new features in development can think of that.\r\n> > Anyway, it is a quite useful field for i40e and future generation of NICs.\r\n> \r\n> To me, having the support in a hardware for that feature is not a sufficient\r\n> reason for adding this field. There are many hardware features that will never\r\n> be integrated in dpdk.\r\n\r\nAt least this field is quite important for i40e.\r\ne.g. packet type=43 means that hardware recognize it as a VXLAN packet. To avoid checking what type of packet by software, hardware can offload that, and fill the packet type ID in that field.\r\nIt cannot be put in ol_flags anymore, as it has more than 100 packet type can be recognized by hardware. Without it, vxlan feature cannot be implemented at all. \r\n\r\n> \r\n> This first version of the patch:\r\n> \r\n> - just adds a field that is not used by any code, so it is useless.\r\n> At least testpmd or an application example should show how to\r\n> use it.\r\n\r\nIt will be used at least in vxlan feature which is in development. Without it, vxlan cannot be completed. So this is a very important field i40e and future NICs.\r\n\r\n>\r\n> - does not describe what enhancement is provided by adding the\r\n> field (performance? in this case, numbers + use case would help\r\n> to convince people).\r\n\r\nI40e hardware can recognize received packets as different packet types, and there are about 256 packet types can be recognized by i40e hardware. It is not a enhancement, it is the key for at least i40e features.\r\n\r\n> \r\n> - does not describe what can be the content of the field. Is it\r\n> a protocol number?\r\n> \r\n\r\nThe packet type is a offload feature of hardware, the value of it can mean one type of packet recognized by the i40e hardware. E.g.\r\n\r\n| Packet type | Description |\r\n| 0 | Reserved |\r\n| 1 | MAC, PAY2 |\r\n| 2 | MAC, TimeSync, PAY2 |\r\n...\r\n| 43 | MAC, IPV4, GRENAT, PAY3 |\r\n\r\n> - does not explain if all drivers must fill this field. If yes,\r\n> the patch has to update all drivers. If not, something must be\r\n> done to mark the packet field as unknown by default.\r\n> \r\nI40e needs it.\r\nigb/ixgbe can be changed to support it, but not mandatory, as ol_flags can represent it.\r\nActually ixgbe and igb has packet type also, but the number of those types is less than 10, so it can be put in ol_flags. For i40e and future NICs, the number of that could be 256 or more, ol_flags does not have that many bits for it. The best idea is to fill the packet type ID directly into a field.\r\n\r\n> Regards,\r\n> Olivier\r\n\r\nRegards,\r\nHelin", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@dpdk.org", "Delivered-To": "patchwork@dpdk.org", "Received": [ "from [92.243.14.124] (localhost [IPv6:::1])\n\tby dpdk.org (Postfix) with ESMTP id A401BB3AB;\n\tTue, 9 Sep 2014 10:40:51 +0200 (CEST)", "from mga02.intel.com (mga02.intel.com [134.134.136.20])\n\tby dpdk.org (Postfix) with ESMTP id 5C9C1B3AA\n\tfor <dev@dpdk.org>; Tue, 9 Sep 2014 10:40:49 +0200 (CEST)", "from orsmga001.jf.intel.com ([10.7.209.18])\n\tby orsmga101.jf.intel.com with ESMTP; 09 Sep 2014 01:45:51 -0700", "from fmsmsx105.amr.corp.intel.com ([10.18.124.203])\n\tby orsmga001.jf.intel.com with ESMTP; 09 Sep 2014 01:45:51 -0700", "from fmsmsx152.amr.corp.intel.com (10.18.125.5) by\n\tFMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP\n\tServer (TLS) id 14.3.195.1; Tue, 9 Sep 2014 01:45:50 -0700", "from shsmsx151.ccr.corp.intel.com (10.239.6.50) by\n\tFMSMSX152.amr.corp.intel.com (10.18.125.5) with Microsoft SMTP Server\n\t(TLS) id 14.3.195.1; Tue, 9 Sep 2014 01:45:50 -0700", "from shsmsx104.ccr.corp.intel.com ([169.254.5.17]) by\n\tSHSMSX151.ccr.corp.intel.com ([169.254.3.172]) with mapi id\n\t14.03.0195.001; Tue, 9 Sep 2014 16:45:28 +0800" ], "X-ExtLoop1": "1", "X-IronPort-AV": "E=Sophos;i=\"5.04,491,1406617200\"; d=\"scan'208\";a=\"570424924\"", "From": "\"Zhang, Helin\" <helin.zhang@intel.com>", "To": "Olivier MATZ <olivier.matz@6wind.com>, Yerden Zhumabekov\n\t<e_zhumabekov@sts.kz>, \"Richardson, Bruce\" <bruce.richardson@intel.com>, \n\t\"dev@dpdk.org\" <dev@dpdk.org>", "Thread-Topic": "[dpdk-dev] [PATCH 03/13] mbuf: add packet_type field", "Thread-Index": "AQHPx47fYiE42MbwtEillcPBudwivJv2huIAgAAEbgCAAAxcAIABmb7Q///CPwCAAIn44A==", "Date": "Tue, 9 Sep 2014 08:45:27 +0000", "Message-ID": "<F35DEAC7BCE34641BA9FAC6BCA4A12E70A78512E@SHSMSX104.ccr.corp.intel.com>", "References": "<1409759378-10113-1-git-send-email-bruce.richardson@intel.com>\n\t<1409759378-10113-4-git-send-email-bruce.richardson@intel.com>\n\t<540D8228.809@6wind.com> <540D85E0.4030203@sts.kz>\n\t<540D903E.1060206@6wind.com>\n\t<F35DEAC7BCE34641BA9FAC6BCA4A12E70A784E49@SHSMSX104.ccr.corp.intel.com>\n\t<540EB428.9060706@6wind.com>", "In-Reply-To": "<540EB428.9060706@6wind.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=\"utf-8\"", "Content-Transfer-Encoding": "base64", "MIME-Version": "1.0", "Subject": "Re: [dpdk-dev] [PATCH 03/13] mbuf: add packet_type field", "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>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 711, "web_url": "http://patches.dpdk.org/comment/711/", "msgid": "<59AF69C657FD0841A61C55336867B5B0343EFB2C@IRSMSX103.ger.corp.intel.com>", "list_archive_url": "https://inbox.dpdk.org/dev/59AF69C657FD0841A61C55336867B5B0343EFB2C@IRSMSX103.ger.corp.intel.com", "date": "2014-09-09T09:47:11", "subject": "Re: [dpdk-dev] [PATCH 03/13] mbuf: add packet_type field", "submitter": { "id": 20, "url": "http://patches.dpdk.org/api/people/20/?format=api", "name": "Bruce Richardson", "email": "bruce.richardson@intel.com" }, "content": "> -----Original Message-----\r\n> From: Olivier MATZ [mailto:olivier.matz@6wind.com]\r\n> Sent: Tuesday, September 09, 2014 9:03 AM\r\n> To: Zhang, Helin; Yerden Zhumabekov; Richardson, Bruce; dev@dpdk.org\r\n> Subject: Re: [dpdk-dev] [PATCH 03/13] mbuf: add packet_type field\r\n> \r\n> Hello,\r\n> \r\n> On 09/09/2014 05:59 AM, Zhang, Helin wrote:\r\n> > It is a common field which i40e PMD will use it to store the 'packet type ID'.\r\n> i40e\r\n> > hardware can recognize more than a hundred of packet types of received\r\n> packets,\r\n> > this is quite useful for upper layer stack or application. So this field is quite\r\n> useful\r\n> > and will be filled by PMD.\r\n> > In ixgbe/igb, it has less than 10 packet types which are marked in offload flags.\r\n> From\r\n> > now on, it would be better to have new field here to put the hardware\r\n> offloaded\r\n> > packet type in and it could be used for future NICs.\r\n> >\r\n> >>\r\n> >> I'm not saying this field is useless. But even if it's useful for some applications\r\n> >> like yours, it does not mean that it should go in the generic mbuf structure.\r\n> >>\r\n> >> Also, for a new field, we should define who is in charge of filling it.\r\n> >> Is is the driver? Does it mean that all drivers have to be modified to fill it? Or\r\n> is\r\n> >> it just a placeholder for applications? In this case, shouldn't we use\r\n> >> application-specific metadata? In the other direction (TX), we would also\r\n> need\r\n> >> to define if this field must be filled by the application before transmitting a\r\n> mbuf\r\n> >> to a driver.\r\n> > Yes, PMD will fill it. I40e PMD will be the first one, ixgbe/igb can be kept as it\r\n> is, or\r\n> > modified to be consistent. It is used for RX side only, and for TX side, it can be\r\n> > investigated to see if it can be used also. I think some new features in\r\n> development\r\n> > can think of that.\r\n> > Anyway, it is a quite useful field for i40e and future generation of NICs.\r\n> \r\n> To me, having the support in a hardware for that feature is not a\r\n> sufficient reason for adding this field. There are many hardware\r\n> features that will never be integrated in dpdk.\r\n> \r\n> This first version of the patch:\r\n> \r\n> - just adds a field that is not used by any code, so it is useless.\r\n> At least testpmd or an application example should show how to\r\n> use it.\r\n> \r\n> - does not describe what enhancement is provided by adding the\r\n> field (performance? in this case, numbers + use case would help\r\n> to convince people).\r\n> \r\n> - does not describe what can be the content of the field. Is it\r\n> a protocol number?\r\n> \r\n> - does not explain if all drivers must fill this field. If yes,\r\n> the patch has to update all drivers. If not, something must be\r\n> done to mark the packet field as unknown by default.\r\n> \r\n> Regards,\r\n> Olivier\r\n\r\nHi,\r\n\r\nPoints taken. Really, this patch doesn't belong in this set as I had planned things and better belongs in patch set 3 (coming soon, I hope) which should propose the new field additions. I simply put it here to avoid having to start renumbering and renaming reserved fields in the structure, but that is possibly the lesser of the two evils.\r\n\r\nHowever, with regards to adding new fields in, I would like to have some agreement that I can add fields in without actually pushing in the patch to use them - so long as sufficient rational is provided for using the field and there is a soon pending change to actually use it. This patch did not meet the criteria for explanation, but if updated to do so, I would like to have this patch accepted on the basis of that explanation so as to enable those working on the drivers to make us of it. \r\n\r\nRegards,\r\n/Bruce", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@dpdk.org", "Delivered-To": "patchwork@dpdk.org", "Received": [ "from [92.243.14.124] (localhost [IPv6:::1])\n\tby dpdk.org (Postfix) with ESMTP id 895ADB3A5;\n\tTue, 9 Sep 2014 11:42:52 +0200 (CEST)", "from mga02.intel.com (mga02.intel.com [134.134.136.20])\n\tby dpdk.org (Postfix) with ESMTP id 97926B3A4\n\tfor <dev@dpdk.org>; Tue, 9 Sep 2014 11:42:50 +0200 (CEST)", "from orsmga002.jf.intel.com ([10.7.209.21])\n\tby orsmga101.jf.intel.com with ESMTP; 09 Sep 2014 02:47:46 -0700", "from irsmsx102.ger.corp.intel.com ([163.33.3.155])\n\tby orsmga002.jf.intel.com with ESMTP; 09 Sep 2014 02:47:13 -0700", "from irsmsx154.ger.corp.intel.com (163.33.192.96) by\n\tIRSMSX102.ger.corp.intel.com (163.33.3.155) with Microsoft SMTP\n\tServer (TLS) id 14.3.195.1; Tue, 9 Sep 2014 10:47:12 +0100", "from irsmsx103.ger.corp.intel.com ([169.254.3.112]) by\n\tIRSMSX154.ger.corp.intel.com ([169.254.12.233]) with mapi id\n\t14.03.0195.001; Tue, 9 Sep 2014 10:47:12 +0100" ], "X-ExtLoop1": "1", "X-IronPort-AV": "E=Sophos;i=\"5.04,491,1406617200\"; d=\"scan'208\";a=\"600142007\"", "From": "\"Richardson, Bruce\" <bruce.richardson@intel.com>", "To": "Olivier MATZ <olivier.matz@6wind.com>, \"Zhang, Helin\"\n\t<helin.zhang@intel.com>, Yerden Zhumabekov <e_zhumabekov@sts.kz>,\n\t\"dev@dpdk.org\" <dev@dpdk.org>", "Thread-Topic": "[dpdk-dev] [PATCH 03/13] mbuf: add packet_type field", "Thread-Index": "AQHPx46uobHyPHV+a0CwgK5disgG7Jv2/DsAgAAEbwCAAAxbAIABGBkAgABD5ACAACSygA==", "Date": "Tue, 9 Sep 2014 09:47:11 +0000", "Message-ID": "<59AF69C657FD0841A61C55336867B5B0343EFB2C@IRSMSX103.ger.corp.intel.com>", "References": "<1409759378-10113-1-git-send-email-bruce.richardson@intel.com>\n\t<1409759378-10113-4-git-send-email-bruce.richardson@intel.com>\n\t<540D8228.809@6wind.com> <540D85E0.4030203@sts.kz>\n\t<540D903E.1060206@6wind.com>\n\t<F35DEAC7BCE34641BA9FAC6BCA4A12E70A784E49@SHSMSX104.ccr.corp.intel.com>\n\t<540EB428.9060706@6wind.com>", "In-Reply-To": "<540EB428.9060706@6wind.com>", "Accept-Language": "en-GB, 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=\"utf-8\"", "Content-Transfer-Encoding": "base64", "MIME-Version": "1.0", "Subject": "Re: [dpdk-dev] [PATCH 03/13] mbuf: add packet_type field", "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>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 713, "web_url": "http://patches.dpdk.org/comment/713/", "msgid": "<FF410A1A-40E3-4D65-995F-E4B09A0389A5@netgate.com>", "list_archive_url": "https://inbox.dpdk.org/dev/FF410A1A-40E3-4D65-995F-E4B09A0389A5@netgate.com", "date": "2014-09-09T15:05:43", "subject": "Re: [dpdk-dev] [PATCH 03/13] mbuf: add packet_type field", "submitter": { "id": 65, "url": "http://patches.dpdk.org/api/people/65/?format=api", "name": "Jim Thompson", "email": "jim@netgate.com" }, "content": "> On Sep 8, 2014, at 4:17 AM, Olivier MATZ <olivier.matz@6wind.com> wrote:\n> \n> Hi Yerden,\n> \n> On 09/08/2014 12:33 PM, Yerden Zhumabekov wrote:\n>> 08.09.2014 16:17, Olivier MATZ пишет:\n>>>> --- a/lib/librte_mbuf/rte_mbuf.h\n>>>> +++ b/lib/librte_mbuf/rte_mbuf.h\n>>>> @@ -146,7 +146,7 @@ struct rte_mbuf {\n>>>> \tuint32_t reserved1; /**< Unused field. Required for padding */\n>>>> \n>>>> \t/* remaining bytes are set on RX when pulling packet from descriptor */\n>>>> -\tuint16_t reserved2; /**< Unused field. Required for padding */\n>>>> +\tuint16_t packet_type; /**< Type of packet, e.g. protocols used */\n>>>> \tuint16_t data_len; /**< Amount of data in segment buffer. */\n>>>> \tuint32_t pkt_len; /**< Total pkt len: sum of all segments. */\n>>>> \tuint16_t l3_len:9; /**< L3 (IP) Header Length. */\n>>>> \n>>> This patch adds a new fields that nobody uses. So why should we add it ?\n>> \n>> I would use it :)\n>> It's useful to store the IP protocol number (UDP, TCP etc) and version\n>> of IP (4, 6) and then relay packet to specific handler.\n> \n> I'm not saying this field is useless. But even if it's useful\n> for some applications like yours, it does not mean that it should go in\n> the generic mbuf structure.\n> \n> Also, for a new field, we should define who is in charge of filling it.\n> Is is the driver? Does it mean that all drivers have to be modified to\n> fill it? Or is it just a placeholder for applications? In this case,\n> shouldn't we use application-specific metadata? In the other direction\n> (TX), we would also need to define if this field must be filled by the\n> application before transmitting a mbuf to a driver.\n\n\nFunny, but these new fields (and extended mbuf) were prominent during the dpdk summit.\n\nI think it’s going to be quite useful.", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@dpdk.org", "Delivered-To": "patchwork@dpdk.org", "Received": [ "from [92.243.14.124] (localhost [IPv6:::1])\n\tby dpdk.org (Postfix) with ESMTP id 10E10B372;\n\tTue, 9 Sep 2014 17:00:43 +0200 (CEST)", "from mail-pa0-f47.google.com (mail-pa0-f47.google.com\n\t[209.85.220.47]) by dpdk.org (Postfix) with ESMTP id 004E5B368\n\tfor <dev@dpdk.org>; Tue, 9 Sep 2014 17:00:40 +0200 (CEST)", "by mail-pa0-f47.google.com with SMTP id ey11so7250253pad.6\n\tfor <dev@dpdk.org>; Tue, 09 Sep 2014 08:05:44 -0700 (PDT)", "from [172.20.12.149] ([12.232.194.107])\n\tby mx.google.com with ESMTPSA id\n\tom6sm12026363pdb.89.2014.09.09.08.05.43 for <multiple recipients>\n\t(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);\n\tTue, 09 Sep 2014 08:05:44 -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:content-type:mime-version:subject:from\n\t:in-reply-to:date:cc:content-transfer-encoding:message-id:references\n\t:to; bh=Oxgo6U4lr4ts9KXgWHKNfdRuYexxFOnY288WoB+ragg=;\n\tb=lZhK+yYcyaJohUPOBwmFjRhVInoijJ83819TZHCJf1NAOfJQm5YWmRo5Fk/kJkFHGq\n\tm/lYXZc3QeZUtHZ4FewNGeSdwT6G+78Z1wZAmba92OLMZbv8r6F6aw8duaIQGLu7PNpE\n\tARXdv8ZoScldLmOB3B96d6RLwhMhaEJRCvQzwWRnIQ89ypQCUquNYfIIdxEW5n8dE6M/\n\tH+ef+5nkxGK2OAWajaPjvEs5uOUezmMCA1lM3kch6Y5bV+e1McYgF/0yw+FdN3uedCJu\n\tOcagtI5/a9kUK38el29Kxx5rvWUMN6xDg7wMpFUu2DYvBQt4QrY0N3VM/7ZN1OEwlYux\n\tGERQ==", "X-Gm-Message-State": "ALoCoQlFUodWg+BK8gOH067vt77w8tTQLcNMXrnv6YV9HnRo76+ZlUTr6mmXkn33j0eeWLqT+b43", "X-Received": "by 10.70.131.70 with SMTP id ok6mr3017013pdb.133.1410275144759; \n\tTue, 09 Sep 2014 08:05:44 -0700 (PDT)", "Content-Type": "text/plain; charset=utf-8", "Mime-Version": "1.0 (Mac OS X Mail 8.0 \\(1974.6\\))", "From": "Jim Thompson <jim@netgate.com>", "In-Reply-To": "<540D903E.1060206@6wind.com>", "Date": "Tue, 9 Sep 2014 08:05:43 -0700", "Content-Transfer-Encoding": "quoted-printable", "Message-Id": "<FF410A1A-40E3-4D65-995F-E4B09A0389A5@netgate.com>", "References": "<1409759378-10113-1-git-send-email-bruce.richardson@intel.com>\n\t<1409759378-10113-4-git-send-email-bruce.richardson@intel.com>\n\t<540D8228.809@6wind.com> <540D85E0.4030203@sts.kz>\n\t<540D903E.1060206@6wind.com>", "To": "Olivier MATZ <olivier.matz@6wind.com>", "X-Mailer": "Apple Mail (2.1974.6)", "Cc": "dev@dpdk.org", "Subject": "Re: [dpdk-dev] [PATCH 03/13] mbuf: add packet_type field", "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>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null } ]