[ovs-dev] [PATCH 3/7] datapath: Enable usage of cached flows.

[Jesse Gross]

On Mon, Sep 20, 2010 at 1:20 PM, Ben Pfaff <blp at nicira.com> wrote:
> On Mon, Sep 20, 2010 at 11:13:41AM -0700, Jesse Gross wrote:
>> An upcoming commit will add support for supplying cached flows for
>> packets entering the datapath.  This adds the code in the datapath
>> itself to recognize these cached flows and use them instead of
>> extracting the flow fields and doing a lookup.
>
> This is clever: I expected that we would have to allocate the flow key
> separately or embed it into struct ovs_skb_cb, but it doesn't have to do
> that.  Great.
>
> It looks OK to me.
>
> One corner case I do not see handled is where the cached flow is an IPv4
> fragment and fragment dropping is enabled.  This would only happen if
> the first datapath hit by a packet had fragment dropping disabled and a
> later one had fragment dropping enabled, so it may not be an interesting
> case.

Currently (as of the end of this patch series) nothing that uses
cached flows will ever generate fragments (the only user being the
tunnel encapsulation code).  It doesn't actually matter if the first
hit datapath has fragment dropping disabled because the flow that we
are caching here is that of the encapsulation header (i.e. GRE
header).  It is possible that the outer packet could be fragmented but
in this case we take a slow path that does not use this mechanism.  We
may want to use this optimization in the future in other scenarios
that could generate fragmented packets but I think it is better to
wait until then to add support for it because I'm not sure exactly
what the mechanism would look like.