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 <https://doc.dpdk.org/guides/howto/rte_flow.html> 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. Thanks, Arvind
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..
On Sun, Aug 9, 2020 at 7:03 PM Arvind Narayanan <webguru2688@gmail.com>
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 <https://doc.dpdk.org/guides/howto/rte_flow.html> 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.
>
> Thanks,
> Arvind
>
On Sun, Aug 9, 2020 at 9:56 PM Cliff Burdick <shaklee3@gmail.com> 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 <webguru2688@gmail.com> 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 <https://doc.dpdk.org/guides/howto/rte_flow.html> 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. >> >> Thanks, >> Arvind
On Sun, 9 Aug 2020 22:14:28 -0500
Arvind Narayanan <webguru2688@gmail.com> wrote:
> On Sun, Aug 9, 2020 at 9:56 PM Cliff Burdick <shaklee3@gmail.com> 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 <webguru2688@gmail.com> 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 <https://doc.dpdk.org/guides/howto/rte_flow.html> 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().