From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by dpdk.org (Postfix) with ESMTP id 97DBF5694 for ; Wed, 13 May 2015 03:16:21 +0200 (CEST) Received: by obblk2 with SMTP id lk2so18910927obb.0 for ; Tue, 12 May 2015 18:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2akHdwKziUb8QRool5m1yFwzrrEaJyjLBDBoU7heje4=; b=CbFIvhow0fMRpXlOS4aJiOdyPHNV/ob3MU7e0yXdm6EHHEnIIFqJbA+eMhaT7nxpcB Z3JLBRCWYrx7zxUBTfWGqTV4IrCC96xAnq/4FBDJ3sKzbrn4VddO54mk0QQjlpidM5AY yh+oZaqwY/MgMnKXbUox+KqIa2qPuR6mdT4FmfQB//AqptBMidc8ap3g9AB6aGeiXYfi CJU68oqx9y0ysm2dEMa/LUo/6vsvx3nmR/2kS6P4fmvoTgVPl5qy3KctNJvGLtRSrtOF IiVbMjpvqHfGpKqpyeuMnWPLMIzLWtboXFf6uF7WuJhReZQqUzk6q1KUfm16R/pMyyIn Hytw== MIME-Version: 1.0 X-Received: by 10.202.65.10 with SMTP id o10mr13383975oia.65.1431479780969; Tue, 12 May 2015 18:16:20 -0700 (PDT) Received: by 10.202.179.195 with HTTP; Tue, 12 May 2015 18:16:20 -0700 (PDT) In-Reply-To: References: <1431119946-32078-1-git-send-email-rkerur@gmail.com> <1431119989-32124-1-git-send-email-rkerur@gmail.com> <2601191342CEEE43887BDE71AB9772582142E106@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772582142E44A@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772582142E475@irsmsx105.ger.corp.intel.com> Date: Tue, 12 May 2015 18:16:20 -0700 Message-ID: From: Ravi Kerur To: Don Provan Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v2] Implement memcmp using AVX/SSE instructions. 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: Wed, 13 May 2015 01:16:22 -0000 On Mon, May 11, 2015 at 3:29 PM, Don Provan wrote: > I probably shouldn't stick my nose into this, but I can't help myself. > > An experienced programmer will tend to ignore the documentation for > a routine named "blahblah_memcmp" and just assume it functions like > memcmp. Whether or not there's currently a use case in DPDK is > completely irrelevant because as soon as there *is* a use case, some > poor DPDK developer will try to use rte_memcmp for that and may or > may not have a test case that reveals their mistake. > In general I agree with you. However, comparison is a hit(equal) or miss(unequal) is generally the case in networking. I haven't seen cases where "less than" or "greater than" has mattered. > > The term "compare" suggests checking for larger or smaller. > If you want to check for equality, use "equal" or "eq" in the name > and return true if they're equal. But personally, I'd compare unless > there was a good reason not to. Indeed, I would just implement > full memcmp functionality and be done with it, even if that meant > using my fancy new assembly code for the cases I handle and then > calling memcmp itself for the cases I didn't. > > Agreed, I will look into implementing full functionality. > If a routine that appears to take an arbitrary size doesn't, the name > should in some manner reflect what sizes it takes. Better would be > for a routine that only handles specific sizes to be split into versions > that only take fixed sizes, but I don't know enough about your use > cases to say whether that makes sense here. > > Users of rte_memcmp will be existing dpdk test and library code. -don provan > dprovan@bivio.net > > -----Original Message----- > From: Ravi Kerur [mailto:rkerur@gmail.com] > Sent: Monday, May 11, 2015 1:47 PM > To: Ananyev, Konstantin > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2] Implement memcmp using AVX/SSE > instructions. > > ... > Following memcmp semantics is not hard but there are no use-cases for it > in DPDK currently. Keeping it specific to DPDK usage simplifies code as > well. > I can change the name to "rte_compare" and add comments to the function. > Will it work? > ... > >