Re: [patch net-next RFC 0/6] Add support for offloading packet-sampling

On Thu, Oct 13, 2016 at 5:45 AM, Jiri Pirko [off-list ref] wrote:

Thu, Oct 13, 2016 at 02:30:19PM CEST, jhs@mojatatu.com wrote:

quoted

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.

quoted

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.

quoted

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.