From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by dpdk.org (Postfix) with ESMTP id B164D9AEF for ; Tue, 3 Feb 2015 09:55:06 +0100 (CET) Received: by mail-wg0-f46.google.com with SMTP id l2so43298643wgh.5 for ; Tue, 03 Feb 2015 00:55:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=esA2nQ7LsW6aFVEyvzjKk3Dgfa2SQrutvzSvP8++ETE=; b=DvmBSdLH5cYOrsrrNuRWdjNwcVQ2r2U1KCR5h2DFc1sSmaDyy7KiBSa1AyjTW2LKXG 9drEHwO3oXVy5bx0yFimzDA22tREZZg+L3jgbtU4g+LzoHN3IY7enBf8XGEHoWRNMJZ0 XM9QRoPk3yFcyQiL8ljcgYC3ZJzzpnqJCci5RKMR8w+31OImM980/paawI32uOZUAEEU RUi1ujD7NIBlC3oFY7TW7gp2OGTjhagajymurI4VDxK3vz3YH78EhUBRQZ2fCHB5W8Tv slo4hAlyp8hH/rqbWbBOB+mOB7y8CY54T3NfhvpFlGduF1lL+0/qsNWMznvStkOzdDZM 9Xnw== X-Gm-Message-State: ALoCoQlqtqxWOBZCpvvkm9mcZRqN0dXjKsPD4mCok+WZrvSZnpdGh05B4VFmd3rmJszlHRFe0qG7 X-Received: by 10.194.22.36 with SMTP id a4mr51873477wjf.54.1422953706538; Tue, 03 Feb 2015 00:55:06 -0800 (PST) Received: from [10.16.0.195] (6wind.net2.nerim.net. [213.41.180.237]) by mx.google.com with ESMTPSA id pl1sm10973425wic.23.2015.02.03.00.55.05 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Feb 2015 00:55:05 -0800 (PST) Message-ID: <54D08CE8.6030902@6wind.com> Date: Tue, 03 Feb 2015 09:55:04 +0100 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.2.0 MIME-Version: 1.0 To: "Ananyev, Konstantin" , "Zhang, Helin" , "dev@dpdk.org" References: <1421637666-16872-1-git-send-email-helin.zhang@intel.com> <1422501365-12643-1-git-send-email-helin.zhang@intel.com> <54CB879D.2010505@6wind.com> <54CF617B.5010009@6wind.com> <2601191342CEEE43887BDE71AB977258213E28EC@irsmsx105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB977258213E28EC@irsmsx105.ger.corp.intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 00/17] unified packet type 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, 03 Feb 2015 08:55:06 -0000 Hi Konstantin, On 02/02/2015 06:20 PM, Ananyev, Konstantin wrote: >> I think the API should describe for each packet type what can be >> expected by the application. Here is an example. When a driver sets the >> RTE_PTYPE_L3_IPV4 type, it means that: >> >> - the layer 3 is identified as IP by underlying layer (ex: ethertype=IP >> if layer 2 is ethernet) >> - the IP version field is 4 >> - there is no IP options (i.e the size of header is 20) > > Yes, I suppose that's what supported HW can guarantee when RTE_PTYPE_L3_IPV4 is set. > >> - the checksum field has been verified by hw, and if wrong, the >> flag PKT_RX_IP_CKSUM_BAD is set > > Hmm, why is that? > As I remember on many devices it is configurable by SW should HW do RX checksum offload or not. > From DPDK point of view there is hw_ip_checksum field in rte_eth_rxmode. > So it is a possible situation, when at RX HW does packet type determination, but doesn't make L3/L4 > checksum calculation. > > I suppose for checksum(s) it should be a separate flags (in ol_flags) with 3 possible values: > CKSUM_UNKNOWN, CKSUM_BAD, CKSUM_OK. Indeed you are right, it's probably better to have specific flags for checksum. Regards, Olivier