Re: [RFC v3 net-next 08/18] net: SO_TXTIME: Add clockid and drop_if_late params

On Wed, 21 Mar 2018, Richard Cochran wrote: @Intel: I removed intel-wired-lan@ as I have absolutely zero interest in the moderation spam from that list. Can you please either get rid of this moderation nonsense or stop CC'ing that list when posting to lkml/netdev? > On

Re: [RFC v3 net-next 08/18] net: SO_TXTIME: Add clockid and drop_if_late params

On Wed, Mar 21, 2018 at 01:58:51PM +0100, Thomas Gleixner wrote: > Errm. No. There is no way to support fd based clocks or one of the CPU > time/process time based clocks for this. Why not? If the we have HW offloading, then the transmit time had better be expressed in terms of the MAC's

Re: [RFC v3 net-next 08/18] net: SO_TXTIME: Add clockid and drop_if_late params

On Tue, 6 Mar 2018, Richard Cochran wrote: > On Tue, Mar 06, 2018 at 06:53:29PM -0800, Eric Dumazet wrote: > > This is adding 32+1 bits to sk_buff, and possibly holes in this very > > very hot (and already too fat) structure. > > > > Do we really need 32 bits for a clockid_t ? > > Probably we

Re: [RFC v3 net-next 08/18] net: SO_TXTIME: Add clockid and drop_if_late params

Hi, On 03/08/2018 08:44 AM, Richard Cochran wrote: > On Wed, Mar 07, 2018 at 09:47:40AM -0800, Eric Dumazet wrote: >> I would love if skb->tstamp could be either 0 or expressed in >> ktime_get() base all the time. >> >> ( Even if we would have to convert this to other bases when/if needed) > >

Re: [RFC v3 net-next 08/18] net: SO_TXTIME: Add clockid and drop_if_late params

On Wed, Mar 07, 2018 at 09:47:40AM -0800, Eric Dumazet wrote: > I would love if skb->tstamp could be either 0 or expressed in > ktime_get() base all the time. > > ( Even if we would have to convert this to other bases when/if needed) We really do need variable clock IDs. Otherwise the HW

Re: [RFC v3 net-next 08/18] net: SO_TXTIME: Add clockid and drop_if_late params

From: Miroslav Lichvar Date: Thu, 8 Mar 2018 12:37:22 +0100 > Well, I'd not expect it to be a common use case, but a public NTP > server could be sending millions of packets per second in traffic > peaks (typically at *:00:00) over multiple interfaces. That's the problem.

Re: [RFC v3 net-next 08/18] net: SO_TXTIME: Add clockid and drop_if_late params

On Wed, Mar 07, 2018 at 02:45:45PM -0800, Eric Dumazet wrote: > On Wed, 2018-03-07 at 13:52 -0800, Jesus Sanchez-Palencia wrote: > > > Do we really need 32 bits for a clockid_t ? > > > > There is a 2 bytes hole just after tc_index, so a u16 clockid would > > fit > > perfectly without increasing

Re: [RFC v3 net-next 08/18] net: SO_TXTIME: Add clockid and drop_if_late params

From: Eric Dumazet Date: Wed, 07 Mar 2018 14:45:45 -0800 > No, we need to be extra careful. +1

Re: [RFC v3 net-next 08/18] net: SO_TXTIME: Add clockid and drop_if_late params

On Wed, 2018-03-07 at 13:52 -0800, Jesus Sanchez-Palencia wrote: > Hi, ... > I should have mentioned on the commit msg, but the tc_drop_if_late is > actually > filling a 1 bit hole that was already there. > > > > > > Do we really need 32 bits for a clockid_t ? > > There is a 2 bytes hole just

Re: [RFC v3 net-next 08/18] net: SO_TXTIME: Add clockid and drop_if_late params

Hi, On 03/06/2018 06:53 PM, Eric Dumazet wrote: > On Tue, 2018-03-06 at 17:12 -0800, Jesus Sanchez-Palencia wrote: >> Extend SO_TXTIME APIs with new per-packet parameters: a clockid_t and >> a drop_if_late flag. With this commit the API becomes: >> >> > > * diff --git a/include/linux/skbuff.h

Re: [RFC v3 net-next 08/18] net: SO_TXTIME: Add clockid and drop_if_late params

On Wed, Mar 7, 2018 at 9:37 AM, Richard Cochran wrote: > On Wed, Mar 07, 2018 at 09:35:24AM -0800, Richard Cochran wrote: >> The discussion on v2 ended with this per-message idea, in preference >> to the per-socket idea, IIRC. > > (But my own opinion is that per-socket

Re: [RFC v3 net-next 08/18] net: SO_TXTIME: Add clockid and drop_if_late params

On Wed, Mar 07, 2018 at 09:35:24AM -0800, Richard Cochran wrote: > The discussion on v2 ended with this per-message idea, in preference > to the per-socket idea, IIRC. (But my own opinion is that per-socket is good enough...) Thanks, Richard

Re: [RFC v3 net-next 08/18] net: SO_TXTIME: Add clockid and drop_if_late params

On Wed, Mar 07, 2018 at 12:01:19PM -0500, Willem de Bruijn wrote: > The same choices are probably made for all packets on a given > socket. Unless skb->sk gets scrubbed in some transmit paths, > then these be set as sockopt instead of cmsg. The discussion on v2 ended with this per-message idea,

Re: [RFC v3 net-next 08/18] net: SO_TXTIME: Add clockid and drop_if_late params

On Wed, Mar 7, 2018 at 12:24 AM, Richard Cochran wrote: > On Tue, Mar 06, 2018 at 06:53:29PM -0800, Eric Dumazet wrote: >> This is adding 32+1 bits to sk_buff, and possibly holes in this very >> very hot (and already too fat) structure. >> >> Do we really need 32 bits

Re: [RFC v3 net-next 08/18] net: SO_TXTIME: Add clockid and drop_if_late params

On Tue, Mar 06, 2018 at 06:53:29PM -0800, Eric Dumazet wrote: > This is adding 32+1 bits to sk_buff, and possibly holes in this very > very hot (and already too fat) structure. > > Do we really need 32 bits for a clockid_t ? Probably we can live with fewer bits. For clock IDs with a positive

Re: [RFC v3 net-next 08/18] net: SO_TXTIME: Add clockid and drop_if_late params

On Tue, 2018-03-06 at 17:12 -0800, Jesus Sanchez-Palencia wrote: > Extend SO_TXTIME APIs with new per-packet parameters: a clockid_t and > a drop_if_late flag. With this commit the API becomes: > > * diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h * index

[RFC v3 net-next 08/18] net: SO_TXTIME: Add clockid and drop_if_late params

Extend SO_TXTIME APIs with new per-packet parameters: a clockid_t and a drop_if_late flag. With this commit the API becomes: - use SO_TXTIME to enable the feature on a socket; - pass the per-packet arguments through the cmsg header using: * SCM_CLOCKID for the clockid to be used as the txtime