Re: [patch net-next RFC 2/3] switchdev: allow caller to explicitly use deferred attr_set version

2015-10-10 Thread Jiri Pirko
Sat, Oct 10, 2015 at 04:43:43AM CEST, sfel...@gmail.com wrote: > >> >>> >>>patch 3/3 I haven't looked at yet...I'm stuck on 2/3. >> >> It is very similar to 2/3, only for obj_add/del. > >Do we have examples of a deferred obj add or del? Maybe we should >hold off adding that support until someon

Re: [patch net-next RFC 2/3] switchdev: allow caller to explicitly use deferred attr_set version

2015-10-09 Thread Scott Feldman
On Thu, Oct 8, 2015 at 11:46 PM, Jiri Pirko wrote: > Fri, Oct 09, 2015 at 06:39:41AM CEST, sfel...@gmail.com wrote: >>On Thu, Oct 8, 2015 at 1:26 AM, Jiri Pirko wrote: >>> Thu, Oct 08, 2015 at 08:03:35AM CEST, sfel...@gmail.com wrote: On Wed, Oct 7, 2015 at 10:39 PM, Jiri Pirko wrote: >

Re: [patch net-next RFC 2/3] switchdev: allow caller to explicitly use deferred attr_set version

2015-10-08 Thread Jiri Pirko
Fri, Oct 09, 2015 at 06:39:41AM CEST, sfel...@gmail.com wrote: >On Thu, Oct 8, 2015 at 1:26 AM, Jiri Pirko wrote: >> Thu, Oct 08, 2015 at 08:03:35AM CEST, sfel...@gmail.com wrote: >>>On Wed, Oct 7, 2015 at 10:39 PM, Jiri Pirko wrote: Thu, Oct 08, 2015 at 06:27:07AM CEST, sfel...@gmail.com wr

Re: [patch net-next RFC 2/3] switchdev: allow caller to explicitly use deferred attr_set version

2015-10-08 Thread Scott Feldman
On Thu, Oct 8, 2015 at 1:26 AM, Jiri Pirko wrote: > Thu, Oct 08, 2015 at 08:03:35AM CEST, sfel...@gmail.com wrote: >>On Wed, Oct 7, 2015 at 10:39 PM, Jiri Pirko wrote: >>> Thu, Oct 08, 2015 at 06:27:07AM CEST, sfel...@gmail.com wrote: On Wed, Oct 7, 2015 at 11:30 AM, Jiri Pirko wrote: >

Re: [patch net-next RFC 2/3] switchdev: allow caller to explicitly use deferred attr_set version

2015-10-08 Thread Jiri Pirko
Thu, Oct 08, 2015 at 08:03:35AM CEST, sfel...@gmail.com wrote: >On Wed, Oct 7, 2015 at 10:39 PM, Jiri Pirko wrote: >> Thu, Oct 08, 2015 at 06:27:07AM CEST, sfel...@gmail.com wrote: >>>On Wed, Oct 7, 2015 at 11:30 AM, Jiri Pirko wrote: From: Jiri Pirko Caller should know if he can

Re: [patch net-next RFC 2/3] switchdev: allow caller to explicitly use deferred attr_set version

2015-10-07 Thread Scott Feldman
On Wed, Oct 7, 2015 at 10:39 PM, Jiri Pirko wrote: > Thu, Oct 08, 2015 at 06:27:07AM CEST, sfel...@gmail.com wrote: >>On Wed, Oct 7, 2015 at 11:30 AM, Jiri Pirko wrote: >>> From: Jiri Pirko >>> >>> Caller should know if he can call attr_set directly (when holding RTNL) >>> or if he has to use de

Re: [patch net-next RFC 2/3] switchdev: allow caller to explicitly use deferred attr_set version

2015-10-07 Thread Jiri Pirko
Thu, Oct 08, 2015 at 06:27:07AM CEST, sfel...@gmail.com wrote: >On Wed, Oct 7, 2015 at 11:30 AM, Jiri Pirko wrote: >> From: Jiri Pirko >> >> Caller should know if he can call attr_set directly (when holding RTNL) >> or if he has to use deferred version of this function. >> >> This also allows dri

Re: [patch net-next RFC 2/3] switchdev: allow caller to explicitly use deferred attr_set version

2015-10-07 Thread Scott Feldman
On Wed, Oct 7, 2015 at 11:30 AM, Jiri Pirko wrote: > From: Jiri Pirko > > Caller should know if he can call attr_set directly (when holding RTNL) > or if he has to use deferred version of this function. > > This also allows drivers to sleep inside attr_set and report operation > status back to sw

Re: [patch net-next RFC 2/3] switchdev: allow caller to explicitly use deferred attr_set version

2015-10-07 Thread kbuild test robot
Hi Jiri, [auto build test ERROR on net-next/master -- if it's inappropriate base, please ignore] config: i386-randconfig-x003-201540 (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): net/bri

[patch net-next RFC 2/3] switchdev: allow caller to explicitly use deferred attr_set version

2015-10-07 Thread Jiri Pirko
From: Jiri Pirko Caller should know if he can call attr_set directly (when holding RTNL) or if he has to use deferred version of this function. This also allows drivers to sleep inside attr_set and report operation status back to switchdev core. Switchdev core then warns if status is not ok, ins