All of 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

  reply	other threads:[~2015-02-25  9:51 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-17 14:03 [PATCH v2 0/3] net: Linn Ethernet Packet Sniffer driver Stathis Voukelatos
2015-02-17 14:03 ` Stathis Voukelatos
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:03   ` 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: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-18 13:56                   ` Stathis Voukelatos
2015-02-17 14:03 ` [PATCH v2 2/3] Packet sniffer core framework Stathis Voukelatos
2015-02-17 14:03   ` Stathis Voukelatos
2015-02-18 15:42   ` Daniel Borkmann
2015-02-18 16:44     ` Stathis Voukelatos
2015-02-18 16:44       ` Stathis Voukelatos
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-17 14:03   ` Stathis Voukelatos
2015-02-17 14:03   ` Stathis Voukelatos
2015-02-18 21:08 ` [PATCH v2 0/3] net: Linn Ethernet Packet Sniffer driver Richard Cochran
2015-02-18 21:08   ` Richard Cochran
2015-02-23  9:37   ` Stathis Voukelatos
2015-02-23  9:37     ` Stathis Voukelatos
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 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 \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.