get:
Show a patch.

patch:
Update a patch.

put:
Update a patch.

GET /api/patches/1147/?format=api
HTTP 200 OK
Allow: GET, PUT, PATCH, HEAD, OPTIONS
Content-Type: application/json
Vary: Accept

{
    "id": 1147,
    "url": "https://patches.dpdk.org/api/patches/1147/?format=api",
    "web_url": "https://patches.dpdk.org/project/dpdk/patch/C6ECDF3AB251BE4894318F4E4512369780C071C8@IRSMSX109.ger.corp.intel.com/",
    "project": {
        "id": 1,
        "url": "https://patches.dpdk.org/api/projects/1/?format=api",
        "name": "DPDK",
        "link_name": "dpdk",
        "list_id": "dev.dpdk.org",
        "list_email": "dev@dpdk.org",
        "web_url": "http://core.dpdk.org",
        "scm_url": "git://dpdk.org/dpdk",
        "webscm_url": "http://git.dpdk.org/dpdk",
        "list_archive_url": "https://inbox.dpdk.org/dev",
        "list_archive_url_format": "https://inbox.dpdk.org/dev/{}",
        "commit_url_format": ""
    },
    "msgid": "<C6ECDF3AB251BE4894318F4E4512369780C071C8@IRSMSX109.ger.corp.intel.com>",
    "list_archive_url": "https://inbox.dpdk.org/dev/C6ECDF3AB251BE4894318F4E4512369780C071C8@IRSMSX109.ger.corp.intel.com",
    "date": "2014-11-05T16:19:07",
    "name": "[dpdk-dev] 答复:答复: [PATCH] eal: map uio resources after hugepages when the base_virtaddr is configured.",
    "commit_ref": null,
    "pull_url": null,
    "state": "not-applicable",
    "archived": true,
    "hash": "05005f0ee1303594ed47cc15f82a406343ec7fb2",
    "submitter": {
        "id": 4,
        "url": "https://patches.dpdk.org/api/people/4/?format=api",
        "name": "Burakov, Anatoly",
        "email": "anatoly.burakov@intel.com"
    },
    "delegate": null,
    "mbox": "https://patches.dpdk.org/project/dpdk/patch/C6ECDF3AB251BE4894318F4E4512369780C071C8@IRSMSX109.ger.corp.intel.com/mbox/",
    "series": [],
    "comments": "https://patches.dpdk.org/api/patches/1147/comments/",
    "check": "pending",
    "checks": "https://patches.dpdk.org/api/patches/1147/checks/",
    "tags": {},
    "related": [],
    "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 BAEBE7F2C;\n\tWed,  5 Nov 2014 17:12:50 +0100 (CET)",
            "from mga11.intel.com (mga11.intel.com [192.55.52.93])\n\tby dpdk.org (Postfix) with ESMTP id 4B7BF7F29\n\tfor <dev@dpdk.org>; Wed,  5 Nov 2014 17:12:46 +0100 (CET)",
            "from fmsmga001.fm.intel.com ([10.253.24.23])\n\tby fmsmga102.fm.intel.com with ESMTP; 05 Nov 2014 08:21:43 -0800",
            "from irsmsx102.ger.corp.intel.com ([163.33.3.155])\n\tby fmsmga001.fm.intel.com with ESMTP; 05 Nov 2014 08:19:11 -0800",
            "from irsmsx155.ger.corp.intel.com (163.33.192.3) by\n\tIRSMSX102.ger.corp.intel.com (163.33.3.155) with Microsoft SMTP\n\tServer (TLS) id 14.3.195.1; Wed, 5 Nov 2014 16:19:08 +0000",
            "from irsmsx109.ger.corp.intel.com ([169.254.13.101]) by\n\tIRSMSX155.ger.corp.intel.com ([169.254.14.70]) with mapi id\n\t14.03.0195.001; Wed, 5 Nov 2014 16:19:07 +0000"
        ],
        "X-ExtLoop1": "1",
        "X-IronPort-AV": "E=Sophos;i=\"5.07,320,1413270000\"; \n\td=\"scan'208,217\";a=\"617637666\"",
        "From": "\"Burakov, Anatoly\" <anatoly.burakov@intel.com>",
        "To": "XU Liang <liang.xu@cinfotech.cn>, \"dev@dpdk.org\" <dev@dpdk.org>",
        "Thread-Topic": "=?utf-8?B?562U5aSN77ya562U5aSN77yaW2RwZGstZGV2XSBbUEFUQ0hdIGVhbDogbWFw?=\n\t=?utf-8?B?IHVpbyByZXNvdXJjZXMgYWZ0ZXIgaHVnZXBhZ2VzIHdoZW4gdGhlCWJhc2Vf?=\n\t=?utf-8?Q?virtaddr_is_configured.?=",
        "Thread-Index": "AQHP+PwmmmVWcq3WK0uPxBQDYbZnPZxSLpdIgAAGJuCAAABnkA==",
        "Date": "Wed, 5 Nov 2014 16:19:07 +0000",
        "Message-ID": "<C6ECDF3AB251BE4894318F4E4512369780C071C8@IRSMSX109.ger.corp.intel.com>",
        "References": "<1415193919-17361-1-git-send-email-liang.xu@cinfotech.cn>,\n\tC6ECDF3AB251BE4894318F4E4512369780C070FA@IRSMSX109.ger.corp.intel.com\n\t<01d6ff37-3473-43af-aff3-1183d4c4768a@cinfotech.cn>,\n\tC6ECDF3AB251BE4894318F4E4512369780C07183@IRSMSX109.ger.corp.intel.com\n\t<7600981e-fc3a-454b-a269-51dd3b9d535b@cinfotech.cn>",
        "In-Reply-To": "<7600981e-fc3a-454b-a269-51dd3b9d535b@cinfotech.cn>",
        "Accept-Language": "en-US",
        "Content-Language": "en-US",
        "X-MS-Has-Attach": "",
        "X-MS-TNEF-Correlator": "",
        "x-originating-ip": "[163.33.239.182]",
        "MIME-Version": "1.0",
        "Content-Type": "text/plain; charset=\"utf-8\"",
        "Content-Transfer-Encoding": "base64",
        "X-Content-Filtered-By": "Mailman/MimeDel 2.1.15",
        "Subject": "Re: [dpdk-dev]\n\t=?utf-8?b?562U5aSN77ya562U5aSN77yaIFtQQVRDSF0gZWFsOiBt?=\n\t=?utf-8?q?ap_uio_resources_after_hugepages_when_the=09base=5Fvirtaddr_is_?=\n\t=?utf-8?q?configured=2E?=",
        "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>"
    },
    "content": "Ah, that makes sense. So you’re actually hitting the very issue I’m concerned about when mapping purely with base-virtaddr (a library is mapped into where you’re trying to map your UIO resources).\r\n\r\nWell, as I said, you can try and walk the memsegs and work out the biggest end-address of hugepage memory. That’s the easiest way I can think of.\r\n\r\nThanks,\r\nAnatoly\r\n\r\nFrom: XU Liang [mailto:liang.xu@cinfotech.cn]\r\nSent: Wednesday, November 5, 2014 4:10 PM\r\nTo: Burakov, Anatoly; dev@dpdk.org\r\nSubject: 答复:答复:[dpdk-dev] [PATCH] eal: map uio resources after hugepages when the base_virtaddr is configured.\r\n\r\nI have a multiple processes application. When start a secondary process, we got error message \"EAL: pci_map_resource(): cannot mmap(11, 0x7ffff7fba000, 0x20000, 0x0): Bad file descriptor (0x7ffff7fb9000)\".\r\n\r\nThe secondary process link difference shared libraries, so the address 0x7ffff7fba000 is used.\r\n\r\n------------------------------------------------------------------\r\n发件人:Burakov, Anatoly <anatoly.burakov@intel.com<mailto:anatoly.burakov@intel.com>>\r\n发送时间:2014年11月5日(星期三) 23:59\r\n收件人:徐亮 <liang.xu@cinfotech.cn<mailto:liang.xu@cinfotech.cn>>,dev@dpdk.org<mailto:dev@dpdk.org> <dev@dpdk.org<mailto:dev@dpdk.org>>\r\n主 题:RE: 答复:[dpdk-dev] [PATCH] eal: map uio resources after hugepages when the base_virtaddr is configured.\r\n\r\nHi Liang\r\n\r\nYes it is a problem. Even if it was carefully selected by user, nothing stops the DPDK application from mapping something into where you’re trying to map your UIO devices. Plus, this changes the default behavior where a wrong base-virtaddr leads to a failure to initialize, rather than simply using a different address (remember that pci_map_resource fails if it cannot map the resource at the exact address you requested).\r\n\r\nA very crude way of finding out where hugepages end would be to walk the hugepage memory (walk through memsegs and note the maximum start addr + length of that memseg).\r\n\r\nCould you perhaps explain what is the problem that you’re trying to solve with this? I can’t think of a situation where the location of UIO maps would matter, to be honest.\r\n\r\nThanks,\r\nAnatoly\r\n\r\nFrom: XU Liang [mailto:liang.xu@cinfotech.cn]\r\nSent: Wednesday, November 5, 2014 3:49 PM\r\nTo: Burakov, Anatoly; dev@dpdk.org<mailto:dev@dpdk.org>\r\nSubject: 答复:[dpdk-dev] [PATCH] eal: map uio resources after hugepages when the base_virtaddr is configured.\r\n\r\nI think the base_virtadd will be carefully selected by user when they need it. So maybe it's not a real problem.  :>\r\n\r\nThe real reason is I can't find a easy way to get the end address of hugepages. Can you give me some suggestions ?\r\n------------------------------------------------------------------\r\n发件人:Burakov, Anatoly <anatoly.burakov@intel.com<mailto:anatoly.burakov@intel.com>>\r\n发送时间:2014年11月5日(星期三) 23:10\r\n收件人:徐亮 <liang.xu@cinfotech.cn<mailto:liang.xu@cinfotech.cn>>,dev@dpdk.org<mailto:dev@dpdk.org> <dev@dpdk.org<mailto:dev@dpdk.org>>\r\n主 题:RE: [dpdk-dev] [PATCH] eal: map uio resources after hugepages when the base_virtaddr is configured.\r\n\r\nI have a slight problems with this patch.\r\n\r\nThe base_virtaddr doesn't necessarily correspond to an address that everything gets mapped to. It's a \"hint\" of sorts, that may or may not be taken into account by mmap. Therefore we can't simply assume that if we requested a base-virtaddr, everything will get mapped at exactly that address. We also can't assume that hugepages will be ordered one after the other and occupy neatly all the contiguous virtual memory between base_virtaddr and base_virtaddr + internal_config.memory - there may be holes, for whatever reasons.\r\n\r\nAlso,\r\n\r\nThanks,\r\nAnatoly\r\n\r\n-----Original Message-----\r\nFrom: dev [mailto:dev-bounces@dpdk.org] On Behalf Of lxu\r\nSent: Wednesday, November 5, 2014 1:25 PM\r\nTo: dev@dpdk.org<mailto:dev@dpdk.org>\r\nSubject: [dpdk-dev] [PATCH] eal: map uio resources after hugepages when the base_virtaddr is configured.\r\n\r\n---\r\nlib/librte_eal/linuxapp/eal/eal_pci_uio.c | 9 ++++++++-\r\n1 file changed, 8 insertions(+), 1 deletion(-)\r\n\r\nif (maps[j].addr != NULL)\r\nfail = 1;\r\nelse {\r\n- mapaddr = pci_map_resource(NULL, fd, (off_t)offset,\r\n+ mapaddr = pci_map_resource(requested_addr, fd, (off_t)offset,\r\n(size_t)maps[j].size);\r\nif (mapaddr == NULL)\r\nfail = 1;\r\n+ else if (NULL != requested_addr)\r\n+ requested_addr = (uint8_t *)mapaddr + maps[j].size;\r\n}\r\n\r\nif (fail) {\r\n--\r\n1.9.1",
    "diff": "diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c\r\nindex 7e62266..bc7ed3a 100644\r\n--- a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c\r\n+++ b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c\r\n@@ -289,6 +289,11 @@ pci_uio_map_resource(struct rte_pci_device *dev)\r\nstruct rte_pci_addr *loc = &dev->addr;\r\nstruct mapped_pci_resource *uio_res;\r\nstruct pci_map *maps;\r\n+ static void * requested_addr = NULL;\r\n+ if (internal_config.base_virtaddr && NULL == requested_addr) {\r\n+ requested_addr = (uint8_t *) internal_config.base_virtaddr\r\n+ + internal_config.memory;\r\n+ }\r\n\r\ndev->intr_handle.fd = -1;\r\ndev->intr_handle.type = RTE_INTR_HANDLE_UNKNOWN; @@ -371,10 +376,12 @@ pci_uio_map_resource(struct rte_pci_device *dev)\r\n",
    "prefixes": [
        "dpdk-dev"
    ]
}