Hi Taras, Regarding #2, the initial API was creating a PMR that was bound to nothing. In that case the PMR represented for some platforms a logical abstraction. Now after this change the pmrs are bound to the cos "decision diamond" and so is no longer an abstraction. Is that right?
-----Original Message----- From: Rosenboim, Leonid [mailto:[email protected]] Sent: Thursday, April 16, 2015 7:53 PM To: Taras Kondratiuk; Bulie Radu-Andrei-B37577 Cc: [email protected]; [email protected] Subject: Re: [lng-odp] [API-NEXT PATCH] api: classification: connect PMR on creation Regarding #1, if you assign a different CoS to pktio2, then pmr1 will only be used for pktio1, e.g.: cos4 = odp_cos_create(...); odp_pktio_default_cos_set(pktio2, cos4); The real issue I see here is that if pmr1 must match packets with both cos1 and cos2 assigned to them, then it is likely that pmr1 will need to use TWO hardware resources, unless the hardware values for cos1 and cos2 can be arranges such that both can be matched using a ternary rule, e.g. if they differ only in one bit, and that can be difficult to implement. For this reason I tend to agree that each PMR must have ONE source CoS, and assigned during PMR creation. Regarding #2, this is a bit philosophical, but also very important. The idea I used to design these APIs was to not abstract any specific hardware, but to create abstractions based on what an application need to do, i.e. top-down instead of bottom-up. In believing that all hardware implementation ultimately are designed to serve roughly the same kind of application, albeit in a different way, basing abstractions on the application would seem more likely to map to most hardware implementation. Hope this helps, - Leo ________________________________________ From: Taras Kondratiuk <[email protected]> Sent: Thursday, April 16, 2015 9:00 AM To: Radu-Andrei Bulie Cc: Rosenboim, Leonid; [email protected]; [email protected] Subject: Re: [lng-odp] [API-NEXT PATCH] api: classification: connect PMR on creation On 04/16/2015 04:24 PM, Radu-Andrei Bulie wrote: > > Looking strictly at the patch I cannot understand the initial issue. Can you > give me a simple example using this new modified API? > > Regarding the assertion ". How can application detach PMR from the first > PktIO, but leave it connected to the second one?" > One possible solution is to limit this from the API. (you cannot assign a pmr > to multiple physical ports). > Things could get more complicated > if we have a pmr chain and somewhere in the middle we have a pmr that is > reached from two ports for example. Let me try to rephrase it. In short current design has two issues: 1. Changes to classification tree cannot be reverted. cos1 = odp_cos_create(...); cos2 = odp_cos_create(...); cos3 = odp_cos_create(...); odp_pktio_default_cos_set(pktio1, cos1); odp_pktio_default_cos_set(pktio2, cos2); pmr1 = odp_pmr_create_match(...); odp_cos_pmr_cos(pmr1, cos1, cos3); odp_cos_pmr_cos(pmr1, cos2, cos3); +--------+ +------+ | pktio1 |----| cos1 |-+ +--------+ +------+ \ +------+ +------+ -->| pmr1 |-->| cos3 | +--------+ +------+ / +------+ +------+ | pktio2 |----| cos2 |-+ +--------+ +------+ PMR can be destroyed completely, but there is no way to detach PMR from only one PktIO. Sure you can add restriction in documentation which prevents application from using the same PMR twice, but it just highlights the issue in API design. 2. Current PMR abstraction is pointless. PMR represents only a set of user-specified parameters. What is the point to abstract them? To show usage example of modified API let's modify an example above. A difference in a code is minor. cos1 = odp_cos_create(...); cos2 = odp_cos_create(...); cos3 = odp_cos_create(...); odp_pktio_default_cos_set(pktio1, cos1); odp_pktio_default_cos_set(pktio2, cos2); pmr1 = odp_pmr_create_match(..., cos1, cos3); pmr2 = odp_pmr_create_match(..., cos2, cos3); +--------+ +------+ pmr1 | pktio1 |----| cos1 |------+ +--------+ +------+ \ +------+ ->| cos3 | +--------+ +------+ pmr2 / +------+ | pktio2 |----| cos2 |------+ +--------+ +------+ _______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
