From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by dpdk.org (Postfix) with ESMTP id A9C2D29CA for ; Tue, 12 Sep 2017 09:24:22 +0200 (CEST) Received: by mail-wm0-f47.google.com with SMTP id f199so54631745wme.0 for ; Tue, 12 Sep 2017 00:24:22 -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=sAMkN5u0pcApFP36XytYoRVJAhHBuDdF6Jm1lhxM9Us=; b=IMk/+cXc0KOvph/XbN/g+0N+nORTWqZ54+SY5rEWEj2IBTCT72LqQLaCZjQmesKBeY 5MB8AvaoUcPPKMFvyAqEP3bI0Wfh3g/SR+6+PgptJrhQbdQeP1Uez6dACjvwJbi2NCf2 DLPIff3kAcnWOWBDEVRJLVBzHHSdf8txDnefGd62NxiMaFnHmWJs0q22hodl0LcaDUi7 PzvtObTwsP2jyoA8mbpPd6vUzrr/Op7aunL4itNa+V8JEoYEoVg0i/8rf/wHT3jjJt9w R375cAt7JGrr6nvBENriY8WlbA4x3HyLr001VuZy6BlqS8gUmr1RN04S//LmxBjfl6DA Q7eQ== 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=sAMkN5u0pcApFP36XytYoRVJAhHBuDdF6Jm1lhxM9Us=; b=pX5rok11RNe75nzgqckyUpVH3BXIpU9W/bOHvT4N9k8W+h4ytriPrEmYjgKN+haSPC ghRhnfRRaUk3Zq2WFZDPfU/d9a3DmuPqMmJz5p98XbPDGUzGZC+6xU2dh8T62a08yXf3 G5gEWbds5EbJei6uBGt1+99V+pY2rMYrYlVw7VORVbG7az1NuxWJZr3BzjRr5uy79d2/ eK0I573NEoF+ruHwNDuRGQolqPgo749aAnvr6WnBZcNcCrqkuNrVqv2DrdnUOcab2llB 2IWDbwnx2WHHs3/S29JzH+B5YG06vZwMVHaFoUnelaKy/SmPt6zooULwVmHUWA7I1+8t xENg== X-Gm-Message-State: AHPjjUh3+4Xaq8vL+6b+2d1oRETxVFOUyvo/8IXKkQxEUwZUDVxfvP2L viP9qxZ2s64dYMPq X-Google-Smtp-Source: AOwi7QCDO8JKpLGtE4A87oiNovFuCF15i5eHHev60Cd4tKXuYNBvCbbNUWL4vt6Zq28oeKkFlVf8gA== X-Received: by 10.28.24.7 with SMTP id 7mr10890031wmy.78.1505201062139; Tue, 12 Sep 2017 00:24:22 -0700 (PDT) Received: from autoinstall.dev.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id p80sm7236089wmf.42.2017.09.12.00.24.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Sep 2017 00:24:20 -0700 (PDT) Date: Tue, 12 Sep 2017 09:24:11 +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: <20170912072411.GO14138@autoinstall.dev.6wind.com> References: <20170831162706.30899-1-yskoh@mellanox.com> <20170904140107.nkr565m266sw5cyf@localhost> <20170911221743.GB1922@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: <20170911221743.GB1922@yongseok-MBP.local> User-Agent: Mutt/1.5.23 (2014-03-12) 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: Tue, 12 Sep 2017 07:24:22 -0000 On Mon, Sep 11, 2017 at 03:17:44PM -0700, Yongseok Koh wrote: > On Mon, Sep 04, 2017 at 04:01:08PM +0200, Nélio Laranjeiro wrote: > > 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? > That was for readability of the code and uint32_t will be always 4bytes. But for > better readability, it should be 'inline_header' instead of 'inl' though. I'm > also okay with using "4" as well. Which way do you prefer? I agree on both, I was not clear enough to explain my thought, if for some reason the inl moves from uint32_t to uint16_t without touching the sizeof later, it will cause an issue. Thanks, -- Nélio Laranjeiro 6WIND