On Dec 20, Han Zhou wrote: > On Mon, Dec 20, 2021 at 10:32 AM Lorenzo Bianconi < > [email protected]> wrote: > > > > > On Mon, Dec 20, 2021 at 5:53 AM Lorenzo Bianconi < > > > [email protected]> wrote: > > > > > > > > Remove global state variable and move move inc-proc code in an > isolated > > > > strucuture. This is a preliminary patch to add the capability to run > > > > multiple inc-proc engines. > > > > > > > > > > Thanks Lorenzo! Could you tell more about the use case when multiple > > > inc-proc engines are required? > > > > Hi Han, > > > > I will rely on this patch to add an incremental processing engine for ovn > > meters since in the current codebase ovs meters are updated when an ovn > meter > > is added or deleted but when it is updated. > > Ok, thanks for the information. For meters, there are different types, ones > directly specified in lflows, and ones referencing SB meter table records. > Are you talking about the SB meter records handling? For either case, it > seems that we need to handle lflow together. Are we sure it is better to > have a separate engine than handling in the existing engine? What would be > the engine nodes and dependencies for the new engine?
I guess this patch is orthogonal to the ovn-meter case, it would be useful even for northd incremental processing started by Mark Gray. What do you think? Regarding the ovn-meter use case I am referencing to the SB meter table but we want to just update the meter bands w/o any change to the flow using the meter (the lflow just refers to the meter UUID, not to the bands). If we use a single engine we would be stopped by a force recompute before processing the SB meter table, losing in this case the new band info. Am I missing something? Regards, Lorenzo > > Thanks, > Han > > > > > Regards, > > Lorenzo > > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
