On Wed, Aug 26, 2015 at 11:30 PM, Jiri Pirko <j...@resnulli.us> wrote:
> Thu, Aug 27, 2015 at 08:23:13AM CEST, sfel...@gmail.com wrote:
>>On Wed, Aug 26, 2015 at 10:43 PM, Jiri Pirko <j...@resnulli.us> wrote:
>>> Wed, Aug 26, 2015 at 07:43:18PM CEST, sfel...@gmail.com wrote:
>>>>On Wed, Aug 26, 2015 at 9:36 AM, Jiri Pirko <j...@resnulli.us> wrote:
>>>>> From: Jiri Pirko <j...@mellanox.com>
>>>>We're going to run out of priv_flags bits. This flag doesn't seem
>>>>like something that will be checked lots of places. How about using
>>>>rtnl_link_ops->kind to save a bit in priv_flags?
>>>>
>>>>static inline bool netif_is_ovs_master(const struct net_device *dev)
>>>>{
>>>> return !strcmp(dev->rtnl_link_ops->kind, "openvswitch"));
>>>>}
>>>
>>> There are lot of helpers like this for other soft-devices. I think that
>>> is okay to have it this way. The thing is that sometimes you need to use
>>> thi helper in fast path and in that case, you do not want to strcmp.
>>>
>>> There is plenty of priv_flags bits for now when I killed the bonding
>>> stuff.
>>
>>Ya, but think about the bit: you (and others) used a bit in priv_flags
>>to indicate the netdev type. Can you add an enum field to
>>rtnl_link_ops->type to indicate link type? Then it's not a strcmp.
>>You can write your helper using strcmp first, and then later migrate
>>to using rtnl_link_ops->type.
>
>
> Also, dev can be multiple things, it can be bridge port and vlan dev at
> the same time. Flags are good for this.
priv_flags bits are three types:
1) dev attribute (IFF_XMIT_DST_RELEASE, IFF_DISABLE_NETPOLL, etc)
2) dev type (IFF_802_1Q_VLAN, IFF_EBRIDGE, etc)
3) and dev membership (IFF_BRIDGE_PORT, IFF_TEAM_PORT, etc)
Are there types 2 or 3 in any fast paths? Type 2 can move to enum;
they're mutually exclusive. Type 3 is the dev's master's type 2, and
since dev can have only one master, no flag is needed: just look up
master type to know if dev is bridged or ovs'ed.
--
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
