From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) by dpdk.org (Postfix) with ESMTP id 619F85A26 for ; Fri, 13 Mar 2015 10:07:51 +0100 (CET) Received: by wesx3 with SMTP id x3so21876810wes.4 for ; Fri, 13 Mar 2015 02:07:51 -0700 (PDT) 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=RvPy1OtX3ydS7e2HvKvdoHP0IxMFQLcayZY6vx7hsTI=; b=kckP9cM85wQJhEa7cP9Meo02x3NMlu1OvQzL0RvBAeOUqTByZt8Crm1G2kiA4P/nwS RWkWgHCJeTHGApwhDlRza8uELsmUx8wkJabfXqBz/u6+yAACjkAZUydwZokLBUktbzaC YluvxJDIB7yWQ0BOX625H9t2Otxz94bAZwdvTussg6D/n0WdJvCNw3wBpjxO3aWxTcNR E7ocypv25MGB5icNcIXBt7zb9jKpDb2kWaMhqLucq11yYulL1uNoYKgQwL4/zZ7+LkvD I7yyJaAOBpPl1rAz4HQs/fOTcCjrHRUNcCJ/3eekZC5Fkc08+YEKHRTz8hLXMjrHk8XU eRhQ== X-Gm-Message-State: ALoCoQmoa0sRKuRxU/zWkZaXKLvXyFGWVTtwVf1YUw8YcWlq8ynzNHvPwTmCRGGUN0gIECHEIXeW X-Received: by 10.194.60.104 with SMTP id g8mr93191364wjr.96.1426237671209; Fri, 13 Mar 2015 02:07:51 -0700 (PDT) Received: from [10.16.0.195] (6wind.net2.nerim.net. [213.41.180.237]) by mx.google.com with ESMTPSA id ga8sm1907892wib.11.2015.03.13.02.07.50 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Mar 2015 02:07:50 -0700 (PDT) Message-ID: <5502A8E8.3010004@6wind.com> Date: Fri, 13 Mar 2015 10:07:52 +0100 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0 MIME-Version: 1.0 To: Vlad Zolotarov , "Ananyev, Konstantin" , "dev@dpdk.org" References: <1425928037-28732-1-git-send-email-vladz@cloudius-systems.com> <1425928037-28732-4-git-send-email-vladz@cloudius-systems.com> <2601191342CEEE43887BDE71AB977258213F5039@irsmsx105.ger.corp.intel.com> <54FEF011.6010205@cloudius-systems.com> <2601191342CEEE43887BDE71AB977258213F5475@irsmsx105.ger.corp.intel.com> <54FF63CB.4040506@cloudius-systems.com> <2601191342CEEE43887BDE71AB977258213F589B@irsmsx105.ger.corp.intel.com> <5500734A.7060800@cloudius-systems.com> In-Reply-To: <5500734A.7060800@cloudius-systems.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v6 3/3] 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: Fri, 13 Mar 2015 09:07:51 -0000 Hi Vlad, On 03/11/2015 05:54 PM, Vlad Zolotarov wrote: >>>> About the existing RX/TX functions and PPC support: >>>> Note that all of them were created before PPC support for DPDK was >>>> introduced. >>>> At that moment only IA was supported. >>>> That's why in some places where you would expect to see 'mb()' there >>>> are 'volatile' and/or ' rte_compiler_barrier' instead. >>>> Why all that places wasn't updated when PPC support was added - >>>> that's another question. >>>> From my understanding - with current implementation some of DPDK >>>> PMDs RX/TX functions and rte_ring wouldn't work correctly >>> on PPC. >>>> So, I suppose we need to decide for ourselves - do we really want to >>>> support PPC and other architectures with non-IA memory >>> model or not? >>>> If not, then I think we don't need any mb()s inside recv_pkts_lro() >>>> - just rte_compiler_barrier seems enough, and no point to >>> complain about >>>> it in comments. >>>> If yes - then why to introduce a new function with a known potential >>>> bug? >>> In order to introduce a new function with the proper implementation or >>> to fix any other places with the similar weakness I would need a proper >>> tools like a proper platform-dependent barrier-macros similar to >>> smp_Xmb() Linux macros that reduce to a compiler barrier where >>> appropriate or to a proper memory fence where needed. >> I understand that. >> Let's add new macro for that: rte_smp_Xmb() or something, >> so it would be just rte_compiler_barrier() for x86 and a proper mb() >> for PPC. > > There was an idea to use the C11 built-in memory barriers. I suggest we > open a separate discussion about that and add these and the appropriate > fixes in a separate series. There are quite a few places to fix anyway, > which are currently broken on PPC so this patch doesn't make things any > worse. However adding a new memory barrier doesn't belong to an LRO > functionality and thus to this series. This is an interesting discussion. Just for reference, I submitted a patch on this topic but it was probably too early as only Intel architecture was supported at that time. See http://dpdk.org/ml/archives/dev/2014-May/002597.html Regards, Olivier