From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by dpdk.org (Postfix) with ESMTP id 736E91515 for ; Wed, 26 Nov 2014 15:44:20 +0100 (CET) Received: by mail-wi0-f174.google.com with SMTP id h11so12771671wiw.13 for ; Wed, 26 Nov 2014 06:55:17 -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 :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=UFxMcax6jGSSu7UOw0QSWuAtMlLgkh80rwBUHG4r3ew=; b=V8s70GostIlab2LerVDj36xdi4U0ic6kRO58rTYZDAopX4NqKv1PT5bVZnkGqw+5iM 5yqGqoc2RPaPtpPJvtG6Y+mqabwmz2HsONwEzEajPLz6GLSxq7FhYk8GkRcgfQWzTnzk JVpyOHsN7JT4OhFTbBKOBYCPipaZcna5qtjI6Sc1dOIIXfx1iro7e3OhDFA28T95o0pW ge4+jkkC6y8+NvsGUDAaWMJv7ynZwbh8tpLApeXiWPHEhJHgp5hIcYfQ/auRai22Vcyg ooyy+pUxo8lL7KnwKfpVhoVWDikPCVmKOLcANNyTTPsxZ1P190W5/WaPAmOqT1i1f5fj sj4A== X-Gm-Message-State: ALoCoQnZy6Z62jRr66KfxYMeOo0gETG63VyML+NCSc0PIJXbXU42C5gaJav7jlL97dkdrQ2fRCJG X-Received: by 10.180.108.167 with SMTP id hl7mr41948909wib.68.1417013717471; Wed, 26 Nov 2014 06:55:17 -0800 (PST) Received: from [10.16.0.195] (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by mx.google.com with ESMTPSA id eu15sm7578597wid.18.2014.11.26.06.55.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Nov 2014 06:55:17 -0800 (PST) Message-ID: <5475E9D4.6000607@6wind.com> Date: Wed, 26 Nov 2014 15:55:16 +0100 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: "Ananyev, Konstantin" , "dev@dpdk.org" References: <1415984609-2484-1-git-send-email-olivier.matz@6wind.com> <1416524335-22753-1-git-send-email-olivier.matz@6wind.com> <1416524335-22753-9-git-send-email-olivier.matz@6wind.com> <2601191342CEEE43887BDE71AB977258213BA62A@IRSMSX105.ger.corp.intel.com> <5475B622.8030705@6wind.com> <2601191342CEEE43887BDE71AB977258213BA869@IRSMSX105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB977258213BA869@IRSMSX105.ger.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "jigsaw@gmail.com" Subject: Re: [dpdk-dev] [PATCH v3 08/13] testpmd: rework csum forward engine 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: Wed, 26 Nov 2014 14:44:20 -0000 Hi Konstantin, On 11/26/2014 01:25 PM, Ananyev, Konstantin wrote: >> By the way (this is probably off-topic), but I'm wondering if the TX >> flags should have the same values than the RX flags: >> >> #define PKT_TX_IPV4 PKT_RX_IPV4_HDR >> #define PKT_TX_IPV6 PKT_RX_IPV6_HDR > > Thought about that too. > From one side, it is a bit out of our concept: separate RX and TX falgs. > From other side, it allows us to save 2 bits in the ol_flags. > Don't have any strong opinion here. > What do you think? I have no strong opinion too, but I have a preference for 2 different bit values for these flags: - as you say, it's matches the concept (RX and TX flags are separated) - 64 bits is a lot, we have some time before there is no more available bit... and I hope we it will never occur because it would become complex for an application to handle them all - it will avoid to send a packet with a bad info: - we receive a Ether/IP6/IP4/L4/data packet - the driver sets PKT_RX_IPV6_HDR - the stack decapsulates IP6 - the stack sends the packet, it has the PKT_TX_IPV6 flag but it's an IPv4 packet This is not a real problem as the flag will not be used by the driver/hardware (it's only mandatory for hw cksum / tso), but it can be confusing. Regards, Olivier