Hi,
On 02/01/2018 01:27 AM, Miroslav Lichvar wrote: > On Wed, Jan 31, 2018 at 04:49:36PM -0800, Jesus Sanchez-Palencia wrote: >> On 01/18/2018 09:13 AM, Richard Cochran wrote: >>> Right, the clockid_t should be passed in through the CMSG along with >>> the time. >> >> While implementing this today it crossed my mind that why don't we have the >> clockid_t set per socket (e.g. as an argument to SO_TXTIME) instead of per >> packet? > > I suspect that might have an impact on the performance. Even if the > application doesn't use sendmmsg(), it would possibly have to call > setsockopt() before each sendmsg() to change the clockid_t, right? Yes. On the other hand, for applications that will be using only 1 clockid_t, keeping it per packet will also have an impact as we'll be copying the same value from the cmsg cookie into sk_buffs over and over. > > If clockid_t could be set per packet, a special value could be used > to allow sending on interfaces that don't support it. > >> The only use-case that we could think of that would be 'blocked' was using >> sendmmsg() to send a packet to different interfaces with a single syscall, >> but >> I'm not sure how common that is. > > The SO_TXTIME option will make sendmmsg() useful in applications where > it wasn't before. For instance, an NTP server will be able to batch > multiple responses as their transmit timestamps can be set accurately > in advance and it's no longer necessary to send the responses as soon > as they are assembled. > > I think it would be nice the sendmmsg() calls didn't have to be split > by clockid_t. OK, fair enough. I will keep it per-packet for now as initially agreed and we can revisit this later if needed. Thanks, Jesus
