Re: [tipc-discussion] [net-next 1/1] tipc: reduce risk of wakeup queue starvation

2019-08-26 Thread Jon Maloy
> -Original Message- > From: Tuong Lien Tong > Sent: 26-Aug-19 07:44 > To: Jon Maloy ; 'Jon Maloy' > > Cc: Mohan Krishna Ghanta Krishnamurthy > ; > parthasarathy.bhuvara...@gmail.com; Tung Quang Nguyen > ; Hoang Huu Le > ; Gordan Mihaljevic > ; ying@windriver.com; tipc- >

Re: [tipc-discussion] [net-next 1/1] tipc: reduce risk of wakeup queue starvation

2019-08-26 Thread Tuong Lien Tong
Hi Jon, Yes, you are right, my previous patch was not complete (sorry, I have not verified it but just wanted to give a general idea...). Actually, we could still preserve the necessary data/header of the original message for building the wakeup message later as needed (look, just the message

Re: [tipc-discussion] [net-next 1/1] tipc: reduce risk of wakeup queue starvation

2019-08-24 Thread Jon Maloy
Hi Tuong, While experimenting with byte-oriented flow control I realized that this is a very real problem that has to be fixed. I first tried your suggestion with putting the congestion test at the end of tipc_link_xmit(), but realized that we need access to the original message header when we

Re: [tipc-discussion] [net-next 1/1] tipc: reduce risk of wakeup queue starvation

2019-08-01 Thread David Miller
From: Jon Maloy Date: Tue, 30 Jul 2019 16:23:18 +0200 > In commit 365ad353c256 ("tipc: reduce risk of user starvation during > link congestion") we allowed senders to add exactly one list of extra > buffers to the link backlog queues during link congestion (aka > "oversubscription"). However,

[tipc-discussion] [net-next 1/1] tipc: reduce risk of wakeup queue starvation

2019-07-30 Thread Jon Maloy
In commit 365ad353c256 ("tipc: reduce risk of user starvation during link congestion") we allowed senders to add exactly one list of extra buffers to the link backlog queues during link congestion (aka "oversubscription"). However, the criteria for when to stop adding wakeup messages to the input