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:	Tue, 26 Aug 2014 10:26:17 -0400
From:	Jamal Hadi Salim <>
To:	Thomas Graf <>
CC:	John Fastabend <>,
	Scott Feldman <>,
	Jiri Pirko <>, netdev <>,
	David Miller <>,
	Neil Horman <>,
	Andy Gospodarek <>,
	dborkman <>, ogerlitz <>,,,,,,,,,,,,,,,,,,,,,,,,
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_PROBES	unused
> 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()

> 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


To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists