Re: [PATCH net-next 5/6] qed: Allow chance for fast ramrod completions

2016-10-10 Thread David Miller
From: "Mintz, Yuval" Date: Mon, 10 Oct 2016 06:33:05 + > >> > + while (iter_cnt--) { >> > + /* Validate we receive completion update */ >> >    smp_rmb(); >> >    if (comp_done->done == 1) { >> >    if (p_fw_ret) >> >   

Re: [PATCH net-next 5/6] qed: Allow chance for fast ramrod completions

2016-10-09 Thread Mintz, Yuval
> > + while (iter_cnt--) { > > + /* Validate we receive completion update */ > >    smp_rmb(); > >    if (comp_done->done == 1) { > >    if (p_fw_ret) > >    *p_fw_ret = comp_done->fw_return_code; > >  

Re: [PATCH net-next 5/6] qed: Allow chance for fast ramrod completions

2016-10-09 Thread Eric Dumazet
On Sun, 2016-10-09 at 18:25 +0300, Yuval Mintz wrote: > From: Yuval Mintz > > Whenever a ramrod is being sent for some device configuration, > the driver is going to sleep at least 5ms between each iteration > of polling on the completion of the ramrod. > > However, in almost every configuration

[PATCH net-next 5/6] qed: Allow chance for fast ramrod completions

2016-10-09 Thread Yuval Mintz
From: Yuval Mintz Whenever a ramrod is being sent for some device configuration, the driver is going to sleep at least 5ms between each iteration of polling on the completion of the ramrod. However, in almost every configuration scenario the firmware would be able to comply and complete the ramr