Mike Pattrick via dev <[email protected]> writes: > Add support in the userspace datapath for PATH MTU on tunnel interfaces. > > This feature allows users to configure an MTU on tunnel ports. If set, > when the userspace datapath attempts to encapsulate a packet that > exceeds the tunnels MTU, OVS will generate and send an ICMP > Fragmentation Needed or Packet Too Big message back to the source host. > > If an MTU is not set on the tunnel interface, there is no change in > behaviour. > > Reported-at: https://issues.redhat.com/browse/FDP-256 > Signed-off-by: Mike Pattrick <[email protected]> > ---
Hi Mike, I've been thinking about this from a different perspective. Namely, we are trying to provide feedback about the topology in OVS to the foreign IP stacks, but maybe it would be better to have this implemented in the sdn controller. What I mean is, we would send this details to the controller and it would give a proper exception packet back that we can send along. Especially since the controller may also be aware of the actual shortest link in the chain. This is a bit different than how things can work with the kernel datapath, since the kernel datapath can have access to all the interface and routing details, and it actually does the l3 routing lookup during the ICMP processing to know which neighbor it will need to involve. It wants to use the FIB on a per-packet basis. That said - there is still value in such a RIB/FIB table being present, and having that in conjunction with the sdn-controller may actually be the most robust solution. What I mean is, we may want to implement higher level primitives in the vswitchd that would require having this kind of table anyway. For example, when I was looking at implementing a kind of CT offload, and also when I was doing some socket map work both could benefit from a proper routing lookup. This would allow us to do the kinds of fallbacks that f.e. nft uses when making forwarding decisions after a miss of an offloaded flow. There is some xlate level routing information that we use at xlate time in the router / route_table modules, but that infrastructure is really only meant for use during xlate processing, and I think we can extend it to do some per-packet lookups. We would also need to have a way to insert entries into the table that don't come from the kernel (not just using the ovs/router/add cli) since some of the userspace routing paths may not ever be known. Or perhaps the SDN controller could have a way to program some routing details to the vswitchd (or have an integration with FRR/something else). I hope I'm making sense - there are definitely times I've seen use in involving the router module on a per-packet basis. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
