From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f180.google.com (mail-wr0-f180.google.com [209.85.128.180]) by dpdk.org (Postfix) with ESMTP id 24DD1199B4 for ; Wed, 13 Sep 2017 09:26:30 +0200 (CEST) Received: by mail-wr0-f180.google.com with SMTP id o42so26741389wrb.3 for ; Wed, 13 Sep 2017 00:26:30 -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=gWobGObU72ZRX5kxEyx4tNcznYITk2YSII++kod4HCk=; b=L1PrZbgOxpLXSmEKsNFCOUy1sLOtP2rTRLK6Hl+5GXcHb9JS3YzOP13A81q0Kwfp7u DdH42Ydkt2PRc6ecQfS9xlWnysI22kaPDFespg3uL+gzELXIdh/Kxx0PZXuvBKgZ7EHz fhCE3bhOthGtsp9EnvgUJ1lZPbzq+kvT1cmxyTIP2T263b59DvM8h6Oq3icCaTJkaWQh y2SJ7vi2fpfJbx9b2BEdlU/K7JJ5nAtV/VulmVgH1vl4VIHPhlSmfVpqHx5uVae8+WLd EENQKrep/f36yBBLKFc2yrRnnjbmdLAybm8VA0m8Nb2qtX7spVcx7JGeKuO/yRb3nxlQ Vaog== 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=gWobGObU72ZRX5kxEyx4tNcznYITk2YSII++kod4HCk=; b=Kuz69Zi5WxDGqMETrsf6doeXj4ZI976YgzSUyIsHj7K4fGiY+Md2JgQW7o8yb2x5lh JtPXFf5ZT+nreTmrDEd+aCBFlJp/4bBpAeVmeEsV8pPL5I7mbALDaXEQtUBZQ5a8Muld sWplif7Us7FkYzC8pXjZUJxS4asMoVb8p5LDECtIRIe32XnMQybTaRrYO3nTWPD29ghj iwqaVjX/M5iIYfW7uJ/pVOfmi6TxDwBzGh1NB2jLdIByXt6D8PGilhEfVTYjPT+Sqgwd IrZ97zDal5V0E7MOD7ucijN2fluY4/1o2/izJlT3yJ9LHypb8EofuriDLx+6AhROotJk i1iQ== X-Gm-Message-State: AHPjjUjCTJ+uyVY44zO964IDH/5kQJp76COJbQaJQgHsqtuEvFY4qGOy 4qpbJmDL0TIzUAugAEEmHg== X-Google-Smtp-Source: ADKCNb6FGbLWJiUJAy9Rcc6r9ia94C3glxjbvVbJwHDMIVF0SAAsU6y6c5G3CRoxXH2aOqnQqpMLfA== X-Received: by 10.223.192.9 with SMTP id z9mr13620081wre.176.1505287589816; Wed, 13 Sep 2017 00:26:29 -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 v98sm11604497wrc.71.2017.09.13.00.26.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Sep 2017 00:26:28 -0700 (PDT) Date: Wed, 13 Sep 2017 09:26:06 +0200 From: =?iso-8859-1?Q?N=E9lio?= Laranjeiro To: Shahaf Shuler , Yongseok Koh Cc: Yongseok Koh , Adrien Mazarguil , "dev@dpdk.org" , "stable@dpdk.org" Message-ID: <20170913072606.GA29920@autoinstall.dev.6wind.com> References: <20170831162706.30899-1-yskoh@mellanox.com> <20170904140107.nkr565m266sw5cyf@localhost> <20170911221743.GB1922@yongseok-MBP.local> <20170912072411.GO14138@autoinstall.dev.6wind.com> <30C13A14-CB69-45B0-9DC8-EBE8048098B7@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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: Wed, 13 Sep 2017 07:26:30 -0000 On Wed, Sep 13, 2017 at 05:05:14AM +0000, Shahaf Shuler wrote: > Tuesday, September 12, 2017 9:34 PM, Nélio Laranjeiro: > > > On Sep 12, 2017, at 12:24 AM, Nélio Laranjeiro > > >>> 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. > > > > I tried to change the sizeof but I found that there are more "sizeof(inl)" in the > > following lines. Changing all the sizeof would be beyond the scope of this > > patch. So, how about leaving it as is for consistency? > > The inline segment format is not expected to change so easily. It is parsed > by the HW and HW maintains backward compatibility for all of the WQE > structures. We are not talking here about the hardware behavior but about wrong ways to define hardware values which should be used trough define and not by size of variable which can be wrongly modified. If the hardware inline_header size of 4, it should be defined as is. I won't block this patch as it is not the single place where this sizeof is used, but it should be replaced as soon as possible by a define to avoid wrong behaviors in the future. Acked-by: Nelio Laranjeiro -- Nélio Laranjeiro 6WIND