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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20161013124526.GF1816@nanopsycho.orion>
Date:   Thu, 13 Oct 2016 14:45:26 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     Jamal Hadi Salim <jhs@...atatu.com>
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

Thu, Oct 13, 2016 at 02:30:19PM CEST, jhs@...atatu.com wrote:
>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.

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
>