From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH 0/3] New Thread Safe Hash Library Date: Thu, 18 Sep 2014 17:45:17 +0200 Message-ID: <12060866.mqQxRznRol@xps13> References: <1411036471-3822-1-git-send-email-pablo.de.lara.guarch@intel.com> <20140918122129.GD20389@hmsreliant.think-freely.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev-VfR2kkLFssw@public.gmane.org To: "De Lara Guarch, Pablo" Return-path: In-Reply-To: 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" 2014-09-18 15:31, De Lara Guarch, Pablo: > From: Neil Horman [mailto:nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org] > > Thread safe hash tables seem to me like a configuration option rather than > > a new > > library. Instead of creating a whole new library (with a new API and ABI > > to maintain, why not just add thread safety as a configurable option to > > the existing hash library. That saves code space in the DPDK, and > > reduces application complexity (as the same api is useable for thread > > safe and unsafe hash tables) > > Makes sense, but implementation has changed so much to add it directly into > the existing library. At first, this was designed to be a replacement of > the existing library, but since API is a bit different from the old one, it > was thought to leave it as an alternative, so users are not forced to have > to change their applications if they don't want to use thread safe hash > tables. It makes me smile :) You basically explain that it's more complicated to properly merge two different implementations than just throwing a new one in the big DPDK bucket. My opinion is that it should not be integrated as is because we must try to make DPDK something else than a trash bucket. Thanks for continuing your effort to make DPDK easier and better. -- Thomas