[PATCH rtems-libbsd 1/2] if_ffec: Reduce buffer size

[Christian MAUDERER]

Am 02.06.22 um 15:49 schrieb Gedare Bloom:
> On Thu, Jun 2, 2022 at 2:28 AM Sebastian Huber
> <sebastian.huber at embedded-brains.de> wrote:
>>
>> On 02/06/2022 09:27, Christian MAUDERER wrote:
>>>
>>> Am 01.06.22 um 14:46 schrieb Gedare Bloom:
>>>> On Mon, May 23, 2022 at 6:21 AM Christian Mauderer
>>>> <christian.mauderer at embedded-brains.de> wrote:
>>>>>
>>>>> Typical embedded systems don't have that much memory. Reduce the buffer
>>>>> size to something more sensible for the usual type of application.
>>>>> ---
>>>>>    freebsd/sys/dev/ffec/if_ffec.c | 8 ++++++++
>>>>>    1 file changed, 8 insertions(+)
>>>>>
>>>>> diff --git a/freebsd/sys/dev/ffec/if_ffec.c
>>>>> b/freebsd/sys/dev/ffec/if_ffec.c
>>>>> index 47c0f770..4c1e147b 100644
>>>>> --- a/freebsd/sys/dev/ffec/if_ffec.c
>>>>> +++ b/freebsd/sys/dev/ffec/if_ffec.c
>>>>> @@ -139,9 +139,17 @@ static struct ofw_compat_data compat_data[] = {
>>>>>    /*
>>>>>     * Driver data and defines.  The descriptor counts must be a power
>>>>> of two.
>>>>>     */
>>>>> +#ifndef __rtems__
>>>>>    #define        RX_DESC_COUNT   512
>>>>> +#else /* __rtems__ */
>>>>> +#define        RX_DESC_COUNT   64
>>>>> +#endif /* __rtems__ */
>>>>
>>>> Do we need some way to control this parameter? Or, how will this
>>>> appear if it breaks something?
>>>
>>> I don't expect that there will be any problems. But I can take a look
>>> how I can make that a parameter.
>>
>> Can we please keep this a compile time constant as it is.  The 64
>> descriptors should be more than enough.
>>
> I don't mind the reduction of the constant, but it would be good to
> predict what behavior might indicate this was exceeded. I guess it
> should be some kind of errno on an allocation request though? So it
> should be fine, but if a user hits this limit, I guess they have
> pretty limited options to overcome it.

Reducing the limit won't cause errors. It will only means that if you 
flood the target with network packets, it will cache less packets and 
start dropping them earlier. That means:

On a short packet burst, some packets will be dropped and (for TCP) some 
have to be re-transmitted. So for short bursts it can be a slight 
disadvantage.

On a constant overload situation: It doesn't really make a difference 
because the target wouldn't be able to process the packages anyway. It 
might even is an advantage because the processor doesn't have to process 
packets that are already outdated and maybe re-transmitted.

Best regards

Christian
-- 
--------------------------------------------
embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
phone: +49-89-18 94 741 - 18
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/