On 1 June 2017 at 15:09, Ola Liljedahl <[email protected]> wrote: > > > 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. > Why is this specific to pktio egress queues. This problem exists even with normal/scheduled queues. Issue is due to source queue being 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. > >> >>>> >
