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

[Stathis Voukelatos <stathis.voukelatos@linn.co.uk>]

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 
points.
>
> Thanks,
> Richard
>

Thanks,
Stathis