On Thu, Oct 13, 2016 at 5:45 AM, Jiri Pirko <j...@resnulli.us> wrote: > 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?). >>
[sorry responding to all conversations so far here] using ife for delivery of sampled packets to remote is a good option to have if you have users. so far I have seen agents collecting samples locally and have their own protocol to ship them to a collector (example sflow). Just bringing that up so that we don't optimize for the less common case and make the common case difficult to use :). In my conversations with the sflow people (founders) and others, netlink as a mechanism for sampled packet delivery (similar to ulog/nflog) has proven useful and they see it as a great API to standardize on going forward (Given they are already using netlink for collecting other samples like stats etc). something to thing about. The people I know collecting samples are happy with having netfilter. agreed that tc already has an existing hw offload mechanism. and I was not suggesting giving up on tc either. and also to jiri, agree, I don't think logging from the driver is a good option. I was merely suggesting having a similar option without the need for a new collector device. The three steps in the patch series to collect samples + a device seems a bit heavy weight. but, if you think you have users for it, sure. having multiple api's is also an option. But api's come with a cost of maintaining them for ever.
