[ovs-dev] [PATCH net-next 8/8] selftests: mlxsw: Add a new test extack.sh

Add a testsuite dedicated to testing extack propagation and related functionality. Signed-off-by: Petr Machata Acked-by: Jiri Pirko Reviewed-by: Ido Schimmel --- .../testing/selftests/drivers/net/mlxsw/extack.sh | 84 ++ 1 file changed, 84 insertions(+) create mode

[ovs-dev] [PATCH net-next 7/8] net: core: dev: Attach extack to NETDEV_PRE_UP

__dev_change_flags() and dev_open(), where it was propagated in the previous patches. Change __dev_open() to call call_netdevice_notifiers_extack() so that the passed-in extack is attached to the NETDEV_PRE_UP notifier. Signed-off-by: Petr Machata Acked-by: Jiri Pirko Reviewed-by: Ido Schimmel --- net

[ovs-dev] [PATCH net-next 5/8] net: core: dev: Add extack argument to __dev_change_flags()

existing users. Since the function declaration line is changed anyway, name the struct net_device argument to placate checkpatch. Signed-off-by: Petr Machata Acked-by: Jiri Pirko Reviewed-by: Ido Schimmel --- include/linux/netdevice.h | 3 ++- net/core/dev.c| 5 +++-- net/core

[ovs-dev] [PATCH net-next 6/8] net: core: dev: Add call_netdevice_notifiers_extack()

In order to propagate extack through NETDEV_PRE_UP, add a new function call_netdevice_notifiers_extack() that primes the extack field of the notifier info. Convert call_netdevice_notifiers() to a simple wrapper around the new function that passes NULL for extack. Signed-off-by: Petr Machata

[ovs-dev] [PATCH net-next 4/8] net: core: dev: Add extack argument to dev_change_flags()

extack argument and update all users. Most of the calls end up just encoding NULL, but several sites (VLAN, ipvlan, VRF, rtnetlink) do have extack available. Since the function declaration line is changed anyway, name the other function arguments to placate checkpatch. Signed-off-by: Petr Machata

[ovs-dev] [PATCH net-next 3/8] net: ipvlan: ipvlan_set_port_mode(): Add an extack argument

A follow-up patch will extend dev_change_flags() with an extack argument. Extend ipvlan_set_port_mode() to have that argument available for the conversion. Signed-off-by: Petr Machata Acked-by: Jiri Pirko Reviewed-by: Ido Schimmel --- drivers/net/ipvlan/ipvlan_main.c | 7 --- 1 file

[ovs-dev] [PATCH net-next 2/8] net: vrf: cycle_netdev(): Add an extack argument

A follow-up patch will extend dev_change_flags() with an extack argument. Extend cycle_netdev() to have that argument available for the conversion. Signed-off-by: Petr Machata Acked-by: Jiri Pirko Reviewed-by: Ido Schimmel --- drivers/net/vrf.c | 7 --- 1 file changed, 4 insertions(+), 3

[ovs-dev] [PATCH net-next 1/8] net: core: dev: Add extack argument to dev_open()

and update all users. Most of the calls end up just encoding NULL, but bond and team drivers have the extack readily available. Signed-off-by: Petr Machata Acked-by: Jiri Pirko Reviewed-by: Ido Schimmel --- drivers/net/bonding/bond_main.c | 2 +- drivers/net/ethernet/aquantia

[ovs-dev] [PATCH net-next 0/8] Pass extack to NETDEV_PRE_UP

ttl 200 # ip link set dev vx2 up Error: mlxsw_spectrum: Conflicting NVE tunnels configuration. Petr Machata (8): net: core: dev: Add extack argument to dev_open() net: vrf: cycle_netdev(): Add an extack argument net: ipvlan: ipvlan_set_port_mode(): Add an extack argument net: core: dev

Re: [ovs-dev] [PATCH] ofproto: Always delete rules before deleting a meter.

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

Re: [ovs-dev] Deferring ofproto_class::destruct vs. ovs-appctl exit

Petr Machata <pe...@mellanox.com> 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 befor

Re: [ovs-dev] Deferring ofproto_class::destruct vs. ovs-appctl exit

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); >

Re: [ovs-dev] Deferring ofproto_class::destruct vs. ovs-appctl exit

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

[ovs-dev] Deferring ofproto_class::destruct vs. ovs-appctl exit

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

[ovs-dev] [PATCH] Destroy rules before destroying meters

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 that mete

Re: [ovs-dev] SAI ofproto provider for OvS

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

Re: [ovs-dev] SAI ofproto provider for OvS

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.

[ovs-dev] SAI ofproto provider for OvS

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