Re: Hardware Timestamping Problem

[Guy Harris <guy () alum mit edu>]

On Jun 9, 2016, at 1:19 PM, Guenter Ebermann <guenter.ebermann () googlemail com> wrote:

> > Am 09.06.2016 um 15:47 schrieb Michael Richardson <mcr () sandelman ca>:
> >
> > Guenter Ebermann <guenter.ebermann () googlemail com> wrote:
> > > Hardware timestamping of sending/receiving buffer descriptors is done
> > > by NIC.
> >
> > Receiving I understand.
> >
> > Are you sure that the hardware is going to timestamp sent packets, and then
> > turn around and send the back to the kernel?
>
> Yes, the driver must monitor tx descriptor consumption by hardware anyways.

But that doesn't mean that the packets time stamped by the hardware when transmitted will be delivered to the PF_PACKET 
sockets used by libpcap *with the hardware time stamp as the time stamp*.

In order make that happen, if hardware transmit time stamping is enabled for a PF_PACKET socket:

        dev_queue_xmit_nit() will *NOT* deliver, to that socket, packets queued for transmission;

        when the hardware says "I've transmitted these packets" (and time-stamped them), the driver will take those 
packets and deliver them to all PF_PACKET sockets with hardware transmit time stamping enabled?

If those aren't done, then code processing packets from a PF_PACKET socket will get a mix of packets with software time 
stamps (packets sent by the machine on which that code is running) and hardware time stamps (packets received by that 
machine).

I don't see any obvious code in dev_queue_xmit_nit() to avoid delivering packets to sockets that have requested 
hardware time stamping, so the first of those statements doesn't appear to be true; is the second one true?
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers