On Thu, Oct 22, 2015 at 06:06:58PM +0300, Nikita Kalyazin wrote: > Hi, > > > [Alex] ODP queues are neither software nor hardware by definition, each > > implementation is free to implement them as they see fit. Also PacketI/O > > abstraction is not an abstraction for a NIC device. The ODP way to use > > multiple > > queues for ingress is through the classifier. There was a former proposal of > > enabling RSS at pktio level but it was not accepted. I also noticed that > > this > > patch tries to introduce multiple default queues which is kind of confusing > > - > > default traffic is all traffic which does not satisfy classifier criteria. > > For > > output, multiple queues are used by the means of TM api. > As I understand, ODP implies three options of ingress processing: > - "recv" (poll pktio with raw recv() method);
I think we should be deprecating this method, and users of it move over to using polled (or scheduled) queues. There should be no performance penalty and the presence of recv mode just causes confusion. > - "poll" (poll poll pktio via default input queue associated with the pktio); It's also possible to poll an input queue which is associated with a class of service. Although, looking at the validation test and example just now I see that they don't do this and they work exclusively with scheduled queues, this should be changed. > - "sched" (call schedule() which makes use of classifier and queue > priorities). > Looks like each ODP implementation should support all the three options. > > For "sched" option, classification may be implemented in hardware, and ODP > queues, in their turn, can also be implemented in hardware. The hardware > would > distribute packets to its hardware queues according to PMRs or L2/L3 QoS. There's no way to do hash based distribution with the classification API currently, it would need to be extended. The initial design included some APIs for this but they weren't fully formed and didn't make it into the release. There has been some debate since then about whether support should be added as part of the pktio or classification API, but consensus seems to be that the classification API is the right place. The rough idea would be to use the classification API to assign a CoS and then packets matching that CoS are distributed to a number of queues based on a hash of a set of preconfigured fields. At the minute packets can only be delivered to a single queue (assigned using odp_cos_set_queue()) so this would need to be extended. If the hardware is only capable of RSS type distribution then you'd have no PMR or L2/L3 based CoS and everything would be distributed within the default CoS. > For "recv" option, the only way possible to access NIC's hardware queues > (if any), is to call recv() on a specified queue explicitly. So there should > be > an API for it. In my patch I proposed such APIs (odp_pktio_recv_queue()). > I admit, this might be not the best API name possible. However I don't see > any > other way to access NIC's hardware queues at "recv" level. The right way to do this is to expose the hardware queues as ODP queues (odp_queue_t). ODP queues should map directly to hardware queues wherever possible, so calling odp_queue_deq[_multi]() on a packet input queue reads packets directly from the hardware queue. > We can add > hw_queue_id parameter to existing odp_pktio_recv() alternatively (same way as > DPDK does with rte_eth_rx_burst()). No, the queue_id passed to rte_eth_rx_burst() should be seen as being equivalent to an ODP queue. So these APIs are logically equivalent; uint16_t rte_eth_rx_burst(uint8_t port_id, uint16_t queue_id, struct rte_mbuf **rx_pkts, const uint16_t nb_pkts); int odp_queue_deq_multi(odp_queue_t queue, odp_event_t events[], int num); > In case of using such an explicit hardware > queue polling, RSS should be configured somehow to distribute packets across > them. > > For "poll" option, it's not completely clear to me how it should relate to > NIC's > hardware queues. It looks like classification is not involved here, and this > option isn't really different from "recv". If this is correct, presence of > multiple default input queues is reasonable, since they're directly mapped to > NIC's hardware queues, and odp_queue_deq() simply extracts a packet from the > appropriate HW queue. > > -- > > Best regards, > > Nikita Kalyazin, > [email protected] > > Software Engineer > Virtualization Group > Samsung R&D Institute Russia > Tel: +7 (495) 797-25-00 #3816 > Tel: +7 (495) 797-25-03 > Office #1501, 12-1, Dvintsev str., > Moscow, 127018, Russia > _______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
