Thu, Oct 13, 2016 at 02:30:19PM CEST, j...@mojatatu.com wrote: >On 16-10-13 08:10 AM, Jiri Pirko wrote: >> Thu, Oct 13, 2016 at 01:49:07PM CEST, j...@mojatatu.com wrote: >> > On 16-10-13 04:48 AM, Jiri Pirko wrote: > >[..] >> > 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 >
