netdev - Re: [PATCH RFC net-next 0/3] Multi-CPU DSA support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 13 Apr 2021 00:47:06 +0200
From:   Marek Behun <marek.behun@....cz>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     DENG Qingfang <dqfext@...il.com>,
        Ansuel Smith <ansuelsmth@...il.com>, netdev@...r.kernel.org,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andriin@...com>,
        Eric Dumazet <edumazet@...gle.com>,
        Wei Wang <weiwan@...gle.com>,
        Cong Wang <cong.wang@...edance.com>,
        Taehee Yoo <ap420073@...il.com>,
        Björn Töpel <bjorn@...nel.org>,
        zhang kai <zhangkaiheb@....com>,
        Weilong Chen <chenweilong@...wei.com>,
        Roopa Prabhu <roopa@...ulusnetworks.com>,
        Di Zhu <zhudi21@...wei.com>,
        Francis Laniel <laniel_francis@...vacyrequired.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC net-next 0/3] Multi-CPU DSA support

On Tue, 13 Apr 2021 01:17:21 +0300
Vladimir Oltean <olteanv@...il.com> 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 <olteanv@...il.com> 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 are are assigned statically to the same CPU port. It's a
> > > > > compromise between flexibility and simplicity, and I would go for
> > > > > simplicity here. That's the most you can achieve with static assignment,
> > > > > just put the CPU ports in a LAG if you want better dynamic load balancing
> > > > > (for details read on below).
> > > > >  
> > > >
> > > > Many switches such as mv88e6xxx only support MAC DA/SA load balancing,
> > > > which make it not ideal in router application (Router WAN <--> ISP BRAS
> > > > traffic will always have the same DA/SA and thus use only one port).  
> > >
> > > Is this supposed to make a difference? Choose a better switch vendor!  
> >
> > :-) Are you saying that we shall abandon trying to make the DSA
> > subsystem work with better performace for our routers, in order to
> > punish ourselves for our bad decision to use Marvell switches?  
> 
> No, not at all, I just don't understand what is the point you and
> Qingfang are trying to make.

I am not trying to make a point for this patch series. I did not touch
it since the last time I sent it. Ansuel just took over this series and
I am just contributing my thoughts to the RFC :)

I agree with you that this patch series still needs a lot of work.

> LAG is useful in general for load balancing.
> With the particular case of point-to-point links with Marvell Linkstreet,
> not so much. Okay. With a different workload, maybe it is useful with
> Marvell Linkstreet too. Again okay. Same for static assignment,
> sometimes it is what is needed and sometimes it just isn't.
> It was proposed that you write up a user space program that picks the
> CPU port assignment based on your favorite metric and just tells DSA to
> reconfigure itself, either using a custom fancy static assignment based
> on traffic rate (read MIB counters every minute) or simply based on LAG.
> All the data laid out so far would indicate that this would give you the
> flexibility you need, however you didn't leave any comment on that,
> either acknowledging or explaining why it wouldn't be what you want.

Yes, you are right. A custom userspace utility for assigning CPU ports
would be better here than adding lots of complication into the kernel
abstraction.