> On 31 May 2017, at 23:53, Bill Fischofer <[email protected]> wrote: > > On Wed, May 31, 2017 at 8:12 AM, Elo, Matias (Nokia - FI/Espoo) > <[email protected]> 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?
