On Mon, Dec 20, 2021 at 11:50 AM Lorenzo Bianconi < [email protected]> wrote: > > 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?
Maybe, but not necessary yet. I am not sure if northd would need multiple inc-proc instances. In general, unless two engine instances have completely separate nodes, there would be repeated processing for the overlapping nodes when we use separate inc-proc engine instances. > > 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). Ok, if it is just to reflect SB meter table change to the desired meter table (so that it is installed to OVS), and has nothing to do with logical flows, then why do we need inc-proc engine for this purpose? Would it be straightforward to use a FOR_EACH_TRACKED loop to handle and update? The inc-proc engine is required when there are multiple input dependencies. > 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. Sorry that I didn't understand this. If the dependency is added to the proper place in I-P engine, it should not lose any update processing. But perhaps I missed your point here. Would it be better to list the dependency you are thinking about and then it is easier to discuss? Thanks, Han > Am I missing something? > > Regards, > Lorenzo > > > > > Thanks, > > Han > > > > > > > > Regards, > > > Lorenzo > > > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
