On Mon, Dec 23, 2013 at 12:13 AM, Chris Luke <chr...@flirble.org> wrote:
> Open vSwitch handles the OPFF_NORMAL action by passing packets
> into a simple layer 2 learning switch. This commit adds the option to have
> packets passed back to the kernel as though Open vSwitch never touched
> them. This allows, for instance, bridge member ports to have IP addresses
> and for the host to run routing protocols on those ports.
>
> Extend the datapath on kernels since 2.6.39 to pass it back by
> providing a special output port number ('OVSP_NORMAL') which causes
> the hook to return RX_HANDLER_PASS. Alter ovs-dpctl to be able to parse
> and display these flows.
>
> Add a flag to the userspace bridge so that it is in either OVS mode
> or kernel mode. This flag is inspected when a packet action is
> OPFF_NORMAL and, if true, the datapath is instructed to use the
> port 'OVSP_NORMAL'.
>
> Extend the OVSDB schema to store this flag and extend ovs-vsctl
> to manipulate it:
> ovs-vsctl set-port-normal-mode br0 kernel
> vs.
> ovs-vsctl set-port-normal-mode br0 ovs
Can you give a full example of how you would use this in a hybrid setting?
I have some high level thoughts. Other people will probably have
additional comments.
* This type of concept has come up before and its usually in the
context of allowing an existing daemon like lldpad to be run on an OVS
port. At a minimum, we would need to make sure that whatever we do
here is compatible with that and ideally we would be able to
essentially solve both problems at the same time. If you are planning
on running routing protocol daemons then maybe it is already pretty
similar.
* The OpenFlow "normal" concept already is already pretty overloaded
so I think it would be better if we didn't add more things to it. An
explicit action would probably make it more programmable as well.
* I'm not sure why we would need to remove any actions already
applied to packets when we hit this action. It seems different from
the OpenFlow action model.
* I agree that upcalls shouldn't work with this model - this seems
like it could be issue to making it work seamlessly.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
