On 16-10-13 04:48 AM, Jiri Pirko wrote:
Thu, Oct 13, 2016 at 09:29:57AM CEST, ro...@cumulusnetworks.com wrote:
On 10/12/16, 5:41 AM, Jiri Pirko wrote:
From: Jiri Pirko <j...@mellanox.com>
[..]
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).
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.
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!
cheers,
jamal
