Re: [patch net-next RFC 0/6] Add support for offloading packet-sampling
From: Jiri Pirko <jiri@resnulli.us>
Date: 2016-10-13 12:45:30
Thu, Oct 13, 2016 at 02:30:19PM CEST, jhs@mojatatu.com wrote:
On 16-10-13 08:10 AM, Jiri Pirko wrote:quoted
Thu, Oct 13, 2016 at 01:49:07PM CEST, jhs@mojatatu.com wrote:quoted
On 16-10-13 04:48 AM, Jiri Pirko wrote:[..]quoted
quoted
Roopa, did you mean eth1 as the new device or did you mean just in general config requiring a device to be specified or did you mean a new cpu netdev being needed? I couldnt tell from the patch.You just have to have some netdev to use to funnel the IFE headered sample skbs to userspace. A dummy or a tap.I see. So with nflog you get basically a backend using a netlink socket but in your case you will redirect to tuntap for the case of local sflow but some other device for remote? I am assuming using dummy would require a packet socket as means of retrieving the data.
Correct. The idea is that the userspace app would create a tap device, setup the sampling packets to be sent there and recieve them over chardev. Or the remote delivery could be use to push the sampling packet to a remote host.
If you take the structuring of the metadata that nflog uses it should be easy to transpose.
Yes, we do it with IFE, this patchset implements that.
To Roopa's point, however: Would it not make sense to support nflog (in addition?). cheers, jamal