From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot0-f182.google.com (mail-ot0-f182.google.com [74.125.82.182]) by dpdk.org (Postfix) with ESMTP id 1BD4A5323 for ; Thu, 22 Jun 2017 07:58:28 +0200 (CEST) Received: by mail-ot0-f182.google.com with SMTP id 95so4108945ott.3 for ; Wed, 21 Jun 2017 22:58:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oXhhDb5a3tllXhBM005UB6TNEDEpYFXQ0lUzq9v6Wsk=; b=bBMV9t6ql80kgc4CQ1/BUBqyYKulNZOGR80u7/SPuSUBaAyBkw9j9zAnECt9cLQ8Zl ErXAO2JeAw0MnQK5MFcRtQ2GODnHtbFKIM/wyCNFocFYLLjcrEa7FzEDUMPlTWe43c7g J42prZm1q28i9TFsnNNe3fXHK0erjSABz/HerDk8zPEU/RriaBxLfraMRGkmrsuzk1/b JmQ4SY4FAgz+l93VX4Do3c8M3Xftz2K8rju3oT32pvkSgsWm1NAdIF7btiKCF+7B+LtY ZafXfni+z+fA7J4W5dIZdwfn9utr4xd/tSVg14LAC50zfZ74dAnTY+Ky7CqOLwRUoVnK 9KEQ== 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=oXhhDb5a3tllXhBM005UB6TNEDEpYFXQ0lUzq9v6Wsk=; b=Pysl0NeqJnqYfdKcCppqnpPEOg6/BISniOk63NDaZrD2qkBO+8C0njvRqIFolcmxbR Jvnc05aos0EYA0iQHH+yxLSXMs7OQHhbBaH6xSkfxCAner5fr1bw/oeQFJTy6b3LZ5uA 80JboYwuTCU04dLXcQlhRNEYv6MmR7YdnjLHfsh7e1Hignf5PKQIqpzvrgQzhL5NVW4k /w2Nj+VntKonf7p7efuzhNSYerDs9G0glvS1pFQdoN5dgYcvv1jdZZ0M55XCtFMmflpD nluezQIbZONfm/WPNZMttEU2S9Aue2Pgk6slVW7W/OqZCs6lLpEehgCfMAjfwHXsJsyB kgFw== X-Gm-Message-State: AKS2vOwz9AGMVWYdCFvl12Rgk5TqRM5iT+K/nBiSfXm05CY5CbiwWWdd qM0U3PHJEgGplst1QucGEY8FxUSiKg== X-Received: by 10.157.42.4 with SMTP id t4mr586441ota.146.1498111108092; Wed, 21 Jun 2017 22:58:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.137.44 with HTTP; Wed, 21 Jun 2017 22:58:27 -0700 (PDT) In-Reply-To: References: From: Doohwan Lee Date: Thu, 22 Jun 2017 14:58:27 +0900 Message-ID: To: Shyam Shrivastav Cc: Anupam Kapoor , users@dpdk.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-users] Question about range type of DPDK ACL 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: Thu, 22 Jun 2017 05:58:29 -0000 Ok. The code to set rule for IPv4 address is like below. ------------------------------------------------------------ #define IPv4(a,b,c,d) ((uint32_t)(((a) & 0xff) << 24) | \ (((b) & 0xff) << 16) | \ (((c) & 0xff) << 8) | \ ((d) & 0xff)) ....... rule->field[2].value.u32 =3D IPv4(1,2,3,4); rule->filed[2].mask_range.u32 =3D IPv4(1,10,10,10); ....... ------------------------------------------------------------- The macro IPv4() is from the DPDK (rte_ip.h) The matching data is from the packet. so it is network order. (big endian) On Thu, Jun 22, 2017 at 1:26 PM, Shyam Shrivastav < shrivastav.shyam@gmail.com> wrote: > Yes if these are the results then might be some issue, but can not be sur= e > unless do this myself, have been using ACL library but not this case till > now. > Can you share code fragment converting dotted decimal to integer if > possible .. > > On Thu, Jun 22, 2017 at 7:57 AM, Doohwan Lee wrote: > >> Thank you Shyam. >> Let me explain my situation in detail. >> All the cases described below use RTE_ACL_FIELD_TYPE_RANGE type. >> >> ----------------------------------------------- >> Case 1. >> rule: 1.2.3.4 ~ 1.2.3.4 >> packet: 1.2.3.4 >> result: match (correct) >> >> Case 2. >> rule: 1.2.3.4 ~ 1.10.10.10 >> packet: 1.2.10.5 >> result: match (correct) >> >> Case 3 >> rule: 1.2.3.4 ~ 1.10.10.10 >> packet: 1.10.10.11 >> result: not match (correct) >> >> Case 4 >> rule: 1.2.3.4 ~ 1.10.10.10 >> packet: 1.2.3.10 >> result: match (correct) >> >> Case 5: >> rule: 1.2.3.4~1.10.10.10 >> packet: 1.2.10.11 >> result: not match (incorrect) >> >> Case 6: >> rule: 1.2.3.4~1.10.10.10 >> packet: 1.2.10.3 >> result: not match (incorrect) >> ----------------------------------------------- >> >> >> Considering case 1~4, It shows expected results and there is no problem >> with byte ordering. >> But, in case 5~6, the result should be 'match' but it was not. >> This is why I doubt DPDK ACL library doesn't support 32-bit range >> matching. >> >> >> On Wed, Jun 21, 2017 at 9:09 PM, Shyam Shrivastav < >> shrivastav.shyam@gmail.com> wrote: >> >>> I haven't used range type with 32 bit integers yet ... >>> Just some theory in case if you haven't already taken into account, if >>> little-endian host 10.10.10.30 actually means 0x1e0a0a0a for acl match, >>> dotted decimal is in big endian so when in little endian host you need = to >>> add it other way round as integers for matching. This means if you add >>> range 0x0a0a0a0a to 0x1e1e1e1e should match 10.10.10.30, this is my >>> understanding theoretically .. >>> >>> On Wed, Jun 21, 2017 at 4:54 PM, Doohwan Lee wrote: >>> >>>> Yes. you are right. I also already knew that 32bit match with mask typ= e >>>> works well. >>>> My point is 32bit match with 'range type' doesn't work in some case. >>>> >>>> >>>> On Wed, Jun 21, 2017 at 6:46 PM, Anupam Kapoor >>> > wrote: >>>> >>>>> >>>>> On Wed, Jun 21, 2017 at 11:36 AM, Doohwan Lee >>>>> wrote: >>>>> >>>>>> DPDK ACL library uses multi-bit trie with 8-bit stride. >>>>>> I guess that implementation of the trie doesn't support 32bit range >>>>>> matching. >>>>>> >>>>> >>>>> =E2=80=8Bwell, you _can_ have address wildcard matches e.g. an addres= s+mask >>>>> combination of 1.2.3.0/24 would match all addresses 1.2.3.[0..255] >>>>> >>>>> =E2=80=8B-- >>>>> kind regards >>>>> anupam=E2=80=8B >>>>> >>>>> In the beginning was the lambda, and the lambda was with Emacs, and >>>>> Emacs was the lambda. >>>>> >>>> >>>> >>> >> >