[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <4AF8B67E.3030604@ripnet.com>
Date: Mon, 09 Nov 2009 19:40:30 -0500
From: "Marcus D. Leech" <mleech@...net.com>
To: netdev@...r.kernel.org
Subject: Possible bug: SO_TIMESTAMPING 2.6.30+
I've searched both the LKML archives, and the patchsets for kernels
since 2.6.30 to see if
this problem has been observed.
I have an Ethernet driver that supports hardware timestamping, and it
has been working
swimmingly well for several months using the SO_TIMESTAMPING
infrastructure that
Patrick Ohly put in the kernel starting around 2.6.30.
What I've discovered, that really causes me to pull my hair out, is that
packets that are
either AF_INET6 or AF_PACKET, *are not* getting Tx (transmit)
timestamps. Diving into
the driver, I've discovered that the sk_buffs associated with these
packets *dont* have
the appropriate skb_tx state in the skb:
shtx = skb_tx(skb);
if (shtx->hardware)
{
/* Do the timestamping thing */
}
Now the puzzling thing is that the socket that originates these packets
has SO_TIMESTAMPING
turned on, and was created as an AF_INET6 socket, but carries both V4
and V6 traffic. The
V4 traffic skbs have shtx->hardware true appropriately, but the
V6 traffic doesn't. Using
Wireshark, I can clearly see the V6 packets leaving the interface, so
it's not like they're
getting routed somewhere else, and debugging in the driver *clearly*
shows that V4 packets
have shtx->hardware, while the V6 ones (from the SAME SOCKET) do not.
I know that Patrick Ohly has essentially moved on from doing the
SO_TIMESTAMPING stuff, so
who's maintaining it now?
When I look at the V6 udp code, it seems to call the same udp_sendmsg()
function that V4
uses, which appears to support Tx timestamping the way it should.
Any clues anyone?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists