[ovs-dev] [PATCH] tnl-neigh-cache: Purge learnt neighbors when port/bridge is deleted

Flavio Leitner fbl at sysclose.org
Mon Jun 24 22:15:43 UTC 2019


On Mon, Jun 24, 2019 at 05:43:26PM -0400, Vasu Dasari wrote:
> On Mon, Jun 24, 2019 at 3:58 PM Flavio Leitner <fbl at sysclose.org> wrote:
> > On Wed, Jun 19, 2019 at 11:02:07PM -0400, Vasu Dasari wrote:
> > > +{
> > > +    struct tnl_neigh_entry *neigh;
> > > +    bool changed = false;
> > > +
> > > +    ovs_mutex_lock(&mutex);
> > > +    CMAP_FOR_EACH(neigh, cmap_node, &table) {
> > > +        if (nullable_string_is_equal(neigh->br_name, br_name)) {
> > > +            tnl_neigh_delete(neigh);
> > > +            changed = true;
> >
> > Do you expect to match on additional entries? Otherwise it
> > could bail out here.
> >
> >
> Say there are two or more neighbors on the port or on bridge, then by
> bailing out we would be missing others. So, will leave it there.

You're right.

[...]
> > However, as I mentioned in the discussion, the tnl IP address could
> > be on a device that doesn't belong to OVS at all. For example:
[...]
> > The tnl endpoint must have a valid route, so I suggest to hook the
> > tnl_neigh_cache_flush into route-table.c which receives a notification
> > when a route changes. If a route is deleted, we should flush the
> > device's tnl cache. Doing so, would cover both userspace and kernel
> > datapath for OVS and non-OVS devices.
> >
> >
> I see what you are saying. Let me play with code a bit and resubmit patch.

OK, looking forward to it!
Thanks Vasu, 
fbl


More information about the dev mailing list