On Thu, Apr 28, 2016 at 11:10 PM, Eric Dumazet wrote:
> Large sendmsg()/write() hold socket lock for the duration of the call,
> unless sk->sk_sndbuf limit is hit. This is bad because incoming packets
> are parked into socket backlog for a long time.
> Critical decisions like fast retransmit might
On 4/28/16 10:05 PM, Eric Dumazet wrote:
On Thu, 2016-04-28 at 21:43 -0700, Alexei Starovoitov wrote:
I don't understand the logic completely, but isn't it
safer to do 'goto wait_for_memory;' here if we happened
to hit this in the middle of the loop?
Well, the wait_for_memory pushes data, an
On Thu, 2016-04-28 at 21:43 -0700, Alexei Starovoitov wrote:
>
> I don't understand the logic completely, but isn't it
> safer to do 'goto wait_for_memory;' here if we happened
> to hit this in the middle of the loop?
Well, the wait_for_memory pushes data, and could early return to user
space wi
On 4/28/16 8:10 PM, Eric Dumazet wrote:
Large sendmsg()/write() hold socket lock for the duration of the call,
unless sk->sk_sndbuf limit is hit. This is bad because incoming packets
are parked into socket backlog for a long time.
Critical decisions like fast retransmit might be delayed.
Receiver
Large sendmsg()/write() hold socket lock for the duration of the call,
unless sk->sk_sndbuf limit is hit. This is bad because incoming packets
are parked into socket backlog for a long time.
Critical decisions like fast retransmit might be delayed.
Receivers have to maintain a big out of order queu
