summaryrefslogtreecommitdiffstats
path: root/README
diff options
context:
space:
mode:
authorStephen Hemminger <shemminger@linux-foundation.org>2007-09-06 14:55:02 +0200
committerDavid S. Miller <davem@sunset.davemloft.net>2007-10-11 01:48:59 +0200
commit50f17787e9b0222ce65cc831407c3ba4790db3ff (patch)
tree71a1a509cf307105a920d81d9b97b8a2e5ada95b /README
parent[DCCP]: Remove unneeded pointer newdp from dccp_v4_request_recv_sock() (diff)
downloadlinux-50f17787e9b0222ce65cc831407c3ba4790db3ff.tar.xz
linux-50f17787e9b0222ce65cc831407c3ba4790db3ff.zip
[AF_PACKET]: Don't enable global timestamps.
Andi mentioned he did something like this already, but never submitted it. The dhcp client application uses AF_PACKET with a packet filter to receive data. The application doesn't even use timestamps, but because the AF_PACKET API has timestamps, they get turned on globally which causes an expensive time of day lookup for every packet received on any system that uses the standard DHCP client. The fix is to not enable the timestamp (but use if if available). This causes the time lookup to only occur on those packets that are destined for the AF_PACKET socket. The timestamping occurs after packet filtering so all packets dropped by filtering to not cause a clock call. The one downside of this a a few microseconds additional delay added from the normal timestamping location (netif_rx) until the receive callback in AF_PACKET. But since the offset is fairly consistent it should not upset applications that do want really use timestamps, like wireshark. Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'README')
0 files changed, 0 insertions, 0 deletions