[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151001152821.GK20219@lunn.ch>
Date: Thu, 1 Oct 2015 17:28:21 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Vivien Didelot <vivien.didelot@...oirfairelinux.com>
Cc: Scott Feldman <sfeldma@...il.com>, Jiri Pirko <jiri@...nulli.us>,
Netdev <netdev@...r.kernel.org>,
Ido Schimmel <idosch@...lanox.com>, eladr@...lanox.com,
Florian Fainelli <f.fainelli@...il.com>,
Guenter Roeck <linux@...ck-us.net>,
"Rosen, Rami" <rami.rosen@...el.com>,
Roopa Prabhu <roopa@...ulusnetworks.com>,
Premkumar Jonnala <pjonnala@...adcom.com>,
Andy Gospodarek <gospo@...ulusnetworks.com>,
Jiri Pirko <jiri@...lanox.com>
Subject: Re: [patch net-next v3 02/10] switchdev: introduce transaction item
queue for attr_set and obj_add
> > Does this help? Maybe we should walk before running and focus on
> > getting non-batch ops working and then revisit?
>
> I agree. I understand the need for a prepare phase, but it looks like it
> exists for specific combinations, i.e. stacked and bonded devices.
>
> For basic Ethernet switch chips (even DSA), it is *for the moment* a bit
> too unnecessarily complex.
I think we are going to need it though. I have bonding on my TODO
list. That will put DSA into a stacked system.
> What I will suggest next, is to explicitly skip the prepare phase in DSA
> (with a good comment as you already suggested), and fix switchdev to
> allow drivers to return -EOPNOTSUPP from its commit phase.
The switches have a limited number of bonds, called trunks in Marvells
terminology. So we will need the prepare phase to say: Sorry, im out
of trunks, do it in software. And different chips have different
numbers of trunks, so it will need to go down into the chip driver,
the DSA layer probably cannot decide.
Andrew
--
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
Powered by blists - more mailing lists