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, devicetree@vger.kernel.org,
netdev@vger.kernel.org, abrestic@chromium.org
Subject: Re: [PATCH v2 0/3] net: Linn Ethernet Packet Sniffer driver
Date: Wed, 25 Feb 2015 10:50:56 +0100 [thread overview]
Message-ID: <20150225095056.GB4293@localhost.localdomain> (raw)
In-Reply-To: <54EAF4D4.4090505@linn.co.uk>
On Mon, Feb 23, 2015 at 09:37:24AM +0000, Stathis Voukelatos wrote:
> Hi Richard,
>
> On 18/02/15 21:08, Richard Cochran wrote:
> >On Tue, Feb 17, 2015 at 02:03:30PM +0000, Stathis Voukelatos wrote:
> >>The command string for packet matching is stored in module RAM
> >>and consists of a sequence of 16-bit entries. Each entry includes
> >>an 8-bit command code and and 8-bit data value. Valid command
> >>codes are:
> >>0 - Don't care
> >>1 - Match: packet data must match command string byte
> >>2 - Copy: packet data will be copied to FIFO
> >>3 - Match/Stamp: if packet data matches string byte, a timestamp
> >> is copied into the FIFO
> >>4 - Copy/Done: packet data will be copied into the FIFO.
> >> This command terminates the command string.
> >
> >Why do you need to expose this interface to user space at all? Why
> >not just time stamp every frame?
>
> To put this into context with an example, the use case this H/W
> module was originally developed for was to allow multiple audio
> receivers to synchronize with a single transmitter, eg. multi-room
> synchronised audio.
The Linux kernel already fully supports this kind of application via
the SIOCSHWTSTAMP, SO_TIMESTAMPING, and PHC mechanisms. We certainly
don't need another another interface just for someone's warped
hardware design.
I suggest that you find a way to make your HW work within the existing
frame work.
> The interface needs to be public so that a user-space application
> can program a command string that will match packets that belong to
> the audio stream of interest, for this example.
Let the user program simply use a BPF for that.
> In addition returning just a timestamp would not be enough in many
> cases. In the audio streaming use case mentioned above some
> additional
> bytes from the packet payload need to be returned (with Copy
> commands) in order to associate the timestamp with a certain point
> in the audio stream.
The time stamp is *already* associated with a particular frame.
Just tell your driver to program the hardware to:
1. time stamp every frame
2. deliver every frame
Thats all you need.
> >How does the "Match" command work? The frame must have one particular
> >byte? That can't be right. Please explain.
>
> Actually, that is how the H/W works. Each Match command is followed by
> a data value which must match the packet data byte at the corresponding
> location. If there is no match processing of the packet stops.
And just what is the "corresponding location"?
Thanks,
Richard
next prev parent reply other threads:[~2015-02-25 9:51 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-17 14:03 Stathis Voukelatos
2015-02-17 14:03 ` [PATCH v2 1/3] Ethernet packet sniffer: Device tree binding and vendor prefix Stathis Voukelatos
2015-02-17 14:16 ` Sergei Shtylyov
2015-02-17 14:51 ` Mark Rutland
2015-02-17 16:22 ` Stathis Voukelatos
2015-02-17 16:35 ` Mark Rutland
2015-02-17 17:13 ` Stathis Voukelatos
2015-02-17 17:30 ` Mark Rutland
2015-02-18 9:40 ` Stathis Voukelatos
2015-02-18 12:11 ` Mark Rutland
2015-02-18 13:56 ` Stathis Voukelatos
2015-02-17 14:03 ` [PATCH v2 2/3] Packet sniffer core framework Stathis Voukelatos
2015-02-18 15:42 ` Daniel Borkmann
2015-02-18 16:44 ` Stathis Voukelatos
2015-02-17 14:03 ` [PATCH v2 3/3] Linn Ethernet packet sniffer driver Stathis Voukelatos
2015-02-18 21:08 ` [PATCH v2 0/3] net: Linn Ethernet Packet Sniffer driver Richard Cochran
2015-02-23 9:37 ` Stathis Voukelatos
2015-02-25 9:50 ` Richard Cochran [this message]
2015-02-25 10:53 ` Stathis Voukelatos
2015-02-25 14:21 ` 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=20150225095056.GB4293@localhost.localdomain \
--to=richardcochran@gmail.com \
--cc=abrestic@chromium.org \
--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 v2 0/3] net: 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).