On Mon, Dec 10, 2012 at 6:42 PM, Jesse Gross <[email protected]> wrote:
> On Mon, Dec 10, 2012 at 5:16 PM, Rich Lane <[email protected]> > wrote: > > This action allows the controller to change the destination IP of the > > encapsulating packet. It just exposes the existing Linux datapath > > functionality. > > > > Tested by installing a flow with the new action and an output action to > a GRE > > tunnel port. The resulting packet had the correct destination IP. > > > > Signed-off-by: Rich Lane <[email protected]> > > The immediate intention of the new infrastructure in the kernel module > was not actually to support this type of operation, it's primarily > designed to be consumed by userspace (and to futureproof the > interface). As such, I don't think we can just expose it outwards > directly without fleshing out the concept. > > The first and easiest piece is that the userspace/kernel interface > should be completely built out before we start adding pieces on top of > it. In particular, it should support the receive side and also not > encode particular policies into the serialization layer. I sent out a > patch to do this a while back. I couldn't apply it at the time since > other pieces were missing (which have since been filled in) and > haven't had time to update it. Here it is if you want to help get it > in: > http://openvswitch.org/pipermail/dev/2012-September/021548.html > I'm assuming Jarno's ODP patch will be updated and merged. Jarno, please let me know if you don't have time for this and I'd be happy to help. > Another issue is that this doesn't help on the receive side, > particularly because packets are matched to ports with their > associated IP addresses. In general, I'm not sure that current port > configuration makes sense in this context. > I thought the "null_port" change in the kernel datapath already allowed packets from any remote IP to match, if userspace didn't supply OVS_TUNNEL_ATTR_DST_IPV4 when creating the tunnel port. Or do you mean that we should remove OVS_TUNNEL_ATTR_* entirely now? I'd think you'd want to do that last, after all the flow-based tunneling patches are merged. The OVS_TUNNEL_ATTR_SRC_IPV4 configuration or equivalent would still need to exist for flow-based tunneling, right? If there are multiple datapaths and each one has a tunnel port we need some way to choose between them. Finally, the kernel interface was designed with the assumption that it > is operating in the context of an exact match flow, which is why it > contains actual values for things like ToS and TTL. This enables > userspace to flexibly implement different policies like inheritance > but it makes less sense in the context of general OpenFlow flows. > There is a similar difference with how we implement decrement/set IP > TTL: in OpenFlow these are explicit actions but in the kernel > interface they both map to a single 'set' command since userspace can > calculate the right value. I would expect to see a similar difference > in reverse here. > Are you saying we need to move the handling of flags like TNL_F_TOS_INHERIT into commit_set_tunnel_action in userspace?
_______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
