[dpdk-dev] l2fwd-event not fully functional with 'dsw'

[dpdk-dev] l2fwd-event not fully functional with 'dsw'

[Liron Himi]

Hi Mattias,

Recently we tried to run the new l2fwd-event examples using the 'dsw' as the evendev.
We noticed that only 4096 packets were sent back to the ethdev.
Only when we changed both 'dequeue_depth' and 'enqueue_depth' to 128 instead of 32, it started to work.

Do you have any objections for modifying  the 'dsw' default configuration to '128'?

Regards,
Liron

Re: [dpdk-dev] l2fwd-event not fully functional with 'dsw'

[Mattias Rönnblom]

On 2019-12-29 20:45, Liron Himi wrote:
>
> Recently we tried to run the new l2fwd-event examples using the ‘dsw’ 
> as the evendev.
>
> We noticed that only 4096 packets were sent back to the ethdev.
>
> Only when we changed both ‘dequeue_depth’ and ‘enqueue_depth’ to 128 
> instead of 32, it started to work.
>
> Do you have any objections for modifying  the ‘dsw’ default 
> configuration to ‘128’?
>
I suspect the problem isn't really the default dsw burst sizes, but 
rather the additional requirements that dsw puts on its user. In 
particular, the requirement that no eventdev ports may be left "unattended".

 From what I can see, l2fwd-event uses the rx ethernet adapter. In case 
there are no ingress packets, the rx ethernet adapter will leave its 
eventdev port unattended, and thus will not work properly with dsw.

If someone wants to explore if this is indeed the problem, they could 
try adding a zero-sized rte_event_dequeue_burst() (being called for 
every service invocation) in the rx adapter code. A dequeue call will 
allow the dsw flow migration machinery to function properly, and will 
also periodically flush buffered events.A zero-sized enqueue operation 
(as suggested by the dsw documentation) would also work, but that would 
have the side-effect of always flushing any buffered events, which might 
be non-optimal from a performance point of view.

The same might also hold true for the l2fwd-event code, but at least the 
burst-variant of the main loop will periodically attend the eventdev 
port (by means of a dequeue and/or enqueue).

The proper way to address this issue would probably be to add a "needs 
maintenance" capability flag, and a pure event device maintenance 
function added to the eventdev API, or something along those lines. 
Another way might be to use a dsw-internal per lcore timer. That would 
instead require the user to call rte_timer_manage(). An additional 
complication for the latter solution is that, even though an eventdev 
port is not thread-safe, it doesn't really have an "owning" lcore, and 
thus it's difficult to figure out on which lcore to install the timer.