Re: [patch net-next RFC 0/6] Add support for offloading packet-sampling
From: Jiri Pirko <jiri@resnulli.us>
Date: 2016-10-13 12:11:09
Thu, Oct 13, 2016 at 01:49:07PM CEST, jhs@mojatatu.com wrote:
On 16-10-13 04:48 AM, Jiri Pirko wrote:quoted
Thu, Oct 13, 2016 at 09:29:57AM CEST, roopa@cumulusnetworks.com wrote:quoted
On 10/12/16, 5:41 AM, Jiri Pirko wrote:quoted
From: Jiri Pirko <redacted>[..]quoted
quoted
we spoke with yotam about this at netdev1.2. and also remember speaking about this on our switchdev calls: Today our driver uses NFLOG to log packets to a netlink socket and hsflowd supported by the sflow people (at http://www.sflow.net/) is capable of reading from a nflog socket. NFLOG has the required netlink attribute markers for packet header/data (which we can possibly extend). We could also add nflog like action in tc if needed. sflow agents like hsflowd are capable of sending packets to an external collector with the required sflow header. Instead of re-inventing a new API for sflow, would be better to standardize/unify on existing mechanisms. Also, this patch series requires a new device to be created which can be avoided if we used existing mechanisms like NFLOG.When I was first thinking about re-using NFLOG, it seemed like an abusal. We need to call it from driver directly, which sounds odd. However, since we use sample_packet_pack function to wrap it up, the NFLOG is called from the tc action code, it does not look bad. Yet still, this has nothing in common with netfilter, only using it's log facilities. That is odd.Sorry, had not seen the code until now; helps me get perspective. If you are going to require netfilter just so you can do this - it sounds so wrong (since you already provides a hook for tc offloading into the switch for other functions).
+1
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.
quoted
I think that the IFE ways is way more clear and generic and not-abusing. However you are right the NFLOG way has advantage of existing user component. I'm not sure how to do this :(Can you do NFLOG to user space without requiring netfilter compiled in? One advantage with IFE is it is a wire protocol - so you can have the sflow collector/aggregator sit on a different machine (for small cpu switches makes sense). So modifying the sflow daemon to accept IFE formatted data is an interesting!
Agreed. For me, that looks like the correct way to do this.
cheers, jamal