From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id C42C5A04C3 for ; Mon, 10 Aug 2020 17:19:01 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0AFB62C16; Mon, 10 Aug 2020 17:19:01 +0200 (CEST) Received: from mail-pj1-f41.google.com (mail-pj1-f41.google.com [209.85.216.41]) by dpdk.org (Postfix) with ESMTP id 8D7B72986 for ; Mon, 10 Aug 2020 17:18:59 +0200 (CEST) Received: by mail-pj1-f41.google.com with SMTP id e4so5225947pjd.0 for ; Mon, 10 Aug 2020 08:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=KbpmEXFffxB7Wr6zre07GJijXmQeaIolfSZxbCos4KY=; b=bPstQjYznzRlzqYIb8DhYDMGPLV2W7b6ks/McK6DSfekhh3rzzWn6OqZvK6GRFDDn8 BucYAx/J10oWmCD8ztWbpGWAtEVNekF3Thr/RTAF4Gx+V84M/TGuxOrCXV3TQi1e9PXA Hjti+pX9EToR1j4s/fdUb1QAIXP1Lzz+4qS4IWYA/DTDczzElPDGlFmQEIkxG7+G6KmI sxOCwnj2DddjXIGc+dP5aUDR/RAj+tRVlBuXLqAiGuirgE+CThU+HhqqJ/HlnJ12WIwg 7pjAWHu+DE3jKsN9vELRVk6gTfn8Yl9+hMihRqyKYhzlNDLQAuE7Lo8Ocl6w8jrUG9RO 194g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=KbpmEXFffxB7Wr6zre07GJijXmQeaIolfSZxbCos4KY=; b=VYbjb/iS/kQH8MGoHVmCUvWuGo+Cyzhg/KiPmtbO571uBmbD4ZFWg5Ztfu0mgChmm+ Mj8u6GJzZXf3SQTPf3+/BRcHe5nhtFqfOxlmE6EVBzR3ydpeiCAXGgnWi76H4/2+pDqo XE8SwdWM80VGHIb+FdWaZAmUtv7ldGuiehqXf29SSEnzN+ZI5wSyWoK3O9VVxGM9x1tU xToCO19S9ufKR9XHt/y/fHM2eXma4sA3OKJHqlHCnbMUuIRwyGx0ZehlHs1xJJ4JLgEp uCt17SPY8NB1rBtXFU0A6Mf2ZjySuRYI6KRcFr2emk8yqrWpK1sIeX9V5TWZuW+TFnkX yf4w== X-Gm-Message-State: AOAM533z4yWc1P+/KhnAXKPUuuvJgK4b5KNumWnwF38lOTlYJQhuNW3M 0GqZItVX7dgPMZ/PlDNmX9V50VVNhrA= X-Google-Smtp-Source: ABdhPJwqVLgcqv71ejxCBwvairqTcSqn62ezCS2lyncPb9II2bsrfkfCJn518mzL970Tuz8zkHyTAw== X-Received: by 2002:a17:90a:19c2:: with SMTP id 2mr26985840pjj.6.1597072738705; Mon, 10 Aug 2020 08:18:58 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id e8sm22940374pfd.34.2020.08.10.08.18.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Aug 2020 08:18:58 -0700 (PDT) Date: Mon, 10 Aug 2020 08:18:49 -0700 From: Stephen Hemminger To: Arvind Narayanan Cc: Cliff Burdick , users Message-ID: <20200810081850.5c643f55@hermes.lan> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-users] rte_flow() usage of htonl() for ipv4 addr masks? 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: , Errors-To: users-bounces@dpdk.org Sender: "users" On Sun, 9 Aug 2020 22:14:28 -0500 Arvind Narayanan wrote: > On Sun, Aug 9, 2020 at 9:56 PM Cliff Burdick wrote: > > > > It should convert to network order, although many applications it won't matter since they use all F's. If you follow the code in flow_filtering, indeed it's using: > > > > #define FULL_MASK 0xffffffff /* full mask */ > > > > So it won't make any difference. The example should probably be updated, though.. > > Thanks Cliff! Yes, when it's all Fs, it doesn't matter. > But I am trying to install rte_flow rules for subnets by parsing a > file which has IPv4 ranges mentioned using CIDR format. > > I have it working for say /24 ranges, but as I go to /30 or /29, the > same implementation is not working. I followed the flow classify > example. https://doc.dpdk.org/guides/sample_app_ug/flow_classify.html > as it does the same thing. > > ``` > static uint32_t > convert_depth_to_bitmask(uint32_t depth_val) { > uint32_t bitmask = 0; > int i, j; > > for (i = depth_val, j = 0; i > 0; i--, j++) > bitmask |= (1 << (31 - j)); > return bitmask; > } > > ip_mask.hdr.dst_addr = htonl(convert_depth_to_bitmask(29)) > ``` > and https://github.com/DPDK/dpdk/blob/master/examples/flow_classify/flow_classify.c#L377-L396 > for ipv4 parsing. > > I'll keep digging. As always, it seems too trivial to fix as a bug, > but it's been driving me crazy.. haha > > - Arvind > > > > > > On Sun, Aug 9, 2020 at 7:03 PM Arvind Narayanan wrote: > >> > >> Hi, > >> > >> In the flow_filtering sample application, the IP's mask was set without > >> using htonl(). > >> https://github.com/DPDK/dpdk/blob/master/examples/flow_filtering/flow_blocks.c#L85 > >> > >> Another DPDK page shows > >> how a testpmd command is translated to C code. > >> On this page though, Example 4.2 (Range IPv4 drop) has used htonl() to set > >> the mask. > >> > >> Any clarification on how to load the mask would be helpful. In DPDK please use rte_cpu_to_be_32() instead of htonl().