On Thu, Oct 17, 2013 at 9:24 PM, Takayuki Usui <takay...@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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev