From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sagi Grimberg Subject: Re: [PATCH] net/mlx5: poll completion queue once per a call Date: Thu, 20 Jul 2017 19:34:04 +0300 Message-ID: References: <20170720154835.13571-1-yskoh@mellanox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org To: Yongseok Koh , adrien.mazarguil@6wind.com, nelio.laranjeiro@6wind.com Return-path: 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 ; Thu, 20 Jul 2017 18:34:08 +0200 (CEST) Received: by mail-wm0-f68.google.com with SMTP id 184so1593162wmo.3 for ; Thu, 20 Jul 2017 09:34:08 -0700 (PDT) In-Reply-To: <20170720154835.13571-1-yskoh@mellanox.com> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > 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?