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 Wed
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 interna
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 ca
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)
>
> W
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 offload
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.
Bloating up sk_buff fo
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 th
From: Eric Dumazet
Date: Wed, 07 Mar 2018 14:45:45 -0800
> No, we need to be extra careful.
+1
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 a
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 b
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 is good enough...)
>
> Thank
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
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, in
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 for a clockid_t ?
>
> Probabl
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 sig
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 d8340e6e8814..951969ceaf6
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 cl
17 matches
Mail list logo
