netdev - Re: [patch net-next RFC 10/12] openvswitch: add support for datapath hardware offload

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: <53FC9909.7000007@mojatatu.com>
Date:	Tue, 26 Aug 2014 10:26:17 -0400
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	Thomas Graf <tgraf@...g.ch>
CC:	John Fastabend <john.fastabend@...il.com>,
	Scott Feldman <sfeldma@...ulusnetworks.com>,
	Jiri Pirko <jiri@...nulli.us>, netdev <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Neil Horman <nhorman@...driver.com>,
	Andy Gospodarek <andy@...yhouse.net>,
	dborkman <dborkman@...hat.com>, ogerlitz <ogerlitz@...lanox.com>,
	jesse@...ira.com, pshelar@...ira.com, azhou@...ira.com,
	ben@...adent.org.uk, stephen@...workplumber.org,
	jeffrey.t.kirsher@...el.com, vyasevic@...hat.com,
	xiyou.wangcong@...il.com, john.r.fastabend@...el.com,
	edumazet@...gle.com, f.fainelli@...il.com,
	roopa@...ulusnetworks.com, linville@...driver.com,
	dev@...nvswitch.org, 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@...il.com, Neil.Jerram@...aswitch.com,
	ronye@...lanox.com
Subject: Re: [patch net-next RFC 10/12] openvswitch: add support for datapath
 hardware offload

On 08/25/14 18:50, Thomas Graf wrote:
> On 08/25/14 at 12:15pm, Jamal Hadi Salim wrote:
>> On 08/25/14 10:17, Thomas Graf wrote:

>> I dont think we have a problem handling any of this today.
>
> Yes we do. It's restricted to L2 and we can't extend it easily

It is restricted to L2 because it is L2 processing;->
i.e a fixed function that is widely deployed and well understood.
Possible new extensions that are added are still L2
(example I think if you were to add TRILL support, you would
likely need to inherit and extend the bridge then add new TLVs).

> because it is based on NDA_*. The use of Netlink makes in-kernel
> usage a pain.

Ok, I understand what you mean by "in kernel" now.
I believe we have representations that are complete today at L3.
The offloader just feeds on that.
L2 needs some work because we have only been offloading the fdb.

>To me this is the sole reason for not using fdb_add()
> in the first place. It seems absolutely clear though that fdb_add()
> should be removed after the more generic ndo is in place providing
> a superset of what fdb_add() can do today.
>

It is by no means complete as i pointed to in my other email.
We need to worry about bridge ports, vlan filtering, igmp snooping
possibly STP parametrization and other knobs of control (flood control,
learning control etc).

> OK, let me do the convertion for you:
>
> NDA_DST		unused
> NDA_LLADDR	sw_flow_key.eth.dst
> NDA_CACHEINFO	unused
> NDA_PROBES	unused
> NDA_VLAN	sw_flow_key.eth.tci
> NDA_PORT	unused
> NDA_VNI		sw_flow_key.tun_key.tun_id
> NDA_IFINDEX	sw_flow_key.phys.in_port
> NDA_MASTER	unused
>

You are waaaay oversimplifying;->.
You need to worry about the rest of the other knobs that
are relevant when one offloads the bridge (refer above to
some of the things i said are missing from current fdb()
interface).

> Agreed but tc is only one out of many possible existing interfaces
> we have. macvtap (given we want to extend beyond L2), routing,
> OVS, bridge and eventually even things like a team device can and
> should make use of offloads.
>

Sure. I just want my cookies. I want it such that if i use tc filter
and that filter is offloadable and there exist a device capable
of offloading in my system - that it should work.

> Can you share that preso? I was not present.
>

I think it should be posted in the netconf site.
Also refer to my earlier presentation in the online meeting
which you were present at.

> Let me remind you about the name of the structure behind all L3
> forwarding decisions:
>
>          struct flowi4 {
> 		[...]
> 	}
>
> Adding a route means adding a flow.

Come on Thomas;->
It is called "flowi" structure - but it represent a much complex thing
than your definition of "flow".

>Can we please stop the flow bashing?

Let me get out my club and bash it some more ;->
I am going to start a newsgroup called alt.bash.bash.flow
Any postings from stanford will be censored by the banana republic
dictator.

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