From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <rich.lane@bigswitch.com>
Received: from mail-ua0-f176.google.com (mail-ua0-f176.google.com
 [209.85.217.176]) by dpdk.org (Postfix) with ESMTP id 1E82A68FC
 for <dev@dpdk.org>; Thu, 18 Aug 2016 20:27:07 +0200 (CEST)
Received: by mail-ua0-f176.google.com with SMTP id 74so42313201uau.0
 for <dev@dpdk.org>; Thu, 18 Aug 2016 11:27:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=bigswitch-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:in-reply-to:references:from:date:message-id:subject:to
 :cc; bh=IaojLFRU+jACOd2kBSq1lKIOfy8zhsJsXqU4kRkWp2s=;
 b=W+TdBhtFLOQfQTGAIdfO6H8mU2DL1Jaxgcx9AI+oYhrMzrnv74PeEjqwYC4TfkCzQE
 LvLPjJ3gECedU7dsRhtUiUs1dh6t61Me+h7e0VPbo1axYxx69qrHTzFSw9eghhksKmrH
 FfS+AkFrSdZ7YIz7WqC4+3xA7UKpf/m+RMUHG/UFu6+Onhk1LD5twiN4lbKkJPieN1q+
 WdR1/WAUqhau0gD4N1f7U9rjK9w47zEjSPpq8Sqm9cmQt+8qjpuvfr5ZOyg2JY0EBTGy
 xUEaWovzxK0UOb+gCi0kbrisG55C2cDntGdqat84+RyFAs4Zef71mZGSBj2Nh0U8WRTs
 WBQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:mime-version:in-reply-to:references:from:date
 :message-id:subject:to:cc;
 bh=IaojLFRU+jACOd2kBSq1lKIOfy8zhsJsXqU4kRkWp2s=;
 b=W8/8RzkuQYSwZRtjj8oZnedV6n+jr7NqIl3f+Kd8yHpmXupXCGHQ18mNWo8/BYSVX6
 n7ta1E6uH3FBWgRrCDMRSFlsu9k8SiVWsGbcRtnTI4Sz1UllxeLSYiVCm2XGDF5DQSHe
 9TlPB+x7quZJX0gJtsFm+DSI49nS1grNVFvKVeMk1Xj2hG1GjmkTVlrwIQsZJaczOKvX
 rrlZAgXYgRTaBGpj7PgET8k11eJXFhyN0Sn5yuF0MuNVVVcKzy4OUbFMtoQa4R7PXJnW
 MWsB85357MfIrjjH2qkxaGQkUL4vFlryZI2NY1OmDbzxvzNCbmWNO70WEBBiUjoluSKS
 8WDw==
X-Gm-Message-State: AEkoouvhZmOwJf/GyvUjIM9n2PFpQ1IL6nWjSZVilolsiZdY/Iy4geujPdGZzQW5bxxSCTwekQYE+3QvA0+WVvE1
X-Received: by 10.176.82.219 with SMTP id w27mr1921535uaw.121.1471544826625;
 Thu, 18 Aug 2016 11:27:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.50.199 with HTTP; Thu, 18 Aug 2016 11:27:06 -0700 (PDT)
In-Reply-To: <20160816023715.GL30752@yliu-dev.sh.intel.com>
References: <1471291224-12755-1-git-send-email-rich.lane@bigswitch.com>
 <20160816023715.GL30752@yliu-dev.sh.intel.com>
From: Rich Lane <rich.lane@bigswitch.com>
Date: Thu, 18 Aug 2016 11:27:06 -0700
Message-ID: <CAGSMBPNcMAO0uS87h8YZwSJ5oWDh_7Vnb17sXzJGEqbU47R4dQ@mail.gmail.com>
To: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Cc: dev@dpdk.org, Huawei Xie <huawei.xie@intel.com>
Content-Type: text/plain; charset=UTF-8
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Subject: Re: [dpdk-dev] [PATCH] vhost: add back support for concurrent
	enqueue
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: Thu, 18 Aug 2016 18:27:07 -0000

On Mon, Aug 15, 2016 at 7:37 PM, Yuanhan Liu <yuanhan.liu@linux.intel.com>
wrote:

> On Mon, Aug 15, 2016 at 01:00:24PM -0700, Rich Lane wrote:
> > Concurrent enqueue is an important performance optimization when the
> number
> > of cores used for switching is different than the number of vhost queues.
> > I've observed a 20% performance improvement compared to a strategy that
> > binds queues to cores.
> >
> > The atomic cmpset is only executed when the application calls
> > rte_vhost_enqueue_burst_mp. Benchmarks show no performance impact
> > when not using concurrent enqueue.
> >
> > Mergeable RX buffers aren't supported by concurrent enqueue to minimize
> > code complexity.
>
> I think that would break things when Mergeable rx is enabled (which is
> actually enabled by default).
>

Would it be reasonable to return -ENOTSUP in this case, and restrict
concurrent enqueue
to devices where VIRTIO_NET_F_MRG_RXBUF is disabled?

I could also add back concurrent enqueue support for mergeable RX, but I
was hoping to avoid
that since the mergeable codepath is already complex and wouldn't be used
in high performance
deployments.


> Besides that, as mentioned in the last week f2f talk, do you think adding
> a new flag RTE_VHOST_USER_CONCURRENT_ENQUEUE (for
> rte_vhost_driver_register())
> __might__ be a better idea? That could save us a API, to which I don't
> object
> though.
>

Sure, I can add a flag instead. That will be similar to how the rte_ring
library picks the enqueue method.