On Wed, May 31, 2017 at 3:53 PM, 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. > > 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.
Forgot to add that odp_tm_queues have the same need. I don't recall if the new ordered queue logic covers them as well. > >> >> -Matias >>
