From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) by dpdk.org (Postfix) with ESMTP id 773C9181 for ; Wed, 4 Mar 2015 01:33:57 +0100 (CET) Received: by iecar1 with SMTP id ar1so63330173iec.11 for ; Tue, 03 Mar 2015 16:33: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=iGyUfZ/1WPRjv5z1z7W05grcXEIPMPV73uPjjuGbb58=; b=UKg2XyHct9z3VFohwmKiT4ZxW8D0fAyD0r4XKC1oaZIlx/l3L0+sbJ0pfh4qPO9uZC jHtOuEge0JVeBxXVrEsgpgkoU9qxjghIeBYO0WObM/J/mPBRWX+W073W+CyVg/uHh5Z4 BQWsumgh56mY6inX+gBofu3LJD3qYtdJ/lvumnipP8XeHIY28H7nPzluwjv4kWZugp78 oBaHHj9OgZvR3XkxGCoFzcn0oxPECY9Rmh/CE8Fa5vfrKUqQUFWuGtL0mXjTYFfgEVQT +U3DerhChuUD/K4J5pIil2lvD7X1T7W0fIfUfxOCW2yxpONPdH1QqE031Zn2HaArpWop hJ7Q== X-Gm-Message-State: ALoCoQls+KPnnnf5Ws++p38jxPk0u7GmVbx7SMeONOIg1zgKSrCcX7rm0FsuAWn179W4ahLBTJy0 X-Received: by 10.50.142.106 with SMTP id rv10mr6585403igb.18.1425429236847; Tue, 03 Mar 2015 16:33:56 -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 b14sm1943689iod.5.2015.03.03.16.33.56 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Mar 2015 16:33:56 -0800 (PST) Date: Tue, 3 Mar 2015 16:33:59 -0800 From: Stephen Hemminger To: Vlad Zolotarov Message-ID: <20150303163359.2975c702@urahara> In-Reply-To: <1425412123-5227-6-git-send-email-vladz@cloudius-systems.com> References: <1425412123-5227-1-git-send-email-vladz@cloudius-systems.com> <1425412123-5227-6-git-send-email-vladz@cloudius-systems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 00:33:57 -0000 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.