packet: if hw/sw ts enabled in rx/tx ring, report which ts we got
authorDaniel Borkmann <dborkman@redhat.com>
Tue, 23 Apr 2013 00:39:31 +0000 (00:39 +0000)
committerDavid S. Miller <davem@davemloft.net>
Thu, 25 Apr 2013 05:22:22 +0000 (01:22 -0400)
commitb9c32fb2717094231b31a7d7dcf5fd7f3638ac2f
tree3a50419c26357a99c8af55000ebd1b7fd2bf83f0
parent7276d5d743d775388bf382cd7bdea1a14e486d32
packet: if hw/sw ts enabled in rx/tx ring, report which ts we got

Currently, there is no way to find out which timestamp is reported in
tpacket{,2,3}_hdr's tp_sec, tp_{n,u}sec members. It can be one of
SOF_TIMESTAMPING_SYS_HARDWARE, SOF_TIMESTAMPING_RAW_HARDWARE,
SOF_TIMESTAMPING_SOFTWARE, or a fallback variant late call from the
PF_PACKET code in software.

Therefore, report in the tp_status member of the ring buffer which
timestamp has been reported for RX and TX path. This should not break
anything for the following reasons: i) in RX ring path, the user needs
to test for tp_status & TP_STATUS_USER, and later for other flags as
well such as TP_STATUS_VLAN_VALID et al, so adding other flags will
do no harm; ii) in TX ring path, time stamps with PACKET_TIMESTAMP
socketoption are not available resp. had no effect except that the
application setting this is buggy. Next to TP_STATUS_AVAILABLE, the
user also should check for other flags such as TP_STATUS_WRONG_FORMAT
to reclaim frames to the application. Thus, in case TX ts are turned
off (default case), nothing happens to the application logic, and in
case we want to use this new feature, we now can also check which of
the ts source is reported in the status field as provided in the docs.

Reported-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Acked-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
include/uapi/linux/if_packet.h
net/packet/af_packet.c