From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <afischet@ecsmtp.ir.intel.com>
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88])
 by dpdk.org (Postfix) with ESMTP id 798828D35
 for <dev@dpdk.org>; Mon, 11 Jan 2016 18:45:06 +0100 (CET)
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
 by fmsmga101.fm.intel.com with ESMTP; 11 Jan 2016 09:45:05 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.20,553,1444719600"; d="scan'208";a="890955968"
Received: from irvmail001.ir.intel.com ([163.33.26.43])
 by fmsmga002.fm.intel.com with ESMTP; 11 Jan 2016 09:45:05 -0800
Received: from sivswdev02.ir.intel.com (sivswdev02.ir.intel.com
 [10.237.217.46])
 by irvmail001.ir.intel.com (8.14.3/8.13.6/MailSET/Hub) with ESMTP id
 u0BHj3Pi022182; Mon, 11 Jan 2016 17:45:04 GMT
Received: from sivswdev02.ir.intel.com (localhost [127.0.0.1])
 by sivswdev02.ir.intel.com with ESMTP id u0BHj3eZ029515;
 Mon, 11 Jan 2016 17:45:03 GMT
Received: (from afischet@localhost)
 by sivswdev02.ir.intel.com with  id u0BHj3a8029510;
 Mon, 11 Jan 2016 17:45:03 GMT
From: Antonio Fischetti <antonio.fischetti@intel.com>
To: dev@dpdk.org
Date: Mon, 11 Jan 2016 17:44:54 +0000
Message-Id: <1452534294-29241-1-git-send-email-antonio.fischetti@intel.com>
X-Mailer: git-send-email 1.7.4.1
Subject: [dpdk-dev] [PATCH] doc: add a further ACL example
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Jan 2016 17:45:07 -0000

Add a further ACL example where the elements of the search key
are not entirely fitting into the 4 consecutive bytes of all
input fields.

Signed-off-by: Antonio Fischetti <antonio.fischetti@intel.com>
---
 .../prog_guide/packet_classif_access_ctrl.rst      | 68 ++++++++++++++++++++++
 1 file changed, 68 insertions(+)
 mode change 100644 => 100755 doc/guides/prog_guide/packet_classif_access_ctrl.rst

diff --git a/doc/guides/prog_guide/packet_classif_access_ctrl.rst b/doc/guides/prog_guide/packet_classif_access_ctrl.rst
old mode 100644
new mode 100755
index a9a5815..5fd3d34
--- a/doc/guides/prog_guide/packet_classif_access_ctrl.rst
+++ b/doc/guides/prog_guide/packet_classif_access_ctrl.rst
@@ -246,6 +246,74 @@ A typical example of such an IPv6 2-tuple rule is a follows:
 Any IPv6 packets with protocol ID 6 (TCP), and source address inside the range
 [2001:db8:1234:0000:0000:0000:0000:0000 - 2001:db8:1234:ffff:ffff:ffff:ffff:ffff] matches the above rule.
 
+In the following example the last element of the search key is 8-bit long.
+So it is a case where the 4 consecutive bytes of an input field are not fully occupied.
+The structure for the classification is:
+
+.. code-block:: c
+
+    struct acl_key {
+        uint8_t ip_proto;
+        uint32_t ip_src;
+        uint32_t ip_dst;
+        uint8_t tos;      /*< This is partially using a 32-bit input element */
+    };
+
+The following array of field definitions can be used:
+
+.. code-block:: c
+
+    struct rte_acl_field_def ipv4_defs[4] = {
+        /* first input field - always one byte long. */
+        {
+            .type = RTE_ACL_FIELD_TYPE_BITMASK,
+            .size = sizeof (uint8_t),
+            .field_index = 0,
+            .input_index = 0,
+            .offset = offsetof (struct acl_key, ip_proto),
+        },
+
+        /* next input field (IPv4 source address) - 4 consecutive bytes. */
+        {
+            .type = RTE_ACL_FIELD_TYPE_MASK,
+            .size = sizeof (uint32_t),
+            .field_index = 1,
+            .input_index = 1,
+           .offset = offsetof (struct acl_key, ip_src),
+        },
+
+        /* next input field (IPv4 destination address) - 4 consecutive bytes. */
+        {
+            .type = RTE_ACL_FIELD_TYPE_MASK,
+            .size = sizeof (uint32_t),
+            .field_index = 2,
+            .input_index = 2,
+           .offset = offsetof (struct acl_key, ip_dst),
+        },
+
+        /*
+         * Next element of search key (Type of Service) is indeed 1 byte long.
+         * Anyway we need to allocate all the 4 consecutive bytes for it.
+         */
+        {
+            .type = RTE_ACL_FIELD_TYPE_BITMASK,
+            .size = sizeof (uint32_t), /* All the 4 consecutive bytes are allocated */
+            .field_index = 3,
+            .input_index = 3,
+            .offset = offsetof (struct acl_key, tos),
+        },
+    };
+
+A typical example of such an IPv4 4-tuple rule is as follows:
+
+::
+
+    source addr/mask  destination addr/mask  tos/mask protocol/mask
+    192.168.1.0/24    192.168.2.31/32        1/0xff   6/0xff
+
+Any IPv4 packets with protocol ID 6 (TCP), source address 192.168.1.[0-255], destination address 192.168.2.31,
+ToS 1 matches the above rule.
+
 When creating a set of rules, for each rule, additional information must be supplied also:
 
 *   **priority**: A weight to measure the priority of the rules (higher is better).
-- 
1.9.3