From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com [209.85.218.46]) by dpdk.org (Postfix) with ESMTP id 77AC0A2F for ; Tue, 14 Feb 2017 15:23:52 +0100 (CET) Received: by mail-oi0-f46.google.com with SMTP id u143so69625955oif.3 for ; Tue, 14 Feb 2017 06:23:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thezims-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3l6WrBH86r6vycsIFSozK9TrTB4R9h9xvdVHokvflYQ=; b=aalgO+g1vZVxgpvaIfOyaRwzFKirnxTfF/k1PWrYKa9bByhQQFaApHyA89fjmIimJb vsCKL2PIESrL6p4DI6lZPo6epj4aHWPJLUkOXK1IlD7+ehBp3pX210/tzKvaTIejEwE0 q3zbb/wRnMKdsGb5OAgz4Pb6Axo8YDJAvu4avmF2fF/3bMDGjWnJpqCfudejmil0TBxh lTNzdAdQw6/mpsBpoyat6Vo1jZa9NP3CdaAwyeYd+MkOZqVnVn5TzTPsp+Brzt57hyCe j7H7SVNnXGN8OePOxS8BEBc3erx8ZCEibyl7vyS4Kn34Bn8y5AGrvb0PiXxEhdBVDvo2 Gizg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3l6WrBH86r6vycsIFSozK9TrTB4R9h9xvdVHokvflYQ=; b=f30guvYNWneJ8UrMqHLdCq24scEkkxAeBcDEk+PyxOrGnANJ2LoJYV02X3sItAyIwA Uq2qiKGI74+IPV5X9mQ0uoOxfAkcLeYWxFi01zq/4bEOBXFqtrxJjqdo+I33vAS6JtWr H/ZUrf4h6pBHqRwosflB4JoeNN0421yaoF1UXSGa6JA+tOuBlqXJk1chijrkh5+4J5Uz 2zKYuMIL9SLXt0WuraWrJ+RKXdDq1arCg3DknsLyI523CaxJyZ27FTgaOXNaTIT146sO O/v6COnu/+2C5/sq7+LsGbL18M4tqcMncBuSAjcWdrnVqTsIPilpWmDoOV/sfRgPp2nZ Vk8g== X-Gm-Message-State: AMke39l83IYW2cN+ppC7IjFW4j7pUe3kPMCqzyKVZV4dDOW8YYXpRXkT6FgkjW8dSLYw+Qqx9Bh7+hArtz5RuRAQ X-Received: by 10.202.207.211 with SMTP id f202mr16930894oig.162.1487082231719; Tue, 14 Feb 2017 06:23:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.173.78 with HTTP; Tue, 14 Feb 2017 06:23:21 -0800 (PST) In-Reply-To: References: From: Rob Zimmerman Date: Tue, 14 Feb 2017 09:23:21 -0500 Message-ID: To: "De Lara Guarch, Pablo" Cc: "users@dpdk.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-users] Is Elastic Flow Distributor thread-safe? X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 14:23:52 -0000 Hi Pablo, That was my assumption. I peeked at the EFD implementation and saw the memcpy's which are definitely not multi-producer safe. What I ended up doing is throwing together a ring buffer for the one core which will perform the EFD update. All other cores just send their updates to that core and it processes them, doing updates. Thanks so much for the confirmation! -Rob On Tue, Feb 14, 2017 at 9:14 AM, De Lara Guarch, Pablo < pablo.de.lara.guarch@intel.com> wrote: > Hi Rob, > > > -----Original Message----- > > From: users [mailto:users-bounces@dpdk.org] On Behalf Of Rob > > Zimmerman > > Sent: Monday, February 13, 2017 2:26 PM > > To: users@dpdk.org > > Subject: [dpdk-users] Is Elastic Flow Distributor thread-safe? > > > > Hi Everyone, > > > > Playing around with EFD and seeing some really bizarre behavior in a > > multi-core environment. Is it safe for multiple logical cores to be > making > > EFD table updates while another logical core is performing lookups? Side > > note: the core which is making lookups is where the offline table > resides. > > > > Intuition tells me this is probably not safe, but the docs make no > mention > > of thread safety. > > The library is not thread-safe. The only operation that is thread safe is > the lookup. > > However, although update is not thread safe, it is interesting to know the > following. > Updating the EFD table consists of two steps: > > 1 - Compute Update: the new key is added to the offline group, which is > not thread safe. > Then, a new perfect hash for the group is computed (thread safe and > where most of time is spent). > > 2 - Apply Update: Once the update is computed, it has to be applied to the > online table (fast, but not thread safe). > > Multi-writer support might be added in the future, as it was added in the > Hash library. > > For now, several readers can work simultaneously, as long as there is no > writer working on it (you would need locks for this), > and only a single writer is supported if there is no other core doing > lookups. > > > > > Thanks, > > -Rob >