Hi Jon,
Iam adding one more patch, where i allow only user sockets to sleep.
The protocol messages should never be in the wakeupq.
"tipc: check for user before making congestion decision"
/Partha
On 12/20/2016 02:21 PM, Jon Maloy wrote:
> Thank you for your thorough testing. This is really the
c-discussion@lists.sourceforge.net;
> Ying Xue
> Subject: Re: [tipc-discussion] [net-next v3 3/3] tipc: reduce risk of user
> starvation
> during link congestion
>
> On 12/20/2016 12:32 PM, Parthasarathy Bhuvaragan wrote:
> > Hi Jon,
> >
> > This patch in the series caused multiple
On 12/20/2016 12:32 PM, Parthasarathy Bhuvaragan wrote:
> Hi Jon,
>
> This patch in the series caused multiple stability issues in my test. I
> spent couple of days to fix all of them in the patches attached.
>
> If you are ok with the fixes, then
> Reviewed-by: Parthasarathy Bhuvaragan
>
>
> /Par
Hi Jon,
This patch in the series caused multiple stability issues in my test. I
spent couple of days to fix all of them in the patches attached.
If you are ok with the fixes, then
Reviewed-by: Parthasarathy Bhuvaragan
/Partha
On 12/12/2016 11:42 PM, Jon Maloy wrote:
The socket code curre
On 12/13/2016 10:08 PM, Jon Maloy wrote:
>> About wakeup skb number, probably we can make it smarter, for example,
>> > its value can be decided by link window size and the size of available
>> > backlog queue or something else. As the value is an important factor for
>> > us, I suggest it's worth
> -Original Message-
> From: Ying Xue [mailto:ying@windriver.com]
> Sent: Tuesday, 13 December, 2016 07:39
> To: Jon Maloy ; tipc-discussion@lists.sourceforge.net;
> Parthasarathy Bhuvaragan
> Cc: ma...@donjonn.com; thompa@gmail.com
> Subject: Re: [net-next v3 3/3] tipc: reduce r
On 12/13/2016 06:42 AM, Jon Maloy wrote:
> void link_prepare_wakeup(struct tipc_link *l)
> {
> - int pnd[TIPC_SYSTEM_IMPORTANCE + 1] = {0,};
> - int imp, lim;
> struct sk_buff *skb, *tmp;
> + int imp, i = 0;
>
> skb_queue_walk_safe(&l->wakeupq, skb, tmp) {
>
The socket code currently handles link congestion by either blocking
and trying to send again when the congestion has abated, or just
returning to the user with -EAGAIN and let him re-try later.
This mechanism is prone to starvation, because the wakeup algorithm is
non-atomic. During the time the
