[dpdk-dev] ACL lookup doesn't work for some schemes

[dpdk-dev] ACL lookup doesn't work for some schemes

[志昌余]

Hi,    I noticed that ACL lookup doesn't work for some schemes.1. If the first field is not uint8_t, even all fields are wildcard, lookup doesn't find the matching rule. See acl_8last.c.2. I prepended a uint8_t field, keep other fields be wildcard, lookup returns the correct result. See acl_8last2.c3. Then I change last field from 8bitmask_WILDCARD to 8bitmask(1, 0x1) (matches odd numbers) or 8bitmask(0, 0x1) (match even numbers), lookup doesn't return the correct. See acl_8last3.c.  And I noticed the similar behavior for uint16_t ranges(date doesn't match 0-0x8000 nor 0x8001-0xffff).    Above behaviors are tricky. Does ACL do some undocumented assumptions or the table schema?    Regards,Zhichang Yu 		 	   		  

Re: [dpdk-dev] ACL lookup doesn't work for some schemes

[志昌余]

[-- Attachment #1: Type: text/plain, Size: 959 bytes --]

Sorry I forgot to attach the sample code in previous mail. See the attached.

From: yuzhichang_scl@hotmail.com
To: dev@dpdk.org
Subject: ACL lookup doesn't work for some schemes
Date: Sun, 15 Feb 2015 17:18:55 +0800




Hi,    I noticed that ACL lookup doesn't work for some schemes.1. If the first field is not uint8_t, even all fields are wildcard, lookup doesn't find the matching rule. See acl_8last.c.2. I prepended a uint8_t field, keep other fields be wildcard, lookup returns the correct result. See acl_8last2.c3. Then I change last field from 8bitmask_WILDCARD to 8bitmask(1, 0x1) (matches odd numbers) or 8bitmask(0, 0x1) (match even numbers), lookup doesn't return the correct. See acl_8last3.c.  And I noticed the similar behavior for uint16_t ranges(date doesn't match 0-0x8000 nor 0x8001-0xffff).    Above behaviors are tricky. Does ACL do some undocumented assumptions or the table schema?    Regards,Zhichang Yu 		 	   		   		 	   		  

[-- Attachment #2: poc_acl_mp.zip --]
[-- Type: application/zip, Size: 14549 bytes --]

Re: [dpdk-dev] ACL lookup doesn't work for some schemes

[志昌余]

I tested against DPDK 1.7.0, 1.8.0 and trunk( ed2547b6). 

________________________________
> From: yuzhichang_scl@hotmail.com 
> To: dev@dpdk.org 
> Subject: RE: ACL lookup doesn't work for some schemes 
> Date: Sun, 15 Feb 2015 17:23:53 +0800 
> 
> Sorry I forgot to attach the sample code in previous mail. See the attached. 
> 
> ________________________________ 
> From: yuzhichang_scl@hotmail.com 
> To: dev@dpdk.org 
> Subject: ACL lookup doesn't work for some schemes 
> Date: Sun, 15 Feb 2015 17:18:55 +0800 
> 
> Hi, 
> I noticed that ACL lookup doesn't work for some schemes. 
> 1. If the first field is not uint8_t, even all fields are wildcard, 
> lookup doesn't find the matching rule. See acl_8last.c. 
> 2. I prepended a uint8_t field, keep other fields be wildcard, lookup 
> returns the correct result. See acl_8last2.c 
> 3. Then I change last field from 8bitmask_WILDCARD to 8bitmask(1, 0x1) 
> (matches odd numbers) or 8bitmask(0, 0x1) (match even numbers), lookup 
> doesn't return the correct. See acl_8last3.c. And I noticed the 
> similar behavior for uint16_t ranges(date doesn't match 0-0x8000 nor 
> 0x8001-0xffff). 
> Above behaviors are tricky. Does ACL do some 
> undocumented assumptions or the table schema? 
> Regards, 
> Zhichang Yu 
 		 	   		  

Re: [dpdk-dev] ACL lookup doesn't work for some schemes

[Ananyev, Konstantin]

Hi

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of ???
> Sent: Sunday, February 15, 2015 9:19 AM
> To: dev@dpdk.org
> Subject: [dpdk-dev] ACL lookup doesn't work for some schemes
> 
> Hi,    I noticed that ACL lookup doesn't work for some schemes.1. If the first field is not uint8_t, even all fields are wildcard, lookup
> doesn't find the matching rule. See acl_8last.c.2. I prepended a uint8_t field, keep other fields be wildcard, lookup returns the correct
> result. See acl_8last2.c3. Then I change last field from 8bitmask_WILDCARD to 8bitmask(1, 0x1) (matches odd numbers) or 8bitmask(0,
> 0x1) (match even numbers), lookup doesn't return the correct. See acl_8last3.c.  And I noticed the similar behavior for uint16_t
> ranges(date doesn't match 0-0x8000 nor 0x8001-0xffff).    Above behaviors are tricky. Does ACL do some undocumented assumptions
> or the table schema?    Regards,Zhichang Yu

Yes, right now, libtre_acl to work correctly first field has to be 1B long and all subsequent grouped into sets of 4 consecutive bytes.
I thought we have it documented into our PG, ACL section:
http://dpdk.org/doc/guides/prog_guide/packet_classif_access_ctrl.html
Though re-reading it again:
"For performance reasons, the inner loop of the search function is unrolled to process four input bytes at a time. This requires the input to be grouped into sets of 4 consecutive bytes. The loop processes the first input byte as part of the setup and then subsequent bytes must be in groups of 4 consecutive bytes."
It probably not very clear and need to be explained in more details.
Will update the doc.

Konstantin

Re: [dpdk-dev] ACL lookup doesn't work for some schemes

[Stevan Markovic]

Hi,

On Mon, Feb 16, 2015 at 4:56 AM, Ananyev, Konstantin <
konstantin.ananyev@intel.com> wrote:

> Yes, right now, libtre_acl to work correctly first field has to be 1B long
> and all subsequent grouped into sets of 4 consecutive bytes.
> I thought we have it documented into our PG, ACL section:
> http://dpdk.org/doc/guides/prog_guide/packet_classif_access_ctrl.html
> Though re-reading it again:
> "For performance reasons, the inner loop of the search function is
> unrolled to process four input bytes at a time. This requires the input to
> be grouped into sets of 4 consecutive bytes. The loop processes the first
> input byte as part of the setup and then subsequent bytes must be in groups
> of 4 consecutive bytes."
> It probably not very clear and need to be explained in more details.
> Will update the doc.
>
> Konstantin
>
>
While improving API documentation would be great, enforcing these
constraints on user defined fields in rte_acl_build(?) also (return an
error if constraints are not met) would be even better.

Stevan

Re: [dpdk-dev] ACL lookup doesn't work for some schemes

[Ananyev, Konstantin]

> -----Original Message-----
> From: Markovic, Stevan [mailto:smarkovi@akamai.com]
> Sent: Monday, February 16, 2015 3:22 PM
> To: Ananyev, Konstantin; yuzhichang_scl@hotmail.com; dev@dpdk.org
> Subject: Re: [dpdk-dev] ACL lookup doesn't work for some schemes
> 
> Hi,
> 
> 
> On 2/16/15, 4:56 AM, "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
> wrote:
> 
> >
> >Yes, right now, libtre_acl to work correctly first field has to be 1B
> >long and all subsequent grouped into sets of 4 consecutive bytes.
> >I thought we have it documented into our PG, ACL section:
> >http://dpdk.org/doc/guides/prog_guide/packet_classif_access_ctrl.html
> >Though re-reading it again:
> >"For performance reasons, the inner loop of the search function is
> >unrolled to process four input bytes at a time. This requires the input
> >to be grouped into sets of 4 consecutive bytes. The loop processes the
> >first input byte as part of the setup and then subsequent bytes must be
> >in groups of 4 consecutive bytes."
> >It probably not very clear and need to be explained in more details.
> >Will update the doc.
> >
> >Konstantin
> >
> 
> While improving API documentation would be great, enforcing these
> constraints on user defined fields in rte_acl_build(?) also (return an
> error if constraints are not met) would be even better.
> 
> Stevan

Good point. Will try to add some extra checks  to rte_acl_build().
If time permits - for 2.0 timeframe, if not then for 2.1.  
Konstantin