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
