From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8AC64A04F0; Fri, 27 Dec 2019 09:59:50 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 835301BFF7; Fri, 27 Dec 2019 09:59:49 +0100 (CET) Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by dpdk.org (Postfix) with ESMTP id 06D711BFF1 for ; Fri, 27 Dec 2019 09:59:47 +0100 (CET) Received: by mail-wr1-f68.google.com with SMTP id g17so25507316wro.2 for ; Fri, 27 Dec 2019 00:59:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=AfoXB2K/oGPGAV1m0QNqhvz6yEPrp5hToIEMrGkheA8=; b=FFJFYNSv3u5oHhAD/RZF9mhYoXIAvL1bCBLPjrygML4DRdU7BWRHIaSWPILEAu30eI oTR9J+A/rkh51AtarS6WLVfYLck4auz/6rXOLXuI768J7XVyrjXxGW7RCLHTUrXGLcqy YZ6ekj/dpk+WO/nL5wLZLcBUHhRLnfTUC6bTeK+CJJCPJU+bIcx4qHyQWTzDgUIZrggh lfvIZsjhnUYS/p20YMgVZyx6ooeMkmQ32QMqeAFpE+jxToRpJg0sVv+BevSq2U3bvfbE yEfUDSDq9OtI37c8mYjPs0JB2q5NqNGpI2DuZBmdmkICs8CrqmC6+XcbXFNRBK1dx4iA ZUTQ== 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:user-agent; bh=AfoXB2K/oGPGAV1m0QNqhvz6yEPrp5hToIEMrGkheA8=; b=ZuxTOLvDbMtXucxEouSL7x7AhFFLwyt6IRqvZRHvPvj/87vdvqk93+WP4zLwE8KvuB OuET/k/qEm4qXdeqd0nSnTJ7v9XfQPsen/3u7TwHw6PnOQh6kBHHKB0la2Q8zWCHOoLM SHNOsqoBNq41dDC8XkRy+vEqLU92JBY8Y56QWWC3YHaW8g/0//GdDKxiBs7CWjsyl1IE QMzn887NF/8GHj8WugwQpDcSjZuVROKUnlxB3kA+jrXzidfqXafIkkvBBYXAxpV4aYV1 Bh2VYifnYl05cUpXIsmPvRMWtsRmebPx2CqvsM7jj0PpPJmWRNT4ngzq7esi2xsafgtI KqkQ== X-Gm-Message-State: APjAAAX2EHCzfThIO4YR0mWDi3g50wrAn+d6c23LDIrl3Ch0zTsnGeCD Z9LvUjVdIx65wBmd5NtfNMkkHg== X-Google-Smtp-Source: APXvYqxXtJiW7krYyuhymlqheIcxdtkPo3XH5hId9UycVUoNozGxn3H5B3zRQsI5Fp+tluJJIed4PA== X-Received: by 2002:a5d:5308:: with SMTP id e8mr49440432wrv.77.1577437187638; Fri, 27 Dec 2019 00:59:47 -0800 (PST) Received: from 6wind.com (2a01cb0c0005a600345636f7e65ed1a0.ipv6.abo.wanadoo.fr. [2a01:cb0c:5:a600:3456:36f7:e65e:d1a0]) by smtp.gmail.com with ESMTPSA id a1sm33490873wrr.80.2019.12.27.00.59.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Dec 2019 00:59:46 -0800 (PST) Date: Fri, 27 Dec 2019 09:59:46 +0100 From: Olivier Matz To: Viacheslav Ovsiienko Cc: dev@dpdk.org, shahafs@mellanox.com, matan@mellanox.com, rasland@mellanox.com, thomas@monjalon.net, orika@mellanox.com Message-ID: <20191227085946.GM22738@platinum> References: <20191017072723.36509-1-shahafs@mellanox.com> <1576083693-26199-1-git-send-email-viacheslavo@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1576083693-26199-1-git-send-email-viacheslavo@mellanox.com> User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [dpdk-dev] [RFC v2] mlx5/net: hint PMD not to inline packet 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Viacheslav, On Wed, Dec 11, 2019 at 05:01:33PM +0000, Viacheslav Ovsiienko wrote: > Some PMDs inline the mbuf data buffer directly to device transmit descriptor. > This is in order to save the overhead of the PCI headers imposed when the > device DMA reads the data by buffer pointer. For some devices it is essential > in order to provide the full bandwidth. > > However, there are cases where such inlining is in-efficient. For example, when > the data buffer resides on other device memory (like GPU or storage device). > Attempt to inline such buffer will result in high PCI overhead for reading > and copying the data from the remote device to the host memory. > > To support a mixed traffic pattern (some buffers from local host memory, some > buffers from other devices) with high bandwidth, a hint flag is introduced in > the mbuf. > > Application will hint the PMD whether or not it should try to inline the > given mbuf data buffer. PMD should do the best effort to act upon this request. > > The hint flag RTE_NET_MLX5_DYNFLAG_NO_INLINE_NAME is supposed to be dynamic, > registered by application with rte_mbuf_dynflag_register(). This flag is > purely vendor specific and declared in PMD specific header rte_pmd_mlx5.h, > which is intended to be used by specific application. > > To query the supported specific flags in runtime the private routine is > introduced: > > int rte_pmd_mlx5_get_dyn_flag_names( > uint16_t port, > char *names[], > uint16_t n) > > It returns the array of currently (over present hardware and configuration) > supported specific flags. > > The "not inline hint" feature operating flow is the following one: > - application start > - probe the devices, ports are created > - query the port capabilities > - if port supporting the feature is found > - register dynamic flag RTE_NET_MLX5_DYNFLAG_NO_INLINE_NAME > - application starts the ports > - on dev_start() PMD checks whether the feature flag is registered and > enables the feature support in datapath > - application might set this flag in ol_flags field of mbuf in the packets > being sent and PMD will handle ones appropriately. > > Signed-off-by: Shahaf Shuler > Signed-off-by: Viacheslav Ovsiienko > > --- > v1: https://patches.dpdk.org/patch/61348/ > It looks the patch is missing. I think a dynamic flag is the good solution for this problem: the pmd can send a pmd-specific hint to the application, without impacting the way it works today. Olivier