On Tue, Dec 21, 2021 at 6:25 AM Lorenzo Bianconi < [email protected]> wrote: > > > 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. > I am open to this, but I would avoid changes if not necessary. The global states are currently encapsulated in the I-P module, which I think is ok as long as the engine is per process level. I didn't find it easier (or harder) to debug by wrapping them in a structure. I would consider this patch whenever multiple instances of the I-P engine are needed within a program.
> > > > > > > > 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? Yes, of course. Since this patch is needed only if multiple instances of I-P engine is used, I'd suggest reviewing it together with the series. There were situations in the past where people put lots of effort on something but received late feedback pointing out design problems wasting lots of their time. I wanted to avoid that as much as possible (and I am sorry if my feedback for this is already late). But if posting the rest of patches saves time in this case, let's do it that way :) Thanks, Han > > 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
