Performance issue: I/O send failure due to packet loss when IP-stack is flooded with, e.g., ARPs

The firmware PSEISV3.8.0.1 failed the performance test in Plugfest 2023. Analysis turned out that DrvEth_Lwip frame queue is 64 entries for all firmwares.

Some firmwares have 84 frames, some have 42, some have 21, on the technical level.
The usable frame buffer numbers may differ slightly from these technical values (82, 41, 20) according to the HAL documentation.

If the DrvEth_Lwip queue overflows, our "ARP solution" kicks in and discard any ARP packets which is crucial in the performance testing. Now, if the number of usable frame buffers is smaller than the 64 entries, the ARP discard is never executed, leading to frame buffer exhaustion and failure in I/O sending (can't get a buffer).

The solution for this ticket will be to adapt the depth of the DrvEth_Lwip queue according to the available number of frame buffers for each HAL.
The DrvEth_Lwip queue can be considered non-realtime. The remainder is for I/O, second chassis, and other users of the layer 2 framefilter stuff.

The following value were selected (number of queued buffer elements /overall number of usable frame buffers):

• SinglePort higher number of frame buffers HAL (netX51/52/90): 23/41
• SinglePort lower number of frame buffers HAL (netX5/10/50/100/500): 10/20
• DualPort higher number of frame buffers HAL (netX51/52/90): 58/82
• DualPort lower number of frame buffers HAL (netX5/10/50/100/500): 22/40