List comments

GET /api/patches/134/comments/
Content-Type: application/json
Vary: Accept

        "id": 355,
        "web_url": "",
        "msgid": "<>",
        "date": "2014-08-12T14:18:31",
        "subject": "Re: [dpdk-dev] [RFC PATCH 13/14] mbuf: cleanup + added in\n\tadditional mbuf fields.",
        "submitter": {
            "id": 8,
            "url": "",
            "name": "Olivier Matz",
            "email": ""
        "content": "Hi Bruce,\n\nOn 08/11/2014 10:44 PM, Bruce Richardson wrote:\n> Cleanups:\n> * use typedefs for markers within mbuf struct\n> * split up vlan_macip field as the l2/l3 lengths are for TX so go on the\n>    second cache line.\n> * created a tx_ol field in second cache line for data used for tx\n>    offloads\n> * rename the hash field to the filter field as it contains more than\n>    just a hash value.\n>\n> Added in the extra mbuf fields needed:\n> * fdir flex bytes for i40e driver, i.e. extra 32-bits for filters\n> * field to be used for a sequence number, extra 32-bit field\n> * field for a second vlan tag, extra 16-bits, using space freed by\n>    moving out the l2 l3 lengths.\n> * userdata field for general application use.\n> * added inner_l3 and l4 length fields to allow tunneling.\n>\n> Signed-off-by: Bruce Richardson <>\n\nI think it would be clearer if splitted in several patches. First\n2 patches for:\n\n- rename hash in filter\n- rename vlan_macip in rte_tx_offloads (and change to 64 bits ?)\n\nBy the way, the modification of ol_flags in 64 bits probably\nrequires more modifications in driver and testpmd. See me initial\npatch \"mbuf: change ol_flags to 32 bits\".\n\nWhy not directly adding the MARKER typedef in previous patches?\nAlso, I'm wondering if the markers really need to by typed. An empty\nstruct would do the job, just requiring the users to cast it into\nthe proper type.\n\nAbout sequence, double vlan id, userdata: they are not used now.\nI think we should add them one by one in separate patches, with\ncode really that really requires the added field to be present.\nBy the way, there is already a way to reserve a zone in mbuf for\nthe application at mbuf pool creation. What is the purpose of\nthe userdata field?\n\nAbout fdir_i40e field, I'm not sure that we should have\ndriver-specific info in the generic mbuf structure. In addition,\nthe application would need to know which hash type is present\nin the mbuf.\n\nEach time we add a new field in the mbuf, I think we should ask\nourselves how the application will use it, especially if the\napplication manages several kind of ports (virtual and\nphysical for instance), which may not support all features.\nFor instance, who will fill the \"sequence\" field ? Is it the\ndriver? If it's application-specific\n\nRegards,\nOlivier",
        "headers": {
            "List-Subscribe": "<>,\n\t<>",
            "Content-Transfer-Encoding": "7bit",
            "X-Google-DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n\; 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=UA7mbRLC292o9U1z/5JPRnWXtYlnPM4MEr8wj35RArI=;\n\tb=VdiwNcru4MazFyYv2PBYpHlKZLfshArAFuw9gYOr37VerSpflu80chg829Mo1NVNv0\n\tMX/GJy0GQLVRxoS0vPyhsNaenBdwYLoxjM7SzMFMkyQy9puhO3mjEKrB4ZlQ1PYhuZP9\n\tNfJlGwOWU+xcVAJmi06QDxeG94WzNzgBIUmwQqhUJXELIVdJJc62mkzHrW+pe//1XkXr\n\the3LsIVswcptLQqUlfw3LdGpE6CSqziLNsv1TZ/+ZxwwWOqzwgev4ybq6zUrBwHgmVPN\n\t4Zf6aCAWY+B7PWB1tr2zn5sEWFM8U+Y6Nem6f8fyPHBQPh0naYWiTu0VPP1gD+kSmMVZ\n\t5pBQ==",
            "List-Help": "<>",
            "Date": "Tue, 12 Aug 2014 16:18:31 +0200",
            "Precedence": "list",
            "X-BeenThere": "",
            "References": "<>\n\t<>",
            "In-Reply-To": "<>",
            "X-Gm-Message-State": "ALoCoQkp1Hy4jPFnAuC1pQF8qVobEet70s31du+aoNZIP2UfDGvhc6qAJxuel1CMLDhIiLVyCF8i",
            "Content-Type": "text/plain; charset=ISO-8859-1; format=flowed",
            "To": "Bruce Richardson <>,",
            "User-Agent": "Mozilla/5.0 (X11; Linux x86_64;\n\trv:24.0) Gecko/20100101 Icedove/24.5.0",
            "MIME-Version": "1.0",
            "Received": [
                "from (\n\t[]) by (Postfix) with ESMTP id C386DB3B7\n\tfor <>; Tue, 12 Aug 2014 16:15:37 +0200 (CEST)",
                "by with SMTP id w62so10083267wes.15\n\tfor <>; Tue, 12 Aug 2014 07:18:33 -0700 (PDT)",
                "from [] (\n\t[]) by with ESMTPSA id\n\tga2sm9535973wjb.44.2014. for <multiple recipients>\n\t(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);\n\tTue, 12 Aug 2014 07:18:32 -0700 (PDT)"
            "From": "Olivier MATZ <>",
            "Message-ID": "<>",
            "List-Id": "patches and discussions about DPDK <>",
            "Subject": "Re: [dpdk-dev] [RFC PATCH 13/14] mbuf: cleanup + added in\n\tadditional mbuf fields.",
            "List-Archive": "<>",
            "X-List-Received-Date": "Tue, 12 Aug 2014 14:15:37 -0000",
            "List-Unsubscribe": "<>,\n\t<>",
            "Return-Path": "<>",
            "List-Post": "<>",
            "X-Received": "by with SMTP id kw1mr5577246wjb.82.1407853113442; \n\tTue, 12 Aug 2014 07:18:33 -0700 (PDT)",
            "X-Mailman-Version": "2.1.15"