On Thu, Nov 19, 2020 at 12:52:14PM +0100, Tobias Waldekranz wrote:
> > it appears that I don't need the .port_lag_change callback, and that the
>
> Ok, does ocelot automatically rebalance the LAG based on link state? I
> took a quick look through the datasheet for another switch from
> Vitesse, and
On Thu Nov 19, 2020 at 1:51 PM CET, Vladimir Oltean wrote:
> I have tested these patches on ocelot/felix and all is OK there, I would
> appreciate if you could resend as non-RFC. In the case of my hardware,
For sure, I am working on it as we speak. I was mostly waiting for the
dsa-tag-unification
On Tue, Oct 27, 2020 at 11:51:13AM +0100, Tobias Waldekranz wrote:
> This series starts by adding the generic support required to offload
> link aggregates to drivers built on top of the DSA subsystem. It then
> implements offloading for the mv88e6xxx driver, i.e. Marvell's
> LinkStreet family.
>
>
On 10/27/2020 3:51 AM, Tobias Waldekranz wrote:
> This series starts by adding the generic support required to offload
> link aggregates to drivers built on top of the DSA subsystem. It then
> implements offloading for the mv88e6xxx driver, i.e. Marvell's
> LinkStreet family.
>
> Posting this a
On Wed, Oct 28, 2020 at 01:45:11AM +0100, Tobias Waldekranz wrote:
> On Tue, Oct 27, 2020 at 23:36, Andrew Lunn wrote:
> > If you are dynamically allocating dsa_lag structures, at run time, you
> > need to think about this. But the number of LAGs is limited by the
> > number of ports. So i would c
On Tue, Oct 27, 2020 at 23:36, Andrew Lunn wrote:
> If you are dynamically allocating dsa_lag structures, at run time, you
> need to think about this. But the number of LAGs is limited by the
> number of ports. So i would consider just allocating the worst case
> number at probe, and KISS for runt
On Tue, 27 Oct 2020 19:25:16 +0100
Tobias Waldekranz wrote:
> .-. TO_CPU, FORWARD .-. TO_CPU, FORWARD .-.
> | +-+ +-+ |
> | CPU | | sw0 | | sw1 |
> | +-+ +-+ |
> '--
On Wed, Oct 28, 2020 at 00:32, Vladimir Oltean wrote:
> And this all happens because for FROM_CPU packets, the hardware is
> configured in mv88e6xxx_devmap_setup to deliver all packets with a
> non-local switch ID towards the same "routing" port, right?
Precisely.
> Whereas for FORWARD frames, t
Hi Tobias
> All LAG configuration is cached in `struct dsa_lag`s. I realize that
> the standard M.O. of DSA is to read back information from hardware
> when required. With LAGs this becomes very tricky though. For example,
> the change of a link state on one switch will require re-balancing of
> L
On Tue, Oct 27, 2020 at 09:53:45PM +0100, Tobias Waldekranz wrote:
> So all FROM_CPU packets to a given device/port will always travel
> through the same set of ports.
Ah, this is the part that didn't click for me.
For the simple case where you have a multi-CPU port system:
S
On Tue, Oct 27, 2020 at 22:02, Vladimir Oltean wrote:
> On Tue, Oct 27, 2020 at 08:37:58PM +0100, Tobias Waldekranz wrote:
>> >> In order for this to work on transmit, we need to add forward offloading
>> >> to the bridge so that we can, for example, send one FORWARD from the CPU
>> >> to send an
On Tue, Oct 27, 2020 at 08:37:58PM +0100, Tobias Waldekranz wrote:
> >> In order for this to work on transmit, we need to add forward offloading
> >> to the bridge so that we can, for example, send one FORWARD from the CPU
> >> to send an ARP broadcast to swp1..4 instead of four FROM_CPUs.
[...]
On Tue, Oct 27, 2020 at 21:00, Vladimir Oltean wrote:
> On Tue, Oct 27, 2020 at 07:25:16PM +0100, Tobias Waldekranz wrote:
>> > 1) trunk user ports, with team/bonding controlling it
>> > 2) trunk DSA ports, i.e. the ports between switches in a D in DSA setup
>> > 3) trunk CPU ports.
> [...]
>> I t
On Tue, Oct 27, 2020 at 21:04, Vladimir Oltean wrote:
> On Tue, Oct 27, 2020 at 07:33:37PM +0100, Marek Behun wrote:
>> > In order for this to work on transmit, we need to add forward offloading
>> > to the bridge so that we can, for example, send one FORWARD from the CPU
>> > to send an ARP broad
On Tue, Oct 27, 2020 at 07:33:37PM +0100, Marek Behun wrote:
> > In order for this to work on transmit, we need to add forward offloading
> > to the bridge so that we can, for example, send one FORWARD from the CPU
> > to send an ARP broadcast to swp1..4 instead of four FROM_CPUs.
>
> Wouldn't thi
On Tue, Oct 27, 2020 at 07:25:16PM +0100, Tobias Waldekranz wrote:
> > 1) trunk user ports, with team/bonding controlling it
> > 2) trunk DSA ports, i.e. the ports between switches in a D in DSA setup
> > 3) trunk CPU ports.
[...]
> I think that (2) and (3) are essentially the same problem, i.e. cr
> In order for this to work on transmit, we need to add forward offloading
> to the bridge so that we can, for example, send one FORWARD from the CPU
> to send an ARP broadcast to swp1..4 instead of four FROM_CPUs.
Wouldn't this be solved if the CPU master interface was a bonding interface?
On Tue, Oct 27, 2020 at 16:23, Andrew Lunn wrote:
> Hi Marek
>
> trunking is something i've looked at once, but never had time to work
> on. There are three different use cases i thought of:
>
> 1) trunk user ports, with team/bonding controlling it
> 2) trunk DSA ports, i.e. the ports between swit
On Tue, Oct 27, 2020 at 14:27, Vladimir Oltean wrote:
>> The LAG driver ops all receive the LAG netdev as an argument when this
>> information is already available through the port's lag pointer. This
>> was done to match the way that the bridge netdev is passed to all VLAN
>> ops even though it i
On Tue, Oct 27, 2020 at 04:05:30PM +0100, Marek Behun wrote:
> When I first read about port trunking in the Peridot documentation, I
> immediately thought that this could be used to transparently offload
> that which is called Bonding in Linux...
>
> Is this what you want to eventually do?
>
> BT
On Tue, Oct 27, 2020 at 15:00, Andrew Lunn wrote:
>> (mv88e6xxx) What is the policy regarding the use of DSA vs. EDSA? It
>> seems like all chips capable of doing EDSA are using that, except for
>> the Peridot.
>
> Hi Tobias
>
> Marvell removed the ability to use EDSA, in the way we do in Linux
>
When I first read about port trunking in the Peridot documentation, I
immediately thought that this could be used to transparently offload
that which is called Bonding in Linux...
Is this what you want to eventually do?
BTW, I thought about using port trunking to solve the multi-CPU DSA
issue as
> > (mv88e6xxx) What is the policy regarding the use of DSA vs. EDSA? It
> > seems like all chips capable of doing EDSA are using that, except for
> > the Peridot.
>
> I have no documentation whatsoever for mv88e6xxx, but just wondering,
> what is the benefit brought by EDSA here vs DSA? Does DSA
> (mv88e6xxx) What is the policy regarding the use of DSA vs. EDSA? It
> seems like all chips capable of doing EDSA are using that, except for
> the Peridot.
Hi Tobias
Marvell removed the ability to use EDSA, in the way we do in Linux
DSA, on Peridot. One of the configuration bits is gone. So i
Hi Tobias,
On Tue, Oct 27, 2020 at 11:51:13AM +0100, Tobias Waldekranz wrote:
> I would really appreciate feedback on the following:
>
> All LAG configuration is cached in `struct dsa_lag`s. I realize that
> the standard M.O. of DSA is to read back information from hardware
> when required. With
This series starts by adding the generic support required to offload
link aggregates to drivers built on top of the DSA subsystem. It then
implements offloading for the mv88e6xxx driver, i.e. Marvell's
LinkStreet family.
Posting this as an RFC as there are some topics that I would like
feedback on
26 matches
Mail list logo
