From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) by dpdk.org (Postfix) with ESMTP id DA9012C7A for ; Tue, 10 Feb 2015 17:53:02 +0100 (CET) Received: by mail-we0-f177.google.com with SMTP id l61so34780135wev.8 for ; Tue, 10 Feb 2015 08:53:02 -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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Xwc1Ngt3hPSNk0Mm5p3w0BJt0CCIc9yVII1JWDPdWGM=; b=L9/c2YSaMgjCVjiZM3XS9YAJTi0JM6vWQvq/FClCesdOpPu1vDptZDPumxhiCgLE5r jreXnS0vHaN4d23YPPOamf12Mh41YHtXR+xh/+V05ahJVYBu1AUMhfA1ivwCaZ3JSPfq N2vskCRbTzmYLfmoezBoR51uuHDcXKOQ3a1lmOHKjlmiAuxnzuNCmt8bApK93oQAqMpU JR5WPCjtsU3drVe8A6EhQk0Qi1urpI9Gwxsi4/b6Dx+DbvBboJC/I6oj8tU6W9+RPRqo wSEeAuYsG7SDkGmxVoYFYK7gJDeZPd52+sa1Iy/Y0c7b5zPeyVry1T00QxrF017ih5LW Rsog== X-Gm-Message-State: ALoCoQlFNe8T8hHV9Ao1bIpS/k/GCFKGFHA+MtLEnVyo4KYHZYYIrbe9lDal8XjNr7xajWqakA3A X-Received: by 10.180.79.131 with SMTP id j3mr37729343wix.33.1423587182680; Tue, 10 Feb 2015 08:53:02 -0800 (PST) Received: from [10.16.0.195] (6wind.net2.nerim.net. [213.41.180.237]) by mx.google.com with ESMTPSA id pl1sm19567185wic.23.2015.02.10.08.53.01 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Feb 2015 08:53:02 -0800 (PST) Message-ID: <54DA376D.2070709@6wind.com> Date: Tue, 10 Feb 2015 17:53:01 +0100 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.2.0 MIME-Version: 1.0 To: "Ananyev, Konstantin" , "Liang, Cunming" , "dev@dpdk.org" References: <1422491072-5114-1-git-send-email-cunming.liang@intel.com> <1422842559-13617-1-git-send-email-cunming.liang@intel.com> <1422842559-13617-17-git-send-email-cunming.liang@intel.com> <54D4DB9F.6080601@6wind.com> <2601191342CEEE43887BDE71AB977258213E461C@irsmsx105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB977258213E461C@irsmsx105.ger.corp.intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v4 16/17] ring: add sched_yield to avoid spin forever 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: Tue, 10 Feb 2015 16:53:03 -0000 Hi Konstantin, On 02/09/2015 04:43 PM, Ananyev, Konstantin wrote: >> The ring library was designed with the assumption that the code is not >> preemptable. The code is lock-less but not wait-less. Actually, if the >> code is preempted at a bad moment, it can spin forever until it's >> unscheduled. >> >> I wonder if adding a sched_yield() may not penalize the current >> implementations that only use one pthread per core? Even if there >> is only one pthread in the scheduler queue for this CPU, calling >> the scheduler code may cost thousands of cycles. >> >> Also, where does this value "RTE_RING_PAUSE_REP 0x100" comes from? >> Why 0x100 is better than 42 or than 10000? > > The idea was to have something few times bigger than actual number > active cores in the system, to minimise chance of a sched_yield() being called > for the case when we have one thread per physical core. > My thought was that having that many repeats would make such chance neglectable. > Though, right now, I don't have any data to back it up. > >> I think it could be good to check if there is a performance impact >> with this change, especially where there is a lot of contention on >> the ring. If it has an impact, what about adding a compile or runtime >> option? > > Good idea, probably we should make RTE_RING_PAUSE_REP configuration option > and let say avoid emitting ' sched_yield();' at all, if RTE_RING_PAUSE_REP == 0. Yes, it looks like a good compromise. Olivier