[ovs-dev] Cloning packets for "action: set field"
ssaurabh at vmware.com
Mon Aug 4 19:25:21 UTC 2014
This is a bug. As you rightfully pointed, we shouldn't modify the original packet but instead copy out the relevant bits before modifying them. Copying the entire data buffer is simpler, but sub-optimal. We should only copy out the headers that are being modified. We already have the infrastructure to do this. I will create an issue to track it.
> -----Original Message-----
> From: dev [mailto:dev-bounces at openvswitch.org] On Behalf Of Samuel
> Sent: Saturday, August 02, 2014 5:03 AM
> To: dev at openvswitch.org
> Subject: [ovs-dev] Cloning packets for "action: set field"
> Hello guys,
> I wanted to ask you: do you have buffer management functionality to
> duplicate a packet?
> I have seen that the function OvsOutputBeforeSetAction CLONES instead of
> duplicating the packet.
> Did you know that, when cloning a packet, both the old and the cloned
> packet reference the same data (buffer)?
> So that setting bytes, say, in the ipv4 header of the cloned NET_BUFFER
> actually modifies the original NET_BUFFER as well?
> Also, we are not allowed to set data in the original packet. We must create a
> clone / duplicate for this.
> For tunneling (i.e. adding headroom) cloning is ok, because the clone writes
> bytes to the "unused" area of the buffer, or allocates a new MDL for the
> headroom (which is removed at Complete).
> The procedure for setting data within the buffer using cloning is a bit more
> You must allocate a new MDL, copy the 'modified' data into its buffer, and
> chain it to the cloned NET_BUFFER (replacing the old MDL). And at Complete,
> you must free your MDL and put the old MDL back.
> A simpler method would be to duplicate the buffer, instead of cloning it.
> Here the architecture of a cloned NET_BUFFER_LIST is presented:
> Samuel Ghinet
> dev mailing list
> dev at openvswitch.org
More information about the dev