Show a cover letter.

GET /api/1.2/covers/833927/?format=api
HTTP 200 OK
Allow: GET, HEAD, OPTIONS
Content-Type: application/json
Vary: Accept

{
    "id": 833927,
    "url": "http://patchwork.ozlabs.org/api/1.2/covers/833927/?format=api",
    "web_url": "http://patchwork.ozlabs.org/project/netdev/cover/20171103152636.9967-1-pablo@netfilter.org/",
    "project": {
        "id": 7,
        "url": "http://patchwork.ozlabs.org/api/1.2/projects/7/?format=api",
        "name": "Linux network development",
        "link_name": "netdev",
        "list_id": "netdev.vger.kernel.org",
        "list_email": "netdev@vger.kernel.org",
        "web_url": null,
        "scm_url": null,
        "webscm_url": null,
        "list_archive_url": "",
        "list_archive_url_format": "",
        "commit_url_format": ""
    },
    "msgid": "<20171103152636.9967-1-pablo@netfilter.org>",
    "list_archive_url": null,
    "date": "2017-11-03T15:26:31",
    "name": "[RFC,WIP,0/5] Flow offload infrastructure",
    "submitter": {
        "id": 1315,
        "url": "http://patchwork.ozlabs.org/api/1.2/people/1315/?format=api",
        "name": "Pablo Neira Ayuso",
        "email": "pablo@netfilter.org"
    },
    "mbox": "http://patchwork.ozlabs.org/project/netdev/cover/20171103152636.9967-1-pablo@netfilter.org/mbox/",
    "series": [
        {
            "id": 11752,
            "url": "http://patchwork.ozlabs.org/api/1.2/series/11752/?format=api",
            "web_url": "http://patchwork.ozlabs.org/project/netdev/list/?series=11752",
            "date": "2017-11-03T15:26:31",
            "name": "Flow offload infrastructure",
            "version": 1,
            "mbox": "http://patchwork.ozlabs.org/series/11752/mbox/"
        }
    ],
    "comments": "http://patchwork.ozlabs.org/api/covers/833927/comments/",
    "headers": {
        "Return-Path": "<netdev-owner@vger.kernel.org>",
        "X-Original-To": "patchwork-incoming@ozlabs.org",
        "Delivered-To": "patchwork-incoming@ozlabs.org",
        "Authentication-Results": "ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)",
        "Received": [
            "from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3yT5Qx47d7z9ryT\n\tfor <patchwork-incoming@ozlabs.org>;\n\tSat,  4 Nov 2017 02:26:49 +1100 (AEDT)",
            "(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1755822AbdKCP0r (ORCPT <rfc822;patchwork-incoming@ozlabs.org>);\n\tFri, 3 Nov 2017 11:26:47 -0400",
            "from mail.us.es ([193.147.175.20]:43300 \"EHLO mail.us.es\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1755819AbdKCP0p (ORCPT <rfc822;netdev@vger.kernel.org>);\n\tFri, 3 Nov 2017 11:26:45 -0400",
            "from antivirus1-rhel7.int (unknown [192.168.2.11])\n\tby mail.us.es (Postfix) with ESMTP id EFFE9C0B20\n\tfor <netdev@vger.kernel.org>; Fri,  3 Nov 2017 16:26:43 +0100 (CET)",
            "from antivirus1-rhel7.int (localhost [127.0.0.1])\n\tby antivirus1-rhel7.int (Postfix) with ESMTP id DE6BDB7FE0\n\tfor <netdev@vger.kernel.org>; Fri,  3 Nov 2017 16:26:43 +0100 (CET)",
            "by antivirus1-rhel7.int (Postfix, from userid 99)\n\tid D41B7B7FE4; Fri,  3 Nov 2017 16:26:43 +0100 (CET)",
            "from antivirus1-rhel7.int (localhost [127.0.0.1])\n\tby antivirus1-rhel7.int (Postfix) with ESMTP id 9D8E4B7FE0;\n\tFri,  3 Nov 2017 16:26:41 +0100 (CET)",
            "from 192.168.1.97 (192.168.1.97) by antivirus1-rhel7.int\n\t(F-Secure/fsigk_smtp/550/antivirus1-rhel7.int); \n\tFri, 03 Nov 2017 16:26:41 +0100 (CET)",
            "from salvia.here (unknown [31.4.245.115])\n\t(Authenticated sender: pneira@us.es)\n\tby entrada.int (Postfix) with ESMTPA id 4DC47403DFA0;\n\tFri,  3 Nov 2017 16:26:41 +0100 (CET)"
        ],
        "X-Spam-Checker-Version": "SpamAssassin 3.4.1 (2015-04-28) on\n\tantivirus1-rhel7.int",
        "X-Spam-Level": "",
        "X-Spam-Status": "No, score=-108.2 required=7.5 tests=ALL_TRUSTED,BAYES_50,\n\tSMTPAUTH_US2,USER_IN_WHITELIST autolearn=disabled version=3.4.1",
        "X-Virus-Status": "clean(F-Secure/fsigk_smtp/550/antivirus1-rhel7.int)",
        "X-SMTPAUTHUS": "auth mail.us.es",
        "From": "Pablo Neira Ayuso <pablo@netfilter.org>",
        "To": "netfilter-devel@vger.kernel.org",
        "Cc": "netdev@vger.kernel.org",
        "Subject": "[PATCH RFC,WIP 0/5] Flow offload infrastructure",
        "Date": "Fri,  3 Nov 2017 16:26:31 +0100",
        "Message-Id": "<20171103152636.9967-1-pablo@netfilter.org>",
        "X-Mailer": "git-send-email 2.11.0",
        "X-Virus-Scanned": "ClamAV using ClamSMTP",
        "Sender": "netdev-owner@vger.kernel.org",
        "Precedence": "bulk",
        "List-ID": "<netdev.vger.kernel.org>",
        "X-Mailing-List": "netdev@vger.kernel.org"
    },
    "content": "Hi,\n\nThis patch adds the flow offload infrastructure for Netfilter. This adds\na new 'nf_flow_offload' module that registers a hook at ingress. Every\npacket that hits the flow table is forwarded to where the flow table\nentry specifies in terms of destination/gateway and netdevice. In case\nof flow table miss, the packet follows the classic forward path.\n\nThis flow table is populated via the new nftables VM action\n'flow_offload', so the user can selectively specify what flows are\nplaced into the flow table, an example ruleset would look like this:\n\n        table inet x {\n                chain y {\n                        type filter hook forward priority 0; policy accept;\n                        ip protocol tcp flow offload counter\n                        counter\n                }\n        }\n\nThe 'flow offload' action adds the flow entry once the flow is in\nestablished state, according to the connection tracking definition, ie.\nwe have seen traffic in both directions. Therefore, only initial packets\nof the flow follow the classic forwarding path.\n\n* Patch 1/5 is nothing really interesting, just a little preparation change.\n\n* Patch 2/5 adds a software flow table representation. It uses the\n  rhashtable and an API to operate with it, it also introduces the\n  'struct flow_offload' that represents a flow table entry. There's a\n  garbage collector kernel thread that cleans up entries for which we\n  have not seen any packet for a while.\n\n* Patch 3/5 Just adds the missing bits to integrate the software flow\n  table with conntrack. The software flow table owns the conntrack\n  object, so it is basically responsible for releasing it. Conntrack\n  entries that have been offloaded in the conntrack table will look like\n  this:\n\nipv4     2 tcp      6 src=10.141.10.2 dst=147.75.205.195 sport=36392 dport=443 src=147.75.205.195 dst=192.168.2.195 sport=443 dport=36392 [OFFLOAD] use=2\n\n* Patch 4/5 adds the extension for nf_tables that can be used to select\n  what flows are offloaded through policy.\n\n* Patch 5/5 Switches and NICs come with built-in flow table, I've been\n  observing out of tree patches in OpenWRT/LEDE to integrate this into\n  Netfilter for a little while. This patch adds the ndo hooks to\n  populate hardware flow table. This patchs a workqueue to configure\n  from user context - we need to hold the mdio mutex for this. There\n  will be a little time until packets will follow the hardware path.\n  So packets will be following the software flow table path for a little\n  while until the start going through hardware.\n\nI'm measuring here that the software flow table forwarding path is 2.5\nfaster than the classic forwarding path in my testbed.\n\nTODO, still many things:\n\n* Only IPv4 at this time.\n* Only IPv4 SNAT is supported.\n* No netns support yet.\n* Missing netlink interface to operate with the flow table, to force the\n  handover of flow to the software path.\n* Higher configurability, instead of registering the flow table\n  inconditionally, add an interface to specify software flow table\n  properties.\n* No flow counters at this time.\n\nThis should serve a number of usecases where we can rely on this kernel\nbypass. Packets that need fragmentation / PMTU / IP option handling /\n... and any specific handling, then we should pass them up to the\nforwarding classic path.\n\nComments welcome,\nThanks.\n\nPablo Neira Ayuso (5):\n  netfilter: nf_conntrack: move nf_ct_netns_{get,put}() to core\n  netfilter: add software flow offload infrastructure\n  netfilter: nf_flow_offload: integration with conntrack\n  netfilter: nf_tables: flow offload expression\n  netfilter: nft_flow_offload: add ndo hooks for hardware offload\n\n include/linux/netdevice.h                          |   4 +\n include/net/flow_offload.h                         |  67 ++++\n include/net/netfilter/nf_conntrack.h               |   3 +-\n include/uapi/linux/netfilter/nf_conntrack_common.h |   4 +\n include/uapi/linux/netfilter/nf_tables.h           |   9 +\n net/netfilter/Kconfig                              |  14 +\n net/netfilter/Makefile                             |   4 +\n net/netfilter/nf_conntrack_core.c                  |   7 +-\n net/netfilter/nf_conntrack_netlink.c               |  15 +-\n net/netfilter/nf_conntrack_proto.c                 |  37 +-\n net/netfilter/nf_conntrack_proto_tcp.c             |   3 +\n net/netfilter/nf_conntrack_standalone.c            |  12 +-\n net/netfilter/nf_flow_offload.c                    | 421 ++++++++++++++++++++\n net/netfilter/nft_ct.c                             |  39 +-\n net/netfilter/nft_flow_offload.c                   | 430 +++++++++++++++++++++\n 15 files changed, 1024 insertions(+), 45 deletions(-)\n create mode 100644 include/net/flow_offload.h\n create mode 100644 net/netfilter/nf_flow_offload.c\n create mode 100644 net/netfilter/nft_flow_offload.c"
}