On Thu, Feb 02, 2023 at 06:36:14PM +0200, Ido Schimmel wrote:
> 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
On Fri, Feb 03, 2023 at 09:20:22AM +0100, Simon Horman wrote:
> > else if (someflag)
> > dosomething();
> >
> > For now only one flag will actually be set and they are mutually exclusive,
> > as they will not make sense together with the potential flags I know, but
> > that can change at
On 2023-02-03 09:17, Simon Horman wrote:
On Thu, Feb 02, 2023 at 05:45:56PM +0100, net...@kapio-technology.com
wrote:
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
On Fri, Feb 03, 2023 at 05:27:43PM +0100, net...@kapio-technology.com wrote:
> On 2023-02-03 17:14, Ido Schimmel wrote:
> >
> > OK, so can't this hunk:
> >
> > ```
> > if (fdb_info->is_dyn)
> > fdb_flags |= DSA_FDB_FLAG_DYNAMIC;
> > ```
> >
> > Become:
> >
> > ```
> > if
On 2023-02-03 17:14, Ido Schimmel wrote:
OK, so can't this hunk:
```
if (fdb_info->is_dyn)
fdb_flags |= DSA_FDB_FLAG_DYNAMIC;
```
Become:
```
if (fdb_info->is_dyn && !fdb_info->added_by_user)
fdb_flags |= DSA_FDB_FLAG_DYNAMIC;
```
?
Then
On Fri, 3 Feb 2023 at 18:14, Ido Schimmel wrote:
> I *think* this is the change Vladimir asked you to do.
Yup, although instead of "is_dyn", I would still prefer "!is_static",
but again, that's a preference for bridge/switchdev maintainers to
override.
On Thu, Feb 02, 2023 at 05:38:06PM +0100, net...@kapio-technology.com wrote:
> On the first question please look here:
> https://lore.kernel.org/netdev/20230119134045.fqdt6zrna5x3iavt@skbuf/
It seems Vladimir also wants the new field to be named 'is_static'
instead of 'is_dyn'. In your reason you
On Thu, Feb 02, 2023 at 06:59:26PM +0100, 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
On Thu, Feb 02, 2023 at 06:59:25PM +0100, 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
>
On 02/02/2023 19:59, Petr Machata wrote:
> 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
> -
On 02/02/2023 19:59, 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
On 02/02/2023 19:59, 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 02/02/2023 19:59, 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
> obviously. Such
13 matches
Mail list logo
