Partial copy data before executing the 'set' action.

[ssp0]

As per - http://openvswitch.org/pipermail/dev/2014-August/043456.html

[Samuel-Ghinet]

So we've got the following situations:

1. An "action: set" must be applied on a NB that contains one MDL.
   The only way not to override the original buffer is to duplicate the NB.
2. Tunneling headers must be prepended to the original packet.
   The first time it works ok. But, if you clone again the original packet, and want to send to a different tunneling port, then:
   2.1. if the original packet had "unused" size (i.e. data offset) = 0 => no problem.
   2.2. if the original packet had unused size > 0, then, when performing a Retreat on the original NB, after the encapsulated clone: the "unused" area of the original first MDL contains bytes of the first encapsulated packet. The first MDL of the original NB must be replaced with a new MDL for the second cloning for the new encapsulation. If the original NB had only one MDL, this means a duplicate.
3. An "action: set" must be applied on a NB that contains more MDLs, and the field to be set is not necessarily in the first MDL.
   A new MDL must be created, for the portion of the packet buffer where the field resides, which would be chained in replace of the old MDL. At Complete, the old MDL would be put back for the original NB.
4. Another "action: set" must be applied on a NB that contains more MDLs, i.e. after an "action: set" was already performed for a clone.
   The MDL original chain may become broken (i.e. would not be restored correctly at Complete), for cases such as: a) new "set" clone sets same fields as was set to the prev clone; b) new "set" clone sets fields in other MDL than was set to the prev clone. A simpler and safer method would be to perform a "duplicate" for the second clone that needs to be performed on it an "action: set"
5. Combination of "action: set"-s for various clones and packet encapsulation for various clones.

Also, given the diversity of possibilities that must be taken into account, and strategies that must be used, I believe it is best to create / use a higher-level NB buffer management module, which would store state and decide on operations, given the situation and evolution of the original packet, while in code where it is used (e.g. Execute Actions part of the code) it would present a simple interface, hiding all these strategical & state details.

[ssp0]

I will work on a fix for this.