[ovs-dev] RFC: Handle IPv4 fragmentation in kernel

Jesse Gross jesse at nicira.com
Tue Oct 22 17:13:06 UTC 2013


On Thu, Oct 17, 2013 at 9:24 PM, Takayuki Usui <takayuki at midokura.com> wrote:
> Hi All,
>
> I'm working an experimental patch to handle IPv4 fragmentation and
> reassembly in kernel. The goals are (1) flow matching an entire
> datagram, not a single fragment, and (2) Path MTU Discovery across
> an OVS network. I would really appriciate it if you could review it.
>
> https://github.com/takayuki/openvswitch/commits/ipfrag
>
> This series of commits handles IPv4 fragmentation and reassembly
> in kernel, preserving the "maximum fragment size" of all fragments
> belonging to an original datagram across inbound and outbound physical
> vports, so that Path MTU Discovery works properly traversing an OVS
> network.
>
> The patch is divided into seven commits, but they are classified into
> four tasks; (1) reassemble incoming fragments, (2) fragment outgoing
> packets, (3) preserve maximum fragment size with extended flow key and
> (4) generate ICMP (Fragmentation Needed) messages for Path MTU Discovery.
> All those features newly introduced are implemented optional attributes
> on datapath or vport.

In the future, can you please post the patches directly to the mailing
list? It's easier to review that way.

When reading through the code, I had some high level notes:
 - There is no userspace code to configure this.
 - The path MTU discovery code was deleted because it wasn't standards
compliant and this reintroduces it without an explanation of why it is
OK.
 - Much of this code seems to be tuned to a specific use case since it
only supports IPv4 over VLANs.
 - I'm not sure that the configuration interface has the right level
of granularity, particularly for fragmentation. For example, when
implementing a simple L2 switch it's not desirable for the kernel to
automatically fragment a packet.
 - It has its own implementation of IP fragmentation.



More information about the dev mailing list