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

The firmware PSEISV5.4.0.3 fails the performance test. 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 (single port with StdMac vs. 2Port Switch).
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 discards any ARP packets. This is crucial for the performance testing. Now, if the number of usable frame buffers is smaller than the 64 entries, the "ARP solution" is never executed, leading to frame buffer exhaustion on the XC level and a failure in I/O sending (can't get a buffer).

The solution for this 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 frame filter stuff.

The following values 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