[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2cc65dfa-de32-2e31-5f03-80e8f0d2586f@mojatatu.com>
Date: Thu, 13 Oct 2016 08:30:19 -0400
From: Jamal Hadi Salim <jhs@...atatu.com>
To: Jiri Pirko <jiri@...nulli.us>
Cc: Roopa Prabhu <roopa@...ulusnetworks.com>, netdev@...r.kernel.org,
davem@...emloft.net, yotamg@...lanox.com, idosch@...lanox.com,
eladr@...lanox.com, nogahf@...lanox.com, ogerlitz@...lanox.com,
geert+renesas@...der.be, stephen@...workplumber.org,
xiyou.wangcong@...il.com, linux@...ck-us.net
Subject: Re: [patch net-next RFC 0/6] Add support for offloading
packet-sampling
On 16-10-13 08:10 AM, Jiri Pirko wrote:
> Thu, Oct 13, 2016 at 01:49:07PM CEST, jhs@...atatu.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.
If you take the structuring of the metadata that nflog uses it should
be easy to transpose.
To Roopa's point, however: Would it not make sense to support nflog
(in addition?).
cheers,
jamal
Powered by blists - more mailing lists