On Wed, Dec 16, 2020 at 04:15:03PM +0100, Tobias Waldekranz wrote:
> On Mon, Dec 14, 2020 at 13:42, Ido Schimmel wrote:
> > On Mon, Dec 14, 2020 at 02:12:31AM +0200, Vladimir Oltean wrote:
> >> On Sun, Dec 13, 2020 at 10:18:27PM +0100, Tobias Waldekranz wrote:
> >> > On Sat, Dec 12, 2020 at 16:26,
On Mon, Dec 14, 2020 at 13:42, Ido Schimmel wrote:
> On Mon, Dec 14, 2020 at 02:12:31AM +0200, Vladimir Oltean wrote:
>> On Sun, Dec 13, 2020 at 10:18:27PM +0100, Tobias Waldekranz wrote:
>> > On Sat, Dec 12, 2020 at 16:26, Vladimir Oltean wrote:
>> > > On Fri, Dec 11, 2020 at 09:50:24PM +0100, T
On Mon, Dec 14, 2020 at 02:12:31AM +0200, Vladimir Oltean wrote:
> On Sun, Dec 13, 2020 at 10:18:27PM +0100, Tobias Waldekranz wrote:
> > On Sat, Dec 12, 2020 at 16:26, Vladimir Oltean wrote:
> > > On Fri, Dec 11, 2020 at 09:50:24PM +0100, Tobias Waldekranz wrote:
> > >> 2. The issue Vladimir ment
On Sun, Dec 13, 2020 at 22:18, Tobias Waldekranz wrote:
> On Sat, Dec 12, 2020 at 16:26, Vladimir Oltean wrote:
>> On Fri, Dec 11, 2020 at 09:50:24PM +0100, Tobias Waldekranz wrote:
>>> 2. The issue Vladimir mentioned above. This is also a straight forward
>>>fix, I have patch for tag_dsa, ma
On Sun, Dec 13, 2020 at 10:18:27PM +0100, Tobias Waldekranz wrote:
> On Sat, Dec 12, 2020 at 16:26, Vladimir Oltean wrote:
> > On Fri, Dec 11, 2020 at 09:50:24PM +0100, Tobias Waldekranz wrote:
> >> 2. The issue Vladimir mentioned above. This is also a straight forward
> >>fix, I have patch fo
On Sat, Dec 12, 2020 at 16:26, Vladimir Oltean wrote:
> On Fri, Dec 11, 2020 at 09:50:24PM +0100, Tobias Waldekranz wrote:
>> 2. The issue Vladimir mentioned above. This is also a straight forward
>>fix, I have patch for tag_dsa, making sure that offload_fwd_mark is
>>never set for ports i
On Fri, Dec 11, 2020 at 09:50:24PM +0100, Tobias Waldekranz wrote:
> On Tue, Dec 08, 2020 at 13:23, Vladimir Oltean wrote:
> > Sorry it took so long. I wanted to understand:
> > (a) where are the challenged for drivers to uniformly support software
> > bridging when they already have code for
On Tue, Dec 08, 2020 at 13:23, Vladimir Oltean wrote:
> Sorry it took so long. I wanted to understand:
> (a) where are the challenged for drivers to uniformly support software
> bridging when they already have code for bridge offloading. I found
> the following issues:
> - We have tagg
On Thu, Dec 10, 2020 at 00:21, Vladimir Oltean wrote:
> On Wed, Dec 09, 2020 at 11:01:25PM +0100, Tobias Waldekranz wrote:
>> It is not the Fibonacci sequence or anything, it is an integer in the
>> range 0..num_lags-1. I realize that some hardware probably allocate IDs
>> from some shared (and th
On Wed, Dec 09, 2020 at 11:59:50PM +0100, Andrew Lunn wrote:
> > so basically my point was that I think you are adding a lot of infra
> > in core DSA that only mv88e6xxx will use.
>
> That is true already, since mv88e6xxx is currently the only driver
> which supports D in DSA. And it has been Marve
On Wed, Dec 09, 2020 at 03:23:40PM +0100, Andrew Lunn wrote:
> On Wed, Dec 09, 2020 at 12:53:26PM +0200, Vladimir Oltean wrote:
> > On Wed, Dec 09, 2020 at 09:37:39AM +0100, Tobias Waldekranz wrote:
> > > I will remove `struct dsa_lag` in v4.
> >
> > Ok, thanks.
> > It would be nice if you could al
On Wed, Dec 09, 2020 at 04:21:31PM +0100, Tobias Waldekranz wrote:
> On Wed, Dec 09, 2020 at 15:27, Andrew Lunn wrote:
> >> I disagree. A LAG is one type of netdev that a DSA port can offload. The
> >> other one is the DSA port's own netdev, i.e. what we have had since time
> >> immemorial.
> >>
> so basically my point was that I think you are adding a lot of infra
> in core DSA that only mv88e6xxx will use.
That is true already, since mv88e6xxx is currently the only driver
which supports D in DSA. And it has been Marvell devices which
initially inspired the DSA framework, and has pushed
On Wed, Dec 09, 2020 at 11:01:25PM +0100, Tobias Waldekranz wrote:
> It is not the Fibonacci sequence or anything, it is an integer in the
> range 0..num_lags-1. I realize that some hardware probably allocate IDs
> from some shared (and thus possibly non-contiguous) pool. Maybe ocelot
> works like
On Wed, Dec 09, 2020 at 18:04, Vladimir Oltean wrote:
> On Wed, Dec 09, 2020 at 03:11:41PM +0100, Tobias Waldekranz wrote:
>> On Wed, Dec 09, 2020 at 12:53, Vladimir Oltean wrote:
>> > And I think that .port_lag_change passes more arguments than needed to
>> > the driver.
>>
>> You mean the `str
On Wed, Dec 09, 2020 at 03:11:41PM +0100, Tobias Waldekranz wrote:
> On Wed, Dec 09, 2020 at 12:53, Vladimir Oltean wrote:
> > And I think that .port_lag_change passes more arguments than needed to
> > the driver.
>
> You mean the `struct netdev_lag_lower_state_info`? Fine by me, it was
> mostly
On Wed, Dec 09, 2020 at 15:27, Andrew Lunn wrote:
>> I disagree. A LAG is one type of netdev that a DSA port can offload. The
>> other one is the DSA port's own netdev, i.e. what we have had since time
>> immemorial.
>>
>> dsa_port_offloads_netdev(dp, dev)?
>
> That is better.
...but there is an
> I disagree. A LAG is one type of netdev that a DSA port can offload. The
> other one is the DSA port's own netdev, i.e. what we have had since time
> immemorial.
>
> dsa_port_offloads_netdev(dp, dev)?
That is better. But a comment explaining what the function does might
be useful.
Andrew
On Wed, Dec 09, 2020 at 12:53:26PM +0200, Vladimir Oltean wrote:
> On Wed, Dec 09, 2020 at 09:37:39AM +0100, Tobias Waldekranz wrote:
> > I will remove `struct dsa_lag` in v4.
>
> Ok, thanks.
> It would be nice if you could also make .port_lag_leave return an int code.
I've not looked at the code
On Wed, Dec 09, 2020 at 12:53, Vladimir Oltean wrote:
> On Wed, Dec 09, 2020 at 09:37:39AM +0100, Tobias Waldekranz wrote:
>> I will remove `struct dsa_lag` in v4.
>
> Ok, thanks.
> It would be nice if you could also make .port_lag_leave return an int code.
Sure.
> And I think that .port_lag_cha
On Wed, Dec 09, 2020 at 09:37:39AM +0100, Tobias Waldekranz wrote:
> I will remove `struct dsa_lag` in v4.
Ok, thanks.
It would be nice if you could also make .port_lag_leave return an int code.
And I think that .port_lag_change passes more arguments than needed to
the driver.
> > I don't think t
On Tue, Dec 08, 2020 at 00:26, Andrew Lunn wrote:
> On Mon, Dec 07, 2020 at 10:19:47PM +0100, Tobias Waldekranz wrote:
>> On Fri, Dec 04, 2020 at 03:20, Andrew Lunn wrote:
>> >> +static inline bool dsa_port_can_offload(struct dsa_port *dp,
>> >> + struct net_device
On Tue, Dec 08, 2020 at 18:37, Vladimir Oltean wrote:
> On Tue, Dec 08, 2020 at 04:33:19PM +0100, Tobias Waldekranz wrote:
>> On Tue, Dec 08, 2020 at 13:23, Vladimir Oltean wrote:
>> > Sorry it took so long. I wanted to understand:
>> > (a) where are the challenged for drivers to uniformly suppor
> There are two points to be made:
> - Recently we have seen people with non-DSA (pure switchdev) hardware
> being compelled to write DSA drivers, because they noticed that a
> large part of the middle layer had already been written, and it
> presents an API with a lot of
On Tue, Dec 08, 2020 at 04:33:19PM +0100, Tobias Waldekranz wrote:
> On Tue, Dec 08, 2020 at 13:23, Vladimir Oltean wrote:
> > Sorry it took so long. I wanted to understand:
> > (a) where are the challenged for drivers to uniformly support software
> > bridging when they already have code for
On Tue, Dec 08, 2020 at 13:23, Vladimir Oltean wrote:
> Hi Tobias,
>
> On Wed, Dec 02, 2020 at 10:13:54AM +0100, Tobias Waldekranz wrote:
>> Monitor the following events and notify the driver when:
>>
>> - A DSA port joins/leaves a LAG.
>> - A LAG, made up of DSA ports, joins/leaves a bridge.
>> -
Hi Tobias,
On Wed, Dec 02, 2020 at 10:13:54AM +0100, Tobias Waldekranz wrote:
> Monitor the following events and notify the driver when:
>
> - A DSA port joins/leaves a LAG.
> - A LAG, made up of DSA ports, joins/leaves a bridge.
> - A DSA port in a LAG is enabled/disabled (enabled meaning
> "di
On Mon, Dec 07, 2020 at 10:19:47PM +0100, Tobias Waldekranz wrote:
> On Fri, Dec 04, 2020 at 03:20, Andrew Lunn wrote:
> >> +static int dsa_tree_setup_lags(struct dsa_switch_tree *dst)
> >> +{
> >> + struct dsa_port *dp;
> >> + unsigned int num;
> >> +
> >> + list_for_each_entry(dp, &dst->ports
On Thu, Dec 03, 2020 at 20:18, Florian Fainelli wrote:
> On 12/3/2020 5:33 PM, Andrew Lunn wrote:
>>> Of course, neither is fully correct. There is always more to improve on
>>> the communication side of things.
>>
>> I wonder if switchdev needs to gain an enumeration API? A way to ask
>> the und
On Fri, Dec 04, 2020 at 02:56, Vladimir Oltean wrote:
> On Fri, Dec 04, 2020 at 12:12:32AM +0100, Tobias Waldekranz wrote:
>> You make a lot of good points. I think it might be better to force the
>> user to be explicit about their choice though. Imagine something like
>> this:
>>
>> - We add NETI
On Fri, Dec 04, 2020 at 03:20, Andrew Lunn wrote:
>> +static int dsa_tree_setup_lags(struct dsa_switch_tree *dst)
>> +{
>> +struct dsa_port *dp;
>> +unsigned int num;
>> +
>> +list_for_each_entry(dp, &dst->ports, list)
>> +num = dp->ds->num_lags;
>> +
>> +list_for_each_
On 12/3/2020 5:33 PM, Andrew Lunn wrote:
>> Of course, neither is fully correct. There is always more to improve on
>> the communication side of things.
>
> I wonder if switchdev needs to gain an enumeration API? A way to ask
> the underlying driver, what can you offload? The user can then get
On 12/2/2020 1:13 AM, Tobias Waldekranz wrote:
> Monitor the following events and notify the driver when:
>
> - A DSA port joins/leaves a LAG.
> - A LAG, made up of DSA ports, joins/leaves a bridge.
> - A DSA port in a LAG is enabled/disabled (enabled meaning
> "distributing" in 802.3ad LACP
> +static int dsa_tree_setup_lags(struct dsa_switch_tree *dst)
> +{
> + struct dsa_port *dp;
> + unsigned int num;
> +
> + list_for_each_entry(dp, &dst->ports, list)
> + num = dp->ds->num_lags;
> +
> + list_for_each_entry(dp, &dst->ports, list)
> + num = min(
> Of course, neither is fully correct. There is always more to improve on
> the communication side of things.
I wonder if switchdev needs to gain an enumeration API? A way to ask
the underlying driver, what can you offload? The user can then get an
idea what is likely to be offloaded, and what not
On Fri, Dec 04, 2020 at 12:12:32AM +0100, Tobias Waldekranz wrote:
> You make a lot of good points. I think it might be better to force the
> user to be explicit about their choice though. Imagine something like
> this:
>
> - We add NETIF_F_SWITCHDEV_OFFLOAD, which is set on switchdev ports by
>
On Thu, Dec 03, 2020 at 10:35:12PM +0100, Tobias Waldekranz wrote:
> - If offloading is available, reject anything that can not be
> offloaded. My guess is that _any_ hardware offloaded setup will almost
> always yield a better solution for the user than a software fallback.
For the case where
On Thu, Dec 03, 2020 at 23:57, Vladimir Oltean wrote:
> On Thu, Dec 03, 2020 at 09:53:08PM +0100, Tobias Waldekranz wrote:
>> I am not sure which way is the correct one, but I do not think that it
>> necessarily _always_ correct to silently fallback to a non-offloaded
>> mode.
>
> Of course, neith
On Thu, Dec 03, 2020 at 09:53:08PM +0100, Tobias Waldekranz wrote:
> > I like the fact that we revert to a software-based implementation for
> > features the hardware can't offload. So rejecting other TX types is out
> > of the question.
>
> Well if we really want to be precise, we must also ensure
On Thu, Dec 03, 2020 at 22:09, Andrew Lunn wrote:
>> One could argue that if Linus had received an error instead, adapted his
>> teamd config and tried again, he would be a happier user and we might
>> not have to compete with his OS.
>>
>> I am not sure which way is the correct one, but I do not
> One could argue that if Linus had received an error instead, adapted his
> teamd config and tried again, he would be a happier user and we might
> not have to compete with his OS.
>
> I am not sure which way is the correct one, but I do not think that it
> necessarily _always_ correct to silentl
On Thu, Dec 03, 2020 at 18:24, Vladimir Oltean wrote:
> On Wed, Dec 02, 2020 at 10:13:54AM +0100, Tobias Waldekranz wrote:
>> +static inline bool dsa_lag_offloading(struct dsa_switch_tree *dst)
>> +{
>> +return dst->lags.num > 0;
>> +}
>
> You assume that the DSA switch, when it sets a non-zer
On Wed, Dec 02, 2020 at 10:13:54AM +0100, Tobias Waldekranz wrote:
> +static int dsa_slave_check_lag_upper(struct net_device *dev)
> +{
> + struct dsa_port *dp = dsa_slave_to_port(dev);
> + struct dsa_switch_tree *dst = dp->ds->dst;
> +
> + if (!dsa_lag_offloading(dst))
> +
On Wed, Dec 02, 2020 at 10:13:54AM +0100, Tobias Waldekranz wrote:
> +static inline bool dsa_lag_offloading(struct dsa_switch_tree *dst)
> +{
> + return dst->lags.num > 0;
> +}
You assume that the DSA switch, when it sets a non-zero number of LAGs,
can offload any type of LAG TX type, when in
On Wed, Dec 02, 2020 at 10:29:38PM +0100, Tobias Waldekranz wrote:
> Sorry about this. I missed an rtnl_dereference in the refactor between
> v2->v3. I have now integrated sparse into my workflow so at least this
> should not happen again.
Please do not resend right away. Give me one more day or s
On Wed, Dec 02, 2020 at 10:58, Jakub Kicinski wrote:
> On Wed, 2 Dec 2020 10:13:54 +0100 Tobias Waldekranz wrote:
>> Monitor the following events and notify the driver when:
>>
>> - A DSA port joins/leaves a LAG.
>> - A LAG, made up of DSA ports, joins/leaves a bridge.
>> - A DSA port in a LAG i
On Wed, 2 Dec 2020 10:13:54 +0100 Tobias Waldekranz wrote:
> Monitor the following events and notify the driver when:
>
> - A DSA port joins/leaves a LAG.
> - A LAG, made up of DSA ports, joins/leaves a bridge.
> - A DSA port in a LAG is enabled/disabled (enabled meaning
> "distributing" in 802
On Wed, Dec 02, 2020 at 12:07, Vladimir Oltean wrote:
> On Wed, Dec 02, 2020 at 10:13:54AM +0100, Tobias Waldekranz wrote:
>> +
>> +/* Link aggregates */
>> +struct {
>> +struct dsa_lag *pool;
>> +unsigned long *busy;
>> +unsigned int num;
>
> Can we get
On Wed, Dec 02, 2020 at 10:13:54AM +0100, Tobias Waldekranz wrote:
> Monitor the following events and notify the driver when:
>
> - A DSA port joins/leaves a LAG.
> - A LAG, made up of DSA ports, joins/leaves a bridge.
> - A DSA port in a LAG is enabled/disabled (enabled meaning
> "distributing"
Monitor the following events and notify the driver when:
- A DSA port joins/leaves a LAG.
- A LAG, made up of DSA ports, joins/leaves a bridge.
- A DSA port in a LAG is enabled/disabled (enabled meaning
"distributing" in 802.3ad LACP terms).
Each LAG interface to which a DSA port is attached is
50 matches
Mail list logo
