On Thu, Jun 2, 2022 at 8:58 AM Christian MAUDERER < christian.maude...@embedded-brains.de> wrote:
> Am 02.06.22 um 15:49 schrieb Gedare Bloom: > > On Thu, Jun 2, 2022 at 2:28 AM Sebastian Huber > > <sebastian.hu...@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.maude...@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. > How much RAM does this save versus having control over the size of UDP and TCP RX/TX buffers like we had in the legacy stack? I recall being able to control the various buffer sizes saved a LOT of memory on applications I used these parameters on. There we had four configuration values. Any chance this has a hint in FreeBSD now or we can provide the same tuning? rtems_set_udp_buffer_sizes( rtems_bsdnet_config.udp_tx_buf_size, rtems_bsdnet_config.udp_rx_buf_size ); rtems_set_tcp_buffer_sizes( rtems_bsdnet_config.tcp_tx_buf_size, rtems_bsdnet_config.tcp_rx_buf_size ); --joel > > Best regards > > Christian > -- > -------------------------------------------- > embedded brains GmbH > Herr Christian MAUDERER > Dornierstr. 4 > 82178 Puchheim > Germany > email: christian.maude...@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/ > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel