On Wed, Dec 10, 2014 at 1:35 PM, Radu-Andrei Bulie <[email protected]> wrote: > I have some classification API questions: > > > > 1. A packet that was classified on a pmr or pmr_set would finally reach a > target cos which will be translated in a queue or > > a queue group that will be scheduled by the scheduler (frame ordering being > insured if the queue is synched ATOMIC or ORDERED). > > So the queue is selected based on the classification process. What is > purpose of flow signature and what is the relation with the pmrs/pmr sets > and also with queues?
I'm no expert, but what little information exists on this topic is covered in the Classification API Doc, I think you should be able to access it: https://docs.google.com/a/linaro.org/document/d/1X42rqzv9qSLrJFU3QZoXXegZHDkonPjP8oKinlyr1R4/edit#heading=h.4tw2trdvw0du There is no API for dealing with flows yet, but what I understood so far, and please others correct me if I'm wrong, one of the purposes of the classes of service is to assign different priorities to different types of traffic, based on whatever the application wants to. The flow concept relates in turn to distributing the workload to multiple CPUs, allowing to group packets in a flow, distributing pieces to different CPUs and reassembling them in the same order they originally appeared. So the relation to classes of service would be one of strict inclusion, packets in a CoS are further broken down into different flows, with the mention that the two concepts are decoupled. > > Can you give a calling sequence example of using flow signature in the > context of classification? > > > > 2. In the classification document there is a statement: > > “If multiple PMRs match the implementation MAY define an inherent precedence > or it MAY be unpredictable as to which PMR will determine the assigned > CoS.”. Suppose we have two different platforms; on both of them we set two > pmrs – ip.src and the other udp.sport (in this order). Due to > > the different support and implementation on these platforms, udp.sport could > be applied first on one of the platforms. Does this mean that we shall have > > different functionality depending on the platform(and in the same time > different output results from platform to platform)? > > > > 3. odp_pmr_terms_avail(void) – if this gives the number of pmrs available > for use in the system what about pmr_sets?(There is no function for this) > > > > 4. odp_pmr_match_count(odp_pmr_t pmr_id) – this function gives the number > of packets that matched a pmr. What about pmr sets? (There is no function > for this) > > > > > > 5. odp_cos_set_drop – only configures/changes the existing action on a > cos to drop(no matter if we have cascade pmrs, pmrs or pmr sets)? If not, > can you explain this in the context with the buffer pool drop policy? > > > > 6. I see that TCP and UDP header fields such as SPORT, DPORT can be used > in the PMR rules. Some hardware/software implementation support IP > reassembly before PMR match can be done. Some implementation may not be able > to do that. How does ODP reconcile to it? I did not see any text indicating > the expected behavior if the fragmented packets are received > > > > > > Regards, > > > > Radu > > > > > > > > > _______________________________________________ > lng-odp mailing list > [email protected] > http://lists.linaro.org/mailman/listinfo/lng-odp > _______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
