From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f176.google.com (mail-pf0-f176.google.com [209.85.192.176]) by dpdk.org (Postfix) with ESMTP id EDB667D0D for ; Fri, 2 Jun 2017 22:51:38 +0200 (CEST) Received: by mail-pf0-f176.google.com with SMTP id m17so56909992pfg.3 for ; Fri, 02 Jun 2017 13:51:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=5Oj0HcpNL9Pf597yqS8gP9Ytw1dXx4EvbLKhqbTgcDU=; b=KPAt+tCyWkfmdxl1jcOc02hqZreHMpwFttXE4I2wTBKw+NFLjJko2Qls1ME1M14CNE PrnkFYMQRFtklYbyVFzRdLTTDBuHKG6bboNrqYodc/nWRJrJfkZtD456jIg0grGoNC6r SPSg5qppFOBDKgdwDQ4xVDeU8v6uINqJJlT9WuybHRX3ZSSED7BGNgNPdSwBRwrPxhu+ C09S7cbCLaT451+E1LDNSfR92M1dQ0wlMWQ5DAXY7gMeOtYcO1CXYKL8Vsx1DJO7mwU4 ctqwCKFFaDr2grswZPVTKa95LjwUruYabO3ALGnl5A/y4wla7PjPCj6v3YqF9dnt4Yyp MKdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=5Oj0HcpNL9Pf597yqS8gP9Ytw1dXx4EvbLKhqbTgcDU=; b=VwKQVs1JAepBDtay/yrnuZN9iJvPJKQIRIKrADJf84fkAK7hP6ApA8EOMo1XwzbD70 +f1rtrzI6+lbtXB05WQjXG4y2ONifakuDpls2lQ764TL2rJv/by0HwFv0So+F0TwzrU9 DqAU93sVjC0pKgIrzWZMlcaMEksyaMVyc6wGhxsu60K2OMyeVgg0XgI+J6oYdVQYd0ew 9NMMG27jSBfhpgJ+4QljVW5A9/MOQm0yPeKwpT/j9EgraxKNFnMuH94tnSCE1i093D22 eJ3S1WxACPWTxdlIPKFe/pt0SuvmtRRwpsYOgW+3v9oLT6UKQHtN5hmMSrG4N17ur+ts d7Xw== X-Gm-Message-State: AODbwcC0Z93QfVTlPJ3imjmzr4rUwcscWV9U8psAeLnmIf1IcajXhnrR AYKwR57wjWwl4ztl X-Received: by 10.99.7.138 with SMTP id 132mr8966020pgh.171.1496436698198; Fri, 02 Jun 2017 13:51:38 -0700 (PDT) Received: from xeon-e3 (76-14-207-240.or.wavecable.com. [76.14.207.240]) by smtp.gmail.com with ESMTPSA id k86sm41387352pfk.125.2017.06.02.13.51.37 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 02 Jun 2017 13:51:38 -0700 (PDT) Date: Fri, 2 Jun 2017 13:51:31 -0700 From: Stephen Hemminger To: "Wang, Yipeng1" Cc: Vincent Jardin , "dev@dpdk.org" , "Gobriel, Sameh" , "Wang, Ren" , "Tai, Charlie" Message-ID: <20170602135131.25fae7f7@xeon-e3> In-Reply-To: References: <1495848888-54621-1-git-send-email-yipeng1.wang@intel.com> <15c49491fa0.27fc.bb328046f2889bc8f44aafa891a44dd2@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [RFC] Add Membership Library X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 20:51:39 -0000 On Thu, 1 Jun 2017 01:03:36 +0000 "Wang, Yipeng1" wrote: > Hi Vincent, > > Thanks for the comments and some quick responses below: > > - DPDK Bloom Filter is derived from the libbloom (as shown by the included BSD license), but optimized for performance with various DPDK goodness such as rte_zmalloc, rte_bitmap, rte_jhash, etc. It doesn't seem appropriate to bring those DPDK specific features into libbloom, which is designed for more generic environments. > - DPDK Bloom Filter is just one very basic mode among other more sophisticated ones in the DPDK Membership Library, which supports a different set of APIs (e.g., bulk lookup, multi-match, etc.) than those supported in libbloom. > - It may make sense to bring some generic (i.e., non DPDK specific) improvements back to libbloom once identified. > > Thanks > Yipeng > > > -----Original Message----- > > From: Vincent Jardin [mailto:vincent.jardin@6wind.com] > > Sent: Saturday, May 27, 2017 2:42 AM > > To: Wang, Yipeng1 > > Cc: dev@dpdk.org; Gobriel, Sameh ; Wang, Ren > > ; Tai, Charlie > > Subject: Re: [dpdk-dev] [RFC] Add Membership Library > > > > Why duplicating Jyri's libbloom - https://github.com/jvirkki/libbloom - for this > > DPDK capability? Why not showing that you can contribute to libbloom and > > make it linkable with the DPDK? > > > > There are so many duplicated code... > > > > Thank you, > > Vincent > > > Note: rte_zmalloc is really no faster in my experience than regular malloc. And under memory pressure rte_malloc is worse than malloc.