netdev - Re: [PATCH net-next 2/7] net: dsa: Add devlink regions support to DSA

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]

Message-ID: <20200816221709.ugb6qf7k4koc3y43@skbuf>
Date:   Mon, 17 Aug 2020 01:17:09 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     David Miller <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>, Chris Healy <cphealy@...il.com>,
        Vivien Didelot <vivien.didelot@...il.com>
Subject: Re: [PATCH net-next 2/7] net: dsa: Add devlink regions support to DSA

On Mon, Aug 17, 2020 at 12:06:32AM +0200, Andrew Lunn wrote:
> > Could we perhaps open-code these from the drivers themselves? There's
> > hardly any added value in DSA providing a "helper" for creation of
> > devlink resources (regions, shared buffers, etc).
>
> If we do change to open coding, would we remove the existing wrappers
> as well?
> 

Maybe?
I reckon one of the main reasons why DSA hides struct net_device is to
present a unified API for the ports that don't have one.
But with devlink we don't have that problem.

> > Take the ocelot/felix driver for example.
> 
> ocelot/felix is just plain odd. We have to do a balancing act for
> it. We don't want to take stuff out of the core just for this one odd
> switch, at the detriment for other normal DSA drivers.
> 

Yes, the ocelot/felix driver _is_ odd, but in my defence it's only as
odd as the hardware was integrated.
On the other hand, the model you're proposing would be forcing me to
register devlink regions in one way for felix DSA, and in another way
for ocelot switchdev. Or could I just ignore the helper, and call
devlink directly, even if there's a helper in place?

Thanks,
-Vladimir