Pushed, thanks!
I corrected a typo in a comment (“alloed” -> “allowed”), which breaks the next
patch in the series. The resolution is trivial, so I’d rather not send out a
new version if not needed otherwise.
Jarno
On Dec 13, 2013, at 3:59 PM, Ben Pfaff wrote:
> On Fri, Nov 15, 2013 at 03:
On Fri, Nov 15, 2013 at 03:12:18PM -0800, Jarno Rajahalme wrote:
> Allowing the packet to be modified by execution allows less data
> copying for userspace action execution. Some users of the
> dpif_execute already expect that the packet may be modified. This
> patch makes this behavior uniform a
On Thu, Nov 21, 2013 at 02:36:59PM -0800, Jarno Rajahalme wrote:
>
> On Nov 21, 2013, at 1:55 PM, Ben Pfaff wrote:
>
> > On Fri, Nov 15, 2013 at 03:12:18PM -0800, Jarno Rajahalme wrote:
> >> Allowing the packet to be modified by execution allows less data
> >> copying for userspace action execut
On Nov 21, 2013, at 1:55 PM, Ben Pfaff wrote:
> On Fri, Nov 15, 2013 at 03:12:18PM -0800, Jarno Rajahalme wrote:
>> Allowing the packet to be modified by execution allows less data
>> copying for userspace action execution. Some users of the
>> dpif_execute already expect that the packet may be
On Fri, Nov 15, 2013 at 03:12:18PM -0800, Jarno Rajahalme wrote:
> Allowing the packet to be modified by execution allows less data
> copying for userspace action execution. Some users of the
> dpif_execute already expect that the packet may be modified. This
> patch makes this behavior uniform a
Allowing the packet to be modified by execution allows less data
copying for userspace action execution. Some users of the
dpif_execute already expect that the packet may be modified. This
patch makes this behavior uniform and makes the userspace datapath and
the execution helpers modify the pack
