From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f67.google.com (mail-wm0-f67.google.com [74.125.82.67]) by dpdk.org (Postfix) with ESMTP id 963861B81D for ; Wed, 25 Oct 2017 09:50:08 +0200 (CEST) Received: by mail-wm0-f67.google.com with SMTP id b9so72257wmh.0 for ; Wed, 25 Oct 2017 00:50:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=jBWHPnezCdl7ylkzSIVc9mVfCuNrZ/Qsf5ExtJdD5e0=; b=SRZKDVnC7RYETVwhM/z4qr6gj+SV+YhGedoJXtmMn/O+1yqb+TVhRxY54roDabCljr tkWwOB/L+nSSnyITGcwr8BWj8hbAnRtl6vJxxAJHjQ2D786LN4gJNKr/GIPNqliukrgo 8VtbdrLMtgUoWl3w0lVdo1/QPBHkqQinJQuobTYWuD6hfU1C1vpz7L1PqELCSLtaNZAw DwkDGxRPUuwkA7x7gzHm1KggqtGx6eObyOiy6sVHBcHBsqQ7TsTF/bOH2ShUUtUafd6V HG2L2kaF2VAt1l7bClBjEk/apClBZEXXEAmOgPb1M0Tts/RA6Go8naWqfFIW8fImFsf4 pa6g== 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:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=jBWHPnezCdl7ylkzSIVc9mVfCuNrZ/Qsf5ExtJdD5e0=; b=Wz7Ch3RyLGZod8SNxQH7MHHvj9HXmpseNWxFP5xTo5yaXIcZSxwGjqOiHsOiKAZ847 ss/7mwxejkfF4RnAA8OTA9j0R+069nZR9GQcGaoSzKK4WV1cv2l/EQzewEATtNESpAFd nnAQ6zx9OdlWJVZtEJbkOjGX42IW0H1L7e3Tz1rt0FY8MvQbEKexf71jHZgevdQk3Jvg PVaAcWYaKlOA3pdA8wq8oyKU8vG3N6jUplyFgZmlpqcQNC63tT1t2IkZeSoT7ardzkLD r0dqdywkxOlO4sjTA/8xWfi/rxMTCfMJ8mkiVJZMQidCzSdhHhlNc3YCGhIKnO59JkQE wsAg== X-Gm-Message-State: AMCzsaVZn7hKxjLHF6I3whMPENOlJAq6UuT32ZVSoz8e3QiLBp9WSXvQ gjbbU63ge8AjDMf5nkewMpskNNJ/sA== X-Google-Smtp-Source: ABhQp+QkSe9VrtSNXEj3SdzeG9b8vO3dnH4mXEGKE5HblgOMgCFSnbr3BKCIyTw5dmpmrxBoD9R3bw== X-Received: by 10.28.0.66 with SMTP id 63mr805720wma.7.1508917808222; Wed, 25 Oct 2017 00:50:08 -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 y15sm3718441wrc.96.2017.10.25.00.50.07 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 25 Oct 2017 00:50:07 -0700 (PDT) Date: Wed, 25 Oct 2017 09:50:06 +0200 From: =?iso-8859-1?Q?N=E9lio?= Laranjeiro To: Ophir Munk Cc: Adrien Mazarguil , "dev@dpdk.org" , Thomas Monjalon , Olga Shern , Matan Azrad Message-ID: <20171025075006.znxl7mezy4pfyzsj@laranjeiro-vm> References: <1508752838-30408-1-git-send-email-ophirmu@mellanox.com> <1508768520-4810-1-git-send-email-ophirmu@mellanox.com> <1508768520-4810-5-git-send-email-ophirmu@mellanox.com> <20171024135149.fyg4nzcbygo2amtz@laranjeiro-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [PATCH v2 4/7] net/mlx4: merge Tx path functions X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 07:50:08 -0000 On Tue, Oct 24, 2017 at 08:36:52PM +0000, Ophir Munk wrote: > Hi, > > On Tuesday, October 24, 2017 4:52 PM, Nélio Laranjeiro wrote: > > > > On Mon, Oct 23, 2017 at 02:21:57PM +0000, Ophir Munk wrote: > > > From: Matan Azrad > > > > > > Merge tx_burst and mlx4_post_send functions to prevent double asking > > > about WQ remain space. > > > > > > This should improve performance. > > > > > > Signed-off-by: Matan Azrad > > > --- > > > drivers/net/mlx4/mlx4_rxtx.c | 353 > > > +++++++++++++++++++++---------------------- > > > 1 file changed, 170 insertions(+), 183 deletions(-) > > > > What are the real expectation you have on the remaining patches of the > > series? > > > > According to the comment of this commit log "This should improve > > performance" there are too many barriers at each packet/segment level to > > improve something. > > > > The point is, mlx4_burst_tx() should write all the WQE without any barrier as > > it is processing a burst of packets (whereas Verbs functions which may only > > process a single packet). > > > The lonely barrier which should be present is the > > one to ensure that all the host memory is flushed before triggering the Tx > > doorbell. > > > > There is a known ConnectX-3 HW limitation: the first 4 bytes of every > TXWBB (64 bytes chunks) should be > written in a reversed order (from last TXWBB to first TXWBB). This means the first WQE filled by the burst function is the doorbell. In such situation, the first four bytes of it can be written before leaving the burst function and after a write memory barrier. Until this first WQE is not complete, the NIC won't start processing the packets. Memory barriers per packets becomes useless. It gives something like: uint32_t tx_bb_db = 0; void *first_wqe = NULL; /* * Prepare all Packets by writing the WQEs without the 4 first bytes of * the first WQE. */ for () { if (!wqe) { first_wqe = wqe; tx_bb_db = foo; } } /* Leaving. */ rte_wmb(); *(uin32_t*)wqe = tx_bb_db; return n; > The last 60 bytes of any TXWBB can be written in any order (before > writing the first 4 bytes). > Is your last statement (using lonely barrier) is in accordance with > this limitation? Please explain. > > > There is also too many cases handled which are useless in bursts situation, > > this function needs to be re-written to its minimal use case i.e. processing a > > valid burst of packets/segments and triggering at the end of the burst the Tx > > doorbell. > > Regards, -- Nélio Laranjeiro 6WIND