On 01/06/2017, 21:03, "Bill Fischofer" <[email protected]> wrote:
>On Thu, Jun 1, 2017 at 10:59 AM, Honnappa Nagarahalli ><[email protected]> wrote: >> On 1 June 2017 at 01:26, Elo, Matias (Nokia - FI/Espoo) >> <[email protected]> wrote: >>> >>>> 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? >>> >> 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. > >Today applications have no way of knowing whether packets sent to a >pktout_queue or tm_queue actually make it to the wire or whether they >are vaporized as soon as they hit the wire, so there's no change here. >An RC of 0 simply says that the packet was "accepted" for transmission >and hence the caller no longer owns that packet handle. You need >higher-level protocols to track end-to-end transmission and receipt. >All that ordered queues say is that packets being sent to TX queues >will have those TX calls made in the same order as the source queue >they originated from. > >The only way to track packet disposition today is to (a) create a >reference to the packet you want to transmit, (b) verify that >odp_packet_has_ref(original_pkt) > 0, indicating that an actual >reference was created, (c) transmit that reference, and (d) note when >odp_packet_has_ref(original_pkt) returns to 0. That confirms that the >reference has exited the scope of this ODP instance since a >"successful" transmission will free that reference. Doesn¹t this just confirm that the reference has been freed? But you don¹t know if this was due to the packet actually being transmitted on the wire or if it was dropped before that (which would also free the reference). Back to my original question, how far into the ³machine² can we return (to SW) absolute knowledge of the states of packets? With normal queues (including scheduled queues), a successful enqueue guarantees that the packet (event) was actually enqueued. But pktio egress queues are not normal queues, they are essentially representations of a network interface¹s TX queues but also maintain the order restoration function of events enqueued to a queue when processing an ordered queue. I interpret your comments Bill as even if enqueue to a pktio egress queue is successful (the packet handle is no longer owned by the application), the implementation from that moment on can do whatever it wants with the packets (as long as the packets are eventually freed). Of course some behaviours might not be very useful. What would an application do if some packets were not accepted for transmission? Extra buffering in the application doesn¹t seem meaningful, there is no mechanism to inform the application that it should re-transmit those packets. The knowledge itself could perhaps be useful. > >>>
