On Oct. Saturday 10 (41) 11:09 PM, Jiri Pirko wrote:
> Sat, Oct 10, 2015 at 05:56:19PM CEST, vivien.dide...@savoirfairelinux.com 
> wrote:
> >On Oct. Saturday 10 (41) 09:04 AM, Jiri Pirko wrote:
> >> Sat, Oct 10, 2015 at 04:53:52AM CEST, sfel...@gmail.com wrote:
> >> >On Thu, Oct 8, 2015 at 9:38 PM, Premkumar Jonnala <pjonn...@broadcom.com> 
> >> >wrote:
> >> >>
> >> >>
> >> >>> -----Original Message-----
> >> >>> From: sfel...@gmail.com [mailto:sfel...@gmail.com]
> >> >>> Sent: Friday, October 09, 2015 7:53 AM
> >> >>> To: netdev@vger.kernel.org
> >> >>> Cc: da...@davemloft.net; j...@resnulli.us; siva.mannem....@gmail.com;
> >> >>> Premkumar Jonnala; step...@networkplumber.org;
> >> >>> ro...@cumulusnetworks.com; and...@lunn.ch; f.faine...@gmail.com;
> >> >>> vivien.dide...@savoirfairelinux.com
> >> >>> Subject: [PATCH net-next v3 3/4] bridge: push bridge setting 
> >> >>> ageing_time down
> >> >>> to switchdev
> >> >>>
> >> >>> From: Scott Feldman <sfel...@gmail.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 <sfel...@gmail.com>
> >> >>> Signed-off-by: Jiri Pirko <j...@resnulli.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.

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.

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.

Thanks,
-v
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to