From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sagigrim@gmail.com>
Received: from mail-wm0-f68.google.com (mail-wm0-f68.google.com [74.125.82.68])
 by dpdk.org (Postfix) with ESMTP id 4ACA529C8
 for <dev@dpdk.org>; Thu, 20 Jul 2017 18:34:08 +0200 (CEST)
Received: by mail-wm0-f68.google.com with SMTP id 184so1593162wmo.3
 for <dev@dpdk.org>; Thu, 20 Jul 2017 09:34:08 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:subject:to:cc:references:from:message-id:date
 :user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=ljoTBYjA4Z1bBYRp3iBFuGc5X2XUgDaunTcjfroofpg=;
 b=nT0PiRdbkBwVtrwoOpVlPXJgNTz4oEI++5Eg5rum5UjBSP0xBv3GQDD5CdTxdgXTlC
 uy2TdZay9UAhvLCSaWizJ9BS/dmiuY0yTwommKnIhlca8jxk5dOMUBMMBKp9Z8CdY93r
 oJWMSC6KFtsedAmIceDtOeAdvHS5Dl1O0ulQVBIZ1HjfIqtg2Uai86wrch/1zBbwW/2m
 yLoIjtW1eWTTLJNnPevnppiJrjnVzcH4gzimJGaBQaHTPrXGTPgbOceL1IVo8U5SYM5j
 K72Gc1gp/siFJWde7g0gm42CwATL+KCVEqTetTDFSEOlNzz8kK1JS6zGFkuXnCaitRxk
 +ycQ==
X-Gm-Message-State: AIVw111aeMOoFGhdJWz5nRUoXuBRwkXaJCOl7Vh0r8PickzW5i5te8Gz
 28EK8ntYJxlFNZeqE6k=
X-Received: by 10.28.229.207 with SMTP id c198mr2682012wmh.108.1500568447804; 
 Thu, 20 Jul 2017 09:34:07 -0700 (PDT)
Received: from [192.168.64.116] (bzq-82-81-101-184.red.bezeqint.net.
 [82.81.101.184])
 by smtp.gmail.com with ESMTPSA id m123sm2756886wmb.3.2017.07.20.09.34.06
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Thu, 20 Jul 2017 09:34:07 -0700 (PDT)
To: Yongseok Koh <yskoh@mellanox.com>, adrien.mazarguil@6wind.com,
 nelio.laranjeiro@6wind.com
Cc: dev@dpdk.org
References: <20170720154835.13571-1-yskoh@mellanox.com>
From: Sagi Grimberg <sagi@grimberg.me>
Message-ID: <fbc908a1-fe53-643d-0d3b-df688232d23c@grimberg.me>
Date: Thu, 20 Jul 2017 19:34:04 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <20170720154835.13571-1-yskoh@mellanox.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-dev] [PATCH] net/mlx5: poll completion queue once per a
 call
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <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, 20 Jul 2017 16:34:08 -0000


> mlx5_tx_complete() polls completion queue multiple times until it
> encounters an invalid entry. As Tx completions are suppressed by
> MLX5_TX_COMP_THRESH, it is waste of cycles to expect multiple completions
> in a poll. And freeing too many buffers in a call can cause high jitter.
> This patch improves throughput a little.

What if the device generates burst of completions? Holding these
completions un-reaped can theoretically cause resource stress on
the corresponding mempool(s).

I totally get the need for a stopping condition, but is "loop once"
the best stop condition?

Perhaps an adaptive budget (based on online stats) perform better?