Thread (20 messages) 20 messages, 5 authors, 2015-02-25

Re: [PATCH v2 0/3] net: Linn Ethernet Packet Sniffer driver

flat view

From: Richard Cochran <richardcochran@gmail.com>
Date: 2015-02-25 09:51:08
Also in: lkml, netdev

On Mon, Feb 23, 2015 at 09:37:24AM +0000, Stathis Voukelatos wrote:
Hi Richard,

On 18/02/15 21:08, Richard Cochran wrote:
quoted
On Tue, Feb 17, 2015 at 02:03:30PM +0000, Stathis Voukelatos wrote:
quoted
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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help