On 28 May 2015 at 17:23, Zoltan Kiss <[email protected]> wrote:

>
>
> On 28/05/15 16:00, Ola Liljedahl wrote:
>
>> I disprove of this solution. TX completion processing (cleaning TX
>> descriptor rings after transmission complete) is an implementation
>> (hardware) aspect and should be hidden from the application.
>>
>
> Unfortunately you can't, if you want your pktio application work with poll
> mode drivers. In that case TX completion interrupt (can be) disabled and
> the application has to control that as well. In case of DPDK you just call
> the send function (with 0 packets, if you don't have anything to send at
> the time)

Why do you have to retire transmitted packet if you are not transmitting
new packets (and need those descriptors in the TX ring)? Does the
application have too few packets in the pool so that reception will suffer?


>
>  There isn't
>
>> any corresponding call that refills the RX descriptor rings with fresh
>> buffers.
>>
> You can do that in the receive function, I think that's how the drivers
> are doing it generally.
>
>>
>> The completion processing can be performed from any ODP call, not
>> necessary odp_pktio_send().
>>
>
> I think "any" is not specific enough. Which one?
>
odp_pktio_recv, odp_schedule. Wherever the application blocks or busy waits
waiting for more packets.



> Can you provide a vague draft how would you fix the l2fwd example below?
>
I don't think anything needs fixing on the application level.


>
>> -- Ola
>>
>>
>> On 28 May 2015 at 16:38, Zoltan Kiss <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>     A pktio interface can be used with poll mode drivers, where TX
>>     completion often
>>     has to be done manually. This turned up as a problem with ODP-DPDK and
>>     odp_l2fwd:
>>
>>     while (!exit_threads) {
>>              pkts = odp_pktio_recv(pktio_src,...);
>>              if (pkts <= 0)
>>                      continue;
>>     ...
>>              if (pkts_ok > 0)
>>                      odp_pktio_send(pktio_dst, pkt_tbl, pkts_ok);
>>     ...
>>     }
>>
>>     In this example we never call odp_pktio_send() on pktio_dst if there
>>     wasn't
>>     any new packets received on pktio_src. DPDK needs manual TX
>>     completion. The
>>     above example should have an odp_pktio_send_completion(pktio_dst)
>>     right at the
>>     beginning of the loop.
>>
>>     Signed-off-by: Zoltan Kiss <[email protected]
>>     <mailto:[email protected]>>
>>
>>     ---
>>       include/odp/api/packet_io.h | 16 ++++++++++++++++
>>       1 file changed, 16 insertions(+)
>>
>>     diff --git a/include/odp/api/packet_io.h b/include/odp/api/packet_io.h
>>     index b97b2b8..3a4054c 100644
>>     --- a/include/odp/api/packet_io.h
>>     +++ b/include/odp/api/packet_io.h
>>     @@ -119,6 +119,22 @@ int odp_pktio_recv(odp_pktio_t pktio,
>>     odp_packet_t pkt_table[], int len);
>>       int odp_pktio_send(odp_pktio_t pktio, odp_packet_t pkt_table[],
>>     int len);
>>
>>       /**
>>     + * Release sent packets
>>     + *
>>     + * This function should be called after sending on a pktio. If the
>>     platform
>>     + * doesn't implement send completion in other ways, this function
>>     should call
>>     + * odp_packet_free() on packets where transmission is already
>>     completed. It can
>>     + * be a no-op if the platform guarantees that the packets will be
>>     released upon
>>     + * completion, but the application must call it periodically after
>>     send to make
>>     + * sure packets are released.
>>     + *
>>     + * @param pktio        ODP packet IO handle
>>     + *
>>     + * @retval <0 on failure
>>     + */
>>     +int odp_pktio_send_complete(odp_pktio_t pktio);
>>     +
>>     +/**
>>        * Set the default input queue to be associated with a pktio handle
>>        *
>>        * @param pktio                ODP packet IO handle
>>     --
>>     1.9.1
>>
>>     _______________________________________________
>>     lng-odp mailing list
>>     [email protected] <mailto:[email protected]>
>>     https://lists.linaro.org/mailman/listinfo/lng-odp
>>
>>
>>
_______________________________________________
lng-odp mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/lng-odp

Reply via email to