On Sat, Oct 10, 2015 at 12:04 AM, Jiri Pirko <j...@resnulli.us> 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.
I like it also, but there is some awkwardness in calling switchdev_port_attr_set() with the first argument being the bridge netdev, not a port netdev. But, the basic algorithm to recurse from _this_ netdev down to its lower netdevs works great in this case; it's just the name "switchdev_port_attr_set" implies a port netdev for top-level netdev. So I was thinking about adding another call, something like "switchdev_master_attr_set", which basically just does the same thing as switchdev_port_attr_set, except maybe skips the check to call the ops->switchdev_port_attr_add on the top-level netdev. But now I don't like that idea so much as "master" would be confusing when your passing a bond netdev (which is also a master), but the bond _is_ the port netdev this time, a port on the bridge. So let's scrap v4 and go with v3. I think I can live with this naming awkwardness, given that we got something for essentially free by using switchdev_port_attr_set() in a new way. Davem, I think we're OK going with v3. (There is a follow-on discussion about a switch device, which we'll continue but it shouldn't block this v3 version). -- 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
