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
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
