LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Richard Cochran <richardcochran@gmail.com>
To: Stathis Voukelatos <stathis.voukelatos@linn.co.uk>
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
devicetree@vger.kernel.org
Subject: Re: [PATCH net-next v4 0/3] Linn Ethernet Packet Sniffer driver
Date: Wed, 25 Feb 2015 16:19:45 +0100 [thread overview]
Message-ID: <20150225151945.GB7703@localhost.localdomain> (raw)
In-Reply-To: <cover.1424796018.git.stathis.voukelatos@linn.co.uk>
On Tue, Feb 24, 2015 at 04:48:08PM +0000, Stathis Voukelatos wrote:
> This patch adds support for the Ethernet Packet Sniffer H/W module
> developed by Linn Products Ltd and found in the IMG Pistachio SoC.
> The module allows Ethernet packets to be parsed, matched against
> a user-defined pattern and timestamped. It sits between a 100M
> Ethernet MAC and PHY and is completely passive with respect to
> Ethernet frames.
First off, please stop calling this device a "sniffer". Real sniffers
are able to deliver whole frames. Real sniffers are most commonly
used to inspect traffic between two or more nodes, but from a third
host.
Instead, this device really is a time stamping unit with a
programmable frame matching engine. So, the approach of this driver
is totally wrong. It runs contrary to how time stamping is handled in
the kernel.
- This driver delivers time stamps "out of band" from a separate
interface. The other kernel drivers deliver time stamps "in band",
using the same socket from the requesting process.
- This driver requires user space to match time stamps with packets.
The other kernel drivers perform the matching automatically.
- This driver requires user space to program a vendor specific
matching engine. The other kernel drivers program their matching
engines automatically.
Let me suggest another approach that stays in line with the existing
frame work. Based on the device's limitations and your own example,
it seems clear that the intended use case is synchronization for AVB
applications using gPTP.
Your time stamping unit is conceptually the same a PHY with hardware
time stamping, and you should treat it as such. This means using the
CONFIG_NETWORK_PHY_TIMESTAMPING kernel option. There is one mainline
PHY driver as an example, dp83640.c.
You will have to hard code command strings in the driver, one for each
of the SIOCSHWTSTAMP filter types that you want to support. I would
recommend supporting just HWTSTAMP_FILTER_PTP_V2_EVENT. You will
probably need different filters for L2, IPv4, and IPv6, with and
without VLAN. For the transmit case, you can limit the match to PTP
events as well. Your filters should at least return the sequenceId
and the messageType back to the driver.
The only (small) difficulty I can see would be how to arrange for your
driver to be called back just like a PHY driver would be. We might
need to adapt or expand the internal PHY timestamping framework within
the kernel, but if you are willing to rework your driver, then I can
help with that part.
Thanks,
Richard
next prev parent reply other threads:[~2015-02-25 15:19 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-24 16:48 Stathis Voukelatos
2015-02-24 16:48 ` [PATCH net-next v4 1/3] Linn Ethernet packet sniffer: device tree binding and vendor prefix Stathis Voukelatos
2015-02-24 16:48 ` [PATCH net-next v4 2/3] Linn packet sniffer core framework Stathis Voukelatos
2015-02-24 16:48 ` [PATCH net-next v4 3/3] Linn Ethernet packet sniffer driver Stathis Voukelatos
2015-02-25 15:19 ` Richard Cochran [this message]
2015-02-25 17:01 ` [PATCH net-next v4 0/3] Linn Ethernet Packet Sniffer driver Richard Cochran
2015-02-25 17:12 ` Stathis Voukelatos
2015-02-25 17:30 ` Richard Cochran
2015-02-27 17:22 ` Stathis Voukelatos
[not found] ` <54F0A4C4.3020407@linn.co.uk>
2015-02-27 18:14 ` Richard Cochran
2015-03-06 13:45 ` Stathis Voukelatos
2015-03-06 15:24 ` Richard Cochran
[not found] ` <54F98660.5070805@linn.co.uk>
2015-03-06 15:22 ` Richard Cochran
2015-03-11 11:20 ` Stathis Voukelatos
2015-03-11 15:03 ` Richard Cochran
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150225151945.GB7703@localhost.localdomain \
--to=richardcochran@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=stathis.voukelatos@linn.co.uk \
--subject='Re: [PATCH net-next v4 0/3] Linn Ethernet Packet Sniffer driver' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).