From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot0-f180.google.com (mail-ot0-f180.google.com [74.125.82.180]) by dpdk.org (Postfix) with ESMTP id BAA745323 for ; Thu, 22 Jun 2017 09:27:07 +0200 (CEST) Received: by mail-ot0-f180.google.com with SMTP id 95so5242301ott.3 for ; Thu, 22 Jun 2017 00:27:07 -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=xOuY2C7qDP27vCx+iBb1YPh1kFhu1KcS1vC/Dz8svv8=; b=UE5aU1yy8i38xOJHrESl4OPkmLWo1SbMHKxDaRIA21tDqy64DBZGwB1+fjI8k0cuSk jdlvs/Pa+HvaQgrFuVAdoJH0P+gLwcIJ61Qmk9zmw+s1jmc2Qlyot6I3F4LecgdTGrDy jNA/1tDTcQTEGVph4qItUd6WloeEIpKoMZrH1jlWYAMfzqWO9M3BXGeH7eqxFYP9gMjh dVoH4OdCbZ5DOgBK6/kvSF3x9wI6T/PctQCc30cMKuWkur/C5fNg/bJ9/bTao1see0YI +OgcFEFtrb30l8Go/79NMSvICTUm8282Y7ZtROi+/f7JWGNqqyPkgnVGLFYyySAiC4JX b9Tg== 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=xOuY2C7qDP27vCx+iBb1YPh1kFhu1KcS1vC/Dz8svv8=; b=MZO4n197ZDaYhYUM0Sl5u9D2WxmerAdzhw3nTwbHZa+mXNq2/gQ1xy7OxXLFtSTq3A 0aSfLLXxHOSx+wjtGosFiHNi9vbausOpdkhT/Y1O5eYaTuglriimYLkHxv+yg25Da2T/ zgsrIivARyU5mxjgYA2lkmm9DH+VLvA+W78dDCUYbTXhjypq5oWWxGdD4jTGcfMNOQK1 NiNAWY2+D31rWlQyXjWYhho7vwWldf4Z4g+N2NPcmSpEtqoGus3vfhFM/ar3QFWsVVT6 RvBOEbCS1Vbp4gptNXegagjJcn+Uie9ZuMwXS6FRHHVlryVFT37uHKOvWtg8tUxs6qDp XKFQ== X-Gm-Message-State: AKS2vOxq/uV3rX1VhDVZ4kxkg+FjoE85m1/UZfBMM1xU2ipeSujuGGll 4p2NgsNvAw2gwWA5OrErAJuJK6CtCA== X-Received: by 10.157.60.4 with SMTP id q4mr525662otc.116.1498116426824; Thu, 22 Jun 2017 00:27:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.137.44 with HTTP; Thu, 22 Jun 2017 00:27:06 -0700 (PDT) In-Reply-To: References: From: Doohwan Lee Date: Thu, 22 Jun 2017 16:27:06 +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 07:27:08 -0000 I really appreciate your help. but I think there's some misunderstanding. I also know that DPDK ACL rule expects host order. IPv4(1,2,3,4) means 0x01020304 and it is little endian(host order) again. and the IP address 1.2.3.4 in packet data on memory is 0x04030201 (big endian). So, I think I didn't have any mistake for using DPDK ACL library. 2017-06-22 16:12 GMT+09:00 Shyam Shrivastav : > 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 orde= r. > I would suggest to try the change, in firewall also we are converting use= r > 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 >>> 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 = 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 n= eed 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 m= y >>>>>>> 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 cas= e. >>>>>>>> >>>>>>>> >>>>>>>> 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 >>>>>>>>> address+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. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >