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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 10 Nov 2014 10:35:59 -0800
From:	Roopa Prabhu <roopa@...ulusnetworks.com>
To:	Scott Feldman <sfeldma@...il.com>
CC:	Jamal Hadi Salim <jhs@...atatu.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@...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 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:
>>>
>>>> IFLA_BRPORT_LEARNING is u8 attr and we're only using lower bit to turn
>>>> learning on/off.  Maybe we can use another bit to indicate learning to
>>>> be done in sw or hw.  I don't think adding another bit would break
>>>> existing iproute2.
>>>>
>>>> LEARNING_ENABLED    (1 << 0)
>>>> LEARNING_HW              (1 << 1)
>>>>
>>>> Would this work?
>>>>
>>> Yes to making it a bit. But:
>>> This is not *learning*. You are doing a *sync*.
>>> Those are two different things.
>>>
>>> Learning on/off exists today. It signals to the L2 whether you
>>> should learn or not.
>>> I like the way fdb_add/del work with a flag which says
>>> it is the software and/or offloaded version. Please keep that
>>> semantic.
>>> What you are doing above is letting the hardware learn then
>>> syncing to software. You need a different flag there. something
>>> like:
>>>
>>> SYNC_HW_FDB (1<<1)
>>>
>> And in any case, It seems like this policy should be per bridge or per
>> switch chip...or per fdb..
>> entry (like the original fdb_add/del) and not a "port" flag.. ?
> Per-port gives more flexibility, and it looks like we can extend
> existing IFLA_BRPORT_LEARNING without much trouble.
>
> I didn't follow the fdb_add/del comment?  Isn't an fdb entry
> port-specific by nature?  fdb entry = {port, mac, vlan} tuple.
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).
--
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