diff mbox

[mlxsw.wiki] ACLs: Add shared blocks

Message ID 20180426152750.13506-1-jiri@resnulli.us (mailing list archive)
State Accepted
Delegated to: Ido Schimmel
Headers show

Commit Message

Jiri Pirko April 26, 2018, 3:27 p.m. UTC 
From: Jiri Pirko <jiri@mellanox.com>

Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
 ACLs.md | 65 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 63 insertions(+), 2 deletions(-)

Comments

Ido Schimmel April 26, 2018, 3:40 p.m. UTC | #1 
On Thu, Apr 26, 2018 at 05:27:50PM +0200, Jiri Pirko wrote:
> -[1]: https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMellanox%2Fmlxsw%2Fwiki%2Ftc-filters.pdf&data=02%7C01%7Cidosch%40mellanox.com%7Cb32ee67022824e30b22608d5ab8a46ab%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C1%7C636603532744000693&sdata=pMmZDxbLg0byDZQGeo2cd3l6hLsXxW%2FV4wq1PGpbHDI%3D&reserved=0
> \ No newline at end of file
> +[1]: https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMellanox%2Fmlxsw%2Fwiki%2Ftc-filters.pdf&data=02%7C01%7Cidosch%40mellanox.com%7Cb32ee67022824e30b22608d5ab8a46ab%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C1%7C636603532744000693&sdata=pMmZDxbLg0byDZQGeo2cd3l6hLsXxW%2FV4wq1PGpbHDI%3D&reserved=0

Sigh...
Ido Schimmel April 27, 2018, 8:51 a.m. UTC | #2 
On Thu, Apr 26, 2018 at 05:27:50PM +0200, Jiri Pirko wrote:
> From: Jiri Pirko <jiri@mellanox.com>
> 
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>

Applied with minor changes. Thanks!

> ---
>  ACLs.md | 65 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 63 insertions(+), 2 deletions(-)
> 
> diff --git a/ACLs.md b/ACLs.md
> index 79a5c9aa3ee0..ffcf66b4ac4d 100644
> --- a/ACLs.md
> +++ b/ACLs.md
> @@ -7,7 +7,8 @@
>      5. [Trap Action Example Usage](#trap-action-example-usage)
>      6. [Multi-table/Multi-chain Support](#multi-tablemulti-chain-support)
>      7. [Mirred Action Example Usage](#mirred-action-example-usage)
> -    8. [More Examples](#more-examples)
> +    8. [Shared Blocks Support](#shared-blocks-support)
> +    9. [More Examples](#more-examples)
>  2. [Further Resources](#further-resources)
>  
>  TC Flower
> @@ -162,6 +163,66 @@ address `fe01::1`. The selected action is `mirred`.
>  This rule insertion instructs the hardware to redirect/mirror matched packet
>  to the specified interface, enp3s0np2 in the example.
>  
> +#### Shared Blocks Support
> +
> +By default, each qdisc has its own group of chains (each contains filters).
> +This group of chains is called `block`. For example for `ingress`
> +qdisc the mapping between netdev:qdisc:block is 1:1:1.
> +
> +But consider a case when you have 2 netdevices, you create ingress qdisc
> +on both. Now if you want to add identical set of filter rules to both,
> +you need to add them twice. One for each netdev:qdisc:block. That is
> +of course doable, but when the filters are offloaded to TCAM with limited
> +number of entries, the duplications may become a scale issue. Sharing of
> +blocks is aiming to resolve that.

Changed to: "Sharing of blocks aims to resolve that."


> +
> +In order to ask kernel to share blocks, one has to indicate so during qdisc
> +creation:
> +
> +```
> +$ tc qdisc add dev enp3s0np1 ingress_block 22 ingress
> +$ tc qdisc add dev enp3s0np2 ingress_block 22 ingress
> +```
> +
> +These two commands added ingress qdiscs to both netdevices. Note the
> +"ingress_block" option that indicates that both qdiscs should share the same
> +block identified by index "22". It is up to the user to choose the
> +block index.

Used `` instead of "" around ingress_block and 22.
Jiri Pirko April 27, 2018, 8:56 a.m. UTC | #3 
Fri, Apr 27, 2018 at 10:51:31AM CEST, idosch@mellanox.com wrote:
>On Thu, Apr 26, 2018 at 05:27:50PM +0200, Jiri Pirko wrote:
>> From: Jiri Pirko <jiri@mellanox.com>
>> 
>> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
>
>Applied with minor changes. Thanks!

Thanks.

>
>> ---
>>  ACLs.md | 65 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
>>  1 file changed, 63 insertions(+), 2 deletions(-)
>> 
>> diff --git a/ACLs.md b/ACLs.md
>> index 79a5c9aa3ee0..ffcf66b4ac4d 100644
>> --- a/ACLs.md
>> +++ b/ACLs.md
>> @@ -7,7 +7,8 @@
>>      5. [Trap Action Example Usage](#trap-action-example-usage)
>>      6. [Multi-table/Multi-chain Support](#multi-tablemulti-chain-support)
>>      7. [Mirred Action Example Usage](#mirred-action-example-usage)
>> -    8. [More Examples](#more-examples)
>> +    8. [Shared Blocks Support](#shared-blocks-support)
>> +    9. [More Examples](#more-examples)
>>  2. [Further Resources](#further-resources)
>>  
>>  TC Flower
>> @@ -162,6 +163,66 @@ address `fe01::1`. The selected action is `mirred`.
>>  This rule insertion instructs the hardware to redirect/mirror matched packet
>>  to the specified interface, enp3s0np2 in the example.
>>  
>> +#### Shared Blocks Support
>> +
>> +By default, each qdisc has its own group of chains (each contains filters).
>> +This group of chains is called `block`. For example for `ingress`
>> +qdisc the mapping between netdev:qdisc:block is 1:1:1.
>> +
>> +But consider a case when you have 2 netdevices, you create ingress qdisc
>> +on both. Now if you want to add identical set of filter rules to both,
>> +you need to add them twice. One for each netdev:qdisc:block. That is
>> +of course doable, but when the filters are offloaded to TCAM with limited
>> +number of entries, the duplications may become a scale issue. Sharing of
>> +blocks is aiming to resolve that.
>
>Changed to: "Sharing of blocks aims to resolve that."
>
>
>> +
>> +In order to ask kernel to share blocks, one has to indicate so during qdisc
>> +creation:
>> +
>> +```
>> +$ tc qdisc add dev enp3s0np1 ingress_block 22 ingress
>> +$ tc qdisc add dev enp3s0np2 ingress_block 22 ingress
>> +```
>> +
>> +These two commands added ingress qdiscs to both netdevices. Note the
>> +"ingress_block" option that indicates that both qdiscs should share the same
>> +block identified by index "22". It is up to the user to choose the
>> +block index.
>
>Used `` instead of "" around ingress_block and 22.
Jiri Pirko April 27, 2018, 8:57 a.m. UTC | #4 
Thu, Apr 26, 2018 at 05:40:57PM CEST, idosch@mellanox.com wrote:
>On Thu, Apr 26, 2018 at 05:27:50PM +0200, Jiri Pirko wrote:
>> -[1]: https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMellanox%2Fmlxsw%2Fwiki%2Ftc-filters.pdf&data=02%7C01%7Cidosch%40mellanox.com%7Cb32ee67022824e30b22608d5ab8a46ab%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C1%7C636603532744000693&sdata=pMmZDxbLg0byDZQGeo2cd3l6hLsXxW%2FV4wq1PGpbHDI%3D&reserved=0
>> \ No newline at end of file
>> +[1]: https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMellanox%2Fmlxsw%2Fwiki%2Ftc-filters.pdf&data=02%7C01%7Cidosch%40mellanox.com%7Cb32ee67022824e30b22608d5ab8a46ab%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C1%7C636603532744000693&sdata=pMmZDxbLg0byDZQGeo2cd3l6hLsXxW%2FV4wq1PGpbHDI%3D&reserved=0
>
>Sigh...

Well I don't understand why this hunk is there. I did not do any changes
at the end of the file. Git bug?
Petr Machata April 27, 2018, 4:21 p.m. UTC | #5 
Jiri Pirko <jiri@mellanox.com> writes:

> Thu, Apr 26, 2018 at 05:40:57PM CEST, idosch@mellanox.com wrote:
>>On Thu, Apr 26, 2018 at 05:27:50PM +0200, Jiri Pirko wrote:
>>> -[1]:
>>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMellanox%2Fmlxsw%2Fwiki%2Ftc-filters.pdf&data=02%7C01%7Cidosch%40mellanox.com%7Cb32ee67022824e30b22608d5ab8a46ab%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C1%7C636603532744000693&sdata=pMmZDxbLg0byDZQGeo2cd3l6hLsXxW%2FV4wq1PGpbHDI%3D&reserved=0
>>> \ No newline at end of file
>>> +[1]:
>>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMellanox%2Fmlxsw%2Fwiki%2Ftc-filters.pdf&data=02%7C01%7Cidosch%40mellanox.com%7Cb32ee67022824e30b22608d5ab8a46ab%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C1%7C636603532744000693&sdata=pMmZDxbLg0byDZQGeo2cd3l6hLsXxW%2FV4wq1PGpbHDI%3D&reserved=0
>>
>>Sigh...
>
> Well I don't understand why this hunk is there. I did not do any changes
> at the end of the file. Git bug?

If the technical writer touched that page before, it may have been left
without the terminal EOL. Your $EDITOR then added it automatically as
you saved, as they are known to do. Then MS safelinks fucked up the URL,
and that's what Ido sighs about.
Jiri Pirko April 27, 2018, 4:26 p.m. UTC | #6 
Fri, Apr 27, 2018 at 06:21:13PM CEST, petrm@mellanox.com wrote:
>Jiri Pirko <jiri@mellanox.com> writes:
>
>> Thu, Apr 26, 2018 at 05:40:57PM CEST, idosch@mellanox.com wrote:
>>>On Thu, Apr 26, 2018 at 05:27:50PM +0200, Jiri Pirko wrote:
>>>> -[1]:
>>>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMellanox%2Fmlxsw%2Fwiki%2Ftc-filters.pdf&data=02%7C01%7Cidosch%40mellanox.com%7Cb32ee67022824e30b22608d5ab8a46ab%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C1%7C636603532744000693&sdata=pMmZDxbLg0byDZQGeo2cd3l6hLsXxW%2FV4wq1PGpbHDI%3D&reserved=0
>>>> \ No newline at end of file
>>>> +[1]:
>>>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMellanox%2Fmlxsw%2Fwiki%2Ftc-filters.pdf&data=02%7C01%7Cidosch%40mellanox.com%7Cb32ee67022824e30b22608d5ab8a46ab%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C1%7C636603532744000693&sdata=pMmZDxbLg0byDZQGeo2cd3l6hLsXxW%2FV4wq1PGpbHDI%3D&reserved=0
>>>
>>>Sigh...
>>
>> Well I don't understand why this hunk is there. I did not do any changes
>> at the end of the file. Git bug?
>
>If the technical writer touched that page before, it may have been left
>without the terminal EOL. Your $EDITOR then added it automatically as
>you saved, as they are known to do. Then MS safelinks fucked up the URL,
>and that's what Ido sighs about.

Oh, got it. The screwed-up url is something that seems to me like the
only way the urls can be presented....
diff mbox

Patch

diff --git a/ACLs.md b/ACLs.md
index 79a5c9aa3ee0..ffcf66b4ac4d 100644
--- a/ACLs.md
+++ b/ACLs.md
@@ -7,7 +7,8 @@ 
     5. [Trap Action Example Usage](#trap-action-example-usage)
     6. [Multi-table/Multi-chain Support](#multi-tablemulti-chain-support)
     7. [Mirred Action Example Usage](#mirred-action-example-usage)
-    8. [More Examples](#more-examples)
+    8. [Shared Blocks Support](#shared-blocks-support)
+    9. [More Examples](#more-examples)
 2. [Further Resources](#further-resources)
 
 TC Flower
@@ -162,6 +163,66 @@  address `fe01::1`. The selected action is `mirred`.
 This rule insertion instructs the hardware to redirect/mirror matched packet
 to the specified interface, enp3s0np2 in the example.
 
+#### Shared Blocks Support
+
+By default, each qdisc has its own group of chains (each contains filters).
+This group of chains is called `block`. For example for `ingress`
+qdisc the mapping between netdev:qdisc:block is 1:1:1.
+
+But consider a case when you have 2 netdevices, you create ingress qdisc
+on both. Now if you want to add identical set of filter rules to both,
+you need to add them twice. One for each netdev:qdisc:block. That is
+of course doable, but when the filters are offloaded to TCAM with limited
+number of entries, the duplications may become a scale issue. Sharing of
+blocks is aiming to resolve that.
+
+In order to ask kernel to share blocks, one has to indicate so during qdisc
+creation:
+
+```
+$ tc qdisc add dev enp3s0np1 ingress_block 22 ingress
+$ tc qdisc add dev enp3s0np2 ingress_block 22 ingress
+```
+
+These two commands added ingress qdiscs to both netdevices. Note the
+"ingress_block" option that indicates that both qdiscs should share the same
+block identified by index "22". It is up to the user to choose the
+block index.
+
+If you list the existing qdiscs, you see the block sharing info in the output:
+
+```
+$ tc qdisc
+qdisc ingress ffff: dev enp3s0np1 parent ffff:fff1 ingress_block 22
+qdisc ingress ffff: dev enp3s0np2 parent ffff:fff1 ingress_block 22
+```
+
+To make it more visual, the situation looks like this:
+
+```
+   enp3s0np1 ingress qdisc            enp3s0np2 ingress qdisc
+              |                                  |
+              |                                  |
+              +---------->  block 22  <----------+
+```
+
+There is no limitation in number of qdiscs that can share the same block.
+
+Once the qdisc block is shared, it is no longer possible to manipulate
+the filters using the qdisc handle. One has to rather use the block
+index as a handle:
+
+```
+$ tc filter add block 22 protocol ip pref 25 flower dst_ip 192.168.0.0/16 action drop
+```
+
+Aside of the `ingress` qdisc, the block sharing is also supported for `clsact`
+qdisc. For that, user can decide to share ingress and egress block:
+
+```
+$ tc qdisc add dev enp3s0np3 ingress_block 23 egress_block 24 clsact
+```
+
 #### More Examples
 
 ```
@@ -186,4 +247,4 @@  Further Resources
 3. [QoS in Linux with TC and Filters][1] by Phil Sutter (part of `iproute`
 documentation)
 
-[1]: https://github.com/Mellanox/mlxsw/wiki/tc-filters.pdf
\ No newline at end of file
+[1]: https://github.com/Mellanox/mlxsw/wiki/tc-filters.pdf