On Fri, Feb 24, 2017 at 1:10 AM, Numan Siddique <nusid...@redhat.com> wrote:
> > > > On Thu, Feb 23, 2017 at 11:06 PM, Mickey Spiegel <mickeys....@gmail.com> > wrote: > > > > > On Thu, Feb 23, 2017 at 6:04 AM, <nusid...@redhat.com> wrote: > > > >> From: Numan Siddique <nusid...@redhat.com> > >> > >> Having zone id per datapath is more than sufficient, because the > >> CT tuple information will be unique anyway with in the logical > >> datapath. > >> > > > > This proposal conflicts with another proposal that is currently in > flight ( > > https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328759.html > ), > > where we were thinking of using ct_label in SFC for load balancing > between > > multiple port pairs in one port pair group. In that case, for each SFC > hop > > we would need to pick up a different value from ct_label, so for SFC > ports > > we would need a different ct_zone for each logical port in one logical > > switch. > > > > Another issue is that this breaks the current use of ct_label.blocked in > > ACLs. If the ingress ACL allows a connection but the egress ACL blocks > the > > connection, then ingress will be clearing the bit while egress will be > > setting the bit. Perhaps this could be resolved by replacing > > ct_label.blocked with ct_label.blocked_ingress and > ct_label.blocked_egress? > > There might be other solutions, depending on the future patch that sends > to > > CT only once for both ingress and egress. > > > > Mickey > > > > > > Thanks Russel and Mickey for comments and pointing out the conflicts. > > I will abandon the patch for now and revisit later if it is required to > optimize for the same host scenario. > > > Or do you think it is good to optimize ? > I would hold off on it for now until we find out for sure that this is a critical scenario. I'll try asking around for some opinions. -- Russell Bryant _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
