[dpdk-dev] [PATCH 0/3] doc: ACL - add description for new features.

[dpdk-dev] [PATCH 0/3] doc: ACL - add description for new features.

[Konstantin Ananyev]

Konstantin Ananyev (3):
  doc: Add restrictions for ACL rule fields
  doc: ACL - add description for different classification methods
  doc: ACL - add description for max_size build parameter

 .../prog_guide/packet_classif_access_ctrl.rst      | 83 ++++++++++++++++++++--
 1 file changed, 78 insertions(+), 5 deletions(-)

-- 
1.8.3.1

[dpdk-dev] [PATCH 1/3] doc: Add restrictions for ACL rule fields

[Konstantin Ananyev]

Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
---
 doc/guides/prog_guide/packet_classif_access_ctrl.rst | 17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/doc/guides/prog_guide/packet_classif_access_ctrl.rst b/doc/guides/prog_guide/packet_classif_access_ctrl.rst
index 72f4510..e018c68 100644
--- a/doc/guides/prog_guide/packet_classif_access_ctrl.rst
+++ b/doc/guides/prog_guide/packet_classif_access_ctrl.rst
@@ -1,5 +1,5 @@
 ..  BSD LICENSE
-    Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+    Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
     All rights reserved.
 
     Redistribution and use in source and binary forms, with or without
@@ -51,8 +51,18 @@ The library API provides the following basic operations:
 Overview
 --------
 
+Rule definition
+~~~~~~~~~~~~~~~
+
 The current implementation allows the user for each AC context to specify its own rule (set of fields)
 over which packet classification will be performed.
+Though there are few restrictions on the rule fields layout:
+
+*  First field in the rule definition has to be one byte long.
+*  All subsequent fields has to be grouped into sets of 4 consecutive bytes.
+
+This is done mainly for performance reasons - search function processes the first input byte as part of the flow setup and then the inner loop of the search function is unrolled to process four input bytes at a time.
+
 To define each field inside an AC rule, the following structure is used:
 
 .. code-block:: c
@@ -85,10 +95,7 @@ To define each field inside an AC rule, the following structure is used:
     A zero-based value that represents the position of the field inside the rule; 0 to N-1 for N fields.
 
 *   input_index
-    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.
+    As mentioned above, all input fields, except the very first one, must be in groups of 4 consecutive bytes.
     The input index specifies to which input group that field belongs to.
 
 *   offset
-- 
1.8.3.1

[dpdk-dev] [PATCH 2/3] doc: ACL - add description for different classification methods

[Konstantin Ananyev]

Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
---
 doc/guides/prog_guide/packet_classif_access_ctrl.rst | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/doc/guides/prog_guide/packet_classif_access_ctrl.rst b/doc/guides/prog_guide/packet_classif_access_ctrl.rst
index e018c68..d2adbff 100644
--- a/doc/guides/prog_guide/packet_classif_access_ctrl.rst
+++ b/doc/guides/prog_guide/packet_classif_access_ctrl.rst
@@ -269,6 +269,22 @@ When creating a set of rules, for each rule, additional information must be supp
     When adding new rules into an ACL context, all fields must be in host byte order (LSB).
     When the search is performed for an input tuple, all fields in that tuple must be in network byte order (MSB).
 
+Classification methods
+~~~~~~~~~~~~~~~~~~~~~~
+
+After rte_acl_build() over given ACL context has finished successfully, it can be used to perform classification - search for a ACL rule with highest priority over the input data.
+There are several implementations of classify algorithm:
+
+*   **RTE_ACL_CLASSIFY_SCALAR**: generic implementation, doesn't require any specific HW support.
+
+*   **RTE_ACL_CLASSIFY_SSE**: vector implementation, can process up to 8 flows in parallel. Requires SSE 4.1 support.
+
+*   **RTE_ACL_CLASSIFY_AVX2**: vector implementation, can process up to 16 flows in parallel. Requires AVX2 support.
+
+It is purely a runtime decision which method to choose, there is no build-time difference.
+All implementations operates over the same internal RT structures and use similar principles. The main difference is that vector implementations can manually exploit IA SIMD instructions and process several input data flows in parallel.
+At startup ACL library determines the highest available classify method for the given platform and sets it as default one. Though the user has an ability to override the default classifier function for a given ACL context or perform particular search using non-default classify method. In that case it is user responsibility to make sure that given platform supports selected classify implementation.
+
 Application Programming Interface (API) Usage
 ---------------------------------------------
 
-- 
1.8.3.1

[dpdk-dev] [PATCH 3/3] doc: ACL - add description for max_size build parameter

[Konstantin Ananyev]

Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
---
 .../prog_guide/packet_classif_access_ctrl.rst      | 52 +++++++++++++++++++++-
 1 file changed, 51 insertions(+), 1 deletion(-)

diff --git a/doc/guides/prog_guide/packet_classif_access_ctrl.rst b/doc/guides/prog_guide/packet_classif_access_ctrl.rst
index d2adbff..210b020 100644
--- a/doc/guides/prog_guide/packet_classif_access_ctrl.rst
+++ b/doc/guides/prog_guide/packet_classif_access_ctrl.rst
@@ -269,10 +269,60 @@ When creating a set of rules, for each rule, additional information must be supp
     When adding new rules into an ACL context, all fields must be in host byte order (LSB).
     When the search is performed for an input tuple, all fields in that tuple must be in network byte order (MSB).
 
+RT memory size limit
+~~~~~~~~~~~~~~~~~~~~
+
+Build phase (rte_acl_build()) creates for a given set of rules internal structure for further run-time traversal.
+With current implementation it is a set of multi-bit tries (with stride == 8).
+Depending on the rules set, that could consume significant amount of memory.
+In attempt to conserve some space ACL build process tries to split the given
+rule-set into several non-intersecting subsets and construct a separate trie
+for each of them.
+Depending on the rule-set, it might reduce RT memory requirements but might
+increase classification time.
+There is a possibility at build-time to specify maximum memory limit for internal RT structures for given AC context.
+It could be done via **max_size** field of the **rte_acl_config** strucure.
+Setting it to the value greater than zero, instructs rte_acl_build() to:
+
+*   attempt to minimise number of tries in the RT table, but
+*   make sure that size of RT table wouldn't exceed given value.
+
+Setting it to zero makes rte_acl_build() to use the default behaviour:
+try to minimise size of the RT structures, but doesn't expose any hard limit on it.
+
+That gives the user the ability to decisions about performance/space trade-off.
+For example:
+
+.. code-block:: c
+
+    struct rte_acl_ctx * acx;
+    struct rte_acl_config cfg;
+    int ret;
+
+    /*
+     * assuming that acx points to already created and
+     * populated with rules AC context and cfg filled properly.
+     */
+
+     /* try to build AC context, with RT strcutures less then 8MB. */
+     cfg.max_size = 0x800000;
+     ret = rte_acl_build(acx, &cfg);
+
+     /*
+      * RT strcutures can't fit into 8MB for given context.
+      * Try to build without exposing any hard limit.
+      */
+     if (ret == -ERANGE) {
+        cfg.max_size = 0;
+        ret = rte_acl_build(acx, &cfg);
+     }
+
+
+
 Classification methods
 ~~~~~~~~~~~~~~~~~~~~~~
 
-After rte_acl_build() over given ACL context has finished successfully, it can be used to perform classification - search for a ACL rule with highest priority over the input data.
+After rte_acl_build() over given AC context has finished successfully, it can be used to perform classification - search for a rule with highest priority over the input data.
 There are several implementations of classify algorithm:
 
 *   **RTE_ACL_CLASSIFY_SCALAR**: generic implementation, doesn't require any specific HW support.
-- 
1.8.3.1

Re: [dpdk-dev] [PATCH 0/3] doc: ACL - add description for new features.

[Butler, Siobhan A]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Konstantin
> Ananyev
> Sent: Wednesday, February 18, 2015 4:29 PM
> To: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH 0/3] doc: ACL - add description for new features.
> 
> Konstantin Ananyev (3):
>   doc: Add restrictions for ACL rule fields
>   doc: ACL - add description for different classification methods
>   doc: ACL - add description for max_size build parameter
> 
>  .../prog_guide/packet_classif_access_ctrl.rst      | 83
> ++++++++++++++++++++--
>  1 file changed, 78 insertions(+), 5 deletions(-)
> 
> --
> 1.8.3.1

Series Acked-by: Siobhan Butler <siobhan.a.butler@intel.com>

Re: [dpdk-dev] [PATCH 0/3] doc: ACL - add description for new features.

[Thomas Monjalon]

> > Konstantin Ananyev (3):
> >   doc: Add restrictions for ACL rule fields
> >   doc: ACL - add description for different classification methods
> >   doc: ACL - add description for max_size build parameter
> 
> Series Acked-by: Siobhan Butler <siobhan.a.butler@intel.com>

Applied, thanks