Hi Ben, No significant cost. Since the implementation is simple, let me add it in next version and we can decide to have it or not. William
On Fri, Jun 10, 2016 at 8:01 AM, Ben Pfaff <b...@ovn.org> wrote: > Is there a significant cost to truncating in the userspace datapath, or > does it just "look weird"? > > On Thu, Jun 09, 2016 at 10:20:31PM -0700, William Tu wrote: >> Hi Ben, >> >> Because for sFlow, it doesn't have any benefit to do >> "sample(truncate(n), userspace(...))" in userspace datapath. I tried >> to implement it by truncating the packet at OVS_ACTION_ATTR_USERSPACE >> in dp_execute_cb() but it looks weird. And currently I couldn't think >> of any other use case so I let sFlow translates differently for kernel >> and userspace dp. >> >> Regards, >> William >> >> >> On Thu, Jun 9, 2016 at 8:16 PM, Ben Pfaff <b...@ovn.org> wrote: >> > On Thu, Jun 09, 2016 at 06:06:47PM -0700, William Tu wrote: >> >> > I'm not sure why CHECK_TRUNC_USERSPACE exists, because I think that your >> >> > patch implements the new action in userspace. >> >> >> >> When translating sflow header config, only if it runs kernel datapath, >> >> I will program truncate to sample's actions list, ex: >> >> "sample(trunc(64), userspace(...))". If it runs userspace datapath, >> >> then it falls back to original way "sample(userspace(...))" and let >> >> sflow code cut the packet to 'header' size. >> > >> > Why are the two datapaths treated differently? Software is easier to >> > test if all the cases are similar, when possible. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
