On 1 June 2017 at 01:26, Elo, Matias (Nokia - FI/Espoo)
<matias....@nokia.com> wrote:
>
>> On 31 May 2017, at 23:53, Bill Fischofer <bill.fischo...@linaro.org> wrote:
>>
>> On Wed, May 31, 2017 at 8:12 AM, Elo, Matias (Nokia - FI/Espoo)
>> <matias....@nokia.com> wrote:
>>>
>>>>>> What’s the purpose of calling ord_enq_multi() here? To save (stash)
>>>>>> packets if the thread is out-of-order?
>>>>>> And when the thread is in-order, it is re-enqueueing the packets which
>>>>>> again will invoke pktout_enqueue/pktout_enq_multi but this time
>>>>>> ord_enq_multi() will not save the packets, instead they will actually be
>>>>>> transmitted by odp_pktout_send()?
>>>>>>
>>>>>
>>>>> Since transmitting packets may fail, out-of-order packets cannot be
>>>>> stashed here.
>>>> You mean that the TX queue of the pktio might be full so not all packets
>>>> will actually be enqueued for transmission.
>>>
>>> Yep.
>>>
>>>> This is an interesting case but is it a must to know how many packets are
>>>> actually accepted? Packets can always be dropped without notice, the
>>>> question is from which point this is acceptable. If packets enqueued onto
>>>> a pktout (egress) queue are accepted, this means that they must also be
>>>> put onto the driver TX queue (as done by odp_pktout_send)?
>>>>
>>>
>>> Currently, the packet_io/queue APIs don't say anything about packets being
>>> possibly dropped after successfully calling odp_queue_enq() to a pktout
>>> event queue. So to be consistent with standard odp_queue_enq() operations I
>>> think it is better to return the number of events actually accepted to the
>>> TX queue.
>>>
>>> To have more leeway one option would be to modify the API documentation to
>>> state that packets may still be dropped after a successful odp_queue_enq()
>>> call
>>> before reaching the NIC. If the application would like to be sure that the
>>> packets are actually sent, it should use odp_pktout_send() instead.
>>
>> Ordered queues simply say that packets will be delivered to the next
>> queue in the pipeline in the order they originated from their source
>> queue. What happens after that depends on the attributes of the target
>> queue. If the target queue is an exit point from the application, then
>> this is outside of ODP's scope.
>
> My point was that with stashing the application has no way of knowing if an
> ordered pktout enqueue call actually succeed. In case of parallel and atomic
> queues it does. So my question is, is this acceptable?
>
Also, currently, it is not possible for the application to have a
consistent 'wait/drop on destination queue full' policy for all the
queue types.
>
