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: <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

Powered by Openwall GNU/*/Linux Powered by OpenVZ