Date:	Sat, 10 Oct 2015 17:07:24 -0700
From:	Florian Fainelli <f.fainelli@...il.com>
To:	Vivien Didelot <vivien.didelot@...oirfairelinux.com>
Cc:	Jiri Pirko <jiri@...nulli.us>, Scott Feldman <sfeldma@...il.com>,
	Premkumar Jonnala <pjonnala@...adcom.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"siva.mannem.lnx@...il.com" <siva.mannem.lnx@...il.com>,
	"stephen@...workplumber.org" <stephen@...workplumber.org>,
	"roopa@...ulusnetworks.com" <roopa@...ulusnetworks.com>,
	"andrew@...n.ch" <andrew@...n.ch>
Subject: Re: [PATCH net-next v3 3/4] bridge: push bridge setting ageing_time
 down to switchdev

2015-10-10 15:41 GMT-07:00 Vivien Didelot <vivien.didelot@...oirfairelinux.com>:
> On Oct. Saturday 10 (41) 11:09 PM, Jiri Pirko wrote:
>> Sat, Oct 10, 2015 at 05:56:19PM CEST, vivien.didelot@...oirfairelinux.com wrote:
>> >On Oct. Saturday 10 (41) 09:04 AM, Jiri Pirko wrote:
>> >> Sat, Oct 10, 2015 at 04:53:52AM CEST, sfeldma@...il.com wrote:
>> >> >On Thu, Oct 8, 2015 at 9:38 PM, Premkumar Jonnala <pjonnala@...adcom.com> wrote:
>> >> >>
>> >> >>
>> >> >>> -----Original Message-----
>> >> >>> From: sfeldma@...il.com [mailto:sfeldma@...il.com]
>> >> >>> Sent: Friday, October 09, 2015 7:53 AM
>> >> >>> To: netdev@...r.kernel.org
>> >> >>> Cc: davem@...emloft.net; jiri@...nulli.us; siva.mannem.lnx@...il.com;
>> >> >>> Premkumar Jonnala; stephen@...workplumber.org;
>> >> >>> roopa@...ulusnetworks.com; andrew@...n.ch; f.fainelli@...il.com;
>> >> >>> vivien.didelot@...oirfairelinux.com
>> >> >>> Subject: [PATCH net-next v3 3/4] bridge: push bridge setting ageing_time down
>> >> >>> to switchdev
>> >> >>>
>> >> >>> From: Scott Feldman <sfeldma@...il.com>
>> >> >>>
>> >> >>> Use SWITCHDEV_F_SKIP_EOPNOTSUPP to skip over ports in bridge that don't
>> >> >>> support setting ageing_time (or setting bridge attrs in general).
>> >> >>>
>> >> >>> If push fails, don't update ageing_time in bridge and return err to user.
>> >> >>>
>> >> >>> If push succeeds, update ageing_time in bridge and run gc_timer now to
>> >> >>> recalabrate when to run gc_timer next, based on new ageing_time.
>> >> >>>
>> >> >>> Signed-off-by: Scott Feldman <sfeldma@...il.com>
>> >> >>> Signed-off-by: Jiri Pirko <jiri@...nulli.us>
>> >> >
>> >> ><snip>
>> >> >
>> >> >>> +int br_set_ageing_time(struct net_bridge *br, u32 ageing_time)
>> >> >>> +{
>> >> >>> +     struct switchdev_attr attr = {
>> >> >>> +             .id = SWITCHDEV_ATTR_ID_BRIDGE_AGEING_TIME,
>> >> >>> +             .flags = SWITCHDEV_F_SKIP_EOPNOTSUPP,
>> >> >>> +             .u.ageing_time = ageing_time,
>> >> >>> +     };
>> >> >>> +     unsigned long t = clock_t_to_jiffies(ageing_time);
>> >> >>> +     int err;
>> >> >>> +
>> >> >>> +     if (t < BR_MIN_AGEING_TIME || t > BR_MAX_AGEING_TIME)
>> >> >>> +             return -ERANGE;
>> >> >>> +
>> >> >>> +     err = switchdev_port_attr_set(br->dev, &attr);
>> >> >>
>> >> >> A thought - given that the ageing time is not a per-bridge-port attr, why are we using a "port based api"
>> >> >> to pass the attribute down?  May be I'm missing something here?
>> >> >
>> >> >I think Florian raised the same point earlier.  Sigh, I think this
>> >> >should be addressed....v4 coming soon...thanks guys for keeping the
>> >> >standard high.
>> >>
>> >> Scott, can you tell us how do you want to address this? I like the
>> >> current implementation.
>> >
>> >Scott, didn't you have a plan to add a struct device for the parent of
>> >switchdev ports?
>> >
>> >I think it would be good to introduce such device with an helper to
>> >retrieve this upper parent, and move the switchdev ops to this guy.
>> >
>> >So switchdev drivers may implement such API calls:
>> >
>> >    .obj_add(struct device *swdev, struct switchdev_obj *obj);
>> >
>> >    .port_obj_add(struct device *swdev, struct net_device *port,
>> >                  struct switchdev_obj *obj);
>> >
>> >Then switchdev code may have a parent API and the current port API may
>> >look like this:
>> >
>> >    int switchdev_port_obj_add(struct net_device *dev,
>> >                               struct switchdev_obj *obj)
>> >    {
>> >        struct device *swdev = switchdev_get_parent(dev);
>> >        int err = -EOPNOTSUPP;
>> >
>> >        if (swdev && swdev->switchdev_ops &&
>> >            swdev->switchdev_ops->port_obj_add)
>> >            err = swdev->switchdev_ops->port_obj_add(swdev, dev, obj);
>> >
>> >        return err;
>> >    }
>>
>> Fro the record, I don't see any reason for this "device". It would just
>> introduce unnecessary complexicity. So far, we are fine without it.
>
> I wouldn't say that. I beleive that an Ethernet switch deserves its
> struct device in the tree, since it is a physical chip, like any other.

Agreed, but gating these patches because we do not yet have a device
driver model for an Ethernet switch outside of its individual ports
does not seem like it hurts the current patch series, nor the existing
model (and future).

>
> Configuring it through one of its port (net_device) is fine, since you
> want to change the port behavior, and Linux config is on per-port basis.
>
> But the complexity is already introduced in the struct net_device with
> the switchdev_ops. These ops really belong to the parent device, not to
> all of its ports.

I am not sure if complexity is the correct term here, bloat (to some
extent) maybe, since with what you are suggesting we could save one
set of function pointers per-port, and instead move that to a
global/switch-wide device implementing these operations. In essence,
there will be per-port switchdev_ops, bridge-specific, and maybe in
the future switch device specific.

>
> Ideally a switch device would be registered with this set of operations,
> creates its net_devices, and will be accessible from a port net_device
> through a netdev helper function.

I think the core of the discussion for a proper Ethernet switch device
model is precisely whether we want to have a special network device to
configure the switch as a whole. It sure would represent one facet of
the switch device, but not everything else for which we are still
trying to find out what that is.
-- 
Florian
--
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