Table usage about faucet HOT 5 CLOSED

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> .

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> .

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> .