Hi Barry, thanks for all these details and explanations. Regarding enhanced API for finding HW configurations those are meant to help in creating portable HW-accelerated applications. The changes may be modest but the goal is not, I think. A high level description of these changes : - set egress of a TM system independently of creation - get capabilities of a given level in a HW TM system, motivated by the fact that different levels may have different features - introduce a maximum and minimum level of levels for a TM systems - not an API change per-se, but I think it's necessary to clearly document that the TM tree creation may not be possible in any order , so that a level N node should be completely configured before it's N+1 level children are created - changing TM queue parameters after configuration may not be always possible - updating a shared profile may not always update all objects (TM nodes) which use that profile - allow local priorities, configurable or not by the user - clarify use of sched params for case when odp_tm_queue_sched_config is used - in this case the only first weight in the sched_weight array should be considered by the implementation (cannot have multiple weights on a single TM queue). However, another question is what is the best way to configure different weights on different queues (with the same prio) - use a new profile, use odp_tm_sched_params_update ?
Thanks, Alex On 9 January 2016 at 17:46, Barry Spinney <spin...@ezchip.com> wrote: > > I just realized that I neglected to add a README to the > > new "test/validation/traffic_mngr" directory explaining how > > to run these tests. Basically the simple answer is "the same > > as the pktio tests", since much of the initial pktio setup code > > came from the pktio tests. But of course since the code for > > these tests can diverge, the traffic_mngr tests need their > > README. There are 3 different ways to configure the pktio > > and traffic_mngr tests, but I cam only going to discuss one > > of them - namely the one I have done the most testing > > with and so I have the most confidence in. > > > Basically need a box with a pair of 1 Gbps or 10 Gbps links. > > Connect these two interfaces with a cable, so that everything > > sent by one interface will be received by the other. Then > > set the two environment variables - ODP_PKTIO_IF0 and > > ODP_PKTIO_IF1 - to contain the names of the two interfaces. > > Then run the pktio tests to prove that these are set correctly, > > and that the odp pktio systems is happy with the interface > > names and has access (often means test needs to be run as > > root). If you can't get the pktio tests to open these links > > and send and receive traffic, there is probably no point to > > trying the traffic_mngr tests. > > > Also regarding the enhancement of the traffic_mngr tests > > to support an improved API for finding HW configurations, > > that should be considered a separate follow on piece of > > work involving modest changes both to the API header files, > > the implementation, the example and the test. But first we > > collectively need to agree on EXACTLY what should change > > in the API ala your feedback. I was planning on sending > > a request for comment email prior to Tuesday mornings > > call with a proposed change (or maybe even a couple of > > proposals). But I don't think this should hold up the > > acceptance of the existing patch set into the git repo. > > A lot easier to patch something that has been added to > > the git repo that patching a set of ongoing patches. > > > Regarding the testing of hierarchical WRED - I deferred this since > > I had the impression that many vendors didn't support this > > and so its importance was a bit little. Of course there is > > a fairly substantial set of tests of normal (tm_queue based) > > WRED. This is particularly tricky given the fact the WRED is > > inherently random and so the test has to deal with the fact > > that which pkts get dropped (and even the number of pkts > > dropped) is not predictable! > > > Thanx Barry. > > > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lng-odp > >
_______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
