[dpdk-dev] l2fwd-event not fully functional with 'dsw'
Mattias Rönnblom
mattias.ronnblom at ericsson.com
Mon Dec 30 11:51:44 CET 2019
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.
More information about the dev
mailing list