From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f193.google.com (mail-wr0-f193.google.com [209.85.128.193]) by dpdk.org (Postfix) with ESMTP id 26A381B738 for ; Tue, 24 Oct 2017 08:49:21 +0200 (CEST) Received: by mail-wr0-f193.google.com with SMTP id y9so7356202wrb.2 for ; Mon, 23 Oct 2017 23:49:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:date:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=ASxGykuP9ZSyaMNztiMbem3ebiuk+Di80RNo7nfRGZ4=; b=oR/FXgc4SkNaDjh57xbBVXCLmPB+OZNLNNIa9F8xIOxD+nd2qrZA69WKVFX945wGmh lMOoQTjnQ0S8JguP6urn+PC9HA+IjW6GIflNXC03ab8QvoioNWkbkDt8lFze/8hhMBo+ 7JM8tVGqzMYloZRCffE9PrJnMEmkZohLMAptgjlkRTI7DKBk5SygaTImtSaIDlFLK4bs PBk8Vs2+Zm/ImreRsx7Rcc4rKVf7CWILiHusMuBLhyM+ITrOlfF0z4O5op9L/rPcTrJ9 NkSacOJwV8+rMhJggvtgMTQq6/SXXE1Dvs75Tt5MHXDSo4P+BB6nidpEOBJ/Xu/aw6al iXww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=ASxGykuP9ZSyaMNztiMbem3ebiuk+Di80RNo7nfRGZ4=; b=InXVyAlOEdHYx9QHjsYfvr16E3Tj3P+yN9rvlF4DaT9XFOoAqBRjYleR62l0S5Iy8s qF/sZDSdRWkL+6eswlOVABp4ja0aYCYJ6thx9G5DcxDXTIIb/s3S5NCIRId5EfG+Lzc6 g2iNBRb3txg6Hh1sEtv8pJiQSTRO4w/U1dIPLttKm0tr/tju9RTz6JtfhsEQFV6M6q5U Cqf9L49UIxYsuvWTYQxEbXM5yqxSN8l6Yg7yJ8jhont0anmwo0GaMlVfkTbrx/4Jhl8K JgSv50KeR8qT8IyYkEtkO0dQz8kPQXM63U+YmT2/LiC+dtdUZwO3WqeW8j4UTS/zm+j8 hLAQ== X-Gm-Message-State: AMCzsaXCEf4M1wiAU/e4CG5xPpn7JkOG1nkH43nPZrRZHhgnv9nLA/Fw p2V5brzGAaw0lqlGM9zccjxi X-Google-Smtp-Source: ABhQp+QgeSYuBpvzD3XHSgPhu5OuuYMbu+7hvohFEp3fFyLKQ4BQmAlLMFe0rl+mYJxx0EcBTblkAA== X-Received: by 10.223.197.131 with SMTP id m3mr14403120wrg.0.1508827761569; Mon, 23 Oct 2017 23:49:21 -0700 (PDT) Received: from laranjeiro-vm (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id x70sm1384715wmf.0.2017.10.23.23.49.20 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 23 Oct 2017 23:49:21 -0700 (PDT) From: "=?iso-8859-1?Q?N=E9lio?= Laranjeiro" X-Google-Original-From: =?iso-8859-1?Q?N=E9lio?= Laranjeiro Date: Tue, 24 Oct 2017 08:49:16 +0200 To: Yongseok Koh Cc: =?iso-8859-1?Q?N=E9lio?= Laranjeiro , Sagi Grimberg , adrien.mazarguil@6wind.com, dev@dpdk.org, stable@dpdk.org, Alexander Solganik Message-ID: <20171024064916.tnmzxzjs5ov6yct5@laranjeiro-vm> References: <20171022080022.13528-1-yskoh@mellanox.com> <20171022220103.GA18571@minint-98vp2qg> <20171023075014.bzubdh2y37s3dirk@laranjeiro-vm> <20171023172408.GA19208@yongseok-MBP.local> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20171023172408.GA19208@yongseok-MBP.local> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH] net/mlx5: fix Tx doorbell memory barrier X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 06:49:22 -0000 On Mon, Oct 23, 2017 at 10:24:09AM -0700, Yongseok Koh wrote: > On Mon, Oct 23, 2017 at 09:50:14AM +0200, Nélio Laranjeiro wrote: > > Yongseok, Sagi, my small contribution to this discussion, > > > > On Sun, Oct 22, 2017 at 03:01:04PM -0700, Yongseok Koh wrote: > > > On Sun, Oct 22, 2017 at 12:46:53PM +0300, Sagi Grimberg wrote: > > > > > > > > > Configuring UAR as IO-mapped makes maximum throughput decline by noticeable > > > > > amount. If UAR is configured as write-combining register, a write memory > > > > > barrier is needed on ringing a doorbell. rte_wmb() is mostly effective when > > > > > the size of a burst is comparatively small. > > > > > > > > Personally I don't think that the flag is really a good interface > > > > choice. But also I'm not convinced that its dependent on the burst size. > > > > > > > > What guarantees that even for larger bursts the mmio write was flushed? > > > > it comes after a set of writes that were flushed prior to the db update > > > > and its not guaranteed that the application will immediately have more > > > > data to trigger this writes to flush. > > > > > > Yes, I already knew the concern. I don't know you were aware but that can only > > > happen when burst size is exactly multiple of 32 in the vectorized Tx. If you > > > look at the mlx5_tx_burst_raw_vec(), every Tx bursts having more than 32 packets > > > will be calling txq_burst_v() more than one time. For example, if pkts_n is 45, > > > then it will firstly call txq_burst_v(32) and txq_burst_v(13) will follow with > > > setting barrier at the end. The only pitfall is when pkts_n is exactly multiple > > > of 32, e.g. 32, 64, 96 and so on. This shall not be likely when an app is > > > forwarding packets and the rate is low (if packet rate is high, we are good). > > > > > > So, the only possible case of it is when an app generates traffic at > > > comparatively low rate in bursty way with burst size being multiple of 32. > > > > A routing application will consume more than the 50 cycles the PMD needs > > to process such burst. It is not a rare case, it is the real one, > > routing lookup table, parsing the packet to find the layers, modifying > > them (decreasing the TTL, changing addresses and updating the checksum) > > is not something fast. > > The probability to have a full 32 packets burst entering in the PMD is > > something "normal". > > Right. There could be more common cases of skipping the barrier. And that's a > good example. But my point here is to give more options to users, not to defend > all the possible singular cases. If an app is processing packets in bursty way, > it is already compromise between latency and throughput. Like you mentioned > below, that's one of design goals of DPDK. If latency is so critical, it would > be better to use interrupt driven processing in kernel context. > > Back to original issue, MLX5 PMD had unreasonably high max latency, especially > with low rate of traffic while min/avg was okay and this could be considered as > a critical bug. This sort of patches are to resolve that issue, not to improve > its overall latency results. > > [...] > > > Before sending out this patch, I've done RFC2544 latency tests with Ixia and the > > > result was as good as before (actually same). That's why we think it is a good > > > compromise. > > > > You cannot do that with testpmd, it does not match the real application > > behavior as it receives a burst of packets and send them back without > > touching them. An application will at least process/route all received > > packets to some other destination or port. The send action will only be > > triggered when the whole routing process is finished to maximize the > > burst sizes. According to the traffic, the latency will change. > > From what I know, we don't have such kind of example/tool in DPDK. > > I wasn't saying that the test with testpmd represented real time use-cases I certain of that, but it is mostly because I know how you work, others DPDK contributors entering in this thread, may understand this ;). > but I just wanted to verify this patch is effective to resolve the > original issue. > Again, this isn't a patch for latency enhancement but to resolve the issue. > > And I think I should also change documentation to address the option > (MLX5_SHUT_UP_BF=1) for v2, unless there's objection. If letting it has a huge impact on the throughput performance and it is the reason why the PMD won't set it in the future, it should be documented to let users embed it in their environment. You can also provide some information about the impact of activating such behavior. Thanks, -- Nélio Laranjeiro 6WIND