From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olivier MATZ Subject: Re: [PATCH v6 3/3] ixgbe: Add LRO support Date: Fri, 13 Mar 2015 10:07:52 +0100 Message-ID: <5502A8E8.3010004@6wind.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit To: Vlad Zolotarov , "Ananyev, Konstantin" , "dev-VfR2kkLFssw@public.gmane.org" Return-path: In-Reply-To: <5500734A.7060800-RmZWMc9puTNJc61us3aD9laTQe2KTcn/@public.gmane.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" 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