From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f174.google.com (mail-qk0-f174.google.com [209.85.220.174]) by dpdk.org (Postfix) with ESMTP id E3A605323 for ; Thu, 22 Jun 2017 08:27:59 +0200 (CEST) Received: by mail-qk0-f174.google.com with SMTP id 16so4857826qkg.2 for ; Wed, 21 Jun 2017 23:27:59 -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=2jK2znLz067JoG756RLVMkQx14edF6KgYp9MOSXMpvg=; b=NL5dotY1hQbvxadpR8tcWEdDCSEqISDkG2lX0/6A8om6knoYdGUPFMidjNJNOjiGMn apHJa1GHM7pvi30r5iHkR9SYp4x69IcLlPGejXHi4Sb839jjK3SCbxw3mg4UpNgi+ash JQuAnWy9n6ltX+ZneI1pDVqExcFDsMrdeIDDFkIIQ2NN6+MS4SA7xCB01b0js++/R/bC 259zuGvGI/oWxeAD7e8yRV2+TaVSWLebAYrCch0S6skJ9Cmhwv0RaEcevc6jO/AvU6Uj PJMd3lcgmQmQ4u4lN2RqIAVnb5GgCGvm2eX6IPj0U7Lyl+qbba3QzcVKeONnnV+A8K8F /FZw== 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=2jK2znLz067JoG756RLVMkQx14edF6KgYp9MOSXMpvg=; b=UpxD9VdwShN0h40kFqAylcUzMP8oyjdsgmAOBRDBznYVG4pEipF97oo/WkmCZm22MT F/J1SnUeMB8HSLpqPYzzYOVidmJPwRfYQBECUzCN6L2/+yZL19go48Jjq14qr/shvo10 n1LXi1OvWVjGrodKFSdc027SwFwc+LNJD/jUsVJEV/agkEcbH0WYX0VHyDdInzsKu5nF FZdt7yS+da6zinY5Bg5GvSY8z43CxAc0p45vusx8KVERRJXdk4bMsP/1A7WSfphEoydX 7B4H4bXl8dvtETrfZYmtmyjW/rI46oUMlGbSDQDAbFgUGVdkyypX6FVRySFZBwMulqzn RQ+w== X-Gm-Message-State: AKS2vOycGA/jXsXtMEM5w6lIeE9zKXE7H3EquVFOjUIRXONo0pJhjJMd LE2reoSDIQ23fRE3q09IlXQHMqD8ow== X-Received: by 10.55.191.197 with SMTP id p188mr1027575qkf.69.1498112879303; Wed, 21 Jun 2017 23:27:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.136.55 with HTTP; Wed, 21 Jun 2017 23:27:58 -0700 (PDT) In-Reply-To: References: From: Shyam Shrivastav Date: Thu, 22 Jun 2017 11:57:58 +0530 Message-ID: To: Doohwan Lee 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 06:28:00 -0000 Yes Doohwan, it is there in rte_ip.h just saw. So this conversion leaves the address in big endian format. Theoretically, we are supposed to add the acl fields in host order, if you see pipeline code even for ip address with mask, following conversion is being done line 1096 examples/ip_pipeline/pipeline-firewall.c key.type =3D PIPELINE_FIREWALL_IPV4_5TUPLE; key.key.ipv4_5tuple.src_ip =3D rte_be_to_cpu_32(sipaddr.s_addr); key.key.ipv4_5tuple.src_ip_mask =3D sipdepth; key.key.ipv4_5tuple.dst_ip =3D rte_be_to_cpu_32(dipaddr.s_addr); I would suggest this in your code rule->field[2].value.u32 =3D rte_be_to_cpu_32(IPv4(1,2,3,4)); rule->filed[2].mask_range.u32 =3D rte_be_to_cpu_32(IPv4(1,10,10,10)); On Thu, Jun 22, 2017 at 11:28 AM, Doohwan Lee wrote: > 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 >> sure unless do this myself, have been using ACL library but not this cas= e >> 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, i= f >>>> 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 >>>>> type 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 < >>>>> anupam.kapoor@gmail.com> 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 addre= ss+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. >>>>>> >>>>> >>>>> >>>> >>> >> >