linux-kernel - Re: [RFC 07/20] net: dsa: list ports in switch\\

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] [day] [month] [year] [list]

Date:	Thu, 28 Apr 2016 11:29:32 -0700
From:	Florian Fainelli <f.fainelli@...il.com>
To:	Vivien Didelot <vivien.didelot@...oirfairelinux.com>,
	Andrew Lunn <andrew@...n.ch>
Cc:	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	kernel@...oirfairelinux.com,
	"David S. Miller" <davem@...emloft.net>,
	Jiri Pirko <jiri@...nulli.us>
Subject: Re: [RFC 07/20] net: dsa: list ports in switch\\

On 28/04/16 11:18, Vivien Didelot wrote:
> Florian Fainelli <f.fainelli@...il.com> writes:
> 
>> On 27/04/16 16:15, Andrew Lunn wrote:
>>> On Wed, Apr 27, 2016 at 06:30:04PM -0400, Vivien Didelot wrote:
>>>> List DSA port structures in their switch structure, so that drivers can
>>>> iterate on them to retrieve information such as their ports membership.
>>>
>>> And this would be so much easier using a plan array.
>>
>> Agreed, I do not see much value in doing this at the moment. Even if you
>> have unused ports in a switch, allocating an array is a small price to
>> pay compared to directly indexing by port number.
>>
>> NAK from me unless there is a compelling reason for doing so.
> 
> The point of having a list is 1) get rid of the DSA_MAX_PORTS and have
> variable number of ports 2) lists make iteration easier with variable
> number of switchs/ports, e.g.:

You could get rid of the DSA_MAX_PORTS by asking switch drivers how many
ports they support and allocate that dynamically.

> 
>     dsa_tree_for_each_switch(dst, ds)
>         dsa_switch_for_each_port(ds, dp)
>             /* do something with the port */;

This is not more compact or efficient than an array walk, but at this
point this becoming preference over anything.

> 
> Anyway, I'm writing a proposal for a new design of DSA, in order to
> support the D in DSA. That way, we'll avoid reviewing details of the
> implementation and have a big picture of the necessary API changes.

Quite frankly, I think your set of changes are submitted at a terrible
time, I would very much prefer to allow Andrew to complete his work on
re-designing the DSA layer to allow different kinds of switches, thus
allowing other people to support more HW in a blink of an eye, and
therefore allowing us all to get a clearer picture of what these little
switches are capable, rather than some patches that produce a lot of
churn with little documented benefits outside of the cross-chip operations.

Don't get me wrong, I think we should get to the point where you want us
to go, and work in that area is very much appreciated!

Thanks
-- 
Florian