aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/networking/timestamping.txt
diff options
context:
space:
mode:
authorOliver Hartkopp <socketcan@hartkopp.net>2010-08-17 04:59:14 -0400
committerDavid S. Miller <davem@davemloft.net>2010-08-19 03:08:30 -0400
commit2244d07bfa2097cb00600da91c715a8aa547917e (patch)
tree44d67d9ffba3697fffeb05c13e88aa76ebc3fd4a /Documentation/networking/timestamping.txt
parent4d5870ec103e6569851b9710f0093f072b08439a (diff)
net: simplify flags for tx timestamping
This patch removes the abstraction introduced by the union skb_shared_tx in the shared skb data. The access of the different union elements at several places led to some confusion about accessing the shared tx_flags e.g. in skb_orphan_try(). http://marc.info/?l=linux-netdev&m=128084897415886&w=2 Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'Documentation/networking/timestamping.txt')
-rw-r--r--Documentation/networking/timestamping.txt22
1 files changed, 13 insertions, 9 deletions
diff --git a/Documentation/networking/timestamping.txt b/Documentation/networking/timestamping.txt
index e8c8f4f06c6..98097d8cb91 100644
--- a/Documentation/networking/timestamping.txt
+++ b/Documentation/networking/timestamping.txt
@@ -172,15 +172,19 @@ struct skb_shared_hwtstamps {
172}; 172};
173 173
174Time stamps for outgoing packets are to be generated as follows: 174Time stamps for outgoing packets are to be generated as follows:
175- In hard_start_xmit(), check if skb_tx(skb)->hardware is set no-zero. 175- In hard_start_xmit(), check if (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP)
176 If yes, then the driver is expected to do hardware time stamping. 176 is set no-zero. If yes, then the driver is expected to do hardware time
177 stamping.
177- If this is possible for the skb and requested, then declare 178- If this is possible for the skb and requested, then declare
178 that the driver is doing the time stamping by setting the field 179 that the driver is doing the time stamping by setting the flag
179 skb_tx(skb)->in_progress non-zero. You might want to keep a pointer 180 SKBTX_IN_PROGRESS in skb_shinfo(skb)->tx_flags , e.g. with
180 to the associated skb for the next step and not free the skb. A driver 181
181 not supporting hardware time stamping doesn't do that. A driver must 182 skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
182 never touch sk_buff::tstamp! It is used to store software generated 183
183 time stamps by the network subsystem. 184 You might want to keep a pointer to the associated skb for the next step
185 and not free the skb. A driver not supporting hardware time stamping doesn't
186 do that. A driver must never touch sk_buff::tstamp! It is used to store
187 software generated time stamps by the network subsystem.
184- As soon as the driver has sent the packet and/or obtained a 188- As soon as the driver has sent the packet and/or obtained a
185 hardware time stamp for it, it passes the time stamp back by 189 hardware time stamp for it, it passes the time stamp back by
186 calling skb_hwtstamp_tx() with the original skb, the raw 190 calling skb_hwtstamp_tx() with the original skb, the raw
@@ -191,6 +195,6 @@ Time stamps for outgoing packets are to be generated as follows:
191 this would occur at a later time in the processing pipeline than other 195 this would occur at a later time in the processing pipeline than other
192 software time stamping and therefore could lead to unexpected deltas 196 software time stamping and therefore could lead to unexpected deltas
193 between time stamps. 197 between time stamps.
194- If the driver did not call set skb_tx(skb)->in_progress, then 198- If the driver did not set the SKBTX_IN_PROGRESS flag (see above), then
195 dev_hard_start_xmit() checks whether software time stamping 199 dev_hard_start_xmit() checks whether software time stamping
196 is wanted as fallback and potentially generates the time stamp. 200 is wanted as fallback and potentially generates the time stamp.