diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/networking/timestamping.txt | 22 |
1 files changed, 13 insertions, 9 deletions
diff --git a/Documentation/networking/timestamping.txt b/Documentation/networking/timestamping.txt index e8c8f4f06c67..98097d8cb910 100644 --- a/Documentation/networking/timestamping.txt +++ b/Documentation/networking/timestamping.txt | |||
| @@ -172,15 +172,19 @@ struct skb_shared_hwtstamps { | |||
| 172 | }; | 172 | }; |
| 173 | 173 | ||
| 174 | Time stamps for outgoing packets are to be generated as follows: | 174 | Time 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. |