netdev - Re: [patch net-next v3 02/10] switchdev: introduce transaction item queue for attr_set and obj

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: <20150930185652.GA2455@ketchup.lan>
Date:	Wed, 30 Sep 2015 14:56:52 -0400
From:	Vivien Didelot <vivien.didelot@...oirfairelinux.com>
To:	Jiri Pirko <jiri@...nulli.us>, sfeldma@...il.com
Cc:	sfeldma@...il.com, jiri@...nulli.us, netdev@...r.kernel.org,
	idosch@...lanox.com, eladr@...lanox.com, f.fainelli@...il.com,
	linux@...ck-us.net, rami.rosen@...el.com,
	roopa@...ulusnetworks.com, pjonnala@...adcom.com, andrew@...n.ch,
	gospo@...ulusnetworks.com, jiri@...lanox.com
Subject: Re: [patch net-next v3 02/10] switchdev: introduce transaction item
 queue for attr_set and obj_add

Hi all,

On Sep. Friday 25 (39) 11:03 AM, Vivien Didelot wrote:
> On Sep. Thursday 24 (39) 10:55 PM, David Miller wrote:
> > From: Scott Feldman <sfeldma@...il.com>
> > Date: Thu, 24 Sep 2015 22:29:43 -0700
> > 
> > > I'd rather keep 2-phase not optional, or at least make it some what of
> > > a pain for drivers to opt-out of 2-phase.  Forcing the driver to see
> > > both phases means the driver needs to put some code to skip phase 1
> > > (and hopefully has some persistent comment explaining why its being
> > > skipped).  Something like:
> > > 
> > > /* I'm skipping phase 1 prepare for this operation.  I have infinite hardware
> > >  * resources and I'm not setting any persistent state in the driver or device
> > >  * and I don't need any dynamic resources from the kernel, so its impossible
> > >  * for me to fail phase 2 commit.  Nothing to prepare, sorry.
> > >  */
> > 
> > I agree with Scott here.
> > 
> > If you can opt out of something, you can not think about it and thus
> > more likely get it wrong.
> > 
> > I can just see a driver not implementing prepare at all and then doing
> > stupid things in commit when they hit some resource limit or whatever,
> > rather than taking care of such issues in prepare.
> 
> OK, I have no experience with stacked devices nor what it actually looks
> like, but I understand that it is a redundant setup where it makes sense
> to ensure that an operation is feasible before programming the hardware.
> 
> I agree with both of you on imposing switchdev drivers such notion.
> 
> I was confused with the rtnl lock (from bridge netlink requests) which
> seemed to limit a lot the usage of this prepare phase.
> 
> I don't know the batch mode neither, but I can think about a potentially
> powerful usage of the prepare phase in Marvell switches (or any basic
> home router switches), please tell me if the following is feasible:
> 
> Every hardware VLANs I know of are programmed with all port membership
> in one shot. This is not feasible today with the bridge command. If I
> could bundle in one request the equivalent of ("VID 100: 0u 1u 5t"):
> 
>     bridge vlan add master dev swp0 vid 100 pvid untagged
>     bridge vlan add master dev swp1 vid 100 pvid untagged
>     bridge vlan add master dev swp5 vid 100 # cpu
> 
> In such case the prepare phase could be great to allocate and populate a
> VLAN entry structure (i.e. struct mv88e6xxx_vtu_stu_entry) before
> programming the hardware *just once*. Is that doable?

May I get answers for this? I'd need that in order to suggest a next
step for the prepare phase in DSA drivers.

Thanks,
-v

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