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 43F1DA0A02; Fri, 16 Apr 2021 20:18:11 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AAE93161D02; Fri, 16 Apr 2021 20:18:10 +0200 (CEST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750089.outbound.protection.outlook.com [40.107.75.89]) by mails.dpdk.org (Postfix) with ESMTP id 97867161CF2 for ; Fri, 16 Apr 2021 20:18:07 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jKoYT+aXZwdas5QOwZQj8XcIiVbJIqVy3cFbwcld4PzDGlFE23YxuZjU5gLByj5BjNfgGYZLQd6qXqTeGNxzVwciw1EB9CWlSNMy4bBXHGhKjXzGSWxgeZ63hwPnSLDXHcnLeXG59yW1Grc6egQXQKHC1zaB4EgaQdkM23zAS9Z2KDp+EBu3je0I7sXD4/4f+uJTdcGbR1gEIDBAbxH+y99XLe2Nqtfoib9GfwuaMpxXnXValCIi7/KhFbYUGQjvTQTxfcbq07UXF3Qi0O5CpQ5BY61GoKcQGz9WpES3E81Kd626D5+ym61Mx0wPI+3d2XNPwab5Iy8RHid5RGvIIA== 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=eGdu8JjImTNZN6ImOsNMhbdDNOiz8DmNGfaMC/foCuU=; b=ElLVg6hJmeGbPQ519g05gFpvBYTOdBk+IQLkZQvqZtY6TZYf9X9omch22h7lDetISxSqcz+md6ozcREwb7NKAJobYVRWdPcwwuOSGa3I/1IkbhwvFmVULzjXras3AMVbdAuUyS0XADYti1EVfFzIWn8sJ02Ruijc6etW+UhsnQ9bosKmA2zZahE9lfXiTDewy6aivK+5borIT+pYW3Nju+BjN9lifcBgE123NiFIyy6g2ukRCzNi3ueiV0++/J2PgkK3onqq5xqsIHIsNJ2EUfKsn/eK51jGlrMA62RPIahbqLmuBNm530eAPEsnteznOHupv/mw2R2gjIU/Ibe72Q== 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=eGdu8JjImTNZN6ImOsNMhbdDNOiz8DmNGfaMC/foCuU=; b=Rf3LDan8tcNnx2QPKCEWJlYwsobGDm3BhXtJGPi054vpniNbSUPZQM6fza/CH1d1t2PP8pg4iyQcs6s8/b99LQYpzltCT2Kv5sBSOUct3bf2RQNkHlw5c+p5REcTGaA0yr9tiI4ZG7er7vGX6YBblYP5jcKBzJbmcWAQVdwYFLHFoQASLzA8dx4MM1pFFtgFFGURNtG6zDn1knliMNnA8MyJNdj6J2QbtRLHL45d/CyqOO2FXWiHtCXZSk1FQlZRq1/B3Ty07ir6L7tkEdqPqkquKHtu+T0T3zkjOv7gXxGkFdmFlSGC93WZYDS2VtjhzhrhNDkMystDyXbgBoPz/Q== Received: from MN2PR12MB2909.namprd12.prod.outlook.com (2603:10b6:208:103::13) by MN2PR12MB2957.namprd12.prod.outlook.com (2603:10b6:208:100::14) 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 18:18:05 +0000 Received: from MN2PR12MB2909.namprd12.prod.outlook.com ([fe80::7cbc:e499:e936:7408]) by MN2PR12MB2909.namprd12.prod.outlook.com ([fe80::7cbc:e499:e936:7408%7]) with mapi id 15.20.4042.018; Fri, 16 Apr 2021 18:18:05 +0000 From: Bing Zhao To: NBU-Contact-Thomas Monjalon CC: Ori Kam , "ferruh.yigit@intel.com" , "andrew.rybchenko@oktetlabs.ru" , "dev@dpdk.org" , "ajit.khaparde@broadcom.com" , "jerinj@marvell.com" , "humin29@huawei.com" , "rosen.xu@intel.com" , "hemant.agrawal@nxp.com" Thread-Topic: [dpdk-dev] [PATCH v2 1/2] ethdev: introduce conntrack flow action and item Thread-Index: AQHXMhYx0VN7vXiF8keDnUbw+e/Xpqq2+FAAgAB5zQA= Date: Fri, 16 Apr 2021 18:18:05 +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> <2924323.ELig26xF5v@thomas> In-Reply-To: <2924323.ELig26xF5v@thomas> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: monjalon.net; dkim=none (message not signed) header.d=none;monjalon.net; dmarc=none action=none header.from=nvidia.com; x-originating-ip: [39.183.9.221] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d14e836a-11de-4a66-6138-08d90103fabc x-ms-traffictypediagnostic: MN2PR12MB2957: 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:5236; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XVNNL3eFu8aaLcMJSMVnEsw32AMxNAoFQLzpzUs6jIA96kY4DUIok8tEkuPbOfDxKaV/tTHijtGGY0Pz+uKPIUuM1OAX1FuoE6fIlSkSKd6dCM7vybi/ingZemEWxBFjk1S8rwuLWHurTT21C2e8slBo2ygDhgGB/Dc4YsPSbZAUtyhJgGs4S4s0YjVU5xKnfkxGe7bi/V+obPCK4a+722+AL9pbBy+iCW4tDBDwIeHxLA15baE1v/0w9Xi4xWR2N7X/a0MpUMnPCafZlU6fQwLRiykcGaQmYbe9svEVfdmw7m430TLJR4Itdc+LSdW03i4HvQsa0VaibC6tM9228Jy065WxXZkgq28kzu4M+3ktcOIt7JBc7Siqj/SchOa8G0yBtrqB7tOrtCmf1YhC5POKcz2UhKpDAoJo4Ol0ns56IWYv/cfd40ItLRJGBnZse7Sj7oBkDql0dce03iFHX7dADZEUIp85mhWKXP3+qsFFYPdtnSydV+l76sMTzmCHb1OS52PxVbQmE0mGvA1R8QL9inxogwJd4E4KB2bvGcPmKQ53gDYl3D4NF/NpKNjBVhXZxojsOvKyskNTaeAfFuYNGplXsFDUf63uFyoN1JaRyS7cSquKldNw9vD1TYtz3/uzyfNyGUrYhkXe8xBfCBbYE03vt4hXAuptRiGlC/SBYzIahFKOeduVnGgzGP09 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR12MB2909.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(376002)(136003)(346002)(396003)(39860400002)(9686003)(966005)(55016002)(45080400002)(64756008)(66946007)(52536014)(4326008)(478600001)(5660300002)(66446008)(83380400001)(30864003)(6916009)(66476007)(86362001)(66556008)(8936002)(2906002)(8676002)(26005)(186003)(6506007)(33656002)(53546011)(76116006)(7696005)(54906003)(122000001)(316002)(71200400001)(38100700002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?nElPllmAiU/7s9ONGpVE9Ukgz3ij4ZdrfbnhAk1PbAYo9AcYD6pJIUa8FX2g?= =?us-ascii?Q?5RNYHEfg397iCQ8z1FE3/2gfLCvqGuT0pKZ3RaUn61+lcjpxs4gWiSHKvg+o?= =?us-ascii?Q?dIB2dIVYG8mc78sIUm6EIZQUZ0XqcAKtFcY0C6KQdNLKvOoqwbB+5JGE1qko?= =?us-ascii?Q?kKnEvRu4RoNumrAoPGTFO6QZKcxU1JRP8zygR4GxU6Yf8Ri0Q1fHmoPIpKU9?= =?us-ascii?Q?x7n/PSRN+Iw9hzjDj4K4i6o4N2Q+8p8tTvnswqLySyx3Dg20UA42JLxru1Pv?= =?us-ascii?Q?yakpwVe6KGWELocXmWi7Rz+q9wBbGguzrCr8V4pgLDRqv/6tYRs8W9y0gjnZ?= =?us-ascii?Q?56Y1bufeG1PPXkk+Br4khymjLafr9mcct0PZLYU70L3uxoG0/skxA/gywdYg?= =?us-ascii?Q?HAXG8pP7x+Oua9fuqBChMhwudzXb3Uh1oytFUw95xHf4q0ju1fIn9VjV/YwS?= =?us-ascii?Q?JUH6gKy4lNEjhSrOdkvs0Oc5zDk2XQlSuEcz/lAOWBvZq9Clr92UpGOjy1aJ?= =?us-ascii?Q?xEGCcZwtjJDdwzuH6uH2/4wtnhSWJ4RdZUr16x3EX6I6SG8qAdhkRnb2uNKY?= =?us-ascii?Q?XgTj/hKIyDMNh+C6EJEn94yqEferX6NRJSnc7pKzpVB0IniC1hiiXO5mWDpD?= =?us-ascii?Q?LHD9GJ9LntX/vR8pPtzT76N7qd+U8B3XAAFhKANI/nM2hnbc8U9toKRj8+ZQ?= =?us-ascii?Q?HsCL5QZU/CjomOFrCLdxw5BYTmiVCQvSsN9xoy3bvqnxDCTBJtkeUHJ9eQAK?= =?us-ascii?Q?KISiHT2Dy6AoDbZ8ekIcDMr0PtC4mrMPdM75BCjLwzqTmAYss4rMRCvX28nc?= =?us-ascii?Q?XRcVu8GX+Ad6aqJfilLdadfowqnP7VUaAydGiVeCLkiIVVLx0Wzj0U1BMO31?= =?us-ascii?Q?9KJNHKRPTHfHlJT4JimxkVx2adSLrlq2U1Wefp7RIwPSVqn+QOgold1Vc2hP?= =?us-ascii?Q?Fk7bVKho186z4dwvnCBNzLlBnxbH26e40C0XVUIGs0TfPH57TLO1YOhudGJd?= =?us-ascii?Q?EEdvRaQBCigsDnxpb2ucFtukqJ/9FrfLk7lDyzrJ9Fm4EciYEMYUs8R13FOa?= =?us-ascii?Q?Ae6atQIFr4FHjGsf569z/knyxpSmuG6dYGEw6kTz8DqA6uKWcrMwApBQ6KFa?= =?us-ascii?Q?NcfcZ/oW9FOiTyViW8j7NZNUAZcSKw5U3lD1GVK7xFKmVlO3hZpyokm7OIj1?= =?us-ascii?Q?ylDGz1SPXp/FXRx48V7cXMr57IBCQGJoBGSWHjhRnFCV4EGjswoLrqGGubJN?= =?us-ascii?Q?1dPzTYG4tnZ3F6uJill3WIIUzEmM28j4e6eHPm0DimEWL27i32YcWg07hsqg?= =?us-ascii?Q?c74=3D?= 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: MN2PR12MB2909.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d14e836a-11de-4a66-6138-08d90103fabc X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2021 18:18:05.2165 (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: +2cUtsr5rW/jZVZ9Z9fi0VbcrrGH9oi2rIHniuoGGZt1MVovpo9jm/kYtFJUxNmqYddU4/hUehUYvf/qAqTLug== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB2957 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 Thomas, Thanks for your comments. Almost all the comments are addressed. PSB. > -----Original Message----- > From: Thomas Monjalon > Sent: Friday, April 16, 2021 6:50 PM > To: Bing Zhao > Cc: Ori Kam ; ferruh.yigit@intel.com; > andrew.rybchenko@oktetlabs.ru; dev@dpdk.org; > ajit.khaparde@broadcom.com; jerinj@marvell.com; humin29@huawei.com; > rosen.xu@intel.com; hemant.agrawal@nxp.com > Subject: Re: [dpdk-dev] [PATCH v2 1/2] ethdev: introduce conntrack > flow action and item >=20 > External email: Use caution opening links or attachments >=20 >=20 > 15/04/2021 18:41, Bing Zhao: > > This commit introduced the conntrack action and item. > > > > 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. > > > > 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 > You probably mean "flow rule", not "traffic flow". > Please make it clear to avoid confusion. Done >=20 > > A TCP connection has two directions traffic. To set a conntrack > action > > context correctly, information from packets of both directions are > > required. > > > > 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 > I am not sure this is a feature description for the commit log or an > usage explanation for the doc. > In any case, please distinguish "ethdev port" and "TCP port" > to avoid confusion. Changed, thanks. >=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. > > > > For the packets received during the conntrack setup, it is > suggested > > to re-inject the packets in order to take full advantage of the >=20 > What do you mean by "full advantage"? > It is counter-intuitive to re-inject for offloading. > Does it improve the performance? No, it is not for the performance but for the functionality correctness. Be= fore the CT established, some data+ack packets may already be received by t= he SW, and the application will use the initial information to setup a conn= track. It may result into some error checking for the following packets. By= re-injecting the packets already received by SW before the established CT,= it will make the HW have all the packets information and check the followi= ng packets correctly. >=20 > > 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. > > > > Naming and definition: >=20 > You mean naming is inspired from Linux? The naming and critical fields definition. The original idea are from the p= aper listed below (correct me if I was wrong), and there is some well-known= definition in this area, to my understanding, it would be better to follow= it. >=20 > > > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fel > ix > > > ir.bootlin.com%2Flinux%2Flatest%2Fsource%2Finclude%2Fuapi%2Flinux%2F > ne > > > tfilter%2Fnf_conntrack_tcp.h&data=3D04%7C01%7Cbingz%40nvidia.com%7 > Ca > > > d68b128653e4428da6e08d900c56373%7C43083d15727340c1b7db39efd9ccc17a%7 > C0 > > %7C1%7C637541670056627642%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw > MDAi > > > LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DkCn9 > kF > > bi7yWrd7A94zFibvQEB97phXXUudSA%2BhAueTU%3D&reserved=3D0 > > > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fel > ix > > > ir.bootlin.com%2Flinux%2Flatest%2Fsource%2Fnet%2Fnetfilter%2Fnf_conn > tr > > > ack_proto_tcp.c&data=3D04%7C01%7Cbingz%40nvidia.com%7Cad68b128653e > 44 > > > 28da6e08d900c56373%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C1%7C6375 > 41 > > > 670056627642%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l > uM > > > zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DAjs9NtCaEpG2Kfnjy > t5 > > X8uwOFo2HyfMdWZbx%2BHkbvX8%3D&reserved=3D0 > > > > Other reference: > > > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww > w. > > > usenix.org%2Flegacy%2Fevents%2Fsec01%2Finvitedtalks%2Frooij.pdf& > da > > > ta=3D04%7C01%7Cbingz%40nvidia.com%7Cad68b128653e4428da6e08d900c56373%7 > C4 > > > 3083d15727340c1b7db39efd9ccc17a%7C0%7C1%7C637541670056627642%7CUnkno > wn > > %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw > iLCJ > > > XVCI6Mn0%3D%7C1000&sdata=3D987HVU%2FefoJ40%2B6aM0Q1RVxcGH5nVJS4bzy > 4A > > 4ZoYSE%3D&reserved=3D0 > > > > Signed-off-by: Bing Zhao > [...] > > + /** > > + * [META] > > + * > > + * Matches conntrack state. > > + * > > + * See struct rte_flow_item_conntrack. >=20 > Please use @see for hyperlink in doxygen. >=20 > > + */ > > + RTE_FLOW_ITEM_TYPE_CONNTRACK, > > }; > [...] > > +/** > > + * The packet is with valid state after conntrack checking. >=20 > "is with valid state" looks strange. > I propose "The packet is valid after conntrack checking." Done >=20 > > + */ > > +#define RTE_FLOW_CONNTRACK_FLAG_PKT_STATE_VALID (1 << 0) >=20 > Please use RTE_BIT32(). Done >=20 > > +/** > > + * 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) >=20 > "INVAL" is strange. Can we add the missing 2 characters? > RTE_FLOW_CONNTRACK_FLAG_PKT_STATE_INVALID >=20 > On a related note, do we really need the word FLAG? > And it is conflicting with the prefix in enum > rte_flow_conntrack_tcp_last_index I think > RTE_FLOW_CONNTRACK_PKT_STATE_ is a good prefix, long enough. >=20 Done > > +/** > > + * 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) >=20 > This one does not have PKT in its name. > And it is limiting to HW, while the driver could implement conntrack > in SW. > I propose RTE_FLOW_CONNTRACK_PKT_DISABLED >=20 Done > > +/** > > + * 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* >=20 > s/bit mask/bitmap/ ? Done >=20 > RTE_FLOW_CONNTRACK_PKT_STATE_* > otherwise it is messed with rte_flow_conntrack_tcp_last_index >=20 > > + * or a reasonable combination of these bits. > > + */ > > +struct rte_flow_item_conntrack { > > + uint32_t flags; > > +}; > [...] > > + > > + /** > > + * [META] > > + * > > + * Enable tracking a TCP connection state. > > + * > > + * Send packet to HW connection tracking module for > examination. >=20 > Not necessarily HW. > No packet is sent. > I think you can remove this sentence completely. >=20 Done > > + * > > + * See struct rte_flow_action_conntrack. >=20 > @see >=20 > > + */ > > + RTE_FLOW_ACTION_TYPE_CONNTRACK, > > }; > > > > /** > > @@ -2875,6 +2940,136 @@ struct rte_flow_action_set_dscp { > > */ > > struct rte_flow_action_handle; > > > > +/** > > + * 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. */ >=20 > s/handshark/handshake/ >=20 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. > */ > > +}; >=20 > Please use RTE_BIT32(). >=20 Done > > +/** > > + * @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. */ >=20 > Move all comments on their own line before the struct member. > Comment should then start with /** >=20 All done, BTW, I see in the current code, the format "/**<" is used in a lo= t of parts. > > + uint32_t last_ack_seen:1; > > + /**< If set, indicates that there is unacked data of the > > + connection. */ >=20 > not sure what means "unacked data of the connection" Updated the description, it means some packets were sent but not all of the= m are ACKed. >=20 > > + 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; > > + /**< Maximal value of actual window size over sent packets. > */ > > + uint32_t max_win; > > + /**< Maximal value of ACK over sent packets. */ > > + uint32_t max_ack; >=20 > Not sure about the word "over" in above definitions. Changed to "in" >=20 > > +}; > > + > > +/** > > + * @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. > > + */ >=20 > As for rte_flow_tcp_dir_param, better to move comments before, on > their own line. >=20 > > + 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. > > +*/ }; >=20 >=20 Thanks