[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAE4R7bDxc-XOBoVibGtzReM1kXi7HFLf5e8Zr0j0nJCHz+qTPQ@mail.gmail.com>
Date: Tue, 14 Apr 2015 00:51:46 -0700
From: Scott Feldman <sfeldma@...il.com>
To: Florian Fainelli <f.fainelli@...il.com>
Cc: Netdev <netdev@...r.kernel.org>,
Jiří Pírko <jiri@...nulli.us>,
Roopa Prabhu <roopa@...ulusnetworks.com>,
Guenter Roeck <linux@...ck-us.net>,
"Samudrala, Sridhar" <sridhar.samudrala@...el.com>,
"Arad, Ronen" <ronen.arad@...el.com>,
"andrew@...n.ch" <andrew@...n.ch>
Subject: Re: [PATCH net-next v4 03/24] switchdev: convert STP update to swdev
attr set
On Mon, Apr 13, 2015 at 12:22 PM, Florian Fainelli <f.fainelli@...il.com> wrote:
> On 12/04/15 23:16, sfeldma@...il.com wrote:
>> From: Scott Feldman <sfeldma@...il.com>
>>
>> STP update is just a writable port attribute, so convert swdev_port_stp_update
>> to an attr set.
>>
>> For rocker, support prepare-commit transaction model for setting STP state.
>> This requires rocker to preallocate memory needed for the commit up front in
>> the prepare phase. Since rtnl_lock is held between prepare-commit, store the
>> allocated memory on a queue hanging off of the rocker_port. Also, in prepare
>> phase, do everything right up to calling into HW. The same code paths are
>> tranversed in the driver for both prepare and commit phases. In some cases,
>> any state modified in the prepare phase must be reverted before returning
>> so the commit phase makes the same decisions.
>
> I now better understand the reason for introducing both the object and
> transactional model, but that is really a dramatic change in the API
> complexity now, and unfortunately this is reflected in the drivers using
> it...
Yes, the drivers must now individually handle each transaction phase
at the level that makes sense for the driver/device. For DSA, the
prepare phase is skipped and only the commit phase is run, as would
have happened before all this transactional model work. Rocker gets
more interesting because the driver allocates memory as it goes and
updates driver and device state in multiple steps, any which can fail,
so the prepare phase needs to do a lot of work before giving the all
clear for commit. I'm not sure how to up-level the prepare phase
since it's very device/driver specific.
> Can we try to classify switches by their underlying control/transport
> bus, essentially sleeping vs. non-sleeping I/O operations and provide a
> good enough abstraction from there which avoids drivers like rocker to
> have to maintain a list of transactions?
I'm not sure I follow the sleeping vs. non-sleeping classification.
--
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