Re: [dpdk-dev] [PATCH v6 00/10] example/l2fwd-event: introduce l2fwd-event example

[Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>]

<snip>
>>
>> It's not a quantifier of each port, It across the eventdevice that the
>number of
>> event queues is equal to number of ethdevices used.
>>
>> This is to prevent event queues being overcrowded i.e. in case there
>is only one
>> event queue and multiple Eth devices then SW/HW will have a
>bottleneck in
>> enqueueing all the mbufs to a single event queue.
>Yes you are correct, but here is my confusion
>
>1. let us assume there are 2 ports, ie: port 0 <==> port 1.
>2. We have 4 workers and 2 event queue (2 ports, so Q-0 for port-0 and
>Q-11 for port-1)
>3. The event mode (SW or HW) is parallel.
>4. In this case we need to rely of Q-2 which can absorb the events for
>single-event TX adapter for L2FWD_EVENT_TX_ENQ.
>5. But for L2FWD_EVENT_TX_DIRECT (which is to send packets out
>directly) this is not right form as multiple parallel workers may
>concurrently send out same destination port queue (as there is 1 TX
>configured).
>
>Can you help me understand, how this is worked around?

We only select TX_DIRECT when the eventdev coupled with ethdev has 
RTE_EVENT_ETH_TX_ADAPTER_CAP_INTERNAL_PORT capability.
It is the PMDs responsibility to synchronize concurrent Tx queues access
across queues if it exposes the above capability.

In case of octeontx2 we expose RTE_EVENT_ETH_TX_ADAPTER_CAP_INTERNAL_PORT
only when both eventdev and ethdev are octeontx2 pmds. 
Since octeontx2 has DEV_TX_OFFLOAD_MT_LOCKFREE multicore Tx queue atomicity is
taken care by HW.

>
>>
>> >3. With this work for vdev ports, if no are we adding check for the
>> >same in `main` function?
>>
>> I have verified the functionality for --vdev=event_sw0 and it seems to
>work fine.
>Thanks, so whether it is physical or virtual ethernet device all packets
>has to come to worker cores for 'no-mac-updating'.
>
>>
>> >
>> >snipped