LKML Archive on
help / color / mirror / Atom feed
From: Stathis Voukelatos <>
To: Richard Cochran <>
Cc: <>, <>,
	<>, <>
Subject: Re: [PATCH v2 0/3] net: Linn Ethernet Packet Sniffer driver
Date: Wed, 25 Feb 2015 10:53:11 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20150225095056.GB4293@localhost.localdomain>

Hi Richard,

On 25/02/15 09:50, Richard Cochran wrote:
> 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 driver already uses that framework for returning timestamps to user 
space. It does not introduce any new interface.

>> 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.

The H/W could not support that:
We have a "Match/Stamp" command, so the packet byte needs to match the 
value following the command, in order for a timestamp to be generated, 
otherwise the packet is dropped.
In addition, due to FIFO size limitations up to 128 bytes (including the 
timestamp) can be returned (through Copy commands) from each packet.

The module was designed to be able to configure it to sniff packets 
belonging to a certain application level stream and from each matching 
packet return a timestamp and some bytes (from eg. the application layer 
protocol header) that would be useful to the application.

BPF could accomplish that too, but timestamps will not be as accurate
without H/W support.

I understand that the device needs to be configured with a proprietary
command stream, but all interfacing with user-space is done using 
existing frameworks (AF_PACKET, SIOCSHWTSTAMP, cmsg)

>> 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"?

The command string is made up of a sequence of <CMD><DATA> pairs. Take 
this for example: {0x00, 0x00, 0x01, 0x55, 0x02, 0x00, 0x04, 0x00}.
First command is Don't Care (0x00), ie 1st byte of Ethernet frame is 
just skipped.
Second command is Match (0x01), ie if the 2nd byte of the Ethernet frame 
is 0x55 processing continues otherwise packet is dropped.
Third command is Copy (0x02), ie 3rd byte of the packet is copied to the 
H/W FIFO to be returned to the user
Fourth command is Copy/Done (0x04), ie 4th packet byte is also copied to 
the FIFO and processing stops.
Then an IRQ is generated, data (2 bytes) are read from the FIFO and
delivered through an AF_PACKET socket.

In v4 of the patch I tried to improve the documentation of some of these 
> Thanks,
> Richard


  reply	other threads:[~2015-02-25 10:53 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
2015-02-25 10:53       ` Stathis Voukelatos [this message]
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \
    --subject='Re: [PATCH v2 0/3] net: Linn Ethernet Packet Sniffer driver' \

* 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).