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. Ethernet is a lossy protocol, so just because packets are "transmitted" in order doesn't mean that they can't be dropped or reordered by some other node en route to their final destination. This is why TCP has ACK packets to confirm receipt. All that ODP says is that it will do its part to preserve order and will not introduce reorderings itself. So I don't see ODP ordered queue processing needing to treat pktout queues any differently than it would for any other target queue. The original oversight was simply that reorder processing was not being used at all for these targets. > > -Matias >
