get:
Show a patch.

patch:
Update a patch.

put:
Update a patch.

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

{
    "id": 113016,
    "url": "https://patches.dpdk.org/api/patches/113016/?format=api",
    "web_url": "https://patches.dpdk.org/project/dpdk/patch/1655491040-183649-1-git-send-email-nicolas.chautru@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": "<1655491040-183649-1-git-send-email-nicolas.chautru@intel.com>",
    "list_archive_url": "https://inbox.dpdk.org/dev/1655491040-183649-1-git-send-email-nicolas.chautru@intel.com",
    "date": "2022-06-17T18:37:15",
    "name": "[v2,0/5] bbdev changes for 22.11",
    "commit_ref": null,
    "pull_url": null,
    "state": null,
    "archived": false,
    "hash": null,
    "submitter": {
        "id": 1314,
        "url": "https://patches.dpdk.org/api/people/1314/?format=api",
        "name": "Chautru, Nicolas",
        "email": "nicolas.chautru@intel.com"
    },
    "delegate": null,
    "mbox": "https://patches.dpdk.org/project/dpdk/patch/1655491040-183649-1-git-send-email-nicolas.chautru@intel.com/mbox/",
    "series": [],
    "comments": "https://patches.dpdk.org/api/patches/113016/comments/",
    "check": "pending",
    "checks": "https://patches.dpdk.org/api/patches/113016/checks/",
    "tags": {},
    "related": [],
    "headers": {
        "Return-Path": "<dev-bounces@dpdk.org>",
        "X-Original-To": "patchwork@inbox.dpdk.org",
        "Delivered-To": "patchwork@inbox.dpdk.org",
        "Received": [
            "from mails.dpdk.org (mails.dpdk.org [217.70.189.124])\n\tby inbox.dpdk.org (Postfix) with ESMTP id 89ADCA0032;\n\tFri, 17 Jun 2022 20:49:11 +0200 (CEST)",
            "from [217.70.189.124] (localhost [127.0.0.1])\n\tby mails.dpdk.org (Postfix) with ESMTP id 2F3FD410E7;\n\tFri, 17 Jun 2022 20:49:11 +0200 (CEST)",
            "from mga04.intel.com (mga04.intel.com [192.55.52.120])\n by mails.dpdk.org (Postfix) with ESMTP id A5FBB40E2D\n for <dev@dpdk.org>; Fri, 17 Jun 2022 20:49:09 +0200 (CEST)",
            "from orsmga006.jf.intel.com ([10.7.209.51])\n by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 17 Jun 2022 11:49:08 -0700",
            "from skx-5gnr-sc12-4.sc.intel.com ([172.25.69.210])\n by orsmga006.jf.intel.com with ESMTP; 17 Jun 2022 11:49:08 -0700"
        ],
        "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/simple;\n d=intel.com; i=@intel.com; q=dns/txt; s=Intel;\n t=1655491749; x=1687027749;\n h=from:to:cc:subject:date:message-id:in-reply-to: references;\n bh=roCGLvrUtXiEFQOOls6OQdlh+/EtPDEAdwTZ2QQo5E4=;\n b=euBdYWqZYCPHgaZQpD43BOS/7TvAIAYavIzaAmPlW0KCOj7ggapfE1Sn\n rW/lRcghBOaaNO63Vr1TUIgC+I/s8t9au6TsiZ7cHM+wUtDrtL6zdJoEP\n Z4f/ocezU9dEghWTMmtZGC2xUxEt8R/r4iHccU0/bq4PFPxidWx/pFI/s\n y5P+RCV9fkY2KHJy+UumXvAls24XzvFq4WVkkrKPk0+2K5JHgSub3wTA5\n 4OkvdrMBefspW9LeZPK0KlW3CCn5UH6YUI6IdrsJEpWcY7d4IgQXgJ9QQ\n /VvSZOCFx5YloEidTRhnmBLKCvQbc1airUbUUsr/XNVasuv44w4S7nnjE A==;",
        "X-IronPort-AV": [
            "E=McAfee;i=\"6400,9594,10380\"; a=\"278333234\"",
            "E=Sophos;i=\"5.92,306,1650956400\"; d=\"scan'208\";a=\"278333234\"",
            "E=Sophos;i=\"5.92,306,1650956400\"; d=\"scan'208\";a=\"560636020\""
        ],
        "X-ExtLoop1": "1",
        "From": "Nicolas Chautru <nicolas.chautru@intel.com>",
        "To": "dev@dpdk.org, thomas@monjalon.net, gakhil@marvell.com,\n hemant.agrawal@nxp.com",
        "Cc": "maxime.coquelin@redhat.com, trix@redhat.com, mdr@ashroe.eu,\n bruce.richardson@intel.com, david.marchand@redhat.com,\n stephen@networkplumber.org, Nicolas Chautru <nicolas.chautru@intel.com>",
        "Subject": "[PATCH v2 0/5] bbdev changes for 22.11",
        "Date": "Fri, 17 Jun 2022 11:37:15 -0700",
        "Message-Id": "<1655491040-183649-1-git-send-email-nicolas.chautru@intel.com>",
        "X-Mailer": "git-send-email 1.8.3.1",
        "In-Reply-To": "<1646785355-168133-3-git-send-email-nicolas.chautru@intel.com>",
        "References": "<1646785355-168133-3-git-send-email-nicolas.chautru@intel.com>",
        "X-BeenThere": "dev@dpdk.org",
        "X-Mailman-Version": "2.1.29",
        "Precedence": "list",
        "List-Id": "DPDK patches and discussions <dev.dpdk.org>",
        "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n <mailto:dev-request@dpdk.org?subject=unsubscribe>",
        "List-Archive": "<http://mails.dpdk.org/archives/dev/>",
        "List-Post": "<mailto:dev@dpdk.org>",
        "List-Help": "<mailto:dev-request@dpdk.org?subject=help>",
        "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n <mailto:dev-request@dpdk.org?subject=subscribe>",
        "Errors-To": "dev-bounces@dpdk.org"
    },
    "content": "Hi,\n\nAgregating together in a single serie a number of bbdev api changes previously submitted over the last few months and all targeted for 22.11 (4 different series detailed below). Related deprecation notice being pushed in 22.07 in parallel. \n* bbdev: add device status info\n* bbdev: add new operation for FFT processing\n* bbdev: add device info on queue topology\n* bbdev: allow operation type enum for growth\n\nv2: Update to the RTE_BBDEV_COUNT removal based on feedback from Thomas/Stephen : rejecting out of range op type and adjusting the new name for the padded maximum value used for fixed size arrays. \n\n---\n\nPrevious cover letters agregated below:\n\n* bbdev: add device status info\nhttps://patches.dpdk.org/project/dpdk/list/?series=23367\n\nThe updated structure will allow PMDs to expose through info_get what be may the status of the underlying accelerator, notably in case an HW error event having happened.\n\n* bbdev: add new operation for FFT processing\nhttps://patches.dpdk.org/project/dpdk/list/?series=22111\n\nThis contribution adds a new operation type to the existing ones already supported by the bbdev PMDs.\nThis set of operation is FFT-based processing for 5GNR baseband processing acceleration. This operates in the same lookaside fashion as other existing bbdev operation with a dedicated set of capabilities and parameters (marked as experimental).\n\nI plan to also include a new PMD supporting this operation (and most of the related capabilities) in the next couple of months (either in 22.06 or 22.09) as well as extending the related bbdev-test.\n\n* bbdev: add device info on queue topology\nhttps://patches.dpdk.org/project/dpdk/list/?series=22076\n\nAddressing an historical concern that the device info struct only\nimperfectly captured what queues are available on the device\n(number of operation and priority). This ended up being an iterative\nprocess for application to find each queue could be configured.\n\nie. the gap was captured as technical debt previously  in comments\n/* This isn't ideal because it reports the maximum number of queues but\n * does not provide info on how many can be uplink/downlink or different\n * priorities\n */\n\nThis is now being exposed explictly based on the what the device actually\nsupports using the existing info_get api\n\n* bbdev: allow operation type enum for growth\nhttps://patches.dpdk.org/project/dpdk/list/?series=23509\n\nThis is related to the general intent to remove using MAX value for enums. There is consensus that we should avoid this for a while notably for future-proofed ABI concerns https://patches.dpdk.org/project/dpdk/patch/20200130142003.2645765-1-ferruh.yigit@intel.com/.\nBut still there is arguably not yet an explicit best recommendation to handle this especially when we actualy need to expose array whose index is such an enum.\nAs a specific example here I am refering to RTE_BBDEV_OP_TYPE_COUNT in enum rte_bbdev_op_type which is being extended for new operation type being support in bbdev (such as https://patches.dpdk.org/project/dpdk/patch/1646956157-245769-2-git-send-email-nicolas.chautru@intel.com/ adding new FFT operation)\n\nThere is also the intent to be able to expose information for each operation type through the bbdev api such as dynamically configured queues information per such operation type https://patches.dpdk.org/project/dpdk/patch/1646785355-168133-2-git-send-email-nicolas.chautru@intel.com/\n\nBasically we are considering best way to accomodate for this, notably based on discussions with Ray Kinsella and Bruce Richardson, to handle such a case moving forward: specifically for the example with RTE_BBDEV_OP_TYPE_COUNT and also more generally.\n\nOne possible option is captured in that patchset and is basically based on the simple principle to allow for growth and prevent ABI breakage. Ie. the last value of the enum is set with a higher value than required so that to allow insertion of new enum outside of the major ABI versions.\nIn that case the RTE_BBDEV_OP_TYPE_COUNT is still present and can be exposed and used while still allowing for addition thanks to the implicit padding-like room. As an alternate variant, instead of using that last enum value, that extended size could be exposed as an #define outside of the enum but would be fundamentally the same (public).\n\nAnother option would be to avoid array alltogether and use each time this a new dedicated API function (operation type enum being an input argument instead of an index to an array in an existing structure so that to get access to structure related to a given operation type enum) but that is arguably not well scalable within DPDK to use such a scheme for each enums and keep an uncluttered and clean API. In that very example that would be very odd indeed not to get this simply from info_get().\n\nSome pros and cons, arguably the simple option in that patchset is a valid compromise option and a step in the right direction but we would like to know your view wrt best recommendation, or any other thought. \n\n\n\n\n\nNicolas Chautru (5):\n  bbdev: allow operation type enum for growth\n  bbdev: add device status info\n  bbdev: add device info on queue topology\n  drivers/baseband: update PMDs to expose queue per operation\n  bbdev: add new operation for FFT processing\n\n app/test-bbdev/test_bbdev.c                        |   2 +-\n app/test-bbdev/test_bbdev_perf.c                   |   4 +-\n doc/guides/prog_guide/bbdev.rst                    | 130 ++++++++++++++++++\n drivers/baseband/acc100/rte_acc100_pmd.c           |  30 ++--\n drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c |   9 ++\n drivers/baseband/fpga_lte_fec/fpga_lte_fec.c       |   9 ++\n drivers/baseband/la12xx/bbdev_la12xx.c             |  10 +-\n drivers/baseband/null/bbdev_null.c                 |   1 +\n drivers/baseband/turbo_sw/bbdev_turbo_software.c   |  12 ++\n examples/bbdev_app/main.c                          |   2 +-\n lib/bbdev/rte_bbdev.c                              |  37 ++++-\n lib/bbdev/rte_bbdev.h                              | 115 +++++++++++++++-\n lib/bbdev/rte_bbdev_op.h                           | 151 ++++++++++++++++++++-\n lib/bbdev/version.map                              |  10 ++\n 14 files changed, 499 insertions(+), 23 deletions(-)",
    "diff": null,
    "prefixes": [
        "v2",
        "0/5"
    ]
}