From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10074.outbound.protection.outlook.com [40.107.1.74]) by dpdk.org (Postfix) with ESMTP id 3C2F41B3A1 for ; Thu, 12 Jul 2018 19:33:17 +0200 (CEST) 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=DO7czj0WPMsqH9uFIGTtaXAD8iLanxt5XoPqVia8tPA=; b=vABAl0MVYbdSb7tEKH+24VFBVf+RauZhCbaKMn2nVHBegT+U2V6GSthptZtE3q8w+DWGumv4+fEMDqvGpyiVbKMdT4sGxP3yYXWNdVDqTeuBTms70xv9wzmeat3kw7PRVyLskTR3ZJJ9KI3N3N3EjVhF4V5dhq+7G7PDWEMThkg= Received: from VI1PR0501MB2045.eurprd05.prod.outlook.com (10.167.195.147) by VI1PR0501MB2815.eurprd05.prod.outlook.com (10.172.11.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.18; Thu, 12 Jul 2018 17:33:15 +0000 Received: from VI1PR0501MB2045.eurprd05.prod.outlook.com ([fe80::89c3:2b8e:5cea:4a0b]) by VI1PR0501MB2045.eurprd05.prod.outlook.com ([fe80::89c3:2b8e:5cea:4a0b%6]) with mapi id 15.20.0952.017; Thu, 12 Jul 2018 17:33:15 +0000 From: Yongseok Koh To: Adrien Mazarguil CC: Shahaf Shuler , =?iso-8859-1?Q?N=E9lio_Laranjeiro?= , "dev@dpdk.org" Thread-Topic: [PATCH 1/6] net/mlx5: lay groundwork for switch offloads Thread-Index: AQHUDn3CTAFdmiPHXESdPU7rmxVxVqSKWQGAgAElOICAAHGeAA== Date: Thu, 12 Jul 2018 17:33:15 +0000 Message-ID: <41469C70-A49D-4929-98B8-936FB1F015AB@mellanox.com> References: <20180627173355.4718-1-adrien.mazarguil@6wind.com> <20180627173355.4718-2-adrien.mazarguil@6wind.com> <20180712001652.GC69686@yongseok-MBP.local> <20180712104635.GS5211@6wind.com> In-Reply-To: <20180712104635.GS5211@6wind.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: [209.116.155.178] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0501MB2815; 7:9bxdwPBC1twV4Y6cEwe92LCWJrVoY3zvGGeRImmYS9w38KjhQmFE7diHnZJDoUnnKrH0YgCYhqN8z8uUZody/Xk8JES1iQsaa5nG5KtQgcZlhqk+8WnLEAoaGdViU/xwJQRsD+AOoxzCU768RKuabX4sQg1r4q/EAKD1KgnFE4MUGzPg/Rd1dw5pYvHKkMznfA0KlTSKwmgfd7+nNJAOjccNiqau4TenppDUOIAz0r26MKvKU0W5xp5r63EkGahZ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 03fe9228-7f57-440a-9fc0-08d5e81d8c85 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0501MB2815; x-ms-traffictypediagnostic: VI1PR0501MB2815: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078)(45079756050767); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231311)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0501MB2815; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0501MB2815; x-forefront-prvs: 0731AA2DE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(39860400002)(366004)(376002)(346002)(199004)(189003)(97736004)(14444005)(476003)(53936002)(86362001)(575784001)(26005)(446003)(486006)(45080400002)(6506007)(83716003)(53546011)(305945005)(11346002)(2616005)(4326008)(2906002)(68736007)(186003)(25786009)(6246003)(256004)(478600001)(966005)(76176011)(102836004)(316002)(2900100001)(81156014)(6512007)(54906003)(6306002)(81166006)(66066001)(8936002)(6436002)(6486002)(36756003)(3846002)(229853002)(14454004)(99286004)(106356001)(105586002)(7736002)(93886005)(6116002)(33656002)(82746002)(8676002)(5660300001)(6916009)(5250100002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0501MB2815; H:VI1PR0501MB2045.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: V1Mc86UEX9mSuGHAIr97Chc8VeMfimlmNstltwh5gglCmZhVC4G9A9hk++0TJm67zQN10PlYC5/dPML10LXti3UOtKe6qsTm2QdNDfg9IxyGJPcNL/fKQcbG9mc8bkM/CrjWbgC4Wu+ZzdrQD5yKwo1kmGGJxOjC/73+wo0MVhcYVFJFSi9Qu7YMPcNbRf0rBcw6/uaentCXD/bNgUAamqHNbzG4uRNe69tgr0hOTZ1QgtPdYao/VR4X4Vvxl2+XNaeqfT2wB4+JDs8csTtAJiAOoTAsp1odxrB3pYQRTduL5hj2+9U45OzwyDPDqBRlo7GPumK6vJgA6E9bqEIly5q+HJbBLTuNW+c3TlsQRPg= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: 03fe9228-7f57-440a-9fc0-08d5e81d8c85 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2018 17:33:15.0555 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0501MB2815 Subject: Re: [dpdk-dev] [PATCH 1/6] net/mlx5: lay groundwork for switch offloads 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: Thu, 12 Jul 2018 17:33:17 -0000 > On Jul 12, 2018, at 3:46 AM, Adrien Mazarguil wrote: >=20 > On Wed, Jul 11, 2018 at 05:17:09PM -0700, Yongseok Koh wrote: >> On Wed, Jun 27, 2018 at 08:08:10PM +0200, Adrien Mazarguil wrote: >>> With mlx5, unlike normal flow rules implemented through Verbs for traff= ic >>> emitted and received by the application, those targeting different logi= cal >>> ports of the device (VF representors for instance) are offloaded at the >>> switch level and must be configured through Netlink (TC interface). >>>=20 >>> This patch adds preliminary support to manage such flow rules through t= he >>> flow API (rte_flow). >>>=20 >>> Instead of rewriting tons of Netlink helpers and as previously suggeste= d by >>> Stephen [1], this patch introduces a new dependency to libmnl [2] >>> (LGPL-2.1) when compiling mlx5. >>>=20 >>> [1] https://emea01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%= 2Fmails.dpdk.org%2Farchives%2Fdev%2F2018-March%2F092676.html&data=3D02%7C01= %7Cyskoh%40mellanox.com%7C1250093eca0c4ad6d9f008d5dc58fbb4%7Ca652971c7d2e4d= 9ba6a4d149256f461b%7C0%7C0%7C636657197116524482&sdata=3DJrAyzK1s3JG5CnuquNc= A7XRN4d2WYtHUi1KXyloGdvA%3D&reserved=3D0 >>> [2] https://emea01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%= 2Fnetfilter.org%2Fprojects%2Flibmnl%2F&data=3D02%7C01%7Cyskoh%40mellanox.co= m%7C1250093eca0c4ad6d9f008d5dc58fbb4%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0= %7C0%7C636657197116524482&sdata=3DyLYa0NzsTyE62BHDCZDoDah31snt6w4Coq47pY913= Oo%3D&reserved=3D0 >>>=20 >>> Signed-off-by: Adrien Mazarguil > >>> diff --git a/drivers/net/mlx5/mlx5_nl_flow.c b/drivers/net/mlx5/mlx5_nl= _flow.c >>> new file mode 100644 >>> index 000000000..7a8683b03 >>> --- /dev/null >>> +++ b/drivers/net/mlx5/mlx5_nl_flow.c >>> @@ -0,0 +1,139 @@ >>> +/* SPDX-License-Identifier: BSD-3-Clause >>> + * Copyright 2018 6WIND S.A. >>> + * Copyright 2018 Mellanox Technologies, Ltd >>> + */ >>> + >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> + >>> +#include >>> +#include >>> + >>> +#include "mlx5.h" >>> + >>> +/** >>> + * Send Netlink message with acknowledgment. >>> + * >>> + * @param nl >>> + * Libmnl socket to use. >>> + * @param nlh >>> + * Message to send. This function always raises the NLM_F_ACK flag b= efore >>> + * sending. >>> + * >>> + * @return >>> + * 0 on success, a negative errno value otherwise and rte_errno is s= et. >>> + */ >>> +static int >>> +mlx5_nl_flow_nl_ack(struct mnl_socket *nl, struct nlmsghdr *nlh) >>> +{ >>> + alignas(struct nlmsghdr) >>> + uint8_t ans[MNL_SOCKET_BUFFER_SIZE]; >>=20 >> There are total 3 of this buffer. On a certain host having large pagesiz= e, this >> can be 8kB * 3 =3D 24kB. This is not a gigantic buffer but as all the fu= nctions >> here are sequentially accessed, how about having just one global buffer = instead? >=20 > All right it's not ideal, I opted for simplicity though. This is a generi= c > ack function. When NETLINK_CAP_ACK is not supported (note: this was made > optional for v2, some systems do not support it), an ack consumes a bit m= ore > space than the original message, which may itself be huge, and failure to > receive acks is deemed fatal. >=20 > Its callers are mlx5_nl_flow_init(), called once per device during > initialization, and mlx5_nl_flow_create/destroy(), called for each > created/removed flow rule. >=20 > These last two are called often but do not put their own buffer on the > stack, they reuse previously generated messages from the heap. >=20 > So to improve stack consumption a bit, what I can do is size this buffer > according to nlh->nlmsg_len + extra room for ack header, yet still alloca= te > it locally since it would be a pain otherwise. Callers may not want their > own buffers to be overwritten with useless acks. I like this approach. Thanks, Yongseok