netdev - Re: [PATCH net-next v3 2/5] swdevice: add new api to set and del bridge port attributes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150124112657.GA1879@nanopsycho.orion>
Date:	Sat, 24 Jan 2015 12:26:57 +0100
From:	Jiri Pirko <jiri@...nulli.us>
To:	roopa <roopa@...ulusnetworks.com>
Cc:	sfeldma@...il.com, jhs@...atatu.com, bcrl@...ck.org, tgraf@...g.ch,
	john.fastabend@...il.com, stephen@...workplumber.org,
	vyasevic@...hat.com, ronen.arad@...el.com, netdev@...r.kernel.org,
	davem@...emloft.net, shm@...ulusnetworks.com,
	gospo@...ulusnetworks.com
Subject: Re: [PATCH net-next v3 2/5] swdevice: add new api to set and del
 bridge port attributes

Sat, Jan 24, 2015 at 12:10:01AM CET, roopa@...ulusnetworks.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@...ulusnetworks.com wrote:
>>>>On 1/23/15, 2:41 AM, Jiri Pirko wrote:
>>>>
>>>><snip..>
>>>>>+
>>>>>+/**
>>>>>+ *    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.

>>
>>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.

>
>
>
>
--
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