On 10/18/16, 3:58 AM, Yotam Gigi wrote: > On 16-10-15 12:34 PM, Roopa Prabhu wrote: [snip]
>> The OVS implementation is a good example, the metadata includes all the >> actions applied >>>> to the packet in the kernel data path. >>>> >>> Again not sure what the use case would be (and why waste such space >>> especially when you are sending over the wire with such details). >> All this is being used currently.., But, this can be other api's sflow uses >> for monitoring. >> http://openvswitch.org/support/ovscon2014/17/1400-ovs-sflow.pdf >> >> Does not have to be part of the main/basic sampling api... >> it was just an example. >> > I guess that making the API extensible solves this, isn't it? yes, that might help... Just wanted to bring up the question/clarification on using mark again tc qdisc add dev eth1 handle ffff: ingress tc filter add dev eth1 parent ffff: \ matchall action sample rate 12 mark 17 tc filter add parent ffff: dev eth1 protocol all \ u32 match mark 172 0xff action mirred egress redirect dev dummy0 Like we discussed @ netdev, mark can be used by other things in the system. A request to sample on an interface cannot be disruptive. Does this require mark to be not used elsewhere in the system when sampling is enabled on an interface ?
