<[email protected]> writes:
> <[email protected]> writes:
>
>> From: Prasurjya Rohan Saikia <[email protected]>
>>
>> Added an algorithm to backoff the Tx Task when low memory scenario is
>> triggered at firmware. During high data transfer from host, the firmware
>> runs out of VMM memory, which is used to hold the frames from the host.
>> So added flow control to delay the transmit from host side when there is
>> not enough space to accomodate frames in firmware side.
>>
>> Signed-off-by: Prasurjya Rohan Saikia <[email protected]>
>
> [...]
>
>> - } while (ret == WILC_VMM_ENTRY_FULL_RETRY && !wl->close);
>> + if (ret != WILC_VMM_ENTRY_FULL_RETRY)
>> + break;
>> + /* Back off from sending packets for some time.
>> + * schedule_timeout will allow RX task to run and free
>> + * buffers. Setting state to TASK_INTERRUPTIBLE will
>> + * put the thread back to CPU running queue when it's
>> + * signaled even if 'timeout' isn't elapsed. This gives
>> + * faster chance for reserved SK buffers to be freed
>> + */
>> + set_current_state(TASK_INTERRUPTIBLE);
>> + schedule_timeout(msecs_to_jiffies
>> + (TX_BACKOFF_WEIGHT_MS));
>> + } while (!wl->close);
>
> Why not msleep_interruptible()?
>
> Thanks you for your suggestion. However, I decided to proceed with
> schedule_timeout_interruptible() after testing and I will resubmit the patch.
You need to provide more information than that.
Please quote your emails properly and don't send HTML emails, our lists
automaticall drop all HTML mail.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
On 9/8/23 13:48, Kalle Valo wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> <[email protected]> writes:
>
>> <[email protected]> writes:
>>
>>> From: Prasurjya Rohan Saikia <[email protected]>
>>>
>>> Added an algorithm to backoff the Tx Task when low memory scenario is
>>> triggered at firmware. During high data transfer from host, the firmware
>>> runs out of VMM memory, which is used to hold the frames from the host.
>>> So added flow control to delay the transmit from host side when there is
>>> not enough space to accomodate frames in firmware side.
>>>
>>> Signed-off-by: Prasurjya Rohan Saikia <[email protected]>
>>
>> [...]
>>
>>> - } while (ret == WILC_VMM_ENTRY_FULL_RETRY && !wl->close);
>>> + if (ret != WILC_VMM_ENTRY_FULL_RETRY)
>>> + break;
>>> + /* Back off from sending packets for some time.
>>> + * schedule_timeout will allow RX task to run and free
>>> + * buffers. Setting state to TASK_INTERRUPTIBLE will
>>> + * put the thread back to CPU running queue when it's
>>> + * signaled even if 'timeout' isn't elapsed. This gives
>>> + * faster chance for reserved SK buffers to be freed
>>> + */
>>> + set_current_state(TASK_INTERRUPTIBLE);
>>> + schedule_timeout(msecs_to_jiffies
>>> + (TX_BACKOFF_WEIGHT_MS));
>>> + } while (!wl->close);
>>
>> Why not msleep_interruptible()?
>>
>> Thanks you for your suggestion. However, I decided to proceed with
>> schedule_timeout_interruptible() after testing and I will resubmit the patch.
>
> You need to provide more information than that.
>
> Please quote your emails properly and don't send HTML emails, our lists
> automaticall drop all HTML mail.
Ohh, somehow this configuration was missed out. I have now updated the
email client configuration.
Also, apologies I didn't provide more information earlier. There are no
specific reasons to use schedule_timeout_interruptible(). Since
schedule_timeout_interruptible() wrapped the same functionality,
I don't think there's any issue if we use msleep_interruptible() instead
as it also provides the same functionality.
I have tested with msleep_interrruptible() and its working fine too. So,
I'll be submitting a patch using it.