[ovs-dev] [PATCH v5] tunneling: Avoid recirculation on datapath by computing the recirculate actions at translate time.

[Joe Stringer]

On 26 May 2017 at 07:00, Zoltán Balogh <zoltan.balogh at ericsson.com> wrote:
>
> Hi Joe,
>
>> Backing up a bit for context, the stats attribution goes roughly like this:
>> * First upcall, handler thread calls through the translate code with a
>> packet. The resubmit_stats are derived from that packet. This goes
>> through xlate_actions().
>> * First dump of flow from revalidator thread fetches the flow and runs
>> the same xlate_actions() with whatever stats it has (may be zero).
>> This time, whenever stats attribution or side effects occur, an
>> xlate_cache entry is generated.
>> * Second and subsequent dumps of flows fetches the flow and shortcuts
>> the xlate_actions() by using the xlate_cache instead - ie a call to
>> xlate_push_stats().
>>
>> So, in the same place where the resubmit_stats is manipulated, you
>> would also need to generate a new XC entry which would manipulate the
>> stats - this would be a 'side-effect'. I'd imagine that prior to the
>> full output translation there would be a XC_TRUNCATE(truncated_size)
>> then afterwards there would be an XC_TRUNCATE_RESET(). Or it could be
>> just XC_SET_SIZE(...) where 0 is reset and non-zero is a truncate
>> size. In the implementation/execution in xlate_push_stats() when
>> performing XC_TRUNCATE you would need to store the original push_stats
>> size somewhere, then calculate a new 'n_bytes' based on the number of
>> packets and existing bytes*. For XC_TRUNCATE_RESET(), it would restore
>> the original push_stats size.
>
>  Thank you for the explanation.
>
>> * Hmm, I'm not sure the calculation will be 100% here. Let's say there
>> were 3 packets hit the flow, 50B, 200B, 300B. If output(max_len=100)
>> was executed, then we don't know how many of the packets were
>> truncated. The maximum number of bytes that could be transmitted is
>> 300, but the actual number was 250. We could divide the n_bytes by
>> n_packets, subtract the max_len and then multiply back up by the
>> number of packets, which works for this case assuming floating point
>> arithmetic but is slightly off if using integer math..
>
> I don't think, that would be the proper way of calculating n_bytes. Let's
> say we have 3 packets with 50B, 200B, 200B and max_len=100. The output
> should be 50 + 100 + 100 = 250B.
> Following the instructions above we will get
> [(50 + 200 + 200) / 3 - 100 ] * 3 = [450 / 3 - 100 ] * 3 = 50 * 3 = 150B
>
> Any other idea how to calculate the truncated size with xlate cache?
> Or maybe I did not understand your calculation.

Nope, you're absolutely right. It occurred to me a little later that
for more complex statistic sets this doesn't work. I suspect you
actually need datapath support for tracking these stats separately.

> There is one more thing to be taken into consideration. By adding a tunnel
> header, the size of packets increases as well. But that's a constant value
> for each packet, easier to calculate with it.

Good point.