From: Willem de Bruijn <willemb@google.com>
Date: Thu, 31 Jul 2014 17:36:16 -0400

An earlier internal version of the patch did not lock the buffers,
but recorded the seqno in skb_shared_info and referenced that in
these cases. The obvious drawback is having to store an u32 in
skb_shinfo. We did just regain 64b with the removal of syststamp,
though. Would this be a reasonable approach?

At the time we were discussing the removal syststamp, the intention
was to use that space for a new value that can be use to match up
timestamps properly with the packets they are for.

Originally you wanted to use skb->mark for this and then we discussed
all of the drawbacks and shortcoming of that.

What happened to those plans?

Also, there might be 4 bytes available in tcp_skb_cb.