From mboxrd@z Thu Jan 1 00:00:00 1970 From: roopa Subject: Re: [PATCH net-next v3 2/5] swdevice: add new api to set and del bridge port attributes Date: Fri, 23 Jan 2015 14:45:46 -0800 Message-ID: <54C2CF1A.1080905@cumulusnetworks.com> References: <1421987606-10884-3-git-send-email-roopa@cumulusnetworks.com> <20150123104127.GC2065@nanopsycho.orion> <54C26FC1.70605@cumulusnetworks.com> <20150123160636.GM2065@nanopsycho.orion> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sfeldma@gmail.com, jhs@mojatatu.com, bcrl@kvack.org, tgraf@suug.ch, john.fastabend@gmail.com, stephen@networkplumber.org, vyasevic@redhat.com, ronen.arad@intel.com, netdev@vger.kernel.org, davem@davemloft.net, shm@cumulusnetworks.com, gospo@cumulusnetworks.com To: Jiri Pirko Return-path: Received: from mail-pd0-f170.google.com ([209.85.192.170]:59257 "EHLO mail-pd0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752718AbbAWWpr (ORCPT ); Fri, 23 Jan 2015 17:45:47 -0500 Received: by mail-pd0-f170.google.com with SMTP id p10so197867pdj.1 for ; Fri, 23 Jan 2015 14:45:47 -0800 (PST) In-Reply-To: <20150123160636.GM2065@nanopsycho.orion> Sender: netdev-owner@vger.kernel.org List-ID: On 1/23/15, 8:06 AM, Jiri Pirko wrote: > Fri, Jan 23, 2015 at 04:58:57PM CET, roopa@cumulusnetworks.com wrote: >> On 1/23/15, 2:41 AM, Jiri Pirko wrote: >> >> >>> + >>> +/** >>> + * netdev_switch_port_bridge_dellink - Notify switch device port of bridge >>> + * attribute delete >>> + * >>> + * @dev: port device >>> + * @nlh: netlink msg with bridge port attributes >>> + * >>> + * Notify switch device port of bridge port attribute delete >>> + */ >>> +int netdev_switch_port_bridge_dellink(struct net_device *dev, >>> + struct nlmsghdr *nlh, u16 flags) >>> +{ >>> + const struct net_device_ops *ops = dev->netdev_ops; >>> + struct net_device *lower_dev; >>> + struct list_head *iter; >>> + int ret = 0, err = 0; >>> + >>> + if (!(dev->features & NETIF_F_HW_NETFUNC_OFFLOAD)) >>> + return err; >>> + >>> + if (ops->ndo_bridge_dellink) { >>> + WARN_ON(!ops->ndo_switch_parent_id_get); >>> + return ops->ndo_bridge_dellink(dev, nlh, flags); >>> + } >>> + >>> + netdev_for_each_lower_dev(dev, lower_dev, iter) { >>> + err = netdev_switch_port_bridge_dellink(lower_dev, nlh, flags); >>> + if (err) >>> + ret = err; >>> + } >>> + >>> + return ret; >>> +} >>> +EXPORT_SYMBOL(netdev_switch_port_bridge_dellink); >>> -- >>> 1.7.10.4 >>> >>> Is there any other place, other than bridge code, this functions are >>> suppored to be called from? >> No other place today. Its usually the master that implements >> ndo_bridge_setlink/dellink. >> >>> If not, which I consider likely, it would >>> make more sense to me to: >>> >>> - move netdev_for_each_lower_dev iterations directly to bridge code >>> - let the masters (bond, team, ..) implement ndo_bridge_*link and do >>> the traversing there (can be in a form of pre-prepared default >>> ndo callback (ndo_dflt_netdev_switch_port_bridge_*link) >> But, i am still not understanding why i would modify bond, team and other >> slaves > Well, that is the usual way to propagate ndo calls. People are used to > this. It is visible right away in bonding/other code that is propagated > some ndo call to slaves. With your code, that is somehow hidden and only > dependent on NETIF_F_HW_NETFUNC_OFFLOAD flag. > > Note that there are only couple of "master drivers" (for this, most likely > only bond and team modifications are needed). > ndo_bridge_setlink today is only implemented by drivers that implement bridging function. So, having the bond and team driver implement it...seems odd. But if you insist, i am going to do just that.