On 4/24/2014 8:46 AM, Jiri Pirko wrote:
Thu, Apr 24, 2014 at 04:54:19PM CEST, john.fastab...@gmail.com wrote:
On 04/17/2014 05:15 AM, Jiri Pirko wrote:
Benefit from the possibility to work with flows in switch devices and
use the swdev api to offload flow datapath.
Signed-off-by: Jiri Pirko <j...@resnulli.us>
---
[...]
@@ -840,13 +841,15 @@ static int ovs_flow_cmd_new_or_set(struct sk_buff *skb,
struct genl_info *info)
flow->flow.key = masked_key;
flow->flow.unmasked_key = key;
rcu_assign_pointer(flow->sf_acts, acts);
+ acts = NULL;
/* Put flow in bucket. */
error = ovs_flow_tbl_insert(&dp->table, flow, &mask);
- if (error) {
- acts = NULL;
+ if (error)
goto err_flow_free;
- }
+ error = ovs_hw_flow_insert(dp, flow, flow->sf_acts);
+ if (error)
+ goto err_flow_tbl_remove;
reply = ovs_flow_cmd_build_info(flow, dp, info,
OVS_FLOW_CMD_NEW);
} else {
Hi Jiri,
If I read this correctly it looks like you do a insert into software
flow tables and then an insert into the hardware flow tables. Into
all lowerdevs. Let me know if I got this wrong.
It should be sufficient to use one-port-per-switch to insert this. I
just insert it to all and if 2 ports of the same switch are used the
switch should see that the flow is already there and bail out. This is
rough so far. Needs some polishing.
OK that seems fine.
This might break on some rules (an insert tag for example) and also
underutilize the switch resources by pushing rules into the switch that
we really only need in software tables or maybe only on some set of
ports.
I thought that I would introduce a flag that would say "push this flow
to hw".
Great this would align with how the FDB interface works. I think this
is a good model although I would prefer a bitfield so I can push it
to hardware, or sw, or both.
I think we need to allow applications direct access to the flow table
via netlink so I can write my policy in user space and not require
OVS. If OVS wants to support a mode where it does this automagically
it can support it in userspace and the kernel side does not need to
change.
The idea was to use the existing ovs api for this so it would be smooth
to userspace. For non-ovs usage there is certainly possible to introduce
new iface which would just call same ndos.
If we get a bitfield to push to just hardware and just software then
using the OVS interface is probably ok. We also need someway to expose
capabilities.
Anyways not a bad start. We can clean it up when the hardware support
is ready.
.John
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
