From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54]) by dpdk.org (Postfix) with ESMTP id 18E4F2A5B for ; Tue, 24 Jan 2017 11:51:28 +0100 (CET) Received: by mail-wm0-f54.google.com with SMTP id c206so202460822wme.0 for ; Tue, 24 Jan 2017 02:51:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:date:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=dYo2EkHCUIixHhK5MTL4ESs8ETEvEMU11ogbb6Dr9+c=; b=rpZUzkHlEMgXhTKI7pKLMGqTy3JI6BWUvS9UmGRQeYoAM47ypjdDg0p6fhgGwEEY+w bHRE9xbtPCF17ysRrYoowa5HdhUudx4PP44Ct6n2osx8UpAmhdNl7k/vObzEZXXUIisE JA0MxAGMl1Rvn+kim4aT5vSVFxtj1p8mNH6XsJgQ6KOe566AJgEphMMbllQHapLyLdqk ObG1Nph2+nEh82BKM9NT3/T8qgFLHvdQglXdGsJyS7STrcM4pZN41JZFAmFzwaqjD51U 4tgM7XRNz+ZX3/FHKd4GyhZir2QZTrHU8T7qv8DeSDgKsOBqFW+8QZGJ47/xhckP16VP E0LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=dYo2EkHCUIixHhK5MTL4ESs8ETEvEMU11ogbb6Dr9+c=; b=T1pZ10AlOs/ijF0ve7Ntqiic8l007d8yzM5X/G/LJixSgOQI6Bgn3z3oAOBghC9LDS VnPJaOAtXi8iajJxJujYTb5aGaBT4chhMMK+9LNBgLLjaKd3KcUJmS31b+AA82Wvip/P ZY7KfDrffZfAEs45FVvddAjXFJ0q2tmKyLt+AcDul5p5MXLCT4P66lShxDnXdhF7ZTnT R2u2lkh9GRtmj+4xFQfK5D6gKcxhbD3Eenh1wgyOPzLfdWwBtpnmxF8hYArqha04/PlO FjZWdOuocDS/6Y1I8l+Pfb/MwQuLCZe9fBMHjcNajAI76XRds/Kpv0m51N5u2SP+y3lp X8pg== X-Gm-Message-State: AIkVDXJklKxqYoLxqokLvS7C6agIPBsMyX+4+iK+/R3Hxba/XArwiiPwKwP0BGhZg33mjFOh X-Received: by 10.223.148.2 with SMTP id 2mr31159175wrq.75.1485255087758; Tue, 24 Jan 2017 02:51:27 -0800 (PST) Received: from glumotte.dev.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id c132sm25796746wme.21.2017.01.24.02.51.27 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 24 Jan 2017 02:51:27 -0800 (PST) From: Olivier MATZ X-Google-Original-From: Olivier MATZ Date: Tue, 24 Jan 2017 11:51:20 +0100 To: Yuanhan Liu Cc: Olivier Matz , dev@dpdk.org, maxime.coquelin@redhat.com, huawei.xie@intel.com, stephen@networkplumber.org, "Tan, Jianfeng" , Tomasz Kulasek , Thomas Monjalon , Konstantin Ananyev Message-ID: <20170124115120.2c2667f4@glumotte.dev.6wind.com> In-Reply-To: <20170118050348.GO10293@yliu-dev.sh.intel.com> References: <1479977798-13417-1-git-send-email-olivier.matz@6wind.com> <1479977798-13417-6-git-send-email-olivier.matz@6wind.com> <20161214072750.GK18991@yliu-dev.sh.intel.com> <20170109184625.7884290a@platinum> <20170116064819.GL9770@yliu-dev.sh.intel.com> <20170117121825.3db48369@platinum> <20170118050348.GO10293@yliu-dev.sh.intel.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 5/5] net/virtio: fix Tso when mbuf is shared 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, 24 Jan 2017 10:51:28 -0000 On Wed, 18 Jan 2017 13:03:48 +0800, Yuanhan Liu wrote: > On Tue, Jan 17, 2017 at 12:18:25PM +0100, Olivier Matz wrote: > > > I hope I could have time to dig this further, since, honestly, I > > > don't quite like this patch: it makes things un-maintainable. > > > > Well, I'm not that proud of the patch, but that's the best solution > > I've found. Nevertheless saying it makes things un-maintainable > > looks a bit excessive to me :) > > Aha... really sorry about that! > > But honestly, I'd say again, it makes thing more complex, just for > fixing a corner and rare issue. I'd try to avoid that. > > > > > The option of reallocating a mbuf, copy and fix network headers in > > it looks even more complex to me (that was my first approach). > > > > > Besides that, I think we have similar issue with nic drivers. See > > > the rte_net_intel_cksum_flags_prepare() function introduced at > > > commit 4fb7e803eb1a ("ethdev: add Tx preparation"). > > > > Yes, that was discussed a bit. See [1] and the subsequent mails. > > http://dpdk.org/ml/archives/dev/2016-December/051014.html > > Thanks for the info, and I'm pretty Okay with that. > > > My opinion is that tx_burst() should not change the mbuf data, it's > > always been like this. For Intel NICs, there is no issue since the > > DPDK API is derived from Intel NICs API, so there is no fix to do > > in the mbuf data. > > > > For tx_prepare(), it's explicitly said that it can update the data. > > If tx_prepare() becomes mandatory, it will naturally fix this issue > > without modifying the driver, because the phdr csum calculation > > will be done in tx_prepare(). > > > > An alternative is to mark this as a known issue for now, and wait > > until tx_prepare() is mandatory. > > I see no reason to wait. Though my understanding is it may not be a > mandatory so far, but user is supposed to calculate the pseudo-header > checksum by themself before. Now they have one more option: > tx_prepare. > > That means, in either way, user has to do some extra works to make > TSO work (either by themself or call tx_prepare). So I don't think > it'd be an issue? Yes sounds good. I'll check how a tx_prepare() could be implemented for virtio, in order to fix this issue. In the meanwhile, for the 17.02, I think it could be good to highlight the problem in the known issues, what do you think? Thanks Olivier