>-----Original Message----- >From: Roopa Prabhu [mailto:ro...@cumulusnetworks.com] >Sent: Wednesday, October 19, 2016 10:33 AM >To: Yotam Gigi <yot...@mellanox.com> >Cc: Jamal Hadi Salim <j...@mojatatu.com>; Jiri Pirko <j...@resnulli.us>; >netdev@vger.kernel.org; da...@davemloft.net; Ido Schimmel ><ido...@mellanox.com>; Elad Raz <el...@mellanox.com>; Nogah Frankel ><nog...@mellanox.com>; Or Gerlitz <ogerl...@mellanox.com>; >geert+rene...@glider.be; step...@networkplumber.org; >xiyou.wangc...@gmail.com; li...@roeck-us.net; Shrijeet Mukherjee ><s...@cumulusnetworks.com>; Yotam Gigi <yotam...@gmail.com> >Subject: Re: [patch net-next RFC 4/6] Introduce sample tc action > >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 ?
I think the we can spare the usage of mark, or at least make it optional, as the user can match on the packets according to the eth_type (as part of the IFE, the user can set the sampled packet eth_type). I will do that, and update the documentation as well.
