From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [PATCH 0/7] Add Membership Library Date: Mon, 21 Aug 2017 21:01:32 -0700 Message-ID: <20170821210132.5dd74b10@xeon-e3> References: <1503361193-36699-1-git-send-email-yipeng1.wang@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: vincent.jardin@6wind.com, bruce.richardson@intel.com, konstantin.ananyev@intel.com, thomas@monjalon.net, dev@dpdk.org, charlie.tai@intel.com, sameh.gobriel@intel.com, ren.wang@intel.com To: Yipeng Wang Return-path: Received: from mail-pg0-f42.google.com (mail-pg0-f42.google.com [74.125.83.42]) by dpdk.org (Postfix) with ESMTP id 0C10811D4 for ; Tue, 22 Aug 2017 06:01:34 +0200 (CEST) Received: by mail-pg0-f42.google.com with SMTP id i12so110575995pgr.3 for ; Mon, 21 Aug 2017 21:01:34 -0700 (PDT) In-Reply-To: <1503361193-36699-1-git-send-email-yipeng1.wang@intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Mon, 21 Aug 2017 17:19:46 -0700 Yipeng Wang wrote: > This patch set implements two types of set-summaries, i.e., hash-table based > set-summary (HTSS) and Vector Bloom Filter (vBF). HTSS supports both the > non-cache and cache modes. The non-cache mode can incur a small chance of > false-positives which is the case when the set-summary indicates a key belongs > to a given set while actually it is not. The cache mode can also have > false-negatives in addition to false-positives. False-negatives means the case > when the set-summary indicates a key does not belong to a given set while > actually it does. This happens because cache mode allows new key to evict > existing keys. vBF only has false-positives similar to the non-cache HTSS. > However, one can set the false-positive rate arbitrarily. HTSS's > false-positive rate is determined by the hash-table size and the signature size. I don't think it makes sense to merge two different types of tables in one API. Especially in DPDK where every cycle counts. You are taking an extra branch on each lookup. The user of this API is likely to know exactly what type of objects and look are desired.