Jarno Rajahalme writes:
> Pushed to master, but not sure if need to backport to earlier
> branches, as meters are not really supported by any release yet?
Nope, we only hit this because our own ofproto provider actually does
support meters.
Thanks for this!
Petr
___
Petr Machata writes:
> We don't actually see a crash, but an AddressSanitizer citation. As I'm
> now trying to reproduce on vanilla branch-2.5, I actually can't either
> (using the NULL trick). All the rule_delete calls end up being
> scheduled before the backer clo
Jarno Rajahalme writes:
> diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
> index 83dcc9c..5b42b7e 100644
> --- a/ofproto/ofproto-dpif.c
> +++ b/ofproto/ofproto-dpif.c
> @@ -864,7 +864,7 @@ close_dpif_backer(struct dpif_backer *backer)
> free(backer->type);
> free(backer->d
Jarno Rajahalme writes:
> Btw. I don’t see this problem triggered by the testsuite even if I set the
> ‘ofproto->backer' pointer
> to NULL right after the free() call. Do you see this happening on an
> unmodified OVS 2.5? If so,
> could you send the steps to reproduce. Just need to know if this
Hi,
On 2.5, we are seeing the following problem when removing a bridge:
- ofproto_destroy calls ofproto_flush__, which eventually calls
ovsrcu_postpone(remove_rules_rcu)
- ofproto_destroy also calls p->ofproto_class->destruct, which
eventually leads to release of DPIF backer (close_d
ve resources to forward-port our
provider and actually observe the issue in practice.
Thank you,
Petr Machata
--8<
An ofproto that's being destroyed could include rules with meters. Each
meter in turn holds a list of rules where
Ben Pfaff writes:
>> > want to make sure that the additional providers can be built without
>> > installing code that is available only under NDA.
>>
>> That is understood. The SAI backend will be optional.
>
> That's not exactly what I mean. I mean, there must be a way for users
> to compile
Ben Pfaff writes:
> We would be pleased to take additional ofproto pr oviders as long as
> they are clean and maintainable (and actually maintained). We would
We will want to put forward code that is up to snuff.
Regarding the "actually maintained" bit--that is the intention. But as
you are pr
Hello,
Mellanox would like to implement an OvS ofproto provider for SAI[1], a
vendor-neutral C API for programming switch ASIC's. Would there be
interest in merging this work upstream eventually?
We are not asking for a blank check here, but are trying to figure out
the general stance of the pro
