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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <93793e84-3438-fbd6-867b-b17755f37613@intel.com>
Date:   Thu, 8 Mar 2018 09:56:32 -0800
From:   Jesus Sanchez-Palencia <jesus.sanchez-palencia@...el.com>
To:     Richard Cochran <richardcochran@...il.com>,
        Eric Dumazet <edumazet@...gle.com>
Cc:     Willem de Bruijn <willemdebruijn.kernel@...il.com>,
        Eric Dumazet <eric.dumazet@...il.com>,
        Network Development <netdev@...r.kernel.org>,
        Jamal Hadi Salim <jhs@...atatu.com>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Jiří Pírko <jiri@...nulli.us>,
        Vinicius Gomes <vinicius.gomes@...el.com>,
        intel-wired-lan@...ts.osuosl.org, anna-maria@...utronix.de,
        Henrik Austad <henrik@...tad.us>,
        Thomas Gleixner <tglx@...utronix.de>,
        John Stultz <john.stultz@...aro.org>,
        Levi Pearson <levi.pearson@...man.com>,
        Willem de Bruijn <willemb@...gle.com>,
        Miroslav Lichvar <mlichvar@...hat.com>
Subject: 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)
> 
> We really do need variable clock IDs.  Otherwise the HW offloading
> case won't work.  The desired transmit time must be expressed in terms
> of the clock inside the MAC.  This clock is not necessarily related to
> the system time at all.
> 
> But in addition to the performance concerns, I think putting this into
> a socket option is the more natural solution.


Ok, so we have it settled for clockid now. Providing it per-socket was what we'd
proposed previously, so this was just an attempt to accommodate all the feedback
we got on the v2 RFC.

What about the tc_drop_if_late bit, though? Would it be acceptable to keep it
per-packet, thus eating the 1-bit hole from skbuff if we would #if guard it
(e.g. with CONFIG_NET_SCH_TBS)?


Thanks,
Jesus