On 7/15/21 7:04 PM, Mark Gray wrote: > On 15/07/2021 15:29, Dumitru Ceara wrote: >> On 7/15/21 3:54 PM, Mark Gray wrote: >>> On 15/07/2021 14:16, Mark Michelson wrote: >>>> Hi Mark, >> >> Hi Mark, Mark, >> >>>> >>>> I'm a bit curious about this change. Does the removal of the protocol >>>> from the match mean that traffic that is not of the protocol specified >>>> in the load balancer will be ct_dnat()'ed? Does that constitute >>>> unexpected behavior? >>>> >>> >>> Yes, this is the case. It's a tradeoff between number of flows and >>> reirculations but thinking about it again, it may be better to have more >>> flows. I will create a v2. >>> >> >> Unless we match on proto *and* L4 port I don't think it's worth adding >> per proto flows. Assuming a TCP load balancer, all TCP traffic with >> destination VIP will still be ct_dnat()'ed, even if the TCP destination >> port is not the one defined in the load balancer VIP. >> >> On the other hand, using the same VIP for multiple ports is probably a >> common use case so if we add the L4 port to the match the number of >> logical flows might increase significantly. > > I don't think we can match on L4 port AFAIK, this could cause misses > with fragmented packets (which is the whole point of the defrag table).
You're right, sorry about the noise. > > I guess it depends on the use case as that will determine the number of > vips (which will generate a certain number of flows) and the traffic > pattern (which will determine the average number of ct_dnat()s). In a > system with a handful of VIPs for TCP traffic but mostly hosting UDP > traffic, it may be better to do as Mark M. suggests. > > The number of flows may not be that high as we only add one flow per > protocol rather than one per port. So I guess in the worst case, this > could be 4x the number of load balancer VIPs associated with the logical > router. > Ok, it doesn't sound that bad indeed. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
