From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f182.google.com (mail-pf0-f182.google.com [209.85.192.182]) by dpdk.org (Postfix) with ESMTP id 760E78D3C for ; Fri, 27 Apr 2018 00:40:58 +0200 (CEST) Received: by mail-pf0-f182.google.com with SMTP id j11so19478453pff.10 for ; Thu, 26 Apr 2018 15:40:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=VAPd08NcvpWszz04Knp/tBYet+ljDXG0SN9YZRisi6M=; b=g14y07/4FJMyiuFgpzDrgxuPgIKnP5plyQS3C9dfe0LD9M9Gs6qfhkV6qNduqFIBZO gUFyXsM/SKM+Oe4FTvGZ90/bMLt6jPF3pmfMv75emcSd4D+Ep3lZaG9fTisFta1P4cDc 1UZO+b0O4cilUkdSnpAohLglV9JKNNMPvKNR1YDIvkMfeSv7OVfyUIqFCQx9fsa4+fgw /13WgGhYdPvrg0PFXTuBbEdhJ8bu9MsniPKWmgP/OmLiSTGJ9ugqC5hDw1uMn8GpoqH5 FxVEvfS3U0Yigv0DzX+xw5q1iNgu9TEnLfXl4q9dpLcBSUXepZTilxXV2edEOi/O1Gbv qkNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=VAPd08NcvpWszz04Knp/tBYet+ljDXG0SN9YZRisi6M=; b=q284YZPZxIVQ9NZkmvs8aIwttYgMQUI1GjEpz1JNjh6i1vrobYwhcT0Dyr9OjOfltB r/Ym8SO4LTkZCmVXFpMx2EmgbGcSv+qFLeZFMY17OVDgOfcsTJq58bwNBp8nfA41urNr XfIwVX9AjiT8jAycPspov0pJzWtd+oxx2T32YX1QEKVeltTfAxiDJheQcwtZa4FxcnLc jdC9XCrmiA2W6MUEvhy1U8XaM6Icf9D5RJ27XNAgqSM3fh4XCdfLKhZ8Z3+ICilnUv4r lHLPS64btpeV7MsaCZK8zJdzkPO88ydqxWC0DcBN80ZaZMOaxg/SujjQpVSQZIVqFPV6 NIPg== X-Gm-Message-State: ALQs6tCW5oA3HQvhZhOkSDd7T/65NyX6fCi4f2aJ5BHvuL24H9LeyH4n /bIYnnyw6Koc/onhsYRpp1qkUg== X-Google-Smtp-Source: AIpwx4/3YJJdUhgfbKj8FC5iLAd7rW6RrRDmv/Qhn3PNzd37lLvP7My5dcSfRkY4gkHU8MTCheYWhw== X-Received: by 10.99.107.8 with SMTP id g8mr29036547pgc.271.1524782457486; Thu, 26 Apr 2018 15:40:57 -0700 (PDT) Received: from xeon-e3 (204-195-71-95.wavecable.com. [204.195.71.95]) by smtp.gmail.com with ESMTPSA id p71sm36859061pfl.170.2018.04.26.15.40.57 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 26 Apr 2018 15:40:57 -0700 (PDT) Date: Thu, 26 Apr 2018 15:40:55 -0700 From: Stephen Hemminger To: "Wu, Xiaoban" Cc: "users@dpdk.org" Message-ID: <20180426154055.16842d96@xeon-e3> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-users] Interesting considerate but annoying behavior of MLX5 driver X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 22:40:58 -0000 On Thu, 26 Apr 2018 22:26:36 +0000 "Wu, Xiaoban" wrote: > Dear All, > > > I have two Dell PowerEdge R740 servers A and B running with ubuntu 16.04, each one has a Mellanox MCX556A-ECAT NIC installed on the PCIe x16 slot. And, the two NICs are directly connected back to back with a copper cable. > > > On server A, it runs a RX program which runs a function to process and analyze the received packets. On server B, it runs a packet-gen program which generates and sends packets out. They are both compiled with dpdk-17.11 > > > Now the interesting thing is that on server B, it is kind of smart and considerate enough to automatically adjust its TX throughput according to how fast server A processes the packets. If server A processes the packets faster, then server B sends packets with a higher throughput. Similarly, if server A processes the packets slower, then server B sends packets with a lower throughput. Please note that once the program on server B starts, it is never interrupted by any way. > > > However, I think the server B should send out the packets with a constant throughput no matter how fast server A processes the packets. > > > Does anybody else notice this interesting behavior of MLX5 driver? Can anybody help me disable this feature permanently? Thanks very much for your help. > > > Best wishes, > > Xiaoban Turn off Ethernet flow control. It was a design mistake that NIC vendors always seem to like because it gives 0 loss benchmarks.