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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux