From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f176.google.com (mail-wr0-f176.google.com [209.85.128.176]) by dpdk.org (Postfix) with ESMTP id D0B21378E for ; Mon, 4 Sep 2017 16:01:51 +0200 (CEST) Received: by mail-wr0-f176.google.com with SMTP id 108so1830236wra.5 for ; Mon, 04 Sep 2017 07:01:51 -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=IV0x1+JunjKl9NebnC4MJio8N1ito4V8NvAp3urNQy4=; b=MRFZIxIKct4W5tEOR0bHCFfl2aH3oPsCUo4q+Mw9HbKTsZBqMSj4POP7HJjFAmCYHL dKj+7cgMpknTO4k0GKvBez8g5VX9Q2lWkr+6gGEcIaxq2aknsWlehuKUImsy7CdLtt88 8H4Hb1B4tBqfxBWOhbvtRjs1yDzXoOqy+0rX+DmlrIGzfFxRGVfp95ijxp4mpbQgieE3 BSutInzzOSI+yaJA7+4CXJ7CF4xOlnQ5cOdrmYCb9qDJ9HwpXR2SuKCMRNYJsS6VrPdR hk4s5iC3nOmdYwQxvlPy787Uq/0GCBUbJS08oIsyPzes/RIR1VmoznE/NdG+5yvgCgCU yuaA== 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=IV0x1+JunjKl9NebnC4MJio8N1ito4V8NvAp3urNQy4=; b=UUJAY5LMv4Pqb2u1k+kq0XCZg4MXW7kMCDgFFCKc7oTJsgkrpSrAaHfdAlMt87Z3lU 16VeeB7gVegKod+kv1yIUCEPxn/xE9xUtHMbrL56C45hhQL4guJ/UV8icT50BB39XemP X1K+2wiY50BIvx474LpKzE4XeFEa9eynioHHarIdlBDsIGrLnEKl2k3urWwZMzFgVoQW yfncPtEm+W9muTXd1D+E9EchIDa91MVcd4x/iauoGq/oCSRkO7PNyEZP59pDbTyK8YGt ApeejagGrvjCOMIQxjlxbP6ZDrz6/IVzowrPD9p+r/3C8Ll5+vyDqqjoLheybe/YfnDM ceEA== X-Gm-Message-State: AHPjjUhbqHnCuMVXK0HCBKu4+C7t0oVHPgl+mQ3OkHK1XmgOII/w39Yg snFUPhFcfO3q//Wx X-Google-Smtp-Source: ADKCNb78foOIF5WVzWzW0Sd7se7PqP5QZrhjMF9rIBBtoa4aZPScKIugTyyLRyv0ZzaBB/ODjMo1gw== X-Received: by 10.223.138.238 with SMTP id z43mr350305wrz.83.1504533711049; Mon, 04 Sep 2017 07:01:51 -0700 (PDT) Received: from localhost (lan31-h07-89-80-147-20.dsl.sta.abo.bbox.fr. [89.80.147.20]) by smtp.gmail.com with ESMTPSA id w81sm588746wme.48.2017.09.04.07.01.49 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 04 Sep 2017 07:01:49 -0700 (PDT) Date: Mon, 4 Sep 2017 16:01:08 +0200 From: =?iso-8859-1?Q?N=E9lio?= Laranjeiro To: Yongseok Koh Cc: adrien.mazarguil@6wind.com, dev@dpdk.org, stable@dpdk.org, Shahaf Shuler Message-ID: <20170904140107.nkr565m266sw5cyf@localhost> References: <20170831162706.30899-1-yskoh@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170831162706.30899-1-yskoh@mellanox.com> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [PATCH] net/mlx5: fix calculating TSO inline size 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: Mon, 04 Sep 2017 14:01:52 -0000 Hi Yongseok, Please see some comments below, On Thu, Aug 31, 2017 at 09:27:06AM -0700, Yongseok Koh wrote: > Tx descriptor for TSO embeds packet header to be replicated. If Tx inline > is enabled, there could be additional packet data inlined with 4B inline > header ahead. And between the header and additional inlined packet data, > there may be padding to make the inline part aligned to > MLX5_WQE_DWORD_SIZE. In calculating the total size of inlined data, the > size of inline header and padding is missing. > > Fixes: 3f13f8c23a7c ("net/mlx5: support hardware TSO") > Cc: stable@dpdk.org > > Signed-off-by: Shahaf Shuler > Signed-off-by: Yongseok Koh > --- > drivers/net/mlx5/mlx5_rxtx.c | 25 +++++++++---------------- > 1 file changed, 9 insertions(+), 16 deletions(-) > > diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c > index fe9e7eac0..f89fa40b5 100644 > --- a/drivers/net/mlx5/mlx5_rxtx.c > +++ b/drivers/net/mlx5/mlx5_rxtx.c > @@ -524,19 +521,20 @@ mlx5_tx_burst(void *dpdk_txq, struct rte_mbuf **pkts, uint16_t pkts_n) > } > /* Inline if enough room. */ > if (inline_en || tso) { > + uint32_t inl; > uintptr_t end = (uintptr_t) > (((uintptr_t)txq->wqes) + > (1 << txq->wqe_n) * MLX5_WQE_SIZE); > unsigned int inline_room = max_inline * > RTE_CACHE_LINE_SIZE - > - (pkt_inline_sz - 2); > + (pkt_inline_sz - 2) - > + !!tso * sizeof(inl); Is not it dangerous to assume inl will always be 4 bytes long? Why not writing the real value instead? > uintptr_t addr_end = (addr + inline_room) & > ~(RTE_CACHE_LINE_SIZE - 1); > unsigned int copy_b = (addr_end > addr) ? > RTE_MIN((addr_end - addr), length) : > 0; > > - raw += MLX5_WQE_DWORD_SIZE; > if (copy_b && ((end - (uintptr_t)raw) > copy_b)) { > /* > * One Dseg remains in the current WQE. To Thanks, -- Nélio Laranjeiro 6WIND