From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f67.google.com (mail-wm0-f67.google.com [74.125.82.67]) by dpdk.org (Postfix) with ESMTP id E64861B471 for ; Thu, 12 Jul 2018 12:46:52 +0200 (CEST) Received: by mail-wm0-f67.google.com with SMTP id z13-v6so5533604wma.5 for ; Thu, 12 Jul 2018 03:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=uywFbrAmqhFkD6z/KEH3NNQuHjwnQuXJFxDRpF9PsOY=; b=G9DeDQW9K4Fm4Hxv4mj7tKMlZR+29QZg/+bSVmhKs4XPTj2WjMjc9fGzUO+GIYL5GS vi3j1UP3Flf4rlCjKpuHkK09OTqXoBpadnr5QKfk7iHt/k3hshSw4DCBJPWFVh6uTtEi p1JIrE99SIyzfdJ3nbpfQcPoHSfNuEtd7e8L+pSNT4nXebs1LFY51hHI4lRat2i/oRsI Irs8Cob1mCUUQoB3azyFSD0gGVYT+rC59J20wweXwQg5agWtxwgUwAopF1puCcg/NdRe VFldUHtu97VEulO/CNBEZiBZIAzvVG3sAr3JvnstbD5WfPOCl/2QeDClDpK3UvmRQGyX Drjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=uywFbrAmqhFkD6z/KEH3NNQuHjwnQuXJFxDRpF9PsOY=; b=I6pwqWoYhL9hI15odzTJCjEYrRP7to0GnYh5mpwE/8YK2iqFqI8oi4Z9lJw0up0ozp t3ISktoNk/7GW0OdyeTlVJde9EuKRW+kjuGj30HyxUgiu8TmperNFPeJSLHK3LDcwpux cLoXXAkySpZlAkvHAoLegw6GpMJGYTL16Y6f+ARJor0Xli0qitTj6PiR3bKRW37nVfNs K2IDHJNnkt04NYtTbaU4N9SHPEYuMBlYcUrdzpTNVpd9gJXSE0OzeHd85p333ONtR88W aocYPFwpw3YSoyq7aI4nA3YzVNYCHMNsnwuCeenNg+eE0LAwrz9jGcue0EFU7hTDFFLl X75w== X-Gm-Message-State: AOUpUlHVM+3PRk/Xjs6ywRQfkbWtolF++Bm2OdaLvNVaXjh6XVlmD+7e rUPlmaBSHWLQ9ypP+mnQCxfTpnxk X-Google-Smtp-Source: AAOMgpcKQAfOvNnqYXpUblT0MuS5PO7XjFJUSCT3j1/9ZrG9KhRFvZzowC3XqrmY2QlF9n5bTW0E8g== X-Received: by 2002:a1c:a8d6:: with SMTP id r205-v6mr1005195wme.6.1531392412706; Thu, 12 Jul 2018 03:46:52 -0700 (PDT) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id f2-v6sm20696125wre.16.2018.07.12.03.46.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jul 2018 03:46:51 -0700 (PDT) Date: Thu, 12 Jul 2018 12:46:35 +0200 From: Adrien Mazarguil To: Yongseok Koh Cc: Shahaf Shuler , Nelio Laranjeiro , dev@dpdk.org Message-ID: <20180712104635.GS5211@6wind.com> References: <20180627173355.4718-1-adrien.mazarguil@6wind.com> <20180627173355.4718-2-adrien.mazarguil@6wind.com> <20180712001652.GC69686@yongseok-MBP.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180712001652.GC69686@yongseok-MBP.local> 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 10:46:53 -0000 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 traffic > > emitted and received by the application, those targeting different logical > > ports of the device (VF representors for instance) are offloaded at the > > switch level and must be configured through Netlink (TC interface). > > > > This patch adds preliminary support to manage such flow rules through the > > flow API (rte_flow). > > > > Instead of rewriting tons of Netlink helpers and as previously suggested by > > Stephen [1], this patch introduces a new dependency to libmnl [2] > > (LGPL-2.1) when compiling mlx5. > > > > [1] https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmails.dpdk.org%2Farchives%2Fdev%2F2018-March%2F092676.html&data=02%7C01%7Cyskoh%40mellanox.com%7C1250093eca0c4ad6d9f008d5dc58fbb4%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636657197116524482&sdata=JrAyzK1s3JG5CnuquNcA7XRN4d2WYtHUi1KXyloGdvA%3D&reserved=0 > > [2] https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnetfilter.org%2Fprojects%2Flibmnl%2F&data=02%7C01%7Cyskoh%40mellanox.com%7C1250093eca0c4ad6d9f008d5dc58fbb4%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636657197116524482&sdata=yLYa0NzsTyE62BHDCZDoDah31snt6w4Coq47pY913Oo%3D&reserved=0 > > > > 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 before > > + * sending. > > + * > > + * @return > > + * 0 on success, a negative errno value otherwise and rte_errno is set. > > + */ > > +static int > > +mlx5_nl_flow_nl_ack(struct mnl_socket *nl, struct nlmsghdr *nlh) > > +{ > > + alignas(struct nlmsghdr) > > + uint8_t ans[MNL_SOCKET_BUFFER_SIZE]; > > There are total 3 of this buffer. On a certain host having large pagesize, this > can be 8kB * 3 = 24kB. This is not a gigantic buffer but as all the functions > here are sequentially accessed, how about having just one global buffer instead? All right it's not ideal, I opted for simplicity though. This is a generic 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 more space than the original message, which may itself be huge, and failure to receive acks is deemed fatal. 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. These last two are called often but do not put their own buffer on the stack, they reuse previously generated messages from the heap. 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 allocate it locally since it would be a pain otherwise. Callers may not want their own buffers to be overwritten with useless acks. -- Adrien Mazarguil 6WIND