From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 644F9A0548; Fri, 16 Apr 2021 14:41:38 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1DB1B141C73; Fri, 16 Apr 2021 14:41:38 +0200 (CEST) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2057.outbound.protection.outlook.com [40.107.223.57]) by mails.dpdk.org (Postfix) with ESMTP id AE4B6141C3F for ; Fri, 16 Apr 2021 14:41:36 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UdL4IsgUGl10eEHF9y8P873s3cRZ5oGEBkxWC4ICA9z6FAUoouz1sq33cYRMAGcct6++10xRmhurobHbdQg67RbK/ymi3P8+4freNHEbcKHE4mJFM+vm7ETu0V5VTRasVLh5J30d3uRGEmr40oLMlDSFyphh1kocBm+XEWHd001KQR8P6EZGrCPTYU4R5BmrkeL+kCeJ35VP+Z3rqVGYm3pAXbVOzbosq1N6LUJBo1jKXGDBykqd3XGYjFaL17J6ELeEV3ev4yFOgsgDXAj38ZxprAi42VapdNOo51Qlk2r1r3hfXc3O01JF6ix0Z8WQKVxDpnhUFWzk90zsdoqUWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qC2vYgk5f7e6nx+1yMcOizxXdygRXTlD7Onh/1ibId4=; b=WIlJIvLJuv75St8nkBMhu+pWxFqiuSqyi+w9bEUhF6e0UfQpj5vV+VIg2s26/vwXTQsG3cjCcFUWj88VdWTjeNZJhY6edBVpfPC5A6DzsvYKkcpx1wYF7O8gVOWjGyImu2SQ1YBNTyBEljYiif5xVULUDyQ46dD/v4IFlkS0yeZ5ZONXcftXTMMtW8a5RgTmb61Os7fXzUq4Kcsee82n3wRrUjcBmZ3WaQEabq7ebZ3EHTrBfopQXe7jlOuvEzLKG3FO6zy+MHrVSqWhpH+zbwEeTU5kNPxxZivDhhgSR5qxRDWV+53L2qh2XaSFJ8xkFbqqs1GLJ8Wsp31k+nnGLQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qC2vYgk5f7e6nx+1yMcOizxXdygRXTlD7Onh/1ibId4=; b=RF8N6oHuZ8Ysyuh1si18y/lugjVtZn5UYzpQKB7CXwIBXIFrFqkNM2vq65aveZfOmf/TzA7n7THXHue3UiM5x5d0WzrbyiqOqDqcvIA8OoZnVf9ZczHGUwODStKNFlxqYkJFEQ81aAGbqhKxpw8IQ3sV1UvboE0pWlUgwVX3B4JnqPUKurBtZzpq2kfgCkQ/tJsDVaen0tMENhtUaCS4yoZurPfAUFdLixFRrrR4u1tk9ayfo3QsorbkfSE0Scw9fUOSarstUgSrwcNOtNbF+WQOTCVwZ3dBoLEW9YhvmOngxw5FJ058s+fxq1DR2wUpLVTUwnuuUvckl3aIdwHUIw== Received: from DM6PR12MB4987.namprd12.prod.outlook.com (2603:10b6:5:163::31) by DM6PR12MB4862.namprd12.prod.outlook.com (2603:10b6:5:1b7::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.18; Fri, 16 Apr 2021 12:41:35 +0000 Received: from DM6PR12MB4987.namprd12.prod.outlook.com ([fe80::f5ce:c5a8:6aec:e308]) by DM6PR12MB4987.namprd12.prod.outlook.com ([fe80::f5ce:c5a8:6aec:e308%7]) with mapi id 15.20.4020.022; Fri, 16 Apr 2021 12:41:35 +0000 From: Ori Kam To: Bing Zhao , NBU-Contact-Thomas Monjalon , "ferruh.yigit@intel.com" , "andrew.rybchenko@oktetlabs.ru" CC: "dev@dpdk.org" , "ajit.khaparde@broadcom.com" Thread-Topic: [PATCH v2 1/2] ethdev: introduce conntrack flow action and item Thread-Index: AQHXMhYxCGk1YN1QW0G+XsK+o0Y6QKq3FQEA Date: Fri, 16 Apr 2021 12:41:35 +0000 Message-ID: References: <1618062393-205611-1-git-send-email-bingz@nvidia.com> <1618504877-95597-1-git-send-email-bingz@nvidia.com> <1618504877-95597-2-git-send-email-bingz@nvidia.com> In-Reply-To: <1618504877-95597-2-git-send-email-bingz@nvidia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nvidia.com; dkim=none (message not signed) header.d=none;nvidia.com; dmarc=none action=none header.from=nvidia.com; x-originating-ip: [147.236.145.126] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 29da48be-bdc9-44b0-1275-08d900d4f89a x-ms-traffictypediagnostic: DM6PR12MB4862: x-ld-processed: 43083d15-7273-40c1-b7db-39efd9ccc17a,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:510; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yNTpjRSr0kKRHdq1BzE4kT1SOB1jDCIx/Sfj7gjiyldG/B6fCUOWXpHriOkp8cpaJi9QG0fDzfnO9Zs0iho4pnT66wEtQhT6HIpsSfRNTPl8LsXwJZGxYV4VWusnFDaLhNHpHUYY4Lp4VFUF2wlL/cUOnX2a1/3atWoxNxEVIm9p7c3ytUGMY83IBo9r4bGnRELapO0TIWgl2f7C1cvITMLo+FKlYOm4l4TiRqc80ynZ5qL3orLXisRJ9joOgIZXTpr8p1zohG8ku0zuIj1eNtrInk3PWbxASDXd25PIPSs7+fZP+maTu/52RyzpaE5cYPuaVffM0CzKyBmWVhwyR8aYKyThykiyviunotMvos2EtEyzf+K38+aybLcVQ5Ba4rkl0gmlOwnFMWRxRP+js0RDnYOfVf9EkgP40KLxXwkVDrPOcf5p58NLcNIJ3rtq8L5AA7mE48xT6rE+KClPQyj52NKI1OszGLL3U1jB4xWGC6au2GgbXlEqpLz1UiqpKgCqxwYAvW+rvYkTULBKdHFB/1TXVCOw5jRMdlP2szDl0BoIFzJXGLOPP9NbuT+kqGVM6RC3/s/w3ZvXo9gRGpuqgqZaHEzc4hJkIPleuLD4kfkbqUVUN+dIGeT4d1nQOCGji77vid+x7u7TXGcRYY5thKOSHRw44gzgIwaXJTsp+lYIPYAu55KvPnKdoNKt x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR12MB4987.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(376002)(366004)(136003)(396003)(39860400002)(55016002)(966005)(186003)(316002)(4326008)(122000001)(64756008)(5660300002)(9686003)(66446008)(66556008)(66476007)(66946007)(71200400001)(86362001)(76116006)(83380400001)(54906003)(30864003)(38100700002)(53546011)(8936002)(52536014)(2906002)(6506007)(110136005)(33656002)(7696005)(478600001)(8676002)(26005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?hKp0DZRmTk68iE7vaHfRY/jxHhSgg0h+8GB0F1HkWYmsv0MCRqGH8yeKOU84?= =?us-ascii?Q?WcQQHSDgR1/QLWqitcTz6bKcDozS7nd5AwvdOPu4ceYY38j2qUXBzG6KSpda?= =?us-ascii?Q?ka8VqTvpnlOD2/46tgx205LxwDjYw4ei9gu0on3+lbOdrB6BCrT4QOulrawy?= =?us-ascii?Q?6GYV3uhD7KAWGQJelCb/JW6RMe+fmMnNrgV41Bi1JhAIeuwOkdmhfvhPN/Kq?= =?us-ascii?Q?ZnFa1fDT3N5GCwb4DrYjyj1YY4GOfkf7w9SgoZ9zqMkCS7ujTzHB+27QCwTC?= =?us-ascii?Q?ZB9CA0QrYUBqdJgoV43GC0dhPgEjNo/zNWdA5YyK2TYXtbHhCVWRdbHSjmyW?= =?us-ascii?Q?sK2c5BGIQC9nUW+bnDsGL6YOr8SKBD3VxSLZIbNvi94FLCXHm4zx/2mtJsuO?= =?us-ascii?Q?BsRSkCzMH2en26mJmS6G08uiHTUSIfO2JZuS23nHXXaGG41To8TVAbsLDcGk?= =?us-ascii?Q?AMKHJkig+o/zSrYYYqRwVMlNjDbXTuk0SCUnQvD+9o/fSi31A77/qkPKCsux?= =?us-ascii?Q?xgn+ubJ25eiJpujhWxChSH6nROG32y4A7S3d7jOq2sfx6Gy2tSJ2f4N1GjDu?= =?us-ascii?Q?FEH7LBu35yDE+5tYD/JBHsyRDwJP2Uon65W9gWqJcPnCqbx03x/6McXDFNgR?= =?us-ascii?Q?itHrWW/TX7i0P3jmMl1lRGBTsTzLaRo+AejgFnXoEwp4rUm7RR1ZPKlvYfHV?= =?us-ascii?Q?MLxldk+mEeqzzfDKKEDmavuUEvRvaB81GOKxf/OOjTPoqzb/yDxXUWD4HNrB?= =?us-ascii?Q?mBqqsKJx/orxESPByQlFIYQ6brWbkH50Zr9lGM5PnEHVSYttup17ABj2fsoz?= =?us-ascii?Q?yHvrSEufGLroqwK3KrNvXmHVis6jc29i4DfLFRcA2b/MGeE3Cfwd8TwuzhH/?= =?us-ascii?Q?LAWGoYpiLJUi/SpqEzzIQVgIGesa9J+GGmI4V0/nIpfmVraew2iKjxkoQrAm?= =?us-ascii?Q?skwj0Tljtk5+/YaRyLaTpaupIUqz3XAg0O4lJvppifI5mch/EgKV6QrlGM7d?= =?us-ascii?Q?A+LRIgMLKpMZrX8M82eKDbrv8dlXIEshOGx3CMdsXV27IZvgZOzaLZG/pZ9u?= =?us-ascii?Q?kcki/aZJ2FqZzdD6s81KuEGX+L+zyWK+OQ2VEp+guLt3/KeO1XD5mpL9zzEV?= =?us-ascii?Q?T7j4y5qrvU3uX0wPAeVMwgoEY+YUEkqncCzxdnD2dotQRv7eE1XKdJ708voQ?= =?us-ascii?Q?L/60jT4sExz97CUYTq6uQ5XfK+n219ABYNywK4mwhU5hWYrmT1RyKubCTiBW?= =?us-ascii?Q?Ytkg01+2IOpYepFS13/R0WXK8fUABBf3X+yML7YFvnDEyk8aB9lzABu/oatP?= =?us-ascii?Q?zwsvkLktzx0FcHzhnadIuvdj?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR12MB4987.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 29da48be-bdc9-44b0-1275-08d900d4f89a X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2021 12:41:35.2689 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: cfasaKklNC6YlKgWcIBOv3lug4eqUO7Qp+kTsPHR+bCzvQyJKxRWUF2of8id3k2fMu25ZAU73EzJO6GzV+wAjg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4862 Subject: Re: [dpdk-dev] [PATCH v2 1/2] ethdev: introduce conntrack flow action and item X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Bing, One more thought, PSB Best, Ori > -----Original Message----- > From: Bing Zhao > Sent: Thursday, April 15, 2021 7:41 PM > To: Ori Kam ; NBU-Contact-Thomas Monjalon > ; ferruh.yigit@intel.com; > andrew.rybchenko@oktetlabs.ru > Cc: dev@dpdk.org; ajit.khaparde@broadcom.com > Subject: [PATCH v2 1/2] ethdev: introduce conntrack flow action and item >=20 > This commit introduced the conntrack action and item. >=20 > Usually the HW offloading is stateless. For some stateful offloading > like a TCP connection, HW module will help provide the ability of a > full offloading w/o SW participation after the connection was > established. >=20 > The basic usage is that in the first flow the application should add > the conntrack action and in the following flow(s) the application > should use the conntrack item to match on the result. >=20 > A TCP connection has two directions traffic. To set a conntrack > action context correctly, information from packets of both directions > are required. >=20 > The conntrack action should be created on one port and supply the > peer port as a parameter to the action. After context creating, it > could only be used between the ports (dual-port mode) or a single > port. The application should modify the action via the API > "action_handle_update" only when before using it to create a flow > with opposite direction. This will help the driver to recognize the > direction of the flow to be created, especially in single port mode. > The traffic from both directions will go through the same port if > the application works as an "forwarding engine" but not a end point. > There is no need to call the update interface if the subsequent flows > have nothing to be changed. >=20 > Query will be supported via action_ctx_query interface, about the > current packets information and connection status. Tha fields > query capabilities depends on the HW. >=20 > For the packets received during the conntrack setup, it is suggested > to re-inject the packets in order to take full advantage of the > conntrack. Only the valid packets should pass the conntrack, packets > with invalid TCP information, like out of window, or with invalid > header, like malformed, should not pass. >=20 > Naming and definition: > https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/netfilt= er/nf_co > nntrack_tcp.h > https://elixir.bootlin.com/linux/latest/source/net/netfilter/nf_conntrack= _proto_ > tcp.c >=20 > Other reference: > https://www.usenix.org/legacy/events/sec01/invitedtalks/rooij.pdf >=20 > Signed-off-by: Bing Zhao > --- > lib/librte_ethdev/rte_flow.c | 2 + > lib/librte_ethdev/rte_flow.h | 195 +++++++++++++++++++++++++++++++++++ > 2 files changed, 197 insertions(+) >=20 > diff --git a/lib/librte_ethdev/rte_flow.c b/lib/librte_ethdev/rte_flow.c > index 27a161559d..0af601d508 100644 > --- a/lib/librte_ethdev/rte_flow.c > +++ b/lib/librte_ethdev/rte_flow.c > @@ -98,6 +98,7 @@ static const struct rte_flow_desc_data > rte_flow_desc_item[] =3D { > MK_FLOW_ITEM(PFCP, sizeof(struct rte_flow_item_pfcp)), > MK_FLOW_ITEM(ECPRI, sizeof(struct rte_flow_item_ecpri)), > MK_FLOW_ITEM(GENEVE_OPT, sizeof(struct > rte_flow_item_geneve_opt)), > + MK_FLOW_ITEM(CONNTRACK, sizeof(uint32_t)), > }; >=20 > /** Generate flow_action[] entry. */ > @@ -186,6 +187,7 @@ static const struct rte_flow_desc_data > rte_flow_desc_action[] =3D { > * indirect action handle. > */ > MK_FLOW_ACTION(INDIRECT, 0), > + MK_FLOW_ACTION(CONNTRACK, sizeof(struct > rte_flow_action_conntrack)), > }; >=20 > int > diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h > index 91ae25b1da..024d1a2026 100644 > --- a/lib/librte_ethdev/rte_flow.h > +++ b/lib/librte_ethdev/rte_flow.h > @@ -551,6 +551,15 @@ enum rte_flow_item_type { > * See struct rte_flow_item_geneve_opt > */ > RTE_FLOW_ITEM_TYPE_GENEVE_OPT, > + > + /** > + * [META] > + * > + * Matches conntrack state. > + * > + * See struct rte_flow_item_conntrack. > + */ > + RTE_FLOW_ITEM_TYPE_CONNTRACK, > }; >=20 > /** > @@ -1685,6 +1694,51 @@ rte_flow_item_geneve_opt_mask =3D { > }; > #endif >=20 > +/** > + * The packet is with valid state after conntrack checking. > + */ > +#define RTE_FLOW_CONNTRACK_FLAG_PKT_STATE_VALID (1 << 0) > +/** > + * The state of the connection was changed. > + */ > +#define RTE_FLOW_CONNTRACK_FLAG_PKT_STATE_CHANGED (1 << 1) > +/** > + * Error is detected on this packet for this connection and > + * an invalid state is set. > + */ > +#define RTE_FLOW_CONNTRACK_FLAG_PKT_STATE_INVAL (1 << 2) > +/** > + * The HW connection tracking module is disabled. > + * It can be due to application command or an invalid state. > + */ > +#define RTE_FLOW_CONNTRACK_FLAG_HW_DISABLED (1 << 3) > +/** > + * The packet contains some bad field(s) and cannot continue > + * with the conntrack module checking. > + */ > +#define RTE_FLOW_CONNTRACK_FLAG_PKT_BAD (1 << 4) > + > +/** > + * @warning > + * @b EXPERIMENTAL: this structure may change without prior notice > + * > + * RTE_FLOW_ITEM_TYPE_CONNTRACK > + * > + * Matches the state of a packet after it passed the connection tracking > + * examination. The state is a bit mask of one RTE_FLOW_CONNTRACK_FLAG* > + * or a reasonable combination of these bits. > + */ > +struct rte_flow_item_conntrack { > + uint32_t flags; > +}; > + > +/** Default mask for RTE_FLOW_ITEM_TYPE_CONNTRACK. */ > +#ifndef __cplusplus > +static const struct rte_flow_item_conntrack rte_flow_item_conntrack_mask= =3D > { > + .flags =3D 0xffffffff, > +}; > +#endif > + > /** > * Matching pattern item definition. > * > @@ -2277,6 +2331,17 @@ enum rte_flow_action_type { > * same port or across different ports. > */ > RTE_FLOW_ACTION_TYPE_INDIRECT, > + > + /** > + * [META] > + * > + * Enable tracking a TCP connection state. > + * > + * Send packet to HW connection tracking module for examination. > + * > + * See struct rte_flow_action_conntrack. > + */ > + RTE_FLOW_ACTION_TYPE_CONNTRACK, > }; >=20 > /** > @@ -2875,6 +2940,136 @@ struct rte_flow_action_set_dscp { > */ > struct rte_flow_action_handle; >=20 > +/** > + * The state of a TCP connection. > + */ > +enum rte_flow_conntrack_state { > + /**< SYN-ACK packet was seen. */ > + RTE_FLOW_CONNTRACK_STATE_SYN_RECV, > + /**< 3-way handshark was done. */ > + RTE_FLOW_CONNTRACK_STATE_ESTABLISHED, > + /**< First FIN packet was received to close the connection. */ > + RTE_FLOW_CONNTRACK_STATE_FIN_WAIT, > + /**< First FIN was ACKed. */ > + RTE_FLOW_CONNTRACK_STATE_CLOSE_WAIT, > + /**< Second FIN was received, waiting for the last ACK. */ > + RTE_FLOW_CONNTRACK_STATE_LAST_ACK, > + /**< Second FIN was ACKed, connection was closed. */ > + RTE_FLOW_CONNTRACK_STATE_TIME_WAIT, > +}; > + > +/** > + * The last passed TCP packet flags of a connection. > + */ > +enum rte_flow_conntrack_tcp_last_index { > + RTE_FLOW_CONNTRACK_FLAG_NONE =3D 0, /**< No Flag. */ > + RTE_FLOW_CONNTRACK_FLAG_SYN =3D (1 << 0), /**< With SYN flag. */ > + RTE_FLOW_CONNTRACK_FLAG_SYNACK =3D (1 << 1), /**< With SYN+ACK > flag. */ > + RTE_FLOW_CONNTRACK_FLAG_FIN =3D (1 << 2), /**< With FIN flag. */ > + RTE_FLOW_CONNTRACK_FLAG_ACK =3D (1 << 3), /**< With ACK flag. */ > + RTE_FLOW_CONNTRACK_FLAG_RST =3D (1 << 4), /**< With RST flag. */ > +}; > + > +/** > + * @warning > + * @b EXPERIMENTAL: this structure may change without prior notice > + * > + * Configuration parameters for each direction of a TCP connection. > + */ > +struct rte_flow_tcp_dir_param { > + uint32_t scale:4; /**< TCP window scaling factor, 0xF to disable. */ > + uint32_t close_initiated:1; /**< The FIN was sent by this direction. */ > + /**< An ACK packet has been received by this side. */ > + uint32_t last_ack_seen:1; > + /**< If set, indicates that there is unacked data of the connection. */ > + uint32_t data_unacked:1; > + /**< Maximal value of sequence + payload length over sent > + * packets (next ACK from the opposite direction). > + */ > + uint32_t sent_end; > + /**< Maximal value of (ACK + window size) over received packet + > length > + * over sent packet (maximal sequence could be sent). > + */ > + uint32_t reply_end; This comment is for all members that are part of the packet, Do you think it should be in network order? I can see the advantage in both ways nice I assume the app needs this data= =20 in host byte-order but since in most other cases we use network byte-order= to=20 set values that are coming from the packet itself maybe it is better to use= network byte-order (will also save the conversion) > + /**< Maximal value of actual window size over sent packets. */ > + uint32_t max_win; > + /**< Maximal value of ACK over sent packets. */ > + uint32_t max_ack; > +}; > + > +/** > + * @warning > + * @b EXPERIMENTAL: this structure may change without prior notice > + * > + * RTE_FLOW_ACTION_TYPE_CONNTRACK > + * > + * Configuration and initial state for the connection tracking module. > + * This structure could be used for both setting and query. > + */ > +struct rte_flow_action_conntrack { > + uint16_t peer_port; /**< The peer port number, can be the same port. > */ > + /**< Direction of this connection when creating a flow, the value only > + * affects the subsequent flows creation. > + */ > + uint32_t is_original_dir:1; > + /**< Enable / disable the conntrack HW module. When disabled, the > + * result will always be RTE_FLOW_CONNTRACK_FLAG_DISABLED. > + * In this state the HW will act as passthrough. > + * It only affects this conntrack object in the HW without any effect > + * to the other objects. > + */ > + uint32_t enable:1; > + /**< At least one ack was seen, after the connection was established. > */ > + uint32_t live_connection:1; > + /**< Enable selective ACK on this connection. */ > + uint32_t selective_ack:1; > + /**< A challenge ack has passed. */ > + uint32_t challenge_ack_passed:1; > + /**< 1: The last packet is seen that comes from the original direction. > + * 0: From the reply direction. > + */ > + uint32_t last_direction:1; > + /**< No TCP check will be done except the state change. */ > + uint32_t liberal_mode:1; > + /**< The current state of the connection. */ > + enum rte_flow_conntrack_state state; > + /**< Scaling factor for maximal allowed ACK window. */ > + uint8_t max_ack_window; > + /**< Maximal allowed number of retransmission times. */ > + uint8_t retransmission_limit; > + /**< TCP parameters of the original direction. */ > + struct rte_flow_tcp_dir_param original_dir; > + /**< TCP parameters of the reply direction. */ > + struct rte_flow_tcp_dir_param reply_dir; > + /**< The window value of the last packet passed this conntrack. */ > + uint16_t last_window; > + enum rte_flow_conntrack_tcp_last_index last_index; > + /**< The sequence of the last packet passed this conntrack. */ > + uint32_t last_seq; > + /**< The acknowledgement of the last packet passed this conntrack. */ > + uint32_t last_ack; > + /**< The total value ACK + payload length of the last packet passed > + * this conntrack. > + */ > + uint32_t last_end; > +}; > + > +/** > + * RTE_FLOW_ACTION_TYPE_CONNTRACK > + * > + * Wrapper structure for the context update interface. > + * Ports cannot support updating, and the only valid solution is to > + * destroy the old context and create a new one instead. > + */ > +struct rte_flow_modify_conntrack { > + /**< New connection tracking parameters to be updated. */ > + struct rte_flow_action_conntrack new_ct; > + uint32_t direction:1; /**< The direction field will be updated. */ > + /**< All the other fields except direction will be updated. */ > + uint32_t state:1; > + uint32_t reserved:30; /**< Reserved bits for the future usage. */ > +}; > + > /** > * Field IDs for MODIFY_FIELD action. > */ > -- > 2.19.0.windows.1