DPDK patches and discussions
 help / color / mirror / Atom feed
From: Andrew Rybchenko <arybchenko@solarflare.com>
To: <dev@dpdk.org>
Cc: Ferruh Yigit <ferruh.yigit@intel.com>,
	Thomas Monjalon <thomas@monjalon.net>,
	Shahaf Shuler <shahafs@mellanox.com>, Wei Dai <wei.dai@intel.com>
Subject: [dpdk-dev] [PATCH v2 2/3] ethdev: fail if Tx queue offload is not supported
Date: Mon, 14 May 2018 08:36:17 +0100	[thread overview]
Message-ID: <1526283378-30507-3-git-send-email-arybchenko@solarflare.com> (raw)
In-Reply-To: <1526283378-30507-1-git-send-email-arybchenko@solarflare.com>

Do not allow to request unsupported Tx offload since all checks
are removed from PMDs because of consistency check in ethdev.
Otherwise application may rely on offload which is not actually
supported and send traffic with, for example, wrong checksums,
truncated packets or packets with garbage.

If application is using the new offload API, queue offloads only
may be added on Tx queue setup.

If application is using the old offload API, it knows nothing
about device level Tx offloads and requests everything required
on Tx queue setup using txq_flags. So, both device level (from PMD
point of view) and queue level offloads may be requested.
It is assumed that no PMD yet strictly separate device and queue
level offloads. If any PMD does it, it was broken for applications
which use the old offload API at the moment of PMD convertion anyway.

Fixes: 0330605295cf ("ethdev: new Rx/Tx offloads API")

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
---
 lib/librte_ethdev/rte_ethdev.c | 51 +++++++++++++++++++++-------------
 1 file changed, 32 insertions(+), 19 deletions(-)

diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 54e1ee771..2b673013a 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -1727,25 +1727,38 @@ rte_eth_tx_queue_setup(uint16_t port_id, uint16_t tx_queue_id,
 	 */
 	local_conf.offloads &= ~dev->data->dev_conf.txmode.offloads;
 
-	/*
-	 * New added offloadings for this queue are those not enabled in
-	 * rte_eth_dev_configure( ) and they must be per-queue type.
-	 * A pure per-port offloading can't be enabled on a queue while
-	 * disabled on another queue. A pure per-port offloading can't
-	 * be enabled for any queue as new added one if it hasn't been
-	 * enabled in rte_eth_dev_configure( ).
-	 */
-	if ((local_conf.offloads & dev_info.tx_queue_offload_capa) !=
-	     local_conf.offloads) {
-		ethdev_log(ERR, "Ethdev port_id=%d tx_queue_id=%d, new "
-				"added offloads 0x%" PRIx64 " must be "
-				"within pre-queue offload capabilities 0x%"
-				PRIx64 " in %s( )\n",
-				port_id,
-				tx_queue_id,
-				local_conf.offloads,
-				dev_info.tx_queue_offload_capa,
-				__func__);
+	if (tx_conf->txq_flags & ETH_TXQ_FLAGS_IGNORE) {
+		/*
+		 * New added offloadings for this queue are those not enabled in
+		 * rte_eth_dev_configure( ) and they must be per-queue type.
+		 * A pure per-port offloading can't be enabled on a queue while
+		 * disabled on another queue. A pure per-port offloading can't
+		 * be enabled for any queue as new added one if it hasn't been
+		 * enabled in rte_eth_dev_configure( ).
+		 */
+		if ((local_conf.offloads & dev_info.tx_queue_offload_capa) !=
+		    local_conf.offloads) {
+			ethdev_log(ERR, "Ethdev port_id=%d tx_queue_id=%d, new "
+					"added offloads 0x%" PRIx64 " must be "
+					"within pre-queue offload capabilities 0x%"
+					PRIx64 " in %s( )\n",
+					port_id,
+					tx_queue_id,
+					local_conf.offloads,
+					dev_info.tx_queue_offload_capa,
+					__func__);
+		}
+	} else {
+		/*
+		 * Applications which are not converted yet to the new
+		 * Tx offload API may request device level offloads on
+		 * queue level (and nothing is requested on device level).
+		 * However, if the offload is not supported at all,
+		 * Tx queue setup must fail.
+		 */
+		if ((local_conf.offloads & dev_info.tx_offload_capa) !=
+		    local_conf.offloads)
+			return -EINVAL;
 	}
 
 	return eth_err(port_id, (*dev->dev_ops->tx_queue_setup)(dev,
-- 
2.17.0

  parent reply	other threads:[~2018-05-14  7:36 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-11 16:25 [dpdk-dev] [PATCH 0/3] ethdev: fail if requested " Andrew Rybchenko
2018-05-11 16:25 ` [dpdk-dev] [PATCH 1/3] ethdev: fail configure " Andrew Rybchenko
2018-05-11 16:25 ` [dpdk-dev] [PATCH 2/3] ethdev: fail if Tx queue offload is not supported at all Andrew Rybchenko
2018-05-13  5:37   ` Shahaf Shuler
2018-05-13 13:30     ` Shahaf Shuler
2018-05-14  6:54     ` Andrew Rybchenko
2018-05-11 16:25 ` [dpdk-dev] [PATCH 3/3] ethdev: fail if Rx queue offload is not supported Andrew Rybchenko
2018-05-14  7:36 ` [dpdk-dev] [PATCH v2 0/3] ethdev: fail if requested " Andrew Rybchenko
2018-05-14  7:36   ` [dpdk-dev] [PATCH v2 1/3] ethdev: fail configure " Andrew Rybchenko
2018-05-14  7:36   ` Andrew Rybchenko [this message]
2018-05-14  7:36   ` [dpdk-dev] [PATCH v2 3/3] ethdev: fail if Rx queue " Andrew Rybchenko
2018-05-14  7:51   ` [dpdk-dev] [PATCH v2 0/3] ethdev: fail if requested " Shahaf Shuler
2018-05-14 14:48     ` Ferruh Yigit
2018-06-18  8:43       ` Ferruh Yigit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1526283378-30507-3-git-send-email-arybchenko@solarflare.com \
    --to=arybchenko@solarflare.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=shahafs@mellanox.com \
    --cc=thomas@monjalon.net \
    --cc=wei.dai@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).