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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ