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 8BD564C57 for ; Thu, 22 Jun 2017 10:31:32 +0200 (CEST) Received: by mail-qk0-f175.google.com with SMTP id p21so6550350qke.3 for ; Thu, 22 Jun 2017 01:31:32 -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=LKTJpPHWwK+ZNKPsMNI/jp12qHw0Iz/isvaBUmO13go=; b=ewpn/bDSTSl/65mrtcNawfsKA902T5e4600EgfgR5liIwwNPI42iSXNr7G34fYK1MG TJ0W85srVE7WG528KFG3stBo0Xf9XtOzL0Kv7M8Y421B5we6BHBeKtZ5Ig7QRPeLdcR7 ajZMvFJKu3Qn63jb3b3cq6yp1/w/z63z9Fort1ha7e1QO5JuNz09rkRs14p1ojz6fla8 sL1q6LlrSOnNCIEsFH80FQidEfj6kAWh2kfeOo2tsBF82O6J0Vb8nTsnNlWFHgsBvu7H A7hm27jge8TfLwGi7HOKtbmWnuuGDyE9x62K14OiKMcf6MrQEk16I1henyutNL+E6ocj CF4A== 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=LKTJpPHWwK+ZNKPsMNI/jp12qHw0Iz/isvaBUmO13go=; b=nh20F2PTHG2uKF874jsdPemO8aNRkn8ai7iOG42buOgrlcnN9vKyM8F//Fpu0kXT3K jaUPOKlvNX6l9AQ64I0JSv8uFbXEzAy+fnD0kh03ot3rOEQeSfN6jKVLY4AZnEm6gncU K8RNO+6Yya55/6obE0/jTRN2F/r+J+talF/NAL38xqmnChjXD64LIUgKsgxU282iazMK TPQuQDmGY2l2mJ+iu09oGhUbS6eUtSDTFfxt10dBb7pCUxB8Axt70MFNKs/guHmns3UU K8HUQYhSQdPicKneItcoFq53/5dM5eEK+Spge8Drz+w/+ZRLFsJHJNsFpsgb5IQFRS4p bXLg== X-Gm-Message-State: AKS2vOzRHhc51CkhGoK7ARUDQrzLkgv1tnOYm8NE/Eb/pJJDvDVoXRtQ DPkUY3ZcaTu2Q9X9VO3XmZ5/FfK7ug== X-Received: by 10.55.136.1 with SMTP id k1mr1538098qkd.104.1498120291936; Thu, 22 Jun 2017 01:31:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.136.55 with HTTP; Thu, 22 Jun 2017 01:31:31 -0700 (PDT) In-Reply-To: References: From: Shyam Shrivastav Date: Thu, 22 Jun 2017 14:01:31 +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 08:31:33 -0000 Yes you are right , the IPv4 conversion keeps the host byte and ip address in packet mbuf would appear other way round for matching. I got confused because firewall parser code reads the dotted decimal user input as big endian, that's why rte_be_to_cpu32 is required. Hope some help comes your way, you can also try posting in dpdk dev dev@dpdk.org On Thu, Jun 22, 2017 at 12:57 PM, Doohwan Lee wrote: > 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 a= s >> they appear in packet, but acl library expects addition in host byte ord= er. >> I would suggest to try the change, in firewall also we are converting us= er >> 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 suppose= d 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 b= e >>>>>> 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 0x1e0a0= a0a for >>>>>>>> acl match, dotted decimal is in big endian so when in little endia= n 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 mas= k >>>>>>>>> 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 >>>>>>>>>> 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. >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >