RE: [patch net-next RFC 4/6] Introduce sample tc action

-----Original Message-----
From: Roopa Prabhu [mailto:roopa@cumulusnetworks.com]
Sent: Wednesday, October 19, 2016 10:33 AM
To: Yotam Gigi <redacted>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>; Jiri Pirko <jiri@resnulli.us>;
netdev@vger.kernel.org; davem@davemloft.net; Ido Schimmel
[off-list ref]; Elad Raz [off-list ref]; Nogah Frankel
[off-list ref]; Or Gerlitz [off-list ref];
geert+renesas@glider.be; stephen@networkplumber.org;
xiyou.wangcong@gmail.com; linux@roeck-us.net; Shrijeet Mukherjee
[off-list ref]; Yotam Gigi [off-list ref]
Subject: Re: [patch net-next RFC 4/6] Introduce sample tc action

On 10/18/16, 3:58 AM, Yotam Gigi wrote:

quoted

On 16-10-15 12:34 PM, Roopa Prabhu wrote:

[snip]

quoted

quoted

The OVS implementation is a good example, the metadata includes all the
actions applied

quoted

quoted

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.