On Wed, Nov 8, 2017 at 12:29 PM, Eric Dumazet wrote:
> Please do not top post on netdev.
Right - apologies for that.
>
> On Wed, 2017-11-08 at 11:04 -0500, Vitaly Davidovich wrote:
>> So this issue is somehow related to setting SO_RCVBUF *after*
>> connecting the socket (f
(systemtap? bpf?) - any tips on that front would be appreciated.
Thanks again for the help.
On Fri, Nov 3, 2017 at 5:33 PM, Eric Dumazet wrote:
> On Fri, 2017-11-03 at 14:28 -0400, Vitaly Davidovich wrote:
>
>> So Eric, while I still have your interest here (although I know it's
>&g
On Fri, Nov 3, 2017 at 1:58 PM, Eric Dumazet wrote:
> On Fri, 2017-11-03 at 13:23 -0400, Vitaly Davidovich wrote:
>> On Fri, Nov 3, 2017 at 12:05 PM, Eric Dumazet wrote:
>> > On Fri, 2017-11-03 at 11:13 -0400, Vitaly Davidovich wrote:
>> >> Ok, an interesting findi
On Fri, Nov 3, 2017 at 12:05 PM, Eric Dumazet wrote:
> On Fri, 2017-11-03 at 11:13 -0400, Vitaly Davidovich wrote:
>> Ok, an interesting finding. The client was originally running with
>> SO_RCVBUF of 75K (apparently someone decided to set that for some
>> unknown reason).
e from the equation.
Instead, perhaps it's some bad interaction between a low recv buf size
and either some other TCP setting or TSO mechanics (LRO specifically).
Still investigating further.
On Fri, Nov 3, 2017 at 10:02 AM, Vitaly Davidovich wrote:
> On Fri, Nov 3, 2017 at 9:39 AM, Vitaly
On Fri, Nov 3, 2017 at 9:39 AM, Vitaly Davidovich wrote:
> On Fri, Nov 3, 2017 at 9:02 AM, Eric Dumazet wrote:
>> On Fri, 2017-11-03 at 06:00 -0700, Eric Dumazet wrote:
>>> On Fri, 2017-11-03 at 08:41 -0400, Vitaly Davidovich wrote:
>>> > Hi Eric,
>>> >
On Fri, Nov 3, 2017 at 9:02 AM, Eric Dumazet wrote:
> On Fri, 2017-11-03 at 06:00 -0700, Eric Dumazet wrote:
>> On Fri, 2017-11-03 at 08:41 -0400, Vitaly Davidovich wrote:
>> > Hi Eric,
>> >
>> > Ran a few more tests yesterday with packet captures, includi
On Fri, Nov 3, 2017 at 9:00 AM, Eric Dumazet wrote:
> On Fri, 2017-11-03 at 08:41 -0400, Vitaly Davidovich wrote:
>> Hi Eric,
>>
>> Ran a few more tests yesterday with packet captures, including a
>> capture on the client. It turns out that the client stops ack'
se this, I'd
appreciate any tips on where/what to look at.
Thanks
On Wed, Nov 1, 2017 at 7:06 PM, Eric Dumazet wrote:
> On Wed, 2017-11-01 at 22:22 +, Vitaly Davidovich wrote:
>> Eric,
>>
>
>> Yes I agree. However the thing I’m still puzzled about is the client
>&
Hi all,
I'm seeing some puzzling TCP behavior that I'm hoping someone on this
list can shed some light on. Apologies if this isn't the right forum
for this type of question. But here goes anyway :)
I have client and server x86-64 linux machines with the 4.1.35 kernel.
I set up the following tes
subscribe netdev
Sent from my iPhone
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
11 matches
Mail list logo
