The testsuite that checks for mcast_max_groups functionality will need to
wipe the added groups as well. Add helpers to build an IGMP or MLD packets
announcing that host is leaving a given group.
Signed-off-by: Petr Machata
Acked-by: Nikolay Aleksandrov
---
Add a suite covering mcast_n_groups and mcast_max_groups bridge features.
Signed-off-by: Petr Machata
---
Notes:
v2:
- Adjust the tests that check setting max below n and
reset of max on VLAN snooping enablement
- Make test naming uniform
- Enable testing of control path
In order to generate IGMPv3 and MLDv2 packets on the fly, the
functions that generate these packets need to be able to generate
packets for different groups and different sources. Generating MLDv2
packets further needs the source address of the packet for purposes of
checksum calculation. Add the
Add the letter missing from the word "INCLUDE".
Signed-off-by: Petr Machata
Reviewed-by: Ido Schimmel
Acked-by: Nikolay Aleksandrov
---
tools/testing/selftests/net/forwarding/bridge_mdb.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
The testsuite that checks for mcast_max_groups functionality will need
to generate IGMP and MLD packets with configurable number of (S,G)
addresses. To that end, further extend igmpv3_is_in_get() and
mldv2_is_in_get() to allow a list of IP addresses instead of one
address.
Signed-off-by: Petr
These functions will be helpful for other testsuites as well. Extract them
to a common place.
Signed-off-by: Petr Machata
Reviewed-by: Ido Schimmel
Acked-by: Nikolay Aleksandrov
---
.../selftests/net/forwarding/bridge_mdb.sh| 49 ---
In order to generate IGMPv3 and MLDv2 packets on the fly, we will need
helpers to calculate the packet checksum.
The approach presented in this patch revolves around payload templates
for mausezahn. These are mausezahn-like payload strings (01:23:45:...)
with possibly one 2-byte sequence replaced
In order to generate IGMPv3 and MLDv2 packets on the fly, we will need
helpers to expand IPv4 and IPv6 addresses given as parameters in
mausezahn payload notation. Add helpers that do it.
Signed-off-by: Petr Machata
Acked-by: Nikolay Aleksandrov
---
The previous patch added accounting for number of MDB entries per port and
per port-VLAN, and the logic to verify that these values stay within
configured bounds. However it didn't provide means to actually configure
those bounds or read the occupancy. This patch does that.
Two new netlink
The following patch will add two more maximum MDB allowances to the global
one, mcast_hash_max, that exists today. In all these cases, attempts to add
MDB entries above the configured maximums through netlink, fail noisily and
obviously. Such visibility is missing when adding entries through the
The MDB maintained by the bridge is limited. When the bridge is configured
for IGMP / MLD snooping, a buggy or malicious client can easily exhaust its
capacity. In SW datapath, the capacity is configurable through the
IFLA_BR_MCAST_HASH_MAX parameter, but ultimately is finite. Obviously a
similar
Since cleaning up the effects of br_multicast_new_port_group() just
consists of delisting and freeing the memory, the function
br_mdb_add_group_star_g() inlines the corresponding code. In the following
patches, number of per-port and per-port-VLAN MDB entries is going to be
maintained, and that
Make it possible to set an extack in br_multicast_new_port_group().
Eventually, this function will check for per-port and per-port-vlan
MDB maximums, and will use the extack to communicate the reason for
the bounce.
Signed-off-by: Petr Machata
Reviewed-by: Ido Schimmel
Acked-by: Nikolay
This function is getting more to clean up in the following patches.
Structuring the cleanups in one labeled block will allow reusing the same
cleanup from several places.
Signed-off-by: Petr Machata
Reviewed-by: Ido Schimmel
Acked-by: Nikolay Aleksandrov
---
net/bridge/br_multicast.c | 7
Now that br_multicast_new_port_group() takes an extack argument, move
setting the extack there. The downside is that the error messages end
up being less specific (the function cannot distinguish between (S,G)
and (*,G) groups). However, the alternative is to check in the caller
whether the callee
Make any attributes newly-added to br_port_policy or vlan_tunnel_policy
parsed strictly, to prevent userspace from passing garbage. Note that this
patchset only touches the former policy. The latter was adjusted for
completeness' sake. There do not appear to be other _deprecated calls
with
The MDB maintained by the bridge is limited. When the bridge is configured
for IGMP / MLD snooping, a buggy or malicious client can easily exhaust its
capacity. In SW datapath, the capacity is configurable through the
IFLA_BR_MCAST_HASH_MAX parameter, but ultimately is finite. Obviously a
similar
On 2023-01-31 20:25, Ido Schimmel wrote:
command like:
bridge fdb replace ADDR dev master dynamic
We choose only to support this feature on locked ports, as it involves
utilizing the CPU to handle ATU related switchcore events (typically
interrupts) and thus can result in significant
On 2023-01-31 19:56, Simon Horman wrote:
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -42,6 +42,7 @@
#include "ptp.h"
#include "serdes.h"
#include "smi.h"
+#include "switchdev.h"
static void assert_reg_lock(struct mv88e6xxx_chip *chip)
{
@@ -2726,18
On 2023-01-31 19:54, Simon Horman wrote:
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -1684,11 +1684,15 @@ static int b53_arl_op(struct b53_device *dev,
int op, int port,
int b53_fdb_add(struct dsa_switch *ds, int port,
const unsigned char
On 2023-02-02 17:11, Ido Schimmel wrote:
On Thu, Feb 02, 2023 at 08:28:36AM +0100, net...@kapio-technology.com
wrote:
On 2023-02-01 19:10, Ido Schimmel wrote:
> On Mon, Jan 30, 2023 at 06:34:25PM +0100, Hans J. Schultz wrote:
> > To be able to add dynamic FDB entries to drivers from userspace,
On Thu, Feb 02, 2023 at 05:19:07PM +0100, net...@kapio-technology.com wrote:
> On 2023-02-02 16:43, Ido Schimmel wrote:
> > On Thu, Feb 02, 2023 at 08:37:08AM +0100, net...@kapio-technology.com
> > wrote:
> > > On 2023-01-31 20:25, Ido Schimmel wrote:
> > > >
> > > > Will try to review tomorrow,
On Wed, 1 Feb 2023 18:28:39 +0100
Petr Machata wrote:
> The following patch will add two more maximum MDB allowances to the global
> one, mcast_hash_max, that exists today. In all these cases, attempts to add
> MDB entries above the configured maximums through netlink, fail noisily and
>
On 2023-02-02 16:43, Ido Schimmel wrote:
On Thu, Feb 02, 2023 at 08:37:08AM +0100, net...@kapio-technology.com
wrote:
On 2023-01-31 20:25, Ido Schimmel wrote:
>
> Will try to review tomorrow, but it looks like this set is missing
> selftests. What about extending bridge_locked_port.sh?
I knew
On Thu, Feb 02, 2023 at 08:28:36AM +0100, net...@kapio-technology.com wrote:
> On 2023-02-01 19:10, Ido Schimmel wrote:
> > On Mon, Jan 30, 2023 at 06:34:25PM +0100, Hans J. Schultz wrote:
> > > To be able to add dynamic FDB entries to drivers from userspace, the
> > > dynamic flag must be added
On Thu, Feb 02, 2023 at 08:37:08AM +0100, net...@kapio-technology.com wrote:
> On 2023-01-31 20:25, Ido Schimmel wrote:
> >
> > Will try to review tomorrow, but it looks like this set is missing
> > selftests. What about extending bridge_locked_port.sh?
>
> I knew you would take this up. :-)
>
Nikolay Aleksandrov writes:
> On 02/02/2023 10:52, Nikolay Aleksandrov wrote:
>> On 01/02/2023 19:28, Petr Machata wrote:
>>> +int br_multicast_vlan_ngroups_set_max(struct net_bridge *br,
>>> + struct net_bridge_vlan *v, u32 max,
>>> +
Nikolay Aleksandrov writes:
> On 01/02/2023 19:28, Petr Machata wrote:
>> @@ -668,6 +692,82 @@ void br_multicast_del_group_src(struct
>> net_bridge_group_src *src,
>> __br_multicast_del_group_src(src);
>> }
>>
>> +static int
>> +br_multicast_port_ngroups_inc_one(struct
Jakub Kicinski writes:
> On Wed, 1 Feb 2023 18:28:33 +0100 Petr Machata wrote:
>> Subject: [PATCH net-next mlxsw v2 00/16] bridge: Limit number of MDB entries
>> per port, port-vlan
>
> What do you mean by "net-next mlxsw"?
> Is there a tree called "net-next mlxsw" somewhere?
Sorry about
On 02/02/2023 10:52, Nikolay Aleksandrov wrote:
> On 01/02/2023 19:28, Petr Machata wrote:
>> The previous patch added accounting for number of MDB entries per port and
>> per port-VLAN, and the logic to verify that these values stay within
>> configured bounds. However it didn't provide means to
On 02/02/2023 10:56, Nikolay Aleksandrov wrote:
> On 01/02/2023 19:28, Petr Machata wrote:
>> The MDB maintained by the bridge is limited. When the bridge is configured
>> for IGMP / MLD snooping, a buggy or malicious client can easily exhaust its
>> capacity. In SW datapath, the capacity is
On 01/02/2023 19:28, Petr Machata wrote:
> The MDB maintained by the bridge is limited. When the bridge is configured
> for IGMP / MLD snooping, a buggy or malicious client can easily exhaust its
> capacity. In SW datapath, the capacity is configurable through the
> IFLA_BR_MCAST_HASH_MAX
On 01/02/2023 19:28, Petr Machata wrote:
> The previous patch added accounting for number of MDB entries per port and
> per port-VLAN, and the logic to verify that these values stay within
> configured bounds. However it didn't provide means to actually configure
> those bounds or read the
33 matches
Mail list logo
