On Thu, Apr 15, 2021 at 02:39, Vladimir Oltean wrote:
> On Wed, Apr 14, 2021 at 08:39:53PM +0200, Tobias Waldekranz wrote:
>> In order to have two entries for the same destination, they must belong
>> to different FIDs. But that FID is also used for automatic learning. So
>> if all ports use their
On Wed, Apr 14, 2021 at 08:39:53PM +0200, Tobias Waldekranz wrote:
> In order to have two entries for the same destination, they must belong
> to different FIDs. But that FID is also used for automatic learning. So
> if all ports use their own FID, all the switched traffic will have to be
> flooded
On Wed, Apr 14, 2021 at 17:14, Marek Behun wrote:
> On Tue, 13 Apr 2021 20:16:24 +0200
> Tobias Waldekranz wrote:
>
>> You could imagine a different mode in which the DSA driver would receive
>> the bucket allocation from the bond/team driver (which in turn could
>> come all the way from userspac
On Tue, 13 Apr 2021 20:16:24 +0200
Tobias Waldekranz wrote:
> You could imagine a different mode in which the DSA driver would receive
> the bucket allocation from the bond/team driver (which in turn could
> come all the way from userspace). Userspace could then implement
> whatever strategy it w
On Tue, Apr 13, 2021 at 17:14, Marek Behun wrote:
> On Tue, 13 Apr 2021 16:46:32 +0200
> Tobias Waldekranz wrote:
>
>> On Tue, Apr 13, 2021 at 02:27, Marek Behun wrote:
>> > On Tue, 13 Apr 2021 01:54:50 +0200
>> > Marek Behun wrote:
>> >
>> >> I will look into this, maybe ask some follow-up q
On Tue, 13 Apr 2021 16:46:32 +0200
Tobias Waldekranz wrote:
> On Tue, Apr 13, 2021 at 02:27, Marek Behun wrote:
> > On Tue, 13 Apr 2021 01:54:50 +0200
> > Marek Behun wrote:
> >
> >> I will look into this, maybe ask some follow-up questions.
> >
> > Tobias,
> >
> > it seems that currently t
On Tue, Apr 13, 2021 at 02:27, Marek Behun wrote:
> On Tue, 13 Apr 2021 01:54:50 +0200
> Marek Behun wrote:
>
>> I will look into this, maybe ask some follow-up questions.
>
> Tobias,
>
> it seems that currently the LAGs in mv88e6xxx driver do not use the
> HashTrunk feature (which can be enabled
On Tue, Apr 13, 2021 at 01:54, Marek Behun wrote:
> On Tue, 13 Apr 2021 01:13:53 +0200
> Tobias Waldekranz wrote:
>
>> > ...you could get the isolation in place. But you will still lookup the
>> > DA in the ATU, and there you will find a destination of either cpu0 or
>> > cpu1. So for one of the
On Tue, 13 Apr 2021 02:27:30 +0200
Marek Behun wrote:
> On Tue, 13 Apr 2021 01:54:50 +0200
> Marek Behun wrote:
>
> > I will look into this, maybe ask some follow-up questions.
>
> Tobias,
>
> it seems that currently the LAGs in mv88e6xxx driver do not use the
> HashTrunk feature (which can b
On Tue, 13 Apr 2021 01:54:50 +0200
Marek Behun wrote:
> I will look into this, maybe ask some follow-up questions.
Tobias,
it seems that currently the LAGs in mv88e6xxx driver do not use the
HashTrunk feature (which can be enabled via bit 11 of the
MV88E6XXX_G2_TRUNK_MAPPING register).
If we u
On Tue, 13 Apr 2021 01:13:53 +0200
Tobias Waldekranz wrote:
> > ...you could get the isolation in place. But you will still lookup the
> > DA in the ATU, and there you will find a destination of either cpu0 or
> > cpu1. So for one of the ports, the destination will be outside of its
> > port base
On Tue, Apr 13, 2021 at 01:09, Tobias Waldekranz wrote:
> On Tue, Apr 13, 2021 at 00:55, Marek Behun wrote:
>> On Tue, 13 Apr 2021 00:05:51 +0200
>> Tobias Waldekranz wrote:
>>
>>> On Mon, Apr 12, 2021 at 23:50, Marek Behun wrote:
>>> > On Mon, 12 Apr 2021 23:22:45 +0200
>>> > Tobias Waldekranz
On Tue, Apr 13, 2021 at 00:55, Marek Behun wrote:
> On Tue, 13 Apr 2021 00:05:51 +0200
> Tobias Waldekranz wrote:
>
>> On Mon, Apr 12, 2021 at 23:50, Marek Behun wrote:
>> > On Mon, 12 Apr 2021 23:22:45 +0200
>> > Tobias Waldekranz wrote:
>> >
>> >> On Mon, Apr 12, 2021 at 21:30, Marek Behun
On Tue, 13 Apr 2021 01:48:05 +0300
Vladimir Oltean wrote:
> On Tue, Apr 13, 2021 at 12:26:52AM +0200, Tobias Waldekranz wrote:
> > On Tue, Apr 13, 2021 at 01:06, Vladimir Oltean wrote:
> > > On Mon, Apr 12, 2021 at 11:49:22PM +0200, Tobias Waldekranz wrote:
> > >> On Tue, Apr 13, 2021 at 00:
On Tue, 13 Apr 2021 00:05:51 +0200
Tobias Waldekranz wrote:
> On Mon, Apr 12, 2021 at 23:50, Marek Behun wrote:
> > On Mon, 12 Apr 2021 23:22:45 +0200
> > Tobias Waldekranz wrote:
> >
> >> On Mon, Apr 12, 2021 at 21:30, Marek Behun wrote:
> >> > On Mon, 12 Apr 2021 14:46:11 +0200
> >> > To
On Tue, Apr 13, 2021 at 12:26:52AM +0200, Tobias Waldekranz wrote:
> On Tue, Apr 13, 2021 at 01:06, Vladimir Oltean wrote:
> > On Mon, Apr 12, 2021 at 11:49:22PM +0200, Tobias Waldekranz wrote:
> >> On Tue, Apr 13, 2021 at 00:34, Vladimir Oltean wrote:
> >> > On Mon, Apr 12, 2021 at 11:22:45PM +0
On Tue, 13 Apr 2021 01:17:21 +0300
Vladimir Oltean wrote:
> On Tue, Apr 13, 2021 at 12:04:57AM +0200, Marek Behun wrote:
> > On Mon, 12 Apr 2021 19:32:11 +0300
> > Vladimir Oltean wrote:
> >
> > > On Mon, Apr 12, 2021 at 11:00:45PM +0800, DENG Qingfang wrote:
> > > > On Sun, Apr 11, 2021 at
On Tue, Apr 13, 2021 at 01:06, Vladimir Oltean wrote:
> On Mon, Apr 12, 2021 at 11:49:22PM +0200, Tobias Waldekranz wrote:
>> On Tue, Apr 13, 2021 at 00:34, Vladimir Oltean wrote:
>> > On Mon, Apr 12, 2021 at 11:22:45PM +0200, Tobias Waldekranz wrote:
>> >> On Mon, Apr 12, 2021 at 21:30, Marek Be
On Tue, Apr 13, 2021 at 12:04:57AM +0200, Marek Behun wrote:
> On Mon, 12 Apr 2021 19:32:11 +0300
> Vladimir Oltean wrote:
>
> > On Mon, Apr 12, 2021 at 11:00:45PM +0800, DENG Qingfang wrote:
> > > On Sun, Apr 11, 2021 at 09:50:17PM +0300, Vladimir Oltean wrote:
> > > >
> > > > So I'd be tempted t
On Mon, Apr 12, 2021 at 11:49:22PM +0200, Tobias Waldekranz wrote:
> On Tue, Apr 13, 2021 at 00:34, Vladimir Oltean wrote:
> > On Mon, Apr 12, 2021 at 11:22:45PM +0200, Tobias Waldekranz wrote:
> >> On Mon, Apr 12, 2021 at 21:30, Marek Behun wrote:
> >> > On Mon, 12 Apr 2021 14:46:11 +0200
> >> >
On Mon, Apr 12, 2021 at 23:50, Marek Behun wrote:
> On Mon, 12 Apr 2021 23:22:45 +0200
> Tobias Waldekranz wrote:
>
>> On Mon, Apr 12, 2021 at 21:30, Marek Behun wrote:
>> > On Mon, 12 Apr 2021 14:46:11 +0200
>> > Tobias Waldekranz wrote:
>> >
>> >> I agree. Unless you only have a few really
On Mon, 12 Apr 2021 19:32:11 +0300
Vladimir Oltean wrote:
> On Mon, Apr 12, 2021 at 11:00:45PM +0800, DENG Qingfang wrote:
> > On Sun, Apr 11, 2021 at 09:50:17PM +0300, Vladimir Oltean wrote:
> > >
> > > So I'd be tempted to say 'tough luck' if all your ports are not up, and
> > > the ones that
On Mon, 12 Apr 2021 23:49:22 +0200
Tobias Waldekranz wrote:
> On Tue, Apr 13, 2021 at 00:34, Vladimir Oltean wrote:
> > On Mon, Apr 12, 2021 at 11:22:45PM +0200, Tobias Waldekranz wrote:
> >> On Mon, Apr 12, 2021 at 21:30, Marek Behun wrote:
> >> > On Mon, 12 Apr 2021 14:46:11 +0200
> >> >
On Tue, Apr 13, 2021 at 00:34, Vladimir Oltean wrote:
> On Mon, Apr 12, 2021 at 11:22:45PM +0200, Tobias Waldekranz wrote:
>> On Mon, Apr 12, 2021 at 21:30, Marek Behun wrote:
>> > On Mon, 12 Apr 2021 14:46:11 +0200
>> > Tobias Waldekranz wrote:
>> >
>> >> I agree. Unless you only have a few rea
On Mon, 12 Apr 2021 23:22:45 +0200
Tobias Waldekranz wrote:
> On Mon, Apr 12, 2021 at 21:30, Marek Behun wrote:
> > On Mon, 12 Apr 2021 14:46:11 +0200
> > Tobias Waldekranz wrote:
> >
> >> I agree. Unless you only have a few really wideband flows, a LAG will
> >> typically do a great job with
On Mon, Apr 12, 2021 at 11:22:45PM +0200, Tobias Waldekranz wrote:
> On Mon, Apr 12, 2021 at 21:30, Marek Behun wrote:
> > On Mon, 12 Apr 2021 14:46:11 +0200
> > Tobias Waldekranz wrote:
> >
> >> I agree. Unless you only have a few really wideband flows, a LAG will
> >> typically do a great job w
On Mon, Apr 12, 2021 at 21:30, Marek Behun wrote:
> On Mon, 12 Apr 2021 14:46:11 +0200
> Tobias Waldekranz wrote:
>
>> I agree. Unless you only have a few really wideband flows, a LAG will
>> typically do a great job with balancing. This will happen without the
>> user having to do any configurat
On Mon, Apr 12, 2021 at 17:35, Vladimir Oltean wrote:
> On Mon, Apr 12, 2021 at 02:46:11PM +0200, Tobias Waldekranz wrote:
>> On Sun, Apr 11, 2021 at 21:50, Vladimir Oltean wrote:
>> > On Sun, Apr 11, 2021 at 08:01:35PM +0200, Marek Behun wrote:
>> >> On Sat, 10 Apr 2021 15:34:46 +0200
>> >> Ansu
On Mon, 12 Apr 2021 14:46:11 +0200
Tobias Waldekranz wrote:
> I agree. Unless you only have a few really wideband flows, a LAG will
> typically do a great job with balancing. This will happen without the
> user having to do any configuration at all. It would also perform well
> in "router-on-a-st
On Mon, Apr 12, 2021 at 11:00:45PM +0800, DENG Qingfang wrote:
> On Sun, Apr 11, 2021 at 09:50:17PM +0300, Vladimir Oltean wrote:
> >
> > So I'd be tempted to say 'tough luck' if all your ports are not up, and
> > the ones that are are assigned statically to the same CPU port. It's a
> > compromise
On Sun, Apr 11, 2021 at 09:50:17PM +0300, Vladimir Oltean wrote:
>
> So I'd be tempted to say 'tough luck' if all your ports are not up, and
> the ones that are are assigned statically to the same CPU port. It's a
> compromise between flexibility and simplicity, and I would go for
> simplicity her
On Mon, Apr 12, 2021 at 02:46:11PM +0200, Tobias Waldekranz wrote:
> On Sun, Apr 11, 2021 at 21:50, Vladimir Oltean wrote:
> > On Sun, Apr 11, 2021 at 08:01:35PM +0200, Marek Behun wrote:
> >> On Sat, 10 Apr 2021 15:34:46 +0200
> >> Ansuel Smith wrote:
> >>
> >> > Hi,
> >> > this is a respin of
On Sun, Apr 11, 2021 at 21:50, Vladimir Oltean wrote:
> On Sun, Apr 11, 2021 at 08:01:35PM +0200, Marek Behun wrote:
>> On Sat, 10 Apr 2021 15:34:46 +0200
>> Ansuel Smith wrote:
>>
>> > Hi,
>> > this is a respin of the Marek series in hope that this time we can
>> > finally make some progress wi
On Sun, Apr 11, 2021 at 09:50:17PM +0300, Vladimir Oltean wrote:
> On Sun, Apr 11, 2021 at 08:01:35PM +0200, Marek Behun wrote:
> > On Sat, 10 Apr 2021 15:34:46 +0200
> > Ansuel Smith wrote:
> >
> > > Hi,
> > > this is a respin of the Marek series in hope that this time we can
> > > finally make
On Sun, Apr 11, 2021 at 08:39:12PM +0200, Andrew Lunn wrote:
> On Sun, Apr 11, 2021 at 08:01:35PM +0200, Marek Behun wrote:
> > On Sat, 10 Apr 2021 15:34:46 +0200
> > Ansuel Smith wrote:
> >
> > > Hi,
> > > this is a respin of the Marek series in hope that this time we can
> > > finally make some
On 4/11/2021 4:53 PM, Vladimir Oltean wrote:
> On Sun, Apr 11, 2021 at 09:50:17PM +0300, Vladimir Oltean wrote:
>> On Sun, Apr 11, 2021 at 08:01:35PM +0200, Marek Behun wrote:
>>> On Sat, 10 Apr 2021 15:34:46 +0200
>>> Ansuel Smith wrote:
>>>
Hi,
this is a respin of the Marek series i
On 4/11/2021 11:39 AM, Andrew Lunn wrote:
> On Sun, Apr 11, 2021 at 08:01:35PM +0200, Marek Behun wrote:
>> On Sat, 10 Apr 2021 15:34:46 +0200
>> Ansuel Smith wrote:
>>
>>> Hi,
>>> this is a respin of the Marek series in hope that this time we can
>>> finally make some progress with dsa support
On Sun, Apr 11, 2021 at 09:50:17PM +0300, Vladimir Oltean wrote:
> On Sun, Apr 11, 2021 at 08:01:35PM +0200, Marek Behun wrote:
> > On Sat, 10 Apr 2021 15:34:46 +0200
> > Ansuel Smith wrote:
> >
> > > Hi,
> > > this is a respin of the Marek series in hope that this time we can
> > > finally make
On Sun, Apr 11, 2021 at 08:01:35PM +0200, Marek Behun wrote:
> On Sat, 10 Apr 2021 15:34:46 +0200
> Ansuel Smith wrote:
>
> > Hi,
> > this is a respin of the Marek series in hope that this time we can
> > finally make some progress with dsa supporting multi-cpu port.
> >
> > This implementation
On Sun, Apr 11, 2021 at 08:01:35PM +0200, Marek Behun wrote:
> On Sat, 10 Apr 2021 15:34:46 +0200
> Ansuel Smith wrote:
>
> > Hi,
> > this is a respin of the Marek series in hope that this time we can
> > finally make some progress with dsa supporting multi-cpu port.
> >
> > This implementation
On Sun, Apr 11, 2021 at 08:01:35PM +0200, Marek Behun wrote:
> On Sat, 10 Apr 2021 15:34:46 +0200
> Ansuel Smith wrote:
>
> > Hi,
> > this is a respin of the Marek series in hope that this time we can
> > finally make some progress with dsa supporting multi-cpu port.
> >
> > This implementation
On Sat, 10 Apr 2021 15:34:46 +0200
Ansuel Smith wrote:
> Hi,
> this is a respin of the Marek series in hope that this time we can
> finally make some progress with dsa supporting multi-cpu port.
>
> This implementation is similar to the Marek series but with some tweaks.
> This adds support for
Hi,
this is a respin of the Marek series in hope that this time we can
finally make some progress with dsa supporting multi-cpu port.
This implementation is similar to the Marek series but with some tweaks.
This adds support for multiple-cpu port but leave the driver the
decision of the type of lo
On 8/25/2019 12:13 AM, Marek Behun wrote:
> On Sat, 24 Aug 2019 13:04:04 -0700
> Florian Fainelli wrote:
>
>> Now, the 4.9 kernel behavior actually works just fine because eth1 is
>> not a special interface, so no tagging is expected, and "wifi", although
>> it supports DSA tagging, represents
On Sat, 24 Aug 2019 13:04:04 -0700
Florian Fainelli wrote:
> Now, the 4.9 kernel behavior actually works just fine because eth1 is
> not a special interface, so no tagging is expected, and "wifi", although
> it supports DSA tagging, represents another side of the CPU/host network
> stack, so you
On Sat, 24 Aug 2019 17:24:07 +0200
Andrew Lunn wrote:
> That is a new idea. Interesting.
>
> I would like to look around and see what else uses this "lan1@eth0"
> concept. We need to ensure it is not counter intuitive in general,
> when you consider all possible users.
There are not many users
On Sat, 24 Aug 2019 23:01:21 +0200
Marek Behun wrote:
> the documentation would became weird to users.
... would become weird ...
>
> We are *already* using the iflink property to report which CPU device
> is used as CPU destination port for a given switch slave interface. So
> why to use that f
On Sat, 24 Aug 2019 13:04:04 -0700
Florian Fainelli wrote:
> 1) Your approach is kind of interesting here, not sure if it is the best
> but it is not outright wrong. In the past, we had been talking about
> different approaches, some of which seemed too simplistic or too narrow
> on the use case,
On 8/23/2019 7:42 PM, Marek Behún wrote:
> Hi,
> this is my attempt to solve the multi-CPU port issue for DSA.
>
> Patch 1 adds code for handling multiple CPU ports in a DSA switch tree.
> If more than one CPU port is found in a tree, the code assigns CPU ports
> to user/DSA ports in a round ro
On Sat, 24 Aug 2019 17:56:36 +0200
Andrew Lunn wrote:
> I expect bad things will happen if frames are flooded to multiple CPU
> ports. For this to work, the whole switch design needs to support
> multiple CPU ports. I doubt this will work on any old switch.
>
> Having a host interface connected
On Sat, 24 Aug 2019 18:44:44 +0300
Vladimir Oltean wrote:
> Just to be clear. You can argue that such switches are weird, and
> that's ok. Just want to understand the general type of hardware for
> which such a patch is intended.
Vladimir,
the general part should solve for devices like Turris 1
On Sat, Aug 24, 2019 at 07:45:46PM +0200, Marek Behun wrote:
> On Sat, 24 Aug 2019 17:24:07 +0200
> Andrew Lunn wrote:
>
> > So this is all about transmit from the host out the switch. What about
> > receive? How do you tell the switch which CPU interface it should use
> > for a port?
>
> Andrew
On Sat, 24 Aug 2019 17:24:07 +0200
Andrew Lunn wrote:
> So this is all about transmit from the host out the switch. What about
> receive? How do you tell the switch which CPU interface it should use
> for a port?
Andrew, we use the same. The DSA slave implementation of ndo_set_iflink
will also t
> Will DSA assume that all CPU ports are equal in terms of tagging
> protocol abilities? There are switches where one of the CPU ports can
> do tagging and the other can't.
Hi Vladimir
Given the current definition of what a CPU port is, we have to assume
the port is using tags. Frames have to be
On Sat, 24 Aug 2019 at 18:40, Vladimir Oltean wrote:
>
> Hi Marek,
>
> On Sat, 24 Aug 2019 at 05:43, Marek Behún wrote:
> >
> > Hi,
> > this is my attempt to solve the multi-CPU port issue for DSA.
> >
> > Patch 1 adds code for handling multiple CPU ports in a DSA switch tree.
> > If more than on
Hi Marek,
On Sat, 24 Aug 2019 at 05:43, Marek Behún wrote:
>
> Hi,
> this is my attempt to solve the multi-CPU port issue for DSA.
>
> Patch 1 adds code for handling multiple CPU ports in a DSA switch tree.
> If more than one CPU port is found in a tree, the code assigns CPU ports
> to user/DSA p
On Sat, Aug 24, 2019 at 04:42:47AM +0200, Marek Behún wrote:
> Hi,
> this is my attempt to solve the multi-CPU port issue for DSA.
>
> Patch 1 adds code for handling multiple CPU ports in a DSA switch tree.
> If more than one CPU port is found in a tree, the code assigns CPU ports
> to user/DSA po
Hi,
this is my attempt to solve the multi-CPU port issue for DSA.
Patch 1 adds code for handling multiple CPU ports in a DSA switch tree.
If more than one CPU port is found in a tree, the code assigns CPU ports
to user/DSA ports in a round robin way. So for the simplest case where
we have one swit
58 matches
Mail list logo
