[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+FuTSe1T4-CtK88rBrm_yymer5iEPR7f8p-+bYHSW_4zMpAUg@mail.gmail.com>
Date: Thu, 31 Jul 2014 17:36:16 -0400
From: Willem de Bruijn <willemb@...gle.com>
To: David Miller <davem@...emloft.net>
Cc: Network Development <netdev@...r.kernel.org>,
Eric Dumazet <eric.dumazet@...il.com>,
Richard Cochran <richardcochran@...il.com>
Subject: Re: [PATCH net-next v4 0/5] net-timestamp: additional sw tstamps and
> I'm mostly fine with this patchset, the only major blocker is the bit
> that changes TCP segmenting behavior when timestamps are enabled. I
> really don't want to see us doing that, because that makes the
> timestamps non-passive.
Good point. It can be avoided with some storage overhead.
The only reason for locking the buffers is to ensure that
the tracked byte is the last byte in the packet. We have to
know the tracked byte at GSO time, to apply the SKBTX_..
flag to the right segment, and at ACK, to identify when the cumulative
ACK exceeds this byte for the first time.
An earlier internal version of the patch did not lock the buffers, but
recorded the seqno in skb_shared_info and referenced that in these
cases. The obvious drawback is having to store an u32 in
skb_shinfo. We did just regain 64b with the removal of syststamp,
though. Would this be a reasonable approach?
> Please work towards a solution to that problem and also fixup the
> minor naming et al. issues I brought up too.
The other issues are clear and easy to fix. Thanks for the review, David.
--
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