Patch Comment List
List patch comments
GET /api/patches/302/comments/?format=api
[ { "id": 656, "web_url": "http://patches.dpdk.org/comment/656/", "msgid": "<5407F3E9.6080907@sts.kz>", "list_archive_url": "https://inbox.dpdk.org/dev/5407F3E9.6080907@sts.kz", "date": "2014-09-04T05:08:57", "subject": "Re: [dpdk-dev] [PATCH 11/13] mbuf: move l2_len and l3_len to second\n\tcache line", "submitter": { "id": 36, "url": "http://patches.dpdk.org/api/people/36/?format=api", "name": "Yerden Zhumabekov", "email": "e_zhumabekov@sts.kz" }, "content": "Hello Bruce,\n\nI'm a little bit concerned about performance issues that would arise if\nthese fields would go to the 2nd cache line.\n\nFor exampe, l2_len and l3_len fields are used by librte_ip_frag to find\nL3 and L4 headers position inside mbuf data. Thus, these values should\nbe calculated by NIC offload, or by user on RX leg.\n\nSecondly, (I wouldn't say on behalf of everyone, but) we use these\nfields in our libraries as well for needs of classification. For\ninstance, in case you try to support other ethertypes which are not\nsupported by NIC offload (MPLS, IPX etc), but you still need to point\nout L3 and L3 headers.\n\nIf my concerns are consistent, what would be possible suggestions?\n\n03.09.2014 21:49, Bruce Richardson ГЇГЁГёГҐГІ:\n> The l2_len and l3_len fields are used for TX offloads and so should be\n> put on the second cache line, along with the other fields only used on\n> TX.\n>\n> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>", "headers": { "Return-Path": "<E_Zhumabekov@sts.kz>", "Received": [ "from mgw.gov.kz (mgw.gov.kz [89.218.88.242])\n\tby dpdk.org (Postfix) with ESMTP id 0E60658EE\n\tfor <dev@dpdk.org>; Thu, 4 Sep 2014 07:05:53 +0200 (CEST)", "from mgw.gov.kz (mx.ctsat.kz [178.89.4.95])\n\tby mgw.gov.kz with ESMTP id s845AVlN020067-s845AVlO020067;\n\tThu, 4 Sep 2014 11:10:31 +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\tThu, 4 Sep 2014 11:09:26 +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\tThu, 4 Sep 2014 11:10:26 +0600" ], "Message-ID": "<5407F3E9.6080907@sts.kz>", "Date": "Thu, 4 Sep 2014 11:08:57 +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": "\"dev@dpdk.org\" <dev@dpdk.org>", "References": "<1409759378-10113-1-git-send-email-bruce.richardson@intel.com>\n\t<1409759378-10113-12-git-send-email-bruce.richardson@intel.com>", "In-Reply-To": "<1409759378-10113-12-git-send-email-bruce.richardson@intel.com>", "X-Enigmail-Version": "1.6", "Content-Type": "text/plain; charset=\"windows-1251\"", "Content-Transfer-Encoding": "8bit", "X-Originating-IP": "[192.168.35.15]", "X-FEAS-SYSTEM-WL": "e_zhumabekov@sts.kz", "Subject": "Re: [dpdk-dev] [PATCH 11/13] mbuf: move l2_len and l3_len to second\n\tcache line", "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, 04 Sep 2014 05:05:54 -0000" }, "addressed": null }, { "id": 658, "web_url": "http://patches.dpdk.org/comment/658/", "msgid": "<20140904102744.GA23231@sivswdev02.ir.intel.com>", "list_archive_url": "https://inbox.dpdk.org/dev/20140904102744.GA23231@sivswdev02.ir.intel.com", "date": "2014-09-04T10:27:45", "subject": "Re: [dpdk-dev] [PATCH 11/13] mbuf: move l2_len and l3_len to second\n\tcache line", "submitter": { "id": 20, "url": "http://patches.dpdk.org/api/people/20/?format=api", "name": "Bruce Richardson", "email": "bruce.richardson@intel.com" }, "content": "On Thu, Sep 04, 2014 at 11:08:57AM +0600, Yerden Zhumabekov wrote:\n> Hello Bruce,\n> \n> I'm a little bit concerned about performance issues that would arise if\n> these fields would go to the 2nd cache line.\n> \n> For exampe, l2_len and l3_len fields are used by librte_ip_frag to find\n> L3 and L4 headers position inside mbuf data. Thus, these values should\n> be calculated by NIC offload, or by user on RX leg.\n> \n> Secondly, (I wouldn't say on behalf of everyone, but) we use these\n> fields in our libraries as well for needs of classification. For\n> instance, in case you try to support other ethertypes which are not\n> supported by NIC offload (MPLS, IPX etc), but you still need to point\n> out L3 and L3 headers.\n> \n> If my concerns are consistent, what would be possible suggestions?\n\nHi Yerden,\n\nI understand your concerns and it's good to have this discussion.\n\nThere are a number of reasons why I've moved these particular fields\nto the second cache line. Firstly, the main reason is that, obviously enough,\nnot all fields will fit in cache line 0, and we need to prioritize what does\nget stored there. The guiding principle behind what fields get moved or not\nthat I've chosen to use for this patch set is to move fields that are not\nused on the receive path (or the fastpath receive path, more specifically -\nso that we can move fields only used by jumbo frames that span mbufs) to the\nsecond cache line. From a search through the existing codebase, there are no\ndrivers which set the l2/l3 length fields on RX, this is only used in\nreassembly libraries/apps and by the drivers on TX.\n\nThe other reason for moving it to the second cache line is that it logically\nbelongs with all the other length fields that we need to add to enable\ntunneling support. [To get an idea of the extra fields that I propose adding\nto the mbuf, please see the RFC patchset I sent out previously as \"[RFC \nPATCH 00/14] Extend the mbuf structure\"]. While we probably can fit the 16-bits\nneeded for l2/l3 length on the mbuf line 0, there is not enough room for all\nthe lengths so we would end up splitting them with other fields in between.\n\nSo, in terms of what do to about this particular issue. I would hope that for\napplications that use these fields the impact should be small and/or possible\nto work around e.g. maybe prefetch second cache line on RX in driver. If not,\nthen I'm happy to see about withdrawing this particular change and seeing if\nwe can keep l2/l3 lengths on cache line zero, with other length fields being\non cache line 1.\n\nQuestion: would you consider the ip fragmentation and reassembly example apps\nin the Intel DPDK releases good examples to test to see the impacts of this\nchange, or is there some other test you would prefer that I look to do? \nCan you perhaps test out the patch sets for the mbuf that I've upstreamed so\nfar and let me know what regressions, if any, you see in your use-case\nscenarios?\n\nRegards,\n/Bruce\n\n> \n> 03.09.2014 21:49, Bruce Richardson ?????:\n> > The l2_len and l3_len fields are used for TX offloads and so should be\n> > put on the second cache line, along with the other fields only used on\n> > TX.\n> >\n> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>\n> \n> -- \n> Sincerely,\n> \n> Yerden Zhumabekov\n> STS, ACI\n> Astana, KZ\n>", "headers": { "Return-Path": "<bruce.richardson@intel.com>", "Received": [ "from mga11.intel.com (mga11.intel.com [192.55.52.93])\n\tby dpdk.org (Postfix) with ESMTP id 845C2231C\n\tfor <dev@dpdk.org>; Thu, 4 Sep 2014 12:23:07 +0200 (CEST)", "from fmsmga003.fm.intel.com ([10.253.24.29])\n\tby fmsmga102.fm.intel.com with ESMTP; 04 Sep 2014 03:27:47 -0700", "from sivswdev02.ir.intel.com ([10.237.217.46])\n\tby FMSMGA003.fm.intel.com with ESMTP; 04 Sep 2014 03:23:04 -0700" ], "X-ExtLoop1": "1", "X-IronPort-AV": "E=Sophos;i=\"4.97,862,1389772800\"; d=\"scan'208\";a=\"381307583\"", "Date": "Thu, 4 Sep 2014 11:27:45 +0100", "From": "Bruce Richardson <bruce.richardson@intel.com>", "To": "Yerden Zhumabekov <e_zhumabekov@sts.kz>", "Message-ID": "<20140904102744.GA23231@sivswdev02.ir.intel.com>", "References": "<1409759378-10113-1-git-send-email-bruce.richardson@intel.com>\n\t<1409759378-10113-12-git-send-email-bruce.richardson@intel.com>\n\t<5407F3E9.6080907@sts.kz>", "MIME-Version": "1.0", "Content-Type": "text/plain; charset=us-ascii", "Content-Disposition": "inline", "In-Reply-To": "<5407F3E9.6080907@sts.kz>", "Organization": "Intel Shannon Limited. Registered in Ireland. Registered\n\tOffice: Collinstown Industrial Park, Leixlip,\n\tCounty Kildare. Registered\n\tNumber: 308263. Business address: Dromore House, East Park, Shannon,\n\tCo. Clare.", "User-Agent": "Mutt/1.5.23 (2014-03-12)", "Cc": "\"dev@dpdk.org\" <dev@dpdk.org>", "Subject": "Re: [dpdk-dev] [PATCH 11/13] mbuf: move l2_len and l3_len to second\n\tcache line", "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, 04 Sep 2014 10:23:08 -0000" }, "addressed": null }, { "id": 659, "web_url": "http://patches.dpdk.org/comment/659/", "msgid": "<5408463C.8040805@sts.kz>", "list_archive_url": "https://inbox.dpdk.org/dev/5408463C.8040805@sts.kz", "date": "2014-09-04T11:00:12", "subject": "Re: [dpdk-dev] [PATCH 11/13] mbuf: move l2_len and l3_len to second\n\tcache line", "submitter": { "id": 36, "url": "http://patches.dpdk.org/api/people/36/?format=api", "name": "Yerden Zhumabekov", "email": "e_zhumabekov@sts.kz" }, "content": "I get your point. I've also read throught the code of various PMDs and\nhave found no indication of setting l2_len/l3_len fields as well.\n\nAs for testing, we'd be happy to test the patchset but we are now in\nprocess of building our testing facilities so we are not ready to\nprovide enough workload for the hardware/software. I was also wondering\nif anyone has run some test and can provide some numbers on that matter.\n\nPersonally, I don't think frag/reassemly app is a perfect example for\nevaluating 2nd cache line performance penalty. The offsets to L3 and L4\nheaders need to be calculated for all TCP/IP traffic and fragmented\ntraffic is not representative in this case. Maybe it would be better to\nwrite an app which calculates these offsets for different set of mbufs\nand provides some stats. For example, l2fwd/l3fwd + additional l2_len\nand l3_len calculation.\n\nAnd I'm also figuring out how to rewrite our app/libs (prefetch etc) to\nreflect the future changes in mbuf, hence my concerns :)\n\n\n04.09.2014 16:27, Bruce Richardson пиÑеÑ:\n> Hi Yerden,\n>\n> I understand your concerns and it's good to have this discussion.\n>\n> There are a number of reasons why I've moved these particular fields\n> to the second cache line. Firstly, the main reason is that, obviously enough,\n> not all fields will fit in cache line 0, and we need to prioritize what does\n> get stored there. The guiding principle behind what fields get moved or not\n> that I've chosen to use for this patch set is to move fields that are not\n> used on the receive path (or the fastpath receive path, more specifically -\n> so that we can move fields only used by jumbo frames that span mbufs) to the\n> second cache line. From a search through the existing codebase, there are no\n> drivers which set the l2/l3 length fields on RX, this is only used in\n> reassembly libraries/apps and by the drivers on TX.\n>\n> The other reason for moving it to the second cache line is that it logically\n> belongs with all the other length fields that we need to add to enable\n> tunneling support. [To get an idea of the extra fields that I propose adding\n> to the mbuf, please see the RFC patchset I sent out previously as \"[RFC \n> PATCH 00/14] Extend the mbuf structure\"]. While we probably can fit the 16-bits\n> needed for l2/l3 length on the mbuf line 0, there is not enough room for all\n> the lengths so we would end up splitting them with other fields in between.\n>\n> So, in terms of what do to about this particular issue. I would hope that for\n> applications that use these fields the impact should be small and/or possible\n> to work around e.g. maybe prefetch second cache line on RX in driver. If not,\n> then I'm happy to see about withdrawing this particular change and seeing if\n> we can keep l2/l3 lengths on cache line zero, with other length fields being\n> on cache line 1.\n>\n> Question: would you consider the ip fragmentation and reassembly example apps\n> in the Intel DPDK releases good examples to test to see the impacts of this\n> change, or is there some other test you would prefer that I look to do? \n> Can you perhaps test out the patch sets for the mbuf that I've upstreamed so\n> far and let me know what regressions, if any, you see in your use-case\n> scenarios?\n>\n> Regards,\n> /Bruce\n>", "headers": { "Return-Path": "<E_Zhumabekov@sts.kz>", "Received": [ "from mgw.gov.kz (mgw.gov.kz [89.218.88.242])\n\tby dpdk.org (Postfix) with ESMTP id B476958DF\n\tfor <dev@dpdk.org>; Thu, 4 Sep 2014 12:57:03 +0200 (CEST)", "from mgw.gov.kz (mx.ctsat.kz [178.89.4.95])\n\tby mgw.gov.kz with ESMTP id s84B1h9u001709-s84B1h9v001709;\n\tThu, 4 Sep 2014 17:01:43 +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\tThu, 4 Sep 2014 17:00:38 +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\tThu, 4 Sep 2014 17:01:41 +0600" ], "Message-ID": "<5408463C.8040805@sts.kz>", "Date": "Thu, 4 Sep 2014 17:00:12 +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": "Bruce Richardson <bruce.richardson@intel.com>", "References": "<1409759378-10113-1-git-send-email-bruce.richardson@intel.com>\n\t<1409759378-10113-12-git-send-email-bruce.richardson@intel.com>\n\t<5407F3E9.6080907@sts.kz>\n\t<20140904102744.GA23231@sivswdev02.ir.intel.com>", "In-Reply-To": "<20140904102744.GA23231@sivswdev02.ir.intel.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", "Cc": "\"dev@dpdk.org\" <dev@dpdk.org>", "Subject": "Re: [dpdk-dev] [PATCH 11/13] mbuf: move l2_len and l3_len to second\n\tcache line", "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, 04 Sep 2014 10:57:04 -0000" }, "addressed": null }, { "id": 660, "web_url": "http://patches.dpdk.org/comment/660/", "msgid": "<20140904115549.GA13208@sivswdev02.ir.intel.com>", "list_archive_url": "https://inbox.dpdk.org/dev/20140904115549.GA13208@sivswdev02.ir.intel.com", "date": "2014-09-04T11:55:49", "subject": "Re: [dpdk-dev] [PATCH 11/13] mbuf: move l2_len and l3_len to second\n\tcache line", "submitter": { "id": 20, "url": "http://patches.dpdk.org/api/people/20/?format=api", "name": "Bruce Richardson", "email": "bruce.richardson@intel.com" }, "content": "On Thu, Sep 04, 2014 at 05:00:12PM +0600, Yerden Zhumabekov wrote:\n> I get your point. I've also read throught the code of various PMDs and\n> have found no indication of setting l2_len/l3_len fields as well.\n> \n> As for testing, we'd be happy to test the patchset but we are now in\n> process of building our testing facilities so we are not ready to\n> provide enough workload for the hardware/software. I was also wondering\n> if anyone has run some test and can provide some numbers on that matter.\n> \n> Personally, I don't think frag/reassemly app is a perfect example for\n> evaluating 2nd cache line performance penalty. The offsets to L3 and L4\n> headers need to be calculated for all TCP/IP traffic and fragmented\n> traffic is not representative in this case. Maybe it would be better to\n> write an app which calculates these offsets for different set of mbufs\n> and provides some stats. For example, l2fwd/l3fwd + additional l2_len\n> and l3_len calculation.\n> \n> And I'm also figuring out how to rewrite our app/libs (prefetch etc) to\n> reflect the future changes in mbuf, hence my concerns :)\n>\nJust a final point on this. Note that the second cache line is always being\nread by the TX leg of the code to free back mbufs to their mbuf pool post-\ntransmit. The overall fast-path RX+TX benchmarks show no performance\ndegradation due to that access.\n\nFor sample apps, you make a good point indeed about the existing app not being\nvery useful as they work on larger packets. I'll see what I can throw together\nhere to make a more realistic test.\n\n/Bruce\n \n> \n> 04.09.2014 16:27, Bruce Richardson ??????????:\n> > Hi Yerden,\n> >\n> > I understand your concerns and it's good to have this discussion.\n> >\n> > There are a number of reasons why I've moved these particular fields\n> > to the second cache line. Firstly, the main reason is that, obviously enough,\n> > not all fields will fit in cache line 0, and we need to prioritize what does\n> > get stored there. The guiding principle behind what fields get moved or not\n> > that I've chosen to use for this patch set is to move fields that are not\n> > used on the receive path (or the fastpath receive path, more specifically -\n> > so that we can move fields only used by jumbo frames that span mbufs) to the\n> > second cache line. From a search through the existing codebase, there are no\n> > drivers which set the l2/l3 length fields on RX, this is only used in\n> > reassembly libraries/apps and by the drivers on TX.\n> >\n> > The other reason for moving it to the second cache line is that it logically\n> > belongs with all the other length fields that we need to add to enable\n> > tunneling support. [To get an idea of the extra fields that I propose adding\n> > to the mbuf, please see the RFC patchset I sent out previously as \"[RFC \n> > PATCH 00/14] Extend the mbuf structure\"]. While we probably can fit the 16-bits\n> > needed for l2/l3 length on the mbuf line 0, there is not enough room for all\n> > the lengths so we would end up splitting them with other fields in between.\n> >\n> > So, in terms of what do to about this particular issue. I would hope that for\n> > applications that use these fields the impact should be small and/or possible\n> > to work around e.g. maybe prefetch second cache line on RX in driver. If not,\n> > then I'm happy to see about withdrawing this particular change and seeing if\n> > we can keep l2/l3 lengths on cache line zero, with other length fields being\n> > on cache line 1.\n> >\n> > Question: would you consider the ip fragmentation and reassembly example apps\n> > in the Intel DPDK releases good examples to test to see the impacts of this\n> > change, or is there some other test you would prefer that I look to do? \n> > Can you perhaps test out the patch sets for the mbuf that I've upstreamed so\n> > far and let me know what regressions, if any, you see in your use-case\n> > scenarios?\n> >\n> > Regards,\n> > /Bruce\n> >\n> -- \n> Sincerely,\n> \n> Yerden Zhumabekov\n> STS, ACI\n> Astana, KZ\n>", "headers": { "Return-Path": "<bruce.richardson@intel.com>", "Received": [ "from mga09.intel.com (mga09.intel.com [134.134.136.24])\n\tby dpdk.org (Postfix) with ESMTP id CACE158DF\n\tfor <dev@dpdk.org>; Thu, 4 Sep 2014 13:51:11 +0200 (CEST)", "from azsmga001.ch.intel.com ([10.2.17.19])\n\tby orsmga102.jf.intel.com with ESMTP; 04 Sep 2014 04:49:48 -0700", "from sivswdev02.ir.intel.com ([10.237.217.46])\n\tby azsmga001.ch.intel.com with ESMTP; 04 Sep 2014 04:55:49 -0700" ], "X-ExtLoop1": "1", "X-IronPort-AV": "E=Sophos;i=\"5.04,465,1406617200\"; d=\"scan'208\";a=\"475161994\"", "Date": "Thu, 4 Sep 2014 12:55:49 +0100", "From": "Bruce Richardson <bruce.richardson@intel.com>", "To": "Yerden Zhumabekov <e_zhumabekov@sts.kz>", "Message-ID": "<20140904115549.GA13208@sivswdev02.ir.intel.com>", "References": "<1409759378-10113-1-git-send-email-bruce.richardson@intel.com>\n\t<1409759378-10113-12-git-send-email-bruce.richardson@intel.com>\n\t<5407F3E9.6080907@sts.kz>\n\t<20140904102744.GA23231@sivswdev02.ir.intel.com>\n\t<5408463C.8040805@sts.kz>", "MIME-Version": "1.0", "Content-Type": "text/plain; charset=us-ascii", "Content-Disposition": "inline", "In-Reply-To": "<5408463C.8040805@sts.kz>", "Organization": "Intel Shannon Limited. Registered in Ireland. Registered\n\tOffice: Collinstown Industrial Park, Leixlip,\n\tCounty Kildare. Registered\n\tNumber: 308263. Business address: Dromore House, East Park, Shannon,\n\tCo. Clare.", "User-Agent": "Mutt/1.5.23 (2014-03-12)", "Cc": "\"dev@dpdk.org\" <dev@dpdk.org>", "Subject": "Re: [dpdk-dev] [PATCH 11/13] mbuf: move l2_len and l3_len to second\n\tcache line", "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, 04 Sep 2014 11:51:12 -0000" }, "addressed": null } ]