On Mon, Sep 21, 2020, 7:56 PM Mark Gray <[email protected]> wrote:

> On 21/09/2020 11:17, Numan Siddique wrote:
> > On Mon, Sep 21, 2020 at 2:49 PM Mark Gray <[email protected]>
> wrote:
> >
> >> On 14/09/2020 19:12, Numan Siddique wrote:
> >>> On Mon, Sep 14, 2020 at 10:18 PM Dumitru Ceara <[email protected]>
> >> wrote:
> >>>
> >>>> On 9/12/20 9:10 AM, Mark Gray wrote:
> ..
> >>>>
> >>>> I'm not sure whether this is completely correct.
> >>
> >> You are right, it is not correct.
> >>
> >>>>
> >>>> What if the sequence of operations is:
> >>>>
> >>>> ovn-nbctl set logical_switch sw other_config:requested-tnl-key=42
> >>>> # ovn-northd writes to datapath_binding.tunnel_key
> >>>>
> >>>> ovn-sbctl set datapath_binding sw external_ids:foo=bar
> >>>>
> >>
> >> I hadn't considered that case.
> >>
> >> If I only check for the case when the tunnel key gets updated, then this
> >> will force recompute on too many changes. For example, when I tried
> >> this, some tests in ovn_performance.at fail (when adding a logical
> >> router or logical switch). I don't think this is acceptable?
> >>
> >
> > I think it should be acceptable given that this use case happens rarely.
> > I think it's better to fall back to recompute in rare cases than handle
> it
> > incrementally
> > (and in the process make the code more complicated :) if it is not
> > straightforward to address it)
> >
> > Thanks
> > Numan
> >
> >
>
> Yeah, I don't want to fall into the trap of optimizing too early. What I
> don't know is how often a lr-add or ls-add happens. However, from what
> you are suggesting here, it is not too often so I will make the change
> as you suggest.
>

Hi Mark,

I think I misunderstood you. ls-add/lr-add would often happen. But setting
the tunnel key would not be that often. So I thought your patch would
trigger a recompute when a datapath in the south db would get updated (and
not when it is added ).

Thanks
Numan


>
>
> _______________________________________________
> dev mailing list
> [email protected]
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
>
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to