From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f175.google.com (mail-qk0-f175.google.com [209.85.220.175]) by dpdk.org (Postfix) with ESMTP id B20324BE1 for ; Thu, 22 Jun 2017 09:12:01 +0200 (CEST) Received: by mail-qk0-f175.google.com with SMTP id p21so5432064qke.3 for ; Thu, 22 Jun 2017 00:12:01 -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=j0r4ktc4xz7SasYH/SZjxdhAR2z8NG4kiwEdvioHuao=; b=JukgL1WnLCnICEZSlM/LyJA/Q/NEggUr0xaefFVHfMnd9tmhgmEzhodTbgeeDpkNlo 0CkQg/E6fNOotCQyb8YK/uIgGmWh7c+nSq+1WXb5zkSW+6BLuWwasiE3PKxisVSFimZb l4c6OKxo7HbkEep2eEdHkwDHu3WihBf1hkg3xsvq2M3jNj3b9tT8vralxbNO4xsb1s08 sYENV/WvLoyxEKKUZSih0QjsJfFhsDm5wtAvO5Xe/YmZPOGJqPxDIlyrNOnQb2aSRuue 9MU1X2w/ZTkpqHQb3euY0IQwuf0Me4Ye//6c8g3DXcdER2Ibn3nac9Tgj0FW/mDWDH1/ XdZA== 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=j0r4ktc4xz7SasYH/SZjxdhAR2z8NG4kiwEdvioHuao=; b=H3u0fo9QUvsYDeof2VIBypk2ogMmy4sJPIivzEVfF4YgFI1H00fpc5nLMNuCBxRmwy 5IFJ/rZj6AS29Ghe5aUBDjiup44jXhnviXUm2XKvmcT85rYbZbZcN0JJ/iWM9FyezvEw VW5kdHgXc1ucifvQlBHfLkfjG3XiTUniE6/4oh3IRIwp2GOYxZRwdoBUt4gDmQTV9cX4 jompBkLkDTc9t25ENNR8f9MOyaHinRlgCo8sASYHGJvQ85Y7+xhBExjoQRbE6AEKwllp 33ISP1b2o/9uZzUhOp1ZSOUadPi1Y12kZoBvNR8w83PR6ZXzuAFMNhJzzxDHQV8TuVrR Qa2Q== X-Gm-Message-State: AKS2vOwg0KLYJVvGB5CviRjkjjzJz8Y8/rY8C1i+yFJm7VDQzCaICO8B VvApxtSdrvXHeZwxGRENmrllVhxHTw== X-Received: by 10.55.145.68 with SMTP id t65mr1227478qkd.68.1498115521126; Thu, 22 Jun 2017 00:12:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.136.55 with HTTP; Thu, 22 Jun 2017 00:12:00 -0700 (PDT) In-Reply-To: References: From: Shyam Shrivastav Date: Thu, 22 Jun 2017 12:42:00 +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 07:12:02 -0000 No it is not as dotted decimal representation is in big endian that is as they appear in packet, but acl library expects addition in host byte order. I would suggest to try the change, in firewall also we are converting user input in dotted decimal to integer then to host byte order .., anyway it is your choice On Thu, Jun 22, 2017 at 12:28 PM, Doohwan Lee wrote: > IPv4(1,2,3,4) means 0x01020304, and it is already host order (little > endian). > It need not to be converted using rte_be_to_cpu32() for setting rule. > > > > 2017-06-22 15:27 GMT+09:00 Shyam Shrivastav : > >> >> Yes Doohwan, it is there in rte_ip.h just saw. So this conversion leave= s >> 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 w= ith >> 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 c= ase >>>> 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 ne= ed to >>>>>> add it other way round as integers for matching. This means if you a= dd >>>>>> 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 ran= ge >>>>>>>>> matching. >>>>>>>>> >>>>>>>> >>>>>>>> =E2=80=8Bwell, you _can_ have address wildcard matches e.g. an add= ress+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, an= d >>>>>>>> Emacs was the lambda. >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >