netdev - Re: [patch net-next v2 06/10] bridge: introduce fdb offloading via switchdev

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAE4R7bDD1=KLGs44UWz--4Ua=-KpEzDSv08ALhYeAdW_L1AXpw@mail.gmail.com>
Date:	Sun, 9 Nov 2014 23:30:11 -1000
From:	Scott Feldman <sfeldma@...il.com>
To:	Jiri Pirko <jiri@...nulli.us>
Cc:	Jamal Hadi Salim <jhs@...atatu.com>,
	Netdev <netdev@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>, nhorman@...driver.com,
	Andy Gospodarek <andy@...yhouse.net>,
	Thomas Graf <tgraf@...g.ch>, dborkman@...hat.com,
	ogerlitz@...lanox.com, jesse@...ira.com, pshelar@...ira.com,
	azhou@...ira.com, ben@...adent.org.uk, stephen@...workplumber.org,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	vyasevic@...hat.com, Cong Wang <xiyou.wangcong@...il.com>,
	"Fastabend, John R" <john.r.fastabend@...el.com>,
	Eric Dumazet <edumazet@...gle.com>,
	Florian Fainelli <f.fainelli@...il.com>,
	Roopa Prabhu <roopa@...ulusnetworks.com>,
	John Linville <linville@...driver.com>, jasowang@...hat.com,
	ebiederm@...ssion.com, nicolas.dichtel@...nd.com,
	ryazanov.s.a@...il.com, buytenh@...tstofly.org,
	aviadr@...lanox.com, nbd@...nwrt.org,
	Alexei Starovoitov <alexei.starovoitov@...il.com>,
	Neil.Jerram@...aswitch.com, ronye@...lanox.com,
	simon.horman@...ronome.com, alexander.h.duyck@...hat.com,
	"Ronciak, John" <john.ronciak@...el.com>, mleitner@...hat.com,
	Shrijeet Mukherjee <shrijeet@...il.com>,
	Andy Gospodarek <gospo@...ulusnetworks.com>,
	Benjamin LaHaise <bcrl@...ck.org>
Subject: Re: [patch net-next v2 06/10] bridge: introduce fdb offloading via switchdev

On Sun, Nov 9, 2014 at 10:15 PM, Jiri Pirko <jiri@...nulli.us> wrote:
> Mon, Nov 10, 2014 at 04:47:48AM CET, jhs@...atatu.com wrote:
>>On 11/09/14 05:51, Jiri Pirko wrote:
>>>From: Scott Feldman <sfeldma@...il.com>
>>>
>>>Add two new ndos: ndo_sw_port_fdb_add/del to offload static bridge
>>>fdb entries.  Static bridge FDB entries are installed, for example,
>>>using iproute2 bridge cmd:
>>>
>>>        bridge fdb add ADDR dev DEV master vlan VID
>>>
>>>This would install ADDR into the bridge's FDB for port DEV on vlan VID.  The
>>>switch driver implements two ndo_swdev ops to add/delete FDB entries in the
>>>switch device:
>>>
>>>        int ndo_sw_port_fdb_add(struct net_device *dev,
>>>                                const unsigned char *addr,
>>>                                u16 vid);
>>>
>>>        int ndo_sw_port_fdb_del(struct net_device *dev,
>>>                                const unsigned char *addr,
>>>                                u16 vid);
>>>
>>>The driver returns 0 on success, negative error code on failure.
>>>
>>>Note: the switch driver would not implement ndo_fdb_add/del/dump on a port
>>>netdev as these are intended for devices maintaining their own FDB.  In our
>>>case, we want the Linux bridge to own the FBD.
>>>
>>>Note: by default, the bridge does not filter on VLAN and only bridges untagged
>>>traffic.  To enable VLAN support, turn on VLAN filtering:
>>>
>>>       echo 1 >/sys/class/net/<bridge>/bridge/vlan_filtering
>>>
>>
>>Sorry - why is the current fdb_add/del insufficient? It needs a vlanid
>>and the master/self flags should indicate intent to add to h/w vs s/w.
>
> Jamal, I believe we discussed this already. The thing is that current
> fdb_add/del does not need vlanid and master/self flags, because it
> already has that (struct nlattr *tb[]). Here is the whole list of
> parameters to these functions:
>         NDA_DST,
>         NDA_LLADDR,
>         NDA_CACHEINFO,
>         NDA_PROBES,
>         NDA_VLAN,
>         NDA_PORT,
>         NDA_VNI,
>         NDA_IFINDEX,
>         NDA_MASTER,
>
> There are few problems in re-using this. It is netlink based so for calling
> it from bridge code, we would have to construct netlink message. But
> that could be probably changed.
> As you can see from the list of parameters, this is no longer about fdb (addr,
> vlanid) but this has been extended to something else. See vxlan code for
> what this is used for. I believe that fdb_add/del should be renamed to
> something else, perhaps l2neigh_add/del or something like that.
> The other problem is that fdb_add/del is currently used by various
> drivers for different purpose (adding macs to unicast list).
>
> Scott, you may probably want to add something to this.

You hit the main point: having to synthesize netlink msg in the bridge
driver and pass it down to port driver using .ndo_fdb_add/del is
awkward.  And then, if the port driver implements .ndo_fdb_add/del
(and dump), then user could by-pass bridge and install fdbs directly
on port, as if the port maintains its own fdb.  We want the bridge fdb
to be the single fdb, and static fdbs installed by user on bridge to
be pushed down to sw port driver to be installed in hw.


>>
>>cheers,
>>jamal
>>
--
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