From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <stephen@networkplumber.org>
Received: from mail-pf0-f174.google.com (mail-pf0-f174.google.com
 [209.85.192.174]) by dpdk.org (Postfix) with ESMTP id B828D2A1A
 for <dev@dpdk.org>; Tue,  8 Dec 2015 01:50:14 +0100 (CET)
Received: by pfbg73 with SMTP id g73so2582624pfb.1
 for <dev@dpdk.org>; Mon, 07 Dec 2015 16:50:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=networkplumber-org.20150623.gappssmtp.com; s=20150623;
 h=from:to:cc:subject:date:message-id;
 bh=4gI5swKPX5wSr0s7/95eSqvc2kMwdRFcpaAg7sif8hg=;
 b=0uYbK4C8e/p6P6iXseQe3/ZwGrnduv254AqXqiDW93cnobv0FHzvrrq8I/dsa95He5
 MSAGwRwQIo8cf4NwdqhHT8dWKLEw1uBd569ew3pc85X3poXuv+S9rol7jnZoTwhCbxpo
 kInhVc7OxvDNEhUDENKJwnNGPM9xcT6i+WRa/4ZZUCk47LK6JMng5CIgnZyn8/Wq7VUo
 N255Toq1wgeSCHFUVjwkXlzLI/+QE8BkQe3WLDEcpKe0w1IOc3/oa1bYiXqxMSbQI50k
 wssa46PDIbEine6+0RwB9C6Wbp36ljwV+JoiwiDqZhiIhXyDRzTe3gSTfNy4H3njl/qT
 N5hg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:from:to:cc:subject:date:message-id;
 bh=4gI5swKPX5wSr0s7/95eSqvc2kMwdRFcpaAg7sif8hg=;
 b=ckZ5BZwoOYGAx3DKnFAosqUGSWAxBO6LWXtjEoXAeTJlAygQZEFf26yKmHWYorL4CW
 lg1cCUWGNM1RkVZx3OOaYoRB3/qiHinzYBlM+minvAlE0BwSwiWainXfzCyDFu/SPCpw
 aKtWyFtgTMzAaylsXLzGcB39vZoUNva++ghnuhzejlUNKGoE3fdEa0lif60BNRhuh43E
 GjFOptDclbTdMgAHarR9ZdHqSdMv4B9NNcsUwvw6uMFvdNWSIMwWP1YkbzjRTjkmlsde
 C8fk0bdlgF563QmvNAZmiAq0uMzhEN3fVEaKReOtLyjsaygkqN6JZZSP1uA7MPiRq/9N
 LJuA==
X-Gm-Message-State: ALoCoQkN/7dhFrm2nnVTG4zkJ8IO59XprEjFju8V3IvA2gBCnZWsPqBfWQNv+mq+SBsXuJ9tOjckBhQWVZ45RR/w44aScfXeGA==
X-Received: by 10.98.74.72 with SMTP id x69mr985152pfa.88.1449535814114;
 Mon, 07 Dec 2015 16:50:14 -0800 (PST)
Received: from xeon-e3.home.lan (static-50-53-82-155.bvtn.or.frontiernet.net.
 [50.53.82.155])
 by smtp.gmail.com with ESMTPSA id xr8sm470817pab.26.2015.12.07.16.50.12
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
 Mon, 07 Dec 2015 16:50:13 -0800 (PST)
From: Stephen Hemminger <stephen@networkplumber.org>
To: huawei.xie@intel.com,
	yuanhan.liu@linux.intel.com,
	nlaw@brocade.com
Date: Mon,  7 Dec 2015 16:50:21 -0800
Message-Id: <1449535821-12384-1-git-send-email-stephen@networkplumber.org>
X-Mailer: git-send-email 2.1.4
Cc: dev@dpdk.org
Subject: [dpdk-dev] [PATCH] vhost: don't stall if guest is slow
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Dec 2015 00:50:15 -0000

When guest is booting (or any othertime guest is busy) it is possible
for the small receive ring (256) to get full. If this happens the
vhost library should just return normally. It's current behavior
of logging just creates massive log spew/overflow which could even
act as a DoS attack against host.

Reported-by: Nathan Law <nlaw@brocade.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 lib/librte_vhost/vhost_rxtx.c | 15 +++++----------
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/lib/librte_vhost/vhost_rxtx.c b/lib/librte_vhost/vhost_rxtx.c
index 9322ce6..bbf3fac 100644
--- a/lib/librte_vhost/vhost_rxtx.c
+++ b/lib/librte_vhost/vhost_rxtx.c
@@ -510,17 +510,12 @@ virtio_dev_merge_rx(struct virtio_net *dev, uint16_t queue_id,
 
 			do {
 				avail_idx = *((volatile uint16_t *)&vq->avail->idx);
-				if (unlikely(res_cur_idx == avail_idx)) {
-					LOG_DEBUG(VHOST_DATA,
-						"(%"PRIu64") Failed "
-						"to get enough desc from "
-						"vring\n",
-						dev->device_fh);
+				if (unlikely(res_cur_idx == avail_idx))
 					goto merge_rx_exit;
-				} else {
-					update_secure_len(vq, res_cur_idx, &secure_len, &vec_idx);
-					res_cur_idx++;
-				}
+
+				update_secure_len(vq, res_cur_idx,
+						  &secure_len, &vec_idx);
+				res_cur_idx++;
 			} while (pkt_len > secure_len);
 
 			/* vq->last_used_idx_res is atomically updated. */
-- 
2.1.4