netdev - Re: [RFC PATCH net-next 0/2] Add new switchdev device class

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: <CAE4R7bD0Ka0187Qq=+6cZL7UqgnxJASKL_6AmaC2z_jiF5Jp1w@mail.gmail.com>
Date:	Thu, 27 Aug 2015 01:42:24 -0700
From:	Scott Feldman <sfeldma@...il.com>
To:	Andrew Lunn <andrew@...n.ch>
Cc:	Netdev <netdev@...r.kernel.org>,
	Jiří Pírko <jiri@...nulli.us>,
	"David S. Miller" <davem@...emloft.net>,
	Florian Fainelli <f.fainelli@...il.com>,
	Roopa Prabhu <roopa@...ulusnetworks.com>
Subject: Re: [RFC PATCH net-next 0/2] Add new switchdev device class

On Thu, Aug 27, 2015 at 12:45 AM, Andrew Lunn <andrew@...n.ch> wrote:
>> I don't know about how this overlaps with DSA platform_class.  Florian?
>
> There is some overlap with DSA, but the current DSA model, with
> respect to probing, is broken. So this might be interesting as a way
> towards fix that.
>
> One thing to keep in mind is the D in DSA. You talk about switch,
> singular. DSA has a number of switches in a cluster. We currently
> export a single switchdev interface for the cluster, but there are
> some properties which are per switch, e.g. temperature, eeprom
> contents, statistics, power management etc.

Export a single 'switchdev' or 'netdev' for the cluster?  I hope that
was a typo.  With switchdev device class, you'd instantiate one per
phy switch, and have per-switch props (temp, eeprom, etc) thru each
switchdev instance.  The cluster netdev would stay a netdev which
spans the switches.

>
> Although ethtool does have options for these, it is not always a
> natural fit. ethtool --eeprom-dump on a switch port dumps the switch
> EEPROM, and all ports on the switch can be used. --register-dump on a
> port is good for showing the per ports registers, but there is no
> natural interface for showing the global switch registers. Florian's
> resent L2 interface patch shows we have issues getting access to the
> 'cpu' port, the port which interfaces to the host.
>
> We need to be careful that any new interfaces we add are better at
> representing the true structure of the hardware, which includes there
> being multiple physical switches below a switchdev, and they are
> connected together by ports which are currently not visible as
> netdevs.

Right.  I'm thinking one switchdev instance (based on the new
switchdev class) per phy switch.  Port netdevs for switch ports worth
exposing (for user interaction).  And cluster netdev for dsa tagging
encap/decap.  Do I have this right?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html