[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAE4R7bBOCgoH0zL6+82jj2qjcP8n3kSo51x+i5SoqkN8Ff1CBQ@mail.gmail.com>
Date: Thu, 4 Dec 2014 22:41:26 -0800
From: Scott Feldman <sfeldma@...il.com>
To: Roopa Prabhu <roopa@...ulusnetworks.com>
Cc: Jiří Pírko <jiri@...nulli.us>,
Jamal Hadi Salim <jhs@...atatu.com>,
Benjamin LaHaise <bcrl@...ck.org>, Thomas Graf <tgraf@...g.ch>,
john fastabend <john.fastabend@...il.com>,
"stephen@...workplumber.org" <stephen@...workplumber.org>,
John Linville <linville@...driver.com>,
"nhorman@...driver.com" <nhorman@...driver.com>,
Nicolas Dichtel <nicolas.dichtel@...nd.com>,
"vyasevic@...hat.com" <vyasevic@...hat.com>,
Florian Fainelli <f.fainelli@...il.com>,
"buytenh@...tstofly.org" <buytenh@...tstofly.org>,
Aviad Raveh <aviadr@...lanox.com>,
Netdev <netdev@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>, shm@...ulusnetworks.com,
Andy Gospodarek <gospo@...ulusnetworks.com>
Subject: Re: [PATCH 2/3] bridge: offload bridge port attributes to switch asic
if feature flag set
On Thu, Dec 4, 2014 at 6:26 PM, <roopa@...ulusnetworks.com> wrote:
> From: Roopa Prabhu <roopa@...ulusnetworks.com>
>
> This allows offloading to switch asic without having the user to set
> any flag. And this is done in the bridge driver to rollback kernel settings
> on hw offload failure if required in the future.
>
> With this, it also makes sure a notification goes out only after the
> attributes are set both in the kernel and hw.
I like this approach as it streamlines the steps for the user in
setting port flags. There is one case for FLOODING where you'll have
to turn off flooding for both, and then turn on flooding in hw. You
don't want flooding turned on on kernel and hw.
> ---
> net/bridge/br_netlink.c | 27 ++++++++++++++++++++++++++-
> 1 file changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
> index 9f5eb55..ce173f0 100644
> --- a/net/bridge/br_netlink.c
> +++ b/net/bridge/br_netlink.c
> @@ -407,9 +407,21 @@ int br_setlink(struct net_device *dev, struct nlmsghdr *nlh)
> afspec, RTM_SETLINK);
> }
>
> + if ((dev->features & NETIF_F_HW_SWITCH_OFFLOAD) &&
> + dev->netdev_ops->ndo_bridge_setlink) {
> + int ret = dev->netdev_ops->ndo_bridge_setlink(dev, nlh);
I think you want to up-level this to net/core/rtnetlink.c because
you're only enabling the feature for one instance of a driver that
implements ndo_bridge_setlink: the bridge driver. If another driver
was MASTER and implemented ndo_bridge_setlink, you'd want same check
to push setting down to SELF port driver.
> + if (ret && ret != -EOPNOTSUPP) {
> + /* XXX Fix this in the future to rollback
> + * kernel settings and return error
> + */
The future is now. Let's fix this now for the rollback case (again up
in rtnetlink.c). So then a general question comes to mind: for these
dual target sets, is it best to try HW first and then SW, or the other
way around? Either way, on failure on second you need to rollback
first. And, on failure, you need to know rollback value for first, so
you have to do a getlink on first before attempting set.
> + br_warn(p->br, "error offloading bridge attributes "
> + "on port %u(%s)\n", (unsigned int) p->port_no,
> + p->dev->name);
> + }
> + }
> +
> if (err == 0)
> br_ifinfo_notify(RTM_NEWLINK, p);
> -
> out:
> return err;
> }
> @@ -433,6 +445,19 @@ int br_dellink(struct net_device *dev, struct nlmsghdr *nlh)
> err = br_afspec((struct net_bridge *)netdev_priv(dev), p,
> afspec, RTM_DELLINK);
>
> + if (dev->features & NETIF_F_HW_SWITCH_OFFLOAD
> + && dev->netdev_ops->ndo_bridge_setlink) {
> + int ret = dev->netdev_ops->ndo_bridge_dellink(dev, nlh);
> + if (ret && ret != -EOPNOTSUPP) {
> + /* XXX Fix this in the future to rollback
> + * kernel settings and return error
> + */
> + br_warn(p->br, "error offloading bridge attributes "
> + "on port %u(%s)\n", (unsigned int) p->port_no,
> + p->dev->name);
> + }
> + }
> +
Same comments as setlink above.
> return err;
> }
> static int br_validate(struct nlattr *tb[], struct nlattr *data[])
> --
> 1.7.10.4
>
--
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