From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00060.outbound.protection.outlook.com [40.107.0.60]) by dpdk.org (Postfix) with ESMTP id 4970C4CAF for ; Sun, 11 Nov 2018 12:41:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gHmHf3vu7Ly2JfBrp4aY6NE1G5J3DWqa5nyEW3DI4Yg=; b=JyIMaV44ZH/qB4D7kLu9nqaftfCdakjy537hXRQmjSQ9rnrCAcbdk3MWm98IpFPpwBL4F5Y9n/N1DWuMWa4kz6GZuooTyoPtQtla+JMm6FDnLaCg1LlX5jU+JFuM4/l2+bm5bCh4eRJ2MqxQHYjemPbiRLFjUC1eT9OrDdrkJ1w= Received: from DB3PR0502MB3980.eurprd05.prod.outlook.com (52.134.72.27) by DB3PR0502MB4041.eurprd05.prod.outlook.com (52.134.66.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.29; Sun, 11 Nov 2018 11:41:33 +0000 Received: from DB3PR0502MB3980.eurprd05.prod.outlook.com ([fe80::58e7:97d8:f9c1:4323]) by DB3PR0502MB3980.eurprd05.prod.outlook.com ([fe80::58e7:97d8:f9c1:4323%3]) with mapi id 15.20.1294.044; Sun, 11 Nov 2018 11:41:33 +0000 From: Yongseok Koh To: Slava Ovsiienko CC: Shahaf Shuler , "dev@dpdk.org" Thread-Topic: [PATCH 3/3] net/mlx5: fix rule cleanup Netlink command sending Thread-Index: AQHUeNwRrWzhqIHNbECEveOZMdqN9aVKdUMA Date: Sun, 11 Nov 2018 11:41:33 +0000 Message-ID: <9DE1F3C9-D4C0-45B7-9B8C-DA9D80C53FC2@mellanox.com> References: <1541843951-31708-1-git-send-email-viacheslavo@mellanox.com> <1541843951-31708-4-git-send-email-viacheslavo@mellanox.com> In-Reply-To: <1541843951-31708-4-git-send-email-viacheslavo@mellanox.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=yskoh@mellanox.com; x-originating-ip: [69.181.245.183] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR0502MB4041; 6:YXejdH94pkQgX9obkidgIUNFKaR/wZC28Ib4TT75eqMcq35eaxSTPWbEIovYD54CXDk0aU7ZdvhL60niPVp4WDbDfa4tvMrsVwkBfZ0kKmFCA5KC9eDha/9xf6oan0o1gTdm/ycIbuanpHRWwUiLGmdd7QtKils/8CwygpEQE6JAA0kfxL/f3Z0c5yI3Za6Ey02ziok+bjuObTcvP83m96phFPQXA7t/8yYreOA60bs+Plqx5jhFR2SvZKORkOvbarwJdnrOugnlP9/p2t6Ne5TQfCkTrmwnPQhfdWk5dVK5HBXBnupJ7k8DiUYgvCTVZ8LUjRAcVTYBKdQHUa8IZbs06BY6egLR3jKd4LIrFMiCZbbBBp4u88HPDscYBr3+OJyCKdzIeTrQ3lyBQ17zFjwFKRZO0sTza+shAWcLq8M4AFop8mGd4GyMxIZgFFx0pYe3n8ELOC2p9bwNU+It/A==; 5:W8gj52f34+AytatrNYrXg/rLCNv4gShb9Nim1o1QLdcRlT4lMAKAZ8omzAwkhjsoBvuiBNf0WNcLItqb/9mYu2doSe5ti7JUt18fQ2tukoWOa946QpvMwBSs7g5Gd+Ff3h/KlDLw8cm45XwRSiiE+/j1rkJpiJvzuNhhtOI9aFo=; 7:xanpMFzaooya2MmLn6kt/vUm6I89p7ijNfkU2d/DNpuCEyC8gGd87qC50Yk4umventouyJKPH0l0+dMiYYMDK2FRBg7pN6w51AGOVVY3t0OrxI6hAV4H5GlwnabjFRVgWhE2Jvk536QpFreBh3NPDA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 181f28f6-6c07-43e7-2497-08d647caa174 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390040)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DB3PR0502MB4041; x-ms-traffictypediagnostic: DB3PR0502MB4041: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(3231382)(944501410)(52105112)(10201501046)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:DB3PR0502MB4041; BCL:0; PCL:0; RULEID:; SRVR:DB3PR0502MB4041; x-forefront-prvs: 08534B37A7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(396003)(376002)(346002)(136003)(189003)(199004)(26005)(6506007)(486006)(54906003)(82746002)(68736007)(8936002)(53546011)(6862004)(83716004)(36756003)(6636002)(37006003)(86362001)(71190400001)(53936002)(229853002)(478600001)(446003)(66066001)(186003)(71200400001)(5660300001)(33656002)(97736004)(2900100001)(2906002)(76176011)(476003)(305945005)(6116002)(14444005)(2616005)(3846002)(6512007)(316002)(14454004)(81156014)(81166006)(102836004)(6246003)(105586002)(4326008)(25786009)(8676002)(6486002)(99286004)(256004)(6436002)(11346002)(7736002)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR0502MB4041; H:DB3PR0502MB3980.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: vxvJ89o3Dakx9mnrnbRW3a+91EvImFGAfyf8/vtMyCnWySF03Fw6/6dhyztzIvR2aLkUIIAYvP7xRJEEXyDEldnG2m4yOprqqQVskLEw/Un1ZBdQ8HuWWsAjaWFyTsQxag719tz2ImDD3g8yWlaUUwi3b21G0V/KJv0jbtyfglNT6NfuOCt3PFMJbFoi5ZuttCTooNOKOemP4sfJzbN9RGTksmzW05MpLmm/LxMupnJGkRYpIQRxrnb/WRjQ0UJZEpalHlDukJHsR+UItMBgKV/MQ7bIyPvm6Ta/e4C5aXeU1zp7KRVKq/ecSHQKAXO+XWwPpff6y/FW1B6a3KRnC6cPqc6CpkXQ/PH87sLHlGE= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: 181f28f6-6c07-43e7-2497-08d647caa174 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2018 11:41:33.6431 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR0502MB4041 Subject: Re: [dpdk-dev] [PATCH 3/3] net/mlx5: fix rule cleanup Netlink command sending X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2018 11:41:35 -0000 > On Nov 10, 2018, at 1:59 AM, Slava Ovsiienko w= rote: >=20 > The VXLAN related rule cleanup routine queries and gathers all > existing local IP and neigh rules into buffer list. One buffer > may contain multiple rule deletetion commands and is prepared > to send into Netlink as single message. But, if error occurs > for some deletion commands in the buffer, the multiple ACK > message with errors can be send back by the kernel. It breaks > the Netlink communication sequence numbers, because we expect > only one ACK message and it smashes out futher Netlik > communication. Just curious. Is parsing the multiple ack msgs more complex than sending commands one by one? > The workaround of this problem is to send rule deletion commands > from buffer in one-by-one fashion and get ACK message for every > command sent. We do not expect too may rules preexist, so there > should not be critical performance degradation at VXLAN outer > interface initialization. >=20 > Fixes: f420f03d6772 ("net/mlx5: add E-switch VXLAN rule cleanup routines"= ) >=20 > Signed-off-by: Viacheslav Ovsiienko > --- Acked-by: Yongseok Koh =20 Thanks > drivers/net/mlx5/mlx5_flow_tcf.c | 58 +++++++++++++++++------------------= ----- > 1 file changed, 24 insertions(+), 34 deletions(-) >=20 > diff --git a/drivers/net/mlx5/mlx5_flow_tcf.c b/drivers/net/mlx5/mlx5_flo= w_tcf.c > index bba8aed..21eb99e 100644 > --- a/drivers/net/mlx5/mlx5_flow_tcf.c > +++ b/drivers/net/mlx5/mlx5_flow_tcf.c > @@ -3847,30 +3847,6 @@ struct tcf_nlcb_context { > } >=20 > /** > - * Set NLM_F_ACK flags in the last netlink command in buffer. > - * Only last command in the buffer will be acked by system. > - * > - * @param[in, out] buf > - * Pointer to buffer with netlink commands. > - */ > -static void > -flow_tcf_setack_nlcmd(struct tcf_nlcb_buf *buf) > -{ > - struct nlmsghdr *nlh; > - uint32_t size =3D 0; > - > - assert(buf->size); > - do { > - nlh =3D (struct nlmsghdr *)&buf->msg[size]; > - size +=3D NLMSG_ALIGN(nlh->nlmsg_len); > - if (size >=3D buf->size) { > - nlh->nlmsg_flags |=3D NLM_F_ACK; > - break; > - } > - } while (true); > -} > - > -/** > * Send the buffers with prepared netlink commands. Scans the list and > * sends all found buffers. Buffers are sent and freed anyway in order > * to prevent memory leakage if some every message in received packet. > @@ -3888,21 +3864,35 @@ struct tcf_nlcb_context { > flow_tcf_send_nlcmd(struct mlx5_flow_tcf_context *tcf, > struct tcf_nlcb_context *ctx) > { > - struct tcf_nlcb_buf *bc, *bn; > - struct nlmsghdr *nlh; > + struct tcf_nlcb_buf *bc =3D LIST_FIRST(&ctx->nlbuf); > int ret =3D 0; >=20 > - bc =3D LIST_FIRST(&ctx->nlbuf); > while (bc) { > + struct tcf_nlcb_buf *bn =3D LIST_NEXT(bc, next); > + struct nlmsghdr *nlh; > + uint32_t msg =3D 0; > int rc; >=20 > - bn =3D LIST_NEXT(bc, next); > - if (bc->size) { > - flow_tcf_setack_nlcmd(bc); > - nlh =3D (struct nlmsghdr *)&bc->msg; > - rc =3D flow_tcf_nl_ack(tcf, nlh, bc->size, NULL, NULL); > - if (rc && !ret) > - ret =3D rc; > + while (msg < bc->size) { > + /* > + * Send Netlink commands from buffer in one by one > + * fashion. If we send multiple rule deletion commands > + * in one Netlink message and some error occurs it may > + * cause multiple ACK error messages and break sequence > + * numbers of Netlink communication, because we expect > + * the only one ACK reply. > + */ > + assert((bc->size - msg) >=3D sizeof(struct nlmsghdr)); > + nlh =3D (struct nlmsghdr *)&bc->msg[msg]; > + assert((bc->size - msg) >=3D nlh->nlmsg_len); > + msg +=3D nlh->nlmsg_len; > + rc =3D flow_tcf_nl_ack(tcf, nlh, 0, NULL, NULL); > + if (rc) { > + DRV_LOG(WARNING, > + "netlink: cleanup error %d", rc); > + if (!ret) > + ret =3D rc; > + } > } > rte_free(bc); > bc =3D bn; > --=20 > 1.8.3.1 >=20