> 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.
Since IP is managed as a library it would be nice to run it multiple times without introduce any dependency (e.g. global variable or symbols). Moreover, I think, removing the global symbols, the code would be even easier to maintain and/or debug. > > > > > 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? I think we can defer this discussion when I will post the series (I do not think it is related to this patch). Agree? Regards, Lorenzo > > 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
