netdev - Re: [patch net-next v2 10/10] rocker: implement L2 bridge offloading

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]

Date:	Mon, 10 Nov 2014 09:47:49 -1000
From:	Scott Feldman <sfeldma@...il.com>
To:	Jamal Hadi Salim <jhs@...atatu.com>
Cc:	Roopa Prabhu <roopa@...ulusnetworks.com>,
	Jiri Pirko <jiri@...nulli.us>, 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>,
	John Linville <linville@...driver.com>, jasowang@...hat.com,
	ebiederm@...ssion.com, Nicolas Dichtel <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 <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 10/10] rocker: implement L2 bridge offloading

On Mon, Nov 10, 2014 at 9:27 AM, Jamal Hadi Salim <jhs@...atatu.com> wrote:
> On 11/10/14 13:35, Roopa Prabhu wrote:
>>
>> On 11/10/14, 9:36 AM, Scott Feldman wrote:
>>>
>>> On Mon, Nov 10, 2014 at 6:12 AM, Roopa Prabhu
>>> <roopa@...ulusnetworks.com> wrote:
>>>>
>>>> On 11/10/14, 4:27 AM, Jamal Hadi Salim wrote:
>>>>>
>>>>> On 11/10/14 03:46, Scott Feldman wrote:
>>
>>
>> yes it is, But if i remember correctly, the api (ndo op) could indicate
>> offload to hw (or nic in this case)
>> by giving 'self'. And in those cases the netdev nic port represents the
>> switch.
>>   (Will be nice to check and confirm this though).
>
>
> No, you are correct. You select to add to the bridge fdb or/and via
> the underlying brport fdb.


For swdev, I don't care for the model where each port has an fdb and
the bridge has an fdb.  The bridge's fdb lookup/learning/fwding is
what we're offloading to HW, so it makes more sense from the driver
and to the user to use one fdb, the bridge's fdb.  So user types
"bridge fdb show" and static fdbs installed on the bridge and learned
fdbs synced from HW are represented.  One table.

I view the existing ndo_fdb_add/del ops useful for devices working
standalone without the bridge driver that have some HW fwding
capabilities and need to manage their own fdb.  For devices under
bridge, let's use the bridge's fdb, at least for swdev.

Does this make sense?  I hate to use a lot of "I"s in my sentences,
but looks like I did exactly that in above, so take this as an
opinion, within the scope of swdev.

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