Table usage

[KitL]

I'm looking at modifying the pipeline around ACLs, and maybe a couple of other things. Which has raised the question:

To what extent should we avoid using more and more openflow tables?

So should we be trying to use as few as possible, even when that isnt particularly logical, for example with the vlan table we are also filtering out BPDUs. I would prefer to have an initial filtering table, to keep things logically separated. But if this makes things significantly harder for hardware vendors, or would cause a considerable decrease in performance with ovs I think we probably ought to compromise (as these changes are somewhat cosmetic).

I could also see an upside to this by reducing the number of fields certain tables will need to match on.

So is anyone aware of issues with switch implementations when using more tables? (and by more tables, I am talking about in the order of maybe 20 at the absolute most).

[anarkiwi]

So, in general, more, narrower (ie less match types within a table) tables are better. This enables better memory management on the switch. Most commercially available hardware switches I've seen handle 15-30 tables (depending on the switch) no problem. Switches that do remapping onto to simpler Broadcom style hardware may find it harder to optimize (because the OFA has to be a bit smarter). But not unreasonably so. I think yes an initial filtering protocol filtering table would indeed make things tidier, and may provide additional benefits (eg allowing an earlier fork of IPv4 to IPv6 which would also be tidier). For that to work you might want to put the filter table after the initial VLAN tag check. Just a thought.

…

On Fri, Dec 9, 2016 at 11:48 AM, KitL ***@***.***> wrote: I'm looking at modifying the pipeline around ACLs, and maybe a couple of other things. Which has raised the question: To what extent should we avoid using more and more openflow tables? So should we be trying to use as few as possible, even when that isnt particularly logical, for example with the vlan table we are also filtering out BPDUs. I would prefer to have an initial filtering table, to keep things logically separated. But if this makes things significantly harder for hardware vendors, or would cause a considerable decrease in performance with ovs I think we probably ought to compromise (as these changes are somewhat cosmetic). I could also see an upside to this by reducing the number of fields certain tables will need to match on. So is anyone aware of issues with switch implementations when using more tables? (and by more tables, I am talking about in the order of maybe 20 at the absolute most). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#310>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEgZ12cpvwOXVjMnDYs8kjgMpQ-zLToaks5rGIkugaJpZM4LIX9n> .

[KitL]

Cool, that's basically what Joe said for OVS as well.

What I am thinking is about moving the port acls before vlan assignment. The main motivation is so that mirroring will happen before the switch starts modifying packets. So to do that we kinda want some other table before the port_acl table for when there are no acls on the port. Then after the vlan assignment we have the vlan_acl table.

So the first table would be filtering, port mirroring and port_acl bypass. Second table is port acls, third table is vlan assignment, 4th table is vlan acls, 5th is termination mac addresses, 6th is eth src, 7th and 8th are FIBs, 9th is eth dst, 10th is flooding.

[anarkiwi]

Sounds very reasonable to me. I suggest a quick test, on an AT to make sure it still gives you line rate performance after swapping VLAN/ACL tables, to check for any possible regressions early.

…

On Fri, Dec 9, 2016 at 3:05 PM, KitL ***@***.***> wrote: Cool, that's basically what Joe said for OVS as well. What I am thinking is about moving the port acls before vlan assignment. The main motivation is so that mirroring will happen before the switch starts modifying packets. So to do that we kinda want some other table before the port_acl table for when there are no acls on the port. Then after the vlan assignment we have the vlan_acl table. So the first table would be filtering, port mirroring and port_acl bypass. Second table is port acls, third table is vlan assignment, 4th table is vlan acls, 5th is termination mac addresses, 6th is eth src, 7th and 8th are FIBs, 9th is eth dst, 10th is flooding. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#310 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEgZ17-5XlH8LHX6K-8dosHqZgwfYmMYks5rGLeEgaJpZM4LIX9n> .

[gizmoguy]

With PR #333 merged in are we happy to close out this issue?

[anarkiwi]

LGTM.

…

On Thu, Jan 5, 2017 at 3:38 PM, Brad Cowie ***@***.***> wrote: With PR #333 <#333> merged in are we happy to close out this issue? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#310 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEgZ17X2-3vqPkcJ5RN5oWXvmb6EFurBks5rPFeIgaJpZM4LIX9n> .