<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 2, 2022 at 8:58 AM Christian MAUDERER <<a href="mailto:christian.mauderer@embedded-brains.de">christian.mauderer@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Am 02.06.22 um 15:49 schrieb Gedare Bloom:<br>
> On Thu, Jun 2, 2022 at 2:28 AM Sebastian Huber<br>
> <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>> wrote:<br>
>><br>
>> On 02/06/2022 09:27, Christian MAUDERER wrote:<br>
>>><br>
>>> Am 01.06.22 um 14:46 schrieb Gedare Bloom:<br>
>>>> On Mon, May 23, 2022 at 6:21 AM Christian Mauderer<br>
>>>> <<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>> wrote:<br>
>>>>><br>
>>>>> Typical embedded systems don't have that much memory. Reduce the buffer<br>
>>>>> size to something more sensible for the usual type of application.<br>
>>>>> ---<br>
>>>>> freebsd/sys/dev/ffec/if_ffec.c | 8 ++++++++<br>
>>>>> 1 file changed, 8 insertions(+)<br>
>>>>><br>
>>>>> diff --git a/freebsd/sys/dev/ffec/if_ffec.c<br>
>>>>> b/freebsd/sys/dev/ffec/if_ffec.c<br>
>>>>> index 47c0f770..4c1e147b 100644<br>
>>>>> --- a/freebsd/sys/dev/ffec/if_ffec.c<br>
>>>>> +++ b/freebsd/sys/dev/ffec/if_ffec.c<br>
>>>>> @@ -139,9 +139,17 @@ static struct ofw_compat_data compat_data[] = {<br>
>>>>> /*<br>
>>>>> * Driver data and defines. The descriptor counts must be a power<br>
>>>>> of two.<br>
>>>>> */<br>
>>>>> +#ifndef __rtems__<br>
>>>>> #define RX_DESC_COUNT 512<br>
>>>>> +#else /* __rtems__ */<br>
>>>>> +#define RX_DESC_COUNT 64<br>
>>>>> +#endif /* __rtems__ */<br>
>>>><br>
>>>> Do we need some way to control this parameter? Or, how will this<br>
>>>> appear if it breaks something?<br>
>>><br>
>>> I don't expect that there will be any problems. But I can take a look<br>
>>> how I can make that a parameter.<br>
>><br>
>> Can we please keep this a compile time constant as it is. The 64<br>
>> descriptors should be more than enough.<br>
>><br>
> I don't mind the reduction of the constant, but it would be good to<br>
> predict what behavior might indicate this was exceeded. I guess it<br>
> should be some kind of errno on an allocation request though? So it<br>
> should be fine, but if a user hits this limit, I guess they have<br>
> pretty limited options to overcome it.<br>
<br>
Reducing the limit won't cause errors. It will only means that if you <br>
flood the target with network packets, it will cache less packets and <br>
start dropping them earlier. That means:<br>
<br>
On a short packet burst, some packets will be dropped and (for TCP) some <br>
have to be re-transmitted. So for short bursts it can be a slight <br>
disadvantage.<br>
<br>
On a constant overload situation: It doesn't really make a difference <br>
because the target wouldn't be able to process the packages anyway. It <br>
might even is an advantage because the processor doesn't have to process <br>
packets that are already outdated and maybe re-transmitted.<br></blockquote><div><br></div><div>How much RAM does this save versus having control over the size of</div><div>UDP and TCP RX/TX buffers like we had in the legacy stack? I recall</div><div>being able to control the various buffer sizes saved a LOT of memory</div><div>on applications I used these parameters on.</div><div><br></div><div>There we had four configuration values. Any chance this has a hint</div><div>in FreeBSD now or we can provide the same tuning?</div><div><br></div> rtems_set_udp_buffer_sizes(<br> rtems_bsdnet_config.udp_tx_buf_size,<br> rtems_bsdnet_config.udp_rx_buf_size<br> );<br><br> rtems_set_tcp_buffer_sizes(<br> rtems_bsdnet_config.tcp_tx_buf_size,<br> rtems_bsdnet_config.tcp_rx_buf_size<br> );</div><div class="gmail_quote"><br></div><div class="gmail_quote">--joel<br><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Best regards<br>
<br>
Christian<br>
-- <br>
--------------------------------------------<br>
embedded brains GmbH<br>
Herr Christian MAUDERER<br>
Dornierstr. 4<br>
82178 Puchheim<br>
Germany<br>
email: <a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
phone: +49-89-18 94 741 - 18<br>
fax: +49-89-18 94 741 - 08<br>
<br>
Registergericht: Amtsgericht München<br>
Registernummer: HRB 157899<br>
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler<br>
Unsere Datenschutzerklärung finden Sie hier:<br>
<a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a><br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div>