On Dec 13, 2012, at 8:22 , ext Rich Lane wrote: > On Mon, Dec 10, 2012 at 6:42 PM, Jesse Gross <je...@nicira.com> wrote: > On Mon, Dec 10, 2012 at 5:16 PM, Rich Lane <rich.l...@bigswitch.com> 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 <rich.l...@bigswitch.com> > > 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.
I'll do that, no problem. > > 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. Aren't we now with a single datapath? Does that make a difference here? > > 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? I think Jesse meant the commit_* functions in odp-util.c when referring to the "serialization layer", if so all policy stuff should be above it. It seems that as part of figuring out the odp port in ofproto-dpif.c:compose_output_action__() we need to check if the odp port is a tunnel port and set the tunnel fields in the context accordingly. That seems like the proper place for tos inheritance processing as well. Jarno
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
