>-----Original Message----- >From: Roopa Prabhu [mailto:[email protected]] >Sent: Wednesday, October 19, 2016 10:33 AM >To: Yotam Gigi <[email protected]> >Cc: Jamal Hadi Salim <[email protected]>; Jiri Pirko <[email protected]>; >[email protected]; [email protected]; Ido Schimmel ><[email protected]>; Elad Raz <[email protected]>; Nogah Frankel ><[email protected]>; Or Gerlitz <[email protected]>; >[email protected]; [email protected]; >[email protected]; [email protected]; Shrijeet Mukherjee ><[email protected]>; Yotam Gigi <[email protected]> >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.
