On 14 April 2015 at 04:53, Ola Liljedahl <[email protected]> wrote:
> Moving a function from one header file to another doesn't really change > anything. The classification API isn't optional (but the level of actual > functionality is implementation/platform specific). Most users will just > include <odp.h> anyway. > > I don't disagree with odp_pktio_default_cos_set() having a better home in > classification.h, possibly this is better showing the dependencies between > different parts of the ODP architecture. > I see that as a major point - to reinforce the ODP logical modules view and its integrity and thus encapsulate any varying level of platform specific functionality very clearly. I think we should view the modules as OO classes with a public and possibly a private interface conceptually. > > > > On 10 April 2015 at 12:37, Bill Fischofer <[email protected]> > wrote: > >> The assignment of APIs to files was Petri's decision, so he needs to be >> involved in any revision of those assignments. >> >> On Fri, Apr 10, 2015 at 5:22 AM, Bala Manoharan < >> [email protected]> wrote: >> >>> On 10 April 2015 at 15:30, Taras Kondratiuk <[email protected]> >>> wrote: >>> > On 04/09/2015 04:37 PM, Bala Manoharan wrote: >>> >> On 9 April 2015 at 14:38, Taras Kondratiuk < >>> [email protected]> wrote: >>> >>> + mailing list that I've missed initially in the RFC. >>> >>> >>> >>> On 04/08/2015 10:25 PM, Rosenboim, Leonid wrote: >>> >>>> >>> >>>> Taras, >>> >>>> >>> >>>> I actually agree with you that a change in the API is justified >>> >>>> that combines the in and out CoS values are provided at the time >>> >>>> of PMR creation, instead of using a separate function. >>> >>>> The main reason is that the input CoS is one of the rules that >>> >>>> the ternary CAM must match, and the output CoS is the action >>> >>>> that it must be assigned. >>> >>>> >>> >>>> Here the key changes I propose, granted that there will >>> >>>> need to be additional changes made in other APIs in a similar >>> manner. >>> >>> >>> >>> >>> >>> Yes this is an alternative approach. >>> >>> >>> >>> odp_pktio_pmr_cos() should be renamed to something like >>> >>> odp_pktio_cos_set() >>> >>> Is there still an implicit 'default' CoS assigned to Pktio on >>> >>> odp_pktio_open()? Or this function should be used to set a default >>> one? >>> >> >>> >> IMO, it might be better to have assigning of default CoS as a separate >>> >> function rather than on odp_pktio_open() since it gives freedom for >>> >> platforms which do not support classifier and also it treats >>> >> classifier as a separate module >>> > >>> > Actually we already have a function for this: >>> > int odp_pktio_default_cos_set(odp_pktio_t pktio, odp_cos_t default_cos) >>> >>> Yes. This function is already available but I thought the question was >>> as to add default CoS as part of odp_pktio_open() function. It is fine >>> if we are on the same page here. >>> >>> > >>> > It is in packet_io.h now. IMO to keep classification as a separate >>> > module all CoS-related API should be in classification.h. >>> >>> I agree. This function should be moved to classification.h file. >>> >>> > >>> > -- >>> > Taras Kondratiuk >>> >>> Regards, >>> Bala >>> >> >> >> _______________________________________________ >> lng-odp mailing list >> [email protected] >> https://lists.linaro.org/mailman/listinfo/lng-odp >> >> > > _______________________________________________ > lng-odp mailing list > [email protected] > https://lists.linaro.org/mailman/listinfo/lng-odp > > -- Mike Holmes Technical Manager - Linaro Networking Group Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
