From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by dpdk.org (Postfix) with ESMTP id 379A05424 for ; Thu, 22 Jan 2015 02:01:58 +0100 (CET) Received: by mail-pa0-f54.google.com with SMTP id eu11so22081517pac.13 for ; Wed, 21 Jan 2015 17:01:57 -0800 (PST) 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-type:content-transfer-encoding; bh=7EfxU9CciLY7EzmggCOTV+rm8f+YTTaUxTPiAVe4vJo=; b=mRv0sD0JBH8JnL12tdemF8BkdS+ZXqHDqalwgvX7tnNDRtq8zOJ+2/kd2w8KiilEW9 jP6rCo/juhXoTgQ49i8M9Uvh8pLQqrdTfXdph/XBfrCn61tUlEkchs0pSk1tjw9gG2YA b5BXTz/re5e2NIDHJAjmvEZ6OTTlv4QsL4mj6pole2NPX8mdejJZNLslc8VQSu69DGyU 1/rosA1jzBi6ThCXqMyR/7O8ZctinOmoLHdT5W4HDsZzf30vZJP/A9kVC9j7LrvLZqDo Cj/MzMmYG1hwSQxk9V4rZU5t4NBcn6Rj9HdSt/ueczhnlcJQKmPyUVHgmmfM1yBlrg46 4NEQ== X-Gm-Message-State: ALoCoQmEvWDQIKQH2FkVlzJVQEM1wUfnRhJuE5q9P1j3hKHYZ68oChgUd+vfN8WAdesv8BgjXDfy X-Received: by 10.68.196.99 with SMTP id il3mr67402317pbc.158.1421888517408; Wed, 21 Jan 2015 17:01:57 -0800 (PST) Received: from urahara (static-50-53-82-155.bvtn.or.frontiernet.net. [50.53.82.155]) by mx.google.com with ESMTPSA id fs1sm4239202pdb.16.2015.01.21.17.01.55 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Jan 2015 17:01:57 -0800 (PST) Date: Wed, 21 Jan 2015 17:01:49 -0800 From: Stephen Hemminger To: Olivier Matz Message-ID: <20150121170149.157da6ed@urahara> In-Reply-To: <1421883395-27235-1-git-send-email-olivier.matz@6wind.com> References: <1421883395-27235-1-git-send-email-olivier.matz@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [RFC 00/16] enhance checksum offload API 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: Thu, 22 Jan 2015 01:01:58 -0000 On Thu, 22 Jan 2015 00:36:19 +0100 Olivier Matz wrote: > The goal of this series is to clarify and simplify the mbuf offload API. > Several issues are solved: > > - simplify the definitions of PKT_TX_IP_CKSUM and PKT_TX_IPV4, each > flag has now only one meaning. No impact on the code. > > - add a feature flag for OUTER_IP_CHECKSUM (from Jijiang's patches) > > - remove the PKT_TX_UDP_TUNNEL_PKT flag: it is useless from an API point > of view. It was added because i40e need this info for some reason. We > have 3 solutions: > > - remove the flag and adapt the driver to the API (the choice I made > for this series). > > - remove the flag and stop advertising OUTER_IP_CHECKSUM in i40e > > - keep this flag, penalizing performance of drivers that do not > require the flag. It would also mean that drivers won't support > outer IP checksum for all tunnel types, but only for the tunnel > types having a flag. > > - a side effect of this API clarification is that there is only one > way for doing one operation. If the hardware has several ways to > do the same operation, a choice has to be made in the driver. > > The patch adds new tunnel types to testpmd csum forward engine. > Note: the i40e patches should be carefully checked by i40e experts. > > [1] http://dpdk.org/ml/archives/dev/2015-January/011127.html If you are doing this could you invert the meaning of the checksum flags? Right now the flags are fine for Intel hardware but are useless for devices that have less checksum support. It would work better if instead of two states: * Checksum known bad => PKT_RX_L4_CKSUM_BAD == 1 * Checksum (maybe) good => PKT_RX_L4_CKSUM_BAD == 0 The bit was changed to only flag good checksum: * Checksum known good => PKT_RX_L4_CKSUM_GOOD == 1 * Checksum status unknown => PKT_RX_L4_CKSUM_GOOD == 0 That way code code fallback to software checksum if hardware was incapable of handling the packet. It does mean packets with bad checksums get checked twice, but thats ok.