On Thu, Mar 10, 2016 at 09:43:18AM -0800, Eric Dumazet wrote:
> On Thu, Mar 10, 2016 at 9:39 AM, Eric Dumazet wrote:
> > On Thu, Mar 10, 2016 at 9:29 AM, Martin KaFai Lau wrote:
> >> Per RFC4898, they count segments sent/received
> >> containing a positive length data segment (that includes
> >>
On Thu, Mar 10, 2016 at 9:39 AM, Eric Dumazet wrote:
> On Thu, Mar 10, 2016 at 9:29 AM, Martin KaFai Lau wrote:
>> Per RFC4898, they count segments sent/received
>> containing a positive length data segment (that includes
>> retransmission segments carrying data). Unlike
>> tcpi_segs_out/in, tcp
On Thu, Mar 10, 2016 at 9:29 AM, Martin KaFai Lau wrote:
> Per RFC4898, they count segments sent/received
> containing a positive length data segment (that includes
> retransmission segments carrying data). Unlike
> tcpi_segs_out/in, tcpi_data_segs_out/in excludes segments
> carrying no data (e.g
On Thu, Mar 10, 2016 at 9:29 AM, Martin KaFai Lau wrote:
> Per RFC4898, they count segments sent/received
> containing a positive length data segment (that includes
> retransmission segments carrying data). Unlike
> tcpi_segs_out/in, tcpi_data_segs_out/in excludes segments
> carrying no data (e.g
Per RFC4898, they count segments sent/received
containing a positive length data segment (that includes
retransmission segments carrying data). Unlike
tcpi_segs_out/in, tcpi_data_segs_out/in excludes segments
carrying no data (e.g. pure ack).
The patch also updates the segs_in in tcp_fastopen_add
