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: Sat, 24 Jan 2015 17:03:51 -0800 Message-ID: <54C440F7.8020209@cumulusnetworks.com> References: <1421987606-10884-3-git-send-email-roopa@cumulusnetworks.com> <20150123104127.GC2065@nanopsycho.orion> <54C26FC1.70605@cumulusnetworks.com> <20150123160636.GM2065@nanopsycho.orion> <54C2CF1A.1080905@cumulusnetworks.com> <54C2D4C9.5000400@cumulusnetworks.com> <20150124112657.GA1879@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-f179.google.com ([209.85.192.179]:34239 "EHLO mail-pd0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751966AbbAYBDy (ORCPT ); Sat, 24 Jan 2015 20:03:54 -0500 Received: by mail-pd0-f179.google.com with SMTP id v10so5047386pde.10 for ; Sat, 24 Jan 2015 17:03:53 -0800 (PST) In-Reply-To: <20150124112657.GA1879@nanopsycho.orion> Sender: netdev-owner@vger.kernel.org List-ID: On 1/24/15, 3:26 AM, Jiri Pirko wrote: > Sat, Jan 24, 2015 at 12:10:01AM CET, roopa@cumulusnetworks.com wrote: >> On 1/23/15, 2:45 PM, roopa wrote: >>> 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. > Well, it is not odd. It is ok I believe. Same as for example: > .ndo_set_mac_address > .ndo_change_mtu > .ndo_vlan_rx_add_vid > .ndo_vlan_rx_kill_vid > .ndo_poll_controller > .ndo_netpoll_setup > .ndo_netpoll_cleanup > > All take care of propagating the ndo to slaves. These mostly operate on netdevs directly. I do have some hesitation, But, I will take your suggestion and add it to the bond and team drivers, > >>> But if you insist, i am going to do just that. >> A side note, I dont see any reason for ndo_bridge_setlink to be renamed to >> ndo_setlink. Because it seems to take the whole netlink msg anyways. It can >> be used to offload other link attributes besides bridging (vxlan and so on). >> Any thoughts on that ?. > Well, it is PF_BRIDGE so I think that the name is accurate. The ndo op does not necessarily have to be tied to the netlink msg family. I don't plan to rename it now. But, in future if i see more value in reusing it for other offloads, i will come back to this. Thanks for the review.