>> 2) new SO_TIMESTAMPING option to receive from the error queue only >> user data as was passed to sendmsg() instead of Ethernet frames >> >> Parsing Ethernet and IP headers (especially IPv6 options) is not >> fun and SOF_TIMESTAMPING_OPT_ID is not always practical, e.g. in >> applications which process messages from the error queue >> asynchronously and don't bind/connect their sockets. > > This would be useful for application writing.
What kind of user data are you suggesting? Just a user-defined ID passed as a cmsg? Allowing such metadata to override skb_shinfo(skb)->tskey sounds fine. >> 3) target address in msg_name of messages from the error queue >> >> With 2) and unconnected sockets, there needs to be a way to get the >> address to which the packet was sent. Is it ok to always fill >> msg_name, or does it need to be a new option? > > > I'm not sure. This would be an argument to just loop the original packet. >> 4) allow sockets to use both SW and HW TX timestamping at the same time >> >> When using a socket which is not bound to a specific interface, it >> would be nice to get transmit SW timestamps when HW timestamps are >> missing. I suspect it's difficult to predict if a HW timestamp will >> be available. Maybe it would be acceptable to get from the error >> queue two messages per transmission if the interface supports both >> SW and HW timestamping? > > > This seems useful, Agreed, as long as it is optional so that it does not change the behavior for existing applications. > but not sure how best to implement it. It might be sufficient to just remove the second line in sw_tx_timestamp static inline void sw_tx_timestamp(struct sk_buff *skb) { if (skb_shinfo(skb)->tx_flags & SKBTX_SW_TSTAMP && !(skb_shinfo(skb)->tx_flags & SKBTX_IN_PROGRESS)) skb_tstamp_tx(skb, NULL); }