From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) by dpdk.org (Postfix) with ESMTP id BAC5F106B for ; Wed, 4 Mar 2015 08:57:26 +0100 (CET) Received: by wesu56 with SMTP id u56so44577785wes.10 for ; Tue, 03 Mar 2015 23:57:26 -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=88TC8/RkmJAz87AzfNAtornBG1Q5vJblYyhaeeZ/sy0=; b=jME1IoJyV+/Sq2BVOiK7FcngoJKQO5m9pE1z1gN/UeHG9M0BeJMSGN8FkK39IQs9+n VL5A3vZubXI/t9RCueg8tXIEFa8fZ4eaR0woi03v4q5GgJM8d4W/+weGnA816I5d4/Ls 0lqGAJeW9Xm7eZTSkuSw+Y7WrFpF9gWdOKHMLw0HI/YOCxvahDCXiUHR8eJAfAIO17O7 PFsqhZazUeby2PSgApv9XK+dkNnr68PEAgDXCF8O7dz6aGmOzSX5/O9KxiySR9QgqxL9 UKOrdRnlDRpD1j3BBFaU03Ao7S+RlLAb9QZt3WSfVSlzTYwAsHEdhw7VqdRmfosl+hnp kEyQ== X-Gm-Message-State: ALoCoQkudykTmHtzWNWwMNHTG6caQ9oIs0F7r9Djkx0j1lZ/W8faGFZbRKn0hu1PqjcqGSRCcjzy X-Received: by 10.181.8.99 with SMTP id dj3mr53538001wid.83.1425455846592; Tue, 03 Mar 2015 23:57:26 -0800 (PST) Received: from [10.0.0.2] (bzq-109-65-117-109.red.bezeqint.net. [109.65.117.109]) by mx.google.com with ESMTPSA id cf12sm4766978wjb.10.2015.03.03.23.57.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Mar 2015 23:57:26 -0800 (PST) Message-ID: <54F6BAE4.8020102@cloudius-systems.com> Date: Wed, 04 Mar 2015 09:57:24 +0200 From: Vlad Zolotarov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Stephen Hemminger References: <1425412123-5227-1-git-send-email-vladz@cloudius-systems.com> <1425412123-5227-6-git-send-email-vladz@cloudius-systems.com> <20150303163359.2975c702@urahara> In-Reply-To: <20150303163359.2975c702@urahara> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v1 5/5] ixgbe: Add LRO support 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, 04 Mar 2015 07:57:27 -0000 On 03/04/15 02:33, Stephen Hemminger wrote: > On Tue, 3 Mar 2015 21:48:43 +0200 > Vlad Zolotarov wrote: > >> + next_desc: >> + /* >> + * The code in this whole file uses the volatile pointer to >> + * ensure the read ordering of the status and the rest of the >> + * descriptor fields (on the compiler level only!!!). This is so >> + * UGLY - why not to just use the compiler barrier instead? DPDK >> + * even has the rte_compiler_barrier() for that. >> + * >> + * But most importantly this is just wrong because this doesn't >> + * ensure memory ordering in a general case at all. For >> + * instance, DPDK is supposed to work on Power CPUs where >> + * compiler barrier may just not be enough! >> + * >> + * I tried to write only this function properly to have a >> + * starting point (as a part of an LRO/RSC series) but the >> + * compiler cursed at me when I tried to cast away the >> + * "volatile" from rx_ring (yes, it's volatile too!!!). So, I'm >> + * keeping it the way it is for now. >> + * >> + * The code in this file is broken in so many other places and >> + * will just not work on a big endian CPU anyway therefore the >> + * lines below will have to be revisited together with the rest >> + * of the ixgbe PMD. >> + * >> + * TODO: >> + * - Get rid of "volatile" crap and let the compiler do its >> + * job. >> + * - Use the proper memory barrier (rte_rmb()) to ensure the >> + * memory ordering below. > This comment screams "this is broken". > Why not get proper architecture independent barriers in DPDK first. This series is orthogonal to the issue above. I just couldn't stand to mention this ugliness when I noticed it on the way. Note that although this is obviously not the right way to write this kind of code it is still not a bug and most likely the performance implications are minimal here. The only overhead is that there may be read "too much" data from the descriptor that we may not actually need. The descriptor is 16 bytes so this doesn't seem to be a critical issue. So, fixing the above issue may wait, especially since the same s..t may be found in other Intel PMDs (see i40e for example). Fixing this issue should be a matter of a massive cleanup series that cover all the relevant PMDs. Of course we may start with ixgbe but even in this single PMD there are at least 3 non-LRO related functions that have to be fixed, so IMHO even fixing ONLY ixgbe should be a matter of a separate series.