netdev - Re: [PATCH net-next v4 5/6] net-timestamp: TCP timestamping

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: <20140806.205049.737444744145587077.davem@davemloft.net>
Date:	Wed, 06 Aug 2014 20:50:49 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	willemb@...gle.com
Cc:	eric.dumazet@...il.com, netdev@...r.kernel.org,
	richardcochran@...il.com
Subject: Re: [PATCH net-next v4 5/6] net-timestamp: TCP timestamping

From: Willem de Bruijn <willemb@...gle.com>
Date: Wed, 6 Aug 2014 23:43:11 -0400

> On Wed, Aug 6, 2014 at 10:03 PM, David Miller <davem@...emloft.net> wrote:
>> From: Willem de Bruijn <willemb@...gle.com>
>> Date: Wed, 6 Aug 2014 20:59:30 -0400
>>
>>>>>> but also that we're going to send multiple reports back to error
>>>>>> queue.
>>>>>
>>>>> I see. The optimization patch to queue timestamps without payload will
>>>>> mitigate that somewhat. I dropped that from the initial patchset, but
>>>>> will fix it up for net-next. It may also be possible to squash
>>>>> multiple timestamped packets on the errqueue together when they all
>>>>> have the same payload, resulting in a single (possibly no-payload)
>>>>> packet with repeating cmsgs IP_RECVERR and SCM_TIMESTAMPING. That
>>>>> would give O(1) overhead regardless of number of retransmits.
>>>>
>>>> We could attach a singly linked list of small sequence number cookies
>>>> to the SKB when it gets queued up.
>>>
>>> To avoid queuing a clone of the skb for each timestamp with
>>> sock_queue_err_skb, only queue the first occurrence. Record
>>> subsequent (tstype, tstamp) tuples to the queued skb with
>>> matching tskey, and at ip_recv_error convert each into a cmsg?
>>
>> The retransmit queue only contains the original transmit SKB(s).
>>
>> So the only modification in tcp_clean_rtx_queue() is to walk the
>> list of timestamp sequence number cookies.
> 
> I think I may have misunderstood the design. When are cookies
> added to this list and what exactly do they record? Attach a
> cookie to the SKB on each invocation of skb_tstamp_tx, instead
> of cloning the SKB every time and queuing each clone onto
> the errqueue. Build this list of cookies and flush them at once on
> the final ACK timestamp? If so, then cookies record a timestamp
> and -type, but all refer to the same skb_shinfo(skb)->tskey.

When transmit packets are built in TCP for which we will provide
a timestamp, that is when we will allocate the cookie blob and
link it into the SKB.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html