linux-kernel - Re: [RFC PATCH net-next v3 1/1] net: Support for switch port configuration

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20141219003510.GC16239@casper.infradead.org>
Date:	Fri, 19 Dec 2014 00:35:10 +0000
From:	Thomas Graf <tgraf@...g.ch>
To:	John Fastabend <john.fastabend@...il.com>
Cc:	"Varlese, Marco" <marco.varlese@...el.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"Fastabend, John R" <john.r.fastabend@...el.com>,
	Jiri Pirko <jiri@...nulli.us>,
	"roopa@...ulusnetworks.com" <roopa@...ulusnetworks.com>,
	"sfeldma@...il.com" <sfeldma@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH net-next v3 1/1] net: Support for switch port
 configuration

On 12/18/14 at 08:03am, John Fastabend wrote:
> On 12/18/2014 07:30 AM, Varlese, Marco wrote:
> Could you also document the attributes. I think they are mostly
> clear but what is IFLA_SW_LOOPBACK. It will help later when we
> try to read the code in 6months and implement drivers.
> 
> I am thinking something like
> 
> /* Switch Port Attributes section
>  * IFLA_SW_LEARNING - turns learning on in the bridge
>  * IFLA_SW_LOOPBACK - does something interesting
> 
>  [...]
>  */

+1. I would even ask for more than that. While clear in the bridge
context, "learning" for this API targetting multi layer switches
is ambigious. The expectation towards the driver must be crystical
clear.

> >+
> >+enum {
> >+	IFLA_SW_UNSPEC,
> >+	IFLA_SW_LEARNING,
> 
> Can you address Roopa's feedback. I'm also a bit confused by the
> duplication.

Agreed. Can we decide on the ndo first and then build the APIs on
top of that? While I agree that we should have a non-bridge based
Netlink API, the underlying ndo should be the same.

> >+static const struct nla_policy ifla_sw_attr_policy[IFLA_SW_ATTR_MAX+1] = {
> >+	[IFLA_SW_LEARNING]	= { .type = NLA_U64 },
> >+	[IFLA_SW_LOOPBACK]	= { .type = NLA_U64 },
> >+	[IFLA_SW_BCAST_FLOODING] = { .type = NLA_U64 },
> >+	[IFLA_SW_UCAST_FLOODING] = { .type = NLA_U64 },
> >+	[IFLA_SW_MCAST_FLOODING] = { .type = NLA_U64 },
> >+};
> 
> Why U64 values? What would we pass in these? Are these just boolean
> bits? Maybe the annotation above will help me understand this.

I think the intent is to keep the ndo API as simple as possible
but I agree that this is wasteful. I gave this feedback on v2 already.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/