From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f169.google.com (mail-wr0-f169.google.com [209.85.128.169]) by dpdk.org (Postfix) with ESMTP id 5E5C4376C for ; Mon, 4 Sep 2017 16:01:51 +0200 (CEST) Received: by mail-wr0-f169.google.com with SMTP id j3so1873129wrb.3 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=UTW90T+FkCeObuI7s3Yl6TTQLMosj43FujHO+cfz60OgG036gnr+1DxmyvUKkU4Pw7 oNQg2HyXosuyW6tQbXroTdgBqMjJLg+XvRgC+ntt2j6eOwf8Gm/408T5v2sPfW+kHMLW 19sTNwsfM9Ee3NVFcypmsh3vXnCmyZQMwVn42DMWvI2PXAwwSn6MsN5m4J8lpCB1JDZn XzGHUU+HnY7AapZ/77roCGktPNCOJ1gnfv2zYjwU5MGelzk0iIrqaZ5IvW1HRn3RcvCW fvTS0kqepTZc/iuyFUzKDJEl+zmTB5KZ+CqCmVUSCH2xkvaC0lkCqWJiHE5U2XObScsR X7GA== X-Gm-Message-State: AHPjjUg9Xcz3KRbRqhmX8WDTK0Wzx+OwEBIs2ItyWi16tc+NIUKFx2dL MdMpxLNCEVKoYzFEDkoeLw== 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-stable] [PATCH] net/mlx5: fix calculating TSO inline size 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: Mon, 04 Sep 2017 14:01:51 -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