From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f171.google.com (mail-pf0-f171.google.com [209.85.192.171]) by dpdk.org (Postfix) with ESMTP id 5CF5837A0 for ; Wed, 1 Jun 2016 00:02:36 +0200 (CEST) Received: by mail-pf0-f171.google.com with SMTP id 62so684195pfd.1 for ; Tue, 31 May 2016 15:02:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=Ofavc0fBJKoAxzY/+8dOrsr9LOiznu891Jc0meiPCfg=; b=1Nu4bDxvpVfk/GjLbZruM3hrof50eGxSaT4T2CyJIWgYqjVn0UqNRs4Nz2I3yX6jhv 1fV2/TW9s+dwtyog+HBwT8gFnLtrS4RpfLNNtUkgeu52O06iiRCFcaBrWs1PXs7Jyk4X 4cSIqXeyNyAUWaV4Us84d+OurThlTOeWBrfAlLKzWS0o+btX2DGlr/1lMfYTRtYXff+5 YOLskg29BU4svKVOis8/LvXp1XQ2AHURouS55UB5/dyZGEd5FIXbSrgKaPhKSmRNkutb eOXThApRT9r3OYreuMN4bskFFEx5I87gX7/Nr8NIhBSl9aFEPRZ1Ipen9lWA35k1No8x r9aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=Ofavc0fBJKoAxzY/+8dOrsr9LOiznu891Jc0meiPCfg=; b=Agdl/bh4vmh3Mwvzv5c1aUbzlDGmGf2CgM3BA5Rjzen+z9WGBIEQ+jfEmzhDOnfJvz yaZIuC3bJepNshW0uI2CqUrrrkBqA2Vp3Pe8PgalQkTK0FZYryjAoPQCpDMK2NCyELuo ncM72QZXi4SmqM5HwRi2GYt7tBxxLkXlseudC5jWv42TSkxCh15mxqSQ54Lqz2v/Cpmt XBZlovY5VG3c8QVLo8L0K7yABSOJeOqlBX7yB7vW1+H1FgYoqyQHPIba4945AWiS25wT 6jtU0oFMV6rpb78De+k6Hzo3X8lFxjsIWnrSbgCH7ihijktE1uiXeNho/42N7PCTZtMH OqoQ== X-Gm-Message-State: ALyK8tI1jsEbcI1f3BomecZ9La1HtdL3oxCP5as0pEQqIjOYMj1/bx92+kSbS1iK2x3rJg== X-Received: by 10.98.25.212 with SMTP id 203mr724690pfz.94.1464732155505; Tue, 31 May 2016 15:02:35 -0700 (PDT) Received: from xeon-e3 (static-50-53-72-186.bvtn.or.frontiernet.net. [50.53.72.186]) by smtp.gmail.com with ESMTPSA id t77sm42584277pfa.71.2016.05.31.15.02.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 May 2016 15:02:35 -0700 (PDT) Date: Tue, 31 May 2016 15:02:47 -0700 From: Stephen Hemminger To: Olivier MATZ Cc: Yuanhan Liu , "dev@dpdk.org" , "Ananyev, Konstantin" , "Richardson, Bruce" , Adrien Mazarguil , "Tan, Jianfeng" Message-ID: <20160531150247.15819f1d@xeon-e3> In-Reply-To: <574DFB11.5020701@6wind.com> References: <574C5B9D.4080006@6wind.com> <20160531080916.GI5641@yliu-dev.sh.intel.com> <574DE1FF.6060402@6wind.com> <20160531132820.4fadfc2e@xeon-e3> <574DFB11.5020701@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 22:02:36 -0000 On Tue, 31 May 2016 22:58:57 +0200 Olivier MATZ wrote: > 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? Not really. They should be mark as undetermined, then software can recheck for the possibly buggy hardware. > 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? Right now application can only see "known bad" or "indeterminate" there is no way to no which packets are good. Since good is the desired/expected case, software has to checksum every packet. > > I think the "2)" also requires a csum_start + csum_offset in > mbuf structure, right? Not really, it would mean having a way to get the raw one's complement sum out of the hardware. This is a good way to support the tunnel protocol du jour without having to have firmware support. Unfortunately, most hardware vendors don't believe in doing it that way. > Do you also suggest to drop IP checksum flags? IP checksum offload is mostly useless. If application needs to look at IP, it can do whole checksum in very few instructions, the whole header is in the same cache line as src/dst so the HW offload is really no help. > > 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