On Tue, Apr 19, 2016 at 2:24 PM, Soheil Hassas Yeganeh
wrote:
> On Tue, Apr 19, 2016 at 2:18 PM, Martin KaFai Lau wrote:
>> On Tue, Apr 19, 2016 at 10:35:52AM -0700, Eric Dumazet wrote:
>>> On Tue, Apr 19, 2016 at 10:28 AM, Martin KaFai Lau wrote:
On Tue, Apr 19, 2016 at 2:18 PM, Martin KaFai Lau wrote:
> On Tue, Apr 19, 2016 at 10:35:52AM -0700, Eric Dumazet wrote:
>> On Tue, Apr 19, 2016 at 10:28 AM, Martin KaFai Lau wrote:
>>
>> > A bit off topic, I feel like the SKBTX_ACK_TSTAMP and txstamp_ack are sort
>>
On Tue, Apr 19, 2016 at 10:35:52AM -0700, Eric Dumazet wrote:
> On Tue, Apr 19, 2016 at 10:28 AM, Martin KaFai Lau wrote:
>
> > A bit off topic, I feel like the SKBTX_ACK_TSTAMP and txstamp_ack are sort
> > of redundant but I have not look into the details yet, so not completely
> >
On Tue, Apr 19, 2016 at 1:28 PM, Martin KaFai Lau wrote:
> On Tue, Apr 19, 2016 at 01:32:14AM -0400, Soheil Hassas Yeganeh wrote:
>> > + TCP_SKB_CB(skb)->txstamp_ack =
>> > + !!(shinfo->tx_flags & SKBTX_ACK_TSTAMP);
>>
>> Maybe we can skip a
On Tue, Apr 19, 2016 at 10:28 AM, Martin KaFai Lau wrote:
> A bit off topic, I feel like the SKBTX_ACK_TSTAMP and txstamp_ack are sort
> of redundant but I have not look into the details yet, so not completely
> sure. It wwould be a separate cleanup patch if it is the case.
On Tue, Apr 19, 2016 at 01:32:14AM -0400, Soheil Hassas Yeganeh wrote:
> > + TCP_SKB_CB(skb)->txstamp_ack =
> > + !!(shinfo->tx_flags & SKBTX_ACK_TSTAMP);
>
> Maybe we can skip a conditional jump here (because of !!), by simply
> using the cached bit in
On Mon, Apr 18, 2016 at 6:46 PM, Martin KaFai Lau wrote:
> If two skbs are merged/collapsed during retransmission, the current
> logic does not merge the tx_flags, tskey and txstamp_ack. The end
> result is the SCM_TSTAMP_ACK timestamp could be missing for a
> packet that the