From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) by dpdk.org (Postfix) with ESMTP id CA71237B8 for ; Tue, 31 May 2016 22:58:59 +0200 (CEST) Received: by mail-wm0-f44.google.com with SMTP id z87so3800145wmh.0 for ; Tue, 31 May 2016 13:58:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=alJZU2e4/fgvMqRodnJpHUBnkxF/J3wBLrr/xUUML9c=; b=JMUPMP0VMRhoJtGzYv/TlBq1oLpSzJqE7xwtLkDFctMIHqrHSzFD6WhbVm7tchRJN5 H9/qbDRHLgpxUDkDdOGZU/Lnl7fvSfPF0ZCbHNYrxT7iZeQkE9qPrnzgsGQBvUE4tNWZ DYPcdwuUeP0G6d1OSocHj4vW20j+A+SnrfIkxnQXPxdd5PSKBaAnwnFrk9lmRQmX3MP0 D+nkxHYMiB/X3YZAmQj1x8L6WV3ofGxvOCitFXwhL3IKFV0y0EkxBpgeHBI7EK5kTVMd XhsqDnmW2GEl/Ac31oge5bd5BuReAaxKT/2ZO0B14Zj4oPW7A74N93g658wyheVgPEOB 2UPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=alJZU2e4/fgvMqRodnJpHUBnkxF/J3wBLrr/xUUML9c=; b=S07hgRzpDXVczcrq4JywfBuEpSPXSVIHk/9egQOhowAUpoDtBimZEWnPApywfFQojM fW/SFOrNdrrYfUzR1tXCJyYKfGGFRe0iDuU0G2XKocWxCXmWwrc1pN7bhN84Ufoc6zaN WsQe5NlIeUuZzyP44nZ07cZ+XQNjBDRkfWhxVI0Em1Fl+r8k44KzB1QsaXBKd3Sc/EJJ tiglyiz7iBY0T4p6Zc+r7qxIB6+F2qqzJaN3DKKSYqq961pIZ87PYytTZQlNlPpbtuN1 nRk77OPeXMrZZASO0uHyixVpeYohMbi7xGmUGQk85K0n9XhTAbPNKT1PSDi9eXXRaKY5 LjIw== X-Gm-Message-State: ALyK8tKA1TihZwpgcbZLnRtaihxvEcvAs9sLGiU+nx/uMrXOPpUk4yVrozcSqWBKBh9wN5SA X-Received: by 10.28.98.215 with SMTP id w206mr16942963wmb.79.1464728339548; Tue, 31 May 2016 13:58:59 -0700 (PDT) Received: from [192.168.0.16] (85-171-34-230.rev.numericable.fr. [85.171.34.230]) by smtp.gmail.com with ESMTPSA id cz3sm41827560wjb.14.2016.05.31.13.58.58 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 May 2016 13:58:58 -0700 (PDT) To: Stephen Hemminger References: <574C5B9D.4080006@6wind.com> <20160531080916.GI5641@yliu-dev.sh.intel.com> <574DE1FF.6060402@6wind.com> <20160531132820.4fadfc2e@xeon-e3> Cc: Yuanhan Liu , "dev@dpdk.org" , "Ananyev, Konstantin" , "Richardson, Bruce" , Adrien Mazarguil , "Tan, Jianfeng" From: Olivier MATZ Message-ID: <574DFB11.5020701@6wind.com> Date: Tue, 31 May 2016 22:58:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160531132820.4fadfc2e@xeon-e3> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] about rx checksum flags X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 20:59:00 -0000 Hi Stephen, On 05/31/2016 10:28 PM, Stephen Hemminger wrote: > On Tue, 31 May 2016 21:11:59 +0200 > Olivier MATZ wrote: > >> >> >> On 05/31/2016 10:09 AM, Yuanhan Liu wrote: >>> On Mon, May 30, 2016 at 05:26:21PM +0200, Olivier Matz wrote: >>>> PKT_RX_L4_CKSUM_NONE: the L4 checksum is not correct in the packet >>>> data, but the integrity of the L4 header is verified. >>>> -> the application can process the packet but must not verify the >>>> checksum by sw. It has to take care to recalculate the cksum >>>> if the packet is transmitted (either by sw or using tx offload) >>> >>> I like the explanation you made at [1] better :) >>> >>> So in general, I think this proposal is good to have. >> >> Thanks everyone for your feedback. >> >> I'll try to send a first patch proposition soon. >> >> Regards, >> Olivier > > I think it is time to ditch the old definitions of Rx checksum and instead > use something more compatiable with virtio (and Linux). I.e have three values > 1) checksum is know good for packet contents > 2) checksum value one's complement for packet contents > 3) checksum is undetermined > The original definition seems to be Intel HW centric and applies to a limited > range of devices making it unusable by general application. > > Break the ABI, and ditch the old values (ok mark PKT_RX_L4_CKSUM_BAD as __deprecated > and remove all usage). > Don't you think knowing that a checksum is bad could be useful? In that case the application can drop/log the packet without any additional cpu cost. What do you mean by beeing unusable by general application? I think the "2)" also requires a csum_start + csum_offset in mbuf structure, right? Do you also suggest to drop IP checksum flags? Will it be possible to manage tunnel checksums? I think this would be a pretty big change. If there is no additional argument than beeing more compatible with virtio/linux, I'm wondering if it's worth breaking the API. Let's wait for other opinions. Thanks for your feedback. Olivier